您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
   
 
     
   
 订阅
  捐助
CI/CD 工具选型:GitLab 还是 AWS?
 
 
 
次浏览 评价:  
2021-1-25 
 
编辑推荐:
在规划新业务,或是将老应用迁移到云端时,如何选择合适的工具一直都是个伤脑筋的事。但不要担心,我亲爱的开发者们——这篇文章将通过一场终极巅峰对决来帮你理清头绪!
本文来自于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 仍然是个非常优秀的服务。对团队而言,它拥有强大的功能;对开发者来说,它拥有顶级的用户体验。在某些特定的条件、特定的用例下,它仍是最好的选择。

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

   
次浏览     评价: 订阅 捐助
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试