在当今瞬息万变的 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 一样,它是手动触发的。在某些情况下此步骤可以自动化,但在大多数情况下,我们在执行部署或销毁部署时都要小心谨慎。同时建议执行这些步骤时限制访问权限,因为安全的最佳实践包括使用用户数据库,并为这些手动步骤的执行申请权限。
此图展示了此部署中使用的所有工具及其在本次部署中提供的功能:
构建文件的第一部分包括我们将在部署中需要执行的阶段:
stages: - validate - plan_before_apply - apply - destroy
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
要执行 terraform apply,需要导航到项目的 CI/CD 部门。点击 New Pipleline 并运行新的流水线。一旦完成验证和计划步骤,点击 apply 步骤并运行。你应该可以了解提交到 repo 的情况。
要销毁部署,请点击 CI/CD 控制台中的 destroy 步骤并运行。Terraform 将销毁流水线之前创建的所有基础设施。唯一会留下的是包含 terraform.tfstate 的 s3 bucket。如果你需要执行销毁步骤,Terraform 状态是至关重要的。
要设置集群的节点数、Kubernetes 版本、Rancher 版本等,请导航至项目的“Settings”页面,然后在 CI / CD 下设置变量。
我们在此部署中使用了 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 提供程序是一个 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
如果你没有配置 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)
领取专属 10元无门槛券
私享最新 技术干货