【51CTO.com快译】众所周知,随着DevOps带来了巨大的转变,容器让开发团队能够以前所未有的速度交付出程序代码。当然,我们仍然需要完成构建、包装和部署容器的过程。这就是为什么我们要使用容器管道(container pipelines)的原因。

如今,业界有着许多在容器管道方面的选择,到底哪一款会适合您和您手头项目呢?在本文中,我们将为您选择六个容器管道,讨论并比较它们的配置、优势、局限性和价格。

什么是容器管道?

首先,让我们讨论一下容器管道的真正含义。管道有助于自动化软件开发过程中的各个阶段,尤其是持续集成和持续交付(CI/CD)阶段。从最初构建初始镜像,到部署至生产环境的过程中,容器管道能够使得容器的每个阶段都实现自动化。也就是说,整个容器管道通常包括三个阶段:

  • 集成:将更改签入源代码的管理之中,从而触发构建过程和单元测试。

  • 验收测试:将容器部署到测试环境并验证其功能。

  • 部署:将完成了全面测试的最终镜像部署到生产环境中。

目前,各种容器管道工具之间虽然有所差异,但通常会包括上述二到三个阶段。下面,我们来具体讨论其中最常见的六种容器管道:

1. Heroku

Heroku是一个利用Docker的完整容器管道。您可以在同一个平台上构建,测试,验证和部署各种容器,而无需额外配置硬件,或利用不同的服务提供者。

配置

Heroku应用程序使用heroku.yml(https://devcenter.heroku.com/articles/build-docker-images-heroku-yml)清单来进行配置。该清单定义了构建和部署容器所需的各个步骤。如下是一个带有自定义Dockerfile应用程序的清单示例:

Dockerfile  build:  docker:  web: Dockerfile

如您需要使用Git来部署该容器(https://devcenter.heroku.com/articles/git),只需运行如下命令:

$ heroku stack:set container  $ git add heroku.yml  $ git commit -m "Add heroku.yml"  $ git push heroku master

由于支持管道,Heroku允许您将容器部署到多个不同的环境中,以反映持续交付工作流程中的各个阶段。例如:您可以在部署到生产环境之前,使用管道来测试登台(staging)环境中的更改。

优势和局限性

Heroku非常易于使用,整个管道只需一个YAML文件即可。由于受到全面的管理,它为测试和部署的更改提供了多种环境。您甚至可以在部署不当的情况下,实现更改的回滚

当然,并非所有Heroku的功能都能够支持Docker部署。例如:您就不能够使用Heroku CI来运行应用程序的测试套件。这意味着:要么在构建镜像时运行测试套件,要么使用多阶段的构建。而且您也不能使用pipeline promotions,将容器从一个管道阶段升级到下一个阶段。相反,您必须将容器重新部署到目标阶段。

价格

Heroku提供了一项免费计划,其中包括:一个每月有1,000个免费运行时间的Web dyno和worker dyno。而其付费计划的起价为:每月每个运行时间dyno 7美元,并包含诸如更大容量的dyno和改进的可扩展性等功能。您若想了解更多Heroku的定价信息,请参见

我的观点

Heroku是一个非常简单且经济高效的容器管道解决方案。它提供了完全托管的环境,以便您全面控制CI/CD流程。它既提供了免费版本,又提供标准,因此您值得一试。

2. Azure DevOps

Azure DevOps是Microsoft的用于项目管理、源代码管理(SCM)和CI/CD的多合一服务。它不但使您能够控制DevOps生命周期的几乎每个阶段,而且提供了许多特定于容器的高级功能。其中包括:私有容器注册表、以及与Azure Kubernetes Service(AKS)的集成。同时,Azure Pipelines提供了平台式的CI/CD服务。

配置

您可以使用基于Web的用户界面,来管理所有Azure DevOps。当然,您也可以通过已签入的应用源码和基于YAML的清单,来配置Azure Pipelines。其Web UI使您可以管理和跟踪部署环境、发行版本、以及工件(artifact)等。

优势和局限性

如果您的团队正在使用Azure,那么Azure DevOps则是您现有工作流程的自然扩展。它既支持托管和本地安装,又支持包括Azure App Service、Kubernetes和Azure Functions在内的多个Azure目标的部署。

不过,Azure DevOps与包括Azure在内的其他服务并不容易集成。在配置集成时,您甚至需要从Azure容器注册表等服务中,去复制与粘贴值。此类设置不但麻烦而且效率低下。

价格

Azure Pipelines提供了一个免费层,其中包含一个每月1800分钟的免费并发CI/CD作业。其他“作业”的费用为40美元,而托管工件(如镜像)的费用则为每月每GB 2美元。当然,那些Azure Boards之类的增值服务也会按月收费。您若想了解更多Azure DevOps Services的定价信息,请参见

我的观点

Azure DevOps非常适合需要一站式DevOps管理解决方案、或已经使用了Azure的团队。它通过集中到一处,极大地简化了开发的生命周期。不过,它对于那些只需要基本容器管道的团队来说,可能过于复杂了一些。

3. GitLab CI/CD

GitLab源于一个开源的SCM,不过它很快发展成为了一个完整的DevOps管理解决方案。与Azure DevOps类似,它提供的功能包括:项目管理、私有容器注册表、以及包括Kubernetes在内的一个精心构建的环境。

配置

GitLab CI/CD由GitLab Runner所驱动,能够在自包含的环境中,执行CI/CD管道中的每个步骤。它通过gitlab-ci.yml清单来完成配置。该清单支持包括条件逻辑、以及导入其他清单在内的高级配置。

另外,您也可以使用Auto DevOps,在无需配置的情况下实现整个管道的自动化。通过Herokuish,GitLab使用Heroku buildpacks并基于源代码(如Dockerfile)来自动确定如何构建应用程序。Auto DevOps可以自动运行单元测试,执行代码质量分析,以及通过扫描图像来查看安全性问题。

GitLab使用dpl工具进行部署。该工具支持包括云平台和Kubernetes集群在内的各种提供者。

优势和局限性

通过GitLab提供的非常灵活的管道,您既可以自行配置,又可以使用内置工具实现完全自动化。其YAML配置允许更大范围的项目结构和步骤,例如:创建项目依赖项,以及组合来自不同项目的多个管道。由于GitLab使用的是诸如Herokuish和dpl之类的开源工具,因此它支持广泛的项目类型、语言和部署目标。

尽管GitLab可以将Runners和工件部署到现有的环境中,但它本身无法配置或维护这些环境(当然,Google Kubernetes Engine和Amazon Elastic Kubernetes Service除外)。而且,它还缺少图形化的管道配置工具,无法像使用Azure Pipelines那样直观。

价格

GitLab使用开放的内核模型:它提供了一个开源的基本版本和一个带有附加功能的付费企业版。付费版的定价从每位用户每月4到99美元不等。这种定价机制是基于用户数量的。它划归了每月可运行CI管道的分钟,以及对于某些功能的访问权。当然,所有版本都包括了无限的代码存储库,项目计划工具、以及每月2,000分钟的免费管道时间。

我的观点

GitLab是一种功能强大的CI/CD工具。在功能的丰富程度上,其开源版本足以与许多商业工具相媲美,而且它还支持托管。不过,它需要您维护一个单独的部署环境。

4. AWS Elastic Beanstalk

Elastic Beanstalk不再是简单的管道,而是更多用于编排的AWS资源工具。它可以实现自动设置,负载均衡,扩展与监视包括ECS容器、S3存储桶和EC2实例在内的各种资源。您可以根据自己的特定需求,在AWS内创建一个完全自定义的管道。

配置

Beanstalk的配置描述了如何部署容器,以及部署该容器的环境。这恰恰是在Dockerrun.aws.json文件中被定义的。此外,Beanstalk也引入了一些独特的概念,例如:

  • 应用程序:包括环境和版本在内的Beanstalk组件的逻辑集合。

  • 应用版本:易于部署的源代码版本。

  • 环境:运行应用程序版本所需的一组AWS资源。

优势和局限性

Beanstalk是一个非常强大的工具。它不仅适用于Docker,也适用于AWS。它通过提供自动扩展,滚动更新,监视和发布管理等服务,以便用户可以直接访问和管理资源。

但是,Beanstalk比普通管道更加复杂。除非您使用的是单个容器环境,并且能够将容器的版本与环境紧密耦合,否则您需要在镜像存储库中预构建和托管各种Docker镜像。而且,您只能通过Beanstalk CLI触发相关更新。因此,如果容器失败的话,您需要使用Beanstalk控制台来手动予以解决。

价格

Beanstalk本身是免费的,但是它提供的AWS组件则按照正常的价格收费。例如:如果您使用ECS节点和ELB负载平衡器来配置环境,那么节点和负载平衡器都会根据您的正常配置予以收费。

我的观点

依靠大量可用的AWS服务,Beanstalk提供了一种管理所有服务的有效方法。作为编排工具时,它功能虽然非常强大;但是用作容器管道时,则配置过于复杂。

5. Google Cloud Build

Cloud Build是基于Google Cloud Platform(GCP)所构建的基础容器CI服务。它可以直接从源代码或Dockerfile处构建镜像,并直接部署到GKE、Cloud Run、以及其他GCP服务中。

配置

Cloud Build是通过cloudbuild.yaml或JSON文件配置的。您可以定义构建镜像的过程以及存储结果镜像的位置。例如:您可以构建Docker镜像,并通过如下简单命令,将其推送到Google容器存储器中:

name: gcr.io/cloud-builders/docker args: ['build', '-t', 'gcr.io/$PROJECT_ID/myimage', '.'] images: ['gcr.io/$PROJECT_ID/myimage']

同时,Cloud Build也支持触发器,以根据源代码的更改自动启动构建过程。

优势和局限性

Cloud Build可与其他GCP服务巧妙地集成到一起,其中包括:GKE、App Engine和Cloud Run。您可以直接控制构建主机的大小、容量、以及缓存镜像层,以加快构建的速度。您还可以运行本地构建,在完成验证或调试构建之后,再推送到Cloud Run处。

由于Cloud Build是围绕着GCP构建的,因此它仅支持有限数量的部署目标。如果您想将容器部署到其他平台,则需要其他的步骤。此外,与GitLab类似,Cloud Build也并不提供可视化的管道配置工具。

价格

定价主要基于构建机器的大小和构建的时间。标准的n1-standard-1实例每个构建分钟的成本为0.003美元,因此在n1-highcpu-32实例上,最高为0.064美元。而在n1-standard-1实例上,您每天可以获得120分钟的免费构建时间。

我的观点

Cloud Build的主要优势在于简单、快速、易学、便宜、并且能与其他GCP服务进行良好的集成。如果您已经有了一个部署环境,或者已经使用到了GCP,那么建议您试用一下Cloud Build。

6. Jenkins X

Jenkins是最流行的CI/CD工具之一,Jenkins X通过添加全面的Kubernetes集成,进一步实现了扩展。Jenkins X不仅可以被部署到Kubernetes,还可以为您配置和管理Kubernetes集群。

配置

Jenkins X Pipelines建立在Tekton Pipelines之上,该管道有助于在Kubernetes上运行CI/CD管道。您可以使用jenkins-x.yml文件来配置管道。Jenkins X还提供了构建包,可以帮助您将源代码打包到镜像之中,然后将其部署到Kubernetes里。

优势和局限性

Jenkins X通过两大流行的现有项目-Jenkins和Kubernetes,来创建可扩展的CI/CD平台。它可以自动化整个CI/CD管道,并支持预览环境和管道升级。由于包含了Jenkins,因此它可以访问Jenkins开发人员的整个社区。

不过值得一提的是,由于Jenkins X需要Kubernetes,因此会涉及到配置集群等问题。当然,其命令行工具可以自动化执行此过程中的大部分操作。

价格

Jenkins X是开源的。

我的观点

对于使用Jenkins的团队来说,Jenkins X是顺理成章之事。虽然有着一些严格的限制和要求,但是对于使用Kubernetes的团队来说,它可以通过根据现有的基础架构实现原生的集成。

总结

  • 对于希望在稳定的环境中,简单部署和托管Docker容器的团队而言,Heroku非常适用。它提供了一个快速且可配置的平台,支持广泛的集成,并拥有庞大的第三方插件市场。

  • Elastic Beanstalk凭借其协调AWS资源的能力,成为了那些具有复杂要求团队的首选。

  • 对于容器CI而言,GitLab具有广泛的功能,可谓最全面的选择。

  • 除了基本功能,Auto DevOps还具有开放的内核模型。

  • Google Cloud Build能够利用Google Cloud Platform的效率和容量进行快速的构建。

  • Jenkins X主要受益于Jenkins项目。

由于这些服务大多数都是开源的、或提供免费试用版本,因此您可以通过试用,找到最适合自己工作流程的一种容器管道。

原文标题:Comparing Container Pipelines,作者:Michael Bogan