当前位置 : 主页 > 网络编程 > ASP >

.NET项目在k8s中运行的Dapr持续集成流程

来源:互联网 收集:自由互联 发布时间:2023-01-30
目录 流程选择 项目结构 dapr.yaml Dockerfile Pipelines 持续集成的配置文件 Release 发布流程配置文件 其它流程 注:本文中主要讨论 .NET6.0项目在 k8s 中运行的 Dapr 的持续集成流程, 但实际上不
目录
  • 流程选择
  • 项目结构
    • dapr.yaml
    • Dockerfile
  • Pipelines 持续集成的配置文件
    • Release 发布流程配置文件
      • 其它流程

        注:本文中主要讨论 .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至ArtifactsK8s 直接发布 对应版本的yaml + 指定Image直接,操作简单1. 产生大量不必要的Image 2.持续集成消耗时间较长3.每次持续集成都有Image产生2. Publish时再进行Build1. 仅 dotnet publish zip1. 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: 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'
        ## 复制上文中的两个文件到 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 发布流程配置文件

        发布流程新建两个作业

        作业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 环境的话有更多做法。

        以上就是.NET项目在k8s中运行的Dapr持续集成流程的详细内容,更多关于.NET在k8s运行Dapr持续集成的资料请关注自由互联其它相关文章!

        网友评论