.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