Captial One如何实现Artifactory HA集群的自动化维护

最新推荐文章于 2024-01-19 10:16:30 发布

JFrog捷蛙中国

最新推荐文章于 2024-01-19 10:16:30 发布

阅读量317

点赞数

分类专栏： JFrog Artifactory

本文链接：https://blog.csdn.net/wangqingjiewa/article/details/103764019

版权

JFrog 同时被 2 个专栏收录

87 篇文章 2 订阅

订阅专栏

Artifactory

68 篇文章 11 订阅

订阅专栏

一、背景

本文整理自Hank Hudgins，Capital One高级工程师，在JFrog 2019用户大会上的讲演《Automated Artifactory HA Pipeline》。

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的正常服务：

把用户流量切换到容灾集群；
缩容现有工作集群，仅保留几个节点（保持和容灾集群的数据同步），不包括primary节点（由于Artifactory HA集群实现了多活的架构，每个节点都是支持读/写的，所以缩容primary节点并不会影响正常服务）。
基于同样的数据库和S3存储，部署新的工作集群，包括新的primary节点。
当新的工作集群通过测试后，再把用户流量切换回新的工作集群。
之后再对容灾集群进行升级部署。

在上述部署过程中，两个Artifactory集群之间始终保持着数据同步，所以从用户的角度来看，部署是无缝切换的。

部署完成之后，要立即对集群中的各个应用服务进行检测。Jenkins通过SSH通道访问新的服务，并运行测试，确保Artifactory、Nginx等应用服务运行正常，相关配置文件的内容、位置、权限都部署正确，以及所有的网络端口都正常开通。如果检测失败，将会启动回滚过程。

接下来要运行系列的测试，确保Artifactory的各个repository都工作正常，包括能够正确拉取Docker镜像。同时，也要检测新的系统配置是否会影响制品依赖的解析，以及对不同虚拟repository的制品上传。

最后，还要进行性能测试，确保部署后集群性能没有下降。目前是利用Jmeter来模拟产品级流量，尽可能的匹配峰值流量时的API调用频率。常规15分钟的负载测试作为流水线的一部分，而可选的1小时负载测试，只有大的变更时才会执行。

性能测试的难点在于流量的建模，这是因为Artifactory的全语言特性带来的复杂性，支持多种数据包类型，及对接相应的包管理系统。通过分析Artifactory日志，获得了用于测试的API调用序列。

最后，是自动化流水线当中的回滚机制。目前实现了两种回滚：

In-region回滚。当部署后的测试失败时，马上启动自动化回滚，删除新的集群，并恢复旧的集群。
DR容错回滚。当工作集群升级成功后，或监测几天用户流量，没有问题的时候再更新容灾集群。如果在这几天中发现问题，就会启动容错回滚：先把用户流量切换到DR集群，然后把工作集群回滚到之前版本，数据库回滚到之前的快照，再通过Artifactory Replication同步数据，最后再把流量切换回回滚后的工作集群。

数据库的回滚是个难题。在大版本的升级过程中，可能会有DB schema的变化，这时自动化的数据库回滚很难实现，目前暂时还是通过手工操作来完成。