CI/CD Pipeline 之 stage: prod-deploy

第 11 屆 iThome 鐵人賽

DAY 14

DevOps

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

11th鐵人賽 devops gitlab

Cheng Wei

2019-09-27 21:42:08

7561 瀏覽

前三天我們搞定了 CI/CD Pipeline 的 build、deploy 與 test，今天輪到 prod-deploy。

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

（Production branch 多了一個需要 User 去手動觸發的 CI Job prod-deploy。）

Stage: prod-deploy

首先我們要問 prod-deploy 與 deploy 到底差在哪裡？關鍵在於 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 才會開始執行它。

（when: manual 的 Job 會是一個齒輪的圖示，需要 User 按下右邊的箭頭才會開始執行。）

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

（如果你針對 dev 與 stg 的 deploy 也有設置 environment:，也會一併條列於此。）

（如果部署出了問題，隨時可以按下 Re-deploy，GitLab Runner 就會幫你再次執行該 CI Job，自動重新部署。）

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

（每一筆紀錄也會顯示並連結是對應哪一個 Commit 與哪一個 CI Job，方便關聯查看相關資訊。）

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

（Operations 的功能越來越多，其實最初 Environments 是獨立一個功能，在近幾次改版 GitLab 新增了 Operations 之後，才被收編在旗下。）

小結

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