火山引擎-张起彤-基于云原生范式构建开发者平台实践

基于云原生范式构建开发者平台实践 张起彤火山引擎云原生架构师 www.top100summit.com 基于云原生范式构建开发者平台实践 请插入您的照片 讲师简介 “负责火山引擎云原生交付运维体系建设和研发效能改进。 www.top100summit.com ” 张起彤 火山引擎云原生架构师 www.top100summit.com 目录 •概念介绍——平台工程及其能力要素介绍 •案例分析——多云异构大型系统的复杂交付案例，挑战和解法 •设计实现——如何基于云原生构建完整的内部开发者平台体系 •基于云原生GitOps&IaC方案，实现编排交付 •基于Backstage统一数据模型与插件体系的开发者门户 •通过CI/CD流程平台驱动交付流程 •案例效果、总结与展望 www.top100summit.com 亮点介绍 •近年来业内兴起了对devOps一些反模式的讨论，萌生了“平台工程(platformengineering)”的理念。平台工程核心动机在于找到研发自助和认知负载的平衡，不限于单个技术或者工具，更聚焦在以提升开发者工作效率和体验为核心，将成熟工具粘合在一起构建合适的工具链路。 •本篇会结合一个真实的多云多应用的复杂系统交付场景，探讨如何基于云原生技术体系，构建完整的内部开发者平台体系，包括GitOps&IaC编排交付设计、平台动态建模与插件扩展原理、开发者门户设计思路等。最终实现交付部署和CICD开发过程的高度集成化、自助化 成功要点 •基于IaC&GitOps的统一编排交付，实现开发者可自助交付 •构建可扩展的开发者平台&门户，提升开发者工具集中度，优化开发者体验 案例背景平台工程理念 DevOps 目标：提高软件工程迭代和运维效率文化："youbuildit,yourunit" 工具：开发&运维、代码&配置、XaaS、敏捷 信息爆炸：我是谁/我在哪儿/做什么?->认知负担 平台建设难题：自研？开源？一站式？->缺乏平台标准 www.top100summit.com 平台工程 新的目标：从“能用”到“好用”，强调开发者自助新的分工：平台团队和平台工程师 平台工程是对devOps的继承和发展 •本质上还是软件工程层面提效降本 •践行平台工程，依赖devOps的成熟度 新的工具：例如内部开发者平台和开发者门户 案例背景DevOps是平台工程的基础 www.top100summit.com 丰富的DevOps工具选择 •基础设施提供方：IaaS、PaaS、存储、中间件 •CI/CD工具链：制品仓库、CI工具、CD工具 •平台界面：配置管理、API和CLI、文档和搜索 •配套能力：权限/可观测/安全 平台工程衍生出的新工具 •内部开发者平台(InternalDeveloperPlatform,IDP) •开发者门户(DeveloperPortal,DevPortal) 《CNCFPlatformsWhitePaper》https://tag-app-delivery.cncf.io/whitepapers/platforms/ www.top100summit.com 案例背景平台工程的增量要素 内部开发者平台(InternalDeveloperPlatform,IDP) •定位：平台团队构建的，粘合应用交付的技术和工具链 •价值：降低开发者认知负载/开发者自助/构建黄金路径 开发者门户(DeveloperPortal,DevPortal) •定位：面向开发者服务的站点Portal，所有软件、工具、资源的动态集成视图层 •价值：解决业务软件信息孤岛和内部研发运维工具碎片化严重的问题 平台工程能力矩阵 平台工程相关产品引用自https://internaldeveloperplatform.org/platform-tooling/ 案例背景平台工程要解决DevOps的什么问题？ •工具多而杂？ •学习成本高？ •扩展迭代难？ •数据分散？ •平台汇集的工具、能力和流程均由领域专家精心挑选，并经过封装。 •开发者不需要很高认知成本，就能够自主完成研发、交付、运维工作 •面向开发者工作界面一定是可扩展的，以应对业务系统/基础设施/工具链层面的持续变化 •解决传统孤岛问题，实现工具和数据资产重用 www.top100summit.com 面向开发者 提供集成化+自助式的工具链和工作流 面向平台团队 标准化的集成范式、解决扩展性问题 www.top100summit.com 问题与挑战多云异构大型系统的复杂交付实践-场景介绍 多云异构大型系统的场景特点 •某大型云服务系统，本身包含多应用多集群构成，并且需要在多地域+公私有云场景交付 对交付运维的挑战 •公私有云交付的基础设施差异 •多种异构的制品形态（二进制/容器） •多组件依赖关系和配置组合复杂 •多地域多集群的规模化运维 问题与挑战开发者痛点和解决思路 通过访谈，获得开发者的进一步痛点： •工具杂乱：不同架构的组件及其依赖没有统一部署方式，用户学习和操作成本高，平台侧想都集成起来成本也高 •配置管理复杂：多环境配置管理效率低易出错、多人多版本协同经常互相冲突、出问题很难追溯和排查 •CI/CD工具分裂：虽然是同一个软件系统，但公私有云的开发-测试-发布流程完全割裂，开发者难以学习适应 •烟囱&孤岛严重：各种业务定制了自己专属的运维/运营后台，人力重复投入大，入口分散并且数据和界面不能打通复用 结合平台工程理念的解决思路： 基于IaC+GitOps的统一编排交付，实现开发者可自助交付 •实现基础设施+应用的统一编排交付，抹平多云交付的环境层差异 •基于GitOps，面向开发者提供可自助的统一配置和交付界面 www.top100summit.com 构建可扩展的开发者平台&门户，提升开发者工具集中度，优化开发者体验 •基于开发者平台能力集成标准，构建可扩展的开发者门户，提升信息与工具集中度，提升开发者体验 基于开发者平台能力集成标准，建立围绕版本研发生命周期的轻量CI/CD协同平台 www.top100summit.com 破题思路平台工程重点工作 【Step1】平台编排框架，实现IaC统一编排交付 •应用交付模型 •可扩展的IaC部署控制器 【Step2】GitOps，解决配置管理和持续交付问题 •GitOps流程引擎pull-modelive-diff •配置管理模板语言 【Step3】定义开发者平台工具前后端集成标准 •Entity-Relation统一元数据建模 •前后端插件集成标准 【Step4】构建开发者可自助、可无限扩展的站点 •开发者门户 •CI/CD流程协同平台 破题思路可扩展的开发者平台整体架构 交付能力的”无限”扩展：基于平台编排框架，实现IaC+GitOps持续交付体系 开发者门户的”无限”扩展：基于Entity模型范式和基于模型的统一插件规范，实现各类开发者工具的无缝集成 www.top100summit.com 核心实践 背景概念-平台编排器 www.top100summit.com 平台编排器(PlatformOrchestrators) 平台编排器是IDP的核心，支持动态配置管理，并包装了RBAC、基础设施编排、应用程序配置管理和自动化部署执行等繁重的软件交付工作。作为IDP的核心，编排器使开发人员能够自助创建新的环境、拉起应用负载以及配套数据库、计算、网络、PaaS等资源，而无需编写复杂的脚本或者操作步骤指南。 https://developer.humanitec.com/getting-started/pe/introduction/ 核心实践 平台编排框架-介绍 www.top100summit.com 平台编排框架，致力于提升产品级系统的多应用协同交付的效率和一致性。基本由应用交付模型渲染引擎和可扩展的K8S部署控制器构成。 有如下特点： •支持同一个产品下多应用、多集群自动化交付 •可扩展的IaC部署控制器，实现基础设施和应用的整体编排交付 •可移植应用定义，向开发者屏蔽基础设施细节 •配置分层渲染，实现应用与基础设施、应用与应用间的配置动态引用，解决复杂产品级系统带来的配置复杂性 •支持健康状态和配置漂移检查+自愈能力，不仅仅是进程级不可变（容器），整个产品系统运行时不可变 核心实践 平台编排框架-应用交付模型设计 平台-产品-应用三层分层交付模型，将不同技术角色关注点进行分离 •研发角色：负责应用自身配置模型的定义，包括应用工作负载、资源服务化需求、，对外暴露应用可运维配置项 •交付/SRE角色：基础设施和配置内容管理；运维特性(Traits)开发 •平台管理：制定配置模型之间的配置变量封装标准和层叠引用关系 其中TPL配置模板是应用开发者可自助管理的应用定义，包括： •部署配置：默认部署的命名空间/部署顺序定义等 •运维特征：traits引入，提供编译打包及运行时阶段的增强能力 •交付参数：options，基于gotemplate语法，动态渲染应用部署时配置值。 www.top100summit.com 核心实践 平台编排框架-交付能力设计 www.top100summit.com 针对公有云/混合云设计了统一的打包交付形态，提供多样打包形态和部署工具 场景规模可伸缩，业务具体可选择组件级持续交付、产品级持续交付、解决方案(局点)级别交付 产品级交付时，可基于应用-资源依赖关系定义，动态决定部署/升级顺序、联合灰度策略等 核心实践 背景概念-IaC、GitOps www.top100summit.com 基础设施即代码（IaC） 通过编写和执行代码来定义、部署、更新和销毁基础设施；可通过IaC管理的包括不限于：应用部署定义、数据库配置定义、云资源定义等 GitOps 一种新的持续交付范式，使用Git进行开发和运维的全自动化流水线/工作流；复用Git版本控制系统跟踪和审批对运行时环境的变更 https://narasimmantech.com/ why-should-you-learn-infrastructure-as-code-as-a-devops-engineer/ 引用自《使用GitOps实现Kubernetes的持续部署：模式、流程及工具》 核心实践 GitOps持续交付-整体流程设计 www.top100summit.com •git配置仓库，存储结构化配置模板和多环境配置值，本地可执行Local-Build，查看静态配置渲染后终态 •提交部署时，基于交付编排模板和环境配置融合渲染，生成终态清单（dry-run） •结合实际生产环境与全量终态配置做live-diff，没问题后提交部署，除了暂停确认之外，其余全自动无需人工干预 核心实践 关键能力 GitOps持续交付-配置模板语言方案 Kustomize支持component与patch能力，components自身也可以相互组装，使 •全量交付资源IaC化 •找到commit节点，可将环境迭代至任意一个时间点的版本 •按需引用的“砖块”化公共配置管理 •支持本地可Local-Build •支持k8syaml终态dry-run，与环境实时态diff能力 •支持敏感信息存储 得公共配置的引用与覆盖，变得非常灵活。可以把配置的最终交付，想象为“搭积木”的过程 •什么是component：用积木块搭建起来的模组，模组也可以引用组成更大模组 •什么是patch：对于某个环境，引用component后还可以通过Patch进行某些小的替换。 www.top100summit.com 核心实践 GitOps持续交付-文件管理方案 •整个产品共享一个配置仓库 •全局配置有独立的配置目录 •独立应用目录存放应用配置 •全局配置与应用配置，都可以按照环境进行分级 www.top100summit.com 核心实践 背景概念-开发者门户