iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 14
1
DevOps

和艦長一起 30 天玩轉 GitLab系列 第 14

CI/CD Pipeline 之 stage: prod-deploy

前三天我們搞定了 CI/CD Pipeline 的 builddeploytest,今天輪到 prod-deploy

在我們的假想情境中,dev 與 stg 環境分別對應 develop 與 master branch,兩者的 CI/CD Pipeline 基本上大同小異。而 production 環境則對應 production branch,CI/CD Pipeline 則多了一個 stage: prod-deploy。

https://ithelp.ithome.com.tw/upload/images/20190927/20120986ZsbnYwR8N2.jpg
(Production branch 多了一個需要 User 去手動觸發的 CI Job prod-deploy。)

Stage: prod-deploy

首先我們要問 prod-deploydeploy 到底差在哪裡?關鍵在於 Production 環境是一個客戶與使用者們正在使用中的環境,如果要將程式部署至此種環境,需要考慮的問題就多了,特別是根據程式部署時該程式(服務)是否可以下線(停機)又會產生巨大的差異。

如果 prod-deploy 時,程式(服務)是可以下線的,那麼目標 Server 就可以維持在一個靜止的狀態,維運人員就可以輕易的在部署之前先對資料庫、環境、檔案做備份,按部就班的部署程式。如果部署失敗了,也可以盡快從備份還原至上一個版本,將損害降到最小。

但如果必須要在程式(服務)維持上線的狀態下部署,那麼通常你的 Production 環境應該有一定的規模,也許有一些 HA 的架構或 Load balancer 的機制,是由多台 Server 支撐著程式(服務)。在此種狀況下,為了不影響到線上的使用者,就必須使用一些不一樣的部署策略,像是藍綠部署(Blue/Green Deployment)、金絲雀發佈(Canary Release)或 Rolling Release⋯⋯等。如果要談這些,又是另一個鐵人賽 30 天,所以同樣的這邊就不過度深入,讓我們繼續回到假想情境。

既然我們的情境是一個全新團隊正在開發全新的產品,目前產品還不算是公開發表,只有募集一批測試使用者,因此目前的 Production 環境是可以停機進行部署的。在這樣的情境 prod-deploy 要處理的問題與 deploy 差不多,一樣是 GitLab Runner 本身是否具備部署程式至 Production 環境的能力與相關的授權。如果這些問題都克服了,那麼 .gitlab-ci.yml 內的 prod-deploy 這項 CI Job 應該會類似如下:

prod-deploy:
  stage: prod-deploy
  only:
    - production
  script:
    - ansible-playbook prod-deploy.yml
  when: manual
  environment:
    name: production
    url: https://production.website.com

在 Day 10 已經有提過,只要設置 when: manual 在 GitLab CI 就會自動讓該項 CI Job 變成需要人工手動觸發,只有 User 手動按下 UI 介面上的「箭頭」,GitLab Runner 才會開始執行它。

https://ithelp.ithome.com.tw/upload/images/20190927/20120986IB6YwShbks.jpg
when: manual 的 Job 會是一個齒輪的圖示,需要 User 按下右邊的箭頭才會開始執行。)

今天新增加的 environment: 則是幫助你在 GitLab 上可以有獨立的介面管理部署動作。只要有成功設置 environment:,並且有成功執行過該 CI Job,在 Operations > Environments 就會出現類似下圖的介面。

https://ithelp.ithome.com.tw/upload/images/20190927/20120986UaGvyAb4pv.jpg
(如果你針對 dev 與 stg 的 deploy 也有設置 environment:,也會一併條列於此。)

https://ithelp.ithome.com.tw/upload/images/20190927/20120986ZtBEW262tu.jpg
(如果部署出了問題,隨時可以按下 Re-deploy,GitLab Runner 就會幫你再次執行該 CI Job,自動重新部署。)

針對每個 environment 還可以點進去查看每一次 deploy 的紀錄。

https://ithelp.ithome.com.tw/upload/images/20190927/20120986I8aDVrosHK.jpg
(每一筆紀錄也會顯示並連結是對應哪一個 Commit 與哪一個 CI Job,方便關聯查看相關資訊。)

Environments 被歸納在 Operations 之下,你可以看到在 Operations 之中還有其他像是 MetricsError Tracking⋯⋯等和維運有關的功能。這些也是 GitLab 隨著 GitLab Workflow 發展的越來越完整,而出現的新功能,讓 GitLab 不只能做到 CI/CD,還能涉足 Ops 部分工作,成為資訊彙整的中心。

https://ithelp.ithome.com.tw/upload/images/20190927/20120986BtDNY3QIbs.jpg
(Operations 的功能越來越多,其實最初 Environments 是獨立一個功能,在近幾次改版 GitLab 新增了 Operations 之後,才被收編在旗下。)

小結

今天我們談了最簡單的 prod-deploy,艦長只能說可以先停機再接續處理服務的維護與部署是幸福的。在現實的職場中,多是不能停機,必須即時處理的狀況,如果後續的文章進度許可,我們應該也有機會談到這方面的一些經驗談。那麼回到今天的內容,針對 prod-deploy 可能會有哪些需要處理的麻煩事呢?

  • 你的 CI Server/Worker 是否具備 prod-deploy 的能力與權限?
  • 續上,CI Server 如具備了 prod-deploy 的權限,那權限控管安全嗎?CI Server 本身的安全性足夠嗎?
  • 如何做到不停機部署?如何做到大量部署至多台 Server?
  • 誰擁有權限按下 prod-deploy 的按鈕?又如何控管權限?
  • deploypord-deploy 自動化部署腳本的內容會是一致的嗎?有必要一致嗎?
  • 除了程式部署之外,還有哪些額外的動作需要處理?例如是否需要設置 Nginx?是否有 DB Migrate 的動作需要處理?

扯到 Production 環境,通常要考慮的事情就會像峭壁一樣突然陡峭的攀升,上面也只是簡單列舉部分項目。後面我們還會繼續改善我們的 CI/CD Pipeline,並解答這幾天提出的一些疑問,鐵人賽我們繼續努力!

參考資料


上一篇
CI/CD Pipeline 之 stage: test
下一篇
GitLab: To-Do List 與 Milestones
系列文
和艦長一起 30 天玩轉 GitLab30

尚未有邦友留言

立即登入留言