Como as equipes usam o GitLab e o Terraform para implantar infraestrutura como código: uma demonstração

Usar um repositório Git como a fonte única de verdade para todo o código de infraestrutura e implantação de aplicações, com várias equipes trabalhando juntas, é uma boa prática de GitOps. As equipes de infraestrutura podem colaborar e implantar código em vários serviços de nuvem usando o Terraform para automação. Este artigo demonstra como as equipes podem criar um cluster do Kubernetes colaborando com colegas de equipe no GitLab.

Confira nesta demonstração como seguir boas práticas de GitOps para implantar infraestrutura como código, usando o Terraform para automação e o GitLab como a fonte única de verdade, bem como para CI.

Primeiros passos

Este grupo gitops-demo ilustra as etapas que as equipes de infraestrutura podem seguir.

Comece fazendo login no grupo que hospeda o projeto no GitLab. A próxima etapa é abrir o arquivo README.md, que mostra a estrutura subjacente do grupo gitops-demo. Existem alguns projetos individuais e dois subgrupos: infraestrutura e aplicações.

Há um repositório separado para cada nuvem: Azure, GCP e AWS, além de um repositório para modelos.
Arquivos semelhantes podem ser encontrados em todos os três repositórios de nuvem. Todos os arquivos são escritos no Terraform para automatizar o processo de implantação, enquanto um arquivo gitlab-ci.yml também é armazenado no repositório para definir as instruções de automação.

O arquivo de back-end

Usar o [Terraform Cloud Service] da HashiCorp (https://www.hashicorp.com/blog/announcing-terraform-cloud) como local remoto para o arquivo de estado mantém o arquivo seguro e centralizado, permitindo que ele seja acessado por qualquer processo. Uma vantagem de usar o Terraform Cloud é que ele possibilita bloquear o estado para garantir que apenas um job possa ser executado por vez e evitar que vários jobs façam alterações conflitantes. O código armazena os arquivos de estado no Terraform Cloud em uma organização chamada gitops-demo, em um espaço de trabalho chamado aws. Isso mantém o estado de execução no provedor de nuvem para que qualquer membro da equipe tenha acesso a qualquer momento.

terraform {
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "gitops-demo"
    workspaces {
      name = "aws"
    }
  }
}

EKS.tf file

O EKS é outro arquivo Terraform que usa o módulo EKS para o cluster Terraform. As equipes podem definir parâmetros, como o tipo de sub-rede e o número de nós, no arquivo EKS do 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
      }]
    }
  ]
}

Definir o administrador do GitLab

O provedor do Kubernetes pode ser usado para criar um usuário administrador do GitLab e configurar tudo automaticamente como código, gerenciado pelo Terraform.

Registrar o cluster com o GitLab

Agora que um cluster do Kubernetes foi criado, é hora de registrá-lo no GitLab para implantar mais código no cluster no futuro. A primeira etapa é usar o provedor do GitLab para criar um cluster de grupos chamado 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))}"
}

O código contém o nome do domínio, escopo do ambiente, e credenciais Kubernetes.

Depois que isso for executado, o cluster será criado na AWS e registrado automaticamente no grupo gitops-demo/apps.

Modelo do Terraform

Retorne ao grupo de infraestrutura e abra a pasta Modelos. Ao analisar o arquivo terraform.gitlab-ci.yml, é possível conferir como a CI funciona para implantar o código da infraestrutura na nuvem usando o Terraform.

Dentro do arquivo de CI, as equipes podem conferir algumas etapas diferentes: validar, planejar, aplicar e destruir. Ao utilizar a imagem base do Terraform da Hashicorp, os usuários podem executar diferentes tarefas.

A primeira etapa é inicializar o 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

A próxima etapa é validar se tudo está correto.

validate:
  stage: validate
  script:
    - terraform validate
    - terraform fmt -check=true
  only:
    - branches

É importante lembrar que bons fluxos de trabalho do GitOps incorporam a criação de uma solicitação de merge para as alterações.

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

A solicitação de merge

A solicitação de merge (MR) é a etapa mais importante no GitOps. Este processo consiste em revisar todas as alterações e verificar o impacto delas. A MR também é uma ferramenta de colaboração na qual os membros da equipe podem discutir as alterações e os stakeholders podem aprová-las antes de fazer o merge final no branch principal.

A solicitação de merge define o que acontecerá ao executar a infraestrutura como código. Depois que a MR é criada, o plano Terraform é enviado por upload para ela. Após a revisão e aprovação de todas as alterações, o código poderá ser mesclado no branch principal. Depois que as alterações de código forem mescladas, todas elas serão implantadas no ambiente de produção.

• O que significa infraestrutura como código?
• O que é GitOps
• Saiba como o GitLab simplifica os fluxos de trabalho do GitOps
• Descubra como será o futuro do GitOps com líderes do setor
• Leia o guia para iniciantes do GitOps