在業務中使用Rancher差不多4年時間了, 在這期間, 已經將部門所有的應用容器化, 且均透過Rancher進行部署. 我也來談談我對Rancher這個平臺的看法和相關的使用經驗.
我所在的部門, 是直接對接業務的, 需要針對不同的業務場景, 將資料清洗成不同的格式. 有時候幾天上線一次, 有時候一天上線幾次. 對我們開發和測試人員來說, 到沒有什麼, 但對運維同事來說, 就是比較頭疼的事情了. 為了提升效率, 運維同事給我們搭建了Rancher平臺, 併為我們提供了關於容器(Docker)和Rancher的基礎培訓. 簡單來說, Rancher是一個開源的面向企業的容器編排管理平臺. 藉助Rancher, 公司不用從頭搭建容器服務平臺. 而且運維人員只需維護Rancher, 和管理的物理主機即可, 他們不再關係業務程式的詳細執行機制. Rancher+Docker, 就真正解放了運維, 他們可以將時間和精力花在其他更重要的方面. 這就是我所在公司的部門, 使用Rancher的原因.
構建好Docker容器後(這裡就不講Docker相關的構建了), 我們一般都是手動升級線上正在執行的容器. 每次, 就是手動的升級! 有時候修改了一些基礎程式碼, 就需要把所有的容器一個一個地點升級, 我們的容器數量, 不說幾百個, 幾十個還是有的.
這樣的手動升級, 肯定是效率低下的. 而且Rancher作為一個企業及的容器管理平臺, 肯定提供了相關的方案, 能夠實現一鍵升級. 經過相關的調研, 我們又引入了Gitlab + Jenkins + Docker + Harbor + Rancher的方案. 典型的持續整合方案.
具體流程如下(程式碼提交到部署開發/測試環境, 省略程式碼審查和UT部分):
開發人員合併程式碼到目標分支, 自動觸發Jenkins構建任務
Jenkins將目的碼打包到Docker映象中, 並將容器推送的映象倉庫Harbor.
根據jenkins配置, 將Rancher上的目標容器進行升級.
整個流程全是自動的, 差不多在10s時間能夠完成整個流程.
目前我所負責的一個專案, 其中有100+容器, 均使用這種方案進行持續整合, 持續部署. 效果卓著.
關於這個流程的詳細實現方案, 後面有機會, 再和大家分享.
在業務中使用Rancher差不多4年時間了, 在這期間, 已經將部門所有的應用容器化, 且均透過Rancher進行部署. 我也來談談我對Rancher這個平臺的看法和相關的使用經驗.
為什麼使用Rancher?我所在的部門, 是直接對接業務的, 需要針對不同的業務場景, 將資料清洗成不同的格式. 有時候幾天上線一次, 有時候一天上線幾次. 對我們開發和測試人員來說, 到沒有什麼, 但對運維同事來說, 就是比較頭疼的事情了. 為了提升效率, 運維同事給我們搭建了Rancher平臺, 併為我們提供了關於容器(Docker)和Rancher的基礎培訓. 簡單來說, Rancher是一個開源的面向企業的容器編排管理平臺. 藉助Rancher, 公司不用從頭搭建容器服務平臺. 而且運維人員只需維護Rancher, 和管理的物理主機即可, 他們不再關係業務程式的詳細執行機制. Rancher+Docker, 就真正解放了運維, 他們可以將時間和精力花在其他更重要的方面. 這就是我所在公司的部門, 使用Rancher的原因.
怎麼使用Rancher?構建好Docker容器後(這裡就不講Docker相關的構建了), 我們一般都是手動升級線上正在執行的容器. 每次, 就是手動的升級! 有時候修改了一些基礎程式碼, 就需要把所有的容器一個一個地點升級, 我們的容器數量, 不說幾百個, 幾十個還是有的.
這樣的手動升級, 肯定是效率低下的. 而且Rancher作為一個企業及的容器管理平臺, 肯定提供了相關的方案, 能夠實現一鍵升級. 經過相關的調研, 我們又引入了Gitlab + Jenkins + Docker + Harbor + Rancher的方案. 典型的持續整合方案.
具體流程如下(程式碼提交到部署開發/測試環境, 省略程式碼審查和UT部分):
開發人員合併程式碼到目標分支, 自動觸發Jenkins構建任務
Jenkins將目的碼打包到Docker映象中, 並將容器推送的映象倉庫Harbor.
根據jenkins配置, 將Rancher上的目標容器進行升級.
整個流程全是自動的, 差不多在10s時間能夠完成整個流程.
目前我所負責的一個專案, 其中有100+容器, 均使用這種方案進行持續整合, 持續部署. 效果卓著.
關於這個流程的詳細實現方案, 後面有機會, 再和大家分享.