本文小编为大家详细介绍“.net项目在k8s中运行的Dapr持续集成方法”,内容详细,步骤清晰,细节处理妥当,希望这篇“.NET项目在k8s中运行的Dapr持续集成方法”文章能帮助大家解决疑惑,下面跟着小编的思路慢慢深入,一起来学习新知识吧
本文小编为大家详细介绍“.net项目在k8s中运行的Dapr持续集成方法”,内容详细,步骤清晰,细节处理妥当,希望这篇“.NET项目在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
kind: DeploymentapiVersion: apps/v1metadata: name: demo namespace: dapr-api labels: app: .api service: demospec: 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: ServiceapiVersion: v1metadata: name: demo-api namespace: dapr-api labels: app: .api service: demospec: type: nodePort selector: service: demo ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 30004
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS finalWORKDIR /appEXPOSE 80COPY ["./projectfolder", "/app"]ENTRYPOINT ["dotnet", "projectdll.dll"]
这两个文件需要每个项目不同,后面在编译和部署流程中会用到。
trigger: batch: truepool: name: Defaultname: $(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)'
发布流程新建两个作业
作业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
即可
读到这里,这篇“.NET项目在k8s中运行的Dapr持续集成方法”文章已经介绍完毕,想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会,如果想了解更多相关内容的文章,欢迎关注编程网精选频道。
--结束END--
本文标题: .NET项目在k8s中运行的Dapr持续集成方法
本文链接: https://www.lsjlt.com/news/326229.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0