简介：DevOps文化以及支撑其落地的自动化工具和平台能力，在云原生架构逐渐普及的背后起到了关键作用。作者：西洋云原生正在成为企业业务创新和解决规模挑战的加速器。云原生带来的变革不仅限于基础设施、应用架构等技术层面，还包括研发理念、交付流程、IT组织方式等方面的变革，也在推动企业IT组织、流程和文化的变革。在云原生架构日益流行的背后，DevOps文化及其支撑其落地的自动化工具和平台能力发挥了关键作用。云原生带来的研发运维协同接口与云原生相比，DevOps并不是什么新鲜事物，其实践早已渗透到现代企业应用架构中。DevOps强调团队间的沟通和快速反馈，通过构建自动化的持续交付（ContinuousDelivery）和流水线应用发布方式，达到快速响应业务需求、交付产品、提升交付质量的目的。随着容器技术在企业中的大规模应用，云计算可编程基础设施、Kubernetes声明式API等能力加速了开发和运维角色的融合。云原生的大趋势已经让云原生成为企业的标配，围绕云原生定义下一代研发平台成为必然，这也迫使IT组织方式的进一步变革——新平台工程团队开始出现。在此背景下，如何在云原生环境下更高效地践行DevOps成为新的话题和需求。下一代DevOps平台的演进趋势伴随着Kubernetes生态从底层到应用层能力的逐步提升。平台工程团队可以更轻松地根据业务场景和终端用户的实际需求构建不同的应用平台，同时也为上层应用开发者带来收益。挑战和迷恋来了。Kubernetes生态本身拥有丰富的能力池，但社区并没有一种可扩展、方便快捷的方式来为云原生架构下的混合分布式部署环境引入一致的上层抽象来对应用交付进行建模。应用交付过程上层缺乏抽象能力，使得Kubernetes的复杂性无法被应用开发者屏蔽。下图展示了一个典型的云原生下DevOps流水线流程。首先是代码开发，代码托管在Github上，然后连接到Jenkins这个单元测试工具。至此，基础研发已经完成。然后是镜像的构建，涉及到配置、编排等，HELM可以用来打包云原生的应用。打包的应用程序被部署到每个环境。但在此过程中存在许多挑战。首先，不同的环境需要不同的运维能力。其次，配置过程中要在云端创建数据库，需要另外打开一个控制台创建数据库。您还需要配置负载平衡。应用启动后，还需要配置一些额外的功能，包括日志、策略、安全防护等。可以发现，云资源和DevOps平台体验是分离的，充满了借助外部平台进行创造的过程。这对于新手来说是非常痛苦的。容器之前的传统DevOps模型需要不同的流程和工作流。容器技术是从DevOps的角度构建的。抽象容器提供的功能将影响我们对DevOps的看法，因为随着微服务的出现，传统的架构开发将发生变化。这意味着遵循在Kubernetes上运行容器的最佳实践，并将DevOps的概念扩展到GitOps和DevSecOps，使云原生下的DevOps更加高效、安全、稳定和可靠。OAM（OpenApplicationModel）试图为云原生应用提供一种建模语言，将研发和运维的视角分离，使得Kubernetes的复杂性不需要透传给研发，OAM提供了模块化、可移植、可扩展的特性。扩展特性组件支持各种复杂的应用交付场景，实现云原生应用交付的敏捷性和平台无关性。其在Kubernetes上完整实现KubeVela，已被业界认为是构建下一代持续交付方式和DevOps实践的核心工具。近日，阿里云在2021云栖大会上发布了云效能应用交付平台AppStack，旨在进一步加速企业云原生DevOps的规模化落地。据云端应用交付平台AppStack研发团队介绍，其在设计之初就全面支持原生Kubernetes和OAM/KubeVela，实现对应用部署架构的无绑定、无侵入，让企业不必担心迁移和技改成本。这也标志着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内置了丰富的Steps，非常容易扩展，帮助用户轻松对接现有平台能力，实现无缝迁移。以应用为中心的云资源交付KubeVela是从“以应用为中心”的角度设计的，因此它可以帮助开发者以完全无服务器的方式更好、更方便地管理云资源，而不是纠结于各种不同的云产品和控制台。在实现上，KubeVela内置集成了Terraform作为云资源编排工具，可以支持以统一的应用模型部署、绑定和管理来自各个云厂商的数百种不同类型的云服务。在用途上，KubeVela目前将云资源分为以下三类：作为组件：如数据库、中间件、SaaS服务。比如KubeVela中的Alibaba-RDS服务就属于这种运维特性：比如日志分析、监控可视化、监控告警等作为应用运行基础设施的服务：比如Kubernetes管理的集群、SLB负载均衡、NAS文件存储服务等更容易落地GitOps持续交付实践KubeVela作为声明式应用交付控制平面，自然可以以GitOps的形式使用（可以单独使用，也可以与ArgoCD等工具配合使用），可以提供更多端GitOps场景的端到端解决方案。帮助GitOps概念以更易于访问和解决问题的方式在企业中落地的功能和增强功能。这些能力包括：定义应用交付工作流（CDpipeline）处理部署过程中的各种依赖关系和拓扑结构在现有各种GitOps工具的语义之上提供统一的上层抽象，简化统一的应用交付和管理流程云服务声明、部署、服务绑定提供开箱即用的交付策略（金丝雀、蓝绿发布等）提供开箱即用的混合环境/多集群部署策略（放置规则、集群过滤规则、跨环境推广等）提供Kustomize风格的Patch来描述多环境交付的部署差异，用户无需了解Kustomize本身的任何细节……KubeVela1.2版本即将发布，持续打造面向自然混合环境的企业应用操作系统，让开发者享受交付应用的过程，这是Kubevela项目的目标和愿景。在接下来的1.2版本中，KubeVela将带来以应用为中心的控制面板UI，实现便捷的企业应用组装、分发和交付流程，为开发者提供更简单的应用交付体验，并覆盖边缘应用交付等。许多使用场景。KubeVela1.2版本将于2021年12月在KubeConChina发布，请持续关注KubVela社区和阿里云原生动态！原文链接本文为阿里云原创内容，未经许可不得转载。
