Bicep-code publiceren vanuit een implementatiepijplijn

5 minuten

Wanneer u het publicatieproces voor een sjabloonspecificatie of een Bicep-module automatiseert, moet u ervoor zorgen dat alles wat u normaal gesproken handmatig doet, automatisch kan worden geautomatiseerd en uitgevoerd in de pijplijn. In deze les past u principes toe die u eerder hebt geleerd om sjabloonspecificaties en Bicep-modules te publiceren vanuit een implementatiepijplijn.

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 pijplijn

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 vervolgens de resources geïmplementeerd die u hebt gedefinieerd. Daarom kunnen de manieren waarop u uw sjabloonspecificaties en Bicep-modules valideert en test, verschillen 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 typen tests uit een implementatiepijplijn uit te voeren 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 beslissen of u pijplijnstappen wilt opnemen die uw sjabloonspecificaties en -modules implementeren en testen. In deze Microsoft Learn-module 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 wilt gebruiken om de resources te implementeren.

Tip

U wordt aangeraden uw Bicep-code testen met behulp van Azure Pipelines te bekijken voor meer informatie over het testen van uw Bicep-bestanden in een geautomatiseerde pijplijn.

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 implementatiepijplijn werkt, zijn dezelfde principes van toepassing. Omdat u echter niet de persoon bent die de implementatie uitvoert, moet u ervoor zorgen dat de service-principal van uw pijplijn 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 service-principal die de implementatie uitvoert waarschijnlijk niet veel machtigingen nodig. Wanneer uw register gebruikmaakt van Microsoft Entra-autorisatie, heeft de service-principal alleen de AcrPush-machtiging voor het register nodig.

Overweeg het beveiligingsprincipe van minimale bevoegdheden te gebruiken. Geef de service-principal van de pijplijn alleen toegang tot het containerregister en niet tot een resourcegroep of abonnement.

Sjabloonspecificaties en modules publiceren vanuit een pijplijn

Wanneer u een sjabloonspecificatie publiceert vanaf uw eigen computer met behulp van de Azure CLI, gebruikt u een opdracht zoals de volgende:

az ts create \
  --name StorageWithoutSAS \
  --resource-group MyResourceGroup \
  --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 pijplijnstap:

- task: AzureCLI@2
  name: Publish
  displayName: Publish template spec
  inputs:
    azureSubscription: $(ServiceConnectionName)
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az ts create \
        --name StorageWithoutSAS \
        --resource-group MyResourceGroup \
        --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 pijplijn gebruikt hetzelfde proces om de sjabloonspecificatie te publiceren die u zelf zou gebruiken.

Op dezelfde manier gebruikt u, wanneer u een Bicep-module publiceert vanaf uw eigen computer met behulp van de Azure CLI, een opdracht zoals de volgende:

az bicep publish \
   --file module.bicep \
   --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

U kunt deze Azure CLI-opdracht ook converteren naar een pijplijnstap:

- task: AzureCLI@2
  name: Publish
  displayName: Publish Bicep module
  inputs:
    azureSubscription: $(ServiceConnectionName)
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    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 pijplijnstap. Dit is geen goede gewoonte. U kunt omgevingsvariabelen gebruiken om configuratie-instellingen als deze in te stellen. Verderop in deze Microsoft Learn-module ziet u hoe dit werkt.

Het publiceren van een sjabloonspecificatie vanuit een pijplijn wordt beschreven in deze eenheid.

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 implementatiepijplijn publiceert, gebruikt en implementeert u deze op dezelfde manier.