GitLab: Auto DevOps 之牛刀小試 3 - Auto Deploy (Production)
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10226257）
【新增補充】Auto DevOps 以及 GitLab 與 K8s 的整合方式都經歷一番大更新，因此本文有多處內容都過期了，建議各位讀者可以直接略過本文，改為查看原廠最新文件。
昨天我們為 Auto DevOps 設置了 K8S，順利讓它可以產生完整的 CI/CD Pipeline，但在 Stage: Staging 卻出現卡關的狀況。今天就讓我們接續這個狀況繼續試用 Auto DevOps。
設置 Base domain
前兩天的文章都有提到，在 Auto DevOps 的四大 Requirements 中有一項是「能自由掌控的 Domain name」。如果你查看 Stage: Staging 的錯誤訊息，會發現其中也再次提醒必須要為 Auto DevOps 設置 Base domain。
該如何取得一個「能自由掌控的 Domain name」呢？總之最簡單的方法就是花錢去買一個吧！當然也有一些免費的選擇，不過這裡就不說明了，大家可以自己 Google。
在取得了 Domain name 之後，即可在 Project 的 Operations > Kubernetes 中設置它。
接著別急著離開，在同一個頁面往下拉，我們要查看在 Applications 中的 Ingress，理論上應該會顯示 Ingress Endpoint，這是一組 IP 位置，請將它記錄下來。
下一步，就請你前往 Domain name 供應商的管理後台，為你剛才設置的 Base domain 設置一組 wildcard DNS。假設你的 Base domain 為 your.domain-name.com，就請新增一筆 DNS 紀錄是 *.your.domain-name.com 指向前面拿到的 Ingress Endpoint。
Auto Deploy - Staging
在成功設置了 Base Domain 之後，我們再次讓 CI/CD Pipeline 重跑，這一次應該就會正常地完成 Stage: Staging，然後停在 Production 等著 User 手動 trigger。
接著可以前往 Operations > Environments，可以看見 staging 環境已被建立。
只要點擊右側的 Open live environment 就可以瀏覽 Staging 環境。
開啟後應該能夠看見下面的網頁。
Auto Deploy - Production
接下來我們要試試看 Production Deploy，回到 CI/CD Pipeline 會看見 Stage: Production 會有四個看起來很相像的 CI Job，分別是 rollout 10%、25%、50%、100%。
這四個看起來相像的 CI Job 可是大有學問的，簡單來說就是充分利用了 K8S 的特性而實現的一種部署方法。假設你的 Production 環境有 10 台 Server，rollout 10% 就會自動幫你部署新版程式在 1 台 Server，同理 50% 就是 5 台。
因此這四個 CI Job 你必須從上慢慢往下按。也就是說你可以僅先部署至 10% 的 Production 環境試試水溫，沒有出現異常，才逐步增加至 25%、50%，最後全部 100% 的 Production 環境都完成部署。倘若在 10% 就發現異常，剩下 90% 就不用急著部署，影響範圍將被縮限在 10%。
（由上到下，逐步將新版程式部署在所有的 Production 環境。）
不過我們目前才剛開始試用 Auto DevOps，其實只有啟用一個 Pod（不熟悉 K8S 的人，就當作我們只有一台 Server），因此這四個 CI Job 實際上並沒有任何意義，當你按下 rollout 10% 的時候，其實就已經是 100% 了。雖然如此，你還是要依序將這四個 CI Job 執行完畢，不然最後一個 Stage: Performance 不會執行。
部署完畢，一樣可以前往 Operations > Environments 查看，這次會發現 Production 環境已被建立。
同樣可以直接瀏覽 Production 網站。
下一步，我們先讓 Pods 數量增加一些，讓 rollout 能真正發揮它的效果。這裡我們要進入 Settings > CI/CD > Variables，並且新增 PRODUCTION_REPLICAS 這個變數，此變數的預設值為 1，我們試著提升到 10。
接著前往 Operations > Environments 按下 re-deploy，這一次就會將程式部署至 10 個 Pods。
查看 re-deploy 的日誌，可以看見確實有部署至 10 個 Pods。
讓我們再做一次實驗，這一次修改一下 Source Code，讓 GitLab 產生一條新的 CI/CD Pipeline，重新跑一次。
我們要修改兩個檔案，分別如下：
app/views/welcome/index.html.erbtest/controllers/weclome_controller_test.rb
將上面兩個檔案原本的字串 You're on Rails! 都改成你想要顯示的文字，然後送出 commit。
（這個是測試，如果沒一起改，等一下在 test 可是不會過的喔！）
（GitLab 的 Web IDE 滿好用的，可以直接線上編輯多個檔案，並且直接 git commit 至指定的 branch。）
等待新的 Pipeline 跑一下。
再次逐一執行 Stage: Production
這次查看 CI Job 的日誌，就會看見 K8S 在幫你更新 Pods。
如果你在 rollout 10%、25% 或 50% 的階段瀏覽 Production 環境，就會發現有時候還會看到舊的網站，有時會看見新版網站，這正是因為還沒有 100% 更新完畢的緣故。
（rollout 100% 之後，按下重新整理也不會看見舊的網站了。）
小結
今天我們順利完成了 Auto DevOps 的 Auto Deploy，並且讓 Production 環境由 1 Pod 變成 10 個 Pods 來支撐它。還記得我們在先前 CI/CD 的文章中有針對 Deploy 提出的問題嗎？
- 如何做到不停機部署？如何做到大量部署至多台 Server？
似乎 Auto DevOps 的 Auto Deploy 利用 K8S 的特性幫我們輕易解決了上面這個問題。但這裡還是要提醒一下，我們目前都還是牛刀小試，如果你真的要善用 GitLab 的 Auto Deploy，建議還是要更加理解 K8S 的原理，並且你的 Application 也需要配合 K8S 與 Container 做出一些「調整」，可不要貿然的就將正式上線的產品轉移到 Auto DevOps。
今天就分享到這裡，明天我們繼續 Auto DevOps。