iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 25
1
DevOps

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

GitLab: Auto DevOps 之牛刀小試 3 - Auto Deploy (Production)

昨天我們為 Auto DevOps 設置了 K8S,順利讓它可以產生完整的 CI/CD Pipeline,但在 Stage: Staging 卻出現卡關的狀況。今天就讓我們接續這個狀況繼續試用 Auto DevOps

設置 Base domain

前兩天的文章都有提到,在 Auto DevOps 的四大 Requirements 中有一項是「能自由掌控的 Domain name」。如果你查看 Stage: Staging 的錯誤訊息,會發現其中也再次提醒必須要為 Auto DevOps 設置 Base domain

https://ithelp.ithome.com.tw/upload/images/20191008/20120986hJXumwaAn0.jpg

該如何取得一個「能自由掌控的 Domain name」呢?總之最簡單的方法就是花錢去買一個吧!當然也有一些免費的選擇,不過這裡就不說明了,大家可以自己 Google。

在取得了 Domain name 之後,即可在 Project 的 Operations > Kubernetes 中設置它。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986sJgKNKyyrJ.jpg

接著別急著離開,在同一個頁面往下拉,我們要查看在 Applications 中的 Ingress,理論上應該會顯示 Ingress Endpoint,這是一組 IP 位置,請將它記錄下來。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986f3eXYbivMJ.jpg

下一步,就請你前往 Domain name 供應商的管理後台,為你剛才設置的 Base domain 設置一組 wildcard DNS。假設你的 Base domainyour.domain-name.com,就請新增一筆 DNS 紀錄是 *.your.domain-name.com 指向前面拿到的 Ingress Endpoint

https://ithelp.ithome.com.tw/upload/images/20191008/20120986gdb9BSY3xK.jpg

Auto Deploy - Staging

在成功設置了 Base Domain 之後,我們再次讓 CI/CD Pipeline 重跑,這一次應該就會正常地完成 Stage: Staging,然後停在 Production 等著 User 手動 trigger。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986QJ8gWTBIsv.jpg

接著可以前往 Operations > Environments,可以看見 staging 環境已被建立。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986Tq9FEIHrNc.jpg

只要點擊右側的 Open live environment 就可以瀏覽 Staging 環境。

https://ithelp.ithome.com.tw/upload/images/20191008/201209868HHjtZEc8g.jpg

開啟後應該能夠看見下面的網頁。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986bNc6fr91Pa.jpg

Auto Deploy - Production

接下來我們要試試看 Production Deploy,回到 CI/CD Pipeline 會看見 Stage: Production 會有四個看起來很相像的 CI Job,分別是 rollout 10%、25%、50%、100%。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986apVVRNd983.jpg

這四個看起來相像的 CI Job 可是大有學問的,簡單來說就是充分利用了 K8S 的特性而實現的一種部署方法。假設你的 Production 環境有 10 台 Server,rollout 10% 就會自動幫你部署新版程式在 1 台 Server,同理 50% 就是 5 台。

因此這四個 CI Job 你必須從上慢慢往下按。也就是說你可以僅先部署至 10% 的 Production 環境試試水溫,沒有出現異常,才逐步增加至 25%、50%,最後全部 100% 的 Production 環境都完成部署。倘若在 10% 就發現異常,剩下 90% 就不用急著部署,影響範圍將被縮限在 10%。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986BMDJAn3Vau.jpg
(由上到下,逐步將新版程式部署在所有的 Production 環境。)

不過我們目前才剛開始試用 Auto DevOps,其實只有啟用一個 Pod(不熟悉 K8S 的人,就當作我們只有一台 Server),因此這四個 CI Job 實際上並沒有任何意義,當你按下 rollout 10% 的時候,其實就已經是 100% 了。雖然如此,你還是要依序將這四個 CI Job 執行完畢,不然最後一個 Stage: Performance 不會執行。

部署完畢,一樣可以前往 Operations > Environments 查看,這次會發現 Production 環境已被建立。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986rrSUCECFiL.jpg

同樣可以直接瀏覽 Production 網站。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986TSc3vkscs1.jpg

下一步,我們先讓 Pods 數量增加一些,讓 rollout 能真正發揮它的效果。這裡我們要進入 Settings > CI/CD > Variables,並且新增 PRODUCTION_REPLICAS 這個變數,此變數的預設值為 1,我們試著提升到 10。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986H0jreiYrc8.jpg

接著前往 Operations > Environments 按下 re-deploy,這一次就會將程式部署至 10 個 Pods。

https://ithelp.ithome.com.tw/upload/images/20191008/201209868aK993hEiw.jpg

查看 re-deploy 的日誌,可以看見確實有部署至 10 個 Pods。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986jPldSVsUzV.jpg

讓我們再做一次實驗,這一次修改一下 Source Code,讓 GitLab 產生一條新的 CI/CD Pipeline,重新跑一次。

我們要修改兩個檔案,分別如下:

  • app/views/welcome/index.html.erb
  • test/controllers/weclome_controller_test.rb

將上面兩個檔案原本的字串 You're on Rails! 都改成你想要顯示的文字,然後送出 commit。

https://ithelp.ithome.com.tw/upload/images/20191008/20120986ANyOYKmnes.jpg

https://ithelp.ithome.com.tw/upload/images/20191008/20120986x6mIruhcIg.jpg
(這個是測試,如果沒一起改,等一下在 test 可是不會過的喔!)

https://ithelp.ithome.com.tw/upload/images/20191008/20120986mCB1syLexz.jpg
(GitLab 的 Web IDE 滿好用的,可以直接線上編輯多個檔案,並且直接 git commit 至指定的 branch。)

等待新的 Pipeline 跑一下。
https://ithelp.ithome.com.tw/upload/images/20191008/201209862g9hzyOds0.jpg

再次逐一執行 Stage: Production
https://ithelp.ithome.com.tw/upload/images/20191008/201209867BOQ8g052k.jpg

這次查看 CI Job 的日誌,就會看見 K8S 在幫你更新 Pods。
https://ithelp.ithome.com.tw/upload/images/20191008/20120986k4QEq7pIk8.jpg

如果你在 rollout 10%、25% 或 50% 的階段瀏覽 Production 環境,就會發現有時候還會看到舊的網站,有時會看見新版網站,這正是因為還沒有 100% 更新完畢的緣故。

https://ithelp.ithome.com.tw/upload/images/20191008/201209861FzXlVtmuF.jpg
(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

參考資料


上一篇
GitLab: Auto DevOps 之牛刀小試 2 - K8S
下一篇
GitLab: Auto DevOps 之牛刀小試 4 - Auto Browser Performance Testing
系列文
和艦長一起 30 天玩轉 GitLab30

尚未有邦友留言

立即登入留言