十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
本文整理自Hank Hudgins,Capital One高级工程师,在JFrog 2019用户大会上的讲演《Automated Artifactory HA Pipeline》。
创新互联长期为上千家客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为绿园企业提供专业的成都网站设计、网站制作,绿园网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。Capital One是美国大的数字化银行之一,其IT管理方法和应用技术也极为敏捷,全球拥有上万研发,具备非常丰富的 DevOps落地经验。在Capital One的DevOps体系当中,有很多类似于JFrog Aritfactory的HA(高可用)应用服务集群。众所周知,HA集群的运维,如升级、扩容、打补丁等工作,要想在保持用户服务不中断,服务水平不降级的前提下完成,尤其是在像Capital One这么大规模的DevOps系统当中,是十分困难、复杂,和高风险的。
Captital One使用的Artifactory为其DevOps体系中的制品及依赖管理提供了企业级解决方案,拥有工作(primary)和容灾(HR)两类HA集群。Hank所在的Artifactory维护团队,针对Artifactory HA集群维护的难点,通过建设和运行自动化的流水线,在不影响用户使用和服务水平的前提下,自动、高效、保质地完成了诸如版本升级、配置更新、补丁加载等工作,并且在检测到问题时,还能够实现自动化的回滚。在本次讲演中,Hank就介绍了这套自动化流水线的组成与特色。
Capital One采用这套可靠的自动化流水线,在Artifactory HA集群的维护工作中获得了良好的收益:
首先是通过自动化加速了维护进程,使得开发人员能够集中精力进行研发,而不需要考虑重复性的部署和测试任务;其次,流水线的可复用性也为维护工作提供了便捷的可扩展性,通过修改相关配置,流水线就能在新的环境中进行部署;最后,流水线还提供了可以快速检测缺陷,并实现无缝、高效回滚的部署过程。
该自动化流水线是按下述方式组成的:
首先是利用Jenkins驱动整个流水线,并集成GitHub进行触发:
· 每个Pull Request会触发小规模的测试以得到快速反馈。这些测试不是HA集群范围的,但可以得到快速验证;
· 每个Merge会触发研发环境HA集群范围的部署,并进行相关测试;
· 标签(Tag)被用来标记代码更新的验证阶段和对应的环境。
其次,利用Terraform创建基础设施,实现了“类”蓝/绿的发布。
最后,利用Chef cookbook实现针对各种应用服务的操作和配置更新。除了Artifactory,这些应用服务还包括了相关用于反向代理的Nginx、监控的Datadog,以及日志收集的Splunk。
接下来,Hank逐一介绍了这套自动化流水线各个阶段的任务及实现方式。
首先是代码的静态分析,针对Pull Request和Merge运行。分析的目的是对代码结构进行快速验证和反馈,确保其符合业界标准。流水线集成了一系列的Linter来实现针对不同类型代码的静态分析。
接下来是安全测试,这在流水线当中体现了“左移”的原则,能够在真正部署之前尽早的检测和发现潜在的安全漏洞。目前的安全测试分两类,一类是静态安全测试,即通过分析代码结构来发现如SQL注入、Cross-site脚本等安全隐患;另一类是JFrog Xray提供的依赖测试,检测三方依赖包中是否包含已知安全漏洞,并推荐对应的修复版本。
下一步是单元/集成测试,用于验证代码的更新不会破坏预期的功能。这一步测试也可以应用于Artifactory的Custom user plugin的测试。流水线通过启动包含Artifactory的容器,安装并测试这些custom plugin,确保其正确工作,而不需要连接到真正的Artifactory HA集群。
在完成了上述初步的测试之后,自动化流水线进入发布过程。首先要把部署相关的文件暂存到可靠的位置,这样在集群自动缩放的过程中不会依赖到其他系统,也包括Artifactory自身。目前,部署的相关文件,包括二进制包和Chef cookbook,都从Artifactory下载并缓存到S3存储上。
自动化流水线的部署阶段实现了“类”蓝/绿的部署过程,能够保证新集群的部署不会影响到Artifactory的正常服务:
1. 把用户流量切换到容灾集群;
2. 缩容现有工作集群,仅保留几个节点(保持和容灾集群的数据同步),不包括primary节点(由于Artifactory HA集群实现了多活的架构,每个节点都是支持读/写的,所以缩容primary节点并不会影响正常服务)。
3. 基于同样的数据库和S3存储,部署新的工作集群,包括新的primary节点。
4. 当新的工作集群通过测试后,再把用户流量切换回新的工作集群。
5. 之后再对容灾集群进行升级部署。
在上述部署过程中,两个Artifactory集群之间始终保持着数据同步,所以从用户的角度来看,部署是无缝切换的。
部署完成之后,要立即对集群中的各个应用服务进行检测。Jenkins通过SSH通道访问新的服务,并运行测试,确保Artifactory、Nginx等应用服务运行正常,相关配置文件的内容、位置、权限都部署正确,以及所有的网络端口都正常开通。如果检测失败,将会启动回滚过程。
接下来要运行系列的测试,确保Artifactory的各个repository都工作正常,包括能够正确拉取Docker镜像。同时,也要检测新的系统配置是否会影响制品依赖的解析,以及对不同虚拟repository的制品上传。
最后,还要进行性能测试,确保部署后集群性能没有下降。目前是利用Jmeter来模拟产品级流量,尽可能的匹配峰值流量时的API调用频率。常规15分钟的负载测试作为流水线的一部分,而可选的1小时负载测试,只有大的变更时才会执行。
性能测试的难点在于流量的建模,这是因为Artifactory的全语言特性带来的复杂性,支持多种数据包类型,及对接相应的包管理系统。通过分析Artifactory日志,获得了用于测试的API调用序列。
最后,是自动化流水线当中的回滚机制。目前实现了两种回滚:
· In-region回滚。当部署后的测试失败时,马上启动自动化回滚,删除新的集群,并恢复旧的集群。
· DR容错回滚。当工作集群升级成功后,或监测几天用户流量,没有问题的时候再更新容灾集群。如果在这几天中发现问题,就会启动容错回滚:先把用户流量切换到DR集群,然后把工作集群回滚到之前版本,数据库回滚到之前的快照,再通过Artifactory Replication同步数据,最后再把流量切换回回滚后的工作集群。
数据库的回滚是个难题。在大版本的升级过程中,可能会有DB schema的变化,这时自动化的数据库回滚很难实现,目前暂时还是通过手工操作来完成。
Capital One通过自动化流水线实现Artifactory HA集群的维护工作,获得了很好的效果和收益,加速了发布过程,提供了良好的可复用性和扩展性,也能够启动有效的回滚机制。
通过自动化流水线的应用也可以看出,即使如Artifactory这样成熟的商业化产品,也需要对基础架构和配置进行全面的测试。
最后,自动化流水线本身也是需要持续的投资和提升的。