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

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