硬核干货|使用GitLab CI部署Rancher集群

在当今瞬息万变的 DevOps 世界中，遵循最佳实践至关重要。这些最佳实践涉及安全性、访问控制、资源限制等方面。在 DevOps 中最为重要的事情之一是持续集成（CI）和持续交付（CD）。而且对于一个有效部署来说，持续集成是极为关键的部分。但是在集成的过程中我们总是一次又一次地重复手动步骤——尤其是在节点配置方面。此时，我们需要“万物自动化”的思维方式来保证我们工作的正常运转，以便我们可以高效执行并确保我们的应用程序得以有效部署和运行。通过 GitLab CI/CD，你会获得一个对用户友好的 UI，它可以配置构建（build）并根据需要对其进行自定义。它还包括了设置流水线触发器、构建变量、license 合规性等。

从统一的控制台查看构建步骤极为有益，特别当你正在试图排除构建故障时。每个构建步骤也会显示运行命令的 CLI 输出。这可以让你从一个视角了解构建过程中发生的事情，而无需 SSH 进入 runner 节点。CI/CD 工具通常与构建文件一起工作，它决定了构建步骤。当使用 GitLab CI/CD 时，构建文件被称为.gitlab-ci.yaml。在本文中，你将会了解到构建文件的组合方式及其作用。

GitLab CI 工具如何与 AWS 进行通信以触发新资源的启动是我们部署的另一个重要部分。我们的部署还包括 Terraform、RKE 和 Rancher2。主要目标是产生一个按需部署和销毁基础设施的流水线。最终结果是我们可以通过点击一个按钮来触发，或者用一条（或两条）CLI 命令来获得一个高可用的、一致的部署。

你可以访问以下链接查看本文的源代码：

https://gitlab.com/iby.autometa/rancher-deploy

部署流程

在这个部署中每个组件都有其特定的目的，部署的目标是按照安全、低成本和高可用的最佳实践以部署所需的最少资源。

但是首先我们要了解 CI/CD 流水线是什么？从概念上来说，CI/CD 流水线应该有 3 个阶段——source、build 和 deploy：

Source：每个部署都需要一个代码管理工具，常见的工具包括 Github 和 GitLab。Bitbucket 也是一个不错的选择。在本文的场景中，我们选择 GitLab，因为它除了作为我们的源码管理工具之外，还可以提供内置的 CI/CD 功能。

Build：在构建文件.gitlab-ci.yaml 中提到的步骤（stages）将定义构建步骤。在这个阶段中，GitLab 平台将验证代码并运行一个 terraform plan。在各个步骤中，可以传递命令、设置变量、构建 Docker 镜像、创建文件等。这使得我们可以将步骤解耦，也就是说如果我们选择移除步骤或添加新的步骤将更加容易。

Deploy：在这一步骤中，有两个手动操作。我们采取的第一个手动操作是 deploy。这个选项会使用 Terraform 代码启动基础设施的创建。一旦执行了这个手动步骤，GitLab 就会联系到 AWS，用访问权限和秘钥进行认证，并开始将基础设施部署到公有云中（本例为 AWS）。另一个发挥重要作用的组件是 provider.tf 文件。这个文件定义了部署的云提供程序。我们的第二个手动选项是 destroy。就像 deploy 一样，它是手动触发的。在某些情况下此步骤可以自动化，但在大多数情况下，我们在执行部署或销毁部署时都要小心谨慎。同时建议执行这些步骤时限制访问权限，因为安全的最佳实践包括使用用户数据库，并为这些手动步骤的执行申请权限。

基础设施图解

此图展示了此部署中使用的所有工具及其在本次部署中提供的功能：

• GitLab：代码管理和 CI/CD
• AWS：弹性计算机云(EC2)、简单存储服务(S3)、Route 53(R53)、安全组、弹性负载均衡(ELB)。 S3：在本次部署中，我们需要手动创建 S3 bucket。在你开始你的部署之前，确保你已经创建你的 bucket 并在变量部分指定了它。S3 bucket 将维护 terraform.tfstate 文件。如果你想了解更多关于管理 Terraform 状态欢迎查阅以下链接： https://www.terraform.io/docs/state/index.html
• Terraform：基础设施即代码（IaC）；RKE 提供程序-允许配置 Kubernetes 集群；Rancher 2.x 提供程序-允许从 Terraform 代码中配置 Rancher 管理的集群；Helm 提供程序-可以安装 Helm chart 并最终在创建的基础设施上安装 Rancher。

CI/CD 流水线如何工作？

CI/CD 的步骤

构建文件的第一部分包括我们将在部署中需要执行的阶段：

stages:  - validate  - plan_before_apply  - apply  - destroy

Before Script

before script 为这次部署的成功奠定了基础，在这个过程中会创建两个文件：

1、backend.ft：这个文件将负责存放 ftstate 的 s3 bucket。

    - |
    cat < backend.tf
        terraform {
            backend "s3" {
            bucket     = "$BUCKET_NAME"
            key        = "$BUCKET_KEY"
            region     = "us-east-1"
            encrypt    = true
            }
        }
    EOF

2、variables.tf：这个文件将保存证书、VPC、K8S 版本等。这些参数是从 GitLab dashboard 的 settings 部分传递过来的。

    cat < variables.tf
    variable "aws_access_keys" {
    type = map(string)
    description = "AWS Access Keys for terraform deployment"

        default = {
            access_key = "$AWS_ACCESS_KEY_ID"
            secret_key = "$AWS_SECRET_ACCESS_KEY"
            region = "us-east-1"
        }
    }
    variable "number_of_nodes" {

构建阶段

1、 Validate：将验证工作目录下的配置文件

   validate:
    stage: validate
    script:
        - terraform validate

2、 plan_before_apply：将运行 terraform plan 并创建一个执行计划（execution plan）

plan_before_apply:
stage: plan_before_apply
script:
    - terraform plan
dependencies:
    - validate

3、 Apply：将运行 terraform apply 并执行该计划。这是一个手动步骤。

apply:
stage: apply
script:
    - apk update && apk add curl git
    - curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
    - chmod u+x kubectl && mv kubectl /bin/kubectl
    - mkdir -p ~/.kube
    - echo '' >  ~/.kube/config
    - apk add --update --no-cache curl ca-certificates
    - curl -L https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz |tar xvz
    - mv linux-amd64/helm /usr/bin/helm
    - chmod +x /usr/bin/helm
    - terraform apply --auto-approve

4、 Destroy：将销毁在 apply 步骤中创建的所有资源。这个步骤也是一个手动的步骤。

destroy:
stage: destroy
script:
    - mkdir -p ~/.kube
    - echo '' >  ~/.kube/config
    - terraform state rm "helm_release.cert_manager"
    - terraform state rm "helm_release.rancher"
    - terraform destroy --auto-approve
dependencies:
    - apply
when: manual

Apply

要执行 terraform apply，需要导航到项目的 CI/CD 部门。点击 New Pipleline 并运行新的流水线。一旦完成验证和计划步骤，点击 apply 步骤并运行。你应该可以了解提交到 repo 的情况。

Destroy

要销毁部署，请点击 CI/CD 控制台中的 destroy 步骤并运行。Terraform 将销毁流水线之前创建的所有基础设施。唯一会留下的是包含 terraform.tfstate 的 s3 bucket。如果你需要执行销毁步骤，Terraform 状态是至关重要的。

变量

要设置集群的节点数、Kubernetes 版本、Rancher 版本等，请导航至项目的“Settings”页面，然后在 CI / CD 下设置变量。

环境变量的建议值

AWS 云提供程序

我们在此部署中使用了 AWS 云提供程序。有关提供程序及其工作方式的更多信息，请参考 AWS 文档：https://www.terraform.io/docs/providers/aws/index.html

provider.tf 文件提供了一个如何使用提供程序的好例子。这个文件将允许 Terraform 代码与 AWS 交互，并部署资源（EC2、安全组、负载均衡器等）。

provider "aws" {
region  = "us-east-1"
profile = "default"
access_key      = lookup(var.aws_access_keys, "access_key")
secret_key      = lookup(var.aws_access_keys, "secret_key")

}

Rancher2 提供程序

Rancher2 提供程序是一个 Terraform 组件，需要作为插件导入才能工作。rancher-ha.tf 文件提供了一个很好的例子来说明如何使用提供程序。

resource "rancher2_bootstrap" "admin" {
provider = rancher2.bootstrap
depends_on = [null_resource.wait_for_rancher]
password = var.ui_password
}

我们使用 Rancher2 提供程序来创建 Rancher UI 管理账户。了解更多关于 Rancher2 提供程序的信息，欢迎查阅以下文档：

https://registry.terraform.io/providers/rancher/rancher2/latest/docs

GitLab Runner

如果你没有配置 runner 节点，你可以使用这个 repo 来设置 runner 的正确配置（https://gitlab.com/iby.autometa/gitlab-runner-aws）。或者按照 GitLab 文档中的说明来设置一个新的 runner（https://docs.gitlab.com/runner/install/）。

如果你已经有一个正在运行的 runner，你可以简单地添加这个配置。

#Register the runner
sudo gitlab-runner register \
--non-interactive \
--url "https://gitlab.com/" \
--registration-token "" \
--executor "docker" \
--docker-image hashicorp/terraform \
--description "docker-runner" \
--tag-list "" \
--run-untagged="true" \
--locked="false" \
--access-level="not_protected"

结论

这篇文章给予了我们几点启示：

首先，我们需要以自动化第一的思维方式来思考我们的日常工作。

其次，我们可以利用 CI/CD 的几个好处：使用 CI/CD 工具可以降低手动管理基础设施的成本；CI/CD 工具使我们能够更有效地协作；而且 CI/CD 工具可以让我们深入了解构建步骤和 runner 节点的 CLI 输出。

总的来说，使用 CI/CD 有助于我们在代码集成、代码构建和代码部署阶段遵循最佳实践。随着基础设施即代码工具（如 Terraform）和 AWS、Azure 和 GCP 的云提供商，CI/CD 工具可以让你轻松地将代码与基础设施一起部署。

本文转载自：RancherLabs（ID：RancherLabs）

原文链接：硬核干货 | 使用GitLab CI部署Rancher集群