Help us learn about your current experience with the documentation. Take the survey.

使用 Auto DevOps 将应用程序部署到 Google Kubernetes Engine

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

在本教程中，我们将通过一个示例，帮助你开始使用 Auto DevOps， 了解如何将应用程序部署到 Google Kubernetes Engine (GKE)。

你使用的是 GitLab 原生的 Kubernetes 集成，因此不需要 使用 Google Cloud Platform 控制台手动创建 Kubernetes 集群。 你正在创建和部署一个从 GitLab 模板创建的应用程序。

这些说明也适用于 GitLab Self-Managed。 请确保你的 runners 已配置 并且 已启用 Google OAuth。

要将项目部署到 Google Kubernetes Engine，请按照以下步骤操作：

  1. 配置你的 Google 账户
  2. 创建 Kubernetes 集群并部署代理
  3. 从模板创建新项目
  4. 配置代理
  5. 安装 Ingress
  6. 配置 Auto DevOps
  7. 启用 Auto DevOps 并运行流水线
  8. 部署应用程序

配置你的 Google 账户

在创建并将 Kubernetes 集群连接到你的 GitLab 项目之前， 你需要一个 Google Cloud Platform 账户。 使用现有的 Google 账户登录，例如你用来访问 Gmail 或 Google Drive 的账户，或者创建一个新账户。

  1. 按照 Kubernetes Engine 文档中 “开始之前” 部分 的步骤启用所需的 API 和相关服务。
  2. 确保你已使用 Google Cloud Platform 创建了一个 计费账户。

每个新的 Google Cloud Platform (GCP) 账户可获得 $300 信用额度， 并且通过与 Google 合作，GitLab 可以为新的 GCP 账户额外提供 $200 信用额度，以帮助他们开始使用 GitLab 与 Google Kubernetes Engine 的集成。 点击此链接 并申请信用额度。

创建 Kubernetes 集群

要在 Google Kubernetes Engine (GKE) 上创建新集群， 请按照 创建 Google GKE 集群 指南中的步骤， 使用基础设施即代码 (IaC) 方法。 该指南要求你创建一个新项目，使用 Terraform 来创建 GKE 集群 并安装 GitLab Kubernetes 代理。 这个项目是 GitLab Kubernetes 代理配置所在的位置。

从模板创建应用程序项目

使用 GitLab 项目模板开始。顾名思义， 这些项目提供了一个基于一些知名框架构建的 基础应用程序。

在集群管理项目的同一级别或更低的层次结构中创建应用程序项目。否则，它将无法 授权代理。

  1. 在左侧边栏顶部，选择 Create new ( plus ) 和 New project/repository。
  2. 选择 Create from template。
  3. 选择 Ruby on Rails 模板。
  4. 为你的项目命名，可选地添加描述，并将其设为公开， 以便你可以利用 GitLab Ultimate 计划 中提供的功能。
  5. 选择 Create project。

现在你有一个将要部署到 GKE 集群的应用程序项目。

配置代理

现在我们需要配置 GitLab Kubernetes 代理，以便我们能够使用它来部署应用程序项目。

  1. 转到 我们创建的用于管理集群的项目。
  2. 转到 代理配置文件 (.gitlab/agents/<agent-name>/config.yaml) 并编辑它。
  3. 配置 ci_access:projects 属性。使用应用程序的项目路径作为 id：
ci_access:
  projects:
    - id: path/to/application-project

安装 Ingress

集群运行后，你必须安装 NGINX Ingress Controller 作为 负载均衡器，以便将互联网流量路由到你的应用程序。 通过 GitLab 集群管理项目模板 安装 NGINX Ingress Controller，或使用 Google Cloud Shell 手动安装：

  1. 转到你的集群详情页面，然后选择 Advanced Settings 选项卡。

  2. 选择指向 Google Kubernetes Engine 的链接，以在 Google Cloud Console 中访问集群。

  3. 在 GKE 集群页面上，选择 Connect，然后选择 Run in Cloud Shell。

  4. Cloud Shell 启动后，运行以下命令安装 NGINX Ingress Controller：

    helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace gitlab-managed-apps --create-namespace

# 检查 ingress controller 是否安装成功
kubectl get service ingress-nginx-controller -n gitlab-managed-apps

配置 Auto DevOps

按照以下步骤配置 Auto DevOps 所需的基础域名和其他设置。

  1. 安装 NGINX 几分钟后，负载均衡器会获得一个 IP 地址，你可以 使用以下命令获取外部 IP 地址：

    kubectl get service ingress-nginx-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip'

    如果你覆盖了你的命名空间，请替换 gitlab-managed-apps。

    复制这个 IP 地址，因为你在下一步中需要它。

  2. 返回应用程序项目。

  3. 在左侧边栏，选择 Settings > CI/CD 并展开 Variables。

    • 添加一个名为 KUBE_INGRESS_BASE_DOMAIN 的键，以应用程序部署域名为值。在本示例中，使用域 <IP 地址>.nip.io。
    • 添加一个名为 KUBE_NAMESPACE 的键，值为你的部署目标的 Kubernetes 命名空间。你可以为每个环境使用不同的命名空间。配置环境，使用环境范围。
    • 添加一个名为 KUBE_CONTEXT 的键，值为 <path/to/agent/project>:<agent-name>。选择你想要的环境范围。
    • 选择 Save changes。

启用 Auto DevOps 并运行流水线

虽然 Auto DevOps 默认是启用的，但对于实例（对于 GitLab Self-Managed 实例）和组， Auto DevOps 可能会被禁用。如果 Auto DevOps 被禁用，请完成以下步骤来启用它：

  1. 在左侧边栏，选择 Search or go to 并找到应用程序项目。

  2. 选择 Settings > CI/CD。

  3. 展开 Auto DevOps。

  4. 选择 Default to Auto DevOps pipeline 以显示更多选项。

  5. 在 Deployment strategy 中，选择你想要的 持续部署策略， 以在流水线在默认分支上成功运行后部署应用程序到生产环境。

  6. 选择 Save changes。

  7. 编辑 .gitlab-ci.yml 文件以包含 Auto DevOps 模板，并将更改提交到 master 分支：

    include:
- template: Auto-DevOps.gitlab-ci.yml

该提交应该会触发一个流水线。在下一节中，我们将解释流水线中每个作业的作用。

部署应用程序

当你的流水线运行时，它在做什么？

要查看流水线中的作业，选择流水线的状态徽章。当 流水线作业正在运行时，会显示 status_running 图标，并且在作业完成时， 无需刷新页面即可更新为 status_success （成功）或 status_failed （失败）。

作业被分为几个阶段：

Pipeline stages

  • Build - 应用程序构建 Docker 镜像并将其上传到你的项目的 Container Registry (Auto Build)。

  • Test - GitLab 对应用程序运行各种检查，但在测试阶段，除了 test 作业外， 其他作业都允许失败：

    • test 作业通过检测语言和框架运行单元和集成测试 (Auto Test)
    • code_quality 作业检查代码质量，允许失败 (Auto Code Quality)
    • container_scanning 作业检查 Docker 容器是否有任何漏洞，允许失败 (Auto Container Scanning)
    • dependency_scanning 作业检查应用程序是否有任何易受漏洞影响的依赖项，允许失败 (Auto Dependency Scanning)
    • 以 -sast 后缀结尾的作业对当前代码运行静态分析以检查潜在的安全问题，允许失败 (Auto SAST)
    • secret-detection 作业检查是否有泄露的密钥，允许失败 (Auto Secret Detection)

  • Review - 默认分支上的流水线包含此阶段，带有 dast_environment_deploy 作业。 有关更多信息，请参阅 动态应用程序安全测试 (DAST)。

  • Production - 测试和检查完成后，应用程序在 Kubernetes 中部署 (Auto Deploy)。

  • Performance - 在已部署的应用程序上运行性能测试 (Auto Browser Performance Testing)。

  • Cleanup - 默认分支上的流水线包含此阶段，带有 stop_dast_environment 作业。

运行流水线后，你应该查看你已部署的网站并学习如何监控它。

监控你的项目

成功部署应用程序后，你可以在 Environments 页面上查看其网站并检查 其健康状况，导航到 Operate > Environments。此页面显示有关 已部署应用程序的详细信息，右侧列显示指向常见环境任务的图标：

Environments

  • Open live environment ( external-link ) - 打开生产环境中部署的应用程序的 URL
  • Monitoring ( chart ) - 打开指标页面，Prometheus 在此收集有关 Kubernetes 集群以及应用程序如何影响它的数据， 包括内存使用、CPU 使用和延迟
  • Deploy to ( play chevron-lg-down ) - 显示你可以部署到的环境列表
  • Terminal ( terminal ) - 在运行应用程序的容器内打开一个 web terminal 会话
  • Re-deploy to environment ( repeat ) - 有关更多信息，请参阅 重试和回滚
  • Stop environment ( stop ) - 有关更多信息，请参阅 停止环境

GitLab 在环境信息下方显示 deploy board， 其中包含代表你 Kubernetes 集群中 pod 的方块，颜色编码显示其状态。 将鼠标悬停在 deploy board 的方块上会显示部署状态，选择该方块会带你到 pod 的日志页面。

示例目前只显示一个托管应用程序的 pod，但你可以通过在 Settings > CI/CD > Variables 中 定义 REPLICAS CI/CD 变量 来添加更多 pod。

使用分支

接下来，创建一个功能分支来为你的应用程序添加内容：

  1. 在你的项目仓库中，转到以下文件：app/views/welcome/index.html.erb。 该文件应只包含一个段落：<p>You're on Rails!</p>。

  2. 打开 GitLab Web IDE 进行更改。

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

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

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

    Web IDE commit

提交合并请求后，GitLab 会运行你的流水线以及其中的所有作业， 如前所述，此外还有一些仅在非默认分支上运行的作业。

几分钟后测试失败，这意味着测试被你的更改"破坏"了。 选择失败的 test 作业以查看更多信息：

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

bin/rails test test/controllers/welcome_controller_test.rb:4

要修复损坏的测试：

  1. 返回你的合并请求。
  2. 在右上角，选择 Code，然后选择 Open in Web IDE。
  3. 在左侧文件目录中，找到 test/controllers/welcome_controller_test.rb 文件，并选择它以打开它。
  4. 将第 7 行更改为 You're on Rails! Powered by GitLab Auto DevOps.
  5. 在左侧边栏，选择 Source Control ( merge )。
  6. 写一个提交消息，然后选择 Commit。

返回你的合并请求的 Overview 页面，你应该不仅看到测试通过， 还应该看到应用程序作为 review application 部署。你可以通过选择 View app external-link 按钮来查看你已部署的更改。

合并合并请求后，GitLab 会在默认分支上运行流水线， 然后将应用程序部署到生产环境。

结论

实施此项目后，你应该对 Auto DevOps 的基础知识有了扎实的理解。 你从构建和测试开始，到在 GitLab 中部署和监控应用程序， 尽管它是自动化的，但 Auto DevOps 也可以配置和定制以适应你的工作流程。 以下是一些有助于进一步阅读的有用资源：

  1. Auto DevOps
  2. 多个 Kubernetes 集群
  3. 渐进式部署到生产环境
  4. 使用 CI/CD 变量禁用不需要的作业
  5. 使用你自己的 buildpack 构建应用程序