使用rancher知足程序猿剛需

經過將近1個季度的努力，基本上完成了內網開發、測試以及生產環境（藉助公有云容器引擎服務）關鍵服務容器化工做。 在這個過程當中，原本是把已經驗證過的技術和方案進行落地，只是執行上的問題。可是研發大爺在使用過程當中又提出了許多新的需求，見招拆招以後，發現仍是有些許收穫，所以整理成文，本文介紹rancher server的應用。

1、什麼是rancher？

Rancher是一個開源的企業級容器管理平臺，經過使用rancher，能夠快速的構建出kubernetes環境並對其進行可視化管理。 Rancher由如下四個部分組成：
一、基礎設施編排
Rancher可使用任何公有云或者私有云的Linux主機資源。對計算資源進行整合和統一調度使用

二、容器編排與調度
Rancher包含了當前所有主流的編排調度引擎，同一個用戶能夠建立Swarm或者Kubernetes集羣。而且可使用原生的Swarm或者Kubernetes工具管理集羣。

三、應用商店
Rancher的用戶能夠在應用商店裏一鍵部署由多個容器組成的應用，例如容器的日誌集中收集應用套件。

四、企業級權限管理
Rancher支持靈活的插件式的用戶認證。支持Active Directory，LDAP， Github等 認證方式。 Rancher支持在環境級別的基於角色的訪問控制 (RBAC)，能夠經過角色來配置某個用戶或者用戶組對開發環境或者生產環境的訪問權限。

更多信息請移步官網：https://rancher.com/

2、爲何要用rancher？

每一個人選擇用rancher的緣由可能各不同，這裏列出rancher能解決的一些實際問題。

一、下降kubernetes集羣的部署門檻
咱們一般使用kubeadm或者二進制方式部署kubernetes集羣，若是你想擁有一個kubernetes學習環境，經過使用rancher，只須要按照嚮導在主機上運行指定的命令，而後等待片刻，就能夠獲得一個kubernetes環境，大大下降了集羣的入門門檻。

二、統一管理各個環境的kubernetes集羣
當有開發環境、測試環境、正式環境甚至更多的kubernetes集羣的時候，如何集中管理這些集羣資源是個問題。rancher提供了很好的解決方案，支持各大公有云的雲容器和自建kubernetes的納管工做。
簡單來講，kubernetes實現了各個主機上docker資源的統一管理，rancher在kubernetes之上，實現了對kubernetes的集中管理。

三、替換kubernetes原生的dashboard
原生的dashboard雖然能夠經過rbac來控制用戶的訪問權限，但在實際的配置中仍是太繁瑣了，尤爲是用戶數多，且每一個用戶的權限又要求設置的不同的時候。Rancher經過項目和namespace掛鉤，對用戶受權各個項目的權限來有效簡化了配置。

其次原生的dashboard的shell web窗口是不支持黏貼的，這個在內網開發和測試環境被無數的吐槽。Rancher提供了完美的解決方案。

3、使用rancher納管k8s集羣

Rancher server自己就是一個docker 容器，能夠運行在kubernetes集羣外部。固然若是你有需求的話，也能夠部署在集羣內。

# yum -y install docker
# docker run -d -p 80:80 -p 443:443  --name rancher-server \
-v /root/star_59iedu_com.pem:/etc/rancher/ssl/cert.pem \
-v /root/star_59iedu_com.key:/etc/rancher/ssl/key.pem \
-v /var/lib/rancher:/var/lib/rancher \
--restart=unless-stopped  rancher/rancher

設置初始密碼和訪問url地址


添加集羣，選擇導入方式納管已存在的k8s集羣

在k8s master節點上建立對應的資源，完成納管。

這裏常常遇到的問題是DNS解析問題，建議在dns後臺將對應的記錄添加好，避免出現納管失敗的狀況。

4、rancher使用

納管完成後能夠看到k8s集羣的資源狀況

建立全局用戶

經過建立project和namespace掛鉤

點擊集羣中的「成員」設置全局用戶對全部項目的權限，相似組的概念

點擊項目「編輯」設置全局用戶對項目的權限

終端使用
點擊「集羣」，能夠運行kubectl工具

經過點擊項目的工做負載「執行命令行」，能夠運行一個shell終端，終端支持黏貼。

後記：

來自程序猿的若干需求：
一、我使用rancher的初衷是爲了解決shell終端黏貼的問題，在內網開發和測試環境，碼農們出於固定思惟，喜歡登錄到容器內部瞧瞧看看，美其名曰debug。

二、適配完終端黏貼的問題以後，碼農提出了新的需求，他們在終端裏面搗鼓半天，須要把結果文件下載到本地，而後但願經過sz命令下載下來，或者經過rz命令能上傳一些class文件進去編輯，這個是任何web終端工具都解決不了的問題，由於lrzsz不能適配web終端。解決方案是把文件保留到PVC裏面，經過共享存儲來解決這種無聊的需求。

三、緊接着，無聊的程序猿又要求能在pod裏面遠程debug，仍是固定思惟。原來tomcat非容器編排部署的是/home/tomcat/bin/catalina.sh jpda start 方式啓動，默認會啓動一個8000的端口，程序猿們就能夠在IDE工具上進行斷點debug。目前咱們開發、測試和生產環境用的jdk、tomcat等基礎鏡像是同一個，程序猿們又不想修改maven上相關的配置，從運維上看，也不想維護多個基礎鏡像，那麼如何解決這個問題呢？同一個基礎鏡像，相同的代碼包，如何適配多個環境呢？且看下回分解。