Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to easily implement container DevOps using the container mirroring service TCR. Many people may not know much about it. In order to make you understand better, the editor summarizes the following contents. I hope you can learn something from this article.

Overview

When you deploy business services using container services provided by cloud vendors, do you have a higher requirement for delivering and deploying full links, such as implementing container-based DevOps services, automatically building images and updating the image version of containers in the cluster? Tencent Cloud Container Image Service TCR provides cloud native application delivery pipeline features, which are traceable, observable and independently configurable, so that users can easily trigger the construction and push of the image after code submission changes, and update the image to the cluster created by CCS TKE, elastic CCS EKS and other platforms to complete the final delivery. Provide enterprise users with an integrated cloud native DevOps solution on Tencent Cloud. This article mainly introduces how to easily implement container DevOps using container image service TCR.

Brief introduction of Container Image Service

Container Image Service (Tencent Container Registry,TCR) is a secure, high-performance container image hosting and distribution service provided by Tencent Cloud, which supports Docker images, Helm Chart storage distribution and image security scanning, and provides enterprise customers with fine-grained access management and network access control.

Container DevOps business process

DevOps is a combination of Development and Operations, representing a culture that values communication and cooperation between "software developers (Dev)" and "IT operation and maintenance technicians (Ops)"; it aims to automate the process of "software delivery" and "architecture change" to make the process of building, testing, and releasing software faster, more frequent and more reliable. TCR integrates seamlessly with container service TKE, CODING DevOps and other products to provide an integrated cloud native DevOps solution on Tencent Cloud. The basic business process of container DevOps is shown in the figure.

How to easily implement container DevOps prerequisites using container mirroring service

Prepare the instance of TCR Enterprise Edition and create an image repository.

Go to the instance list page, create a new enterprise instance, and create an image repository in the generated instance.

Prepare the TKE standard cluster and deploy container applications

Go to the CCS console and create a new TKE standard cluster. For more information, please see the documentation to create a cluster.

Currently, CCS TKE supports selecting CCS TCR Enterprise Edition image in the console to create workload. At the same time, TKE standard clusters can install TCR plug-ins to achieve private network and secret-free pull of TCR enterprise edition images. For reference documents, use the container images in TCR enterprise edition instances to create workloads.

Activate CODING DevOps service.

Scenario 1: automatically build the image after the code change, and trigger the deployment operation scenario

Support user configuration pipeline, automatically build image after code change, and trigger automatic deployment to container platform.

Procedure to configure the delivery pipeline

Log in to the TCR console of the container image service, select "delivery Pipeline" in the left navigation bar, and click "New" on the "delivery Pipeline" page.

In the basic Information step, configure the following parameters, and then click next: mirror configuration.

Pipeline name: sets the delivery pipeline name.

Pipeline description: add description information to the delivery pipeline, which can be modified after creation.

In the "Image configuration" step, configure the following parameters, and click "next: application deployment".

Push to the specified branch trigger: you need to specify the branch.

Trigger build when a new tag is pushed: trigger when a new tag is created and pushed.

Trigger build when pushed to a branch: trigger when pushed to any branch without specifying a branch.

Build when the branch or label rules are met: you need to enter a regular expression, for example, ^ refs/heads/master$, can match the master branch to trigger.

Deploy any version directly: any version of the image pushed to the image repository will be deployed.

Deploy only the version with the specified name: you need to specify an image version. Multiple versions can be separated by commas, and non-specified versions will not be deployed.

Deploy only the specified rule version: you need to enter a regular expression.

Image repository: select the image repository associated with the delivery pipeline, and the image construction and push will be automatically configured to host the images needed for application deployment.

Image version filtering

Limit the version of the image in the execution delivery pipeline to filter out the version of the image that does not need to be deployed.

Image source: platform-built images and local push images are supported. Platform build image allows users to associate code repositories of different code hosting platforms, automatically trigger delivery pipeline when code changes, and complete automatic construction, push image and application deployment. Local push image allows users to manually push image. Application deployment can also be triggered. In scenario 1, we choose the platform to build the image.

Code source and code repository: select the code repository used to build the image, and the pipeline will pull the source code in the code repository for compilation and construction. Authorization is required for the first selection. Code hosting platforms such as GitHub, public GitLab, private GitLab, Code Cloud and worker Bee are supported.

Trigger rule

Mirror builds rule conditions that are automatically triggered The following four scenarios are supported:

Dockerfile path: the operation performed by the image build is based on the Dockerfile in the code repository, and you need to specify the path to the Dockerfile file. If not specified, the default is the file named Dockerfile under the root directory of the code repository.

Build directory: the working directory where the mirror build is executed, the context (context), defaults to the root directory of the code repository.

Version rule: define the name of the image generated by the image build, that is, the image version (tag). Support for the configuration of custom prefixes, and the combination of "branch / label", "update time", "commit number" three environment variables. Where the update time is the system time to build the service when the docker tag instruction is executed.

In the "Application deployment" step, configure the following parameters, and click "OK".

Deployment platform: the delivery pipeline also supports container service TKE, elastic container service EKS and edge container service Edge. This article takes CCS TKE as an example.

Deployment region: the region where the target cluster is located. Select the region where the created TKE standard cluster resides.

Deployment cluster: target cluster. Select the TKE standard cluster that has been created.

Deployment method: currently only "update existing workloads" is supported.

Namespace: the namespace where the deployed application is located.

Workload: the associated workload of the deployed application.

Pod container: a Pod container within the workload of the deployed application.

After completing the above configuration, you can view the new pipeline on the delivery Pipeline list page.

Update Container Application

After the above configuration is completed, the image construction, push and application update can be triggered automatically after updating the application code.

Update the source code and submit it to the remote code repository.

Execution pipeline

After the source code push is completed, if the trigger condition of the image construction in the image configuration is met, the pipeline execution will be triggered. You can click on the pipeline to view the execution record of the pipeline and view the progress of the specific steps.

Checkout: check out the code.

Docker Build: build an image based on the image construction configuration, and specify a regular Tag for the generated image, such as v-{tag}-{date}-{commit}.

Docker Push: push the image, which is automatically pushed to the associated image repository.

Deploy To TKE: update the associated workload and the image with the same name in the Pod with the newly pushed image.

Check the application update status and go to the CCS TKE console, go to the above cluster and workload details page, and select the revision history to view the application update status. As shown in the figure below, the v1 version is a nginx image deployed manually at the beginning, and updated to the v2 version after the pipeline execution is completed, using a new image built automatically. You can access the application service directly to see if it has been updated. By looking at the address where Servce is exposed to the public network and the result, you can see that the service has been updated.

Scenario 2: after the image is pushed locally, the deployment operation scenario is automatically triggered

In some scenarios, you may not need to use TCR image to build automatically, but you want to be able to deploy to the container platform automatically after the image is pushed. TCR allows users to automatically trigger image deployment through the ability of triggers after configuring a local push image.

Procedure to configure the delivery pipeline

Refer to scenario 1 configuration to create a new delivery pipeline, which is different from scenario 1. In the "Mirror configuration" step, select "Image Source" as "Local push Image".

Update Container Application

After the configuration is completed, the image can be pushed locally using command-line instructions to trigger automatic deployment.

Local push image

Through the shortcut command, we can log in to Tencent Cloud Container Image Service Docker Registry and push the image to Registry. For example, a nginx image is pushed here.

After the execution pipeline locally promotes the image, if the trigger condition for image construction in the image configuration is met, the pipeline execution will be triggered. Since the image is ready, the pipeline only needs to perform automatic deployment.

View the status of application updates

In the same scenario 1, we can go to the CCS TKE console, go to the details page of the above cluster and workload, and select the revision history to view the update status of the application, or directly access the application service to check whether it has been updated.

This article describes how to use container image service TCR to implement container DevOps in two scenarios. In scenario 1, image construction and application deployment are triggered automatically after code changes; in scenario 2, application deployment is triggered automatically after the local push image. This article is a good reference for quickly getting started with TCR and TKE of container image service to practice CD process.

After reading the above, do you have any further understanding of how to easily implement container DevOps using the container image service TCR? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.