【詳解】以 ASP.NET Core 為例的CI/CD

在軟體開發中，專案部署是很重要的一環。特別是在敏捷開發中，如何快速、高效且順利的將修改的程式碼轉化成實際效果，一直是一個津津樂道的話題。常見持續整合和持續部署（下文簡稱CI/CD）的實現方案是Jenkins，通過Jenkins+宿主機伺服器，快速實現專案迭代，這樣做確實是會給我們帶來極大的便利，也是一直比較流行的方案。然而現實中卻沒這麼簡單，我們現在更多的是基於容器化實現K8s叢集開發，Jenkins總是會顯得有些無力，更別說在K8s中實現一整套的基於多環境的CI/CD操作了。那麼我們如何才能完美的實現基於K8s的CI/CD呢？
通過本次實驗，我們以微軟 Azure Kubernetes Service 為例（下文簡稱AKS），使用 ASP.NET Core 專案，來分析CI/CD操作。

CI篇

前期準備賬號

首先，需要註冊一個Azure賬號。

其次，需要一個原始碼管理倉庫，可以新建並使用Azure DevOps程式碼庫，有很好的看板和操作提示，推薦使用。

也可以使用自己的GitHub賬戶，自從微軟收購Github以來，對Azure的相容性特別友好！如果在GitHub上已經有專案了，可以直接建一個CI的Pipeline即可，建完後效果如圖，具體的操作部署下文會顯示說明。

使用Azure來建立Pipeline的目的主要有兩個：
1、保證程式碼的準確性，比如臨時修改一個程式碼，又沒有編譯器，一般就直接修改，然後提交，讓CI來初步檢查程式碼的準確性；
2、可以構建映象並推送到倉庫，甚至還可以下一篇文章說到的直接部署。
真正意義上實現 修改程式碼 == 預覽效果 的目的。
Github的Action也有這樣的功能，實現思路大致一樣，只不過在CD（持續部署上），不太好操作，具體可以參考我Blog.Core專案的程式碼，這裡不細說。

連線Dockers Registry服務

新建CI的管道，推薦配置一個Docker Registry服務，這樣可以將Build完成後的映象推送到映象倉庫中，方便後續的CD操作。

步驟 1 - 專案設定

點選專案下方的Project settings操作連結：

在彈出的新頁面中，選擇左側導航條的Service connections操作：

點選新建服務連線按鈕：

步驟 2 - 配置 Docker Registry 選項

搜尋docker關鍵詞，選中Docker Registry選項：

選擇Registry型別，輸入DockerID和密碼，給這個連線取一個名字，點選Save按鈕。

一個服務連線就建立完成了，在以後的CI操作中，會用到這個連線。

使用者名稱和密碼要正確，否則會提示錯誤，可以點選Verify進行校驗：

新建一個Pipeline管道

步驟 1 - 配置 Code 源倉庫

選擇新建Pipeline，勾選Github，如果原始碼管理是在Azure DevOps中的，可以直接第一個選項。因為我使用的是Github，所以直接勾選GitHub，基本都是採用的是YAML的方式。

選擇一個自己的專案（PS：這個時候可能需要Github二次密碼確認）：

步驟 2 - 配置你的Pipeline

採用容器化部署，點選Docker選項，注意和第二個的區別：

配置YAML檔案，系統會預設建立一個，只有build操作，可以去掉預設的task，在後側選擇一個docker的Assistant模板：

也可以直接點選左側程式碼中settings連結，自動喚起編輯視窗：

其他都是預設，只需要勾選剛剛的服務連線就行，然後輸入自己的容器倉庫名，請注意，需要在映象名中增加字首，也就是各自的Docker ID，點選Add按鈕，左側就同步變化了。

步驟 3 - 點選執行 Pipeline

然後點選右上角的Save and run按鈕，一個完整的CI操作就完成了。

同時會把剛剛為建立Pipeline而產生的YAML檔案程式碼給同步到GitHub上：

Build完成後，我們可以在Docker hub中看到推送的映象：

以上，我們已經完成了持續整合（下文簡稱CI）的部分，成功將ASP.NET Core專案進行打包編譯，並推送到了指定的Docker映象倉庫中。

現在我們繼續完成成品的持續部署（下文簡稱CD）流程。

CD篇

新增Release管道

步驟 1 - 新建Pipeline

在左側導航條中，點選Pipelines（管道）下的Release（釋出）選項，新建一個Pipeline，如果之前未建立過Release的Pipeline，頁面預設展示效果如下所示：

在右側的模板中，選擇一個空模板：

步驟 2 - 配置Artifact

將滑鼠移動到左側的Artifacts（製品）模組上，單擊新增一個Artifact，此時右側會喚起編輯視窗，單擊build（編譯）選項：

選擇之前build的管道，使用Latest最新版本，此刻我們的CD管道便正式和CI管道關聯起來。

步驟 3 - 自動構建

單擊製品右上角的構建圖示，開啟自動構建，這樣只要提交程式碼的時候，便會觸發CI的Build操作，接著便立即觸發CD的Release操作，整個流程一氣呵成。

配置好了Artifact，然後就可以配置task任務了。

配置Agent代理

將滑鼠放到右側的Stage（階段）選項上，可以看到有三塊功能選擇，分別是：

①、對Stage進行重新命名；
②、新增一個新的Stage；
③、編輯task（任務）；

點選任務連結，配置Agent Job（代理工作），這裡有兩點需要注意：

1、代理池，指部署的地方，目前預設即可，以後可以用自己的伺服器；

2、agent specification（代理規格），就是伺服器規格配置；

請注意！這裡預設的是vs2019規格，是windows環境的，如果不改的話，會出現Docker不能執行的平臺問題。所以直接選Linux即可。

配置Task任務

步驟 1 - 刪除舊容器

點選AgentJob右側的加號，篩選docker的task模板

在新喚起的編輯頁中編輯命令，刪除舊的容器，直接用run命令，所以Task的版本用0.*：

選擇容器Registry地址，配置一個action（行為），增加一個刪除映象的命令

rm -f xxxx

步驟 2 - 執行新容器

與第一步刪除舊容器的階段步驟相似，再建一個執行容器的Stage，整體流程一致，配置圖如下所示：

Task版本為1.*的Docker容器配置，使用自定義的DockerRegistry，配置映象名，支援自定義，比如我加了字首，最後指定埠。

點選Save（儲存），一套簡單的持續整合管道就建好了

可以手動觸發，create release，就可以看到詳細的過程：

等一段時間後，新容器已經被成功執行了，只不過目前還沒有配置自己的代理池，因此無法檢視具體的展示效果。

如何檢視效果

目前Azure部署專案有兩種常見的方式：

1、配置自定義代理池，用自己的伺服器提供代理池，生成映象和執行容器都會在自己的代理池伺服器中執行。

2、直接使用Azure的k8s服務，新建一個Deploy的Task，指定對應的服務連線和Yml檔案，這樣就會把映象推送到Azure的映象倉庫，並將映象執行構建Pod例項。

編者兩者都用過，用第二種舉例，大致是這樣的：

先構建並推送映象到映象倉庫

接著對映象部署

總結

本文先以 ASP.NET Core 為例講解了如何在 Azure 中實現持續整合操作，整體流程簡單方便，文件特別清晰，再一次為微軟Docs文件而歡呼。

後以 ASP.NET Core 為例講解了如何在 Azure 中實現持續部署操作，整體流程以持續整合為前提，一步步將我們的Code執行起來，真正意義上實現了自動化操作。

Source Link：
https://docs.microsoft.com/zh...
https://devblogs.microsoft.co...

Github：
https://github.com/anjoy8/Blo...