What is cloud native
The concept of cloud native was born in order to solve the problems of traditional applications, such as slow upgrade, bloated architecture, failure to iterate quickly, failure to locate quickly, and problem solving quickly.
Pivotal is the originator of Cloud native application, 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.
Back in 2015, Matt Stine of Pivotal wrote a booklet called Migrating to Cloud Native Application Architectures, which discusses some of the key features of cloud native application architectures:
- Accord with 12 factor application
- Microservices Oriented architecture
- Self-service Agile architecture
- Api-based collaboration
- Resistance of vulnerability
Since then, Pivotal has updated its definition of cloud native several times, and the most recent introduction to cloud native apps on its website focuses on the following four points:
- Integrated enterprise
- Continuous delivery
- Micro service
- The container is changed
- DevOps is a 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 distributed quickly, frequently, and reliably;
- Continuous delivery enables individual application changes to be released when they are ready, without having to wait for events such as bundled releases with other changes or maintenance window periods. Continuous delivery makes release behavior unexciting and reliable, so organizations can deliver frequently with less risk and get end user feedback faster, until deployment becomes an integral part of business processes and enterprise competitiveness;
- Microservices are an architectural approach to developing applications as small collections of services, where each service implements business functions, runs in its own process and communicates through HTTP apis. Each microservice can be deployed, upgraded, extended, and restarted independently of other services in the application, and typically operates as part of an automated system that can frequently update in-use applications without affecting end customers;
- Containers provide both efficiency and speed compared to standard virtual machines. A single operating system instance is dynamically partitioned among one or more isolated containers, each with a unique writable file system and resource quota, using operating system-level virtualization. The low overhead of creating and breaking containers, coupled with the high wrapper density in a single virtual machine, makes containers a perfect computing tool for deploying individual microservices.
Google led the establishment of cloud Native Computing Foundation (CNCF), which defined cloud native as:
“Cloud Native technologies help enterprises and organizations build and run resilient, scalable applications in new, dynamic environments such as public, private and hybrid clouds. Cloud native technologies include containers, service grids, microservices, immutable infrastructure, and declarative apis. These technologies enable the construction of loosely-coupled systems that are fault-tolerant, easy to manage, and easy to observe. Combined with reliable automation, cloud native technology enables developers to easily make frequent and predictable changes to their systems.”
At present, CNCF is the biggest driver behind cloud native. Key technologies include containers, microservices, service grids, DevOps, declarative apis and so on.
Comparison between cloud native applications and traditional applications. Cloud native applications can make full use of the advantages of cloud, flexibly distribute applications among cloud vendors, release enterprise productivity, and focus on business innovation rather than spending more time on adapting and expanding different infrastructure platforms.
New DevOps challenges in the cloud native era
First of all, we should clearly know that from the perspective of enterprises, in such an era of fast business, what do enterprises need most?
- Only fast can not break. Here fast can read out two meanings, one is the business application online, quickly to seize market opportunities, the second is when you have the explosive growth of the business, how do you give full guarantee on computing resources, this time actually append a huge IT investments to purchase hardware and software that can keep up with the rapid development of business. This is actually a problem of enterprise research and development effectiveness;
- Seek change while maintaining stability. The stability of business or application is always the first priority. How to ensure the “steady state” of business and meet the “sensitive state” requirements of fast business, such as the launch of new business and the change of application, etc. This is an enterprise IT architecture problem;
- Save resources, how to save computing resources, according to whether the business peak automatically expand and shrink, this is the cloud platform construction problem;
- Pioneering and innovative, the development of integrated operation and maintenance, micro-service architecture.
The initial emergence of DevOps broke down the traditional barriers and gaps between developers and operations personnel, enhancing communication, collaboration, and integration among development, operations, and quality assurance personnel. In the post-DevOps era, container technology can be used to iteratively bring applications online faster.
The following is the general process of application release. 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 it.
There are already many aspects of the model that take full advantage of cloud native technology, such as container technology, Kubernetes, slave Pod dynamic allocation, etc. But there are challenges.
- How to apply secure push publishing between stacks of environments
- How do I manage application publishing permissions and security approval
- How can I improve the average deployment time and average recovery time of applications
- How to quickly locate, reproduce, and roll back online applications
The way to DevOps in the cloud native era
First of all, we should make full use of the advantages of cloud native technology. Cloud native technology can improve the efficiency of application development, change the organizational structure of the enterprise, and even directly affect the decision-making of a company on the cultural level. In the container space, Kubernetes has become the community standard for container choreography and management. It provides a common portable model for cloud native applications by abstracting application services into multiple resource types, such as Deployment, Service, and so on.
In this context, how we can practice more efficient DevOps in the cloud native environment to achieve more productive performance has become a new topic and pursuit.
The following are the goals of building an enterprise application platform:
Based on this PaaS platform, we designed the GitOps security release model to address some of the challenges we mentioned earlier.
The GitOps release model was designed with these core concerns:
- Version management. Git commit ID = git Commit ID = Git Commit ID = Git Commit ID = Git Commit ID = Git Commit ID = Git Commit ID = Git Commit ID
- Baseline management. Facilitate problem recurrence and fast rollback;
- Security release. Including release permission management and security approval content;
- Quick feedback. Improve r&d efficiency.
The GitOps publishing model has the following features:
- The Git repository is the sole source of input to any CICD process
- Declarative application choreography, building deployment models
- Application of undifferentiated, automated propulsion between stacks in the environment
- Pull-pipeline process triggered by PR/MR
- Quick feedback mechanism
Below is an architecture diagram for publishing to different Kubernetes clusters using GitOps management applications.
First of all, the application source code is separated from the build source code. We can see the two source code projects in the orange box, one is our application source code project application-Java-Demo, the source code project on the left is used to store the build source. For example, the Preview Pipeline Jenkinsfile, the staging pipeline Jenkinsfile, the production Pipeline Jenkinsfile, There may also be sensitive information about dynamically creating test environments, connection pre-release environments, or production environments, which can also be stored in a database where the database connection information is stored.
Application java-demo has different branches in Git repository. Each branch corresponds to Kubernetes cluster environment. For example, the master branch corresponds to the production environment. The latest branch corresponds to the pre-release environment, and other development branches correspond to the test environment. Dynamic creation and destruction of the test environment and deployment and release of the application retest environment are self-service services provided by development testers. However, applications that want to be deployed in the pre-release environment and production environment must be approved by the administrator.
The normal developer only has the permission to create new code branches and create merge requests, but the rest is for administrators. The green area is Jenkins’ pipelined task, but you can also build pipelined tasks using other CICD engines. The average developer does not have the permission to create or build a Job in the Jenkins environment, nor does he have the permission to change the configuration. He only has the permission to view the log of the build Job.
Finally, a sequence diagram shows a complete process of an application from development test to business launch iteration:
- Developers submit new branch features;
- The developer creates a Merge Request to Merge code into the latest branch.
- The developer creating the Merge Request automatically triggers the build of the Jenkins pipeline task called preview-Pipeline;
- Preview-pipeline pipeline task pull preview-Pipeline source project from Git server, The process of source code compilation, testing, container image building and push, application deployment to Preview container cluster, and pinning notification is executed according to the declarative script in Jenkinsfile in the project.
- On the Merge Request page of the Git server, the administrator checks the preview connection of the application and verifies whether the application can be merged into the latest branch. If the Merge Request passes the verification, the Merge Request will be accepted and step 6 will be triggered. If the Merge Request fails, the developer will be notified to update and submit the code. Step 1;
- The administrator’s acceptance of Merge Request will automatically trigger the Jenkins pipeline-task staging pipeline construction.
- The staging-pipeline pipeline task pulls the staging-pipeline source project from the Git server, According to the declarative script in Jenkinsfile file in the project, the process of source code compilation, testing, container image construction and push, application deployment to Staging container cluster, and pinning notification is run.
- After application services in the Staging environment pass tests and authentication, the administrator can merge the latest branch to the Master branch.
- After the administrator merges latest branch to master branch, it will automatically trigger the construction of Jenkins pipeline-task production-pipeline.
- The production-pipeline pipeline task pulls the production-Pipeline source project from the Git server, According to the declarative script in Jenkinsfile file in the project, the process of source code compilation, testing, container image construction and push, application deployment to Production container cluster, and pinning notification was run.
GitOps is a set of methodology, so there are a variety of practical ways, there are a variety of useful tools, such as draft to help complete the automatic generation of application choreography templates, Skaffold to simplify the application construction and deployment process, Kaniko can build and push images independent of Docker Daemons, 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, among others.
Later, we will demonstrate the working process of the GitOps security release model separately.
Read more: https://yqh.aliyun.com/detail/6570?utm_content=g_1000105892
On the cloud to see yunqi: more cloud information, on the cloud case, best practices, product introduction, visit: https://yqh.aliyun.com/