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

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