Bicep-modules maken en gebruiken

Voltooid

Modules zijn onafhankelijke Bicep-bestanden. Ze bevatten doorgaans sets resources die samen worden geïmplementeerd. Modules kunnen worden gebruikt vanuit elke andere Bicep-sjabloon.

Door modules te gebruiken, kunt u uw Bicep-code opnieuw gebruiken en kunt u uw Bicep-bestanden leesbaarder en begrijpelijker maken omdat ze elk zijn gericht op een specifieke taak. Uw belangrijkste sjablonen stellen vervolgens meerdere modules samen.

De voordelen van modules

In uw speelgoedbedrijf hebt u cloudresources ingericht met behulp van veel afzonderlijke Bicep-bestanden. Na verloop van tijd groeien deze sjablonen aanzienlijk. Uiteindelijk hebt u monolithische code die moeilijk te lezen en te navigeren is, en nog moeilijker te onderhouden.

Deze aanpak dwingt u ook af om delen van uw code te dupliceren wanneer u deze opnieuw wilt gebruiken in andere sjablonen. Wanneer u iets wijzigt, moet u meerdere bestanden doorzoeken en bijwerken.

Bicep-modules helpen u deze uitdagingen aan te pakken door uw code op te splitsen in kleinere, beter beheerbare bestanden waarnaar meerdere sjablonen kunnen verwijzen. Modules bieden u enkele belangrijke voordelen.

Herbruikbaarheid

Nadat u een module hebt gemaakt, kunt u deze opnieuw gebruiken in meerdere Bicep-bestanden, zelfs als de bestanden voor verschillende projecten of werkbelastingen zijn. Wanneer u bijvoorbeeld één oplossing bouwt, kunt u afzonderlijke modules maken voor de app-onderdelen, de database en de netwerkgerelateerde resources. Wanneer u vervolgens aan een ander project gaat werken met vergelijkbare netwerkvereisten, kunt u de relevante module opnieuw gebruiken.

U kunt zelfs modules binnen uw team, binnen uw organisatie of met de Azure-community delen. U leert meer over het delen van Bicep-modules in een toekomstige Microsoft Learn-module.

Inkapseling

Met modules kunt u gerelateerde resourcedefinities bijeenhouden. Wanneer u bijvoorbeeld een Azure Functions-app definieert, implementeert u doorgaans de app, een hostingabonnement voor de app en een opslagaccount voor de metagegevens van de app. Deze drie onderdelen worden afzonderlijk gedefinieerd, maar ze vertegenwoordigen een logische groepering van resources, dus het kan zinvol zijn om ze te definiëren als een module.

Op die manier hoeft uw hoofdsjabloon niet op de hoogte te zijn van de details van hoe een functie-app wordt geïmplementeerd. Dat is de verantwoordelijkheid van de module.

Modulariteit

Nadat u een set modules hebt gemaakt, kunt u deze samen samenstellen. U kunt bijvoorbeeld een module maken waarmee een virtueel netwerk wordt geïmplementeerd en een andere module waarmee een virtuele machine wordt geïmplementeerd. U definieert parameters en uitvoer voor elke module, zodat u de belangrijke informatie van de ene naar de andere kunt verzenden.

Tip

Het is handig om Bicep-modules te beschouwen als bouwstenen die u op verschillende manieren kunt combineren om uw implementaties te ondersteunen.

Functionaliteit

Soms moet u mogelijk modules gebruiken om toegang te krijgen tot bepaalde functionaliteit. U kunt bijvoorbeeld modules en lussen samen gebruiken om meerdere sets resources te implementeren. U kunt modules ook gebruiken om resources op verschillende bereiken in één implementatie te definiëren.

Een module maken

Een module is een normaal Bicep-bestand. U maakt het net als elk ander Bicep-bestand.

Over het algemeen is het geen goede gewoonte om een module te maken voor elke resource die u implementeert. Een goede Bicep-module definieert doorgaans meerdere gerelateerde resources. Als u echter een complexe resource met veel configuratie hebt, kan het zinvol zijn om één module te maken om de complexiteit in te kapselen. Met deze aanpak blijven uw belangrijkste sjablonen eenvoudig en overzichtelijk.

Een bestaande Bicep-sjabloon splitsen in modules

U kunt een grote Bicep-sjabloon samenstellen en vervolgens besluiten dat deze moet worden gesplitst in modules. Soms is het duidelijk hoe u een groot Bicep-bestand moet splitsen. Mogelijk hebt u een set resources die duidelijk bij elkaar horen in een module. In andere gevallen is het niet zo eenvoudig om de resources te bepalen die in een module moeten worden gegroepeerd.

De Bicep-visualisatie kan u helpen uw hele Bicep-bestand in perspectief te plaatsen. De visualizer is opgenomen in de Bicep-extensie voor Visual Studio Code.

Als u de visual wilt weergeven, opent u Visual Studio Code Explorer, selecteert en houdt u het Bicep-bestand ingedrukt (of klikt u erop met de rechtermuisknop) en selecteert u Bicep Visualizer openen. De visualizer toont een grafische weergave van de resources in uw Bicep-bestand. Het bevat regels tussen resources om de afhankelijkheden weer te geven die Bicep detecteert.

U kunt de visualizer gebruiken om uw bestanden op te splitsen. Kijk of de visualisatie clusters met resources illustreert. Het kan zinvol zijn om deze clusters samen naar een module te verplaatsen.

Denk bijvoorbeeld aan de volgende visualisatie voor een Bicep-bestand. Er worden twee afzonderlijke sets resources gedefinieerd. Het kan zinvol zijn om ze te groeperen in afzonderlijke database- en netwerkmodules.

Visualizer

Groepering

Nest-modules

Modules kunnen andere modules bevatten. Met behulp van deze nesttechniek kunt u enkele modules maken die kleine sets resources implementeren en deze vervolgens samenstellen in grotere modules die complexe topologieën van resources definiëren. Een sjabloon combineert deze onderdelen in een implementeerbaar artefact.

Tip

Hoewel het mogelijk is om meerdere lagen modules te nesten, kan dat complex worden. Als er een fout optreedt of als er iets anders misgaat, is het moeilijker om te bepalen wat u moet oplossen wanneer u veel nestlagen hebt.

Voor complexe implementaties is het soms zinvol om implementatiepijplijnen te gebruiken om meerdere sjablonen te implementeren in plaats van één sjabloon te maken die alles doet met nesten. Meer informatie over implementatiepijplijnen vindt u in een toekomstige Microsoft Learn-module.

Goede bestandsnamen kiezen

Zorg ervoor dat u voor elke module een beschrijvende bestandsnaam gebruikt. De bestandsnaam wordt in feite de id voor de module. Het is belangrijk dat uw collega's het doel van de module begrijpen door alleen de bestandsnaam te bekijken.

De module gebruiken in een Bicep-sjabloon

U gebruikt een module in een Bicep-sjabloon met behulp van het module trefwoord, zoals hieronder:

module appModule 'modules/app.bicep' = {
  name: 'myApp'
  params: {
    location: location
    appServiceAppName: appServiceAppName
    environmentType: environmentType
  }
}

Een moduledefinitie bevat de volgende onderdelen:

• Het trefwoord module.
• Een symbolische naam, zoals appModule. Deze naam wordt gebruikt in dit Bicep-bestand wanneer u naar de module wilt verwijzen. De symbolische naam wordt nooit weergegeven in Azure.
• Het modulepad, zoals modules/app.bicep. Dit is doorgaans het pad naar een Bicep-bestand op uw lokale bestandssysteem. In een toekomstige Microsoft Learn-module leert u hoe u modules kunt delen met behulp van registers en sjabloonspecificaties, die hun eigen modulepadindelingen hebben.

  Tip

  U kunt ook een JSON Azure Resource Manager-sjabloon (ARM-sjabloon) als module gebruiken. Deze mogelijkheid kan handig zijn als u een set sjablonen hebt die u nog niet hebt gemigreerd naar Bicep.

• De name eigenschap, waarmee de naam van de implementatie wordt opgegeven. In de volgende sectie vindt u meer informatie over implementaties.
• De params eigenschap, waar u waarden kunt opgeven voor de parameters die door de module worden verwacht. In de volgende les vindt u meer informatie over moduleparameters.

Hoe modules werken

Begrijpen hoe modules werken, is niet nodig om ze te gebruiken, maar het kan u helpen bij het onderzoeken van problemen met uw implementaties of het uitleggen van onverwacht gedrag.

Installaties

In Azure is een implementatie een speciale resource die een implementatiebewerking vertegenwoordigt. Implementaties zijn Azure-resources met het resourcetype Microsoft.Resources/deployments. Wanneer u een Bicep-implementatie verzendt, maakt of werkt u een implementatieresource bij. Op dezelfde manier maakt de portal namens u een implementatieresource wanneer u resources maakt in Azure Portal.

Niet alle wijzigingen in Azure-resources maken of gebruiken echter implementaties. Wanneer u bijvoorbeeld Azure Portal gebruikt om een bestaande resource te wijzigen, wordt er meestal geen implementatie gemaakt om de wijziging aan te brengen. Wanneer u hulpprogramma's van derden zoals Terraform gebruikt om uw resources te implementeren of te configureren, worden er mogelijk geen implementaties gemaakt.

Wanneer u een Bicep-bestand implementeert met behulp van de Azure CLI of Azure PowerShell, kunt u desgewenst de naam van de implementatie opgeven. Als u geen naam opgeeft, maakt de Azure CLI of Azure PowerShell automatisch een implementatienaam voor u op basis van de bestandsnaam van de sjabloon. Als u bijvoorbeeld een bestand met de naam main.bicep implementeert, is mainde standaardimplementatienaam.

Wanneer u modules gebruikt, maakt Bicep een afzonderlijke implementatie voor elke module. De name eigenschap die u voor de module opgeeft, wordt de naam van de implementatie. Wanneer u een Bicep-bestand implementeert dat een module bevat, worden er meerdere implementatiebronnen gemaakt: één voor de bovenliggende sjabloon en één voor elke module.

Stel dat u een Bicep-bestand met de naam main.bicep maakt. Hiermee definieert u een module met de naam myApp. Wanneer u het bestand main.bicep implementeert, worden er twee implementaties gemaakt. De eerste heet mainen er wordt een andere implementatie gemaakt met de naam myApp die uw toepassingsbronnen bevat.

U kunt de details van implementatiebronnen weergeven en weergeven om de status van uw Bicep-implementaties te controleren of om de geschiedenis van implementaties weer te geven. Wanneer u echter dezelfde naam voor een implementatie opnieuw gebruikt, overschrijft Azure de laatste implementatie met dezelfde naam. Als u de implementatiegeschiedenis wilt onderhouden, moet u ervoor zorgen dat u voor elke implementatie een unieke naam gebruikt. U kunt de datum en tijd van de implementatie opnemen in de naam om deze uniek te maken.

Gegenereerde JSON ARM-sjablonen

Wanneer u een Bicep-bestand implementeert, converteert Bicep het naar een JSON ARM-sjabloon. Deze conversie wordt ook wel transpilatie genoemd. De modules die door de sjabloon worden gebruikt, worden ingesloten in het JSON-bestand. Ongeacht het aantal modules dat u in uw sjabloon opneemt, wordt er slechts één JSON-bestand gemaakt.

In het voorbeeld dat in de vorige sectie is besproken, genereert Bicep één JSON-bestand, ook al waren er oorspronkelijk twee Bicep-bestanden.