本文中主要討論 .NET6.0項目在 k8s 中運行的 Dapr 的持續集成流程 ...
註:本文中主要討論 .NET6.0項目在 k8s 中運行的 Dapr 的持續集成流程, 但實際上不是Dapr的項目部署到K8s也是相同流程,只是k8s的yaml配置文件有所不同
流程選擇
基於 Dapr 的項目持續集成包含以下流程
- 編譯並打包項目
- 構建 Dockerfile,並推送鏡像
push image
至私有倉庫 - 準備 k8s 部署的配置文件
- 通過 kubectl 部署鏡像至 k8s 中
這裡面有多種方案
- | Pipeline的操作 | Publish的操作 | 優點 | 缺點 |
---|---|---|---|---|
1. 直接BuildImage併發布 | 1. 直接使用 Docker Build Image 2. push image 3.複製Yaml至Artifacts | K8s 直接發佈 對應版本的yaml + 指定Image | 直接,操作簡單 | 1. 產生大量不必要的Image 2.持續集成消耗時間較長3.每次持續集成都有Image產生 |
2. Publish時再進行Build | 1. 僅 dotnet publish zip | 1. Build Image / Push Image (可選 )2. K8S 部署+指定Image | 單次部署減慢,多次增快 | 部署過程會比直接接取鏡像慢 |
3. 僅發佈 Zip,並Build一個使用Volume的專署鏡像 | 僅 dotnet publish zip | 使用編譯好的鏡像修改Volume參數 | 快 | 跨環境部署時會導致對於文件系統依賴過重 |
鑒於以上優缺點,最終我選擇了第二種
折衷方案,這種方案既不影響持續集成的速度,也不會產生過多的鏡像,只是在部署時會產生多餘的鏡像構建時間。
項目結構
- 每個要發佈的API的 project 文件夾中增加以下文件
- dapr.yaml
- Dockerfile
dapr.yaml
kind: Deployment
apiVersion: apps/v1
metadata:
name: demo
namespace: dapr-api
labels:
app: .api
service: demo
spec:
replicas: 1
selector:
matchLabels:
service: demo
template:
metadata:
labels:
app: .api
service: demo
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "demo-api"
dapr.io/app-port: "80"
dapr.io/log-as-json: "true"
spec:
containers:
- name: demo-api
image: 倉庫地址/鏡像名:220310.13
ports:
- name: http
containerPort: 80
protocol: TCP
imagePullPolicy: IfNotPresent
---
kind: Service
apiVersion: v1
metadata:
name: demo-api
namespace: dapr-api
labels:
app: .api
service: demo
spec:
type: NodePort
selector:
service: demo
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30004
Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS final
WORKDIR /app
EXPOSE 80
COPY ["./projectfolder", "/app"]
ENTRYPOINT ["dotnet", "projectdll.dll"]
這兩個文件需要每個項目不同,後面在編譯和部署流程中會用到。
Pipelines 持續集成的配置文件
trigger:
batch: true
pool:
name: Default
name: $(Date:yy)$(Date:MM)$(Date:dd)$(Rev:.r)
variables:
BuildConfiguration: 'Release'
steps:
- task: UseDotNet@2
displayName: 'Check and Install .NET SDK 6.0'
inputs:
version: '6.0.x'
includePreviewVersions: false
- task: DotNetCoreCLI@2
displayName: 'Publish to zip'
inputs:
command: publish
publishWebProjects: false
projects: './src/projectfolder/project.csproj'
arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory) -v n'
zipAfterPublish: false
workingDirectory: '$(Build.SourcesDirectory)/src'
## 複製上文中的兩個文件到 Artifact
- task: CopyFiles@2
displayName: 'Copy dapr.yaml to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: './src/${{ parameters.project }}/'
Contents: |
Dockerfile
dapr.yaml
TargetFolder: '$(build.artifactstagingdirectory)'
- task: PublishBuildArtifacts@1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
Release 發佈流程配置文件
發佈流程新建兩個作業
作業1 Build Image
variables:
image: '自定義鏡像名'
steps:
- task: Docker@2
displayName: buildAndPush
inputs:
containerRegistry: harbor
repository: '$(image)'
Dockerfile: '$(System.DefaultWorkingDirectory)/_dapr-demo/drop/Dockerfile'
tags: '$(Build.BuildNumber)'
作業2 KubeDeploy
variables:
image: '自定義鏡像名,與上文須一致'
steps:
- task: KubernetesManifest@0
displayName: deploy
inputs:
kubernetesServiceConnection: online
namespace: '$(ns)' ## k8s的部署目標命名空間
strategy: canary ## 灰度部署策略
percentage: 50
manifests: '$(System.DefaultWorkingDirectory)/_dapr-demo/drop/dapr.yaml'
containers: '$(harborUrl)/$(image):$(Build.BuildNumber)'
這樣,在首次部署時執行全部管道。
後期回滾版本只,手動執行第二個管理即KubeDeploy
即可
其它流程
本流程全部依賴 Azure DevOps 自身的配置,並不依賴 Agent 環境配置,如果依賴 Agent 環境的話有更多做法。
供大家學習參考,轉文章隨意--重典