本文最初发布于 beSharp，经原作者授权由 InfoQ 中文站翻译并分享。

GitLab 已成为一款广受欢迎的、集众多功能于一身的 DevOps 工具，它既可以在内部部署，又有 SaaS 版本供人选择。

代码库维护、流水线运行，以及管理项目信息等常用任务，免费版 GitLab 足矣。亚马逊云服务（AWS）则采用按实际使用量付费的模式，借助一系列包括 AWS CodeCommit、AWS CodeBuild、AWS CodePipeline 在内的服务，实现了 CI/CD 的最佳实践。

在规划新业务，或是将老应用迁移到云端时，如何选择合适的工具一直都是个伤脑筋的事。但不要担心，我亲爱的开发者们——这篇文章将通过一场终极巅峰对决来帮你理清头绪！既然目标是云环境，那么我们首先需要找到一个共同的战场来展开决斗：公平起见，我们将应用 AWS 架构完善的框架详解（AWS Well-Architected Framework），该框架由 AWS 设计，旨在帮助用户设计可维护、安全、弹性、高效，且具有成本效益的应用程序和架构。

我们将以 AWS 的五大基础支柱：卓越操作、安全性、可靠性、性能效率，以及成本效益为设计参考。因为这五大支柱并不涉及 AWS 的具体服务项目，所以可以被广泛应用在任何服务或基础设施的构建上。

接下来让我们热烈欢迎选手入场！两方选手，GitLab 和 AWS CodePipeline，正在进行热身！

比赛规则

在这场 GitLab 和 AWS CodePipeline 的虚拟比赛中，规则如下：五大支柱中每一条算作一轮，最终根据支柱的设计原则进行评分。

第一轮：卓越操作

在这一轮比赛中，我们将依据以下规则进行评分：

• 以代码形式进行操作

• 频繁进行小规模、可逆修改

• 频繁完善操作程序

• 预测失败

• 从所有的操作失败中吸取教训

GitLab 和 CodePipeline 可以为不同的任务定义不同的流水线，项目的构建和部署也都可以用 yaml 模板解决。因此，定义不同阶段，并在每个阶段中执行步骤是可行的。

我们将使用这个示例。

GitLab 服务器端：

image: python:latestvariables:  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"test:  script:  - python setup.py test  - pip install tox flake8  # you can also use tox  - tox -e py36,flake8run:  script:    - python setup.py bdist_wheel    - pip install dist/*  artifacts:    paths:      - dist/*.whl

轮到 CodePipeline 上场：

version: 0.2env:  variables: PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"phases:  test:        - python setup.py test        - pip install tox flake8  # you can also use tox        - tox -e py36,flake8run:        - python setup.py bdist_wheel        - pip install dist/*        artifacts:  files:      - dist/*.whl

GitLab 允许定义构建用 image，而 CodePipeline 则允许在流水线中定义，而非是构建过程中定义 image。二者语法清晰且相当类似，派生也非常灵活。

1-1 平手。

无论如何，CodePipeline 允许使用 Cloud Formation 部署全部的基础架构堆栈。这就意味着整体架构的持续交付！

CodePipeline 暂时领先：2-1

第二轮：安全性

在这一轮比赛中，我们将根据以下规则进行评分：

• 允许追溯

• 在所有层面中实施安全防护

• 自动化最佳安全措施

• 保护传输状态与非传输状态中的数据

• 确保非授权人员无法接触数据

• 为安全事件做好准备

GitLab 提供的认证机制让用户可以利用其他 IdP，诸如 Active Directory 和 SAML 的联盟，如果有好好规划过配置的话，就将能享受到集中式用户管理的优势。总之，如果你的组同样需要 SAML SSO 的话，那么你恐怕只能选择付费计划了。

AWS CodePipeLine 使用与 AWS 相同的身份验证与授权层：其具有 Active Directory、SAML，以及......为 group 服务的 SAML SSO。鉴于 GitLab 免费版并不能提供所有的身份验证功能，AWS 领先一分。

下面让我们来看看可追溯性和让人们远离数据：GitLab 中的审计日志仅在可在付费版中查看，而 CloudTrail 的审计日志则是注册可用，并且账户中所有服务均可使用。

AWS 得分：3-1

于 GitLab 而言，最难处理的部分可以在 GitLab 上关于运行程序安全性和存储数据（缓存和构件）加密的公开 issue 和讨论中找到。

利用 AWS 服务部署应用则更需要考虑 runner-manager 角色的授权问题。部署使用不同服务的不同应用，需要授予 runner 更多的权限，或者你也可以选择生成更多的 runner，并授予他们最低访问权限。需要注意的是，这样做会导致资源数量和成本的增加。

因为 AWS 可以为每一款服务提供存储与传输时数据加密，这一轮的获胜者是 AWS。另外，IAM 角色还可以让你免去使用 token，密钥（access key）或者其他脆弱的服务认证机制。

CodePipeline 再得一分！目前比分：4-1。

第三轮：可靠性

在这一轮比赛中，我们将根据以下几点进行评分：

• 故障恢复自动化

• 恢复测试程序

• 横向扩展提高总工作负载的可用性

• 停止猜测容量

• 自动管理变更

在进一步讨论之前，请注意，这一次的结果很大程度上取决于，你对使用这两种服务中实现构建环境时的期望。

GitLab 和 AWS CodePipeline 都拥有横向可扩展的特点，二者都可以自动完成变更、无需人为干预即可自动进行高级容量规划（为 GitLab 使用单个大型内部 runner 除外）

二者各得一分，比分 5-2。

而在扩展的灵活性上，GitLab 使用的是插件系统，用户也可以使用自定义执行器。这项功能可以称得上是意外之喜了，干得漂亮 GitLab：5-3。

AWS CodePipeLine 允许用户使用多可用区部署。举例来说，这项功能可以确保在 eu-west-1-a 区出现故障时，用户的构建可以在另外两个可用区中运行。需要注意，如果你使用的是 GitLab 的 EC2 自动扩展插件，将无法实现多可用区部署。下面的配置示例来源于这个示例。

[runners.machine]    IdleCount = 1    IdleTime = 1800    MaxBuilds = 10    MachineDriver = "amazonec2"    MachineName = "gitlab-docker-machine-%s"    MachineOptions = [      "amazonec2-access-key=XXXX",      "amazonec2-secret-key=XXXX",      "amazonec2-region=us-central-1",      "amazonec2-vpc-id=vpc-xxxxx",      "amazonec2-subnet-id=subnet-xxxxx",      "amazonec2-zone=x",      "amazonec2-use-private-address=true",      "amazonec2-tags=runner-manager-name,gitlab-aws-autoscaler,gitlab,true,gitlab-runner-autoscale,true",      "amazonec2-security-group=xxxxx",      "amazonec2-instance-type=m4.2xlarge",    ]

由此可见，只设置一个子网和一个可用区是可行的。这样一来，当这个区域发生故障是，你的配置同样也会失败。AWS 得分，现在比分 6-3。

注意，虽然你可以选择使用自定义执行器来提高可靠性，但这样一来，你就需要自己开发并测试，会浪费不少时间。

接下来让我们继续最后两轮的比赛。

第四轮：性能效率

在这一轮比赛中，我们将根据以下几点进行评分：

• 先进技术的民主化

• 只需几分钟便可全球化

• 使用无服务架构

• 多做实验

• 在考虑到的情况下，请注意以下几点特殊情况
  

即使 GitLab 与 Code Pipeline 有许多共同点，但 GitLab 支持许多不同的部署和配置，在灵活性上更胜一筹。

GitLab 再得一分：6-4

另一方面，CodePipeline 对 Fargate 平台上的无服务器构建提供了更好的支持，相比之下，GitLab 对部分无服务器方式支持有限。举例来说，你不能在 fargate 自定义执行程序的同一个 Docker 套接字中使用 Docker 中的 Docker。

看来这一轮比赛又是平局收场。AWS Pipeline 和 GitLab 各得一分，现在比分：7-4。

第五轮：成本效益

在这一轮比赛中，我们将根据以下几点进行评分：

• 实现云财务管理

• 采用消费模式

• 衡量整体效率

• 拒接将钱花费在无意义的重活上

• 分析和分配支出

首先让我们来分析一下这两款服务的定价模式。GitLab 选择基于买家的定价模式，而 AWS 的账户则是免费的。CodeBuild的收费是根据用户使用资源构建的持续时间，按分钟计费。假设使用 general1.small（双核 3GB RAM），那么费用将会是 5 美元/1000 分钟。

而使用 GitLab 的共享 runner，费用将会是 10 美元/1,000 分钟（前 2,000 分钟免费）。

如果你不想使用 GitLab 的共享 runner，那么你还有 AWS 的 Auto Scaling 可选。但请记住，你需要为 runner 管理准备一个 EC2 示例，而为了构建能够扩展，你还需要再准备一个示例。你也可以可以在业务允许的情况下，选择提前购买预购示例，或者使用现货示例。

对于这一轮比赛，胜者毫无疑问：AWS CodePipeline 以更多的预建和开箱即用的集成解决方案夺得最后一分！

结论

两款最广泛使用的服务之间的友谊赛已经结束。以 8-4 的比分，让我们欢迎 AWS CodePipeline 登上冠军的领奖台！

AWS 会保持它的霸主地位吗？

不要误会，GitLab 仍然是个非常优秀的服务。对团队而言，它拥有强大的功能；对开发者来说，它拥有顶级的用户体验。在某些特定的条件、特定的用例下，它仍是最好的选择。

而在其他的情况下，二选一永远不是个好主意。根据不同的需求，两种服务的共同使用可能是个更明智的选择。

原文链接

GitLab VS AWS CodePipeline: the ultimate Battle Royal!