大数据和AI不分家,AI助力低代码和智能运维落地,AI智能体的探索实践,本届AS会议一站聚齐!>>> 了解详情
写点什么

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

  • 2021-05-09
  • 本文字数:3993 字

    阅读完需:约 13 分钟

硬核干货|使用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_applyscript:    - terraform plandependencies:    - validate
复制代码


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


apply:stage: applyscript:    - 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: destroyscript:    - mkdir -p ~/.kube    - echo '' >  ~/.kube/config    - terraform state rm "helm_release.cert_manager"    - terraform state rm "helm_release.rancher"    - terraform destroy --auto-approvedependencies:    - applywhen: 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.bootstrapdepends_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 runnersudo 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集群

2021-05-09 07:002077

评论

发布
暂无评论
发现更多内容

第四章作业

白知之明

第四周总结

Jove

MyBatis专栏 - 关联查询中的延迟加载

小马哥

Java mybatis 七日更 二月春节不断更

云原生中间件的下一站

apache/dubbo-go

微服务 云原生 dubbo 中间件

作业4

YING꯭YING

羚羊行走在悬崖边:一份报告背后的移动开发者“自救计划”

脑极体

第四周作业

墨狂之逸才

架构11周

FreeOcean

不可用原因

Qcon现代数据架构-《万亿级数据库MongoDB集群性能数十倍提升优化实践》核心17问详细解答

杨亚洲(专注MongoDB及高性能中间件)

MySQL 数据库 mongodb 分布式 分布式数据库mongodb

helm入门教学

三丰SanFeng

Kubernetes k8s Helm

一周信创舆情观察(2.1~2.7)

统小信uos

产品经理训练营--第四周学习总结

月亮 😝

产品训练营第四周作业

朱航

第四章作业-用例

Wangyunnfei

产品经理训练营第0期-第四次作业

孙行者

第0期 第四周作业 极客大学产品经理训练营

妹妹10分钟就玩懂了零拷贝和NIO,也太强了

moon聊技术

Java nio 零拷贝

产品经理第四周作业

朱琴

AI窥人(二):彻底“AI化”怎么样?

脑极体

第四周作业-用例文档

Au revoir

产品经理训练营 - 第四章作业 (一)

joelhy

产品经理训练营

第四周

Jove

产品训练营 - 作业 4

简小一

产品经理训练营-作业四

胡小湖

前端工程师必须知道的用javaScript刷新当前页面的3种方法

孙叫兽

JavaScript 大前端 刷新

干个副业开个小店的简单分析

boshi

创业 副业赚钱 七日更

计算机中的流水线技术到底是个啥?

冰河

程序员 进阶 计算机 流水线技术

云计算自动化对于虚拟化环境意味着什么?

浪潮云

云计算

面试官系列:讲讲快速失败和安全失败的区别?

后台技术汇

面试 2月春节不断更

容器 & 服务:Jenkins构建实例

程序员架构进阶

容器 持续集成 七日更 28天写作 2月春节不断更

微信朋友圈发动态用例及流程图(学习模拟):

🙈🙈🙈

极客大学产品经理训练营

如何检验人生的假设

熊斌

个人提升 2月春节不断更

硬核干货|使用GitLab CI部署Rancher集群_架构_Rancher_InfoQ精选文章