歡迎光臨
每天分享高質量文章

ASP.NET Core應用程式容器化、持續集成與Kubernetes集群部署(三

在上文ASP.NET Core應用程式容器化、持續集成與Kubernetes集群部署(二)中,我介紹瞭如何使用Azure DevOps為ASP.NET Core應用程式案例:tasklist搭建持續集成環境。在持續集成的過程中,Azure DevOps的Build Pipeline會下載tasklist的原始碼,使用Docker容器環境進行專案構建,將構建的容器鏡像推送到Docker Hub,並將原始碼庫中的yml檔案複製到構建生成目錄(Build Artifacts),以備持續部署時使用。今天,我打算介紹一下基於Azure Kubernetes Service和Azure DevOps的部署過程,本章節結束後,你可以看到我們的tasklist已在Kubernetes集群中運行。

強烈建議在閱讀本文前,先對上兩篇文章做一個大致的瞭解,然後閱讀tasklist原始碼庫,因為tasklist原始碼庫展示的是一個完整的案例。

好吧,既然介紹Kubernetes部署,就離不開這兩個概念:Kubernetes與Azure Kubernetes Service。Kubernetes(k8s)是Google開源的容器編排集群系統,可以讓一個或一組容器運行在集群環境,從而使基於容器的應用程式獲得可伸縮與高可用的特性。Kubernetes使用Go語言實現,它有一個實驗性的版本,叫Minikube。Minikube是一個只包含一個節點的Kubernetes集群,可以在Windows、Linux等多平臺中部署Minikube,部署過程也相對簡單,因此,如果是用於學習或者一些簡單的實驗,可以選擇Minikube。在Kubernetes集群運行起來後,就可以使用Kubectl命令列客戶端對集群進行管理。

如果是自己部署生產級別的Kubernetes集群的話,配置過程會相對比較複雜,此外,由於Kubernetes是Google的專案,有很多配置部署的腳本以及二進制檔案都是使用Google的CDN進行分發,國內是無法訪問這些資源的,所以,我還是建議大家使用托管的Kubernetes服務,比如Azure的Azure Kubernetes Service(AKS),這樣可以省去繁雜的配置過程,而且還可以根據自己的需要來決定Kubernetes集群的體量,非常方便。

Azure Container Service為容器化的應用程式的運行提供了容器集群環境,它支持三種不同的容器編排器(container orchestrator):Docker Swarm、基於DC/OS的Marathon服務,以及大家熟知的Kubernetes,也就是今天我打算介紹的Azure Kubernetes Service。大家如果有興趣的話,也不妨瞭解一下Docker Swarm和DC/OS Marathon。

據我所知,目前Azure中國區版沒有官方的AKS服務,網上也有一些資料,幫助讀者在Azure中國區版中部署Kubernetes集群,但是過程也相對比較繁雜。在這裡,我會使用Azure國際版進行介紹。

首先,登錄Azure國際版,點擊Create a resource按鈕,在新建資源的串列中輸入Kubernetes進行搜索,在搜索結果中點擊Kubernetes Service選項:

在Create Kubernetes Cluster頁面中,進入Basics標簽頁,然後填寫以下信息:

  • Subscription:選擇你的Azure訂閱
  • Resource Group:為Kubernetes集群選擇一個Azure的資源組(Resource Group),之後為Kubernetes創建的所有資源都會被劃入該資源組中,便於管理。你也可以點擊Create new按鈕新建一個資源組
  • Kubernetes cluster name:新創建的Kubernetes集群的名稱
  • Region:創建資源所屬的Region
  • Kubernetes version:Kubernetes的版本,選擇預設的即可
  • DNS name prefix:所創建集群的DNS名稱前綴
  • Node size:集群中每個節點的虛擬機配置,可以根據自己的實際情況進行選擇,當然,配置越高費用也越高。這裡我只選擇Standard B2s,一個月40美金的樣子
  • Node count:集群中的節點個數,為了演示,我選擇2個節點,於是,Node size * Node count,費用大概一個月80美金的樣子

為了演示tasklist專案的K8S部署,我選擇瞭如下的配置:

在這個頁面中還可以選擇針對認證、網絡、監控等方面的高級設置,我就不一一介紹了,官方網站的文件中都有詳細說明。現在直接點擊Review + create按鈕,在Azure完成了對配置信息的校驗之後,就可以點擊Create按鈕創建集群了。

創建成功後,就可以在Azure的站點中找到剛剛創建好的Kubernetes集群了。在集群的管理頁面上,點擊View Kubernetes dashboard鏈接,此時會打開一個邊窗,列出連接Kubernetes集群的操作步驟。接下來,按照步驟一步步地安裝kubectl命令列,並通過Azure的命令列打開Kubernetes的儀錶盤。

  1. 首先確保已經安裝Azure命令列工具(Azure CLI)2.0.27或以上版本,有關Azure CLI的安裝,可以參考:https://docs.microsoft.com/zh-cn/cli/azure/install-azure-cli?view=azure-cli-latest
  2. 使用以下命令安裝kubectl命令列工具:
  3. Kubectl工具安裝完成之後,可以將kubectl的路徑添加到PATH環境變數中,方便今後使用。然後,執行下麵的命令,以下載集群的登錄連接憑證:

    1

    az aks get-credentials --resource-group --name

    此處表示在創建Kubernetes集群時指定的資源組名稱,則是創建集群時指定的Kubernetes集群名稱

  4. 執行以下命令,即可打開Kubernetes集群的儀錶盤(Dashboard),其中引數如上所述:

    1

    az aks browse --resource-group --name

在完成上述步驟之後,可以看到Dashboard被正常打開:


目前除了kubernetes服務之外,沒有部署任何其它的組件。除了使用Dashboard,我們也可以使用kubectl命令列工具,比如,通過以下命令查看已經部署的服務:

接下來,讓我們一起看看如何將由Azure DevOps構建好的tasklist應用程式容器部署到這個Kubernetes集群中。

在前一篇文章中,我們已經將構建生成的容器鏡像推送到Docker Hub中,並將用於部署的yml檔案複製到了構建輸出目錄。簡便起見,我已經將yml檔案儲存到了代碼庫中,在tasklist的代碼庫中,目前有三個yml檔案:docker-compose.pki.yml,docker-compose.yml以及k8s.deployment.yml。前兩個檔案都是用於構建或者運行容器的(docker-compose.pki.yml檔案是我私人使用的,這裡可以忽略),只有k8s.deployment.yml才是真正用來實現部署的。接下來,我們將使用這個k8s.deployment.yml,將tasklist容器部署到Kubernetes集群中。

Compose?Kompose?

在Kubernetes上部署容器應用,需要使用YAML格式的配置檔案,然後使用kubectl apply命令實現部署。通過閱讀官方網站的文件,你會發現其實編寫這些YAML檔案還是有一定工作量的。對於tasklist案例,我使用Google官方的Kompose命令列工具,它可以很方便地將Docker Compose檔案轉為Kubernetes的部署檔案。官方的解釋就是:Kubernetes + Compose = Kompose。不過可惜的是,Kompose的網站在國內是打不開的,不過可以通過Kompose的代碼庫來瞭解這個工具。tasklist所使用的k8s.deployment.yml檔案,正是通過Kompose生成的,不過我也基於自己的需要進行了一些簡單的定製。

在Azure Pipeline中創建部署任務

打開Azure DevOps管理界面,選擇我們在上一講中創建的tasklist-demo專案,然後,在Pipelines下選擇Releases,然後點擊New pipeline按鈕,新建一個Release Pipeline。

然後,在Select a template頁面,選擇Deploy to a Kubernetes cluster模板,點擊Apply按鈕使用該模板:

在Stage的配置中,填入Stage的名稱:

回到All pipelines的配置界面,首先為我們的部署任務起個名字,然後,點擊Add an artifact選項,將之前持續集成的輸出結果檔案,也就是用於k8s部署的YAML檔案作為Release Pipeline的輸入,添加到Artifacts中。在Add an artifact界面中,我們選擇Build型別,表示要使用構建的輸出結果,然後,Source選擇Build Pipeline的名稱,也就是tasklist-demo,其它選項可以預設。當然,你也可以根據自己專案的需求對這些預設的設置進行更改,不過,在此也就不多介紹了。一切設置好之後,點擊Add按鈕,將Artifact加入Release Pipeline。

之後,點擊創建好的K8S Deployment stage,在Agent job串列中,選擇kubectl apply,表示我們需要更改一個Kubernetes的集群,然後,在右邊的Deploy to Kubernetes界面中,進行如下設置:

  1. Display name:當前任務的名稱,隨便起一個有意義的名字就行了
  2. Kubernetes service connection:選擇所需部署的k8s集群的連接信息。目前我們沒有可用的連接,所以需要創建一個。點擊New按鈕即可創建:
  3. 回到Deploy to Kubernetes頁面,此時Kubernetes service connection會自動選中剛剛所創建的Kubernetes連接
  4. 勾選Use Configuration file複選框,在Configuration file文本框右邊點擊省略號按鈕:
  5. 在Select a file or folder對話框中,選擇k8s.deployment.yml。還記得上面我們選擇Build作為Artifact的型別嗎?這個k8s.deployment.yml就是從那邊複製過來的:
  6. 對於其它的配置選項,我們暫且使用預設值,然後點擊Save按鈕,儲存我們的Release Pipeline設置

觸發部署事件

在成功創建了Azure Kubernetes集群,併在Azure DevOps Pipeline中創建了Release Pipeline之後,就可以嘗試將我們的tasklist應用部署到AKS了。回到Pipelines\Releases界面,選擇剛剛新建的Pipeline,然後點擊Release下拉選單,選擇Create a release選項:

在Create a new release頁面中,指定所需部署的編譯版本,然後填入一些描述信息後,點擊Create按鈕,即可手工觸發部署。

成功部署之後,會在Release Pipeline的K8S Deployment stage上顯示出狀態:

點擊Logs按鈕,可以查看詳細的部署信息。事實上,通過編輯K8S Deployment stage的設置,還可以選擇部署執行的觸發條件,比如,是僅通過手工觸發,還是在每次release之後觸發,還可以設置觸發時間以及通過Pull Request創建觸發等,限於文章篇幅,這裡就不多介紹了。對這部分有需求的讀者請根據自己的實際情況自行設置。

現在回到命令列,通過kubectl get po命令,可以看到,我們的容器已經正常運行:

通過kubectl get svc命令,可以看到我們已經部署在Kubernetes集群中的服務:

在上面的服務串列中可以看到,tasklist-web服務的型別是LoadBalancer,也就是這個服務會有一個公網可訪問的IP地址。這個IP地址就是104.211.50.78。現在打開瀏覽器,直接訪問這個IP地址,可以看到,我們的tasklist已經成功運行在Azure Kubernetes集群中:

還可以使用下麵的命令對tasklist的ASP.NET Core應用程式(也就是後端)進行伸縮:

然後看看執行後有多少個Pods在運行:

本文是有關ASP.NET Core應用程式容器化以及Azure DevOps持續集成、持續部署和Azure Kubernetes Service部署相關內容介紹的最後一篇文章。在這個系列中,我們首先介紹了ASP.NET Core應用程式容器化所需註意的要點,然後介紹了基於容器開發與部署的CI/CD流程,之後包含了有關在Azure DevOps中創建持續集成和持續部署任務的內容,然後是在Azure Kubernetes集群中部署我們的應用程式。相關內容還是比較多的,因此,也無法在這個系列文章中一一介紹完。對於這方面技術感興趣的讀者,我仍然推薦閱讀tasklist的原始碼庫,因為它是一個完整的案例,它涵蓋了一個ASP.NET Core應用程式容器化之路的各個方面。在今後的文章中,我還會對DevOps以及代碼庫分支策略等內容進行介紹,歡迎廣大讀者閱讀討論。

原文地址:http://sunnycoding.cn/2018/10/26/dockerize-aspnetcore-cicd-with-azure-devops-and-kubernetes-part3/

赞(0)

分享創造快樂