今年參加鐵人賽的文章連結都有放在這個頁面，算是一個文章目錄吧！裡面寫到了上次參加鐵人賽完賽的那次距離現在已經隔了八年，今年在一家尚未在台灣成立分公司的港商工作，所以在台灣辦公室這邊找了同一個團隊的同事與香港那邊起初有意願參加的同事加上我共三個人組成了一個團隊。

我今年參賽的文章主題就以Azure DevOps為主軸，將我在目前公司使用到的功能透過這30天不中斷的發文寫出來。當然，文章的內容不可能用目前工作上的東西來寫，所以需要重新思考一下怎麼樣用比較簡單的方式把功能和操作帶出來，沒有在公司用到的功能就先略過不寫，和Azure DevOps無關的也略過，不然寫文章的時間可能不夠…

其實今年以這個主題報名參加iThome的鐵人賽，說實在的並不是為了寫這些文章有其他人會看，而且有很多內容應該有不少地方寫得不錯，所以今年除了要挑戰30天不中斷的發表文章之外，另外一個目的就是把它當作是交接文件來寫。

今年鐵人賽的文章在這一篇之前應該都是和發表在iThome完全相同的內容，唯獨這篇文章的內容可能是兩邊不一樣。

除此之外，iThome那邊的文章發表是為了參加鐵人賽的30天發文不中斷，但是在這個部落格並不會中斷發文，只是不會像參賽一樣維持每天都發文的頻率，後續仍然會視情況將使用Azure DevOps的心得寫上來，只是不會將後續的文章繼續更新連結在「iThome鐵人賽」這個頁面。

不得不說，不管是先前參賽的時候或是這次參賽的過程，總是會碰到趕著寫文章的情況，所以其實從幾個文章內容中應該可以很明顯看得出來哪些是有比較花時間寫得比較多的內容，而哪些則是為了趕在發文時間截止之前儘快生出來的文章。

今年的鐵人賽除了個人參賽項目之外，因為和另外兩個同事一起組了團隊，所以也有團隊參賽的目標，最起碼不能另外兩個同事還沒有Game Over之前我就自己先挑戰失敗，所以再怎麼樣也要完成這個30天的挑戰。

只是沒想到團隊進度進行到三分之一的時候，香港的同事就已經放棄了。在那前兩天，他還提到寫了文章好像都沒什麼人在看，再加上可能公司有些事情他也很忙，所以最後在第10天的時候中斷了發文，放棄了挑戰，因此團隊項目最終是失敗的。反倒是台灣的這個新人同事堅持到了最後一天，完成了挑戰，著實應該給予鼓勵。

最終，也希望藉著參加這個30天不中斷發文的挑戰，帶動起自己寫文章的習慣，不然有時候真的是惰性大於一切，偏偏很多東西不記錄下來又不會時常用到，久了就容易忘記，所以花點時間寫文章也算是一種學習的筆記了。只是…這次又可以持續多久呢？

對了，上次參加鐵人賽完賽好像有送T恤一件(我的那件衣服應該只是因為完賽而得到的吧?)，今年不知道會有什麼東西？或許下個月有結果之後再來更新這篇文章吧！

這篇文章 【2021鐵人賽】2021iThome鐵人賽結尾 最早出現於 泰克哪裡去。

有些前面的步驟在先前的文章就提過了，所以就直接略過，直接看關鍵截圖吧！

從上面的三張截圖中可以看到加入了三個Artifact，分別是Git Repo，裡面放著Dockerfile檔案，建立Docker image的時候會用到；第二個則是從BuildConsoleApp這個Build pipeline取得最新版本的Artifacts；第三個則是從BuildSpecifiedProject這個Build pipeline中取得Artifacts。第二個是直接從最新版本取得，第三個則是讓使用者在建立Release的時候手動從清單中選擇。Build pipeline中取得Artifact的部份必須要在Pipeline中有將檔案上傳到Pipeline的Artifacts，前面文章都有提過喔！

接著來看看Release中的Task內容：

從上面的兩張截圖可以看到內容很簡單，第一張的關鍵在於紅線的地方，也就是前面加入Artifacts的時候設定的名稱，在第二行與第三行後面的BuildOutputFiles這個名稱則是Build pipeline中我們上傳到Artifacts的時候取得資料夾名稱。

第二張截圖則是利用bash來執行docker build的指令，因為在這個Release的Agent部份我指定了使用Self-hosted的Agent，也就是前面文章提到的LinuxContainerAgent(因為Azure試用過期了…)，所以等於在Agent裡面執行透過Bash來執行docker指令，這部份就要確定Agent裡面有安裝才行。

最後是在建立Release的時候，可以從下圖看到在Module的部份就可以讓使用者自行選擇要挑選哪一個版本來作為這個Release的檔案了：

這樣在非全自動的情境下，就可以暫時不需要建立太多的Pipeline，尤其是Module很多的時候，每一個都要建立一個Pipeline的話數量也是不少呢！

這篇文章 【2021鐵人賽】再次建立Release pipeline：多個不同Artifacts來源 最早出現於 泰克哪裡去。

如上圖的兩張截圖，不是以日期加序號的方式呈現，就是名稱加上序號，這種識別方式在Pipeline多的情況下其實會有些困擾，如果又是像前面文章「CI/CD從這裡：第2個Pipeline，建立共用的Build Pipeline」這種方式建立了共用的Build Pipeline，可以透過執行時輸入變數值的方式來讓Pipeline產生不同的結果時，這時候在識別上就會產生很大的問題，不知道哪一次的執行結果是做了些什麼。

不過這個識別編號的格式其實是可以修改的，下面幾張截圖是修改後的範例：

上面第一張截圖就是共用的Build Pipeline修改後的結果，分別執行了三個不同專案的建置，並且從識別文字中可以看得出來是使用master這個Branch的原始碼來建置的，後面再加上日期和序號，這樣就可以知道哪一次執行是做了什麼動作。

第二張截圖則是Release Pipeline修改後的結果，從原本的Release-1、Release-2的格式內容，修改成了DevOpsAgent-20211010.1，從這樣的識別文字就可以直接知道是哪一個Release pipeline的執行結果，並且是哪個日期執行的，比起Release-1、Release-2這樣的內容看起來要好得多了。

下面就來看看要如何修改Pipeline的識別文字吧！

首先是Build pipeline的部份，因為分成兩種編輯模式(傳統編輯器與YAML)，所以修改的方式不太相同，傳統編輯器的修改方式是透過Options頁籤之下的Build number format的欄位進行修改，點擊旁邊的i符號會有提示說明與官網的文件連結(中文/英文)：

以上面共用的Build pipeline執行結果的截圖為例，因為有ProjectName這個變數可供使用者設定，再加上取得Branch名稱的系統預先定義變數為SourceBranchName，日期的部份則是以Date:yyyyMMdd的方式輸出，最後的序列號則是Rev:.r的格式，最終在Build number format的部份就需要輸入：

$(ProjectName)_$(SourceBranchName)_$(Date:yyyyMMdd)$(Rev:.r)

至於同樣是使用Classic editor方式編輯的Release pipeline，同樣也是在Options的頁籤下進行設定，只是欄位名稱改為Release name format，而官網的文件連結也不相同(中文/英文)：

傳統編輯器有設定欄位可以方便設定，但是YAML格式的Build pipeline要怎麼設定呢？

其實上面在傳統編輯器的部份雖然已經寫出了整個Build number format的設定內容，但是最前面的截圖內容卻不是在傳統編輯器下設定的，因為前面文章「CI/CD從這裡：第2個Pipeline，建立共用的Build Pipeline」所建立的Pipeline是透過YAML格式設定的，所以我只是把設定的內容提前寫出來而已，詳細的YAML如下：

name: $(ProjectName)_$(SourceBranchName)_$(Date:yyyyMMdd)$(Rev:.r)

trigger:
- none

pool:
  vmImage: ubuntu-latest

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: '$(ProjectName)/*.csproj'
    arguments: '-o $(Build.BinariesDirectory)'
- task: ArchiveFiles@2
  inputs:
    rootFolderOrFile: '$(Build.BinariesDirectory)'
    includeRootFolder: false
    archiveType: 'zip'
    archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildNumber).zip'
    replaceExistingArchive: true
- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)'
    artifact: 'BuildOutputFiles'
    publishLocation: 'pipeline'

從上面的YAML內容可以看到，設定的地方是在最上面的name的部份，在官網文件上(中文/英文)有提到，在YAML格式是以name這個名稱來設定，並且它是屬於根(root)層級，所以把它放在最上面的一行。

上面的YAML內容中還有一個地方也進行了修改，那就是在壓縮檔案的Task部份也使用了Build.BuildNumber這個變數，也就是我們在最上面的name的部份所設定的格式內容會放入Build.BuildNumber裡面，所以將這個變數值做為我們壓縮後的檔案名稱，最終從下圖也可以看到執行後所上傳到Artifacts中的檔案名稱的變化，以及Pipeline執行結果的識別名稱與之前的差異：

這篇文章 【2021鐵人賽】設定Pipeline的識別文字格式 最早出現於 泰克哪裡去。

底下先來部份回顧前面文章「CI/CD從這裡：設定第一個Pipeline(範本與編輯介面介紹)」內的YAML內容，也就是.NET Desktop的YAML範本：

trigger:
- master

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

從上面的內容中可以看到在第一層有trigger、pool、variables、steps，而在steps的下一層有多個task，在Pipeline的YAML結構應該是下面的這個樣子：

• YAML
  • name
  • resources
  • trigger
  • pool
  • variables
  • stages
    • jobs
      • steps
        • script/bash/pwsh/task …

扣除掉前面幾個只會設定一個的項目，範例結構會像這樣：

• stages
  • 階段A(stage)
    • jobs
      • 作業1(job)
        • steps
          • 步驟1(task)
          • 步驟2(script)
          • 步驟3(pwsh)
      • 作業2(job)
  • 階段B(stage)
  • 階段C(stage)

所以在上面的YAML範例內容中，其實是省略了上層的許多結構描述，這部份在官方的文件頁面上有提到，如果只有單一階段(stage)，可以省略關鍵字stages並且直接使用jobs開始。如果只有單一階段(stage)和單一作業(job)，可以省略stages和jobs關鍵字，直接使用steps開始。所以在範本的YAML中才會看到只有steps開始定義底下的task的情況。

所以前一篇的「YAML格式以外的Pipeline傳統編輯器(Classic Editor)」文章內容中看到了一個Pipeline中可以有多個不同的Agent Job，實際上在YAML格式的內容中就只是在jobs底下定義多個不同的job，在job底下再放入steps底下的內容即可，下面我以前面文章「CI/CD從這裡：編譯專案與上傳成品」內容中的YAML稍作修改，steps中使用相同的內容，多增加一個job，YAML如下：

# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml

trigger:
- none

pool:
  vmImage: ubuntu-latest

jobs:
  - job:
    displayName: Job1
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'
        projects: 'ConsoleApp/*.csproj'
        arguments: '-o $(Build.BinariesDirectory)'
    - task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: '$(Build.BinariesDirectory)'
        includeRootFolder: true
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/Job1-$(Build.BuildId).zip'
        replaceExistingArchive: true
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'BuildOutputFiles'
        publishLocation: 'Container'

  - job:
    displayName: Job2
    pool:
      vmImage: windows-latest
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'
        projects: 'ConsoleApp/*.csproj'
        arguments: '-o $(Build.BinariesDirectory)'
    - task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: '$(Build.BinariesDirectory)'
        includeRootFolder: true
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/Job2-$(Build.BuildId).zip'
        replaceExistingArchive: true
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'BuildOutputFiles'
        publishLocation: 'Container'

從上面的YAML內容可以看到有兩個不同的Job，顯示的名稱分別是Job1、Job2，Job底下的steps幾乎都是相同的內容(複製的)，只有在壓縮檔案的名稱內多了Job1、Job2的前綴字來分別，但是在Job1的displayName底下並沒有額外的設定，在Job2的displayName底下卻另外設定了pool的內容，指定使用Windows的vmImage。也就是說，Job1使用最上層定義的Linux的vmImage(ubuntu)，Job2則是自行另外設定，改用Windows的vmImage。

實際執行的資訊頁如下，可以看到最下面有兩個不同的Job：

點擊任何一個Job都可以進入執行的Log頁面，可以看到下面兩個不同Job的Agent是來自不同的OS(Linux/Windows)：

執行之後上傳的成品檔案也如預期以不同的Job名稱為開頭命名：

不同的Job除了可以定義不同的pool之外，也可以定義不同的variables等其它不同的設定，如果需要更多詳細的YAML結構描述內容的定義資訊，可以直接看官方的文件(中文/英文)。

這篇文章 【2021鐵人賽】Build Pipeline的YAML結構描述：多個Agent Job 最早出現於 泰克哪裡去。

當時在文章中有稍微提到Classic editor傳統編輯器，而在「CI/CD從這裡：建立第一個Releases Pipeline」這篇文章中也亮相了UI編輯的畫面(因為目前Release Pipeline沒有YAML編輯畫面)，這篇就來談談這個Classic Editor。

建立Build Pipeline的時候，在選擇範本的最下面有一行「Use the classic editor to create a pipeline without YAML」(還記得前面文章提到的嗎？)，如下圖點擊之後就可以進入傳統編輯器的流程：

接著選擇Source code的來源：

選好Source來源之後就可以來到範本選擇的畫面：

我們選擇Empty job之後一開始出現的畫面如下：

在上面這個畫面中可以修改Pipeline的名稱以及預設這個Pipeline使用的Agent pool和Agent規格，不過Agent的設定在Agent job裡面可以另外修改。

如果前面的Source來源選錯或是要更換，以及更詳細的設定，則是可以點選左邊的Get sources之後就可以在右邊的對話框調整設定。

而Agent job的設定畫面則是如下圖：

在之前的文章建立Pipeline的時候都只有使用到一個Agent job，但是其實是可以另外增加許多個不同的Agent job，而不同的Agent job可以設定使用不同的Agent(可以Windows與Linux互相搭配)：

在多個Agent/Agentless job的情況下就有些額外的設定可以調整：

而Task則是加在Agent job底下，設定的畫面和YAML版本右邊的assistant顯示的畫面相同：

若是要同時設定Pipeline的Triggers也可以從上面切換到Triggers的頁籤，畫面和先前文章所提的完全一樣。Task那些的用法與設定也和前面文章所提的相同，所以這邊就不再重覆建立新的Pipeline。可以試著對照先前建立的YAML格式的Pipeline來改用傳統編輯器試試喔！

最後，因為Classic editor並不會將設定的內容存成檔案放在Repo裡，所以和YAML編輯器最大的不同就是不會看到Pipeline的設定檔案(所以也沒有Save之後的Commit觸發)。

這篇文章 【2021鐵人賽】YAML格式以外的Pipeline傳統編輯器(Classic Editor) 最早出現於 泰克哪裡去。

Teams可以發送訊息的地方分為Chat與Teams底下的Channel，這篇主要是設定Channel中的連接器Connector。

首先，挑選要接收通知的Channel，然後將右邊的隱藏選單叫出來，接著選擇「連接器」或「Connectors」(下面以英文版為例)：

若是沒有設定過Azure DevOps的Connector的話，第一次會看到如下圖的Add：

點擊Add進入Connector的介紹畫面後再按下Add新增：

新增完之後，同一個Channel以後就只會看到如下圖的Configure：

點擊Configure進入之後第一次會要求Login，進行身份驗證與授權，代表這個Channel之後就會使用登入的帳號身份來使用Connector：

完成登入與授權之後，進入Connector主要的設定畫面，可以從下圖看到能設定的選項有哪些：

其中Event Type有下列可以選擇的項目，根據不同選擇而出現Event Type下方不同的選項，上圖選擇的是Build completed的時候發送通知到Teams channel中：

設定完成之後在Connectors畫面的左邊選項Configured中就會列出Azure DevOps底下已設定的通知事件，可以設定多個不同的事件通知：

完成設定之後實際在Azure DevOps裡面執行相對應的操作之後，在Channel中就會出現如下的通知訊息(第一則是設定之後的通知訊息)：

不過這裡要特別提醒相關人員要將Channel的notification選項改為All activity，這樣才會在Teams的左邊出現紅色提醒，不然可能會很久沒發現有新的訊息通知喔！

這篇文章 【2021鐵人賽】接收Azure DevOps的通知：Microsoft Teams頻道中的連結器 最早出現於 泰克哪裡去。

首先，我在Project Settings的Permissions建立了兩個Group，分別是Build Pipeline Executor與Release Pipeline Executor：

接著到Build Pipeline或Release Pipeline叫出隱藏的選單，選擇Manage security/Security：

設定權限的對話框長得都差不多，左邊會列出Groups與Users，透過上面的搜尋框搜尋到要設定的Group或User，然後在右邊進行設定：

像上面這張是設定單獨的Build pipeline的權限，我加入了Build Pipeline Executor這個Group，並且在右邊設定了四個項目的權限。

Build Pipeline的權限設定也可以設在整個Build Pipeline上，如下圖我在整個Build Pipeline的部份設定了一個User：

上面第一張是設定在整個Build Pipeline的截圖，第二張則可以看到從其中的一個Build Pipeline看到相同的User在右邊權限項目是顯示為inhertied。

Release Pipeline的設定也差不多：

透過上面的這些設定，我們就可以將Pipeline的執行權限設定給其他人，目前的Azure DevOps也已經允許Stakeholder擁有執行Pipeline的權限，所以如果只是要執行Pipeline的任務，不一定要將使用者的角色設定為Basic(還記得嗎？Basic要計費的)。

這篇文章 【2021鐵人賽】設定Build Pipeline與Release Pipeline的執行權限 最早出現於 泰克哪裡去。

從Azure DevOps Project左邊的Pipelines選單底下的Releases點擊之後，第一次進入會看到下面這個空的畫面：

點擊New pipeline之後右邊會跳出選擇範本的畫面，我們選擇Empty job：

接著出現Stage的設定畫面，可以改一下容易識別的名稱，然後按右上角的X關閉對話框就行：

接著點擊Artifacts的+ Add：

這邊我將前面建立Liunx Container Image相關的檔案放到另外一個Git Repo用來作為這篇的範例：

所以在Add Artifacts Source的部份選擇第二個Azure Repo，並且選擇來源的Project、Source (repository)、Default branch等…，不一定要和Release pipeline相同的Project。

接著點擊右邊Stage底下的1 job, 0 task就可以進入Task的編輯畫面：

因為是要建立Linux的Image，所以點擊Agent job要修改一下Agent改為Linux的Agent(這裡用的是雲端的Agent)：

Agent Specification改為ubuntu-20.04之後，點擊Agent job右邊的+號新增Task，搜尋Docker這個Task並按下Add加入：

設定Task的屬性，Container registry第一次要先新增Service connection，Tags的部份如果需要額外的tag以每一行一個新增：

改完之後也修改了Release pipeline的名稱就可以按下Save，旁邊的Create release按鈕就會變成可以按的狀態。按下之後會出現下面的對話框：

這邊因為沒有什麼特別要調整的，所以點擊對話框下面的Create就行。接著在左上角會有淺綠底的提示訊息，裡面有文字快速連結可以進入剛建立的Release：

進入後可以看到建立的Release狀態(Queued等待中或In progress執行中)：

點擊底下的Logs就可以進入看各步驟詳細的Logs：

這篇就先快速的帶大家簡單的建立一個Release pipeline，後續的文章再做複雜一點的說明。

這篇文章 【2021鐵人賽】CI/CD從這裡：建立第一個Releases Pipeline 最早出現於 泰克哪裡去。

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