Skip to main content

Bestehende Infrastruktur in Terraform importieren

Artikel von
Headshot of Stephane Jourdan

Stephane Jourdan

feature synk iac terraform teal

2. Juli 2020

0 Min. Lesezeit

Anmerkung der Redaktion: Dieser Beitrag erschien ursprünglich auf CloudSkiff.com. CloudSkiff ist im Oktober 2021 zu Snyk gekommen .

Manchmal müssen Sie eine bestehende Infrastruktur in Terraform importieren. Dafür gibt es viele Gründe. Manche steigen gerade erst ein und müssen vorhandene Infrastrukturen migrieren und daraus eine neue Codebasis erstellen. Manchmal müssen Sie, selbst wenn Sie Expertin oder Experte sind, einfach von einem POC (Proof of Concept), den Sie schnell durch Klicken in Ihrer Konsole erstellt haben, zu einem Live-Projekt wechseln, das in der Produktion stabil laufen muss.

Angenommen, Sie verfügen bereits über eine Live-Infrastruktur, die Sie über Ihre Cloud-Konsole erstellt haben … Wie erzeugen Sie daraus Terraform-Code und, noch wichtiger, wie bringen Sie ihn zum Laufen?

In diesem Artikel stellen wir kurz die wichtigsten Möglichkeiten vor, automatisch Infrastrukturcode aus einer bestehenden Umgebung zu generieren – eine Umgebung zu klonen, zum Laufen zu bringen und sicherzustellen, dass sie reproduzierbar ist.

Bestehende Infrastruktur mit Terraform import in Terraform importieren

Wenn Sie nur wenige Ressourcen in Code umwandeln müssen und über die nötigen Kenntnisse verfügen, können Sie den Code einfach neu schreiben. Dazu müssen Sie natürlich genau wissen, wie diese Ressourcen konfiguriert sind.

Wenn Sie bereits über eine Terraform-Codebasis verfügen, müssen Sie den geschriebenen Code anschließend mit terraform import in Ihre Codebasis importieren. terraform import ist ein Terraform-Unterbefehl. Da dieser Code genau zu den vorhandenen Ressourcen im Konto Ihres Cloud-Anbieters passt, erhalten Sie ein perfektes Gleichgewicht zwischen Ihrem Code, Ihren vorhandenen Ressourcen und Ihrer TFState-Datei.

Bestehende Infrastruktur mit einem Importer in Terraform importieren

Die gerade erwähnte Option eignet sich für wenige Ressourcen. Bei größeren Umgebungen kann die Aufgabe jedoch schnell überwältigend werden. Auf dem Markt gibt es verschiedene Importer, Konverter, Scanner, Terraform-Generatoren usw., die Sie dabei unterstützen.

Einer davon, Terraformer, wurde vom Waze-SRE-Team in Tel Aviv entwickelt.

Wenn Sie Ihre Zugangsdaten angeben, scannt Terraformer das Konto Ihres Cloud-Anbieters nach Ressourcen. Findet das Tool eine Ressource, wandelt es sie in korrekten Terraform-Code mit einer funktionsfähigen State-Datei um.

Der Code, den Sie erhalten, ist nicht besonders sauber und ganz sicher nicht DRY. Er erledigt aber 80 % der Arbeit, sodass Sie darauf aufbauen können.

Wichtige Schritte, um importierte Infrastrukturen in funktionierenden Terraform-Code umzuwandeln

Nachdem Sie Ihre vorhandenen Ressourcen in Terraform importiert haben, müssen Sie unbedingt noch einige weitere Schritte ausführen, damit alles funktioniert. Denn in diesem Stadium ist der Code weder sauber noch optimiert.

Stellen Sie sicher, dass überall Variablen verwendet werden und alle Variablen vereinheitlicht sind.

Stellen Sie sich vor, Sie haben ein VPC-Netzwerk mit dem Namen VPC. Das kann problematisch sein, wenn Sie pro Region nur einen VPC-Namen verwenden können. Das ist bei Amazon-S3-Buckets der Fall. Beispielsweise können Sie weltweit nur einen S3-Bucket für alle Kunden haben.

Das Umbenennen der Ressourcen kostet etwas Zeit. Wenn Sie jedoch mithilfe von Variablen sicherstellen, dass die verwendeten Namen eindeutig sind, können Sie sicher sein, dass sich der Code in einer anderen Region wiederverwenden lässt.

Deklarieren Sie Ihre Abhängigkeiten explizit.

Ein Problem beim automatischen Importieren von Ressourcen in Terraform-Code ist, dass die Verknüpfungen zwischen den Ressourcen oft nicht hergestellt werden. Sie sehen dann Ressourcen, die als Ganzes sinnvoll sind, für die jedoch keine Abhängigkeiten explizit deklariert wurden. Oder die Abhängigkeiten sind zwar deklariert, aber nicht mithilfe von Variablen.

Beispielsweise kann eine Sicherheitsgruppenregel deklariert und mit einer ID für diese Sicherheitsgruppe verknüpft sein, sodass alles ordnungsgemäß funktioniert. Fehlt jedoch eine interne Verknüpfung – genauer gesagt eine Abhängigkeit im Code –, werden Sie bei der nächsten Bereitstellung in einer anderen Region wahrscheinlich Regeln und eine Sicherheitsgruppe bereitstellen, die nicht miteinander verknüpft sind.

Zu guter Letzt: Sorgen Sie durch Zufallswerte für Reproduzierbarkeit

Der letzte wichtige Schritt ist, durch Zufallswerte für Reproduzierbarkeit zu sorgen. Im Grunde reicht es aus, Namen mit einigen zufälligen Zeichen zu versehen.

Ich verwende persönlich einen zufälligen String mit einem Suffix. Dadurch wird ein einfacher, acht Zeichen langer Zufallsstring generiert (ohne Sonderzeichen, denn Sonderzeichen im Namen möchten Sie vermeiden). Dafür erstelle ich einfach lokale Variablen.

Für meine Produktions- und Staging-Systeme füge ich sie einfach als Suffix hinzu. So bin ich sicher, dass ich sowohl in der Produktions- als auch in der Staging-Umgebung einen eindeutigen, darauf basierenden Zufallsnamen habe. Und mit einfachem Kopieren und Einfügen kann ich problemlos eine weitere Testumgebung erstellen.

# cluster name needs to be unique
resource "random_string" "suffix" {
  length  = 8
  special = false
}
locals {
  production_cluster_name = "eks-production-${random_string.suffix.result}"
  staging_cluster_name    = "eks-staging-${random_string.suffix.result}"
}
# Production Cluster
module "production_cluster" {
  source          = "terraform-aws-modules/eks/aws"
  version         = "7.0.1"
  cluster_name    = local.production_cluster_name
  cluster_version = var.kubernetes_version
  manage_aws_auth = true
  worker_ami_name_filter = "amazon-eks-node-1.14-v20200312"
  subnets = module.vpc.private_subnets
  vpc_id = module.vpc.vpc_id
  map_users = var.map_users
  workers_additional_policies          = [aws_iam_policy.allow_ecr.arn]
  worker_additional_security_group_ids = [aws_security_group.management.id]
  worker_groups = [
    {
      name                 = "production-1.14-wg-small"
      instance_type        = "t3.small"
      asg_max_size         = 2
      asg_desired_capacity = 1
    },
    {
      name                 = "production-1.14-wg-medium"
      instance_type        = "t3.medium"
      asg_max_size         = 3
      asg_desired_capacity = 2
      asg_min_size         = 2
    }
  ]
  tags = {
    environment = "production"
    Terraform   = "true"
  }
  workers_group_defaults = {
    key_name = aws_key_pair.admin.key_name
  }
}

Zusammenfassung

Der Import Ihrer Ressourcen ist nur der erste Schritt und reicht selten aus.

Damit Ihr Code einsatzbereit ist, sollten Sie als Nächstes:

  • sicherstellen, dass überall Variablen verwendet werden

  • sicherstellen, dass alle Variablen vereinheitlicht sind

  • Ihre Abhängigkeiten deklarieren und miteinander verknüpfen

  • Variablen mit Zufallswerten versehen, um eindeutige Namen zu generieren.

Terraform-Code absichern

Snyk IaC schützt Ihre Terraform-Konfigurationen (sowie Kubernetes-, CloudFormation- und ARM-Vorlagen!) während der Entwicklung und bietet angeleitete Fehlerbehebungen, damit Sie Änderungen zusammenführen und weitermachen können. Sie können den Code während des Schreibens testen, Änderungen in Ihren Git-Repositories überwachen und Tests in Ihren Build-Pipelines vor der Bereitstellung automatisieren. Die Einrichtung eines kostenlosen Tarifs dauert nur wenige Minuten – während ein Sicherheitsvorfall aufgrund einer IaC-Fehlkonfiguration lebenslange Schäden verursachen kann. Registrieren Sie sich und schützen Sie Ihre Konfigurationen ab sofort.

Sichern Sie Ihre Infrastruktur an der Quelle

Snyk automatisiert die IaC-Sicherheit und Compliance in Workflows und erkennt abweichende sowie fehlende Ressourcen.

Weiterlesen

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.

Blog

Evo ADS Govern Agent Behavior ist allgemein verfügbar: MCP-Nutzung unter Kontrolle bringen

Evo ADS Govern Agent Behavior ist jetzt allgemein verfügbar und startet mit MCP Governance. Entdecken, genehmigen, überwachen, protokollieren und blockieren Sie die MCP-Server-Nutzung in führenden KI-Coding-Agenten.

illustration hero ai
Blog

Was ist Agentic AppSec?

Erfahren Sie, wie Agentic AppSec fundierte, klar begrenzte und unabhängig überprüfte KI-Agenten einsetzt, um den Application-Security-Kreislauf zu steuern.