Bicep-code publiceren vanuit een implementatiewerkstroom
Wanneer u het publicatieproces voor een sjabloonspecificatie of een Bicep-module automatiseert, moet u ervoor zorgen dat alles wat u normaal gesproken zelf zou doen, kan worden geautomatiseerd en uitgevoerd binnen de werkstroom. In deze les leert u hoe u enkele principes toepast die u eerder hebt geleerd wanneer u sjabloonspecificaties en Bicep-modules publiceert vanuit een implementatiewerkstroom.
Sjabloonspecificaties en modules
Bicep stelt u in staat om uw code eenvoudig opnieuw te gebruiken. Twee algemene benaderingen voor het hergebruik van uw Bicep-code in verschillende implementaties zijn:
- Sjabloonspecificaties, die zijn geoptimaliseerd voor de implementatie van volledige oplossingen. Stel dat u een set beveiligingsharde resources hebt gedefinieerd om een volledige virtuele machine te implementeren volgens de specificaties van uw bedrijf. U kunt deze code publiceren als sjabloonspecificatie. Uw collega's kunnen vervolgens uw sjabloonspecificatie gebruiken om een volledige virtuele machine te implementeren, zelfs vanuit Azure Portal.
- Modules, die zijn ontworpen om onderdelen van andere implementaties te zijn. Stel dat u een Bicep-bestand hebt gemaakt waarmee een opslagaccount wordt gemaakt. U hebt waarschijnlijk opslagaccounts nodig in veel andere implementaties, dus u kunt het Bicep-bestand publiceren naar een register en dit gebruiken als een module in de implementaties van uw organisatie.
Wanneer u besluit tussen sjabloonspecificaties en Bicep-modules, is een goede vuistregel: als de sjabloon wordt geïmplementeerd zoals in uw organisatie, zijn sjabloonspecificaties waarschijnlijk geschikt. Maar als u deze sjabloon waarschijnlijk opnieuw wilt gebruiken binnen meerdere bovenliggende sjablonen, kunnen Bicep-modules uw behoeften verbeteren.
Herbruikbare code valideren in een werkstroom
In tegenstelling tot reguliere Bicep-implementaties, implementeert u de resources niet rechtstreeks in Azure wanneer u een sjabloonspecificatie of een module maakt. In plaats daarvan publiceert u de sjabloonspecificatie of -module. Vervolgens kunt u de sjabloonspecificatie of -module in een andere implementatie gebruiken. Met deze implementatie worden de resources geïmplementeerd die u hebt gedefinieerd. Vanwege dit verschil kunnen de manieren waarop u uw sjabloonspecificaties en Bicep-modules valideert en test, afwijken van het proces dat u gebruikt voor reguliere Bicep-implementaties.
Het is raadzaam om uw Bicep-code te linten. De linter detecteert syntactische problemen en waarschuwt u als u de aanbevolen procedures niet volgt.
Naast linting kunt u overwegen om uw sjabloonspecificaties en modules te testen met behulp van preflight-validatie. U kunt zelfs overwegen om uw sjabloonspecificaties en -modules te implementeren in Azure en te testen of de resources die ze maken zich gedragen zoals verwacht. Het kan echter lastig zijn om deze soorten tests uit te voeren vanuit een implementatiewerkstroom om twee redenen:
- Voor voorbereidende validatie en implementaties is een Azure-omgeving vereist om de resources te implementeren. Mogelijk moet u een toegewezen Azure-abonnement of resourcegroep onderhouden voor het implementeren en testen van uw modules.
- Voor veel sjabloonspecificaties en modules moet u een set parameters opgeven. Mogelijk moet u een testset parameters maken voor uw sjabloonspecificaties of modules die moeten worden gebruikt wanneer ze worden geïmplementeerd.
U moet kiezen of u werkstroomstappen wilt opnemen die uw sjabloonspecificaties en -modules implementeren en testen. In deze Microsoft Learn-trainingsmodule linten we de Bicep-code, maar bevatten we geen andere vormen van testen. Als u de sjabloonspecificaties en -modules wilt testen, kunt u overwegen hoe u deze implementeert in Azure. Overweeg ook of u toegewezen abonnementen of resourcegroepen gebruikt om de resources te implementeren.
Tip
We raden u aan uw Bicep-code testen te bekijken met behulp van GitHub Actions voor meer informatie over het testen van uw Bicep-bestanden in een geautomatiseerde werkstroom.
Verificatie en autorisatie
Wanneer u zelf sjabloonspecificaties naar Azure publiceert, moet uw Microsoft Entra-gebruiker toegang krijgen tot de resourcegroep die de sjabloonspecificatieresource bevat. Wanneer u een Bicep-module naar een register publiceert, moet uw Microsoft Entra-gebruiker ook gemachtigd zijn om te schrijven naar het Azure Container Registry-exemplaar dat uw organisatie gebruikt voor de Bicep-modules.
Wanneer u met een geautomatiseerde implementatiewerkstroom werkt, zijn dezelfde principes van toepassing. Omdat u echter niet de persoon bent die de implementatie uitvoert, moet u ervoor zorgen dat de identiteit van uw werkstroom de juiste toegang krijgt tot de resourcegroep voor het publiceren van de sjabloonspecificatie of in het containerregister voor het publiceren van modules.
Tip
Wanneer u een module naar een register publiceert, heeft de workload-id voor het uitvoeren van de implementatie waarschijnlijk niet veel machtigingen nodig. Wanneer uw register gebruikmaakt van Microsoft Entra-autorisatie, heeft de workloadidentiteit alleen de AcrPush-machtiging voor het register nodig.
Overweeg het beveiligingsprincipe van minimale bevoegdheden te gebruiken. Geef de identiteit van de werkstroom alleen toegang tot het containerregister en niet tot een resourcegroep of abonnement.
Sjabloonspecificaties en -modules publiceren vanuit een werkstroom
Wanneer u een sjabloonspecificatie publiceert vanaf uw eigen computer met behulp van de Azure CLI, gebruikt u een opdracht als volgt:
az ts create \
--name StorageWithoutSAS \
--location westus3 \
--display-name "Storage account with SAS disabled" \
--description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
--version 1 \
--template-file main.bicep
U kunt deze Azure CLI-opdracht converteren naar een GitHub Actions-stap:
- name: Publish template spec
uses: azure/cli@v1
with:
inlineScript: |
az ts create \
--name StorageWithoutSAS \
--location westus3 \
--display-name "Storage account with SAS disabled" \
--description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
--version 1 \
--template-file main.bicep
De werkstroom gebruikt hetzelfde proces om de sjabloonspecificatie te publiceren die u zelf zou gebruiken.
Op dezelfde manier gebruikt u een opdracht als volgt wanneer u een Bicep-module publiceert vanaf uw eigen computer met behulp van de Azure CLI:
az bicep publish \
--file module.bicep \
--target 'br:toycompany.azurecr.io/mymodules/myqueue:2'
U kunt deze Azure CLI-opdracht ook converteren naar een GitHub Actions-stap:
- name: Publish Bicep module
uses: azure/cli@v1
with:
inlineScript: |
az bicep publish \
--file module.bicep \
--target 'br:toycompany.azurecr.io/mymodules/myqueue:2'
Tip
In dit voorbeeld wordt de hostnaam (toycompany.azurecr.io) van het Bicep-register ingesloten in de definitie van de werkstroomstap. Dit is geen goede gewoonte. U kunt omgevingsvariabelen gebruiken om configuratie-instellingen als deze in te stellen. Verderop in deze Microsoft Learn-trainingsmodule ziet u hoe dit werkt.
Binnenkort ziet u hoe u een sjabloonspecificatie vanuit een werkstroom kunt publiceren met behulp van de stappen die in deze les worden beschreven.
Een module- of sjabloonspecificatie gebruiken
In eerdere Microsoft Learn-trainingsmodules hebt u geleerd hoe u de resources implementeert die zijn gedefinieerd in sjabloonspecificaties en hoe u Bicep-modules gebruikt die zijn opgeslagen in registers. Ongeacht of u de sjabloonspecificaties en modules handmatig of vanuit een implementatiewerkstroom publiceert, kunt u deze op dezelfde manier gebruiken en implementeren.
U implementeert bijvoorbeeld een sjabloonspecificatie of Bicep-bestand in een resourcegroep met behulp van de az deployment group create Azure CLI-opdracht of de New-AzResourceGroupDeployment cmdlet met Azure PowerShell.