Handleidingen

In onze vorige artikelen behandelden we de basis van Infrastructure as Code met Terraform en Jamf Pro en doorliepen we vervolgens de specifieke Terraform-providers voor Jamf Protect en het Jamf Platform. Als u die nog niet heeft gelezen, raden we aan daar te beginnen — ze behandelen de fundamenten van Terraform, projectstructuur, state management en hoe u Jamf-resources vanaf nul in code definieert.

Deze keer pakken we een vraag aan die we vaak horen: "Dit klinkt allemaal geweldig, maar ik heb al honderden policies, profielen, scripts en groepen in mijn Jamf-omgeving. Moet ik dat echt allemaal met de hand herschrijven?"

Het korte antwoord is nee. We hebben een tool gebouwd genaamd jamformer om hierbij te helpen — maar voordat we erin duiken, is het belangrijk om eerlijk te zijn over wat het is en wat het niet is.

Wat is jamformer?

jamformer is een enablement- en acceleratietool voor teams die Jamf met Terraform adopteren. Het maakt verbinding met uw bestaande Jamf-instantie, ontdekt alles wat het kan vinden, en genereert een Terraform-project als startpunt — een realistisch scaffold waar u van kunt leren en verfijnen. Zie het als een brug tussen waar u nu bent (een volledig geconfigureerde Jamf-omgeving beheerd via de console) en waar u wilt zijn (diezelfde omgeving beheerd als code) — maar de brug is geen lopende band. U loopt er nog steeds zelf overheen.

Het is bewust niet:

• Een productie-codegenerator. De HCL die het produceert is een eerste concept. Voordat u er echte infrastructuur mee beheert, verwacht elk bestand te reviewen, te refactoren naar uw eigen modulestructuur, naamgevingsconventies toe te passen, secret-handling aan te scherpen en provider-drift-eigenaardigheden af te handelen.
• Een vervanging voor het leren van Terraform of de Jamf-providers. Het vlakt de leercurve af; het verwijdert deze niet.
• Een one-click migratieknop. Grote of ongebruikelijke Jamf-omgevingen zullen altijd menselijk oordeelsvermogen nodig hebben.

Waar het wel goed voor is:

• Zien wat er daadwerkelijk in uw Jamf-instantie zit, uitgedrukt in het resource-model van de Terraform-providers — attributen, kruisverwijzingen, lifecycle-eigenaardigheden en al het andere.
• Bootstrappen van proofs-of-concept, demo's, workshops, interne trainingen en migratieplanning-sessies.
• Engineers een realistisch scaffold geven om te refactoren naar IaC in plaats van naar een lege editor te staren.

Het is ook alleen-lezen. jamformer wijzigt, maakt of verwijdert niets in uw Jamf-instantie. Het enige wat het schrijft is een set Terraform-bestanden op uw lokale machine.

Houd dat kader in gedachten voor de rest van dit bericht. Wanneer we de workflow doorlopen en voorbeeldoutput tonen, kijkt u naar grondstof voor een menselijke engineer om te verfijnen — niet het eindproduct.

Waarom niet gewoon terraform import gebruiken?

Dat kan absoluut, en als u het Protect-artikel heeft gelezen, heeft u al gezien hoe terraform import en terraform query met list-blokken bestaande resources onder beheer kunnen brengen.

Maar als u al enige tijd een Jamf-omgeving via de console beheert, weet u dat er veel in zit. Alles handmatig importeren betekent elk resourcetype inventariseren, honderden import-blokken schrijven met de juiste Jamf-ID's, uitzoeken welk beleid naar welk script en welke groep en welke categorie verwijst, ingesloten scripts en configuratieprofielpayloads naar losse bestanden extraheren, en omgaan met provider-eigenaardigheden rond standaardwaarden.

Dat is veel werk. We wilden dit makkelijker maken.

Wat ondersteunt het?

jamformer werkt met vier Terraform-providers in de Jamf-productfamilie:

Voor alleen Jamf Pro omvat dat policies, scripts, configuratieprofielen, Smart Groups, Static Groups, computer prestages, mobile device profielen, extension attributes, packages, categorieën, gebouwen, afdelingen en nog veel meer — plus instellingen zoals Client Check-In, Cloud Distribution Point en Self Service-configuratie. De gezaghebbende, altijd actuele lijst is jamformer -list-resources (optioneel gefilterd met -provider).

Wat gebeurt er als u het uitvoert?

Wanneer u jamformer naar uw Jamf-instantie wijst, doorloopt het een paar fasen. We doorlopen wat elke fase doet zodat u weet wat u kunt verwachten.

Eerst ontdekt het uw resources. Voor Jamf Pro authenticeert het naar uw instantie (OAuth2 of basic auth) en bevraagt de API voor elk ondersteund resourcetype. Het doorloopt uw omgeving in afhankelijkheidsvolgorde — eerst sites en categorieën, dan scripts en packages, dan policies en profielen — zodat het de relaties tussen resources kan mappen. Voor Jamf Protect en Jamf Platform gebruikt het terraform query met list-blokken (dezelfde aanpak die we in het Protect-artikel behandelden) om resources rechtstreeks via de provider te ontdekken.

Vervolgens genereert het import-blokken. Voor elke ontdekte resource schrijft jamformer een Terraform import-blok met een label afgeleid van de resourcenaam. Spaties worden underscores, speciale tekens worden verwijderd, en als twee resources hetzelfde label krijgen, wordt een numeriek achtervoegsel toegevoegd om dingen uniek te houden. Het genereert ook provider.tf, variables.tf en terraform.tfvars geconfigureerd voor de juiste provider.

Zo kunnen die import-blokken eruitzien:

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

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

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

Dan vraagt het Terraform om de HCL te genereren. jamformer voert terraform plan -generate-config-out uit (of terraform query -generate-config-out voor Protect en Platform), waardoor de provider de HCL voor elke geïmporteerde resource produceert. Omdat de provider zelf hier het zware werk doet, komt de gegenereerde configuratie altijd overeen met wat de provider verwacht.

Als specifieke resources niet kunnen worden geïmporteerd — het gebeurt, soms kan een provider een bepaalde resource niet schoon teruglezen — verwijdert jamformer automatisch het falende import-blok en probeert opnieuw. U ziet een bericht over welke resources zijn overgeslagen zodat u ze later kunt afhandelen.

Tot slot ruimt het de output op. De ruwe output van Terraform is één groot bestand met overal letterlijke waarden. jamformer transformeert het naar iets waar u daadwerkelijk mee zou willen werken:

• jamformer herschrijft letterlijke Jamf-ID's naar Terraform-referenties. Een beleid dat verwijst naar categorie-ID 5 wordt jamfpro_category.productivity.id, zodat Terraform de relaties tussen uw resources begrijpt — precies zoals u het met de hand zou schrijven.
• Ingesloten scripts gaan naar individuele bestanden onder support_files/scripts/, configuratieprofiel-payloads naar support_files/macos_configuration_profiles/, extension attribute-scripts naar support_files/extension_attributes/, en mobile device app-configuraties naar support_files/app_configurations/. jamformer werkt de HCL bij met file()-referenties zodat uw scripts en profielen echte bestanden zijn die u onafhankelijk kunt diffen, reviewen en bewerken. Device enrollment en volume purchasing tokens gebruiken file(var.xxx) pad-variabelen — u plaatst uw tokenbestanden (gedownload van Apple Business Manager) op het pad dat u specificeert in de variabele.
• jamformer lost icon-resources op naar CDN-URL's (icons worden niet lokaal gedownload) en voegt een lifecycle { ignore_changes }-blok toe om onnodige destroy/create-cycli bij eerste apply te voorkomen.
• Optionele attributen die terugkomen als null worden verwijderd, waarden waarvan bekend is dat ze problemen veroorzaken (zoals category_id = -1 voor niet-gecategoriseerde resources) worden verwijderd, en het enkele grote bestand wordt gesplitst in per-resourcetype-bestanden — policies.tf, scripts.tf, categories.tf enzovoort.
• Een validatiepass voert terraform validate uit om conditioneel ongeldige attributen te detecteren — bijvoorbeeld attributen die alleen geldig zijn voor een specifiek CDN-type — en verwijdert ze automatisch zodat u niet handmatig schema-fouten hoeft na te jagen.

Na nabewerking scant jamformer de output op secrets. Jamf-omgevingen bevatten vaak credentials ingesloten in configuratieprofielen, scripts en resource-attributen — dingen zoals LDAP-bind-wachtwoorden, SMTP-credentials, Wi-Fi shared secrets en API-tokens. jamformer gebruikt gitleaks met Jamf-specifieke regels om deze te vinden voordat u ze per ongeluk naar Git commit.

Wanneer jamformer secrets vindt, toont het u een rapport gegroepeerd per resource en attribuut. In interactieve modus kunt u kiezen om alle bevindingen automatisch te remediëren, ze individueel door te lopen of remediatie helemaal over te slaan. Remediatie verplaatst secrets naar gevoelige Terraform-variabelen — voor .tf-bestanden wordt de secret-waarde vervangen door een var.-referentie; voor support-bestanden zoals scripts en profielen wordt het bestand geconverteerd naar een .tpl-template met templatefile(). U kunt deze stap overslaan met -skip-secret-scan als u liever zelf secrets afhandelt.

Aan de slag

Als u het introductie-artikel heeft gevolgd, zou u al Terraform en een teksteditor moeten hebben ingesteld. De stappen hier zijn rechttoe rechtaan.

1. Installeer jamformer

Homebrew:

brew install Jamf-Concepts/tap/jamformer

Voorgebouwde binaries en een .pkg-installer zijn beschikbaar op de releases-pagina.

U hoeft Terraform niet apart te installeren — jamformer downloadt het automatisch naar een tijdelijke directory, zodat het niet conflicteert met een bestaande Terraform-installatie op uw machine.

2. Voer het uit tegen uw instantie

De makkelijkste manier om te beginnen is jamformer zonder argumenten uitvoeren:

jamformer

Het leidt u interactief door alles — welke provider u wilt gebruiken, uw instantie-URL en uw credentials. U voert wachtwoorden en client secrets in als verborgen invoer zodat ze niet in uw terminal-history verschijnen.

Verkorte URL's werken hier ook — u kunt gewoon yourinstance typen en jamformer breidt het uit naar yourinstance.jamfcloud.com. Voor Protect breidt your-tenant uit naar your-tenant.protect.jamfcloud.com.

Zodra u vertrouwd bent met de tool of het wilt scripten, kunt u credentials instellen via omgevingsvariabelen:

# Jamf Pro met OAuth2
export JAMF_CLIENT_ID='your-client-id'
export JAMF_CLIENT_SECRET='your-client-secret'
jamformer -url https://yourinstance.jamfcloud.com

# Jamf Protect
export JAMF_CLIENT_ID='your-client-id'
export JAMF_CLIENT_SECRET='your-client-secret'
jamformer -provider jamfprotect -url https://your-tenant.protect.jamfcloud.com

jamformer leest credentials alleen van omgevingsvariabelen of interactieve prompts — nooit CLI-flags — om te voorkomen dat secrets lekken in shell-history en proceslijsten. U kunt de URL als flag (-url) of via JAMF_URL doorgeven.

jamformer schrijft geen credentials naar terraform.tfvars en genereert een .gitignore die tfvars-bestanden, state-bestanden en de .terraform/-directory uitsluit.

3. Alles in één keer importeren is optioneel

Als uw omgeving groot is en u liever klein begint, kunt u specifieke resourcetypes targeten:

# Begin met alleen policies, scripts en categorieën
./jamformer -include-resources "policies scripts categories"

# Alles behalve packages en icons
./jamformer -exclude-resources "packages icons"

# Bekijk alle beschikbare filternamen
./jamformer -list-resources

Wanneer een afhankelijkheidstype niet is opgenomen (zeg, u importeert policies maar geen categorieën), blijven referenties naar die types letterlijke ID's in plaats van Terraform-expressies. U kunt altijd later opnieuw uitvoeren met meer types naarmate u comfortabeler wordt.

Dus, hoe ziet de output er eigenlijk uit?

Nadat jamformer klaar is, heeft u een directory die er ongeveer zo uitziet:

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/     (leeg - plaats hier uw .p7m-bestanden)
    volume_purchasing_tokens/     (leeg - plaats hier uw .vpptoken-bestanden)
    app_configurations/
      managed_browser.xml

Elk resourcetype krijgt zijn eigen .tf-bestand en een bijbehorend _import.tf-bestand. De support_files/-directory bevat geëxtraheerde scripts, profielen en app-configuraties waarnaar verwezen wordt via file()-expressies. jamformer maakt token-directories (device_enrollment_tokens/ en volume_purchasing_tokens/) als de aanbevolen locatie voor uw Apple Business Manager-tokenbestanden — deze gebruiken file(var.xxx) pad-variabelen omdat de API geen tokendata retourneert.

Compacte modus

Standaard genereert jamformer één resource-blok per object — een platte, expliciete layout die makkelijk te lezen en te reviewen is. Maar als uw omgeving tientallen vergelijkbare resources heeft (categorieën, gebouwen, afdelingen), kan de output repetitief aanvoelen.

De -compact-flag consolideert in aanmerking komende resourcetypes in for_each + locals-patronen, wat output produceert die dichter bij wat u met de hand zou schrijven ligt:

jamformer -compact

Zonder compacte modus krijgt u individuele blokken:

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

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

Met compacte modus ingeschakeld worden deze:

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

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

jamformer herschrijft automatisch cross-resource-referenties om de nieuwe adressering te gebruiken — jamfpro_category.all["productivity"].id in plaats van jamfpro_category.productivity.id — zodat alles verbonden blijft. Het werkt import-blokken op dezelfde manier bij.

jamformer bepaalt geschiktheid dynamisch tijdens runtime. Een resourcetype komt in aanmerking wanneer het bestand twee of meer resource-blokken bevat die allemaal dezelfde set attributen delen en geen geneste blokken hebben (anders dan lifecycle). Attributen die identiek zijn over alle instanties worden letterlijke waarden op het resource-blok; alleen de waarden die variëren gaan in de locals-map. Dit werkt over alle vier de providers.

Als u fijnere controle wilt, kunt u specifieke types targeten:

# Alleen categorieën en gebouwen compact maken
jamformer -compact -compact-include "categories buildings"

# Alles compact maken dat in aanmerking komt behalve policies
jamformer -compact -compact-exclude "policies"

Multi-omgevingsondersteuning

Let op: Experimenteel en zeer geavanceerd. Deze functie is gericht op mensen die al vloeiend zijn in Terraform-modules, langlopende branch-workflows en het resource-model van de Jamf-provider. De output is meer scaffold-graad dan de single-environment-modus, niet minder — verwacht de gegenereerde module, de per-omgeving roots en de variabele-extractie te bewerken voordat iets ervan bruikbaar is. Behandel het als een research/enablement-functie, niet als een ondersteunde productie-workflow. Als u nieuw bent met Terraform of nog bezig bent uw eerste single-instance-project werkend te krijgen, begin daar en kom hier later op terug.

Als u meerdere Jamf Pro-omgevingen beheert — staging en productie, of dev en prod — heeft u waarschijnlijk nagedacht over hoe u ze gesynchroniseerd kunt houden. jamformer kan een Terraform-project genereren gestructureerd rond een gedeelde module met per-omgeving root-directories, ontworpen voor een Git-branching-workflow waar elke langlopende branch een omgeving vertegenwoordigt.

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 voert discovery onafhankelijk uit tegen elke omgeving, matcht resources op naam, en produceert output die er zo uitziet:

generated/
  modules/jamf/                # gedeelde resource-definities
    policies.tf                # resources aanwezig in alle omgevingen
    scripts.tf
    categories.tf
    policies_staging_only.tf   # resources alleen in staging
    variables.tf               # module input-variabelen
    providers.tf
    support_files/             # bestanden identiek over omgevingen
      scripts/
      macos_configuration_profiles/
  environments/
    staging/
      main.tf                  # provider-config + module-aanroep
      backend.tf               # placeholder voor uw state-backend
      variables.tf
      terraform.tfvars         # omgevingsspecifieke waarden
      imports.tf               # import-blokken met module.jamf. prefix
      support_files/           # bestanden die verschillen van de andere omgeving
    prod/
      main.tf
      backend.tf
      variables.tf
      terraform.tfvars
      imports.tf
      support_files/

De gedeelde module in modules/jamf/ bevat resource-definities gemeenschappelijk aan alle omgevingen. Waar attribuutwaarden verschillen over omgevingen — een beleid met een andere category_id of een profiel met een andere description — extraheert jamformer die waarden naar module-variabelen en stelt ze per omgeving in via terraform.tfvars. Cross-resource-referenties blijven als juiste Terraform-expressies (bijv. jamfpro_category.productivity.id), zodat de relaties tussen resources intact blijven.

Dit werkt het beste wanneer u bewust uw omgevingen gesynchroniseerd houdt — dezelfde policies, scripts, profielen en groepen uitgerold over instanties. Hoe meer ze overeenkomen, hoe schoner de output. Dat gezegd hebbende, handelt jamformer de gangbare real-world verschillen af:

• Dezelfde resource, andere instellingen (bijv. een beleid met een andere categorie of frequentie in staging vs prod) — de verschillende attributen worden module-variabelen, met de waarden van elke omgeving in zijn eigen terraform.tfvars. jamformer sorteert variabelen alfabetisch en groepeert ze per resourcetype voor leesbaarheid.
• Resources die in sommige omgevingen bestaan maar niet in andere (bijv. een testbeleid alleen in staging) — jamformer scheidt deze in duidelijk gelabelde bestanden zoals policies_staging_only.tf binnen de module. Op de branch voor een andere omgeving verwijdert u simpelweg die bestanden.
• Support-bestanden die verschillen (bijv. een script met iets andere inhoud over instanties) — bestanden identiek over alle omgevingen leven in de support_files/-directory van de gedeelde module. Wanneer bestanden verschillen, plaatst jamformer ze in de eigen support_files/-directory van elke omgeving en geeft ze door aan de module als variabelen.

Elke omgevingsdirectory heeft zijn eigen backend.tf-placeholder, zijn eigen state en zijn eigen import-blokken met prefix module.jamf.. Dit betekent dat u terraform plan en terraform apply onafhankelijk per omgeving kunt uitvoeren, parallel indien nodig, zonder risico dat de state van de ene omgeving interfereert met een andere.

jamformer gebruikt de eerst vermelde omgeving als bron van waarheid voor de gedeelde resource-definities; gebruik -source-env om dit te overschrijven. Het matcht resources op naam, dus een beleid genaamd "Software Update - Enforce" in staging zal matchen met een beleid met dezelfde naam in prod, ongeacht hun Jamf-ID's.

De bedoelde workflow is de output naar een repository te committen, een langlopende branch per omgeving te maken, de backend.tf van elke branch te configureren met de juiste state-backend, en CI in te stellen om terraform apply in de bijbehorende environments/<env>/-directory uit te voeren wanneer code op die branch land. Wijzigingen stromen van feature-branches naar de eerste omgeving, en promoveren vervolgens door branches via pull requests.

Hoe meer uw omgevingen divergeren, hoe meer variabelen en omgevingsspecifieke bestanden de output zal bevatten. Als uw instanties substantieel anders zijn, bent u misschien beter af met jamformer apart voor elk uit te voeren en onafhankelijke Terraform-projecten te onderhouden.

Werken met de gegenereerde output

We zeiden het aan het begin en we zeggen het hier opnieuw, omdat dit het deel is dat het meest telt: de gegenereerde configuratie is geen productie-klaar Terraform. jamformer is een enablement- en acceleratietool. Het geeft u een realistisch startpunt op de reis naar het beheren van uw Jamf-omgeving als code — geen shortcut die u er onmiddellijk brengt. Plan om echte tijd te besteden aan het reviewen, verfijnen en begrijpen van wat het geproduceerd heeft voordat iets echte infrastructuurwijzigingen aanstuurt.

De output is opzettelijk plat — één resource-blok per object, één bestand per type, geen modules. In de praktijk zult u het waarschijnlijk willen refactoren naar een modulaire projectstructuur, profiteren van HCL-features zoals for_each en locals om herhaling te verminderen, dingen zoals instantie-URL's en gemeenschappelijke instellingen in variabelen voor uw omgeving veranderen, en resources organiseren op een manier die zinvol is voor uw team. jamformer geeft u het ruwe materiaal om dat te doen; hoe u het vormt is aan u. Dat vormgevingswerk is waar het meeste Terraform-leren daadwerkelijk gebeurt — en het is de hele reden waarom jamformer bestaat in de vorm die het heeft.

Met dat in gedachten, hier is de workflow die we zouden aanraden.

Dezelfde commando's die u leerde in de introductie zijn hier van toepassing:

cd generated
terraform plan       # Review het importplan, check op provider-fouten

Verwacht diffs in uw eerste plan. Het is normaal om verschillen te zien tussen wat Terraform genereert en wat er daadwerkelijk in uw Jamf-instantie zit. Sommige attributen kunnen waarden tonen die niet overeenkomen met wat u in de console ziet, sommige optionele velden kunnen standaarden hebben die de provider invult die afwijken van de live-configuratie, en sommige resources kunnen validatiefouten hebben vanwege write-only-velden die de provider niet kan teruglezen. Dit zijn provider-niveau-eigenaardigheden, geen bugs in jamformer, en ze hebben handmatige aandacht nodig.

Werk door de plan-output, fix fouten en pas attributen aan totdat u tevreden bent met wat Terraform rapporteert. Dit reviewproces is waar u het meeste leert over hoe de provider uw resources representeert — en het is een belangrijke stap voordat u controle overdraagt aan Terraform.

Zodra het plan er schoon uitziet:

terraform apply      # Importeer resources in state (u wordt gevraagd te bevestigen)

Het uitvoeren van terraform apply hier importeert uw bestaande resources in Terraform-state. Het wijzigt niets in Jamf — het vertelt Terraform alleen "deze resources bestaan al en hier is hoe ze eruitzien."

Zodra u succesvol heeft toegepast, hebben de import-blokken hun werk gedaan. U kunt ze verwijderen:

rm *_import.tf

Voer dan terraform plan opnieuw uit. Idealiter ziet u geen wijzigingen. Als er verschillen verschijnen, zijn dit gevallen waar de standaarden van de provider niet helemaal overeenkomen met wat er daadwerkelijk in Jamf zit — pas de gegenereerde HCL aan totdat u een schoon plan krijgt.

Op dit punt heeft u een Terraform-project dat uw Jamf-omgeving representeert. Commit het naar Git en u bent klaar om het echte werk te beginnen: de configuratie verfijnen, het organiseren op een manier die past bij de workflow van uw team, en geleidelijk overgaan naar het maken van wijzigingen via pull requests, code review en terraform apply in plaats van de console.

Dingen om in gedachten te houden

Standaard downloadt jamformer packages van het Cloud Distribution Point. Voor grote omgevingen met veel packages kan dit even duren. Gebruik -skip-package-downloads om deze stap over te slaan en packages apart af te handelen.

Secret scanning draait automatisch na generatie. Als u liever zelf secret management afhandelt of in een headless omgeving draait, gebruik -skip-secret-scan om het over te slaan. Zelfs als u de ingebouwde scan overslaat, raden we sterk aan een vorm van secret-detectie uit te voeren voordat u de output naar Git commit.

Compacte modus (-compact) is puur cosmetisch — het verandert de vorm van de HCL maar niet wat Terraform doet. Als u niet zeker weet of u het wilt, begin zonder en probeer het op een tweede run. U kunt ook -compact-include en -compact-exclude gebruiken om specifieke resourcetypes te targeten terwijl u andere plat laat.

De gegenereerde provider.tf bevat een minimale versieconstraint (>= X.Y.Z) gebaseerd op de providerversie die Terraform downloadde. Als u liever een exacte versie vastpint, gebruik -provider-version 1.2.3.

Jamf Protect en Jamf Platform vereisen Terraform 1.14+ voor terraform query-ondersteuning. jamformer downloadt dit automatisch, maar het is goed om te weten als u uw eigen Terraform-binary levert via -terraform-path.

Wat nu

Als u deze serie heeft gevolgd, heeft u nu gezien hoe u Terraform voor Jamf vanaf nul schrijft, hoe u Jamf Protect en Jamf Platform-configuratie als code beheert met een specifieke provider, en nu hoe u een bestaande omgeving onder Terraform-beheer brengt zonder opnieuw te beginnen. Er komt meer — we zullen aanvullende onderwerpen behandelen in toekomstige berichten naarmate de providers en tooling blijven evolueren.

We werken actief aan jamformer en verzamelen feedback. Als u het uitprobeert, horen we graag wat werkt en wat niet. Open een issue op de GitHub-repository of neem contact op via Jamf Nation.

Referenties

• jamformer op GitHub
• Managing Jamf Configuration with Terraform: An Introduction
• Managing Jamf Protect with Terraform: The Jamf Protect Provider
• Managing the Jamf Platform with Terraform: The Jamf Platform Provider
• Deployment Theory Jamf Pro Provider
• Jamf Protect Provider
• Jamf Platform Provider
• Jamf Security Cloud Provider
• Terraform Documentation