写点什么

持续演进的云原生应用交付

用户头像
CODING DevOps
关注
发布于: 15 小时前
持续演进的云原生应用交付

本文作者:吴海黎 - CODING 研发总监

负责持续部署产品设计,帮助多个行业客户完成研发效能的方案设计与最终落地。


什么是云原生


云原生是指导企业应用上云的方法论和技术体系,包含应用的开发、交付、运行时等阶段Cloud Native 可以理解为:

  • Cloud 表示应用运行在云端,而非传统的 IDC;

  • Native 表示应用从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳姿势运行,充分利用云平台的弹性和敏捷。


对云原生的理解,各家厂商在不同时间有不同的定义:

  • 2013 年,Pivotal 公司的 Matt Stine 首次提出云原生“CloudNative”的概念;

  • 2015 年,Matt Stine 在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征:12 因素、微服务、自敏捷架构、基于 API 协作、扛脆弱性;

  • 2017 年,Pivotal 最新官网对云原生概括为 4 个要点:DevOps + 持续交付 + 微服务 + 容器;

  • 2018 年,CNCF 更新了云原生的定义,新增服务网格“Service Mesh”和声明式 API。


可以简单的总结为:

云原生 = DevOps + 持续交付(Continuous Delivery)+ 微服务(Micro Services)+ 敏捷基础设施(Agile Infrastructure)+ 12 要素(The Twelve-Factor App)+ 服务网格(Service Mesh)+ 声明式 API。



云原生应用交付现状



CNCF 发布的「Continuous Delivery, June 2020」主要结论如下:

  • 开源工具难以满足企业级发布需求

中大型企业的发布场景,开源工具较难匹配,一般的解决方案是选择上图中 2-4 种,基于企业自身场景,深度定制满足需求。


  • Helm 不仅仅是包管理工具

虽然 Helm 自身的定位是解决 K8s 应用的安装包管理,但也被广泛应用发布场景,关于这点其实不难猜想,基础架构由单体迁移至微服务,同时也将应用的交付切分为细粒度的服务交付,但企业面向最终用户的价值交付,需由完整的应用承载,单一微服务价值为 0,因此从交付的完整性考虑,Helm 被广泛应用于发布场景并不奇怪。


  • Jenkins 正逐步被替代

Jenkins 及其生态(Jenkins X、Jenkins Blue Ocean)依然是持续交付中主要被采纳的工具,但企业也在逐步使用新工具替代,如承载 GitOps 理念的 Flux。Jenkins 定位于持续集成,用来做发布的场景是略显无力的,针对 Jenkins 发布下文也做出了分析。


持续演进的云原生应用交付


从 CNCF 的调研报告中得出的核心结论是企业需求未被满足,持续交付的方法论和工具建设依然处于持续演进中,下面我们回顾一下云原生应用持续演进的重要方法论及相关工具。


Continue Delivery


方法论:持续交付

持续交付主张应用被更频繁、更快速的交付至客户,但快并不意味着对质量要求的降低,通常在持续交付实践中,会辅之以质量左移的手段,如代码审查、代码扫描、单元测试、自动化测试,保障应用交付的可靠性。


工具:Jenkins、Gitlab Ci、Tketon


价值:通过持续交付的引入,用户可通过上诉工具实现部署流程的自动化和可视化,通常的持续交付流水线如下,「Deploy」阶段使用:kubectrl apply 或 helm install 等命令完成应用部署。



核心问题:通过上诉工具实现持续交付,前提需将集群密钥交由工具纳管,相比于 GitOps 密钥不出集群,相对不安全;且无法通过版本化的手段,实现交付的可追溯和可审计,出现问题较难快速恢复。


IAC


方法论:IAC(基础设施及代码)

随着云原生应用的快速发展,企业对云基础设施的交付和变更速度要求越来越高,依靠传统手工的方式,操作云控制台维护基础设施,已经无法满足企业的需求,通过抽象云基础设施,并对其通过代码编排的方式即为 IAC。


工具:TIC、Terraform、Crossplane


价值:IAC 将云的基础设施,通过代码来进行编排,并将编排代码存储于代码仓库中,实现了基础设施的版本化管理,用户可轻易的拓展应用依赖的基础设施,比如一个游戏公司将应用部署于腾讯云上海,因业务需求,客户需将应用部署至腾讯云广州,通过 Terraform 的能力,可快速实现应用依赖的基础设施跨可用区迁移:



核心问题:本质上 IAC 的能力依赖于云 OPEN API 的开放性和稳定性,目前云产品处于快速演进中,一定程度上造成了 IAC 的能力不够稳定。同时 IAC 的成熟程度仅局限于单一云厂商,跨云 IAC 目前仍需要较高的人工转换成本。


GitOps



方法论:GitOps

GitOps 是一种实现持续交付的模型,它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 的版本控制库中,通过版本控制库的变更,来实现应用和基础架构的变更。


工具:ArgoCD、Flux


价值:通过版本控制库来发布应用和基础架构的变更,将使发布的复杂性降低至版本控制库的 Pull and Push 操作。GitOps 通过安装在 K8s 集群中的 Operator 实现变更物料获取,集群密钥无需出集群,GitOps Operator 中只需获取制品库凭据,即可获取应用变更的制品信息,这也同时大大简化了大型微服务应用的变更交付流程,因为对变更物料的感知,是通过 Gitops 的 Pull 模式自动实现。另外 Git 仓库天生具有可审计「MR」、可追溯「commit log」、快速恢复「回退至某一版本」的能力,使应用发布的可靠性大大提升。最后 GitOps 通过状态控制实现版本库对集群的终态控制,实现 yaml 仓库的「所见」即是 K8s cluster 「所得」。



核心问题:Gitops 的出现大幅提高了云原生交付的效率和可靠性,但依然有两个问题未被解决,第一:密钥的存储问题,版本仓库的定位决定了它不适合存储密钥;第二:可视化,虽然版本仓库将所有变更存储于 history 中,但这些信息可能分布于不同分支,可读性较差。


OAM



方法论:OAM(Open Application Model)

OAM 试图提供一种云原生应用的建模语言,以实现研发和运维的视角分离,K8s 的复杂性无需透传至研发,运维通过提供模块化、可移植、可扩展的特性组件,支撑各种复杂的应用交付场景,从而实现云原生应用交付的敏捷性和平台无关性。


工具:KubeVela


价值:

  • 应用(Application):云原生应用建模语言,实现视角分离;

  • 开放(Open):支持异构的平台、容器运行时、调度系统、云供应商、硬件配置;

  • 模型(Model):建模标准,与底层平台无关。


总结


上述方法论尝试从不同维度优化云原生交付,但采用云原生架构的企业,依然需基于开源工具定制,才能满足企业级云原生交付需求,可见云原生交付域的发展远没有到最优解。比如云原生应用 12 要素(The Twelve-Factor App)中提及的环境隔离和治理问题,依然未被很好的解决。因此我们相信,2021 年会有更多的方法论和工具出现在云原生应用交付域,尝试解决企业级云原生交付问题。CODING 作为国内一站式 DevOps 头部品牌,将在下半年推出云原生应用交付工具,服务企业更好的落地云原生,实现研发效能升级。


点击深度探索云原生之旅



用户头像

CODING DevOps

关注

还未添加个人签名 2018.04.23 加入

涵盖了软件开发从构想到交付的一切所需,助力企业实践敏捷开发与 DevOps,提升软件交付质量与速度。

评论

发布
暂无评论
持续演进的云原生应用交付