注：本文中主要討論 .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: truepool: 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: |Dockerfiledapr.yamlTargetFolder: '$(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 環境的話有更多做法。

總結

以上是生活随笔為你收集整理的Azure DevOps 中 Dapr项目自动部署流程实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。