Architect Growth Series | The Way of DevOps in the Cloud Native Era

Author | Hao Shuwei (flower name: Liusheng) Alibaba Cloud Senior R&D Engineer

This article is compiled from the live course of the architect growth series on February 17.

Follow the "Alibaba Cloud Native" official account and reply "217" to get the corresponding live playback link and PPT download link.

Introduction: DevOps is a collaborative process between software developers and IT staff with the goal of automating software delivery and infrastructure change processes efficiently. In the cloud-native era, how can enterprises use DevOps to realize rapid, stable, efficient and safe iteration of products and release business value?

What is cloud native

In order to solve the problems of slow upgrade of traditional applications, bloated architecture, inability to quickly iterate, failure to locate faults quickly, and inability to solve problems quickly, the concept of cloud native was born.

Pivotal is the proponent of cloud native applications, and has launched the Pivotal Cloud Foundry cloud native application platform and Spring open source Java development framework, becoming a pioneer and pathfinder in cloud native application architecture.

As early as 2015, Matt Stine of Pivotal wrote a booklet called Migrating to Cloud-Native Application Architecture, which explored several key characteristics of cloud-native application architecture:

Compliant with 12 factor applications
Microservice-oriented architecture
Self-service agile architecture
API-based collaboration
antifragility

Later, Pivotal made several updates to the definition of cloud native. The latest introduction to cloud native applications on the latest Pivotal official website focuses on the following four points:

Integrate DevOps
continuous delivery
Microservices
containerized

DevOps is the collaboration between software developers and IT operations with the goal of automating software delivery and infrastructure change processes. It creates a culture and environment in which software can be built, tested, and released quickly, frequently, and more reliably;
Continuous Delivery enables individual application changes to be released when they are ready, without having to wait for events such as bundling releases with other changes or waiting for maintenance windows. Continuous delivery makes the act of releasing flat and reliable, so businesses can deliver frequently with less risk and get feedback from end users faster, until deployment becomes an integral part of business processes and business competitiveness;
Microservices is an architectural approach to developing an application as a collection of small services, where each service implements a business function, runs in its own process, and communicates through HTTP APIs. Each microservice can be deployed, upgraded, scaled, and restarted independently of other services in the application, often running as part of an automated system that can frequently update the application in use without affecting the end customer;
Containers offer both efficiency and speed compared to standard virtual machines. A single OS instance uses OS-level virtualization, dynamically partitioned between one or more isolated containers, each with a unique writable filesystem and resource quota. The low overhead of creating and destroying containers, combined with the high packing density within a single virtual machine, makes containers the perfect computing tool for deploying individual microservices.

Google led the establishment of the Cloud Native Computing Foundation (CNCF), which defines cloud native as:

"Cloud native technology helps enterprises and institutions build and run elastically scalable applications in new dynamic environments such as public cloud, private cloud and hybrid cloud. Representative technologies of cloud native include containers, service meshes, micro services, immutable infrastructure, and declarative APIs; these technologies enable building loosely coupled systems that are fault-tolerant, easy to manage, and easy to observe. Combined with reliable automation, cloud-native technologies make it easy for developers to perform frequent and Significant changes to forecasts."

At present, the biggest driver behind cloud native is CNCF. The key technologies include containers, microservices, service meshes, devops, declarative APIs and so on.

Compared with traditional applications, cloud-native applications can make full use of the advantages of the cloud, flexibly distribute applications among various cloud vendors, release enterprise productivity, and focus on business innovation instead of spending more time on adaptation and expansion. on different infrastructure platforms.

New DevOps Challenges in the Cloud-Native Era

First of all, we must clearly know that from the perspective of enterprises, in such an era of fast business, what do enterprises need most?

Only fast is not broken. The word "quick" here can be interpreted in two meanings. One is that business applications are launched quickly, which is conducive to seizing market opportunities. The second layer means that when your business has explosive growth, how can you provide sufficient computing resources? Guarantee, at this time, in fact, additional huge IT investment to purchase software and hardware may not be able to keep up with the rapid development of the business. This is actually a problem of enterprise R&D efficiency;
Seek change in stability. The stability of the business or application is always the first priority. How to ensure the "steady state" of the business and meet the "sensitive state" requirements of the fast business, such as the launch of new business, the change of application, etc. This is a problem of enterprise IT architecture;
Saving resources, how to save computing resources, and automatically expand and shrink according to whether the business peaks, this is the problem of cloud platform construction;
Pioneering and innovating, integrating development, operation and maintenance, and micro-service architecture.

The initial emergence of DevOps broke down the barriers and gaps that have historically existed between developers and operations personnel, and strengthened communication, collaboration, and integration between development, operations, and quality assurance personnel. In the post-DevOps era, we can use container technology to iteratively launch applications faster.

The following is the general process of application publishing. The developer pushes the code and triggers the build. The build process is to pull the source code, package the application, push the container image, and deploy.

In fact, there are many places in this model that make full use of the advantages of cloud native, such as container technology, Kubernetes, and dynamic allocation of slave pods. But there are some challenges.

How to apply secure push releases between environment stacks
How to manage permissions and security approvals for app publishing
How to improve the mean time to deploy and mean time to restore of your application
How to quickly locate, reproduce and roll back online applications

The Way of DevOps in the Cloud Native Era

First of all, we must make full use of the advantages of cloud native technology. Cloud native can improve the efficiency of application development, change the organizational structure of enterprises, and even directly affect a company's decision-making at the cultural level. In the container world, Kubernetes has become the community standard for container orchestration and management. It provides a common portable model for cloud-native applications by abstracting application services into multiple resource types, such as Deployment, Service, etc.

In this context, how to practice more efficient DevOps in a cloud-native environment to achieve more productive performance has become a new topic and appeal.

The following are the construction goals of an enterprise application platform:

Based on this PaaS platform, we designed the GitOps secure release model to address some of the challenges we mentioned earlier.

When designing the GitOps release model, there are the following core demands:

Version management. We hope that the version number of each released application can be associated with the git commit id. The advantage of this is that each change has a history query, which can locate and repair faults faster;
Baseline management. Facilitate problem recurrence and quick rollback;
Safe release. Including publishing rights management and security approval content;
Quick feedback. Improve R&D efficiency.

The GitOps release model has the following characteristics:

The Git repository is the only input source for any CICD process
Declarative application orchestration, building and deploying models
Undifferentiated, automated advancement of applications across environment stacks
Pull pipeline process triggered by PR/MR
Fast feedback mechanism

Below is an architecture diagram of using GitOps to manage application publishing to different Kubernetes clusters.

The first is the separation of application source code and build source code. We can see the two source code projects framed in orange, one is our application source code project application-java-demo, the source code project on the left is used to store the build source code, For example, the Jenkinsfile of the preview pipeline, the Jenkinsfile of the staging pipeline, and the Jenkinsfile of the production pipeline, in addition to the Jenkinsfile, there may be some sensitive information about dynamically creating a test environment, connecting to the staging environment or the production environment, and these sensitive information can also be stored in the database. , and then save the connection information of the database here.

This common application application-java-demo has different branches in the Git repository, and each branch has a certain corresponding relationship with the Kubernetes cluster environment. For example, in our setting, the master branch corresponds to the production environment, and the latest branch corresponds to the production environment. It corresponds to the pre-release environment, and other development branches correspond to the test environment. The dynamic creation and destruction of the test environment, and the deployment and release of the application and re-test environment are self-service services for developers and testers, but the application wants to be deployed to the pre-release environment and production. In the environment, it needs to be approved by the administrator security.

The permissions of ordinary developers are only the permissions to create new code branches and merge requests. In addition, the rest of the parts are only authorized by administrators. The green area is the pipeline task of Jenkins. Of course, you can also be Use other cicd engines to do the build for this pipeline task. Ordinary developers do not have the permission to create and build jobs in the Jenkins environment, nor do they have permission to change the configuration. All they have is the permission to view the logs of the build job.

Finally, there is a sequence diagram that demonstrates a complete process of an application from development and testing to business online iteration:

The developer submits a new feature branch feature;
The developer creates a Merge Request that requests to merge the code into the latest branch;
The action of the developer to create a Merge Request automatically triggers the build of the Jenkins pipeline task named preview-pipeline;
The preview-pipeline pipeline task pulls the preview-pipeline source code project from the Git server, and follows the declarative script in the Jenkinsfile in the project to run source code compilation, testing, container image building and push, application deployment to Preview's container cluster, and DingTalk notifications process;
The administrator checks the preview connection of the application on the Merge Request page of the Git server and verifies whether the application can be merged into the latest branch. If it passes the verification, the merge of the Merge Request is accepted, and step 6 is triggered. If it does not pass, the developer is notified to update and submit the code. , return to step 1;
The administrator's action of accepting the Merge Request will automatically trigger the construction of the Jenkins pipeline task staging-pipeline;
The staging-pipeline pipeline task pulls the staging-pipeline source code project from the Git server, and runs source code compilation, testing, container image building and push, application deployment to Staging's container cluster, and nail notifications according to the declarative script in the Jenkinsfile in the project process;
After the application service in the Staging environment has passed the test and verification, the administrator can merge the latest branch into the master branch;
After the administrator merges the latest branch into the master branch, it will automatically trigger the construction of the Jenkins pipeline task production-pipeline;
The production-pipeline pipeline task pulls the production-pipeline source code project from the Git server, and runs source code compilation, testing, container image building and push, application deployment to Production's container cluster, and DingTalk notifications according to the declarative script in the Jenkinsfile in the project process.

GitOps is a set of methodology, so there are actually a variety of ways to practice, there will be a variety of useful tools, such as the use of draft can help complete the automatic generation of application orchestration templates, skaffold is used to simplify the application construction and deployment process, kaniko can realize image building and pushing without relying on docker daemon, helm is used as a package management tool for applications, and there are other cicd engines like jenkins, tekton, argo, and jenkinsx for cloud native, etc.

Later, we will demonstrate the working process of the GitOps secure release model separately.

References: https://pivotal.io/cn/cloud-native

Live poster.png

" Alibaba Cloud Native focuses on micro-services, serverless, containers, Service Mesh and other technical fields, focuses on popular cloud-native technology trends, and implements large-scale implementation of cloud-native, and is the technology circle that understands cloud-native developers best."