Wie man Terraform-Zustand zu GitLab CI/CD migriert

Als Software-Profi, der Infrastruktur als Code (IaC) verwaltet, arbeiten Sie häufig mit Terraform. Beim Helfen neuer Kunden bei der Nutzung von IaC ist es üblich, Dinge zu vereinfachen, aber die Verwaltung einer Terraform-Zustandsdatei ist die erste Herausforderung, mit der Sie konfrontiert sind. Im Kern enthält der Terraform-Zustand vertrauliche Informationen, die nicht in der Quellcodeverwaltung gespeichert werden sollten, aber gleichzeitig wird es nicht skalieren, wenn mehrere Benutzer am gleichen Terraform-Zustand arbeiten. Die Antwort darauf? Backends.

Es ist wichtig zu beachten, dass Sie diese Zustandsdatei in einem S3-Bucket speichern und DynamoDB zur Verwaltung des Sperrzustands verwenden könnten. Dieser Ansatz zwingt Sie jedoch dazu, zusätzliche Ressourcen zu erstellen, was ihn zu einer komplizierten Option macht, insbesondere wenn der Kunde GitLab verwendet. GitLab hat kürzlich die Einstiegshürde zur Integration von Terraform gesenkt, indem es eine Möglichkeit bietet, den Terraform-Zustand zu speichern und zu verwalten, sowie eine einfache Möglichkeit, ein CI dafür einzurichten.

In diesem Artikel erklären wir, was eine Terraform-Zustandsdatei ist, wie Sie sie zu GitLab migrieren und eine CI-Pipeline dafür einrichten. Besuchen Sie unser Repository hier.

Inhaltsverzeichnis

• Was ist Terraform State?
• Wie lässt sich GitLab zur Verwaltung des Terraform-Zustands verwenden?
• Wie lässt sich GitLab dazu bringen, Ihre IaC über eine CI-Pipeline auszuführen
  • Bonus-Tipp: Infracost
• Zusammenfassung

Was ist Terraform State?

Terraform speichert Informationen über die in Ihrem Code definierten Infrastrukturen in einem State-Datei. Geschrieben in JSON, notiert es im Wesentlichen eine Zuordnung vom Terraform-Code zu den tatsächlich erstellten Ressourcen. Folgendes ist ein Beispiel für den Inhalt einer terraform.tfstate-Datei. Hauptsächlich holt Terraform jedes Mal, wenn es ausgeführt wird, den aktuellen Status seiner EC2-Instanz und vergleicht diesen mit Ihrer Terraform-Konfiguration, um festzustellen, welche Änderungen angewendet werden müssen:

{   
     "version": 4,    
     "terraform_version": "0.12.0",    
     "serial": 1,    
     "lineage": "1f2087f9-4b3c-1b66-65db-8b78faafc6fb",    
     "outputs": {},    
     "resources": [     
      {        
         "mode": "managed",        
         "type": "aws_instance",       
         "name": "example",       
         "provider": "provider.aws",       
         "instances": [         
           {           
             "schema_version": 1,           
             "attributes": {              
               "ami": "ami-0c55b159cbfafe1f0",             
               "availability_zone": "us-west-2a",             
               "id": "i-00a123a0accffffff",            
               "instance_state": "running",             
               "instance_type": "t2.micro",            
               "(...)": "(truncated)"           
            }         
          }       
        ]      
      }   
    ]  
 }

Standardmäßig wird diese terraform.tfstate-Datei lokal gespeichert, wo auch Ihre Terraform-Dateien, Ihr Plan und Ihre Änderungen angewendet werden. Für ein persönliches Projekt, bei dem Sie nur einige Tests durchführen, ist das in Ordnung, aber nicht empfohlen, und das aus folgenden Gründen:

• In einem gemeinsam genutzten Speicherort gespeichert: Wenn Sie diese State-Datei auf Ihrem lokalen Arbeitsplatz hosten und mit einem anderen Ingenieur zusammenarbeiten müssten, würde es kompliziert. Beide müssten sicherstellen, dass Sie die neueste Version des Zustands verwenden, und es könnten Rennbedingungen auftreten, wenn Sie gleichzeitig einen Terraform-Plan oder eine Anwendung ausführen.
• Schützen von sensiblen Informationen: Eine generierte State-Datei kann Verschlüsselungsschlüssel und Infrastrukturpasswörter enthalten. Allerdings werden State-Dateien standardmäßig nicht verschlüsselt, und das Speichern sensibler Informationen im Klartext ist eine schlechte Idee.
• Sperren: Die meisten Versionsverwaltungssysteme unterstützen keine Form der Sperrung, die verhindert, dass zwei Teammitglieder gleichzeitig auf derselben State-Datei Terraform apply ausführen. Dies ist ein weiterer Grund, warum wir keine State-Datei sehen, die von der Quellcodeverwaltung verwaltet wird.

So erhalten Sie GitLab zur Verwaltung des Terraform-Zustands

Da Terraform als Standard für die Bereitstellung von Cloud-Infrastruktur angesehen wird, bietet GitLab seit etwa einem Jahr eine Möglichkeit, Ihren Terraform-Zustand zu speichern und zu verwalten. Aus diesem Grund möchten wir Ihnen den Migrationsprozess mitteilen, da wir kürzlich angefangen haben, GitLab zur Verwaltung unserer IaC zu verwenden.

Für diesen Artikel gehen wir davon aus, dass Sie einen lokalen Zustand verwenden und Ihr Zustand mit einem AWS S3 Bucket oder einer anderen Backend-Lösung verwaltet wird.

Zunächst müssen Sie Ihr backend.tf so ändern, dass es HTTP verwendet:

terraform {  
    backend "http" {} 
  }

Als Nächstes müssen Sie vier Variablen in Ihrem Terminal einrichten:

1. PROJECT_ID: Sie können dies ganz einfach finden, indem Sie zu Ihrem Repository auf der Seite „Projektübersicht“ navigieren.

2. TF_USERNAME: Der GitLab-Benutzername, der Zugriff auf das Repository hat, an dem Sie arbeiten.

3. TF_PASSWORD: Zugastoken, das von Ihrem GitLab-Benutzer generiert wurde.

4. TF_ADDRESS: URL des entfernten Zustand-Backends.

PROJECT_ID="28450092"
TF_USERNAME="florianpialoux"
TF_PASSWORD="123456789"
TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/aws-buckets"

Sie können nun den Migrationsbefehl ausführen, der Ihren Terraform-Zustand von seinem vorherigen Speicherort zu GitLab verschiebt, mit dem folgenden Befehl:

  terraform init \  
    -migrate-state \  
    -backend-config=address=${TF_ADDRESS} \  
    -backend-config=lock_address=${TF_ADDRESS}/lock \ 
    -backend-config=unlock_address=${TF_ADDRESS}/lock \  
    -backend-config=username=${TF_USERNAME} \ 
    -backend-config=password=${TF_PASSWORD} \  
    -backend-config=lock_method=POST \ 
    -backend-config=unlock_method=DELETE \ 
    -backend-config=retry_wait_min=5

Sie müssen eine Bestätigung durch ein „ja“ geben, damit GitLab anfangen kann, Ihr Zustandsdatei zu verwalten. Hier ist ein Beispiel von einem lokalen Zustand zu GitLab:

Beispiel S3 zu GitLab:

I noticed for some of the state files I had from S3 will be blank even after using the migrate-state command ran previously. In this case, you can run this:  

terraform state pull > aws-buckets.json

Kopieren und einfügen Sie den Inhalt aus dem S3-Zustand und führen Sie einen Push aus:

terraform state push -lock=true aws-buckets.json

GitLab unterstützt das Versionsverwaltung für Ihr Terraform-Statusdatei, aber das Anzeigen/Wiederherstellen älterer Versionen über die Web-Oberfläche erfordert, dass Sie ein GitLab Premium-Abonnement verwenden. Andernfalls müssen Sie eine GraphQL-API Anfrage.

So lassen Sie GitLab Ihr IaC über eine CI-Pipeline ausführen

GitLab bietet einen Docker-Container, der GitLab-Terraform enthält, was ein dünnes Wrapper-Skript um das offizielle Terraform-Binär ist. Alternativ könnten Sie den offiziellen Docker-Container von Hashicorp verwenden. Weitere Informationen über den GitLab Terraform Image finden Sie hier.

Sobald der Terraform-Anwendungsauftrag ausgeführt wird, können Sie sehen, wann der Status verwendet wurde und mit welcher Pipeline.

Bonus-Tipp: Infracost

Wie Sie vielleicht bemerkt haben, betrachten wir unser gitlab-ci.yaml und fügen Infracost hinzu, was uns ermöglicht, mehr Kontrolle über unsere Cloud-Rechnung zu haben, da es Ihnen eine Kostenschätzung gibt, wann immer Sie eine neue Ressource zu Ihrem IaC definieren.

Schlussfolgerung

Die Verwendung Ihrer Terraform-State und CI auf Gitlab ist eine großartige Möglichkeit, GitOps-Best Practices zu befolgen. Beide bilden eine ausgezeichnete Kombination zur Entwicklung und Bereitstellung von IaC. Da die meisten von Ihnen wahrscheinlich bereits GitLab für Ihre Repositorys verwenden, wird es viel einfacher, Ihre IaC unter einem Dach zu haben und GitLab die Verwaltung Ihres Terraform-State zu überlassen, indem es die Verschlüsselung während der Übertragung und im Ruhezustand sowie die Versionierung, Sperrung und Entsperrung des Zustands unterstützt.