Wie Teams GitLab und Terraform für Infrastructure as Code nutzen: Eine Demo

Wenn mehrere Teams ein Git-Repository als einzige Quelle der Wahrheit für den gesamten Infrastruktur- und Anwendungsbereitstellungscode verwenden, ist das eine gute GitOps-Vorgehensweise. Infrastrukturteams können zusammenarbeiten und mit Terraform Code für mehrere Cloud-Dienste für die Automatisierung bereitstellen. Dieser Artikel zeigt, wie Teams einen Kubernetes-Cluster erstellen können, indem sie mit Teamkolleg(inn)en in GitLab zusammenarbeiten.

Diese Demo zeigt, wie man eine gute GitOps-Vorgehensweise befolgt, um Infrastructure as Code mit Terraform für die Automatisierung und GitLab als Single Source Of Truth (und CI) bereitzustellen.

Erste Schritte

Die Gruppe gitops-demo veranschaulicht die Schritte, die Infrastrukturteams befolgen können.

Melde dich zunächst in der Gruppe an, in der sich das Projekt in GitLab befindet. Im nächsten Schritt öffnest du die Datei README.md, die die zugrunde liegende Struktur der Gruppe gitops-demo zeigt. Es gibt einige Einzelprojekte und zwei Untergruppen: Infrastruktur und Anwendungen.

Es gibt ein separates Repository für jede Cloud: Azure, GCP und AWS sowie ein Repository für Vorlagen.
Ähnliche Dateien findest du in allen drei Cloud-Repositories. Alle Dateien werden in Terraform geschrieben, um den Bereitstellungsprozess zu automatisieren. Außerdem wird im Repository auch eine Datei mit dem Namen gitlab-ci.yml gespeichert, die Anweisungen für die Automatisierung enthält.

Die Backend-Datei

Mit dem Terraform-Cloud-Service von HashiCorp als Remote-Standort für die Statusdatei wird die Statusdatei sicher und an einem zentralen Ort aufbewahrt, sodass jeder Prozess auf sie zugreifen kann. Ein Vorteil von Terraform Cloud ist die Möglichkeit, den Status zu sperren, um sicherzustellen, dass immer nur ein Job ausgeführt werden kann. Dadurch wird verhindert, dass unterschiedliche Jobs widersprüchliche Änderungen vornehmen. Der Code speichert die Statusdateien in der Terraform Cloud in einer Organisation namens gitops-demo in einem Arbeitsbereich namens aws. Dadurch bleibt der Cloud-Anbieter im Status „Wird ausgeführt“, so dass jedes Teammitglied jederzeit Zugriff darauf hat.

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

EKS.tf file

EKS ist eine weitere Terraform-Datei, die das EKS-Modul für den Terraform-Cluster nutzt.

Teams können Parameter wie die Art der Subnetze und die Anzahl der Knoten in der EKS-Terraform-Datei festlegen.

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-Admin definieren

Mit dem Kubernetes-Anbieter kannst du ein Benutzerkonto für eine(n) GitLab-Administrator(in) erstellen und automatisch als Code und von Terraform verwaltet einrichten.

Registrierung des Clusters bei GitLab

Jetzt, wo ein Kubernetes-Cluster erstellt wurde, ist es an der Zeit, ihn bei GitLab zu registrieren, damit in Zukunft mehr Code für den Cluster bereitgestellt werden kann. Der erste Schritt besteht darin, mit dem GitLab-Anbieter einen Gruppencluster namens AWS-Cluster zu erstellen.

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

Code enthält den Domänennamen, den Umgebungsbereich und die Kubernetes-Anmeldedat.

Nach der Ausführung wird der Cluster in AWS erstellt und automatisch in der Gruppe gitops-demo/apps registriert.

Terraform-Vorlage

Kehr zur Infrastrukturgruppe zurück und öffne den Ordner „Vorlagen“. Wenn du dir die Datei „terraform.gitlab-ci.yml“ ansiehst, kannst du sehen, wie CI bei der Bereitstellung von Infrastrukturcode in der Cloud mit Terraform funktioniert.

In der CI-Datei sehen die Teams verschiedene Phasen: validate (validieren), plan (planen), apply (anwenden) und destroy (zerstören). Mit dem Terraform-Basis-Image von Hashicorp können Benutzer(innen) verschiedene Aufgaben ausführen.

Der erste Schritt ist die Initialisierung von 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

Im nächsten Schritt musst du validieren, dass alles korrekt ist.

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

Denke daran, dass gute GitOps-Workflows das Erstellen eines Merge Request für die Änderungen beinhalten.

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

Der Merge Request

Der Merge Request (MR) ist der wichtigste Schritt in GitOps. Dies ist der Prozess, um alle Änderungen zu überprüfen und die Auswirkungen dieser Änderungen zu sehen. Der MR ist auch ein Kollaborationstool, in dem Teammitglieder Änderungen besprechen und Stakeholder Änderungen vor dem endgültigen Merge in den main-Branch genehmigen können.

Der Merge Request legt fest, was passieren soll, wenn die Infrastruktur als Code (Infrastructure as Code) ausgeführt wird. Nachdem der MR erstellt wurde, wird der Terraform-Plan in den MR hochgeladen. Nachdem alle Änderungen geprüft und genehmigt wurden, kann der Code mit dem main-Branch zusammengeführt werden. Sobald die Codeänderungen zusammengeführt sind, werden alle Änderungen in der Produktion bereitgestellt.

• Was bedeutet Infrastructure as Code?
• Was ist GitOps?
• Erfahre, wie GitLab die Workflows von GitOps optimiert
• Entdecke die Zukunft von GitOps von Branchenführern
• Lies den Einsteigerleitfaden zu GitOps