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 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.
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:
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.
Log in to the TKE console, click DevOps on the left sidebar, and click Use Now .
Create a test project and test code repository on the CODING team homepage. For more information on CODING code hosting, see Code Hosting.
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.
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 .
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.
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.
In the sample, a simple Deployment YAML is used for the Kubernetes cluster, along with the default
RollingUpdatepolicy. 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.
TKE pulls a TCR private repository image in two ways:
- In the available regions of TCR, you can configure secret-free pulling of TCR container images by TKE. For more information on the available regions of TCR, see Billing Overview. For configuration directions, see TKE Clusters Use the TCR Addon to Enable Secret-free Pulling of Container Images via Private Network.
- Manually configure the TKE to pull access credentials of the TCR private repository image as instructed in Sample TKE Configuration for Accessing Private Repository.
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
For more information on associating projects and applications, see Project and Application Association.
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:
The test and verification results show that the entire DevOps process from source code update to business release is implemented in TKE.