使用 Auto DevOps 将应用程序部署到 Amazon Elastic Kubernetes Service (EKS)

在本教程中，我们将通过一个示例帮助你入门 Auto DevOps，该示例演示如何将应用程序部署到 Amazon Elastic Kubernetes Service (EKS)。

本教程使用 GitLab 原生的 Kubernetes 集成，因此你无需通过 AWS 控制台手动创建 Kubernetes 集群。

你也可以在 GitLab 自托管实例上遵循本教程。请确保你的 runners 已配置。

要将项目部署到 EKS：

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

配置你的 Amazon 账户

在创建并将 Kubernetes 集群连接到你的 GitLab 项目之前，你需要一个 Amazon Web Services 账户。使用现有的 Amazon 账户登录或创建一个新账户。

创建 Kubernetes 集群

要在 Amazon EKS 上创建新集群：

• 按照 创建 Amazon EKS 集群 中的步骤操作。

如果你愿意，也可以使用 eksctl 手动创建集群。

从模板创建应用程序项目

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

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

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

配置 agent

接下来，我们将配置 GitLab agent for Kubernetes，以便我们可以使用它来部署应用程序项目。

1. 转到 我们创建用于管理集群的项目。
2. 转到 agent 配置文件（.gitlab/agents/eks-agent/config.yaml）并编辑它。
3. 配置 ci_access:projects 属性。使用应用程序项目路径作为 id：

ci_access:
  projects:
    - id: path/to/application-project

安装 Ingress

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

1. 确保你的机器上已安装 kubectl 和 Helm。

2. 创建一个用于访问集群的 IAM 角色。

3. 创建一个用于访问集群的访问令牌。

4. 使用 kubectl 连接到你的集群：

   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 all -n gitlab-managed-apps --selector app.kubernetes.io/instance=ingress-nginx

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

   接下来，使用以下命令查找集群的实际外部 IP 地址：

   nslookup [External IP]

   其中 [External IP] 是通过上一个命令找到的主机名。

   IP 地址可能列在响应的 Non-authoritative answer: 部分。

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

2. 返回应用程序项目。

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

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

启用 Auto DevOps 并运行流水线

虽然 Auto DevOps 默认是启用的，但对于整个实例（GitLab 自托管实例）和单个组，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 模板，并将更改提交到默认分支：

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

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

部署应用程序

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

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

作业被分为不同的阶段：

• 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。此页面显示有关已部署应用程序的详细信息，右侧列显示指向常见环境任务的图标链接：

• Open live environment（ ）- 打开生产环境中部署的应用程序 URL
• Monitoring（ ）- 打开 Prometheus 收集数据的指标页面，其中包含关于 Kubernetes 集群以及应用程序在内存使用、CPU 使用和延迟方面影响的数据
• Deploy to（ ）- 显示你可以部署到的环境列表
• Terminal（ ）- 在运行应用程序的容器内打开一个 web terminal 会话
• Re-deploy to environment（ ）- 更多信息，请参阅 重试和回滚
• Stop environment（ ）- 更多信息，请参阅 停止环境

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 创建新分支和合并请求。

   

提交合并请求后，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（ ）。
6. 写一个提交消息，然后选择 Commit。

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

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

结论

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

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