An overview of the

More and more enterprises are adopting the concept of DevOps. DevOps is a combination of Development and Operations. IT represents a culture that values communication and collaboration between “software developers” and “IT Operations technicians”. It aims to make the process of building, testing, and releasing software faster, more frequently, and more reliably by automating the “software delivery” and “architecture change” processes. In the cloud native era, we need more Devops thinking to realize agile development. This article will introduce and practice the TKE container Devops service, which is designed for cloud native, and realize the automatic building of the image triggered from the code submission. When the image build is successful, the automatic deployment process is triggered to deploy and update the application to a seamless Devops pipeline in the TKE cluster.

Introduction to TKE Container DevOps

TKE container DevOps is a close combination of container service TKE, container image service TCR and CODING DevOps. It is oriented to container business scenarios and has functions such as automatic code compilation, container image building, image push and application deployment. Provide customers with a powerful one-stop cloud native DevOps service. For a quick start on container DevOps, refer to the TKE and Coding Collaborative Business Implementation Fast Iteration best Practices document.

TKE container DevOps business process

The TKE Container DevOps service manages the entire lifecycle of the application development and deployment process, automating everything from code updates to application deployment and updates, as shown below:

How to use TKE container DevOps

Operating scenarios

The TKE container Devops feature provides a powerful cloud native Devops service. Follow the above TKE container Devops business flowchart to automate the entire process from source update to business release.

The premise condition

  • Create a TKE test cluster

    Refer to the documentation on how to create the Deployment Container service TKE.

  • Enable the container image service TCR service

    An accessible TCR test instance has been created and the test instance access credentials have been generated. TCR requires enterprise standard or Advanced edition to support cloud native delivery workflow. For details, refer to the Container Image Service Purchase Guide. For current TCR support regions, refer to supported regions.

  • Launch the CODING DevOps service

    A Coding Devops team has been created and refined. If you want to use a subaccount to perform operations, use the primary account to quickly create a subuser on the CODING DevOps console or grant the subaccount the operation rights of the corresponding instance in advance.

steps

TKE container Devops access point

Click the “Devops” function link in the left functional menu bar of the TKE console to enter the “Devops” introduction interface, as shown in the picture below:

Click “Use Now” to jump to your team’s Coding home page to use DevOps related features.

Configuring code management

Create a test project and test code repository on the Coding team home page. For more information on Coding code hosting, see code hosting. The creation steps are as follows:

** Step 1: ** Create a test project on the Coding team home page [Projects], as shown below:

** Step 2: ** Click the created test project “test-Jokey” to enter the main page of the project, and create a test code warehouse in the “Code Warehouse” menu, as shown in the picture below:

Create a build plan

In the test project “test-Jokey” home page, create a build plan under the “Continuous Integration” submenu “Build Plan”. A build plan is the basic unit of continuous integration. You can quickly create a build plan by selecting the build Plan template.

** Step 1: ** Select the “Build image and Push to TCR Enterprise” template to quickly create a component plan, as shown in the following example:

** Step 2: ** Select the code source to check out and configure the environment variables related to TCR access credentials according to the build plan template. You can see the Jenkinsfile preview generated by the template on the right, as shown below:

Tip: Coding DevOPS and TCR instances are interoperable on the Intranet. Mirroring push uses Intranet transmission by default. No additional configuration is required.

For the build project generated with the build template, you can also customize the build details by clicking the [Settings] menu of the build project. The functions of the configuration page of the build plan are described as follows:

[Basic Information] : On the basic configuration page, you can select basic configurations, such as code sources and node pools. For details about node pools, see the document Building a Node.

Process Configuration: Configures the environment for running build tasks. For details, see Build Environment.

Trigger Rule: Used to configure the trigger rule for a build plan. A build plan can be triggered in various ways. For details, see Trigger Rule.

[Variables and cache] : Configure environment variables and cache. For details, see Environment Variables and cache directory.

Notification alerts: Notification alerts can be sent to designated Coding team members when the build schedule is completed.

In addition, you can create a new WebHook in [Project Configuration -> Developer Options -> WebHook] to push event notifications to instant messaging platforms such as enterprise wechat. For details, please refer to WebHook and bound enterprise wechat group robot. The configuration example is shown as follows:

For more details on Coding continuous integration, please refer to continuous Integration Introduction.

Creating a continuous deployment

In the “test-Jokey” main page of the test project, follow the steps in the “Continuous Integration” sub-menu [Kubernetes] to create the continuous deployment pipeline, as shown in the figure below:

Configuring a Cloud Account

Please refer to the cloud account documentation to add and configure cloud account information for accessing resources on the deployment cloud. You can select a cloud account of the Tencent Cloud TKE or Kubernetes type and enter relevant authentication configurations to add a cloud account. Here, you have selected the Kubernetes binding mode.

Configure applications and processes

For details about Coding applications and projects, please refer to the application and Project and Process Configuration document. Here is a brief description of the key configuration items in configuring applications and processes.

When creating an application, select Kubernetes(TKE) deployment:

When creating the Deployment process in the new application, select the [Kubernetes] process template, and then select the process under the template according to the actual needs. In this case, the second process in the following figure is selected, the process of deploying Deployment and Service to the Kubernets cluster:

When configuring the deployment process in deployment Process, the Start Required artifacts option associates the TCR warehouse image artifacts generated during the previous continuous integration process:

Use [automatic trigger] to bind the TCR warehouse image product. This is the key point. When a new version of the image is successfully built, the deployment process will be automatically triggered.

The next step is to configure the [Deployment] and [Deployment Service] Deployment phases, which are configured in a similar way by selecting the previously added cloud account with Deployment permission and filling in the custom Manifest, that is, the custom Deployment YAML template.

The following is an example of custom Deployment YAML:

Tip: About continuously deploying update policies

This example uses only a simple Deployment YAML to a Kubernetes cluster, using the default RollingUpdate policy. In fact, tools like Nginx-Ingress/Istio can be used to configure more advanced update policies such as blue-green release, Canary, A/B testing, etc. For details, see Blue and Green Release, NGINX-Ingress Automated Gray Release, Continuous Deployment + TKE Mesh Gray Release practice.

apiVersion: apps/v1 kind: Deployment metadata: name: devops-app spec: replicas: 2 selector: matchLabels: app: devops-app template: metadata: labels: app: devops-app spec: containers: - image: Xxx-test.tencentcloudcr.com/xxx-test/jokey-test # sample image address name: the conversation - app ports: - containerPort: 5000 imagePullSecrets: # private repository access credential configuration - name: tcr-secret # access credential secretCopy the code

Among them, for the spec. The template. The spec. Containers. *. The mirror image address field Coding there will be a conversion matching rules, instructions regarding transformation of matching rules refer to the document binding products in the manifest.

There are two ways for TKE to pull the TCR private warehouse image:

  • TKE mile-free TCR container image can be configured in the TCR support area. For details about the TCR support area, see supporting area. For details about how to configure TKE cluster using TCR plug-in internal mile-free TCR container image.
  • For details about how to manually configure TKE to pull the access credentials of the TCR private warehouse image, see the TKE Private Warehouse Access Configuration example.

Note: The Deployment YAML example above uses the “manually configure TKE to pull access credentials for the TCR private repository image” approach.

Example of a custom Service Manifest YAML:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: devops-svc
  name: devops-svc
spec:
  ports:
    - port: 5000
      protocol: TCP
  selector:
    app: devops-app
Copy the code

In addition, you can configure custom event notification (optional) for each stage of the deployment process to quickly and conveniently know the implementation of the deployment process. The enterprise wechat notification mode is configured here. For the method of obtaining the enterprise wechat Webook robot link, refer to creating enterprise wechat Group robot.

Associate projects and applications

For details about how to configure associated projects and applications, see the document Associated Projects and Applications.

The bill of lading issued

For details about how to use and configure the BILL of lading, see the document.

For more details on Coding continuous deployment, see continuous Deployment Introduction.

The validation test

Add the following v2 API code to the project code file and submit the master branch:

Because the build plan in Continuous Integration uses the event-triggered configuration of “automatically executed when code updates”, refer to the trigger rules to learn about the trigger configuration. When the modified code is committed, the associated build plan execution is automatically triggered:

If the enterprise wechat Webhook notification is configured for continuous integration, the enterprise wechat will also receive the corresponding instant notification message, as shown in the figure below:

When the build plan generates Docker image products, it will automatically trigger the associated [continuous deployment] process to update the new image application to the TKE cluster:

If the deployment process is configured with enterprise wechat notification, when the deployment process task is completed, the corresponding enterprise wechat deployment completion notification will be received, as shown in the figure below:

At this point, you can see in the TKE that the workload has been successfully updated:

As you can see from the test validation results, we implemented the entire DevOps process from source update to business release in TKE.

[Tencent cloud native] cloud said new, cloud research new technology, cloud travel new live, cloud appreciation information, scan the code to pay attention to the public number of the same name, timely access to more dry goods!!