上面這張圖是流程規劃說明裡面畫的Develop CI Pipeline流程，我們已經在前兩篇完成了Build(Code)、Build Image，剩下最後一步就是Deploy Dev環境，這一篇就來完成這最後一步吧！

trigger:
- none

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
  - repository: sources
    type: git
    name: ironman2022/NetApp
    ref: Develop
    trigger:
      branches:
        include:
          - Develop

variables:
  pipelineArtifact: output
  buildResultZipName: buildResult.zip
  slnOrCsprojName: IronmanWeb.sln
  imgRepository: 'asia-east1-docker.pkg.dev/feisty-mechanic-363012/ironman2022/ironmanweb'
  buildDockerfile: 'Dockerfile'
  imgRegistryService: 'GCPArtifactRegistry'
  cloudRunServiceName: ironmanweb
  cloudRunPort: 8080
  cloudRunRegion: asia-east1
  cloudRunProjectId: feisty-mechanic-363012
  gcpAuthJsonFile: ironman2022-gcp-key.json

jobs:
  - job: BuildCode
    steps:
      - checkout: sources
        clean: true
      - script: |
          export UID=$(id -u)
          export GID=$(id -g)
          docker run --user $UID:$GID --rm \
          -v $(Build.SourcesDirectory):/tmp/source \
          -v $(Build.BinariesDirectory):/tmp/publish \
          -e DOTNET_CLI_HOME=/tmp/.dotnet \
          mcr.microsoft.com/dotnet/sdk:6.0-alpine \
          dotnet publish /tmp/source/$(slnOrCsprojName) \
          -c release \
          -o /tmp/publish
        displayName: Dotnet Build
      - task: ArchiveFiles@2
        displayName: 壓縮成zip
        inputs:
          rootFolderOrFile: $(Build.BinariesDirectory)
          includeRootFolder: false
          archiveType: 'zip'
          archiveFile: '$(Build.ArtifactStagingDirectory)/zipFiles/$(buildResultZipName)'
          replaceExistingArchive: true
      - task: PublishBuildArtifacts@1
        displayName: 上傳到Pipeline Artifact
        inputs:
          PathtoPublish: '$(Build.ArtifactStagingDirectory)/zipFiles/$(buildResultZipName)'
          ArtifactName: '$(pipelineArtifact)'
          publishLocation: 'Container'
  - job: BuildImage
    dependsOn: BuildCode
    steps:
      - task: DownloadBuildArtifacts@0
        displayName: 下載Pipeline Artifact
        inputs:
          buildType: 'current'
          cleanDestinationFolder: true
          downloadType: 'single'
          artifactName: '$(pipelineArtifact)'
          downloadPath: '$(System.ArtifactsDirectory)/'
      - task: ExtractFiles@1
        displayName: Unzip zip
        inputs:
          archiveFilePatterns: '$(System.ArtifactsDirectory)/$(pipelineArtifact)/$(buildResultZipName)'
          destinationFolder: '$(System.ArtifactsDirectory)/BuildImage'
          cleanDestinationFolder: true
          overwriteExistingFiles: true
      - task: Docker@2
        displayName: Build image
        inputs:
          repository: '$(imgRepository)'
          command: 'build'
          Dockerfile: $(buildDockerfile)
          buildContext: '$(System.ArtifactsDirectory)/BuildImage'
          arguments: '--no-cache'
          tags: |
            latest
      - task: Docker@2
        displayName: "Login to Container Registry"
        inputs:
          command: login
          containerRegistry: $(imgRegistryService)
      - task: Bash@3
        displayName: Push docker image
        inputs:
          targetType: 'inline'
          script: |
            docker push -a $(imgRepository)
  - job: DeployCloudRun
    dependsOn: BuildImage
    steps:
      - task: Bash@3
        displayName: Deploy docker image to cloudrun
        inputs:
          targetType: 'inline'
          script: |
            docker run --rm \
            -v $(Build.SourcesDirectory)/$(gcpAuthJsonFile):/gcp/cloudKey.json \
            asia.gcr.io/google.com/cloudsdktool/google-cloud-cli:latest \
            bash -c "gcloud auth login --cred-file=/gcp/cloudKey.json && gcloud run deploy $(cloudRunServiceName) --set-env-vars=Ironman=$(Build.BuildId) --image $(imgRepository) --region $(cloudRunRegion) --project $(cloudRunProjectId) --allow-unauthenticated"

哇！一來就是一長串的YAML內容…

不不不，你如果是用VSCode打開，幾乎可以把前面兩個Job折疊起來，這邊增加的DeployCloudRun Job也只有一個Bash的task，不多的。

就讓我娓娓道來這篇主要增加的內容吧！

  cloudRunServiceName: ironmanweb
  cloudRunPort: 8080
  cloudRunRegion: asia-east1
  cloudRunProjectId: feisty-mechanic-363012
  gcpAuthJsonFile: ironman2022-gcp-key.json

cloudRunServiceName就是圖中Cloud Run的名稱。

cloudRunPort設定為8080是在appsettings.json中設定了Kestrel的Http是使用8080 Port，也就是container內會監聽什麼Port，對應docker指令就是-p 80:8080。

cloudRunRegion則是CloudRun佈署的區域(機房)。

cloudRunProjectId可以直接從Google Cloud管理介面的URL得知，也就是在上圖畫面的時候，看一下瀏覽器上的網址列，「&project=」後面的就是了，或是選擇Project的下拉選單：

最後的gcpAuthJsonFile則是前面幾篇用來授權的Json檔案。不過這邊要補充一下，那時候在新增服務帳戶的時候還少加了一個「服務帳戶使用者」角色，所以漏加這個角色繼續做下去的話，就會碰到下面的錯誤訊息：

PERMISSION_DENIED: Permission ‘iam.serviceaccounts.actAs’ denied on service account

為了讓後面使用gcloud cli可以順利執行，所以要先在IAM裡面將前面新增的服務帳戶加上「服務帳戶使用者」角色：

增加角色之後不需要重新下載用於授權的Json檔案，因為有什麼角色權限不會寫在檔案裡。

Job越加越多，這三個Job之間其實是有相依性的，也就是說要先BuildCode之後才能夠BuildImage，接下來才能DeployCloudRun，所以在第二個和第三個Job底下分別要加上dependsOn的屬性：

- job: BuildImage
    dependsOn: BuildCode

- job: DeployCloudRun
    dependsOn: BuildImage

這個部份滿重要的，尤其是如果有額外購買CloudAgent的執行數量時，因為Job可以在不同的Agent執行，所以它可以在同一個Pipeline同時跑多個Job(沒有設定相依的dependsOn時)，就算沒有額外購買CloudAgent的執行數量，沒設定dependsOn也無法保證它們的執行順序。BuildImage的Job相較前一篇有增加的也只有dependsOn這個屬性。

最後就是DeployCloudRun這個Job，裡面的內容也只有一個Bash的task，所以下面我直接貼bash script的部份：

            docker run --rm \
            -v $(Build.SourcesDirectory)/$(gcpAuthJsonFile):/gcp/cloudKey.json \
            asia.gcr.io/google.com/cloudsdktool/google-cloud-cli:latest \
            bash -c "gcloud auth login --cred-file=/gcp/cloudKey.json && gcloud run deploy $(cloudRunServiceName) --set-env-vars=Ironman=$(Build.BuildId) --image $(imgRepository) --region $(cloudRunRegion) --project $(cloudRunProjectId) --allow-unauthenticated"

在這裡是使用google的gcloud CLI工具來執行CloudRun的佈署，不過gcloud CLI工具還是需要安裝的，要嘛是需要先裝在Agent的電腦內，而且還要去爬官方的安裝文件知道怎麼安裝，不然就是安裝在Docker Image裡面。

我們使用的是ClougAgent，所以Agent的環境不是我們可以控制的，每次執行也是新的vm執行起來，所以選擇後者使用google建立的gcloud CLI的Docker Image會是最理想的選擇，除了從Docker Hub可以找到之外，官方文件也有提供不同Container Registry的選擇說明。

使用Container來執行gcloud CLI，我們可以省去安裝的麻煩事，只要會使用就可以了，這讓我們可以更專注在其它的設計部份。

script中的重點只有第二行和最後一行，分別是把授權用的Json檔案關聯到Container裡面，以便讓裡面的gcloud CLI工具可以讀取到內容進行login動作，以及最後一行包含lgoin的指令。

最後一行的指令有個重點，就是我們必須先使用gloud auth login的指令讓CLI工具登入，接著才能執行CloudRun的Deploy指令，也就是說要執行的指令有兩個，所以使用了「&&」這個管道符號讓它接續執行，但是直接這樣接在Image Repository後面是行不通的，「&&」符號的前面會跟最前面的docker run指令合起來作為第一個指令，後面的則是host環境接續docker run指令執行的第二個指令。

所以在這個地方必須是讓docker run執行起來的contianer是執行bash程式，後面接著要執行的指令字串(用引號包起來)，也因為是一整個字串，所以沒辦法使用「\\」換行，就會是一行很長的指令，下面為了方便閱讀，把它們拆開來說明。

gcloud auth login --cred-file=/gcp/cloudKey.json

「&&」符號前的這一行是將gcloud CLI工具登入，使用–cred-file參數帶入Json檔案，後面的路徑是Container內的路徑，也就是前面-v設定的部份。

gcloud run deploy $(cloudRunServiceName) --set-env-vars=Ironman=$(Build.BuildId) --image $(imgRepository) --region $(cloudRunRegion) --project $(cloudRunProjectId) --allow-unauthenticated

「&&」符號後面的指令我依參數拆行來看應該就很清楚，因為大部份都是上面設定的變數，已經有說明過了。

–set-env-vars的參數是設定CloudRun放入的環境變數(還記得前面的Ironman環境變數嗎？)，–allow-unauthenticated則是允許訪客瀏覽，不然CloudRun可能不會正常回應頁面。

gcloud run deploy $(cloudRunServiceName)
–set-env-vars=Ironman=$(Build.BuildId)
–image $(imgRepository)
–region $(cloudRunRegion)
–project $(cloudRunProjectId)
–allow-unauthenticated

關於CloudRun在gcloud CLI可以設定的更多參數部份，請參考官方文件的頁面，之後的文章還會把部份參數用上。

最後，在CI Pipeline成功執行完之後，就可以在對應的Task log中看到gcloud CLI工具吐出來的CloudRun網址，這樣就不用進入到GCP的管理介面去查看。

最後補充一個小細節，就是在這三個Job之中，只有BuildCode這個Job中有明確的加上checkout: sources，並且身份驗證的Json檔案是放在Pipelines這個Git Repository裡面，但是在後面的BuildImage和DeployCloudRun並沒有明確加上checkout動作卻會(可以)取得Pipelines這個Git Repository裡面的檔案，也沒有在resources.repositories底下設定Pipelines，主要是因為這裡的Pipeline YAML檔案就是放在Pipelines這個Git Repository裡面，所以隱含了checkout: self這個動作，替我們省下了一些設定。(下圖紅框與藍框的差異)

這篇文章 【2022鐵人賽】基本版-建立CI Pipeline(3) 最早出現於 泰克哪裡去。

那什麼是CloudRun呢？

它是Google雲端服務的一個項目，是一個由Google全代管的無伺服器平台服務，讓我們可以利用建置好的Docker Image(只是其中一種方式)就可以佈署我們的網站，而且它只在有流量進入的時候被啟動/執行，還可以根據流量大小在我們設定的允許範圍內動態增減執行個體的數量，以滿足網站不同時段的流量需求。

除此之外，每一次的佈署都會有版本保留下來，除了方便在發生問題的時候倒回版本之外，也可以設定不同流量百分比導向不同的版本，在佈署策略上也彈性許多。

因為後面的文章實際上是使用gcloud cli的方式將Docker Image佈署到CloudRun，所以下面只是快速的透過UI帶過手動建立CloudRun服務的過程。在這之前，我已經先透過VS建立了一個Web專案範本並且建置了一個Docker Image，這部份就不在文章中特別帶到了。

我在首頁中寫了一行程式碼讀取一個名為Ironman的環境變數，為的就是示範Build同一份程式碼/Docker Image，用在多個不同的環境。

前置作業已經先準備了一個Docker Image，所以就直接從建立CloudRun開始吧！

進入GCP的管理介面之後，在選單中找到CloudRun選項(任意門在這)，進入之後選擇「建立服務」。

接著就可以選擇已經Push到前一篇文章提到的Google Artifact Registry裡面的Docker Image，按下「選取」之後，「選取容器映像檔」的畫面(第二張圖)就會出現在右邊。

接下來就是CloudRun的詳細設定，不過這邊只是帶過，所以除了額外加了一個環境變數之外，其它幾乎沒什麼異動，就隨意看一下吧！知道有哪些選項可以設定，之後用gcloud cli的時候有印象就行。

設定完想要設定的項目並且按下「建立」按鈕之後，稍微等它抓一下Image，很快就會Ready了。

每一個CloudRun服務建立之後都會提供一個固定的網址，之後版本持續更新也不會異動，也可以將自訂的網域套用上去，不過這不在這篇文章的範圍，直接點擊它提供的網址看看佈署後的頁面吧！

上圖有正確的將環境變數設定的值列出來，雖然畫面有點醜(因為我沒有把css那些都放進去)，不過正確顯示才是最重要的，對吧！

接著使用同一個Image Repository，只修改設定的環境變數值，看看是不是能正確的顯示不同的內容吧！

從上圖可以看到已經改為第二個版本，並且環境變數的內容文字也稍有不同，重新整理剛剛打開的網頁之後，文字內容也有如期望的更改了。

是不是很方便呢？之後的文章中將會透過gcloud cli的方式來佈署，這樣才能夠整合在CI/CD Pipeline之中，拭目以待吧！

這篇文章 【2022鐵人賽】Google CloudRun介紹 最早出現於 泰克哪裡去。

Docker Image存放位置的選擇其實也很多，像是放在Docker Hub、Azure Container Registry(ACR)、Google Container Registry(GCR)/Google Artifact Registry(GAR)、Amazon Elastic Container Registry(ECR)等等…，這些雲端服務都是可以選擇的選項。

不過，因為我們後面使用的是Google的Cloud Run，所以為了有最佳的網路傳輸與最節省成本的考量(主要還是網路輸出的費用部份)，所以就直接選擇放在Google的雲端服務上面。

然而，Google現在可以存放Docker Image的服務其實有兩個，就像上面寫的，有分為Google Container Registry和Google Artifact Registry，這兩者其實對於存放Docker Image沒有什麼太大的差別，主要應該只是URI的部份不一樣。如果真要說的話，GCR就如同它的名稱一樣，就是拿來放Image的，而GAR則是綜合存放庫的服務，除了可以放Image之外，也可以是程式的套件庫，就像.Net的Nuget套件庫一樣。

GAR是由GCR演進而來(官網就是這麼寫的)，所以GAR是新的服務，會不會在之後取代GCR很難說…，所以在裡面既然要建立新的存放空間，那就直接從新的服務建立吧！

建立Artifact Registry存放區

進到Google Cloud的管理頁面之後，從左邊的選單找到「Artifact Registry」吧(或是你想要任意門)！如果找不到的話，應該是被隱藏在最下面的「其他產品」裡面。

進入Artifact Registry之後，找到「建立存放區」，接著填寫簡單的資料就可以建立一個新的存放區了，記得格式要選「Docker」，地區的部份輸入「asia」就會篩選出台灣的選項了。

建立完之後從列表中就可以看到剛才建立的項目，點進去之後就會看到Image Repository的URI了，旁邊很貼心的放了一個直接複製的按鈕。

到這邊雖然已經將存放Image的Artifact Registry存放區建立好，但是其實還有一個很重要的事情，那就是身份驗證與授權的部份。如果沒有登入的話是沒辦法將Image推送上來的，所以我們還需要建立對應的服務帳戶。

建立服務帳戶

同樣在Google Cloud左邊的Menu找到「IAM與管理」(任意門在此)，進入之後點選左邊的「服務帳戶」，然後在右邊的上方點擊「建立服務帳戶」。

需要填寫的步驟不多，不過在第二步的部份雖然它是寫「選用」，不過我們還是直接把後續會需要使用到的角色權限設定給它吧！分別是「Artifact Registry 寫入者」、「Cloud Run 開發人員」。

產生授權金鑰

建立完成之後，從列表中點擊剛剛建立的服務帳戶，進入之後點擊在上方的「金鑰」分頁。

進入金鑰頁面之後，點擊「新增金鑰」後選擇「建立新的金鑰」，接著確認金鑰類型是JSON，按下「建立」按鈕之後，就會讓你下載json格式的金鑰檔案，務必要保存好。

Docker Login

使用上面產生的金鑰就可以透過docker login指令登入Registry囉！登入的使用者名稱固定為「_json_key」，密碼的部份就是整個json檔案的內容，下面提供一個相對安全的指令登入方式：

cat {Your_Json_File} | docker login -u _json_key --password-stdin https://asia-east1-docker.pkg.dev

把上面的{Your_Json_File}的部份取代成下載的json檔名，如果剛剛建立存放區不是選台灣的機房的話，最後面的網址再根據後台顯示的內容修改即可。

登入之後就可以試一下可不可以push docker image，可以從docker hub上面pull一個下來，然後透過docker tag重新更改image repository名稱和tag，就可以push看看囉！

這篇文章 【2022鐵人賽】Docker Image存放位置選擇：Google Artifact Registry 最早出現於 泰克哪裡去。

這次的需求是為了知道簡單網路行為的耗用時間，也就是延遲時間，所以透過Ping這個簡單的網路測試功能來獲得Client端到Server端的網路耗用時間(ms)，用在計算某些服務耗用時間的扣除基準。

不過，雲端服務的防火牆預設是不開放任何網路封包從外面進入，必須根據需求在網路規則介面上建立，像是常用到的Web 80 Port，或是Windows遠端連線RDP的3389，所以這次需要在網路規則中加上Ping的允許規則。

Ping的網路規則和一般開啟Port Number不太一樣，Ping是透過ICMP協定傳送的封包，所以不是像一般設定TCP/UDP的規則，Port Number的部份不需要指定，直接填入*即可。

如果是Linux的VM，可以輸入cat /proc/sys/net/ipv4/icmp_echo_ignore_all，看看顯示的值是0(啟用Ping回應)還是1(停用Ping回應)，如果是0的話，應該就可以正常Ping得到該台VM才是。

【參考來源】

• 搞懂ICMP協定及工具 抵擋「死亡之Ping」攻擊
• 網際網路控制訊息協定第六版
• HOW TO ENABLE PING (ICMP ECHO) ON AN AZURE VM
• enable ping in linux

這篇文章 Azure VM 開啟 Ping 網路規則 最早出現於 泰克哪裡去。