Een sjabloonspecificatie beheren

  • 4 minuten

Sjabloonspecificaties bieden een handige manier om sjablonen binnen uw organisatie te publiceren en te delen. Naarmate u meer sjabloonspecificaties gebruikt, wordt het belangrijk om te begrijpen hoe u ze beheert.

In deze les leert u meer over versiebeheer, het wijzigen en verwijderen van sjabloonspecificaties en het beheren van de toegang tot sjabloonspecificaties.

Notitie

De opdrachten in deze les worden weergegeven om concepten te illustreren. Voer de opdrachten nog niet uit. U oefent wat u hier binnenkort leert.

Versies toevoegen

U hebt geleerd dat één sjabloonspecificatie meerdere versies kan hebben. Een sjabloonspecificatie fungeert als een container voor een of meer versies en elke versie is gekoppeld aan een sjabloonbestand. Wanneer u een sjabloonspecificatie implementeert, moet u de versie opgeven die u wilt gebruiken, zodat Azure Resource Manager weet welk sjabloonbestand moet worden opgehaald.

Met de Azure CLI en Azure PowerShell kunt u eenvoudig met meerdere versies werken. In feite hebt u al met versies gewerkt toen u de sjabloonspecificatie in de vorige oefening hebt geïmplementeerd.

Het is een goed idee om zorgvuldig te plannen hoe u de sjabloonspecificaties gaat versien. Twee belangrijke beslissingen zijn het versiebeheerschema en het versiebeheerbeleid dat moet worden gebruikt.

Versiebeheerschema's

Uw versiebeheerschema bepaalt hoe u versienummers genereert. Veelvoorkomende versiebeheerschema's zijn:

  • Basis gehele getallen kunnen worden gebruikt als versienummers. Uw eerste versie kan bijvoorbeeld worden aangeroepen 1, uw tweede versie 2, enzovoort.
  • Datums maken ook goede versienummers. Als u bijvoorbeeld de eerste versie van de sjabloonspecificatie publiceert op 16 januari 2021, kunt u de versie 2021-01-16 een naam geven (met de notatie jjjj-mm-dd ). Wanneer u een andere versie publiceert op 3 maart, kunt u deze 2021-03-03een naam opgeven.
  • Semantische versiebeheer is een versiebeheersysteem dat vaak wordt gebruikt in software, waarbij één versienummer meerdere onderdelen bevat. Elk onderdeel geeft verschillende informatie over de aard van de wijziging aan.

Hoewel u elk versiebeheerschema kunt gebruiken dat u bevalt, is het een goed idee om iets te kiezen dat kan worden gesorteerd in een zinvolle volgorde, zoals getallen en datums.

Notitie

Azure slaat de datum op waarop elke versie wordt gemaakt. Zelfs als u geen versiebeheer op basis van datums gebruikt, kunt u deze informatie nog steeds zien.

Versiebeheerbeleid

Sjabloonspecificaties bieden u de flexibiliteit om te kiezen wanneer u nieuwe versies maakt of een bestaande versie wilt bijwerken. U kunt zich bijvoorbeeld effectief afmelden voor versiebeheer door één versie met de naam latestte maken en te publiceren. Wanneer u de sjabloonspecificatie moet wijzigen, werkt u die versie gewoon bij. Hoewel dit beleid werkt, is het geen goede gewoonte.

Als u daarentegen een kleine wijziging aanbrengt in een bestaande sjabloon die geen invloed heeft op het gebruik ervan, is het maken van een nieuwe versie waarschijnlijk geen goed idee. U moet het nieuwe versienummer doorgeven aan iedereen die de sjabloonspecificatie gebruikt.

Hier volgt een versiebeheerbeleid dat vaak goed werkt:

  • Wanneer u belangrijke wijzigingen aanbrengt in een sjabloonspecificatie, maakt u een nieuwe versie. Belangrijke wijzigingen in de sjabloonspecificatie bevatten alles wat een verschil kan maken voor de gebruiker die deze implementeert. Voorbeelden zijn het toevoegen van een andere resource aan de sjabloon of het wijzigen van de eigenschappen van een resource.
  • Wanneer u kleine wijzigingen aanbrengt in een sjabloonspecificatie, die soms een hotfix wordt genoemd, werkt u de bestaande versie van de sjabloonspecificatie bij.
  • Verwijder oude versies wanneer ze niet meer relevant zijn of wanneer u niet wilt dat iemand ze gebruikt.

Tip

Houd rekening met de gebruikers van de sjabloonspecificatie en zorg ervoor dat u nadenkt over wat ze verwachten. Als een gebruiker uw sjabloonspecificatie meerdere keren implementeert en één resultaat krijgt en deze vervolgens opnieuw implementeert na een hotfix en een ander resultaat krijgt, zullen ze waarschijnlijk verrast zijn. Probeer de kans te minimaliseren dat uw gebruikers een resultaat krijgen dat ze niet verwachten.

Versiebeschrijvingen

Wanneer u een nieuwe versie van een sjabloonspecificatie maakt, kunt u deze desgewenst een versiebeschrijving geven. Het opgeven van een versiebeschrijving is een goede gewoonte, zelfs als dit niet vereist is. De versiebeschrijving bevat een overzicht van de wijzigingen die u hebt aangebracht, zodat iedereen die uw sjabloonspecificatie gebruikt, kan helpen de versie te selecteren die het beste bij hun behoeften past.

Wijzigingen aanbrengen in een sjabloonspecificatie

Sjabloonspecificaties zijn Azure-resources, zodat u ze kunt beheren zoals elke andere resource. Dit betekent dat u de details van een sjabloonspecificatie kunt bekijken, bijwerken en verwijderen, net zoals normaal.

Als u bijvoorbeeld de versies van een sjabloonspecificatie wilt weergeven, gebruikt u de Get-AzTemplateSpec cmdlet:

Get-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec

Dezelfde cmdlet wordt gebruikt om een sjabloonspecificatieversie weer te geven. Voeg de -Version parameter toe om de details van een versie op te halen:

Get-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0

U kunt de JSON-sjabloon openen door de MainTemplate eigenschap te lezen vanuit de Versions matrix:

(Get-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0 `
).Versions[0].MainTemplate

Als u bijvoorbeeld de versies van een sjabloonspecificatie wilt weergeven, gebruikt u de az ts show opdracht:

az ts show \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec

Dezelfde opdracht wordt gebruikt om een sjabloonspecificatieversie weer te geven. Voeg het --version argument toe om de details van een versie op te halen:

az ts show \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0

De JSON-sjabloon is opgenomen in de uitvoer.

Notitie

Wanneer u een Bicep-bestand publiceert naar een sjabloonspecificatie, wordt het geconverteerd naar JSON. U kunt het oorspronkelijke Bicep-bestand niet zien, dus het is een goed idee om dat ergens anders te bewaren.

Als u een bestaande sjabloonspecificatie wilt bijwerken, gebruikt u de Set-AzTemplateSpec cmdlet. U kunt deze cmdlet bijvoorbeeld gebruiken om een hotfix toe te passen op een versie die u al hebt gepubliceerd:

Set-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0 `
  -TemplateFile azuredeploy.json

En u kunt een sjabloonspecificatieversie verwijderen met behulp van de Remove-AzTemplateSpec cmdlet:

Remove-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0

Als u een bestaande sjabloonspecificatie wilt bijwerken, gebruikt u de az ts update opdracht. U kunt deze opdracht bijvoorbeeld gebruiken om een hotfix toe te passen op een versie die u al hebt gepubliceerd:

az ts update \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0 \
  --template-file azuredeploy.json

En u kunt een sjabloonspecificatieversie verwijderen met behulp van de az ts delete opdracht:

az ts delete \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0

Een sjabloonspecificatie exporteren

Nadat u een sjabloon hebt gepubliceerd als sjabloonspecificatie, kunt u deze exporteren . Als u een sjabloonspecificatie exporteert, wordt het sjabloonbestand gedownload naar uw lokale computer. Daar kunt u het sjabloonbestand bewerken of gewoon inspecteren, zodat u begrijpt wat het doet.

Tip

Als uw sjabloonspecificatie gekoppelde sjablonen bevat, downloadt het exporteren van een sjabloonspecificatie ook de gekoppelde sjablonen. De mapstructuur blijft zelfs behouden.

Belangrijk

Wanneer u een Bicep-bestand publiceert als sjabloonspecificatie, wordt uw Bicep-code geconverteerd naar een JSON-sjabloon. Tijdens het converteren van uw Bicep-code naar JSON worden enkele gegevens in uw Bicep-bestand verwijderd. Uw opmerkingen, symbolische namen voor resources en de volgorde waarin u uw resources definieert, ontbreken of verschillen in JSON. Dit betekent dat u een Bicep-bestand niet eenvoudig kunt publiceren als sjabloonspecificatie en vervolgens het oorspronkelijke Bicep-bestand terug kunt krijgen (ook wel roundtripping genoemd). Het is een goed idee om een kopie van uw oorspronkelijke Bicep-code te bewaren in een codeopslagplaats zoals Git, vooral wanneer u met sjabloonspecificaties werkt.

Als u een sjabloonspecificatie wilt exporteren, gebruikt u de Export-AzTemplateSpec cmdlet. Gebruik de -OutputFolder waarde om op te geven waar u de sjabloonbestanden wilt opslaan:

Export-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0 `
  -OutputFolder ./mytemplate

Als u een sjabloonspecificatie wilt exporteren, gebruikt u de az ts export opdracht. Gebruik de --output-folder waarde om op te geven waar u de sjabloonbestanden wilt opslaan:

az ts export \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0 \
  --output-folder ./mytemplate

Toegang tot een sjabloonspecificatie beheren

Omdat sjabloonspecificaties Azure-resources zijn, gebruiken ze het identiteits- en toegangsbeheer van Azure (IAM). Wanneer een gebruiker een sjabloonspecificatie implementeert, controleert Azure of de gebruiker eerst toegang heeft om de sjabloonspecificatie te lezen.

Notitie

Een gebruiker heeft het volgende nodig om een sjabloonspecificatie te implementeren:

  • Toegang om de sjabloonspecificatie te lezen.
  • Toegang om te implementeren in de resourcegroep of een ander bereik waarnaar ze vragen om te implementeren.

Azure controleert beide voorwaarden voordat de implementatie wordt gestart.