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

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

起先我在寫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)問題 最早出現於 泰克哪裡去。

為了在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檔案設定值的方法 最早出現於 泰克哪裡去。

一開始可以使用「sudo fdisk -l」的方式來列出目前系統中的磁碟(Disk)，看看有哪些磁碟(Disk)與分割區(Partition)。

從上圖看到系統中有三個不同的Disk，而我新增加的是最下面的/dev/sdc 250G大小的Disk，它就是我要下手的目標。

接下來輸入「sudo fdisk /dev/sdc」(後面沒數字)，執行fdisk進入操作模式。

一開始會出現上半部的訊息，如果常操作fdisk工具記得各種選項是做什麼用的，可以直接輸入選項的代號，不然可以輸入m來查看(如下半部)：

因為是一個新的完全空白的磁碟，所以選擇n來建立新的Partition，接下來會詢問是要建立主要分割區還是延伸分割區、分割區號碼、開始與結束磁區位置(就是要割多大)等，如果是使用預設值的話也可以直接按Enter不用輸入。

完成上面的步驟之後，這些改變只是暫時存在記憶體，再輸入w選項，將變更寫入磁碟之後離開。

再輸入一次「sudo fdisk -l」指令重新查看列表，發現最下面多了/dev/sdc1的項目，這就是剛才分割的Parition了。

fdisk是用來做磁碟分割使用，分割完之後還要format格式化才能儲存檔案，在Linux環境中使用mkfs(Make a Linux filesystem的縮寫)，選項的說明可以輸入「sudo mkfs –help」來查看。

我打算將它格式化為xfs格式，所以就輸入「sudo mkfs -t xfs /dev/sdc1」(後面數字要正確)，系統使用預設的設定值格式化之後的資訊如下：

格式化完成之後需要掛載起來，在Windows就是要給它個磁碟機代號(當然也可以掛在某個資料夾下)。

Windows做完格式化並設定完磁碟機代號後就可以使用了，就算重新開機還是會看得到新增的磁碟分割，但是Linux如果要開機時也會自動掛載起來的話，需要將相關資訊寫入/etc/fstab檔案中，在這之前會需要知道分割區的UUID，所以先輸入「sudo blkid」找到對應的UUID。

將UUID裡面的值複製下來之後，輸入「sudo nano /etc/fstab」(我這裡用nano編輯器來修改，也可以用別的)，內容會長得像下面的樣子，分別是Device, Mount point, FileSystem, Parameters, dump, fsck，反正不是很熟就照著第一列的格式輸入大概就行了。

#
# /etc/fstab
# Created by anaconda on Thu Sep  7 20:55:27 2017
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=3c11fba3-32c7-4d0c-b614-aad5630504eb /                       xfs     defaults        0 0
UUID=ca02dd2d-a91b-4fb1-b24b-0fb19c18b89d /boot                   xfs     defaults        0 0

檔案儲存之後，如果要掛載的位置(資料夾)不存在，需要先建立之後再掛載，輸入「sudo mkdir 掛載路徑」建立完空的資料夾之後，最後再輸入「sudo mount -a」將fstab裡面設定的項目都掛載起來。

參考來源

• http://linux.vbird.org/linux_basic/0230filesystem/0230filesystem-fc4.php
• https://blog.gtwang.org/linux/linux-add-format-mount-harddisk/

這篇文章 Linux(Ubuntu)磁碟分割 最早出現於 泰克哪裡去。

這次的需求是為了知道簡單網路行為的耗用時間，也就是延遲時間，所以透過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 網路規則 最早出現於 泰克哪裡去。

這篇文章主要是簡易的快速筆記，如果有較多的心得與內容整理，會再個別獨立寫成一篇篇的文章。

【硬體類】

查看硬體資訊

查看CPU資訊

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
Stepping:              7
CPU MHz:               2593.906
BogoMIPS:              5187.81
Hypervisor vendor:     Microsoft
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              1024K
L3 cache:              36608K
NUMA node0 CPU(s):     0-3
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec md_clear

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
stepping        : 7
microcode       : 0xffffffff
cpu MHz         : 2593.906
cache size      : 36608 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 21
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec md_clear
bogomips        : 5187.81
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
stepping        : 7
microcode       : 0xffffffff
cpu MHz         : 2593.906
cache size      : 36608 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 21
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec md_clear
bogomips        : 5187.81
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
stepping        : 7
microcode       : 0xffffffff
cpu MHz         : 2593.906
cache size      : 36608 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 4
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 21
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec md_clear
bogomips        : 5187.81
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
stepping        : 7
microcode       : 0xffffffff
cpu MHz         : 2593.906
cache size      : 36608 KB
physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 21
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec md_clear
bogomips        : 5187.81
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

這篇文章 Linux指令筆記 最早出現於 泰克哪裡去。

其實這只是因為電腦重新啟動後，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服務 最早出現於 泰克哪裡去。

答案就是：利用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 最早出現於 泰克哪裡去。