【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
