写点什么

GitOps 系列二|如何借助极狐 GitLab 和 Terraform 以代码形式构建基础设施?

用户头像
极狐GitLab
关注
发布于: 2021 年 06 月 17 日
GitOps系列二|如何借助极狐GitLab 和Terraform以代码形式构建基础设施?

当多个团队使用一个 Git 仓库作为所有基础设施和应用部署代码的单一事实来源时,他们正在遵循一个良好的流程规范。基础设施团队可以使用 Terraform 进行自动化协作,并将代码部署到多个云服务中。本文展示了团队如何在极狐 GitLab 内与队友协作来创建一个 Kubernetes 集群。

第一步


首先登录到该项目在极狐 GitLab 中所在的组。下一步是打开 README.md 文件,其中显示了 gitops-demo 组的基本结构。这里有几个单独的项目和两个子组:基础设施和应用。



基础设施分组内部


在这个文件夹下,每个云都有一个单独的资源库(如图中所示 Azure、GCP、AWS),此外,还有一个模板库。



类似的文件可以在所有三个对应的“云”代码仓库中找到所有的文件都是用 Terraform 编写的,以实现部署过程的自动化,同时在存储库中还存储了一个极狐 GitLab-ci.yml 文件,为自动化提供指示。

后台文件


使用 HashiCorp 的 Terraform 云服务在远程存储状态文件,可以保证状态文件的安全,并且在一个中心位置,便于任何作业的访问。使用 Terraform Cloud 的一个好处是,它有能力锁定状态,以确保每次只有一个工作可以运行,防止多个工作做出冲突的改变。代码将状态文件存储在Terraform云的一个名为 gitops-demo 的组织中,工作空间名为 aws。这样运行状态就会保存在云供应商中,任何团队成员都可以随时访问。


terraform {

  backend "remote" {

    hostname     = "app.terraform.io"

    organization = "gitops-demo"

    workspaces {

      name = "aws"

    }

  }

}


EKS.tf 文件


EKS 是另一个 Terraform 文件,它利用了 Terraform 集群的 EKS 模块。团队可以在 EKS Terraform 文件中定义参数,如子网的类型和节点的数量。


module "eks" {

  source           = "terraform-aws-modules/eks/aws"

  cluster_name     = "gitops-demo-eks"

  subnets          = "${module.vpc.public_subnets}"

  write_kubeconfig = "false"

  tags = {

    Terraform   = "true"

    Environment = "dev"

  }

  vpc_id = "${module.vpc.vpc_id}"

  worker_groups = [

    {

      instance_type = "m4.large"

      asg_max_size  = 5

      tags = [{

        key                 = "Terraform"

        value               = "true"

        propagate_at_launch = true

      }]

    }

  ]

}


定义极狐 GitLab 管理员


利用 Kubernetes Provider 创建一个极狐 GitLab 管理用户,并自动设置为代码,由 Terraform 管理。

在极狐 GitLab 上注册集群


现在,一个 Kubernetes 集群已经创建。接下来我们开始在极狐 GitLab 上进行注册,以便将来在集群上部署更多代码。第一步是使用极狐 GitLab Provider 创建一个名为 AWS cluster 的群集。


data "gitlab_group" "gitops-demo-apps" {

  full_path = "gitops-demo/apps"

}

provider "gitlab" {

alias   = "use-pre-release-plugin"

  version = "v2.99.0"

}

resource "gitlab_group_cluster" "aws_cluster" {

  provider           = "gitlab.use-pre-release-plugin"

  group              = "${data.gitlab_group.gitops-demo-apps.id}"

  name              = "${module.eks.cluster_id}"

  domain             = "eks.gitops-demo.com"

  environment_scope  = "eks/*"

kubernetes_api_url = "${module.eks.cluster_endpoint}"

kubernetes_token = "${data.kubernetes_secret.gitlab-admin-token.data.token}"

kubernetes_ca_cert = "${trimspace(base64decode(module.eks.cluster_certificate_authority_data))}"

}


该代码包含域名、环境范围和 Kubernetes 凭证。

运行该程序后,集群将在 AWS 中创建,并自动注册到 gitops-demo/apps 组。


使用极狐 GitLab CI 部署代码

Terraform 模板

返回到基础设施组,打开 Templates 文件夹。在查看 terraform.GitLab-ci.yml 文件时,可以看到 CI 是如何使用 Terraform 将基础设施代码部署到云中的。

在 CI 文件里面,团队可以看到几个不同的阶段:验证、计划、应用和销毁。使用 Hashicorp 的 Terraform 基础镜像,用户可以运行不同的任务。


第一步是初始化 Terraform。


before_script:

  - terraform --version

  - terraform init

  - apk add --update curl

  - curl -o kubectl 

https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/linux/amd64/kubectl

  - install kubectl /usr/local/bin/ && rm kubectl

  - curl -o aws-iam-authenticator 

https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/linux/amd64/aws-iam-authenticator

  - install aws-iam-authenticator /usr/local/bin/ && rm 

aws-iam-authenticator


下一步是验证一切是否正确。


validate:

   stage: validate

   script:

    - terraform validate

    - terraform fmt -check=true

   only:

    - branches


重要的是要记住,好的 GitOps 工作流程包括为变化创建一个合并请求


merge review:

    stage: plan

    script:

    - terraform plan -out=$PLAN

    - echo \`\`\`diff > plan.txt

    - terraform show -no-color ${PLAN} | tee -a plan.txt

 - echo \`\`\` >> plan.txt

    - sed -i -e 's/  +/+/g' plan.txt

    - sed -i -e 's/  ~/~/g' plan.txt

    - sed -i -e 's/  -/-/g' plan.txt

    - MESSAGE=$(cat plan.txt)

 - >-

  curl -X POST -g -H "PRIVATE-TOKEN: ${GITLAB_TOKEN}"

 --data-urlencode "body=${MESSAGE}"

"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/discussions"

artifacts:

    name: plan

    paths:

      - $PLAN

  only:

    - merge_requests


合并请求

合并请求(MR)是 GitOps 中最重要的步骤。这是一个审查所有修改并能监视这些变化带来影响的过程。合并请求也是一个协作工具,团队成员可以在这里讨论修改,可以在最后合并到主分支之前批准修改。

合并请求定义了基础设施作为代码运行时将会发生什么。MR 创建后,Terraform 计划被上传到 MR。在所有的修改都被审查和批准后,代码可以被合并到主分支上。一旦代码变化被合并,所有的变化将被部署到生产中。

免费试用

更多教程和介绍,欢迎试用

用户头像

极狐GitLab

关注

开源开放,人人贡献 2021.05.19 加入

开放式一体化DevOps平台,助力行业高速协同增长!

评论

发布
暂无评论
GitOps系列二|如何借助极狐GitLab 和Terraform以代码形式构建基础设施?