自動化部署方案CICD

自動化部署方案

 

因爲來來也的時間不久，可能對現有的部署狀況不是很瞭解，如下是我的對POC自動化部署的設計方案。

自動化部署優勢

下降成本，提升生產力，高可用，更可靠，性能優化

 

與gitlab持續集成的比較流行的有jenkins和gitlab-ci

Jenkins:

優勢：編譯服務和代碼倉庫分離，並且編譯配置文件不須要在工程中配置，若是團隊有開發、測試、配置管理員、運維、實施等完整的人員配置，那就採用jenkins，這樣職責分明。jenkins依靠它豐富的插件，能夠配置不少gitlab-ci不存在的功能，好比說看編譯情況統計等。

缺點：配置相對複雜，維護成本較高等

gitlab-ci:

優勢：完美和gitlab進行集成，gitlab-ci已經集成進gitlab服務器中，在使用的時候只須要安裝配置gitlab-runner便可。 gitlab-runner基本上提供了一個能夠進行編譯的環境，負責從gitlab中拉取代碼，根據工程中配置的gitlab-ci.yml，執行相應的命令進行編譯。

缺點：功能相對少一些，沒有web頁面查看等

總結：

我的以爲gitlab-ci更簡單易用，若是有gitlab-ci達不到的要求，能夠考慮使用jenkins。若是隻部署poc類似的項目使用gitlab-ci能夠知足需求。

 

方案一：gitlab-ce + gitlab-runner + docker

 

從左往右看，首先研發人員完成需求提交代碼到 GitLab。GitLab 觸發一次 Build，構建好服務，而後開始跑單元測試、集成測試。等待測試結果經過後，再由負責該項目的同事進行 CodeReview（可省略），灰度發佈，正式部署到線上，支持shell部署和docker部署。

 

 

gitlab-ce 代碼倉庫管理與pipeline主控臺

gitlab-runner 則是當pipeline啓動時，會根據gitlab特有的gitlab-ci.yml執行CI/CD

gitlab-ce 每一個project會有一組本身的token，用以註冊gitlab-runner

gitlab-runner註冊時，能夠選擇執行方式(executor)，咱們選擇docker

gitlab-runner會另外開幾個container來pull code與執行CI/CD，最後push到服務器上

 

主要步驟：

編寫統一格式dockerfile，若是多應用關聯編寫docker-compose文件

編寫統一pipeline，註冊ci-runner等

 

 

上圖是一個典型的 Pipeline，一共有 5 個階段，Build，Test，Release， Staging， Production，每一個階段裏都至少有一個 Job，Test 中有兩個 Job。GitLab 會從左往右依次把任務給到 Runner 處理，若是中途有一個任務沒有處理成功的話，整個 Pipeline 就會退出。這就是持續集成（CI）、持續發佈（CD） 的一個流程。

 

方案二：gitlab + jenkins + docker

• 開發者向本身的gitlab網站提交了代碼
• 經過webhook讓jenkins執行自動化構建過程
• jenkins從git上拉取代碼進行構建，如構建失敗可配置郵件通知開發人員
• jenkins在自動化構建腳本中調用docker命令將構建好的鏡像push 私有鏡像服務器
• 同時，jenkins也能夠直接執行remote shell啓動構建好的容器
• 服務端能夠手動經過docker命令，從鏡像倉庫中心拉取鏡像，進行手動

 

總結：我的意見若是隻部署poc相似不是很複雜的應用能夠選擇方案一知足

緣由：配置簡單使用方便，能夠花較少的時間完成自動化部署，節約成本，主要比較符合現狀。可是若是之後須要區分環境部署，作一些相似sonar代碼的健康檢查等，可能不能很好的完成。

 

我的不成熟建議：隨時時間變長，poc的項目也會愈來愈多，每一個人的項目也會愈來愈多，可能須要一些資產的管理，例如CMDB，權限系統控制每一個人操做的權限等，能夠引入devops的概念，從急需的需求，慢慢作起。