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 RegistryAuto 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.
  6. 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