注：本文中主要讨论 .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
`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
Original: https://www.cnblogs.com/chsword/p/ci_dapr_net6.html
Author: 重典
Title: Azure DevOps 中 Dapr项目自动部署流程实践
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/551397/
转载文章受原作者版权保护。转载请注明原作者出处！