Anleitungen

In unseren vorherigen Artikeln haben wir die Grundlagen von Infrastructure as Code mit Terraform und Jamf Pro behandelt und dann die dedizierten Terraform-Provider für Jamf Protect und die Jamf Platform durchgegangen. Falls Sie diese noch nicht gelesen haben, würden wir empfehlen, dort zu beginnen — sie behandeln Terraform-Grundlagen, Projektstruktur, State Management und wie Sie Jamf-Ressourcen von Grund auf in Code definieren.

Dieses Mal gehen wir auf eine Frage ein, die wir häufig hören: „Das klingt alles großartig, aber ich habe bereits hunderte von Richtlinien, Profilen, Skripten und Gruppen in meiner Jamf-Umgebung. Muss ich das wirklich alles manuell umschreiben?"

Die kurze Antwort ist nein. Wir haben ein Tool namens jamformer genau dafür entwickelt — aber bevor wir einsteigen, ist es wichtig, klar zu machen, was es ist und was nicht.

Was ist jamformer?

jamformer ist ein Enablement- und Beschleunigungstool für Teams, die Jamf mit Terraform einführen. Es verbindet sich mit Ihrer bestehenden Jamf-Instanz, entdeckt alles, was es finden kann, und generiert ein Terraform-Projekt als Ausgangspunkt — ein realistisches Gerüst, das Sie erlernen und verfeinern können. Stellen Sie es sich als eine Brücke vor zwischen dem, wo Sie heute sind (eine vollständig konfigurierte Jamf-Umgebung, die über die Konsole verwaltet wird) und wo Sie sein möchten (diese gleiche Umgebung, die als Code verwaltet wird) — aber die Brücke ist kein Förderband. Sie gehen immer noch hinüber.

Es ist absichtlich nicht:

• Ein Produktions-Code-Generator. Das HCL, das es erzeugt, ist ein erster Entwurf. Bevor Sie damit echte Infrastruktur verwalten, sollten Sie jede Datei überprüfen, in Ihre eigene Modulstruktur umgestalten, Namenskonventionen anwenden, Secret-Handhabung verschärfen und mit Provider-Drift-Eigenheiten umgehen.
• Ein Ersatz für das Erlernen von Terraform oder den Jamf-Providern. Es flacht die Lernkurve ab; es entfernt sie nicht.
• Ein One-Click-Migrationsbutton. Große oder ungewöhnliche Jamf-Umgebungen erfordern immer menschliches Urteilsvermögen.

Wobei es gut ist:

• Zu sehen, was sich tatsächlich in Ihrer Jamf-Instanz befindet, ausgedrückt im eigenen Ressourcenmodell der Terraform-Provider — Attribute, Querverweise, Lebenszyklusbesonderheiten und alles.
• Proof-of-Concepts, Demos, Workshops, interne Schulungen und Migrationssitzungen zu bootstrappen.
• Ingenieuren ein realistisches Gerüst zum Umgestalten in IaC zu geben, anstatt auf einen leeren Editor zu starren.

Es ist auch schreibgeschützt. jamformer ändert, erstellt oder löscht nichts in Ihrer Jamf-Instanz. Die einzige Sache, die es schreibt, ist ein Satz von Terraform-Dateien auf Ihrem lokalen Computer.

Behalten Sie diese Perspektive für den Rest dieses Artikels im Hinterkopf. Wenn wir den Workflow durchgehen und Beispielausgaben zeigen, sehen Sie Rohmaterial, das ein menschlicher Ingenieur verfeinern kann — nicht den fertigen Artikel.

Warum nicht einfach terraform import verwenden?

Das können Sie absolut, und wenn Sie den Protect-Artikel gelesen haben, haben Sie bereits gesehen, wie terraform import und terraform query mit list-Blöcken bestehende Ressourcen unter Verwaltung bringen können.

Aber wenn Sie eine Jamf-Umgebung über die Konsole verwaltet haben, wissen Sie, dass sich da eine Menge befindet. Das manuelle Importieren von allem bedeutet, jeden Ressourcentyp zu erfassen, hunderte von Importblöcken mit den korrekten Jamf-IDs zu schreiben, herauszufinden, welche Richtlinie auf welches Skript und welche Gruppe und welche Kategorie verweist, eingebettete Skripte und Konfigurationsprofilnutzlasten in eigenständige Dateien zu extrahieren und mit Provider-Eigenheiten bei Standardwerten umzugehen.

Das ist eine Menge Arbeit. Wir wollten das einfacher machen.

Was wird unterstützt?

jamformer funktioniert mit vier Terraform-Providern in der Jamf-Produktfamilie:

Allein für Jamf Pro umfasst das Richtlinien, Skripte, Konfigurationsprofile, Smart Groups, statische Gruppen, Computer-Prestages, Mobile Device Profile, Extension Attributes, Pakete, Kategorien, Gebäude, Abteilungen und vieles mehr — plus Einstellungen wie Client Check-In, Cloud Distribution Point und Self Service-Konfiguration. Die autoritative, immer aktuelle Liste ist jamformer -list-resources (optional gefiltert mit -provider).

Was passiert, wenn Sie es ausführen?

Wenn Sie jamformer auf Ihre Jamf-Instanz richten, durchläuft es mehrere Phasen. Wir werden durchgehen, was jede macht, damit Sie wissen, was Sie erwartet.

Zunächst werden Ihre Ressourcen entdeckt. Für Jamf Pro authentifiziert es sich bei Ihrer Instanz (OAuth2 oder Basic Auth) und fragt die API für jeden unterstützten Ressourcentyp ab. Es durchlaufen Ihre Umgebung in Abhängigkeitsreihenfolge — zuerst Sites und Kategorien, dann Skripte und Pakete, dann Richtlinien und Profile — damit es die Beziehungen zwischen Ressourcen abbilden kann. Für Jamf Protect und Jamf Platform verwendet es terraform query mit list-Blöcken (der gleiche Ansatz, den wir im Protect-Artikel behandelt haben), um Ressourcen direkt über den Provider zu entdecken.

Als nächstes werden Importblöcke generiert. Für jede entdeckte Ressource schreibt jamformer einen Terraform-import-Block mit einer Bezeichnung, die vom Ressourcennamen abgeleitet ist. Leerzeichen werden zu Unterstrichen, Sonderzeichen werden entfernt, und wenn zwei Ressourcen die gleiche Bezeichnung erhalten, wird ein numerisches Suffix hinzugefügt, um die Eindeutigkeit zu bewahren. Es generiert auch provider.tf, variables.tf und terraform.tfvars, die für den richtigen Provider konfiguriert sind.

So könnten diese Importblöcke aussehen:

import {
  to = jamfpro_policy.software_update_enforce
  id = "142"
}

import {
  to = jamfpro_script.install_rosetta
  id = "87"
}

import {
  to = jamfpro_category.productivity
  id = "5"
}

Dann wird Terraform aufgefordert, das HCL zu generieren. jamformer führt terraform plan -generate-config-out aus (oder terraform query -generate-config-out für Protect und Platform), wobei der Provider das HCL für jede importierte Ressource erzeugt. Da der Provider selbst die Schwerarbeit hier leistet, passt die generierte Konfiguration immer zu dem, was der Provider erwartet.

Wenn bestimmte Ressourcen nicht importiert werden — es passiert manchmal, dass ein Provider eine bestimmte Ressource nicht sauber zurücklesen kann — entfernt jamformer automatisch den fehlgeschlagenen Importblock und versucht erneut. Sie sehen eine Nachricht darüber, welche Ressourcen übersprungen wurden, damit Sie diese später bearbeiten können.

Abschließend wird die Ausgabe bereinigt. Die rohe Ausgabe von Terraform ist eine einzelne große Datei mit Literalwerten überall. jamformer transformiert sie in etwas, das Sie tatsächlich verwenden möchten:

• jamformer schreibt Jamf-ID-Literale in Terraform-Referenzen um. Eine Richtlinie, die die Kategorie-ID 5 referenziert, wird zu jamfpro_category.productivity.id, damit Terraform die Beziehungen zwischen Ihren Ressourcen versteht — genau wie Sie es von Hand schreiben würden.
• Eingebettete Skripte gehen in einzelne Dateien unter support_files/scripts/, Konfigurationsprofilnutzlasten zu support_files/macos_configuration_profiles/, Extension Attribute Skripte zu support_files/extension_attributes/ und Mobile Device App-Konfigurationen zu support_files/app_configurations/. jamformer aktualisiert das HCL mit file()-Referenzen, damit Ihre Skripte und Profile echte Dateien sind, die Sie diff, überprüfen und unabhängig bearbeiten können. Geräteregistrierungs- und Volume-Purchasing-Token verwenden file(var.xxx)-Pfadvariablen — Sie platzieren Ihre Token-Dateien (heruntergeladen von Apple Business Manager) unter dem Pfad, den Sie in der Variable angeben.
• jamformer löst Symbol-Ressourcen in CDN-URLs auf (Symbole werden nicht lokal heruntergeladen) und fügt einen lifecycle { ignore_changes }-Block hinzu, um unnötige Destroy/Create-Zyklen beim ersten Apply zu verhindern.
• Optionale Attribute, die null zurückkommen, werden entfernt, Werte, die bekanntermaßen Probleme verursachen (wie category_id = -1 für unkategorisierte Ressourcen), werden entfernt, und die einzelne große Datei wird in pro-Ressourcentyp-Dateien aufgeteilt — policies.tf, scripts.tf, categories.tf usw.
• Ein Validierungsdurchlauf führt terraform validate aus, um bedingt ungültige Attribute zu erkennen — beispielsweise Attribute, die nur für einen bestimmten CDN-Typ gültig sind — und entfernt sie automatisch, damit Sie keine Schema-Fehler von Hand verfolgen müssen.

Nach der Nachbearbeitung wird die Ausgabe auf Secrets gescannt. Jamf-Umgebungen enthalten oft Anmeldedaten, die in Konfigurationsprofile, Skripten und Ressourcenattribute eingebettet sind — Dinge wie LDAP-Bindkennwörter, SMTP-Anmeldedaten, Wi-Fi-Shared Secrets und API-Token. jamformer verwendet gitleaks mit Jamf-spezifischen Regeln, um diese zu finden, bevor Sie sie versehentlich in Git committen.

Wenn jamformer Secrets findet, zeigt es Ihnen einen Bericht, gruppiert nach Ressource und Attribut. Im interaktiven Modus können Sie wählen, alle Erkennungen automatisch zu beheben, sie einzeln durchzugehen oder die Behebung ganz zu überspringen. Die Behebung verschiebt Secrets in sensitive Terraform-Variablen — für .tf-Dateien wird der Secret-Wert durch eine var.-Referenz ersetzt; für Support-Dateien wie Skripte und Profile wird die Datei in ein .tpl-Template mit templatefile() konvertiert. Sie können diesen Schritt mit -skip-secret-scan überspringen, wenn Sie Secrets lieber selbst behandeln möchten.

Erste Schritte

Wenn Sie den Einführungsartikel verfolgt haben, sollten Sie bereits Terraform und einen Text-Editor eingerichtet haben. Die Schritte hier sind unkompliziert.

1. jamformer installieren

Homebrew:

brew install Jamf-Concepts/tap/jamformer

Vorgefertigte Binärdateien und ein .pkg-Installer sind auf der Releases-Seite verfügbar.

Sie müssen Terraform nicht separat installieren — jamformer lädt es automatisch in ein temporäres Verzeichnis herunter, sodass es nicht mit einer vorhandenen Terraform-Installation auf Ihrem Computer in Konflikt gerät.

2. Führen Sie es gegen Ihre Instanz aus

Der einfachste Weg zum Einstieg ist, jamformer ohne Argumente auszuführen:

jamformer

Es wird Sie interaktiv durch alles geleitet — welcher Provider Sie verwenden möchten, Ihre Instanz-URL und Ihre Anmeldedaten. Sie geben Kennwörter und Client-Secrets als versteckte Eingabe ein, damit sie nicht in Ihrem Terminal-Verlauf angezeigt werden.

Shorthand-URLs funktionieren auch hier — Sie können einfach Ihreinstanz eingeben und jamformer wird es auf Ihreinstanz.jamfcloud.com erweitern. Für Protect wird Ihr-Mandant auf Ihr-Mandant.protect.jamfcloud.com erweitert.

Sobald Sie mit dem Tool vertraut sind oder es scriptbasiert verwenden möchten, können Sie Anmeldedaten über Umgebungsvariablen festlegen:

# Jamf Pro mit OAuth2
export JAMF_CLIENT_ID='Ihre-Client-ID'
export JAMF_CLIENT_SECRET='Ihr-Client-Secret'
jamformer -url https://Ihreinstanz.jamfcloud.com

# Jamf Protect
export JAMF_CLIENT_ID='Ihre-Client-ID'
export JAMF_CLIENT_SECRET='Ihr-Client-Secret'
jamformer -provider jamfprotect -url https://Ihr-Mandant.protect.jamfcloud.com

jamformer liest Anmeldedaten nur aus Umgebungsvariablen oder interaktiven Eingabeaufforderungen — niemals aus CLI-Flags — um zu vermeiden, dass Secrets in Shell-Verlauf und Prozesslisten lecken. Sie können die URL als Flag (-url) oder über JAMF_URL übergeben.

jamformer schreibt Anmeldedaten nicht in terraform.tfvars und generiert eine .gitignore, die tfvars-Dateien, State-Dateien und das .terraform/-Verzeichnis ausschließt.

3. Das Importieren von allem auf einmal ist optional

Wenn Ihre Umgebung groß ist und Sie lieber klein anfangen möchten, können Sie auf bestimmte Ressourcentypen abzielen:

# Beginnen Sie mit nur Richtlinien, Skripten und Kategorien
./jamformer -include-resources "policies scripts categories"

# Alles außer Pakete und Symbole
./jamformer -exclude-resources "packages icons"

# Alle verfügbaren Filternamen sehen
./jamformer -list-resources

Wenn ein Abhängigkeitstyp nicht enthalten ist (sagen Sie, Sie importieren Richtlinien aber nicht Kategorien), bleiben Referenzen zu diesen Typen als Jamf-ID-Literale statt Terraform-Ausdrücke. Sie können später mit mehr Typen erneut ausführen, wenn Sie bequemer werden.

Wie sieht die Ausgabe also aus?

Nachdem jamformer fertig ist, haben Sie ein Verzeichnis, das ungefähr so aussieht:

generated/
  .gitignore
  provider.tf
  variables.tf
  terraform.tfvars
  policies.tf
  policies_import.tf
  scripts.tf
  scripts_import.tf
  categories.tf
  categories_import.tf
  ...
  support_files/
    scripts/
      install_rosetta.sh
      set_wallpaper.sh
    extension_attributes/
      battery_health.sh
    macos_configuration_profiles/
      wifi_corporate.mobileconfig
      filevault_enforce.mobileconfig
    device_enrollment_tokens/     (leer - platzieren Sie Ihre .p7m-Dateien hier)
    volume_purchasing_tokens/     (leer - platzieren Sie Ihre .vpptoken-Dateien hier)
    app_configurations/
      managed_browser.xml

Jeder Ressourcentyp erhält eine eigene .tf-Datei und eine entsprechende _import.tf-Datei. Das support_files/-Verzeichnis enthält extrahierte Skripte, Profile und App-Konfigurationen, die über file()-Ausdrücke referenziert werden. jamformer erstellt Token-Verzeichnisse (device_enrollment_tokens/ und volume_purchasing_tokens/) als empfohlenen Ort für Ihre Apple Business Manager Token-Dateien — diese verwenden file(var.xxx)-Pfadvariablen, da die API keine Token-Daten zurückgibt.

Kompakter Modus

Standardmäßig generiert jamformer einen Ressourcenblock pro Objekt — ein flaches, explizites Layout, das einfach zu lesen und zu überprüfen ist. Aber wenn Ihre Umgebung Dutzende ähnlicher Ressourcen hat (Kategorien, Gebäude, Abteilungen), kann sich die Ausgabe repetitiv anfühlen.

Das Flag -compact konsolidiert berechtigte Ressourcentypen in for_each + locals-Muster, was eine Ausgabe erzeugt, die dem ähnelt, was Sie von Hand schreiben würden:

jamformer -compact

Ohne Kompaktmodus würden Sie einzelne Blöcke bekommen:

resource "jamfpro_category" "productivity" {
  name = "Productivity"
}

resource "jamfpro_category" "security" {
  name = "Security"
}

Mit aktiviertem Kompaktmodus werden diese zu:

locals {
  categories = {
    productivity = { name = "Productivity" }
    security     = { name = "Security" }
  }
}

resource "jamfpro_category" "all" {
  for_each = local.categories
  name     = each.value.name
}

jamformer schreibt Querverweise automatisch um, um die neue Adressierung zu verwenden — jamfpro_category.all["productivity"].id statt jamfpro_category.productivity.id — damit alles verbunden bleibt. Es aktualisiert Importblöcke auf die gleiche Weise.

jamformer bestimmt die Berechtigung dynamisch zur Laufzeit. Ein Ressourcentyp ist berechtigt, wenn die Datei zwei oder mehr Ressourcenblöcke enthält, die alle den gleichen Satz von Attributen teilen und keiner verschachtelte Blöcke hat (außer lifecycle). Attribute, die in allen Instanzen identisch sind, werden zu Literalwerten auf dem Ressourcenblock; nur die Werte, die variieren, gehen in die Locals-Zuordnung. Dies funktioniert über alle vier Provider hinweg.

Wenn Sie eine feinere Kontrolle möchten, können Sie auf bestimmte Typen abzielen:

# Kompaktieren Sie nur Kategorien und Gebäude
jamformer -compact -compact-include "categories buildings"

# Kompaktieren Sie alles Berechtigte außer Richtlinien
jamformer -compact -compact-exclude "policies"

Multi-Environment-Unterstützung

⚠️ Experimentell und hochgradig fortgeschritten. Diese Funktion richtet sich an Personen, die bereits mit Terraform-Modulen, Long-Lived-Branch-Workflows und dem Jamf-Provider-Ressourcenmodell fließend sind. Die Ausgabe ist mehr Gerüst-Stufe als der Single-Environment-Modus, nicht weniger — erwarten Sie, das generierte Modul, die Pro-Environment-Roots und die Variable-Extraktion zu bearbeiten, bevor etwas davon verwendbar ist. Behandeln Sie es als Research/Enablement-Funktion, nicht als unterstützten Produktions-Workflow. Wenn Sie neu bei Terraform sind oder noch an Ihrem ersten Single-Instance-Projekt arbeiten, beginnen Sie dort und kehren Sie später hierher zurück.

Wenn Sie mehrere Jamf Pro Umgebungen verwalten — Staging und Produktion, oder Dev und Prod — haben Sie wahrscheinlich überlegt, wie Sie diese synchron halten. jamformer kann ein Terraform-Projekt generieren, das um ein gemeinsames Modul mit Pro-Environment-Root-Verzeichnissen strukturiert ist, das für einen Git-Branching-Workflow ausgelegt ist, bei dem jeder Long-Lived-Branch eine Umgebung darstellt.

export JAMF_URL_STAGING=https://staging.jamfcloud.com
export JAMF_CLIENT_ID_STAGING=xxx
export JAMF_CLIENT_SECRET_STAGING=xxx
export JAMF_URL_PROD=https://prod.jamfcloud.com
export JAMF_CLIENT_ID_PROD=xxx
export JAMF_CLIENT_SECRET_PROD=xxx

jamformer -multi-env "staging prod"

jamformer führt die Entdeckung gegen jede Umgebung unabhängig durch, matching Ressourcen nach Namen und erzeugt eine Ausgabe, die ungefähr so aussieht:

generated/
  modules/jamf/                # gemeinsame Ressourcendefinitionen
    policies.tf                # Ressourcen in allen Umgebungen vorhanden
    scripts.tf
    categories.tf
    policies_staging_only.tf   # Ressourcen nur in Staging
    variables.tf               # Moduleingabevariablen
    providers.tf
    support_files/             # Dateien, die über Umgebungen hinweg identisch sind
      scripts/
      macos_configuration_profiles/
  environments/
    staging/
      main.tf                  # Provider-Konfiguration + Modulaufruf
      backend.tf               # Platzhalter für Ihr State-Backend
      variables.tf
      terraform.tfvars         # Umgebungsspezifische Werte
      imports.tf               # Importblöcke mit module.jamf. Präfix
      support_files/           # Dateien, die sich von der anderen Umgebung unterscheiden
    prod/
      main.tf
      backend.tf
      variables.tf
      terraform.tfvars
      imports.tf
      support_files/

Das gemeinsame Modul in modules/jamf/ enthält Ressourcendefinitionen, die allen Umgebungen gemeinsam sind. Wobei Attributwerte über Umgebungen hinweg unterschiedlich sind — eine Richtlinie mit einer anderen category_id oder ein Profil mit einer anderen description — extrahiert jamformer diese Werte in Modulvariablen und setzt sie pro Umgebung in terraform.tfvars. Querverweise bleiben echte Terraform-Ausdrücke (z. B. jamfpro_category.productivity.id), damit die Beziehungen zwischen Ressourcen intakt bleiben.

Dies funktioniert am besten, wenn Sie Ihre Umgebungen absichtlich synchron halten — die gleichen Richtlinien, Skripte, Profile und Gruppen über Instanzen hinweg bereitgestellt. Je mehr sie übereinstimmen, desto sauberer die Ausgabe. Davon abgesehen verwaltet jamformer die häufigen realen Unterschiede:

• Gleiche Ressource, unterschiedliche Einstellungen (z. B. eine Richtlinie mit einer anderen Kategorie oder Häufigkeit in Staging vs Prod) — die unterschiedlichen Attribute werden zu Modulvariablen, wobei die Werte jeder Umgebung in ihren eigenen terraform.tfvars sind. jamformer sortiert Variablen alphabetisch und gruppiert sie nach Ressourcentyp für Lesbarkeit.
• Ressourcen, die in einigen Umgebungen vorhanden sind, aber nicht in anderen (z. B. eine Test-Richtlinie nur in Staging) — jamformer trennt diese in klar gekennzeichnete Dateien wie policies_staging_only.tf innerhalb des Moduls. Auf dem Branch für eine andere Umgebung löschen Sie einfach diese Dateien.
• Support-Dateien, die unterschiedlich sind (z. B. ein Skript mit leicht unterschiedlichem Inhalt über Instanzen hinweg) — Dateien, die über alle Umgebungen hinweg identisch sind, befinden sich im support_files/-Verzeichnis des gemeinsamen Moduls. Wenn sich Dateien unterscheiden, platziert jamformer sie im support_files/-Verzeichnis jeder Umgebung und übergibt sie dem Modul als Variablen.

Jedes Umgebungsverzeichnis hat sein eigenes backend.tf-Placeholder, seinen eigenen State und seine eigenen Importblöcke mit module.jamf.-Präfix. Das bedeutet, Sie können terraform plan und terraform apply unabhängig pro Umgebung ausführen, parallel wenn nötig, ohne das Risiko, dass der State einer Umgebung die andere beeinflusst.

jamformer verwendet die erste aufgelistete Umgebung als Quelle der Wahrheit für die gemeinsamen Ressourcendefinitionen; verwenden Sie -source-env, um dies zu überschreiben. Es matching Ressourcen nach Namen, sodass eine Richtlinie namens „Software Update - Enforce" in Staging eine Richtlinie mit dem gleichen Namen in Prod matching, unabhängig von ihren Jamf-IDs.

Der vorgesehene Workflow besteht darin, die Ausgabe in ein Repository zu committen, einen Long-Lived-Branch pro Umgebung zu erstellen, jedes Branch's backend.tf mit dem entsprechenden State-Backend zu konfigurieren und CI einzurichten, um terraform apply im entsprechenden environments/<env>/-Verzeichnis auszuführen, wenn Code auf diesem Branch landet. Änderungen fließen aus Feature-Branches in die erste Umgebung, dann fördern sie über Branches über Pull Requests.

Je mehr sich Ihre Umgebungen unterscheiden, desto mehr Variablen und Umgebungs-spezifische Dateien enthält die Ausgabe. Wenn Ihre Instanzen erheblich unterschiedlich sind, können Sie jamformer separat für jede ausführen und unabhängige Terraform-Projekte verwalten.

Arbeiten mit der generierten Ausgabe

Wir haben es oben gesagt und wir sagen es hier nochmal, denn dies ist der Teil, der am meisten zählt: Die generierte Konfiguration ist nicht produktionsfähiges Terraform. jamformer ist ein Enablement- und Beschleunigungstool. Es gibt Ihnen einen realistischen Ausgangspunkt auf der Reise zur Verwaltung Ihrer Jamf-Umgebung als Code — nicht eine Abkürzung, die Sie sofort dorthin bringt. Planen Sie echte Zeit zum Überprüfen, Verfeinern und Verstehen dessen ein, das es erzeugt hat, bevor etwas echte Infrastruktur-Änderungen verwaltet.

Die Ausgabe ist absichtlich flach — einen Ressourcenblock pro Objekt, eine Datei pro Typ, keine Module. In der Praxis werden Sie es wahrscheinlich in eine modulare Projektstruktur umgestalten möchten, HCL-Funktionen wie for_each und locals nutzen, um Wiederholungen zu reduzieren, Dinge wie Instanz-URLs und gemeinsame Einstellungen zu Variablen für Ihre Umgebung machen und Ressourcen auf eine Weise organisieren, die für Ihr Team Sinn macht. jamformer gibt Ihnen das Rohmaterial, um das zu tun; wie Sie es gestalten, liegt bei Ihnen. Diese Gestaltungsarbeit ist der Ort, an dem der größte Teil des Terraform-Lernens tatsächlich stattfindet — und es ist der ganze Grund, warum jamformer in dieser Form existiert.

Angesichts dessen, hier ist der Workflow, den wir empfehlen würden.

Die gleichen Befehle, die Sie in der Einführung gelernt haben, gelten hier:

cd generated
terraform plan       # Überprüfen Sie den Importplan, überprüfen Sie auf Provider-Fehler

Erwarten Sie Unterschiede in Ihrem ersten Plan. Es ist normal, Unterschiede zwischen dem zu sehen, was Terraform generiert, und dem, was sich tatsächlich in Ihrer Jamf-Instanz befindet. Einige Attribute können Werte anzeigen, die nicht dem entsprechen, was Sie in der Konsole sehen, einige optionale Felder können Standard haben, die der Provider ausfüllt, die sich von der Live-Konfiguration unterscheiden, und einige Ressourcen können Validierungsfehler aufgrund von Write-Only-Feldern haben, die der Provider nicht zurücklesen kann. Dies sind Provider-Level-Eigenheiten, keine Bugs in jamformer, und sie benötigen manuelle Aufmerksamkeit.

Arbeiten Sie durch die Plan-Ausgabe, beheben Sie alle Fehler und passen Sie Attribute an, bis Sie glücklich mit dem sind, das Terraform meldet. Dieser Überprüfungsprozess ist der Ort, an dem Sie das