| 编辑推荐: |
在规划新业务，或是将老应用迁移到云端时，如何选择合适的工具一直都是个伤脑筋的事。但不要担心，我亲爱的开发者们——这篇文章将通过一场终极巅峰对决来帮你理清头绪！
本文来自于beSharp，由火龙果软件Anna编辑推荐。 |
|
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:latest
variables:
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,flake8
run:
script:
- python setup.py bdist_wheel
- pip install dist/*
artifacts:
paths:
- dist/*.whl |
轮到 CodePipeline 上场：
version: 0.2
env:
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,flake8
run:
- 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 CodePipeline 得分：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 仍然是个非常优秀的服务。对团队而言，它拥有强大的功能；对开发者来说，它拥有顶级的用户体验。在某些特定的条件、特定的用例下，它仍是最好的选择。
而在其他的情况下，二选一永远不是个好主意，根据不同的需求，两种服务的共同使用可能是个更明智的选择。 |
