关于阿里云开发者:云原生-DevOps模型化应用交付能力很重要

5次阅读

共计 3865 个字符，预计需要花费 10 分钟才能阅读完成。

简介：DevOps 文化及其撑持其落地实际的自动化工具与平台能力在云原生架构渐为遍及的背地，施展了要害的价值。

撰稿：溪洋

审核校对：_天元、_海珠

编辑 & 排版：雯燕

云原生正在成为企业业务翻新和解决规模化挑战的加速器。

云原生带来的改革绝不限于基础设施和利用架构等技术层面，更是对于研发理念、交付流程和 IT 组织形式的改革，也在推动企业 IT 组织、流程和文化的改革。在云原生架构渐为遍及的背地，DevOps 文化及其撑持其落地实际的自动化工具与平台能力，施展了要害的价值。

相较于云原生，DevOps 并不是什么陈腐的事件，其实际早已深刻企业古代应用程序架构。DevOps 强调团队间的沟通和疾速反馈，通过构建自动化的继续交付（Continuous Delivery）及流水线的利用公布形式，达到疾速响应业务需要、交付产品和进步交付品质的目标。随着容器技术在企业的规模化利用，云计算可编程基础设施和 Kubernetes 申明式的 API 等能力减速了开发和运维角色的交融。

云原生的大势所趋使上云成为企业标配，围绕云原生去定义下一代研发平台成为必然，也倒逼着 IT 组织形式进一步发生变化——新的平台工程团队开始浮现。在这样的背景下，如何在云原生的环境下更高效地实际 DevOps 成为一个新的课题和诉求。

随同着 Kubernetes 生态从底层到应用层能力的逐步完善，平台工程团队能够更不便地基于业务场景和终端用户理论需要来构建不同的利用平台，却也为下层利用开发者带来了挑战和困扰。

Kubernetes 生态自身的能力池诚然丰盛，然而社区里却并没有一个可扩大的、方便快捷的形式，为云原生架构下混合、分布式的部署环境引入统一的下层形象来为利用交付进行建模。利用交付过程下层形象能力的缺失，使 Kubernetes 的复杂性无奈做到向利用开发人员屏蔽。

下图展现了一个云原生下的 DevOps 流水线的典型流程。首先是代码的开发，代码托管到 Github，再接入单元测试的工具 Jenkins，此时根本研发已实现。再接着到镜像的构建，波及到配置、编排等。云原生中能够用 HELM 打包利用。打包好的利用部署到各个环境中。但整个过程中会面临很多挑战。

首先，在不同的环境须要不同的运维能力。其次，配置的过程中要创立云上数据库，须要另外关上一个控制台来创立数据库。还须要配置负载平衡。在利用启动当前还须要配置额定的性能，包含日志、策略、平安防护等等。能够发现，云资源和 DevOps 平台体验是割裂的，外面充斥着借助内部平台创立的过程。这对老手来说是十分苦楚的。

在容器呈现之前的传统的 DevOps 模式须要不同的流程和工作流。容器技术是以 DevOps 的视角构建的。形象的容器所提供的性能会影响咱们如何对待 DevOps，因为随着微服务的呈现，传统的架构开发将发生变化。这意味着要遵循在 Kubernetes 上运行容器的最佳实际，并将 DevOps 的理念向 GitOps、DevSecOps 扩大，使云原生下的 DevOps 更加高效、平安、稳固、牢靠。

OAM（Open Application Model）试图提供一种云原生利用的建模语言，以实现研发和运维的视角拆散 ，使 Kubernetes 的复杂性无需透传至研发，运维通过提供模块化、可移植、可扩大的个性组件，撑持各种简单的利用交付场景，从而实现云原生利用交付的敏捷性和平台无关性。 其在 Kubernetes 上的残缺实现 KubeVela，曾经被业界认为是构建下一代继续交付形式及 DevOps 实际的外围工具。

最近，阿里云在 2021 云栖大会上公布了云效应用交付平台 AppStack，旨在进一步减速企业云原生 DevOps 规模化落地。据云效应用交付平台 AppStack 研发团队介绍，其在设计之初就全面反对原生 Kubernetes 和 OAM/KubeVela，以实现对利用部署架构无绑定、无侵入，使企业不必放心迁徙以及技术改造老本。这也标记着 KubeVela 正在成为云原生时代利用交付畛域的重要基石。

在云原生理念迅速遍及的明天，混合环境部署（混合云 / 多云 / 分布式云 / 边缘）曾经成为了大多数企业应用、SaaS 服务、利用继续交付平台的必然选择，而云原生技术的发展趋势也正在朝着“统一的、跨云、跨环境的的利用交付”一直迈进。

KubeVela 作为一个开箱即用、面向古代微服务架构的利用交付与治理平台，曾经正式公布 1.1 版本。在此版本中，KubeVela 更加聚焦面向混合环境的利用交付流程，带来了多集群交付、交付流程定义、灰度公布、私有云资源接入等多个开箱即用的能力和更加敌对的用户体验，帮忙开发者从“动态配置、模板、胶水代码”的初级阶段，间接降级至“自动化、申明式、对立模型、人造面向多环境”的下一代以工作流为外围的交付体验当中。

基于 KubeVela，用户能够十分轻松地解决以下场景：

面向 Kubernetes 的多环境、多集群交付已是一个规范性需求。从 1.1 版本开始，KubeVela 不仅实现了多集群的利用交付，并且既能够独立工作间接纳管多个集群，也能够集成 OCM、Karmada 等各类多集群管理工具来进行更简单的交付动作。在多集群交付策略的根底上，用户还能够通过定义 Workflow 来管制交付到不同集群的程序、条件等工作流步骤。

Workflow 的具体应用场景则很多，比方在多环境利用交付场景中，用户能够定义不同的环境交付的程序和前置条件等。KubeVela 的工作流是面向 CD 过程的，同时也是申明式的，所以它既能够作为 CD 零碎间接同 CI 零碎（比方 Jenkins 等）对接，也能够嵌入到现有 CI/CD 体系中作为加强和补充，落地形式非常灵活。

在模型上，Workflow 是由一系列 Step 组成的，而在实现上，每一个 Step 则是一个独立的能力模块，由其具体的类型和参数来决定其具体步骤的能力。在 1.1 版本中，KubeVela 内置的 Step 曾经比拟丰盛，也非常容易扩大，帮忙用户轻松对接已有的平台能力，做到无缝迁徙。

KubeVela 的设计是从“以利用为核心”的视角登程，因而能够帮忙开发者以齐全 Serverless 的形式更好、更不便的治理云资源，而不是疲于应酬各种不同的云产品和控制台。在实现上，KubeVela 内置集成了 Terraform 来作为云资源的编排工具，并且可能以对立的利用模型反对各个云厂商上百种不同类型云服务的部署、绑定和治理。

在应用上，目前 KubeVela 将云资源分为以下三类：

作为组件：比方数据库、中间件、SaaS 服务等。比方 KubeVela 中的 Alibaba-RDS 服务就属于这种
作为运维特色：比方日志剖析、监控可视化、监控报警等服务
作为利用运行基础设施：比方 Kubernetes 托管集群、SLB 负载平衡、NAS 文件存储服务等

KubeVela 作为一个申明式的利用交付管制立体，人造就能够以 GitOps 的形式进行应用（可独自应用，也可配合 ArgoCD 等工具），并且可能为 GitOps 场景提供更多端到端的能力和加强、帮忙 GitOps 理念以更加亲民和解决理论问题的形式在企业中落地。这些能力包含：

定义利用交付工作流（CD 流水线）
解决部署过程中的各种依赖关系和拓扑构造
在现有各种 GitOps 工具的语义之上提供对立的下层形象，简化利用交付与治理过程
对立进行云服务的申明、部署和服务绑定
提供开箱即用的交付策略（金丝雀、蓝绿公布等）
提供开箱即用的混合环境 / 多集群部署策略（搁置规定、集群过滤规定、跨环境 Promotion 等）
在多环境交付中提供 Kustomize 格调的 Patch 来形容部署差别，而用户无需学习任何 Kustomize 自身的细节
……

继续打造人造面向混合环境的企业应用操作系统、让开发者享受交付利用的过程，这是 Kubevela 我的项目的指标和愿景。在接下来的 1.2 版本，KubeVela 将带来以利用为核心的控制面板 UI，实现便捷的企业应用组装、散发、交付流程，提供给开发者更简略的利用交付体验，同时笼罩边缘利用交付等更多的应用场景。

KubeVela 1.2 版本将在 2021 年 12 月举办的 KubeCon China 上重磅公布，敬请继续关注 KubVela 社区以及阿里巴巴云原生动静！

您能够通过如下形式理解更多对于 KubeVela 以及 OAM 我的项目的细节：

1）我的项目代码库：

_github.com/oam-dev/kubevela_

欢送 Star/Watch/Fork！

2）我的项目官方主页与文档：

kubevela.io/

从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢送开发者进行翻译。

3）我的项目钉钉群：23310022；Slack：CNCF #kubevela Channel

4）退出微信群：请先扫码增加以下 maintainer 微信号，表明进入 KubeVela 用户群：

戳这里，查看 KubeVela 我的项目官方主页与文档！！

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

正文完