因為其實在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的抉擇 最早出現於 泰克哪裡去。

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

不同的地方在於，Linux環境中透過額外安裝jq套件來達成修改json檔案的作法，在Windows環境下我們則是使用PowerShell來達成這樣的事情，所以不需要額外安裝任何套件(PowerShell應該都有內建在Windows環境中)。

下面的內容和Linux Container中修改json檔案設定值的方法文章中的內容幾乎一樣，我額外用不同的字型顏色標出不同的地方，以便參考。

使用方式

假設在Dockerfile中定義了ENV LOG_LEVEL=Error，並且appsettings.json檔案中有段Serilog的設定如下：

{
    "Serilog": {
        "MinimumLevel": "Debug",
        "WriteTo": [
            {
                "Name": "File",
                "Args": {
                    "path": "MyApp.log",
                    "outputTemplate": "{Timestamp:yyyy-MM-dd HH:mm:ss} RequestID:{RequestID} User:{UserID} {RequestPath} {SourceContext} [{Level:u3}] {Message:lj}{NewLine}{Exception}",
                    "rollingInterval": "Day"
                }
            }
        ],
        "Enrich": [ "FromLogContext" ]
    }
}

可以看到在Serilog中有個MinimumLevel屬性設定的是Debug，這個設定會記錄大量的Log記錄，但是有時候在執行container的時候並不想要記錄這麼詳細的資訊，以降低檔案大小，減少儲存空間的耗用時，有個LOG_LEVEL的ENV設定就可以方便的調整設定值。

現在假設有個.Net Core的程式叫MyApp，Build完之後有個MyApp.dll檔案，在Dockerfile中設定了ENV和複製相關的執行檔案之外，還需要一個.ps1檔案(Powershell的副檔名)，假設這個檔案叫做app-init.ps1。

接下來在app-init.ps1檔案中要做下面這幾件事：

1. 判斷container是不是第一次執行，以避免每次都進行修改appsettings.json的動作。
2. 透過Powershell的Get-Content指令將appsettings.json的內容讀入記憶體。
3. 找到MinimumLevel屬性，將值修改為LOG_LEVEL這個ENV所設定的值。
4. 將Powershell修改後的內容儲存為appsettings.temp.json。
5. 將原本的appsettings.json改名為appsettings.ori.json。
6. 將前面的appsettings.temp.json改名為appsettings.json。
7. 產生一個用來判斷是否執行過app-init.ps1的檔案，例如：inited.txt。
8. 啟動MyApp。

Set-Location C:\app

if (Test-Path inited.txt) {
    echo "Powershell already run finished."
}
else {
    $JsonSettings = Get-Content appsettings.json | ConvertFrom-Json
    $JsonSettings.Serilog.MinimumLevel = "$env:LOG_LEVEL"
    $JsonSettings | ConvertTo-Json -Depth 10 > appsettings.temp.json

    Rename-Item appsettings.json appsettings.ori.json
    Rename-Item appsettings.temp.json appsettings.json
    "Powershell run finished." > inited.txt
}

dotnet MyApp.dll

這篇文章 Windows Container中修改json檔案設定值的方法 最早出現於 泰克哪裡去。

為了在docker啟動container的時候可以根據繫結的環境參數(environment, -e)值做出相對應的修改，因此需要有個方便的作法可以在container執行的時候動態修改json檔案。

這一篇文章就來介紹如何在Linux中透過jq套件修改json文件。

先決條件

Container中需要先安裝jq套件，所以必須在Dockerfile中先透過apt-get install -y jq指令(Ubuntu/Debian)安裝jq套件，以便Docker Image中有jq套件可以使用。

使用方式

假設在Dockerfile中定義了ENV LOG_LEVEL=Error，並且appsettings.json檔案中有段Serilog的設定如下：

{
    "Serilog": {
        "MinimumLevel": "Debug",
        "WriteTo": [
            {
                "Name": "File",
                "Args": {
                    "path": "MyApp.log",
                    "outputTemplate": "{Timestamp:yyyy-MM-dd HH:mm:ss} RequestID:{RequestID} User:{UserID} {RequestPath} {SourceContext} [{Level:u3}] {Message:lj}{NewLine}{Exception}",
                    "rollingInterval": "Day"
                }
            }
        ],
        "Enrich": [ "FromLogContext" ]
    }
}

可以看到在Serilog中有個MinimumLevel屬性設定的是Debug，這個設定會記錄大量的Log記錄，但是有時候在執行container的時候並不想要記錄這麼詳細的資訊，以降低檔案大小，減少儲存空間的耗用時，有個LOG_LEVEL的ENV設定就可以方便的調整設定值。

現在假設有個.Net Core的程式叫MyApp，Build完之後有個MyApp.dll檔案，在Dockerfile中設定了ENV和複製相關的執行檔案之外，還需要一個.sh檔案(Linux中的Shell檔，相當於Windows的.cmd或.bat)，假設這個檔案叫做app-init.sh。

接下來在app-init.sh檔案中要做下面這幾件事：

1. 判斷container是不是第一次執行，以避免每次都進行修改appsettings.json的動作。
2. 透過jq套件將appsettings.json的內容讀入記憶體。
3. 找到MinimumLevel屬性，將值修改為LOG_LEVEL這個ENV所設定的值。
4. 將jq套件修改後的內容儲存為appsettings.temp.json。
5. 將原本的appsettings.json改名為appsettings.ori.json。
6. 將前面的appsettings.temp.json改名為appsettings.json。
7. 產生一個用來判斷是否執行過app-init.sh的檔案，例如：inited。
8. 啟動MyApp。

假設Dockerfile中設定的WORKDIR是/app，第7點的檔案是放在/app/inited，那麼app-init.sh的程式碼內容大概會是下面這個樣子：

if [ -f "/app/inited" ]; then
    echo "Container inited, skip this shell."
else
    cat appsettings.json #這行只是先輸出原本的設定值，用來查看用的
    jq '.Serilog.MinimumLevel=env.LOG_LEVEL' appsettings.json > appsettings.temp.json

    cat appsettings.temp.json #查看儲存的檔案內容

    mv appsettings.json appsettings.ori.json #第5點，將原本的設定檔改名
    mv appsettings.temp.json appsettings.json #第6點，將jq儲存的暫存檔改為正式檔名

    echo "Container inited." > /app/inited #第7點，產生判斷是否init過的檔案
fi

dotnet MyApp.dll #第8點，啟動MyApp

透過上面的app-init.sh檔案，在Container第一次執行的時候就會根據設定的內容修改appsettings.json檔案，產生的inited檔案可以避免container restart之後重複執行init的動作。

透過這樣的技巧，也可以修改appsettings.json中的資料庫連線字串，如果是像Serilog底下的WriteTo屬性是陣列(集合)型式的，則是用[0]、[1]這樣的方式設定，範例如下：

jq '.Serilog.MinimumLevel=env.LOG_LEVEL' appsettings.json | \
jq '.Serilog.WriteTo[0].Args.rollingInterval=env.LOG_ROLLING_INTERVAL'  > appsettings.temp.json

這篇文章 Linux container中修改json檔案設定值的方法 最早出現於 泰克哪裡去。

答案就是：利用Windows中的Linux子系統(Windows Subsystem for Linux, WSL)。

透過WSL安裝Linux子系統之後，可以在Linux子系統中安裝原生的Docker執行環境，在Windows環境中則是安裝Docker Desktop並且切換到使用Windows Container，這樣一來就可以在Windows環境執行Windows Container，Linux子系統中執行Linux Container了。

註：WSL是Windows 10的功能，版本又分為Version 1(WSL)與Version 2(WSL2)，WSL2只能在Windows 10 2004版(組建19041以上)執行。(參考官方wsl文件說明)

在開始之前，先輸入wsl -l -v查看一下系統內安裝的Linux子系統是執行在哪一個版本(1或2)。
在Linux子系統中要執行原生的Docker，只能在Version 2的版本(WSL2)。

先輸入docker info確認系統中沒有安裝docker。

接著，根據官方的安裝指引將Docker Engine安裝到Linux子系統中：

• Ubuntu：https://docs.docker.com/engine/install/ubuntu/
• Debian：https://docs.docker.com/engine/install/debian/
• CentOS：https://docs.docker.com/engine/install/centos/
• Fedora：https://docs.docker.com/engine/install/fedora/

更新系統中的套件

先輸入sudo apt-get update更新系統中的套件。

安裝需要的套件

再輸入下列指令安裝docker需要的其它套件：

sudo apt-get install \
apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
software-properties-common

註：「\」符號是Linux指令的換行連接符號，用來將較長的指令換行輸入，實際上在系統中仍然是組合成一整行的指令，因此也可以將上面的指令直接輸入成一行。(記得拿掉「\」符號)

安裝上述幾個套件的過程中會碰到詢問y/n的問題，通常是告知會使用多少磁碟空間，輸入y繼續安裝就行了。

取得GPG Key

接下來取得docker的GPG key：

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

註：「|」符號是Linux中的命令管線符號，用來將前一個命令執行的結果送到下一個命令的輸入。

接下來這一步可以跳過，只是用來驗證剛才取得的GPG key是否正確。

sudo apt-key fingerprint 0EBFCD88

輸入完之後會看到下面9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88的內容。

加入套件存放庫(Repository)

接下來將docker官方的套件存放庫(repository)加入到Linux子系統中，這樣才能夠安裝docker engine：

sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"

小提示：如果你發現你的網址輸入錯誤．也就是在輸入指令之後下面的訊息有顯示Err的字樣，那麼可以編輯套件庫清單的設定檔，將錯誤的網址修正或移除重新加入。(參考來源)

sudo nano /etc/apt/sources.list

安裝Docker Engine

輸入下面兩行指令安裝Docker Engine，第一行是更新套件指令，第二行則是安裝Docker的指令

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

安裝過程中會有個磁碟空間耗用的問題，輸入y就能繼續。
接著會碰到下面的問題，是詢問grub-pc套件要裝在哪一個磁碟分割：

grub-pc應該是一個啟動管理的套件，不太確定是上面哪個套件相依的需求，以上圖來看，Linux子系統抓到三個(實際上只有sda、sdb兩個)容量大小相同的項目。
透過空白鍵可以選擇/取消，想知道sda、sdb分別是什麼的話，可以再另外開一個cmd或powershell視窗，輸入wsl透過另外一個terminal進入查看：

從上面可以發現sda、sdb其實是一樣的，只是檔案系統實際上掛載在sdb項目，所以選擇sda、sdb也許都可以，不過實際上選擇第一個sda項目的時候，安裝到一半會出現下面的錯誤訊息：

既然無法安裝在sda，那麼就不要霸王硬上弓硬是要安裝在sda，所以選擇No之後，回到上面的選單項目，將sda取消，選擇第二個sdb試試。
沒有再出現上面無法安裝詢問是否要霸王硬上弓的問題，順利安裝完成。

輸入docker info查看安裝的結果，只顯示client資訊，server資訊則是無法連線，其實這只是docker service沒有啟動的關係。

輸入sudo service docker start啟動docker服務，再次輸入docker info查看docker的資訊卻發現…

看起來和上面那張截圖滿像的，不過最後有個關鍵字是「permission denied」。
既然如此，那使用sudo執行看看呢？(sudo docker info)

Bingo，能夠正常查看到docker的資訊了！

不過這樣每次要執行docker相關的指令都要輸入sudo有點麻煩，所以接著可以利用下面的指令，將docker加入特定的用戶群：

sudo usermod -aG docker 帳號

輸入完上面的指令之後，如果直接再次輸入docker info想要試試是否有效，會得到令人失望的結果。主要是因為當下使用的terminal沒有登出再重新登入取得最新的資訊，只要退出terminal之後再重新執行就可以正常了。

OK，這下子終於將docker順利安裝在WSL2裡面啦~

從下面的截圖也可以發現，在wsl裡面查看docker info和windows底下查看docker info的差異，證明兩個docker環境是彼此分開獨立的喔！

PS.Windows環境安裝Docker Desktop並且切換到Windows Container模式了，這樣一來就可以在一台電腦中同時執行Linux Container與Windows Container了。

這篇文章 同一台電腦可執行Windows與Linux Container？在WSL2安裝原生Docker環境 最早出現於 泰克哪裡去。

不太想要動到OS重灌這一招，想到之前似乎有試過(看到)在Windows 10 Home版安裝Hyper-V與WSL，不過因為很久沒有寫部落格記錄，有些問題解決之後就沒有記錄，所以趁著這次解決這個問題並且將部落格從幾次亂搞之後最近放到Google Cloud Run上面執行，一併將這些操作記錄下來。

首先，Windows 10 Home版打開控制台「程式和功能」中的「Windows 功能」應該不會有「Hyper-V平台」、「適用於 Linux 的 Windows 子系統」兩個選項。

從Windows 10 Hyper-V System Requirements的頁面說明中也有下面這段，明確表明Windows 10 Home的版本不能安裝。

The Hyper-V role cannot be installed on:

• Windows 10 Home
• Windows 10 Mobile
• Windows 10 Mobile Enterprise

不過這個其實有秘技可以讓Hyper-V安裝在Windows 10 Home，只需要將下面這段指令貼在記事本上，並且以.bat的副檔名儲存後透過管理員權限執行即可。

pushd “%~dp0”
dir /b %SystemRoot%\servicing\Packages*Hyper-V*.mum >hyper-v.txt
for /f %%i in (‘findstr /i . hyper-v.txt 2^>nul’) do dism /online /norestart /add-package:”%SystemRoot%\servicing\Packages\%%i”
del hyper-v.txt
Dism /online /enable-feature /featurename:Microsoft-Hyper-V -All /LimitAccess /ALL
pause

如果也想要安裝Container功能的話，同樣將下面這段指令以.bat儲存後透過管理員權限執行。

pushd “%~dp0”
dir /b %SystemRoot%\servicing\Packages*containers*.mum >containers.txt
for /f %%i in (‘findstr /i . containers.txt 2^>nul’) do dism /online /norestart /add-package:”%SystemRoot%\servicing\Packages\%%i”
del containers.txt
Dism /online /enable-feature /featurename:Containers -All /LimitAccess /ALL
pause

執行完之後重新開機應該就可以找到Hyper-V的功能了，不過到這裡為止，仍然無法安裝Docker。
或者是說，如果不是Windows 10 Home搭配Docker使用WSL2(Windows Subsystem for Linux, WSL)，那麼就無法使用Docker。

再更精確一點的說法，就是Docker需要Hyper-V與Container的功能，如果是Windows Home安裝WSL2再加上Docker，那麼就是在WSL2裡面執行Container，跑的是Linux，如果只需要執行Linux的Container是OK的。

不過若是需要在Windows Container和Linux Container之間切換的話，Windows 10 Home版本一般來說是無法達成，而且Docker搭配WSL2跑Linux Container若是使用到Docker-Compose的話，可能還會有一點點問題…

所以為了在Windows 10 Home的版本正常執行Docker(Hyper-V都透過秘技安裝了，應該還有秘技可以讓Docker正常在Windows 10 Home版本安裝與執行吧！)，所以我繼續在網路上搜尋可能的秘技，想要解決在Windows 10 Home版本使用Docker的問題。

這次的秘技不需要再執行指令安裝什麼東西，需要的是執行regedit編輯Windows登錄檔，透過將「HKLM\Software\Microsoft\Windows NT\CurrentVersion」底下的EditionID從「Core」更改為「Professional」，改完之後不需要重新開機，就可以執行最新版本的Docker安裝檔。

上面的這個修改Windows登錄檔的位置要記下來，或者是寫成一個指令檔。
因為Windows過一段時間(不知多久)會自己將更改的值改回「Core」(如果你改完忘了改回來)，尤其是Windows Update完之後。

這會有什麼影響呢？

會影響的就是Docker切換Windows Container與更新Docker版本，如果Docker發現新的版本，但是當你要執行更新安裝的時候發現有問題，可以試著將EditionID再改為「Professional」，之後應該就可以更新了。
註：要透過Docker結合WSL2執行Linux Container必須是切換到Linux Container模式才行。
(不過也可以選擇不要在Windows下操作Docker跑Linux Container，直接在WSL2裡面安裝獨立的Docker)參考來源：

參考來源

• Installing Docker on Windows 10 Home

這篇文章 Windows 10 Home家用版安裝Hyper-V與Docker 最早出現於 泰克哪裡去。