使用GCP Cloud Builder建置CI/CD Flow
服務的建置通常是持續性的作業，而部署則一般是專案初期建置一次，未來可以沿用該部署設定... 這樣的流程走向自動化，在Container的環境又更是重要... 本篇介紹一下，在Google雲端，我們可以搭配Source Repository與Build Trigger等服務來完成服務的自動建置與部屬，讓封裝Container與部署到Container Engine的動作可以一氣呵成...
首先幾單瞭解一下一個Container Engine服務的建置與部屬過程...
使先，建立Container Engine Cluster，透過GCP Winzard可以很快速地開立您的GKE Cluster…
假設您的cluster是叫做demo-cluster，則可以透過下面的指令來跟GKE建立連線
$ gcloud container clusters get-credentials demo-cluster --zone asia-east1-a
|
這串指令不用記ㄛ～可以在Cluster的頁面找到他...
點選複製，即可貼到您的Terminal執行...
這個專案中，包含幾個重要結構：
- app/ : 放置您的程式，在Dockerfile中會將該資料匣複製到Docker Image中
- k8s/ : 放置k8s的deployment與service描述檔
- Dockerfile : 封裝docker的描述檔，會以node.js的image為基礎來建置執行環境
- cloudbuild.yaml : Google Cloud Build Trigger的步驟描述檔
建置的流程大致描述如下：
- 當程式碼push至github後，會觸發hook(由source repository建立的)到GCP source repository
- Source repository更版後，會觸發Cloud Build Trigger來執行cloudbuild.yaml裡面的設定步驟
- cloudbuild.yaml步驟一：建置image，並上傳到gcr.io registry
- cloudbuild.yaml步驟二：觸發GKE上的版本更新
下面針對整個建置步驟描述...
Step1: 建立GCP對應的Source Repository
由於我們想要直接連動Github上的Repo，這邊選擇Github的Source Code Repo位置...
Step2: 建立Build Trigger，在這邊選擇複製自Github的Cloud Source Repository
然後選擇要建置的Cloud Repository (有filter還滿貼心的^^)
設定Build參數，指定使用自建的cloudbuild.yaml檔案來建置... 另外，Trigger Type部分，選擇Tag Build，並設定Tag Pattern為”v.*”，來聆聽符合該Tag形式的Build動作。
設定的部分就這樣，頗簡單吧... 接下來可以驗證一下設定是否正確...
剛設定的部分是只針對您的專案建立”v”開頭的tag，即可觸發建置及部署的動作，我們可以實際tag一個v開頭的tag版本，然後可以在Build History中看到建置的過程紀錄與狀態...
git tag v20170928.001
git push origin v20170928.001 |
檢視一下Build History...
如果一切無誤，可以在Status欄位看到Successful… 如果失敗，也沒關係，看一下每個步驟的log，確認一下失敗原因，排除後可以rebuild看看 :D
參考：