因為其實在Azure DevOps Pipeline中已經有提供許多不錯的Task設計，尤其.Net的程式在Azure DevOps Pipeline中有各式各樣對應的Task可以使用，像去年的文章「CI/CD從這裡：設定第一個Pipeline(範本與編輯介面介紹)」裡面就是使用內建的VSBuild Task來編譯.Net的程式碼，但是今年卻在「基本版-建立CI Pipeline(1)」文章內一開始就使用.Net Sdk的Container來編譯.Net的程式碼…

除了今年的文章屬於進階應用之外，還有其它幾個不同的因素考量：

• Task要透過GUI才能快速方便知道有什麼參數可以選擇與設定
• 不同功能可能要選用不同task
• 可以達到相同功能的Task可能不只一個
• 想要測試看看執行結果如何無法在Pipeline以外的環境執行
• 用Container或直接用Sdk CLI可以在本機執行看看結果
• 新功能或指令在Task可能沒有設計或支援
• 如果是自管的Agent只要裝了Docker就可以

因為透過CLI就是組Scripts來達成目的，所以彈性相對高很多。例如.Net Core Sdk CLI除了可以Build Source Code之外，要Pack Nuget Package也是同樣透過Sdk CLI就可以達成，只是指令的組成不太一樣。但是如果是用Task的話，就會需要分成Nuget Task與.Net Core Task，或是pack也用.Net Core Task而不是用Nuget Task。

另外還有像是我們使用Azure DevOps Artifacts功能來存放私有的Nuget Packages，不過要Push上去是需要身份驗證授權的，在Task的選擇部份就有Nuget authenticate Task(搭配設定Service Connection)，或是有個nuget.config檔案，裡面寫入PAT然後放在特定的位置來自動解決身份驗證的問題。

所以原本的dotnet-build-in-linux-container.yaml就可以重新做一份step template：

# steps/dotnet-sdk-in-linux-container.yaml

parameters:
  - name: dotnetSdkImgRepository
    type: string
    default: mcr.microsoft.com/dotnet/sdk:6.0-alpine
  - name: srcPath
    type: string
  - name: outputPath
    type: string
    default: $(Build.ArtifactStagingDirectory)/outputFiles/
  - name: slnOrCsprojName
    type: string
    default: Pipeline.sln
  - name: dotnetCommand
    type: string
  - name: dotnetCommandArgs
    type: string

steps:
  - script: |    
      echo "Dotnet sdk in linux container template"
      echo "${{ convertToJson(parameters) }}"
    displayName: Print template parameters
  - task: Bash@3
    displayName: Run dotnet sdk command in container
    inputs:
      targetType: 'inline'
      script: |
        if [ -d ${{ parameters.outputPath }} ]; then echo "${{ parameters.outputPath }} exist"; else mkdir -p ${{ parameters.outputPath }}; fi
        export UID=$(id -u)
        export GID=$(id -g)
        docker run --user $UID:$GID --rm \
        -v ${{ parameters.srcPath }}:/tmp/source \
        -v ${{ parameters.outputPath }}:/tmp/publish \
        -e DOTNET_CLI_HOME=/tmp/.dotnet \
        ${{ parameters.dotnetSdkImgRepository }} \
        dotnet ${{ parameters.dotnetCommand }} /tmp/source/${{ parameters.slnOrCsprojName }} \
        -o /tmp/publish ${{ parameters.dotnetCommandArgs }} \
  - task: ArchiveFiles@2
    displayName: 壓縮成zip
    inputs:
      rootFolderOrFile: $(Build.BinariesDirectory)
      includeRootFolder: false
      archiveType: 'zip'
      archiveFile: '$(Build.ArtifactStagingDirectory)/zipFiles/buildResult.zip'
      replaceExistingArchive: true

這樣就可以用同樣的一個範本搞定Build Source Code、Pack Nuget Package之類的事情，對應在jobs/buildCode.yaml就是把引用的template檔案改成新的，然後加上dotnetCommand、dotnetCommandArgs參數的設定就行了。

      - template: ../steps/dotnet-sdk-in-linux-container.yaml
        parameters:
          srcPath: ${{ parameters.sourcePath }}
          slnOrCsprojName: ${{ parameters.slnOrCsprojName }}
          dotnetCommand: publish
          dotnetCommandArgs: '-c ${{ parameters.buildConfiguration }}'

這篇文章 【2022鐵人賽】使用Task與CLI的抉擇 最早出現於 泰克哪裡去。

上面這張圖是流程規劃說明裡面畫的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) 最早出現於 泰克哪裡去。

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'

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
    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)

今天的YAML內容雖然是沿用前一篇的內容，但是從resources之後就有些改變。首先可以看到在resources之後加上了variables的區段，裡面設定了幾個不同的變數。

前三個是從昨天的BuildCode job中將一些內容抽離出來改為變數，除了方便在一開始設定並且若有用在不只一個地方而有修改的話只要改變數內容就不用擔心漏改。

後三個就是這一篇BuildImage會使用到的變數，就是Image Repository、Dockerfile以及在Azure DevOps設定的Service Connection名稱。

variables:
  pipelineArtifact: output
  buildResultZipName: buildResult.zip
  slnOrCsprojName: IronmanWeb.sln
  imgRepository: 'asia-east1-docker.pkg.dev/feisty-mechanic-363012/ironman2022/ironmanweb'
  buildDockerfile: 'Dockerfile'
  imgRegistryService: 'GCPArtifactRegistry'

為了要在Build完Docker Image之後推到GCP的Artifact Registry，所以需要建立一個Service Connection來存放身份驗證的設定，主要是這邊使用到的是內建的Docker task。還記得前面文章的json檔案嗎？又需要它的內容囉！檔案要好好保管好啊，後面還有它再度出場的時候。

建立Service Connection從Azure DevOps的專案設定(Project Settings)進入，按下「Create service connection」按鈕之後選擇「Docker Registry」的選項，接著要輸入的內容就和前面文章的最後面Docker Login差不多，而Docker Password的內容就把json檔案的內容全部複製之後貼進去就行了(我知道，有點長)，最重要的就是記下Service connection name，回來貼到上面的imgRegistryService變數中。

對了，上面的buildDockerfile變數值是Dockerfile，這個dockerfile的內容如下，如果你儲存的檔名並不是使用預設的Dockerfile這個名稱，記得變數值要改喔！

FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine

WORKDIR /app
COPY . .

ENTRYPOINT ["dotnet", "IronmanWeb.dll"]

上面這個Dockerfile沒什麼特別，除了第一行使用的Image版本選用alpine這個比較小的Image之外，再來就是要執行dll名稱直接寫在裡面。

嗯？可以不這樣寫在裡面嗎？後面的文章就會知道了…

接下來第一個Job是前一篇的BuildCode Job，裡面的內容可以自己對照一下，把哪些小地方改成變數。

這篇的內容主要在第二個job，也就是BuildImage的部份。因為前一個BuildCode job裡面把編譯的結果都壓縮成zip，而且這邊是分開在兩個不同的Job執行後續的動作，所以在第二個Job需要先有一個下載Pipeline Artifact的動作，主要是不同Job其實是可以在不同的Agent執行，去年的這一篇文章有介紹過。

      - task: DownloadBuildArtifacts@0
        displayName: 下載Pipeline Artifact
        inputs:
          buildType: 'current'
          cleanDestinationFolder: true
          downloadType: 'single'
          artifactName: '$(pipelineArtifact)'
          downloadPath: '$(System.ArtifactsDirectory)/'

下載了前面Job上傳到Pipeline Artifact中的zip檔案之後，接下來當然是要把它解壓縮之後才能使用，解壓縮到$(System.ArtifactsDirectory)/BuildImage這個位置，這個位置會在後面用於buildContext的位置。

      - task: ExtractFiles@1
        displayName: Unzip zip
        inputs:
          archiveFilePatterns: '$(System.ArtifactsDirectory)/$(pipelineArtifact)/$(buildResultZipName)'
          destinationFolder: '$(System.ArtifactsDirectory)/BuildImage'
          cleanDestinationFolder: true
          overwriteExistingFiles: true

接下來最後面的三個Task都是和Docker相關的動作，分別是Build、Login、Push。

      - 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)

第一個Task是使用Docker task並且command設定為build，tags的部份是陣列類型，如果你建立的Image不只要使用latest為tag，那就多加一行，每一行一個tag。

第二個Task就是使用上面設定的Service Connection名稱執行登入的動作，如果不是透過Service Connection的話，就必須自己透過指令登入，那就會額外需要json檔案，比較麻煩一點，所以這邊先簡單做吧！

第三個Task使用的是Bash執行docker push的指令，其實和第一個Task一樣用Docker task也是可以，在command的部份改成push就行(利用UI的Task小助手方便設定)，只是用Bash執行docker push指令也不難，剛好可以對照做個比較。

到這邊為止，已經將程式編譯和建置Docker Image的動作都完成了，可以試試在本機端把Image拉下來執行看看有沒有問題喔！

下一篇將會使用到gcloud cli工具佈署Dev環境的CloudRun，下回見。

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

首先是Build Code的部份，雖然去年的文章已經有建立YAML的Pipeline來編譯.Net程式的範例，但是今年還是要再做一次。

只是如果我只是照著去年的內容搬過來改一小部份就交差，那肯定會被噓爆的吧？所以這次我們改用.net sdk的docker image執行container來編譯.net的程式，這樣就是新鮮貨了，對吧！

因為用container執行sdk是透過script的方式執行，所以就沒辦法使用去年文章的方式把小助手叫出來設定幾個選項搞定，能透過小幫手的部份也只是加一個Bash的Task，差異不大。不囉嗦，還是直接先上code吧！

trigger:
- none

pool:
  vmImage: ubuntu-latest

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

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/IronmanWeb.sln \
          -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/buildResult.zip'
          replaceExistingArchive: true
      - task: PublishBuildArtifacts@1
        displayName: 上傳到Pipeline Artifact
        inputs:
          PathtoPublish: '$(Build.ArtifactStagingDirectory)/zipFiles/buildResult.zip'
          ArtifactName: 'output'
          publishLocation: 'Container'

上面的YAML內容前半段是借用前一篇文章的設定，從sources這個repository的ref分支參考的下一行開始才是今天新增的內容。可以發現多增加了trigger的部份，而且是設定在resources底下的repository設定，同時設定了以Develop分支為篩選條件(branches下面的include)。

    trigger:
      branches:
        include:
          - Develop

接著下面有一個名為BuildCode的Job，這個名稱不是放在displayName屬性裡面，它是屬於ID(也就是識別)的一種，只能包含英數字和底線，不能有空格也不能以數字為開頭。簡單來說就是程式的變數命名的概念。

jobs:
  - job: BuildCode

接著在BuildCode Job底下的steps加入了許多不同的task，先checkout程式碼出來，沒有特別設定path的話會放在Build.SourcesDirectory這個系統預先定義的變數中。

接著我們使用script(等同Bash task)寫了一段Linux的script，利用dotnet 6.0的sdk docker image(使用alpine的版本，image size比較小)建立container來編譯.net程式(使用publish命令)。

在script中每一行最後的空白加上「\」符號是命令區塊換行的用法，是為了可讀性，實際執行的時候會是與同一行指令相同效果。

      - 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/IronmanWeb.sln \
          -c release \
          -o /tmp/publish
        displayName: Dotnet Build

前面兩行的export是為了將host的uid和gid帶到container裡面(–user $UID:$GID部份)，避免檔案建立之後的問題。

–rm是告訴docker當container使用完就可以刪掉了。

-v的部份則是掛volume的設定，也就是將host的路徑與container內的路徑關聯起來，script中的例子就是把$(Build.SourcesDirectory)所代表的位置和$(Build.BinariesDirectory)所代表的位置分別和container內的/tmp底下的source、publish目錄關聯起來，這樣就可以在source目錄中找到程式碼，編譯產生的檔案放在container內的publish目錄則是相當於放在host。

-e DOTNET_CLI_HOME=/tmp/.dotnet這部份也是把sdk的Home目錄設在/tmp底下的.dotnet目錄，會發現這裡都是使用/tmp開頭，因為在這個tmp目錄下才不會碰到存取權限的問題。

在mcr.microsoft.com/dotnet/sdk:6.0-alpine這個image repository之後就是單純的dotnet sdk的指令，和docker container就沒什麼關係了，就是指定使用publish指令與其它設定來執行編譯的動作。

接下來後面兩個task就是把編譯完的檔案壓縮成zip檔案之後上傳到Pipeline Run的Artifacts空間中，這部份和去年的這篇文章內容做的事是一樣的。

因此這篇內容的關鍵在於resources的repository設定與利用docker container來編譯程式而不是使用內建的dotnet task。

到這邊就完成了Build Code的設計部份，後續步驟請待下一篇文章分享。

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

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 最早出現於 泰克哪裡去。

1. 選擇基底映像檔
2. 安裝所需要的額外套件與程式
3. 將Azure DevOps Agent的開始程式start.ps/start.sh複製進去

既然已經知道了上面的概念，前一篇也有做過一次，那麼這篇就少浪費一些篇幅，直接把Code端上來看吧！

start.sh的內容如下，記得要改成Unix格式的結束符號(LF)喔！(或是透過dos2unix轉換)

#!/bin/bash
set -e

if [ -z "$AZP_URL" ]; then
  echo 1>&2 "error: missing AZP_URL environment variable"
  exit 1
fi

if [ -z "$AZP_TOKEN_FILE" ]; then
  if [ -z "$AZP_TOKEN" ]; then
    echo 1>&2 "error: missing AZP_TOKEN environment variable"
    exit 1
  fi

  AZP_TOKEN_FILE=/azp/.token
  echo -n $AZP_TOKEN > "$AZP_TOKEN_FILE"
fi

unset AZP_TOKEN

if [ -n "$AZP_WORK" ]; then
  mkdir -p "$AZP_WORK"
fi

export AGENT_ALLOW_RUNASROOT="1"

cleanup() {
  if [ -e config.sh ]; then
    print_header "Cleanup. Removing Azure Pipelines agent..."

    # If the agent has some running jobs, the configuration removal process will fail.
    # So, give it some time to finish the job.
    while true; do
      ./config.sh remove --unattended --auth PAT --token $(cat "$AZP_TOKEN_FILE") && break

      echo "Retrying in 30 seconds..."
      sleep 30
    done
  fi
}

print_header() {
  lightcyan='\033[1;36m'
  nocolor='\033[0m'
  echo -e "${lightcyan}$1${nocolor}"
}

# Let the agent ignore the token env variables
export VSO_AGENT_IGNORE=AZP_TOKEN,AZP_TOKEN_FILE

source ./env.sh

print_header "1. Configuring Azure Pipelines agent..."

./config.sh --unattended \
  --agent "${AZP_AGENT_NAME:-$(hostname)}" \
  --url "$AZP_URL" \
  --auth PAT \
  --token $(cat "$AZP_TOKEN_FILE") \
  --pool "${AZP_POOL:-Default}" \
  --work "${AZP_WORK:-_work}" \
  --replace \
  --acceptTeeEula & wait $!

print_header "2. Running Azure Pipelines agent..."

trap 'cleanup; exit 0' EXIT
trap 'cleanup; exit 130' INT
trap 'cleanup; exit 143' TERM

# To be aware of TERM and INT signals call run.sh
# Running it with the --once flag at the end will shut down the agent after the build is executed
./run.sh "$@"

官方的Dockerfile內容如下：

FROM ubuntu:18.04

# To make it easier for build and release pipelines to run apt-get,
# configure apt to not require confirmation (assume the -y argument by default)
ENV DEBIAN_FRONTEND=noninteractive
RUN echo "APT::Get::Assume-Yes \"true\";" > /etc/apt/apt.conf.d/90assumeyes

RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates \
    curl \
    jq \
    git \
    iputils-ping \
    libcurl4 \
    libicu60 \
    libunwind8 \
    netcat \
    libssl1.0 \
  && rm -rf /var/lib/apt/lists/*

RUN curl -LsS https://aka.ms/InstallAzureCLIDeb | bash \
  && rm -rf /var/lib/apt/lists/*

ARG TARGETARCH=amd64
ARG AGENT_VERSION=2.185.1

WORKDIR /azp
RUN if [ "$TARGETARCH" = "amd64" ]; then \
      AZP_AGENTPACKAGE_URL=https://vstsagentpackage.azureedge.net/agent/${AGENT_VERSION}/vsts-agent-linux-x64-${AGENT_VERSION}.tar.gz; \
    else \
      AZP_AGENTPACKAGE_URL=https://vstsagentpackage.azureedge.net/agent/${AGENT_VERSION}/vsts-agent-linux-${TARGETARCH}-${AGENT_VERSION}.tar.gz; \
    fi; \
    curl -LsS "$AZP_AGENTPACKAGE_URL" | tar -xz

COPY ./start.sh .
RUN chmod +x start.sh

ENTRYPOINT [ "./start.sh" ]

同樣的，上面的Dockerfile並不包含dotnet sdk，所以仍然需要自行安裝進去。

也和上一篇提到的一樣，我們可以透過在Docker hub上找到官方的dotnet sdk映像檔，找到我們要的OS版本，然後取代Dockerfile第一行的FROM後面使用的image repository：

上圖的表格來自於微軟在Docker Hub上的dotnet sdk頁面，dotnet sdk的image repository是mcr.microsoft.com/dotnet/sdk:5.0，我們只需要將冒號後面的5.0改成需要的就行了，以上面紅框內容為例，就把5.0改為5.0-focal，這樣就是以Ubuntu 20.04為版本安裝了dotnet sdk 5.0製作的Docker image，再加上安裝PowerShell、Docker的話，最終的Dockerfile內容如下：

FROM mcr.microsoft.com/dotnet/sdk:5.0-focal

# To make it easier for build and release pipelines to run apt-get,
# configure apt to not require confirmation (assume the -y argument by default)
ENV DEBIAN_FRONTEND=noninteractive
RUN echo "APT::Get::Assume-Yes \"true\";" > /etc/apt/apt.conf.d/90assumeyes

#在這底下加入要額外裝在Docker Image內的程式

RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates \
    curl \
    jq \
    git \
    iputils-ping \
    libcurl4 \
    libicu66 \
    libunwind8 \
    netcat \
    libssl1.0 \
	wget \
  && rm -rf /var/lib/apt/lists/*

# 新增 Microsoft 存放庫金鑰和摘要
RUN wget https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb && \
         dpkg -i packages-microsoft-prod.deb

# 安裝PowerShell
# Enable the "universe" repositories & Install PowerShell
RUN apt-get update && apt-get install -y powershell

# 安裝Docker
RUN apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add
RUN add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
RUN apt-get update && apt-get install docker-ce docker-ce-cli containerd.io

#===========================================

RUN curl -LsS https://aka.ms/InstallAzureCLIDeb | bash \
  && rm -rf /var/lib/apt/lists/*

ARG TARGETARCH=amd64
ARG AGENT_VERSION=2.185.1

WORKDIR /azp
RUN if [ "$TARGETARCH" = "amd64" ]; then \
      AZP_AGENTPACKAGE_URL=https://vstsagentpackage.azureedge.net/agent/${AGENT_VERSION}/vsts-agent-linux-x64-${AGENT_VERSION}.tar.gz; \
    else \
      AZP_AGENTPACKAGE_URL=https://vstsagentpackage.azureedge.net/agent/${AGENT_VERSION}/vsts-agent-linux-${TARGETARCH}-${AGENT_VERSION}.tar.gz; \
    fi; \
    curl -LsS "$AZP_AGENTPACKAGE_URL" | tar -xz

COPY ./start.sh .
RUN chmod +x start.sh

ENTRYPOINT [ "./start.sh" ]

上面的Dockerfile內容中要特別提一下在官方的範例中安裝的libicu60 package只適用在Ubuntu 18.04(參考這篇)，因為我是選Ubuntu 20.04，所以改成libicu66(參考這篇)。

準備好Dockerfile和start.sh這兩個檔案之後，執行下面的指令建立映像檔：

docker build -t devopsagent .

完成Build Image的動作之後，透過下面的指令建立一個名為azure-agent的Container：

docker run --name azure-agent -d -v /var/run/docker.sock:/var/run/docker.sock -e AZP_URL=[AzureDevOpsURL] -e AZP_TOKEN=[AzureDevOpsPAT] -e AZP_AGENT_NAME=[AzureDevOpsAgentName] IMAGE:TAG

docker run的指令和前一篇的大同小異，主要差別在於如何繫結host的docker給container使用。

同樣的環境變數表再貼一次：

同樣貼一下執行的結果：

還有Agent Pools裡的列表和Agent的Capabilities：

其它和前一篇的內容沒什麼太大的差別，至於Linux VM的部份意思差不多，所以就不再另外弄一篇安裝在Linux VM裡的文章了

這篇文章 【2021鐵人賽】建立自管的Azure DevOps Agent(Linux Container agent) 最早出現於 泰克哪裡去。

首先，在Windows Container的部份有些基本的知識需要了解，那就是Windows Container區分不同的基底映像類型(Base Image)，分為Windows、Windows Server、Windows Server Core、Nano Server四種，越前面的映像檔大小所佔的容量越大，包含的功能越多，越後面的則越小，所包含的功能也越少。(參考官方文件：中文/英文)

另外就是Windows Container的隔離模式(Isolation Modes)，分為Process和Hyper-V隔離這兩種，在Windows Server上執行的Windows Container預設以Process隔離方式執行，在Windows 10執行的Windows Container則預設以Hyper-V隔離方式執行。(參考官方文件：中文/英文)

在上面這兩個不同的差異之下，選擇建立Windows Container Image就會有很多的選擇，這牽涉到執行Container的主機(Host)所使用的是哪一個版本的OS，不同版本之間的相容性會有所差異，例如：Windows Server 2019與Windows Server 20H2這兩個版本的OS相容性：

從上面兩張圖可以看到Windows Server 2019的Host可以支援以Windows Server 2019為基底的Container Image以Process隔離模式執行，若是以Hyper-V隔離模式執行，則是可以支援Windows Server 2019以下的版本。同樣的，Windows Server 20H2的Host可以支援同為Windows Server 20H2的Image以Process隔離模式執行，Hyper-V的隔離模式則是與Host相同版本以下的都能夠支援。

換成是Windows 10作為Host的話，支援性又有不同的差異：

Windows 10的部份可以從上面三張圖看到一點點差異，就是Windows 10的1909版本並不能支援Windows Server任何版本為基底映像檔以Process隔離模式執行，Windows 10的2004版本之後才開始支援與Windows Server相對應的版本映像檔以Process隔離模式執行，但是以Hyper-V隔離模式執行的話則是支援相同版本以下的OS映像檔。

有點複雜，對吧？

簡單來說，要能夠支援以Process隔離模式執行，必須是Container Base Image和Host為相同版本的OS，若是以Hyper-V隔離模式執行，則必須挑選Host OS版本以下製成的Container Image，也就是說Windows Server 2016的選擇性非常少，只能使用同為Windows Server 2016為基底製作的映像檔，越新的OS版本則支援以Hyper-V隔離模式執行的Container Image選擇越多。

更多Windows Container版本相容性的部份可以參考官方文件的說明(中文/英文)。

回到Azure DevOps Agent，上面說了那麼多，主要是必須考量Agent要執行的任務需要多大的支援與資源，若是只需要能夠以dotnet sdk建置專案，那麼選擇任何一個OS版本的Image應該都可以，只要能夠在Image裡面安裝dotnet sdk即可。

以dotnet sdk這個例子來說，在官方文件「在 Docker 中執行自我裝載的代理程式」所提到的Dockerfile範例是使用Windows Server Core 2019的基底映像檔，裡面並沒有安裝dotnet sdk：

FROM mcr.microsoft.com/windows/servercore:ltsc2019

WORKDIR /azp

COPY start.ps1 .

CMD powershell .\start.ps1

所以要讓Agent可以執行dotnet build的任務，可以選擇使用上面的範例，在Dockerfile中再另外加入安裝dotnet sdk的內容，或是從Docker hub上另外找微軟官方製作的dotnet sdk映像檔，找到對應的Container Repository與Image tag，例如：「mcr.microsoft.com/dotnet/sdk:5.0-windowsservercore-ltsc2019」這個就是同樣以Windows Server Core 2019為基底的Image，並且安裝了dotnet 5.0 sdk。

從官方文件「在 Docker 中執行自我裝載的代理程式」 中的範例可以看得出來，在Container中執行Azure DevOps Agent的關鍵在於下面這段PowerShell內容，將它複製之後以start.ps1儲存在與Dockerfile相同的位置即可：

if (-not (Test-Path Env:AZP_URL)) {
  Write-Error "error: missing AZP_URL environment variable"
  exit 1
}

if (-not (Test-Path Env:AZP_TOKEN_FILE)) {
  if (-not (Test-Path Env:AZP_TOKEN)) {
    Write-Error "error: missing AZP_TOKEN environment variable"
    exit 1
  }

  $Env:AZP_TOKEN_FILE = "\azp\.token"
  $Env:AZP_TOKEN | Out-File -FilePath $Env:AZP_TOKEN_FILE
}

Remove-Item Env:AZP_TOKEN

if ((Test-Path Env:AZP_WORK) -and -not (Test-Path $Env:AZP_WORK)) {
  New-Item $Env:AZP_WORK -ItemType directory | Out-Null
}

New-Item "\azp\agent" -ItemType directory | Out-Null

# Let the agent ignore the token env variables
$Env:VSO_AGENT_IGNORE = "AZP_TOKEN,AZP_TOKEN_FILE"

Set-Location agent

Write-Host "1. Determining matching Azure Pipelines agent..." -ForegroundColor Cyan

$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$(Get-Content ${Env:AZP_TOKEN_FILE})"))
$package = Invoke-RestMethod -Headers @{Authorization=("Basic $base64AuthInfo")} "$(${Env:AZP_URL})/_apis/distributedtask/packages/agent?platform=win-x64&`$top=1"
$packageUrl = $package[0].Value.downloadUrl

Write-Host $packageUrl

Write-Host "2. Downloading and installing Azure Pipelines agent..." -ForegroundColor Cyan

$wc = New-Object System.Net.WebClient
$wc.DownloadFile($packageUrl, "$(Get-Location)\agent.zip")

Expand-Archive -Path "agent.zip" -DestinationPath "\azp\agent"

try
{
  Write-Host "3. Configuring Azure Pipelines agent..." -ForegroundColor Cyan

  .\config.cmd --unattended `
    --agent "$(if (Test-Path Env:AZP_AGENT_NAME) { ${Env:AZP_AGENT_NAME} } else { ${Env:computername} })" `
    --url "$(${Env:AZP_URL})" `
    --auth PAT `
    --token "$(Get-Content ${Env:AZP_TOKEN_FILE})" `
    --pool "$(if (Test-Path Env:AZP_POOL) { ${Env:AZP_POOL} } else { 'Default' })" `
    --work "$(if (Test-Path Env:AZP_WORK) { ${Env:AZP_WORK} } else { '_work' })" `
    --replace

  Write-Host "4. Running Azure Pipelines agent..." -ForegroundColor Cyan

  .\run.cmd
}
finally
{
  Write-Host "Cleanup. Removing Azure Pipelines agent..." -ForegroundColor Cyan

  .\config.cmd remove --unattended `
    --auth PAT `
    --token "$(Get-Content ${Env:AZP_TOKEN_FILE})"
}

接著就是準備我們要用的Dockerfile，這邊我以dotnet 5.0 sdk的Windows Server Core 2022映像檔為基底，它裡面包含了PowerShell與dotnet 5.0 sdk，並且我還要額外在Image裡面安裝Docker。若是需要dotnet core 3.1與其它OS基底映像檔的部份可以到Docker hub的頁面上去尋找相關的Tag：

FROM mcr.microsoft.com/dotnet/sdk:5.0-windowsservercore-ltsc2022

#在這底下加入要額外裝在Docker Image內的程式

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

RUN Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
RUN Install-Module -Name DockerMsftProvider -Repository PSGallery -Force -verbose
RUN Install-Package -Name docker -ProviderName DockerMsftProvider -Force -verbose -ErrorAction SilentlyContinue; exit 0

#===========================================

WORKDIR /azp

COPY start.ps1 .

CMD powershell .\start.ps1

準備好Dockerfile和start.ps1這兩個檔案之後，執行下面的指令建立映像檔：

docker build -t devopsagent .

完成Build Image的動作之後，透過下面的指令建立一個名為azure-agent的Container：

docker run --name azure-agent -d -v \.\pipe\docker_engine:\.\pipe\docker_engine -e AZP_URL=[AzureDevOpsURL] -e AZP_TOKEN=[AzureDevOpsPAT] -e AZP_AGENT_NAME=[AzureDevOpsAgentName] IMAGE:TAG

指令中比較特別的地方是透過mount的方式將host的docker轉給container內使用，也就是「-v \.\pipe\docker_engine:\.\pipe\docker_engine」這段，其它的除了IMAGE:TAG是根據上面的docker build所指定的Repository與Tag(預設為latest)之外，環境變數的部份則參考下面這張表：

五個環境變數中的最後兩個AZP_POOL、AZP_WORK是選擇性的，只有前三個是必須的，執行之後的結果如下：

從Azure DevOps中的Agent Pools列表中可以看到這個Agent：

進入查看Capabilities的部份也可以看到幾個比較不一樣的資訊，像是ComputerName是Docker產生的隨機名稱，還有docker的資訊：

至於為什麼需要將host的docker提供給Container中的docker使用，這部份則是為了讓Container中的docker可以共用host上的docker，從Container中的Agent執行docker build所產生的docker image也會儲存在host的docker images裡面，並且可以代替host執行docker run建立新的Container。不過這麼做也是有安全性的風險的，官方就有提出警告，是否要這麼做則是可以自行思考決定：

會在這篇文章中這麼做的原因，純粹是為了提供Windows環境將docker轉給Container內使用的指令使用方式，因為這部份在微軟的文件頁面上似乎沒有提到(我忘了之前從哪裡看到的)。

這篇文章 【2021鐵人賽】建立自管的Azure DevOps Agent(Windows Container agent) 最早出現於 泰克哪裡去。

最近在寫iThome鐵人賽的文章，有一篇文章需要在Windows Server上使用Docker與Container的功能，在Azure上建立了一個VM，所以就順便將過程記錄一下。

首先，必須先將Container功能安裝進去(如果這台也要安裝Docker可以跳過這步)，透過ServerManager的AddRolesAndFeatures叫出UI介面之後在Features的部份找到Containers：

勾選之後安裝完需要重新開機。

重新開機之後開啟具有Administrator權限的PowerShell，輸入下面這行指令：

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force

上面這行是安裝稱為 DockerMicrosoftProvider 的 OneGet 提供者 PowerShell 模組。並且需要NuGet提供者(Provider)，如果沒安裝過的話會一併提示是否安裝(預設為Yes)：

接著輸入下面這行指令，從剛才安裝的DockerMicrosoftProvider中安裝Docker：

Install-Package -Name docker -ProviderName DockerMsftProvider

安裝完成之後需要重新啟動電腦，可以透過UI操作，或是輸入下面的PowerShell指令：

Restart-Computer -Force

重開機之後再輸入docker info就可以看到docker相關的資訊了。

參考連結：

• 開始使用：準備適用於容器的 Windows

這篇文章 Windows Server安裝Docker與Container功能 最早出現於 泰克哪裡去。

起先我在寫Shell檔案的時候真的是碰到了許多次因為CRLF / LF換行字元的問題，早期都是回頭去修改原始檔案之後再重新Build Image，久了之後實在是覺得很麻煩，某天忽然想到直接在Dockerfile中安裝dos2unix這個套件，在shell檔案複製之後再執行它來將shell檔案的換行字元的問題解決，從此之後就沒有再為了Windows / Unix-like不同環境的換行字元問題而煩惱過了，因此特別用這篇文章簡短記錄一下，也許有人也為了這個問題困擇了一段時間呢！

Dockerfile內容參考範例

RUN apt-get install dos2unix;
COPY my-init.sh .
RUN dos2unix my-init.sh
CMD ["bash", "my-init.sh"]

這篇文章 解決.sh檔案在Container內執行時的換行字元(CRLF/LF)問題 最早出現於 泰克哪裡去。

其實這只是因為電腦重新啟動後，WSL環境也是重新啟動，所有額外安裝的程式與服務都需要手動重新啟動它們，所以這時候只要再輸入sudo service docker start，再執行docker的指令就可以正常工作了。

不過每次WSL重新啟動之後都需要輸入指令讓docker服務啟動，說實在的有一點麻煩，因為通常用到WSL的時候就是要在裡面跑docker container，所以如果在輸入wsl進入Linux子系統環境的時候就能夠自動將服務啟動的話，那不是方便很多嗎？

這一篇文章就是說明該如何在Linux子系統設定自動啟動docker服務，這個概念其實就和Windows作業系統啟動的時候要執行什麼事情所做的設定是相同的概念，所以也不限於使用在WSL的環境喔！

自動啟動Docker服務

首先，進入WSL之後，輸入cd ~切換到使用者的根目錄，接著再輸入sudo nano .bashrc，透過nano編輯.bashrc這個檔案。

接著會看到裡面有一堆的設定值，直接在最上面第一行將啟動docker的指令sudo service docker start輸入進去，然後按下鍵盤的ctrl+x離開，詢問要不要儲存檔案的時候按y，接著再直接按enter就行了。

到這個動作其實已經可以讓WSL在啟動的時候自動將docker服務啟動起來，不過這樣子只能算是完成了一半，因為在WSL啟動的時候仍然需要一個麻煩的動作：輸入密碼。

省略輸入密碼設定

其實輸入密碼的這個動作也是可以設定成不需要輸入，同樣是透過編輯設定就行。

進入WSL之後輸入sudo visudo，進入設定編輯畫面，這次我們選擇在最下面一行輸入設定值：

<em>帳號</em> ALL=(ALL) NOPASSWD: ALL

輸入完之後，同樣按下鍵盤的ctrl+x離開，詢問要不要儲存檔案的時候按y，接著再直接按enter離開就行了。

完成之後同樣離開WSL環境，並且將WSL終止(wsl -t <em>WSL子系統Distro名稱</em>)，重新輸入wsl進入Linux子系統，可以看到下圖與上面的差異，需要輸入密碼的步驟已經省略掉了。

參考來源

• How to make WSL run services at startup

這篇文章 WSL啟動時，自動啟動Docker服務 最早出現於 泰克哪裡去。