汽车DevOps
危险:自动DevOps目前在β而且不建议用于生产使用．
介绍了在GitLab 10.0中。
自动DevOps自动检测、构建、测试、部署和监视应用程序。
概述
使用Auto DevOps，软件开发过程变得更容易设置，因为每个项目都可以拥有从验证到监控的完整工作流程，而不需要配置任何东西。只需推送代码，GitLab就会处理其他一切。这使得启动新项目变得更容易，并使整个公司的应用程序设置方式保持一致。
与应用程序平台和PaaS的比较
Auto DevOps提供了被其他人描述为应用程序平台或平台即服务(PaaS)的功能。它从创新工作中获得灵感Heroku并在几个方面超越了它:
- Auto DevOps适用于任何Kubernetes集群，您不局限于在GitLab的基础设施上运行(注意，许多功能在没有Kubernetes的情况下也可以工作)。
- 没有额外的成本(没有基础设施成本的标记)，并且您可以在任何公共云上使用自托管的Kubernetes集群或容器即服务(例如谷歌Kubernetes引擎)．
- Auto DevOps有更多的特性，包括安全测试、性能测试和代码质量测试。
- 它提供了一个递增的毕业路径。如果您需要高级定制，您可以开始修改模板，而不必在一个完全不同的平台上重新开始。
特性
Auto DevOps由一组阶段组成，以一种简单而自动的方式将这些最佳实践带到你的项目中:
由于Auto DevOps依赖于许多不同的组件，因此最好掌握以下基本知识:
Auto DevOps为所有阶段提供了很棒的默认值;然而，你可以，定制几乎应有尽有。
关于创建Auto DevOps的概述，请阅读这篇博客文章从2/3的自托管Git市场，到下一代CI系统，再到自动DevOps．
先决条件
提示:提示:对于自托管安装，使用Auto DevOps最简单的方法是在Kubernetes集群中使用GitLab综合舵图自动安装和配置您需要的一切!
为了充分利用Auto DevOps，你需要:
- GitLab跑步(所有阶段都需要)-您的Runner需要配置为能够运行Docker。通常这意味着使用码头工人或Kubernetes执行人,启用特权模式．runner不需要安装在Kubernetes集群中，但是Kubernetes executor易于使用，并且可以自动伸缩。基于docker的runner也可以配置为自动伸缩，使用码头工人的机器．参赛者必须注册为共享的跑步者整个GitLab实例，或者特定的跑步者被分配到特定的项目。
- 基础领域(自动审查应用程序和自动部署需要)-你需要一个配置了通配符DNS的域，它将被你所有的自动DevOps应用程序使用。阅读细节．
- Kubernetes(需要自动审查应用程序，自动部署和自动监控)-启用部署，你将需要Kubernetes 1.5+。你需要一个Kubernetes集群或者Kubernetes默认服务模板用于整个GitLab安装。
- 负载均衡器-你可以使用NGINX入口部署到你的Kubernetes集群使用
nginx-ingress执掌图表。 - 通配符TLS终止—可以部署
kube-legoHelm chart到您的Kubernetes集群，使用Let's Encrypt自动为您的域颁发证书。
- 负载均衡器-你可以使用NGINX入口部署到你的Kubernetes集群使用
- 普罗米修斯(需要自动监控)-要启用自动监控，你需要在某个地方(集群内部或外部)安装Prometheus，并配置为刮除你的Kubernetes集群。要获得响应指标(除了系统指标)，您需要配置Prometheus监控NGINX．的普罗米修斯服务需要为项目启用集成，或者作为默认服务模板用于整个GitLab安装。
注意:注意:如果您没有安装Kubernetes或Prometheus，则自动审查应用程序、自动部署和自动监控将被静默跳过。
自动DevOps基础域
如果您想使用Auto DevOps基础域，则必须使用自动审查应用程序而且自动部署．在项目的CI/CD设置下定义启用自动DevOps或者在CI/CD部分的实例级设置中。它也可以在项目或组级别设置为变量，AUTO_DEVOPS_DOMAIN．
通配符DNS需要匹配基本域的记录，例如给定的基本域为example.com，你需要一个DNS条目:
A 1.2.3.4在哪里example.com部署的应用程序将使用的域名，以及为1.2.3.4是负载均衡器的IP地址;通常NGINX (看到先决条件)．如何设置DNS记录不在本文讨论范围之内;你应该向你的DNS提供商咨询。
或者你可以使用免费的公共服务，比如xip.io或nip.io提供自动通配符DNS，无需任何配置。只需将Auto DevOps基本域设置为1.2.3.4.xip.io或1.2.3.4.nip.io．
设置完成后，所有请求都将到达负载均衡器，负载均衡器将依次将它们路由到运行应用程序的Kubernetes pod。
注意:注意:如果GitLab是使用GitLab综合舵图，有两个选项:提供一个静态IP，或分配一个。有关更多信息，请参阅网络的先决条件．
快速启动
如果您正在使用GitLab.com，请参阅我们的快速入门指南用于使用GitLab.com和谷歌云上的外部Kubernetes集群的自动DevOps。
启用自动DevOps
如果你还没有做，请阅读先决条件充分利用Auto DevOps。如果这是你的第一次，我们建议你遵循快速入门指南．
为你的项目启用自动DevOps:
- 检查您的项目是否有
.gitlab-ci.yml，否则将其移除 - 去你的项目> CI/CD >常规管道设置并找到Auto DevOps部分
- 选择“启用自动DevOps”
- 中添加基础领域Kubernetes将使用它来部署您的应用程序
- 打击保存更改以便更改生效
一旦保存，Auto DevOps管道将在默认分支上触发。
注意:注意:对于GitLab 10.0 - 10.2版本，当启用自动DevOps时，需要手动触发一个管道，要么将一个新的提交推入存储库，要么通过访问项目https://example.gitlab.com/ <用户名> / < > /管道/新并且通常为默认分支创建一个新管道主．
注意:注意:如果你是一个GitLab管理员，你可以在实例范围内启用自动DevOpsAdmin Area >设置>持续集成与部署．这样，所有没有显式设置选项的项目都会默认启用Auto DevOps。
自动DevOps的阶段
下面几节描述了Auto DevOps的各个阶段。仔细阅读它们，了解每一个是如何工作的。
汽车制造
自动构建以以下两种方式之一创建应用程序的构建:
- 如果有
Dockerfile，它将使用码头工人建造来创建Docker映像。 - 否则，它将使用Herokuish而且Heroku buildpacks来自动检测应用程序并将其构建到Docker映像中。
无论采用哪种方式，生成的Docker映像都会自动推送到容器注册表并标记为提交SHA。
警告:重要的是:如果你也使用自动审查应用程序和自动部署，并选择提供自己的Dockerfile，确保将应用程序公开到端口5000因为这是默认的Helm图所假设的端口。
汽车测试
“自动测试”自动为您的应用程序运行相应的测试Herokuish而且Heroku buildpacks通过分析你的项目来检测语言和框架。会自动检测到几种语言和框架，但如果没有检测到您的语言，则可能会成功地使用自定义buildpack．检查当前支持的语言．
注意:注意:自动测试使用应用程序中已有的测试。如果没有测试，则由您决定是否添加它们。
自动代码质量
Auto Code Quality使用开源codeclimate图像对当前代码运行静态分析和其他代码检查。报告被创建，并作为工件上传，您可以稍后下载和检出。
在GitLab Starter中，源分支和目标分支之间也存在差异在合并请求小部件中显示．
汽车科协
介绍了GitLab最终10.3.
静态应用程序安全测试(SAST)使用SAST Docker映像对当前代码运行静态分析，并检查潜在的安全问题。一旦创建了报告，它就会作为工件上传，您可以稍后下载并检出它。
在GitLab Ultimate中，任何安全警告也会被删除在合并请求小部件中显示．
自动依赖扫描
介绍了GitLab最终10.7.
依赖项扫描使用依赖扫描Docker镜像对项目依赖项进行分析，并检查潜在的安全问题。一旦创建了报告，它就会作为工件上传，您可以稍后下载并检出它。
在GitLab Ultimate中，任何安全警告也会被删除在合并请求小部件中显示．
集装箱自动扫描
在GitLab 10.4中引入。
容器使用的漏洞静态分析克莱尔对Docker映像运行静态分析，并检查潜在的安全问题。一旦创建了报告，它就会作为工件上传，您可以稍后下载并检出它。
在GitLab Ultimate中，任何安全警告也会被删除在合并请求小部件中显示．
自动审查应用程序
注意:注意:这是一个可选步骤，因为许多项目没有可用的Kubernetes集群。如果先决条件得不到满足，工作就会默默跳过。
警告:警告:你的应用应该不在Helm之外被操纵(直接使用Kubernetes)这可能会导致Helm没有检测到更改的混乱，并且后续使用Auto DevOps部署可以撤销您的更改。此外，如果您更改了某些内容，并希望通过再次部署来撤销它，Helm可能一开始就检测不到任何更改，因此没有意识到需要重新应用旧配置。
回顾应用程序是基于分支代码的临时应用程序环境，因此开发人员、设计人员、QA、产品经理和其他审查人员可以在审查过程中实际看到代码更改并与之交互。Auto Review Apps为每个分支创建一个Review App。
Review App将有一个基于项目名称、分支名称和唯一编号的唯一URL，并结合Auto DevOps基础域。例如,用户-项目-分公司- 1234. - example.com．一个到Review App的链接显示在合并请求小部件中，以便于发现。当分支被删除时，例如合并请求被合并后，Review App将自动被删除。
汽车DAST
介绍了GitLab最终10.4.
动态应用程序安全测试(DAST)使用流行的开源工具OWASP ZAProxy对当前代码进行分析，检查潜在的安全问题。一旦创建了报告，它就会作为工件上传，您可以稍后下载并检出它。
在GitLab Ultimate中，任何安全警告也会被删除在合并请求小部件中显示．
自动浏览器性能测试
介绍了GitLab溢价10.4.
自动浏览器性能测试利用Sitespeed。io容器衡量网页的性能。创建一个JSON报告并作为工件上传，其中包括每个页面的总体性能得分。默认情况下，将测试Review和Production环境的根页面。如果您想添加额外的URL进行测试，只需将路径添加到一个名为.gitlab-urls.txt在根目录中，每行一个。例如:
//功能/方向在GitLab Premium中，源分支和目标分支之间的性能差异是在合并请求小部件中显示．
自动部署
注意:注意:这是一个可选步骤，因为许多项目没有可用的Kubernetes集群。如果先决条件得不到满足，工作就会默默跳过。
警告:警告:你的应用应该不在Helm之外被操纵(直接使用Kubernetes)这可能会导致Helm没有检测到更改的混乱，并且后续使用Auto DevOps部署可以撤销您的更改。此外，如果您更改了某些内容，并希望通过再次部署来撤销它，Helm可能一开始就检测不到任何更改，因此没有意识到需要重新应用旧配置。
在一个分支或合并请求被合并到项目的默认分支(通常主)， Auto Deploy将应用程序部署到生产例如，在Kubernetes集群中使用基于项目名称和唯一项目ID的命名空间项目- 4321．
自动部署默认情况下不包括部署到登台或金丝雀，但是自动DevOps模板如果要启用这些任务，则包含这些任务的作业定义。
你可以利用环境变量自动缩放您的豆荚副本。
需要注意的是，当一个项目部署到Kubernetes集群时，它依赖于已推送到的Docker映像GitLab容器注册．Kubernetes获取这个映像并使用它来运行应用程序。如果项目是公共的，Kubernetes可以在不需要任何身份验证的情况下访问映像，从而使我们的部署更加可用。如果项目是私有/内部的，那么Registry需要凭据才能提取映像。目前，通过提供CI_JOB_TOKEN作为可以使用的密码，但一旦部署作业完成，此令牌将不再有效。这意味着Kubernetes可以运行应用程序，但如果它应该重新启动或在其他地方执行，则不能再次访问它。
汽车监控
注意:注意:检查先决条件自动监控使这一阶段工作。
一旦部署了应用程序，Auto Monitoring就可以立即监视应用程序的服务器和响应指标。自动监控功能普罗米修斯以直接获得CPU和内存使用等系统指标Kubernetes的响应指标，如HTTP错误率、延迟和吞吐量NGINX服务器．
这些指标包括:
- 响应指标:延迟、吞吐量、错误率
- 系统指标:CPU利用率，内存利用率
如果已使用GitLab综合舵图，无需配置。
如果你使用不同的方法安装了GitLab，你需要:
- 部署普罗米修斯进入你的Kubernetes集群
- 如果你想要响应指标，请确保你正在运行至少0.9.0版本的NGINX Ingress和启用普罗米修斯度量．
- 最后,注释Prometheus使用的NGINX Ingress部署
普罗米修斯。io /刮:“真正的”而且普罗米修斯。io /端口:“10254”．
要查看指标，请打开监视已部署环境的仪表板．
定制
虽然Auto DevOps提供了很好的默认值让你开始，但你可以自定义几乎所有东西来满足你的需求;从自定义buildpacks,Dockerfile年代，执掌图表，甚至复制完整CI / CD配置到您的项目中，以支持登台和金丝雀部署等等。
自定义buildpacks
如果项目的自动构建包检测失败，或者希望使用自定义构建包，则可以使用项目变量或.buildpacks文件在你的项目:
- 项目变量—创建项目变量
BUILDPACK_URL使用要使用的构建包的URL。 .buildpacks文件-添加一个文件在你的项目的回购称为.buildpacks并在文件中的一行中添加要使用的构建包的URL。如果你想使用多个构建包，你可以输入它们，每行一个。
警告:警告:Auto DevOps还不支持使用多个构建包。
自定义Dockerfile
如果你的项目有Dockerfile在项目repo的根目录中，Auto DevOps将基于Dockerfile而不是使用构建包构建Docker映像。这可以更快，并导致更小的图像，特别是如果您的Dockerfile基于高山．
自定义舵图
自动DevOps使用舵将应用程序部署到Kubernetes。你可以通过将一个图表捆绑到你的项目回购或指定一个项目变量来覆盖Helm图表:
- 绑定图-如果你的项目有
。/图带有Chart.yaml文件，Auto DevOps将检测到图表并使用它而不是默认的一个．这是精确控制应用程序部署方式的好方法。 - 项目变量—创建项目变量
AUTO_DEVOPS_CHART与要使用的自定义图表的URL。
定制.gitlab-ci.yml
如果您想修改Auto DevOps使用的CI/CD管道，可以复制自动DevOps模板进入你的项目的回购和编辑，因为你认为合适。
假设你的项目是新的或者没有.gitlab-ci.yml文件存在:
- 在项目主页，点击“设置CI/CD”按钮，或点击加号按钮，然后(
+)，然后按“新建档案” - 选择
.gitlab-ci.yml作为模板类型 - 从模板下拉菜单中选择“Auto-DevOps”
- 编辑模板或添加所需的任何作业
- 给出一个适当的提交消息并点击“提交更改”
提示:提示:Auto DevOps模板包含有用的注释，可以帮助您自定义它。例如，如果希望将部署转到登台环境，而不是直接转到生产环境，则可以启用暂存通过重命名Job.staging来暂存．然后确保取消注释当钥匙生产作业，将其转换为手动操作，而不是自动部署。
PostgreSQL数据库支持
为了支持需要数据库的应用程序，PostgreSQL默认情况下是配置的。访问数据库的凭据是预先配置的，但是可以通过设置相关的变量．这些凭证可用于定义DATABASE_URL格式:
postgres: / /用户:password@postgres-host: postgres-port / postgres-database环境变量
以下变量可用于设置Auto DevOps域、提供自定义Helm图表或扩展应用程序。PostgreSQL也可以自定义，你可以很容易地使用自定义buildpack．
| 变量 | 描述 |
|---|---|
AUTO_DEVOPS_DOMAIN |
的自动DevOps域；默认情况下由自动设置自动DevOps设置． |
AUTO_DEVOPS_CHART |
掌舵图用来部署你的应用;默认为1由GitLab提供． |
副本 |
要部署的副本数量;默认值为1。 |
PRODUCTION_REPLICAS |
要在生产环境中部署的副本数量。这个优先于副本；默认值为1。 |
CANARY_REPLICAS |
要部署的金丝雀副本的数量金丝雀的部署；默认值为1 |
CANARY_PRODUCTION_REPLICAS |
要部署的金丝雀副本的数量金丝雀的部署在生产环境中。这个优先于CANARY_REPLICAS；默认值为1 |
POSTGRES_ENABLED |
PostgreSQL是否启用;默认为“真正的”．设置为假禁用PostgreSQL自动部署功能。 |
POSTGRES_USER |
PostgreSQL用户;默认为用户．设置为使用自定义用户名。 |
POSTGRES_PASSWORD |
PostgreSQL密码;默认为testing-password．设置为使用自定义密码。 |
POSTGRES_DB |
PostgreSQL数据库名;默认为的值CI_ENVIRONMENT_SLUG美元．将其设置为使用自定义数据库名称。 |
BUILDPACK_URL |
构建包的完整URL。它可以指向Git存储库或tarball URL。对于Git存储库，可以指向特定的存储库裁判例如，https://github.com/heroku/heroku-buildpack-ruby.git#v142 |
STAGING_ENABLED |
从GitLab 10.8开始，这个变量可以用来定义一个部署用于登台和生产环境的策略． |
INCREMENTAL_ROLLOUT_ENABLED |
从GitLab 10.8开始，此变量可用于启用增量推出用于生产环境的应用程序。 |
提示:提示:设置复制变量使用项目变量并通过重新部署来扩展应用程序!
警告:警告:你应该不直接使用Kubernetes扩展应用程序。这可能会导致Helm没有检测到更改的混乱，并且后续使用Auto DevOps部署可以撤销您的更改。
高级复制变量设置
除了上面提到的两个与复制相关的生产变量外，还可以在不同的环境中使用其他变量。
Kubernetes的标签命名之间有一个非常具体的映射跟踪、GitLab CI/CD环境名称和replicas环境变量。一般规则是:TRACK_ENV_REPLICAS．地点:
跟踪的大写值跟踪Kubernetes标签在Helm Chart应用定义中。如果不设置，则不会考虑变量名。ENV:所设置的部署作业的大写环境名称.gitlab-ci.yml．
这样，你就可以定义你自己的TRACK_ENV_REPLICAS使用这些变量，您将能够轻松地缩放pod的副本。
在下面的示例中，环境的名称为质量保证它会展开轨道喷火这就会导致寻找FOO_QA_REPLICAS环境变量:
QA测试：阶段：部署环境：名字：质量保证脚本：-部署foo轨道喷火被引用也需要在应用的Helm图中定义，比如:
replicaCount：1图像：存储库：gitlab.example.com/group/project标签：稳定的pullPolicy：总是秘密：-名字：gitlab-registry应用程序：跟踪：喷火层：网络服务：启用：真正的名字：网络类型：ClusterIPurl：http://my.host.com/externalPort：5000internalPort：5000部署用于登台和生产环境的策略
介绍了在GitLab 10.8中。
自动DevOps的正常行为是使用持续部署，自动推送到生产每次在默认分支上运行新管道时，环境。但是，在某些情况下，您可能希望使用登台环境并手动部署到生产环境。对于这个场景，使用STAGING_ENABLED引入环境变量。
如果STAGING_ENABLED在您的项目中定义(例如，setSTAGING_ENABLED来1作为秘密变量)，那么应用程序将自动部署到暂存环境，以及production_manual作业将在您准备手动部署到生产环境时为您创建。
增量部署到生产(高级)
介绍了在GitLab 10.8中。
当您有一个新版本的应用程序要部署到生产环境中时，您可能希望使用增量式部署，用最新的代码替换一些pod。这将允许您首先检查应用程序的行为，然后手动将铺开率提高到100%。
如果INCREMENTAL_ROLLOUT_ENABLED在您的项目中定义(例如，setINCREMENTAL_ROLLOUT_ENABLED来1作为一个秘密变量)，然后代替标准生产工作，4个不同的手动工作将被创建:
推出10%推出25%推出50%推出100%
百分比是基于副本变量，并定义您希望为部署拥有的pod的数量。如果你说10，然后运行10％推出工作，会有的1新豆荚+9旧的。
要开始作业，请单击作业名称旁边的播放图标。你不需要从10％来100％在美国，你可以随便跳槽。您还可以在到达之前运行一个较低百分比的作业100％．一旦你到了100％方法重新部署旧版本，因此无法缩小规模，必须进行回滚回滚按钮在环境页面。
下面，您可以看到如果定义了rollout或staging变量，管道将会是什么样子。
没有
INCREMENTAL_ROLLOUT_ENABLED和不STAGING_ENABLED
没有
INCREMENTAL_ROLLOUT_ENABLED和STAGING_ENABLED与
INCREMENTAL_ROLLOUT_ENABLED和不STAGING_ENABLED与
INCREMENTAL_ROLLOUT_ENABLED和STAGING_ENABLED
当前支持的语言
注意:注意:并不是所有的构建包都支持Auto Test，因为这是一个相对较新的增强。都是赫鲁库的官方支持的语言支持它，以及一些第三方构建包，如Go, Node, Java, PHP, Python, Ruby, Gradle, Scala和Elixir都支持自动测试，但值得注意的是，多构建包不支持自动测试。
从GitLab 10.0开始，支持的构建包是:
- heroku-buildpack-multi v1.0.0- heroku-buildpack-ruby v168- heroku-buildpack-nodejs v99- heroku-buildpack-clojure v77- heroku-buildpack-python v99- heroku-buildpack-java v53- heroku-buildpack-gradle v23- heroku-buildpack-scala v78- heroku-buildpack-play v26- heroku-buildpack-php v122- heroku-buildpack-go v72- heroku-buildpack-erlang fa17af9- buildpack-nginx v8限制
以下限制适用。
私人项目支持
警告:警告:Auto DevOps中的私有项目支持是实验性的。
当一个项目被标记为私有时，GitLab的容器注册表下载容器时需要身份验证。Auto DevOps将自动向Kubernetes提供所需的身份验证信息，允许临时访问注册表。在管道运行时，身份验证凭证将是有效的，从而允许成功的初始部署。
管道完成后，Kubernetes将不再能够访问容器注册表。重新启动pod、扩展服务或其他需要持续访问注册表的操作可能会失败．后续版本计划持续的安全访问。
故障排除
- 自动构建和自动测试可能无法检测到您的语言/框架。您的应用程序可能没有构建包，或者您的应用程序可能缺少构建包正在寻找的关键文件。例如，对于ruby应用程序，你必须有一个
Gemfile被正确检测，即使有可能编写一个Ruby应用程序没有Gemfile．试着指定一个自定义buildpack． - Auto Test可能会因为测试框架之间的不匹配而失败。在这种情况下，您可能需要定制您的
.gitlab-ci.yml使用您的测试命令。
禁用横幅实例宽度
如果管理员想在实例级别禁用横幅，可以通过控制台禁用此功能:
sudogitlab-rails控制台然后运行:
功能．得到（: auto_devops_banner_disabled)．启用或者通过带有管理员访问令牌的HTTP API:
旋度——数据“价值= true”——头“PRIVATE-TOKEN: personal_access_token”https://gitlab.example.com/api/v4/features/auto_devops_banner_disabled