tencent cloud

Feedback

Quick Implementation of Container DevOps in TKE Using CODING

Last updated: 2022-06-14 17:35:08

    Overview

    DevOps, a combination of development and operations, is becoming more and more popular among enterprises. It represents a culture that values the communication and collaboration between software developers (Dev) and IT Ops technicians (Ops). DevOps aims to make the process of software building, testing, and release faster, more frequent, and more reliable by automating the software delivery and architecture change processes. It can enable agile development in the cloud-native era. This document describes TKE DevOps for cloud native, where a seamless DevOps pipeline is established from the automatic image build triggered by code committing to the subsequent automatic deployment and update of applications in TKE clusters.

    TKE DevOps

    Overview

    TKE DevOps is an integration of Tencent Kubernetes Engine (TKE), Tencent Container Registry (TCR), and CODING DevOps. It's a one-stop cloud-native service featuring automated code compilation, container image build, image push, and application deployment for container use cases.

    Business process

    TKE DevOps is a lifecycle management scheme that automates everything from code update to application deployment and update. Its business process is as shown below:
    process

    Prerequisites

    • You have created a TKE test cluster as instructed in Quickly Creating a Standard Cluster.
    • You have activated the TCR service, created accessible TCR test instances, and generated test instance access credentials. You need TCR Enterprise Standard Edition or Premium Edition to support cloud-native delivery workflows. For more information, see Billing Overview. For more information on the available regions of TCR, see Billing Overview.
    • You have activated the CODING DevOps service and built a well-established CODING DevOps team. If you are using a sub-account, you must have quickly created a sub-account with the operation permissions for the instance in the CODING DevOps console by using your root account, or have granted the sub-account such permissions as instructed in Cloud Access Management.

      Directions

    TKE DevOps provides a powerful cloud-native DevOps service. This document describes how it automates the entire process from source code update to business release.

    Accessing TKE DevOps

    Log in to the TKE console, click DevOps on the left sidebar, and click Use Now .

    Configuring code hosting

    Create a test project and test code repository on the CODING team homepage. For more information on CODING code hosting, see Code Hosting.

    Creating build plan

    1. Log in to CODING DevOps and select Project on the left sidebar.
    2. On the Project Management page, click the name of the created test project to enter its details page.
    3. On the left sidebar, click Continuous Integration > Build Plan > Create Build Plan to enter the Select Build Plan Template page.
      Note:

      A build plan is the basic unit of continuous integration and can be created quickly from a template. For more information, see Continuous Integration Quick Start.

    4. Select the Build image and push it to TCR Enterprise Edition template to quickly create a plan .
      Select the code source to be checked out and configure TCR access credential environment variables according to the build plan template. You can preview the generated Jenkinsfile on the right as shown below:
      Note:

      CODING DevOps and TCR instances are connected and images are pushed over the private network by default, which requires no extra configuration.
      For a build project generated by using the template, you can customize its details by selecting the target project on the build plan details page and clicking Set on the project details page .

    • Basic Info allows you to select basic configuration items such as code source and node pool. For more information on node pools, see Building Node.
    • Process Configuration allows you to configure the environment for running build tasks. For more information, see Building Environment.
    • Trigger Rule allows you to configure trigger rules for a build plan that can be triggered in multiple ways. For more information, see Trigger Rule.
    • Variables and Cache list environment variables and cache configuration items. For more information, see Environment Variables and Cache Directories.
    • Notification allows notifications to be sent to specific CODING team members when a build plan is completed.
    1. Click OK.
    2. (Optional) Click Project Configuration > Developer Options > Webhook > Create Webhook to push event notifications to WeCom and other instant messaging platforms as instructed in Webhook and Binding WeCom Group Bot. For more information on CODING continuous integration, see Continuous Integration.

    Creating continuous deployment

    1. Log in to CODING DevOps and select Project on the left sidebar.
    2. On the Project Management page, click the name of the created test project to enter its details page.
    3. On the left sidebar, select Continuous Deployment > Kubernetes and click Configure Now.
    4. On the Deployment Console page, select the cloud account to be configured. Then, you can proceed to subsequent steps such as configuring applications and processes, associating projects and applications, and starting deployment.

    Configuring cloud account

    Select a cloud account type as instructed in Cloud Account. Configure the cloud account for accessing resources in the cloud. You can select a TKE or Kubernetes account. This document uses Kubernetes as an example to describe how to configure a cloud account.

    1. On the Kubernetes-Based Continuous Deployment page, click Configure Now.
    2. On the Cloud Account Management page, click Bind Cloud Account on the right.
    3. On the Bind Cloud Account page, select Kubernetes and other items as needed .
    4. Click OK.

    Configuring application and process

    For more information on CODING applications and projects, see Applications and Projects and Process Configuration. This document describes key configuration items to configure applications and processes.

    1. When creating an application, select Kubernetes (TKE) Deployment as the deployment method.
    2. When you create a deployment process in the new application, select the Kubernetes process template and then select the template process as needed. Here, the Deploy Deployment and Service to Kubernetes cluster process is used as an example.
    3. When you configure the deployment process in Deployment Process, associate the TCR image artifact generated in the previous continuous integration step under Enable Required Artifact.
    4. On the Automatic Trigger page, bind the TCR image artifact. When a new version of an image is built successfully, the deployment process will be triggered automatically. The configuration method is.
    5. The Deployment and Service are configured in a similar way, that is, adding a cloud account with deployment permission and entering a custom Manifest, that is, the deployment YAML template.
      This document describes how to manually configure TKE to pull access credentials for a TCR private repository image and customize the Deployment YAML. Below is a sample:
      Note:

      In the sample, a simple Deployment YAML is used for the Kubernetes cluster, along with the default RollingUpdate policy. In practice, you can leverage Nginx-ingress, Istio, and other tools to configure more advanced update policies, such as blue-green deployment, canary release, and A/B testing. For more information, see Blue-Green Deployment, Nginx-ingress for Automated Grayscale Release, and Continuous Deployment + TKE Mesh Grayscale 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: devops-app
            ports:
              - containerPort: 5000
        imagePullSecrets:  # Credential configuration for accessing the private repository 
          - name: tcr-secret # Access credential secret
      

    Here, the image address field of spec.template.spec.containers.*.image is included in CODING's conversion matching rules, which are described in Binding Artifact in Manifest.

    Note:

    TKE pulls a TCR private repository image in two ways:

    Below is a sample 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
    
    1. (Optional) Configure custom event notifications for each deployment stage, so that you can be informed of the deployment process. This document describes the WeCom notification mode. For more information on how to get the Webhook URL of the WeCom bot, see Creating WeCom Group Bot.

    Associating project and application

    For more information on associating projects and applications, see Project and Application Association.

    Starting deployment

    For release by a posting order and its configuration, see Creating Posting Order. For more information on CODING continuous deployment, see Continuous Deployment.

    Testing and Verification

    In the project code file, add the v2 API code as shown below and commit the master branch:

    The build plan in Continuous Integration uses the automatic execution upon code update event trigger configuration. For more information on the trigger configuration, see Trigger Rule. When the modified code is committed, the associated build plan will be automatically triggered.
    If WeCom Webhook notifications are configured for continuous integration, WeCom will also receive the notifications.
    When you generate a Docker image artifact in the build plan, the associated continuous deployment process will be triggered to update the new image application to the TKE cluster.
    If the deployment process is configured with WeCom notifications, WeCom will be notified upon the deployment task completion.
    At this point, you can see that the workload has been successfully updated in TKE as shown below:
    image-20201028214913813
    The test and verification results show that the entire DevOps process from source code update to business release is implemented in TKE.

    Contact Us

    Contact our sales team or business advisors to help your business.

    Technical Support

    Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

    7x24 Phone Support