Architect growth Series | DevOps the era of cloud native road

Author | Haoshu Wei (nickname: Liu Sheng) Ali cloud senior research engineer

This paper finishing architect from growing series of live February 17 courses.

Concern "Alibaba Cloud native" public number, reply  , "217" , you can get the corresponding link and replay live PPT download link.

REVIEW: DevOps is a process of cooperation between software developers and IT staff, the goal is to efficiently automate the software delivery process and infrastructure changes. Native in the cloud era, and how to help companies achieve product DevOps fast, stable, efficient and safe iteration, release business value?

What is cloud native

In order to solve the traditional application upgrades slow, bloated, fast iteration can not, can not quickly locate the fault, the problem can not quickly resolve issues such as the concept of cloud native turned out.

Pivotal is the author of native cloud applications, and launched Pivotal Cloud Foundry cloud-native application platform and open source Spring Java development framework, become native cloud application architecture pioneers and Pathfinder.

As early as 2015 Pivotal's Matt Stine wrote a book called native applications migrate to the cloud architecture booklet discusses several key characteristics of cloud native application architecture:

• 12 factors in line with the application
• Service-oriented micro-architecture
• Self-service agile architecture
• The API-based collaboration
• Anti-Vulnerability

Later Pivotal definition of cloud native had several updates, the latest official website for the latest Pivotal introduction of native cloud applications is the following four points:

• Integrated DevOps
• Continuous Delivery
• Micro Services
• Containerized

• DevOps is a collaboration between software developers and IT operations, the goal is to automate the software delivery process and infrastructure changes. It created a culture and environment for fast, frequent and more reliably construct in which the test and publish software;

• Continuous delivery allows a single application to change after the release is ready, without waiting for the other to change the bundled release or wait for maintenance windows and other events. Continuous delivery allows publishers behavior becomes dull and reliable, so businesses can lower the risk of frequent delivery, and access to end-user feedback more quickly, until the deployment of enterprise business processes and become an integral part of competitiveness;

• 微服务是将应用作为小型服务集合进行开发的架构方法，其中每个服务都可实施业务功能，在自己的流程中运行并通过 HTTP API 进行通信。每个微服务都可以独立于应用中的其他服务进行部署、升级、扩展和重新启动，通常作为自动化系统的一部分运行，可以在不影响最终客户的情况下频繁更新正在使用中的应用；

• 与标准虚拟机相比，容器能同时提供效率和速度。单个操作系统实例使用操作系统 级的虚拟化，在一个或多个隔离容器之间进行动态划分，每个容器都具有唯一的可写文件系统和资源配额。创建和破坏容器的开销较低，再加上单个虚拟机中的高包装密度，使容器成为部署各个微服务的完美计算工具。

Google 主导成立了云原生计算基金会（CNCF），对云原生的定义为：

“云原生（Cloud Native）技技术帮助企业和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、 服务网格、微服务、不可变基础设施和声明式 API；这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可以使开发者轻松地对系统进行频 繁并可预测的重大变更 。”

目前云原生背后最大的推手就是 CNCF，关键技术包括容器、微服务、服务网格、devops，声明式的 API 等等。

云原生应用与传统应用的对比，云原生应用可以充分利用云的优势，灵活地在各个云厂商分发应用，释放企业生产力，聚焦到业务创新上，而不是花费更多的时间在适配和扩展不同的基础设施平台上。

云原生时代的 DevOps 新挑战

首先我们要清楚地知道， 站在企业的角度来看，在这样一个快捷商业的时代，企业最需要什么？

• 唯快不破。这里的快可以解读出来两层含义，一是业务应用快速上线，有利于抢占市场先机，第二层意思就是在你的业务有爆炸式增长的时候，你如何在计算资源上给以充分的保证，这个时候其实追加巨额的 IT 投资购买软硬件也未必能跟得上业务的快速发展。这个其实就是企业研发效能的问题；
• 稳中求变。业务或者应用的稳定性永远都是第一位的，如何既保证业务的“稳态”又要满足快捷商业的“敏态”需求，比如新业务的上线、应用的变更等。这个是企业 IT 架构的问题；
• 节省资源，如何节省计算资源，根据业务是否高峰自动扩容缩容，这个是云平台建设的问题；
• 开拓创新，开发运维一体化、微服务架构。

DevOps 最初的出现打破了开发人员和运维人员之间历来存在的壁垒和沟鸿，加强了开发、运营和质量保证人员之间的沟通、协作与整合。在后 DevOps 时代，我们可以借助容器技术更快地对应用进行迭代上线。

下面是应用发布的一般过程，开发者 push 代码，触发构建，构建过程是拉取源码，应用打包，容器镜像推送，部署。

这个模型其实已经有很多地方充分利用了云原生的优势，比如容器技术、Kubernetes、动态分配 slave pod 等。但还有一些挑战。

• 如何应用在环境栈之间的安全推进发布
• 如何管理应用发布的权限和安全审批
• 如何提高应用的平均部署时间和平均恢复时间
• 如何迅速对线上应用进行故障定位、复现和回滚

云原生时代下的 DevOps 之道

首先我们要充分利用云原生技术的优势，云原生可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。在容器领域内，Kubernetes 已经成为了容器编排和管理的社区标准。它通过把应用服务抽象成多种资源类型，比如 Deployment、Service 等，提供了一个云原生应用通用的可移植模型。

在这样的背景下，我们如何在云原生的环境下实践更高效的 DevOps 来达到更有生产力的表现就成为了一个新的课题和诉求。

下面是一个企业应用平台的建设目标：

在此 PaaS 平台的基础上，我们设计了 GitOps 安全发布模型来解决前面我们提到的一些挑战。

在设计 GitOps 发布模型的时候是有以下这些核心诉求的：

• 版本管理。我们希望每一个发布的应用的版本号都能跟 git commit id 关联，这样的好处就是每一个变更都有历史记录查询、可以更快进行故障定位和修复；
• 基线管理。便于问题复现和快速回滚；
• 安全发布。包括发布权限管理以及安全审批的内容；
• 快速反馈。提高研发效能。

GitOps 发布模型有以下特性：

• Git 仓库是任何 CICD 过程的唯一输入源
• 声明式的应用编排、构建部署模型
• 应用在环境栈之间的无差别、自动化推进
• PR/MR 触发的拉取式流水线过程
• 快速反馈机制

下面是使用 GitOps 管理应用发布到不同 Kubernetes 集群的架构图。

首先是应用源码与构建源码分离，我们可以看到橙色框起来的这两个源码项目，一个是我们的应用源码项目 application-java-demo， 左侧的这个源码项目是用来存放构建源码的，比如 preview pipeline 的 Jenkinsfile， staging pipeline 的 Jenkinsfile，production pipeline 的 Jenkinsfile， 除了 Jenkinsfile 之外，可能还有一些关于动态创建测试环境、连接预发环境或者生产环境的敏感信息，这些敏感信息也可以存放在数据库里，然后这里保存数据库的连接信息。

这个普通应用 application-java-demo 在 Git 仓库里是有不同的分支的，每个分支跟 Kubernetes 集群环境都有一定的对应关系，比如我们这里的设定，master 分支对应的是生产环境，latest 分支对应的是预发环境，其他开发分支对应的是测试环境，测试环境的动态创建和销毁、应用再测试环境的部署发布是开发测试人员自助的服务，但应用想要部署到预发环境和生产环境中的话是需要经过管理员安全审批的。

普通开发者的权限只有创建新代码分支和创建合并请求的权限，除此之外，剩下其他的部分都是管理员才有权限做的，绿色区域是 Jenkins 的流水线任务，当然你也可以是使用其他 cicd 引擎来做这个流水线任务的构建。普通开发者没有 Jenkins 环境的创建 Job 和构建 Job 的权限，也没有更改配置的权限，他有的只是构建 Job 的日志查看权限。

最后是一个时序图，演示一个应用从开发测试到业务上线迭代的一个完整流程：

1. 开发者提交新的功能分支 feature；
2. 开发者创建请求合并代码到 latest 分支的 Merge Request；
3. 开发者创建 Merge Request 的动作自动触发名为 preview-pipeline 的 Jenkins 流水线任务的构建；
4. preview-pipeline 流水线任务从 Git 服务器拉取 preview-pipeline 源码项目，并按照项目中 Jenkinsfile 文件中的声明式脚本运行源码编译、测试、容器镜像构建和推送、应用部署到 Preview 的容器集群、钉钉通知的流程；
5. 管理员在 Git 服务器的 Merge Request 页面查看应用的预览连接并验证应用是否可以合并到 latest 分支，如果通过验证则接受 Merge Request 的合并，触发步骤 6， 如果不通过则通知开发者进行代码更新和提交，退回步骤 1；
6. 管理员接受 Merge Request 合并的动作会自动触发 Jenkins 流水线任务 staging-pipeline 的构建；
7. staging-pipeline 流水线任务从 Git 服务器拉取 staging-pipeline 源码项目，并按照项目中 Jenkinsfile 文件中的声明式脚本运行源码编译、测试、容器镜像构建和推送、应用部署到 Staging 的容器集群、钉钉通知的流程；
8. Staging 环境中的应用服务在通过测试和验证后，管理员可以合并 latest 分支到 master 分支；
9. 管理员合并 latest 分支到 master 分支后，会自动触发 Jenkins 流水线任务 production-pipeline 的构建；
10. production-pipeline assembly line task to pull from the Git server production-pipeline-source project, and build and push accordance declarative script source compiler project Jenkinsfile file, testing, container mirroring, application deployment to a cluster Production of container, nails notice process.

GitOps is a methodology, so in fact there are many practical ways, there will be a wide variety of useful tools, such as using a draft that can help automate generation application layout template, skaffold to simplify application deployment process to build, kaniko docker daemon can be implemented not rely on the construction and push the mirror, as the application helm package management tools, as well as other engines cicd jenkins, tekton, argo and cloud native born jenkinsx like.

Later, we will demonstrate the operation of a separate real security release process GitOps model.

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

" Alibaba Cloud native concern micro service, Serverless, container, Service Mesh and other technical fields, focusing cloud native popular technology trends, cloud native large-scale landing practice, most do understand the developer's native cloud technology circles."