云原生持续交付的模式和实践
RIO(大众汽车公司的一个品牌)首席架构师Christian Deger最近在伦敦Continuous Lifecycle大会上分享了一系列实现云原生持续交付的模式和实践。Deger的演讲内容涵盖了用于独立部署管道的模式(得益于容器化)、拥有交付所有权(包括流程和基础架构两个方面)的产品团队,以及动态、不可变性和可组合的基础架构(避免单体,区分宏观和微观基础设施)。
\\
持续集成(CI)和持续交付(CD)对于经常要将独立服务部署到动态创建的基础设施中的自主团队来说至关重要。按照Deger的话说,将云原生概念和现代基础设施即代码应用于软件交付系统可以“为已经准备好介入到平台的新服务快速创建的解耦管道,并且所有内容都由代码驱动”。
\\
拥有一个可靠的交付系统,能够承受灾难并且无需等待就能提供反馈,这已成为现代软件交付的先决条件。对CI/CD基础设施进行容器化可以:
\\
- 进行独立的构建:创建带有必要代理配置文件的干净容器(例如,一个应用程序可能需要Java 8,而另一个应用程序仍在Java 7上运行),并且仅在构建期间存在。\\t
- 带来弹性:每个构建有自己的容器代理,消除等待时间并提高资源使用率。\
将此基础设施定义为代码可以从零开始恢复交付过程(例如发生灾难时),并避免出现CI/CD雪花服务器(snowflake server),也就是说,通过UI进行且未被版本控制系统捕获的变更会导致配置的漂移。
\\
Deger强调了将快速且可预测地设置新管道(对于新服务)作为项目第一要务的重要性(否则团队就会为了避免较长的启动时间,对现有服务负起更多的责任)。将管道(阶段、任务、依赖关系、构件等)定义为代码/配置,可以快速从灾难中恢复,因为这样可以快速重新创建管道,并且可以以最短的延迟交付服务变更。大多数管道编排工具都支持管道即代码(尽管具有不同的实现)。
\\
Deger建议对管道定义和相应的服务代码进行版本控制,因为自治团队需要拥有完整的交付管道。实际上,Deger建议每个服务都应该有自己的代码库和实际的服务代码,以及管道定义和基础设施代码。对后者的变更应像通常的应用程序变更一样,都要流经管道,让它们变得可追踪和可重复。这意味着基础设施创建或更新需要通过管道进行动态触发。
\\
在Deger看来,避免出现基础设施单体(包含所有服务定义的单个仓库或者按层进行分组的定义,如如数据库、计算实例或中间件)才是最根本的。他建议创建与服务边界(微基础设施)相一致的独立基础设施栈,并在全局栈(宏基础设施)中留下一小组交叉、缓慢变化的非服务特定方面,如网络和安全)。服务从它们共享的宏基础设施中导入参数,以便能够在其中运行。
\\
\\
图片由Christian Deger提供
\\
另一个主要想法是解耦(或控制)多层服务之间的依赖关系,而不仅仅是应用程序代码。除了每个服务的独立管道之外,其他的依赖关系——例如服务的基础映像(AMI、Docker等)——应该是静态的(针对特定版本),避免一个镜像更新同时触发多个管道,导致重新部署生产系统的风险。
\\
也许Deger提出的最有争议的建议是移除管道中的staging环境。由于服务的变化率很高(至少每小时),Deger声称几乎不可能在staging环境中针对所有其他服务的当前版本测试新服务。这可能会导致等待时间变长,因为staging环境将成为瓶颈,或者变成发布单体,因为多个服务的变更在staging环境耦合在一起,然后通过测试后一起发布。
\\
相反,通过依靠基于消费者驱动的合约测试以及将生产中的修复时间(MTTR)降至最低,可以独立部署服务变更并对其进行监控,以确保它们在生产中按照预期运行。为进一步降低影响,部署策略应依赖金丝雀发布(特别是密切监控新实例的错误率、延迟和负载)、功能开关(快速关闭发生故障的功能)和蓝绿部署(如果没有数据库变更的话,可快速回滚到之前的环境)。在某些特定情况下(例如重大代码重构),可能可以考虑使用黑暗启动。部署新版本,并发出与生产环境相同的请求,从功能性上面判断响应消息是否正常,新实例是否可以处理负载。
\\
在整个演讲中,Deger几次强调了团队拥有服务的重要性,从交付(团队负责他们自己的管道和CI实例)到基础设施(团队定义服务运行的微堆栈)以及运行时(微堆栈包括可操作性特性,如日志和监控)。他建议共享模式、实践和指南,但不要将这些工作集中化,因为这样的话团队将失去自主权,并且对其他团队的依赖会降低交付速度。
\\
\\
图片由Christian Deger提供
\\
查看英文原文:Patterns and Practices for Cloud Native Continuous Delivery
云原生持续交付的模式和实践相关推荐
- 使用 KubeSphere 和极狐GitLab 打造云原生持续交付系统
KubeSphere 简介 Kubernetes 是一个非常复杂的容器编排平台,学习成本非常高,KubeSphere 所做的事情就是高度产品化和抽象了底层 Kubernetes,是一个面向云原生的操作 ...
- KubeMeet 新年首站成都开放报名,5 场云原生应用交付开源实践
"九天开出一成都,万户千门入画图" KubeMeet 开发者沙龙新年首站 "锁定" 成都,本场沙龙将以「云原生应用交付与管理」为主题,结合云原生应用交付.自动化 ...
- OAM 与 KubeVela:下一代云原生应用交付和管理实践
本篇文章是我在 "2022云原生超级英雄会" 直播中分享的<OAM 与 KubeVela:下一代云原生应用交付和管理实践>演讲内容整理. 演讲视频 在业务不断扩张的当下 ...
- 应云而生,幽灵的威胁 - 云原生应用交付与运维的思考
作者 | 易立 阿里云资深技术专家 来源|阿里巴巴云原生公众号 本系列文章: 第一篇 - 云原生基础设施 第二篇 - 云原生软件架构 第三篇 - 云原生应用交付与运维(本文) 过去的 2020 是充 ...
- 应云而生,幽灵的威胁 - 云原生应用交付与运维
简介:过去的 2020 是充满不确定性的一年,但也是充满机遇的一年.突发的新冠疫情为全社会的数字化转型按下加速键.云计算已经不再是一种技术,而是成为支撑数字经济发展和业务创新的关键基础设施.在利用云计 ...
- 【附赠PPT】 KubeMeet 成都站回顾:让云原生应用交付和管理变得更简单
1 月 15 日,由云原生基金会 CNCF 和阿里云开发者 ACE 共同主办的 「KubeMeet · 云原生应用交付与管理专场」开发者沙龙在成都举办.技术讨论.积极互动.开源项目近距离接触-5 场开 ...
- KubeMeet 直播 | 现场直击大规模集群、混合环境下的云原生应用交付难题
伴随着 Kubernetes 生态逐步完善,越来越多的大型互联网终端企业开始加入到云原生梯队中,云原生应用交付与管理正在成为 Kubernetes 之上重要的价值聚焦点. 2022 年 1 月 15 ...
- 基于云原生的大数据产品前端实践 | 第七期图文直播文字回放
点击"蓝字"关注我们 2月5日晚,智领云第七次社群图文技术直播如约而至.本次直播由智领云Web开发经理陈磊为大家分享了<基于云原生的大数据产品前端实践>主题内容,其中 ...
- 火山引擎云原生大数据在金融行业的实践
本文整理自火山引擎云原生计算研发工程师-张云尧 在 DataFun 智能金融峰会上的演讲.大数据架构向云原生演进是行业的重要趋势,火山引擎协助关键金融客户在大数据云原生方向进行了深度实践,形成了整体解 ...
最新文章
- PCL滤波介绍(2)
- 基于python的天气预报系统,基于python编写的天气抓取程序
- 轻松简单地开发Web Services 2
- prfm预加载指令使用说明
- Android 可视化界面编辑器无法显示界面问题的终极解决方案
- 教你几招识别和防御Web网页木马
- ENVI5.4完美实现MODIS NDVI数据格式转换和投影变换
- redis缓存穿透,缓存击穿与缓存雪崩详解
- tcp拥塞控制_面试必备TCP(四):拥塞控制
- ❤️大佬都在学什么?Python爬虫分析C站大佬收藏夹,跟着大佬一起学, 你就是下一个大佬❤️!
- gmm中隐变量是什么的_机器学习-隐变量模型和期望最大算法
- DirectX 初始化DirectX(手写和红龙书里面的方式)
- 论文中设置章节自动编号
- 强化学习10——迭代学习
- 一个变量对应多个标量的结果(平均值加标准差),Excel作图方法(多数据作图方法)
- IDEA中suppress warnings
- linux Windows双系统时间不一致的解决办法
- B/S三层架构[转载]
- 算法谜题——三个水壶问题
- 【正本清源】关于extern、static、const的正确使用方法