In che modo i team utilizzano GitLab e Terraform per l'Infrastructure as Code: una dimostrazione

Se diversi team utilizzano un repository Git come unica fonte di riferimento per tutto il codice relativo all'infrastruttura, in tal caso si può parlare di buona prassi GitOps. I team incaricati dell'infrastruttura possono collaborare ed eseguire il deployment del codice su più servizi cloud utilizzando Terraform per l'automazione. Questo articolo mostra come i team possono creare un cluster Kubernetes collaborando con gli altri colleghi all'interno di GitLab.

In questa dimostrazione vengono illustrate le buone prassi GitOps per eseguire il deployment dell'Infrastructure as Code utilizzando Terraform per l'automazione e GitLab come unica fonte di riferimento (e CI).

Guida introduttiva

Questo gruppo gitops-demo illustra i passaggi che possono seguire i team incaricati all'infrastruttura.

Per iniziare, esegui l'accesso al gruppo in cui si trova il progetto all'interno di GitLab. Apri quindi il file README.md, che mostra la struttura alla base del gruppo gitops-demo. Oltre ad alcuni progetti individuali, vi sono due sottogruppi: infrastruttura e applicazioni.

Esiste un repository separato per ogni servizio cloud (Azure, GCP e AWS), oltre a un repository dedicato ai modelli.
È possibile trovare file simili in tutti e tre i repository cloud. Tutti i file sono scritti in Terraform per automatizzare il processo di deployment, mentre un file gitlab-ci.yml è memorizzato nel repository per fornire istruzioni ai fini dell'automazione.

Il file di back-end

Utilizzando il servizio Terraform Cloud di HashiCorp come posizione remota per il file di stato, quest'ultimo resta al sicuro e in una posizione centralizzata, in modo che possa essere accessibile da qualsiasi processo. Un vantaggio dell'utilizzo del servizio Terraform Cloud è la possibilità di bloccare lo stato per fare in modo che sia possibile eseguire un solo job alla volta, evitando che diversi job apportino modifiche in conflitto tra loro. Il codice memorizza i file di stato di Terraform Cloud in un'organizzazione chiamata gitops-demo e in uno spazio di lavoro denominato aws. Lo stato di esecuzione viene mantenuto nel provider di servizi cloud, in modo che ogni membro del team possa accedervi in qualsiasi momento.

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

EKS.tf file

Il file EKS è un altro file Terraform che si serve del modulo EKS per il cluster Terraform. I team possono definire parametri come il tipo di sottoreti e il numero di nodi nel file Terraform EKS.

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
      }]
    }
  ]
}

Imposta un utente amministratore in GitLab

Il provider Kubernetes può essere utilizzato per creare un utente amministratore di GitLab e configurarlo automaticamente tramite codice, utilizzando Terraform per gestire tale processo.

Registra il cluster con GitLab

Una volta creato il cluster Kubernetes, è il momento di registrarlo con GitLab in modo da poter eseguire il deployment di più porzioni di codice al cluster in futuro. Il primo passo è utilizzare il provider GitLab per creare un cluster di gruppo denominato cluster AWS.

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))}"
}

Il codice contiene il nome di dominio, l'ambito dell'ambiente e le credenziali di Kubernetes.

Una volta avviata l'esecuzione, il cluster verrà creato in AWS e registrato automaticamente nel gruppo gitops-demo/apps.

Modello Terraform

Torna al gruppo dell'infrastruttura e apri la cartella dei modelli. Osservando il file terraform.gitlab-ci.yml, è possibile vedere come opera la CI per eseguire il deployment del codice dell'infrastruttura nel cloud utilizzando Terraform.

All'interno del file CI, i team possono osservare alcune fasi diverse: validazione, pianificazione, applicazione ed eliminazione definitiva. Utilizzando l'immagine di base in Terraform di Hashicorp, gli utenti possono eseguire diverse attività.

Il primo passo è inizializzare 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

Il passo successivo è verificare che tutto sia corretto.

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

È bene ricordare che un flusso di lavoro GitOps efficace prevede la creazione di una richiesta di merge per ogni modifica effettuata.

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

La richiesta di merge

La richiesta di merge (RM) è il passaggio più importante in GitOps. Questo processo serve a rivedere tutte le modifiche e a verificarne l'impatto. La RM è inoltre uno strumento di collaborazione che permette ai membri del team di discutere delle modifiche, e agli stakeholder di approvarle, prima di eseguire il merge finale nel ramo principale.

La richiesta di merge definisce ciò che accadrà al momento dell'esecuzione dell'Infrastructure as Code. Una volta creata la RM, viene caricato il piano Terraform sulla richiesta di merge. Dopo che tutte le modifiche sono state riviste e approvate, è possibile eseguire il merge del codice al ramo principale. Dopo che tutte le modifiche del codice sono state sottoposte a merge, ne verrà effettuato il deployment in produzione.

• Cosa significa Infrastructure as Code?
• Che cos'è GitOps
• Scopri come GitLab ottimizza i flussi di lavoro GitOps
• Scopri il futuro di GitOps grazie ai leader del settore
• Leggi la guida per neofiti a GitOps