Pipeline 的實踐

yaml 的說明

昨天將如何利用kong做到藍綠分流佈署的實作邏輯後，接下來就準備要將變更管理的流程，同樣使用Azure DevOps 的 pull request 與 pipeline，來實踐整個變更管理的流程。

讀者這次請關注到下面所列的三個pipeline檔案，位於 ironman2025\case_ELK_JPG_Route_JWT\pipelines\ 資料夾下：

.
├── pipelines/
│    ├─── SIT_docker_compose_deploy.yaml
│    ├─── tmp_docker_compose_predeploy_blue.yaml
│    └─── tmp_docker_compose_swap_blue_green.yaml

與筆者之前在撰寫pipeline的習慣一樣，筆者同樣使用了範本檔作為各階段可以重複呼叫的所有步驟，由各環境帶入不同參數來完成作業。各別將主要pipeline以及範本檔簡述如下：

#SIT_docker_compose_deploy.yaml
trigger:
  branches:
    include:
      - main
  paths:
    include:
      - SIT/docker-compose.yaml

stages:
  - template: tmp_docker_compose_predeploy_blue.yaml
    parameters:
      environmentName: 'Demo SIT'
      docker_compose_path: 'C:\Users\samnc\2025_ironman\ironman2025\case_ELK_JPG_Route_Blue_Green'
      docker_compose_git_path: 'SIT'
  - stage: ManualApproval
    displayName: 'Manual Approval'
    dependsOn: predeploy
    jobs:
      - job: 'WaitForApproval'
        displayName: 'Wait for Manual Approval'
        pool: server
        steps:
          - task: ManualValidation@0
            inputs:
              notifyUsers: 'samnchiu@hotmail.com'
              instructions: '請進行預先版本確認，如沒問題請按resume，如驗證失敗請按reject'
  - template: tmp_docker_compose_swap_blue_green.yaml
    parameters:
      environmentName: 'Demo SIT'
      docker_compose_path: 'C:/Users/samnc/2025_ironman/ironman2025/case_ELK_JPG_Route_Blue_Green'

SIT_docker_compose_deploy.yaml 是根據SIT環境所準備的，預計進行三個階段：

• trigger 設定
  • 不曉得讀者是否還記得，當時Iac_Demo下是根據資料夾區分不同環境的，因此監控的docker-compose.yaml是位於SIT資料夾下(可參考Day 20 的資料夾結構)。
  • 只要 main 分支有變更(PR後的merge 行為)，且變更路徑包含 docker-compose.yaml，就會觸發這個 pipeline。
• stages 階段
  • predeploy（前置部署）
    • 使用 tmp_docker_compose_predeploy_blue.yaml 範本，傳入環境名稱與 compose 路徑等參數，進行藍綠部署的前置作業，將新版本 blue 版本啟動提供驗證。
  • ManualApproval（人工審核）
    • 這個階段會暫停 pipeline，等待指定人員（這裡是 samnchiu@hotmail.com）進行人工驗證。驗證沒問題就 resume，否則可以 reject 讓目標環境不會被更新。
  • swap（藍綠切換）
    • 通過人工審核後，會執行 tmp_docker_compose_swap_blue_green.yaml 範本，進行藍綠流量切換，讓新版本正式上線。

#tmp_docker_compose_predeploy_blue.yaml

    ...傳入參數以及Deploy等內容上略...
    steps:
    - checkout: self
        clean: true
    - task: PowerShell@2
        displayName: '複製更新版本的docker compose啟動API Blue'
        inputs:
        targetType: 'inline'
        script: |
            cd ${{ parameters.docker_compose_path }}
            cp $(System.DefaultWorkingDirectory)/${{ parameters.docker_compose_git_path }}/docker-compose.yaml ./docker-compose.yaml
            cat ./docker-compose.yaml
    - task: PowerShell@2
        displayName: '啟動API Blue'
        inputs:
        targetType: 'inline'
        script: |
            cd ${{ parameters.docker_compose_path }}
            docker compose up -d case_elk_jpg_authzn_weather_blue
                  

在預佈署的階段可以看到，筆者僅用非常簡單的方式進行操作，列點如下：

1. 複製新的版本docker-compose.yaml 檔案到環境中該檔案運行的位置。
2. 將docker-compose.yaml 中的新版本case_elk_jpg_authzn_weather_blue啟動，提供開發人員驗證。

這時候就完成了第一步驟，將預備要更新的版本，透過預先被kong定義好的case_elk_jpg_authzn_weather_blue服務啟動，這時資訊人員就可以帶入預先定義好的驗證header x-version: blue 來確認新版本的運行狀態。這個動作也因為kong的分流，因此不會影響線上的consumer讀取原有版本服務。

#tmp_docker_compose_swap_blue_green.yaml
    ...傳入參數以及Deploy等內容上略...
    steps:
    - checkout: self
        clean: true
    - task: PowerShell@2
        displayName: '關閉 predeploy blue version 與更新線上 green version'
        inputs:
        targetType: 'inline'
        script: |
            cd ${{ parameters.docker_compose_path }}
            docker compose down case_elk_jpg_authzn_weather_blue
            docker compose up -d case_elk_jpg_authzn_weather
                  

當資訊人員人工檢查完成後，接下來則可以運行pipeline執行swap_blue_and_green_api stage，可以看到也非常容易，筆者將已經驗證過的 case_elk_jpg_authzn_weather_blue 服務關閉，以節省資源。另外將case_elk_jpg_authzn_weather用 docker compose up -d的方式啟動。這時，docker compose 會偵測到版本號碼已經被變更，而重新啟動這一個服務。

接下來，既然pipeline的yaml檔案都寫好了，是時候在 Azure Devops中跑看看了。

實戰

Pipeline 設定的部分筆者就省略，直接進行操作。在pipeline啟動之前，服務的狀態大概如圖30-1：

圖 30-1 佈署前狀態

從圖30-1中可以看到，目前原有版本API還在提供服務，因此藍色通道(header x-version: blue)後方的服務尚未被啟動。接下來，當變更管理的pull request完成後，main 分支的docker-compose.yaml被變更，會觸發pipeline啟動變更管理後的自動化佈署。

圖30-2 藍色版本佈署完成，待驗證

圖30-3 藍色通道暢通中

可以看到圖30-2與圖30-3，已經完成了預佈署的動作，這時候藍色通道已經被打開了，因此技術人員可以對藍色通道進行預驗證。而原有的綠色通道還持續提供consumer服務。

圖30-4 具備隕石雨的版本已經被佈署

圖30-4可以看到，工程師對藍色通道所開出來的路線，進行了版本的驗證，確定已經看到流星雨出現在驗證過程中。

圖30-5 pipeline中同意佈署進入下一階段

圖30-6 完成swap 階段

當驗證都沒有問題，這時則是進入人工確認(圖30-5)，同意後續的swap_blue_and_green_api階段繼續進行(圖30-6)。

圖30-7 完成佈署後的綠色通道

最後，新版本經歷過驗證之後，如同圖30-7畫面上一樣，consumer也可以感受到被隕石雨沐浴的天氣了。而原有的藍色通道後方的服務也被關閉以節省資源(特別是K8S 有單一node 的上限數)，等待下次的變更管理再次到來。

而這條通道會被保留下來，這表示kong的管理員也不會需要每次開發人員的變更管理，需要頻繁的協助變更設定。這種做法，讓驗證可以被提早在所有相關人員都在白天上班時進行，且不影響線上的consumer，這樣就能讓變更管理更為滑順，而不需賭在變更的那一瞬間的細心與好運了。

圖30-8 變更成功享用下午茶的工程師

小結

Aries：這點子感覺很不錯耶，對於kong的管理者來說，負擔不會太重，未來在協助開發人員開立service與route的時候，只要同時多開一條藍色通道就可以了。

Lala：而且當版本預先佈署在上班時間就進行，既不會影響到線上使用者，又可以讓工程師先行驗證，確保晚上的變更管理已經完備，這真是一個很棒的作法。

Sam：沒錯，雖說既有的變更管理流程，需要與開發團隊與維運團隊先討論過，取得共識後需要先做小規模試行才能夠慢慢的推廣。但相信這種作法好處多多，大家應該能接受的。

Aries：那我建議先找一直以來合作關係良好的團隊來互動，這樣試行成功的可能性較高。

Lala：那我來研究一下開發團隊的布版流程，看如何改寫成可以共用的pipeline讓大家可以使用。

Sam：那我繼續泡咖啡去，大家加油(溜)~

寫在最後

這是筆者第二次參加鐵人賽，很高興也努力地度過了30天(好啦其實花超過30天)。因為個性使然，心中總是有一些曾經經歷過覺得非常有價值的想法與知識，想要希望一起升級的夥伴分享。

回頭再次閱讀系列文，可以發現筆者從kong的各式各樣plugin與可觀測性的三本柱，一路聊到了IaC、Azure DevOps、pipeline、變更管理甚至實做了藍綠佈署。

雖說過去的經驗是使用kong enterprise edition在企業中進行api的各項管理，但筆者挑選分享題目時，還是希望從開源社群或是可以免費練功的角度切入。因此這次主題特別選擇了kong的開源版本，加上使用可以免費申請的Azure DevOps Service的服務來進行系列文的撰寫。

這個系列文除了在技術上進行著墨，同時也談到了協作與變更管理的流程在引入團隊時，針對痛點進行設計有多麼的重要。筆者在過去引入Azure DevOps Service的變更管理流程到組織中，引用了不少的變革管理的理論與實踐。不論是推力理論或是ADKAR 變革管理模型，都讓筆者能更深入的思考，到底要如何才能夠讓團隊或是組織，可以認知變革的必要，進而接受變革，甚至擁抱變革。

系列文中出現的Aries與Lala，都是筆者在過去的變革管理歷程中，共同戰鬥的夥伴，這次也被筆者慫恿一起組隊來參加17th ItHome鐵人賽。感謝你們兩位與山姆大叔一同參與這個盛宴，也祝福在未來DevOps的道路上，可以更加卓越與成長，畢竟我們可是一起在今年的鐵人賽中一同升級的夥伴。

我們不獨自升級，我們是邦邦不邦邦。

圖30-9 這次的旅程技能樹