.NET項目在k8s中運行的Dapr持續(xù)集成流程
注:本文中主要討論 .NET6.0項目在 k8s 中運行的 Dapr 的持續(xù)集成流程, 但實際上不是Dapr的項目部署到K8s也是相同流程,只是k8s的yaml配置文件有所不同
流程選擇
基于 Dapr 的項目持續(xù)集成包含以下流程
- 編譯并打包項目
- 構(gòu)建 Dockerfile,并推送鏡像
push image至私有倉庫 - 準備 k8s 部署的配置文件
- 通過 kubectl 部署鏡像至 k8s 中
這里面有多種方案
| - | Pipeline的操作 | Publish的操作 | 優(yōu)點 | 缺點 |
|---|---|---|---|---|
| 1. 直接BuildImage并發(fā)布 | 1. 直接使用 Docker Build Image 2. push image 3.復(fù)制Yaml至Artifacts | K8s 直接發(fā)布 對應(yīng)版本的yaml + 指定Image | 直接,操作簡單 | 1. 產(chǎn)生大量不必要的Image 2.持續(xù)集成消耗時間較長3.每次持續(xù)集成都有Image產(chǎn)生 |
| 2. Publish時再進行Build | 1. 僅 dotnet publish zip | 1. Build Image / Push Image (可選 )2. K8S 部署+指定Image | 單次部署減慢,多次增快 | 部署過程會比直接接取鏡像慢 |
| 3. 僅發(fā)布 Zip,并Build一個使用Volume的專署鏡像 | 僅 dotnet publish zip | 使用編譯好的鏡像修改Volume參數(shù) | 快 | 跨環(huán)境部署時會導(dǎo)致對于文件系統(tǒng)依賴過重 |
鑒于以上優(yōu)缺點,最終我選擇了第二種折衷方案,這種方案既不影響持續(xù)集成的速度,也不會產(chǎn)生過多的鏡像,只是在部署時會產(chǎn)生多余的鏡像構(gòu)建時間。
項目結(jié)構(gòu)
每個要發(fā)布的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 持續(xù)集成的配置文件
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'
## 復(fù)制上文中的兩個文件到 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 發(fā)布流程配置文件
發(fā)布流程新建兩個作業(yè)

作業(yè)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)'
作業(yè)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)'
這樣,在首次部署時執(zhí)行全部管道。

后期回滾版本只,手動執(zhí)行第二個管理即KubeDeploy即可

其它流程
本流程全部依賴 Azure DevOps 自身的配置,并不依賴 Agent 環(huán)境配置,如果依賴 Agent 環(huán)境的話有更多做法。
以上就是.NET項目在k8s中運行的Dapr持續(xù)集成流程的詳細內(nèi)容,更多關(guān)于.NET在k8s運行Dapr持續(xù)集成的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
.net程序開發(fā)IOC控制反轉(zhuǎn)和DI依賴注入詳解
這篇文章主要為大家介紹了.net程序開發(fā)IOC控制反轉(zhuǎn)和DI依賴注入示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-11-11

