Practice DevOps in TKE

Overview

The DevOps concept is adopted by more and more companies. DevOps is a combination of Development and Operations. It represents a culture that values communication and cooperation between "software developers (Dev)" and "IT operation and maintenance technicians (Ops)"; By automating the process of "software delivery" and "architecture change", the process of building, testing, and releasing software can be faster, more frequent and reliable. In the cloud-native era, we need Devops thinking to achieve agile development. This article will introduce and practice the TKE container DevOps service specially built for cloud-native. This will realize the automatic construction of the image from the trigger when the code is submitted, and then the automatic trigger when the image is successfully built. The deployment process deploys and updates the application to a set of seamless Devops pipelines in the TKE cluster.

Introduction to TKE Container DevOps

TKE DevOps container is a container service TKE , container mirroring service TCR and CODING DevOps closely integrated three service-oriented container business scenarios, with automatic compile the code, build container mirror, mirror push and application deployment capabilities to provide customers with a powerful one-stop Cloud-native DevOps service. For quick start of container DevOps, please refer to TKE and Coding collaborative business to achieve rapid iteration best practice document.

TKE container DevOps business process

The TKE container DevOps service runs through the entire life cycle management of the entire application development and deployment process, and realizes the automation from code update to application deployment and update, as shown in the following figure:

How to use TKE container DevOps

Operation scene

The TKE container Devops function provides a powerful cloud-native Devops service. The following will follow the above-mentioned TKE container Devops business flow chart to implement a complete set of automated processes from source code update to business release.

Precondition

Create TKE test cluster

Reference documentation on how to create a deployment container service TKE .
Open container mirror service TCR Service

An accessible TCR test instance has been created and test instance access credentials have been generated. TCR need to open Enterprise Standard or Advanced Edition supports native cloud delivery workflows, please refer to the container mirror service buying guide , please refer to the current TCR support regional support areas .
Open CODING DevOps service

The Coding Devops team has been created and improved. Such as the use of sub-account operation, using the master account in CODING DevOps create fast sub-user has permission or reference console sub-user permission settings operating authority granted in advance corresponding instances of the sub-account.

Steps

TKE container Devops access entrance

Click the [Devops] function link in the function menu bar on the left side of the TKE console to enter the [Container Devops] introduction interface, as shown below:

Click [Use Now] to jump to the main Coding page of your team to use the relevant DevOps functions.

Configure code hosting

Create a test project and test code warehouses Coding team home page, the code is hosted on Coding description please refer to code hosting presentation . The creation steps are as follows:

Step 1: Create a test project in the main page of the Coding team [Project], as shown in the following figure:

Step 2: Click the created test project "test-jokey" to enter the main page of the project, and create a new test code repository in the [Code Repository] menu, as shown in the figure below:

Create a build plan

Create a build plan in the submenu [Build Plan] of the [Continuous Integration] menu on the left side of the main page of the test project "test-jokey". The build plan is the basic unit of continuous integration. You can quickly create a build plan by selecting the build plan template. For details, please refer to the documentation start fast continuous integration .

Step 1: Select the "build image and push to TCR Enterprise Edition" template to quickly create a component plan, the creation example is as follows:

Step 2: According to the build plan template, select the code source to be checked out and configure the environment variables related to TCR access credentials. On the right, you can see a preview of the Jenkinsfile generated by the template, as shown in the figure below:

Tip: Coding devops and TCR instances can communicate with each other in the intranet. The mirror push uses intranet transmission by default, and no additional configuration is required.

For the build project generated using the build template, you can also customize the build details by clicking the [Settings] menu of the build project. The function description of the build plan configuration page is as follows:

[Basic information] : Basic Configuration page to select the source codes and other basic configuration node pool, the pool of nodes instructions refer to the documentation building node .

[Process] Configuration : used to configure the task of running the build environment, the instructions refer to the build environment .

[Trigger] rule : to set the rules of the scheme to build triggers that can support a variety of ways to trigger the build plan, the instructions refer to the rule is triggered .

[] Variables and cache : cache environment variables and configuration instructions refer to the environment variables and cache directory .

[Notification reminder] : When the construction plan is completed, a notification reminder can be sent to the designated Coding team members.

Also can [configuration items -> Developer Options -> WebHook] in New WebHook way event notifications pushed to the corporate micro letters and other instant messaging platforms, please refer to WebHook and binding corporate micro-channel group robot , configuration examples below:

To learn more about Coding of Continuous Integration details please refer to the continuous integration introduced .

Create continuous deployment

In the submenu [Kubernetes] of the [Continuous Integration] menu on the left side of the test project "test-jokey" main page, follow the steps to guide the creation of a continuous deployment pipeline, as shown in the following figure:

Configure cloud account

Refer to the cloud account documentation to add access to the cloud account information resources on the configuration of the deployment of the cloud, you can select [Tencent cloud TKE] or [Kubernetes] type of cloud account, enter the relevant authentication configuration add cloud account, here select the [Kubernetes] way tie set.

Configure applications and processes

About Coding application and project-related information, refer to documentation application and project and process configuration , there is only a brief description key configuration items in the configuration applications and processes during the next.

When creating an application, you need to check the [Kubernetes (TKE) deployment] method:

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

When configuring the deployment process in the [Deployment Process], the [Start Required Products] option associates the TCR warehouse mirror products generated in the previous continuous integration link:

Use [Auto Trigger] to bind TCR warehouse mirror products. Here is the key point. When a new version of the mirror is successfully built, the deployment process will be automatically triggered. The configuration method is as follows:

The next step is to configure the [Deployment Deployment] and [Deploy Service] deployment phases. The configuration methods of the two phases are similar. Select the cloud account with deployment permission added before and fill in the custom Manifest, which is the custom deployment YAML template.

Examples of custom Deployment YAML are as follows:

Tip: Regarding continuous deployment update strategy

This example only uses a simple Deployment YAML to deploy to the Kubernetes cluster, and uses the default rolling update (RollingUpdate) update strategy. In fact, you can help Nginx-ingress / Istio more advanced tools such as configuration update policy, such as blue-green publishing, canary, A / B testing, please refer to the specific use of blue-green publishing , Nginx-gray Ingress automation 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  # 示例镜像地址
          name: devops-app
          ports:
            - containerPort: 5000
      imagePullSecrets:  # 私有仓库访问凭证配置 
        - name: tcr-secret # 访问凭证 secret

Among them, for spec.template.spec.containers.*.imagemirroring the address field of Coding there will be a conversion rule matches, the matching description of the conversion rules, refer to the document binding products in the manifest .

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

In the TCR can be configured to support regional TKE pulled tight TCR-free container mirror, on TCR support area please refer to the support area , refer to the documentation on how to configure the TKE cluster using the net-free within the TCR plug pulled tight container mirror .
Manually configure TKE to pull the access credentials of the TCR private warehouse mirror. For the configuration method, please refer to the TKE configuration private warehouse access example .

Note: The Deployment YAML example above uses the method of "Manually configure TKE to pull the access credentials of the TCR private warehouse image".

Customized Service Manifest YAML example:

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

Method may additionally for each stage of the configuration of the deployment process custom event notification (optional), so convenient informed of the deployment process implementation, here configured enterprise micro-channel notification method of accessing the micro-channel Webook robot links refer to create an enterprise micro letter Group of robots .

Associated projects and applications

Related projects and application configuration please refer to the documentation application and related projects .

Bill of lading issuance

Bill of lading issued to use and configure, please refer to the documentation new single release .

For more details about the ongoing deployment of Coding refer to the continued deployment of introduction .

Test verification

Submit the master branch after modifying and adding the following v2 API code in the project code file:

Because [in] continuous integration build plan to use the event "is automatically executed when the code update" trigger configuration, understand the relevant trigger configuration please refer to trigger the rule . When the modified code is submitted, the execution of the associated build plan 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 following figure:

When the build plan generates a Docker image product, it will automatically trigger the associated [Continuous Deployment] process to update the new image application to the TKE cluster:

If the deployment process has configured corporate WeChat notification, when the deployment process task is completed, you will receive the corresponding corporate WeChat deployment completion notification, as shown in the following figure:

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

It can be seen from the test verification results that we have implemented the entire DevOps process from source code update to business release in TKE.

Practice DevOps in Tencent Cloud Container Service TKE