Shulou(Shulou.com)06/01 Report--

This article Xiaobian for you to introduce in detail ".NET project running in K8s Dapr continuous integration method", detailed content, clear steps, details handled properly, I hope that this ".NET project running in K8s Dapr continuous integration method" article can help you solve doubts, following the editor's ideas slowly in-depth, together to learn new knowledge.

Note: this article mainly discusses the continuous integration process of Dapr running in K8s of .NET 6.0 project, but in fact, it is the same process for projects that are not Dapr to deploy to K8s, except that the yaml configuration file of K8s is different.

Process selection

Dapr-based project continuous integration includes the following processes

Compile and package the project

Build the Dockerfile and push the image push image to the private repository

Prepare the configuration file for k8s deployment

Deploy an image to k8s via kubectl

There are a variety of options.

The advantages and disadvantages of the operation of Pipeline Publish. Directly BuildImage and release 1. Use Docker Build Image 2. Push image 3 directly. Copy Yaml to ArtifactsK8s directly release the corresponding version of yaml + specify Image directly, the operation is simple 1. Produce a large number of unnecessary Image 2. Continuous integration takes a long time. Every time there is a continuous collection of Image in Chengdu to produce 2. Publish and then Build1. Only dotnet publish zip1. Build Image / Push Image (optional) 2. K8S deployment + specified Image single deployment slows down, and multiple faster deployments will be slower than accessing images directly. Only publish Zip and Build a dedicated image using Volume only dotnet publish zip uses the compiled image to modify Volume parameters. Fast cross-environment deployment results in over-reliance on the file system.

In view of the above advantages and disadvantages, I finally chose the second compromise, which does not affect the speed of continuous integration, nor will it generate too many images, but will only result in extra image build time during deployment.

Project structure

Add the following files to the project folder of each API to be published

Dapr.yaml

Dockerfile

Dapr.yamlkind: 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: warehouse address / image name: 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: 30004DockerfileFROM mcr.microsoft.com/dotnet/aspnet:6.0 AS finalWORKDIR / appEXPOSE 80COPY [. / projectfolder " "/ app"] ENTRYPOINT ["dotnet", "projectdll.dll"]

These two files need to be different for each project, which will be used later in the compilation and deployment process.

Configuration file for Pipelines continuous integration 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'## copy the above two files to 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 publishing process configuration file

Publish process create two new jobs

Job 1 Build Image

Variables: image: 'custom image name' steps:- task: Docker@2 displayName: buildAndPush inputs: containerRegistry: harbor repository:'$(image) 'Dockerfile:' $(System.DefaultWorkingDirectory) / _ dapr-demo/drop/Dockerfile' tags:'$(Build.BuildNumber)'

Job 2 KubeDeploy

Variables: image: 'custom image name, which must be consistent with the above' steps:- task: KubernetesManifest@0 displayName: deploy inputs: kubernetesServiceConnection: online namespace:'$(ns)'# # K8s deployment target namespace strategy: canary # # Grayscale deployment strategy percentage: 50 manifests:'$(System.DefaultWorkingDirectory) / _ dapr-demo/drop/dapr.yaml' containers:'$(harborUrl) / $(image): $(Build.BuildNumber)'

In this way, all pipes are executed on the first deployment.

Later rollback version can only be done by performing the second management manually, namely KubeDeploy.

After reading this, the article "Dapr continuous Integration method for .NET projects running in K8s" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself. If you want to know more about related articles, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.