Getting started with Auto DevOps

原文：https://docs.gitlab.com/ee/topics/autodevops/quick_start_guide.html

Getting started with Auto DevOps

本分步指南将帮助您使用Auto DevOps将 GitLab.com 上托管的项目部署到 Google Kubernetes Engine.

您将使用 GitLab 的本地 Kubernetes 集成，因此您无需使用 Google Cloud Platform 控制台手动创建 Kubernetes 集群. 您将创建并部署一个从 GitLab 模板创建的简单应用程序.

这些说明也适用于自我管理的 GitLab 实例； 您只需要确保配置了自己的Runners并启用了 Google OAuth .

Configure your Google account

在创建 Kubernetes 集群并将其连接到 GitLab 项目之前，您需要一个Google Cloud Platform 帐户 . 使用现有的 Google 帐户登录，例如用于访问 Gmail 或 Google 云端硬盘的帐户，或创建一个新帐户.

  1. 请按照 Kubernetes Engine 文档的“开始之前”一节中描述的步骤来启用所需的 API 和相关服务.
  2. 确保您已使用 Google Cloud Platform 创建了一个结算帐户 .

提示：每个新的 Google Cloud Platform（GCP）帐户都会获得$ 300 的信用额 ，并且与 Google 合作，GitLab 能够为新的 GCP 帐户提供额外的$ 200，以开始使用 GitLab 的 Google Kubernetes Engine Integration. 点击此链接并申请信用.

Create a new project from a template

我们将使用 GitLab 的项目模板之一来开始. 顾名思义，这些项目提供了基于某些知名框架的准系统应用程序.

  1. 在 GitLab 中，单击加号（ ），然后选择新建项目 .

  2. 转到从模板创建选项卡，您可以在其中选择 Ruby on Rails，Spring 或 NodeJS Express 项目. 对于本教程，请使用 Ruby on Rails 模板.

    Select project template

  3. 给您的项目起一个名字，或者选择一个描述，并将其公开，以便您可以利用GitLab Gold 计划中的可用功能.

    Create project

  4. Click 建立专案.

现在，您已经创建了一个项目，接下来将创建 Kubernetes 集群以将该项目部署到该集群.

Create a Kubernetes cluster from within GitLab

  1. 在项目的登录页面上，单击添加 Kubernetes 集群 （请注意，当您导航到 操作> Kubernetes ）.

    Project landing page

  2. 在” 添加 Kubernetes 集群集成”页面上，单击” 创建新集群”选项卡，然后单击” Google GKE” .

  3. 与您的 Google 帐户关联，然后单击” 允许”以允许访问您的 Google 帐户. （此授权请求仅在您第一次将 GitLab 与您的 Google 帐户连接时显示.）

    授权访问后，将显示” 添加 Kubernetes 集群集成”页面.

  4. 在输入 Kubernetes 集群的详细信息部分中，提供有关集群的详细信息：

    • Kubernetes cluster name
    • 环境范围 -保留此字段不变.
    • Google Cloud Platform 项目 -选择一个项目. 在配置 Google 帐户后 ，应该已经为您创建了一个项目.
    • 区域 -要在其中创建群集的区域/区域 .
    • 节点数
    • 机器类型 -有关机器类型的更多信息，请参阅 Google 文档.
    • 为 Anthos 启用 Cloud Run-选中此复选框以对该集群使用Cloud Run ，Istio 和 HTTP Load Balancing 加载项.
    • 由 GitLab 管理的群集 -选中此复选框以允许 GitLab 管理该群集的名称空间和服务帐户 .
  5. Click 创建一个 Kubernetes 集群.

几分钟后，将创建集群. 您还可以在GCP 仪表板上查看其状态.

接下来，您将在群集上安装一些需要充分利用 Auto DevOps 的应用程序.

Install Ingress and Prometheus

集群运行后，您可以安装第一个应用程序. 在本指南中，我们将安装 Ingress 和 Prometheus：

  • 入口-在后台使用 NGINX 提供负载平衡，SSL 终止和基于名称的虚拟主机.
  • Prometheus-一种用于监视已部署应用程序的开源监视和警报系统.

注意：我们不会在此快速入门指南中安装 GitLab Runner，因为该指南使用了 GitLab.com 提供的共享 Runners.

要安装应用程序：

  • 单击Ingress的安装按钮.
  • 显示入口端点时 ，复制 IP 地址.
  • 添加您的基本域 . 对于本指南，我们将使用 GitLab 建议的域.
  • Click 保存更改.

Cluster Base Domain

Enable Auto DevOps (optional)

默认情况下启用 Auto DevOps 时，可以在实例级别（对于自我管理的实例）和组级别禁用 Auto DevOps. 完成以下步骤以启用 Auto DevOps（如果已禁用）：

  1. 导航 设置> CI / CD>自动 DevOps ，然后点击扩展 .
  2. 选择默认为自动 DevOps 管道以显示更多选项.
  3. 在” 部署策略”中 ，选择所需的连续部署策略 ，以在管道成功在master分支上运行之后将应用程序部署到生产中.

  4. Click 保存更改.

    Auto DevOps settings

保存更改后，GitLab 将创建一个新管道. 要查看它，请转到 CI / CD>管道 .

在下一节中，我们将解释管道中每个作业的作用.

Deploy the application

当管道运行时，它在做什么？

要查看管道中的作业，请单击管道的状态标记. 的 图标在管道作业运行时显示，并在不刷新页面的情况下进行更新 （成功）或 （失败）作业完成时.

作业分为以下几个阶段：

Pipeline stages

  • 构建 -应用程序将构建 Docker 映像并将其上传到项目的Container Registry （ Auto Build ）.

  • 测试 -GitLab 在应用程序上运行各种检查：

    • test作业通过检测语言和框架来运行单元测试和集成测试（ 自动测试 ）
    • code_quality作业检查代码质量，并允许失败（ 自动代码质量 ）
    • container_scanning作业检查 Docker 容器是否存在任何漏洞并被允许失败（ 自动容器扫描 ）
    • dependency_scanning作业检查应用程序是否具有易受漏洞影响的任何依赖关系，并允许其失败（ 自动依赖关系扫描 ）
    • 后缀为-sast作业在当前代码上运行静态分析，以检查潜在的安全问题，并允许其失败（ Auto SAST ）
    • secret-detection作业会检查泄漏的机密并允许其失败（ 自动机密检测 ）
    • license_management作业搜索应用程序的依存关系，以确定其每个许可证并被允许失败（ 自动许可证合规 ）注意：除test外，所有作业均允许在测试阶段失败.

  • 回顾 -对输水管道master包括这个阶段有dast_environment_deploy工作. 要了解更多信息，请参阅动态应用程序安全性测试（DAST） .

  • 生产 -测试和检查完成后，该应用程序将在 Kubernetes 中进行部署（ Auto Deploy ）.

  • 性能 -性能测试在已部署的应用程序上运行（ 自动浏览器性能测试 ）.

  • 清理 -对输水管道master包括这个阶段有stop_dast_environment工作.

在运行管道之后，您应该查看已部署的网站并学习如何对其进行监视.

Monitor your project

成功部署您的应用程序后，您可以通过导航到” 环境”页面来查看其网站并检查其运行状况. 运营>环境 . 该页面显示有关已部署应用程序的详细信息，右侧列显示将您链接到常见环境任务的图标：

Environments

  • 开放的现场环境 （ ）-打开生产环境中部署的应用程序的 URL
  • Monitoring () - Opens the metrics page where Prometheus collects data about the Kubernetes cluster and how the application affects it in terms of memory usage, CPU usage, and latency
  • 部署到 （ ）-显示可以部署到的环境的列表
  • 终端 （ ）-在运行应用程序的容器内打开Web 终端会话
  • 重新部署到环境 （ ）-有关更多信息，请参阅重试和回滚
  • 停止环境 （ ）-有关更多信息，请参阅停止环境

GitLab 在环境信息下方显示部署板 ，并用正方形表示 Kubernetes 集群中的 Pod，并用颜色编码以显示其状态. 将鼠标悬停在部署板上的正方形上会显示部署的状态，单击该正方形会将您带到窗格的日志页面.

提示：该示例目前仅显示一个托管应用程序的 Pod，但是您可以通过在以下REPLICAS定义REPLICAS变量来添加更多 Pod 设置> CI / CD>环境变量 .

Work with branches

按照GitLab 流程 ，您接下来应该创建一个功能分支以向您的应用程序添加内容：

  1. 在项目的存储库中，导航到以下文件： app/views/welcome/index.html.erb . 该文件应仅包含一个段落： <p>You're on Rails!</p> .
  2. 打开 GitLab Web IDE进行更改.

  3. 编辑文件，使其包含：

    1. <p>You're on Rails! Powered by GitLab Auto DevOps.</p>

  4. 暂存文件. 添加提交消息，然后通过单击Commit创建一个新分支和一个合并请求.

    Web IDE commit

提交合并请求后，GitLab 运行你的管道，而在这一切的工作，如前文所述 ，除了仅在比其他分支多跑几个master .

Merge request

几分钟后，您会注意到测试失败，这意味着您的更改”破坏了”测试. 单击失败的test作业以查看有关它的更多信息：

  1. Failure:
  2. WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]:
  3. <You're on Rails!> expected but was
  4. <You're on Rails! Powered by GitLab Auto DevOps.>..
  5. Expected 0 to be >= 1.
  7. bin/rails test test/controllers/welcome_controller_test.rb:4

要修复损坏的测试：

  1. 返回到合并请求的” 概述”页面，然后单击” 在 Web IDE 中打开” .
  2. 在文件的左侧目录中，找到test/controllers/welcome_controller_test.rb文件，然后单击将其打开.
  3. 更改第 7 行，说” You're on Rails! Powered by GitLab Auto DevOps. You're on Rails! Powered by GitLab Auto DevOps.
  4. Click Commit.
  5. 在左侧列的”未分段的更改”下 ，单击选中标记图标（ ）进行更改.
  6. 编写提交消息，然后单击提交 .

返回到合并请求的” 概述”页面，您不仅应该看到测试通过，而且应该看到部署为审阅应用程序的应用程序 . 您可以通过单击查看应用程序来访问它 按钮以查看已部署的更改.

Review app

合并合并请求后，GitLab 在master分支上运行管道，然后将应用程序部署到生产环境.

Conclusion

实施该项目之后，您应该对 Auto DevOps 的基础有深入的了解. 您从构建和测试开始，到在 GitLab 中全部部署和监视应用程序. 尽管具有自动特性，但也可以配置和自定义 Auto DevOps 以适合您的工作流程. 以下是一些有用的资源，供您进一步阅读：

  1. Auto DevOps
  2. Multiple Kubernetes clusters
  3. Incremental rollout to production
  4. Disable jobs you don’t need with environment variables
  5. Use a static IP for your cluster
  6. Use your own buildpacks to build your application
  7. Prometheus monitoring