Gerelateerde resources groeperen met behulp van modules

  • 6 minuten

U bent begonnen met het gebruik van Bicep-sjablonen voor enkele recente productlanceringen en ze zijn succesvol. Omdat u uw resources in een sjabloonbestand hebt gedeclareerd, kunt u de resources snel implementeren voor nieuwe speelgoedlanceringen zonder dat u resources handmatig hoeft te configureren in Azure Portal.

De IT-manager kan zien dat uw Bicep-code complexer wordt en steeds meer resources heeft gedefinieerd, zodat ze hebben gevraagd of u de code modulairer kunt maken. U kunt afzonderlijke Bicep-bestanden, modules genoemd, maken voor verschillende onderdelen van uw implementatie. De belangrijkste Bicep-sjabloon kan verwijzen naar deze modules. Achter de schermen worden modules omgezet in één JSON-sjabloon voor implementatie.

Modules zijn ook een manier om Bicep-code nog herbruikbare te maken. U kunt één Bicep-module hebben die veel andere Bicep-sjablonen gebruiken.

U moet ook vaak uitvoer verzenden van de Bicep-modules en -sjablonen. Uitvoer is een manier voor uw Bicep-code om gegevens terug te sturen naar wie of wat de implementatie is gestart. Laten we eerst de uitvoer bekijken.

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.

Uitvoerwaarden

Een mens kan Bicep-sjablonen handmatig implementeren, of een soort geautomatiseerd releaseproces kan deze implementeren. In beide gevallen is het gebruikelijk dat u gegevens uit de sjabloon hebt die u moet terugsturen naar degene die de sjabloonimplementatie uitvoert of wat dan ook is.

Hier volgen enkele voorbeeldscenario's waarin u mogelijk informatie moet ophalen uit de sjabloonimplementatie:

  • U maakt een Bicep-sjabloon waarmee een virtuele machine wordt geïmplementeerd en u moet het openbare IP-adres ophalen, zodat u SSH op de computer kunt gebruiken.
  • U maakt een Bicep-sjabloon die een set parameters accepteert, zoals een omgevingsnaam en een toepassingsnaam. De sjabloon maakt gebruik van een expressie om een naam te geven aan een Azure-app Service-app die wordt geïmplementeerd. U moet de naam van de app uitvoeren die door de sjabloon is geïmplementeerd, zodat u deze in een implementatiepijplijn kunt gebruiken om de binaire bestanden van de toepassing te publiceren.

U kunt uitvoer gebruiken voor deze scenario's. Als u een uitvoer in een Bicep-sjabloon wilt definiëren, gebruikt u het output trefwoord als volgt:

output appServiceAppName string = appServiceAppName

De uitvoerdefinitie bevat enkele belangrijke onderdelen:

  • Het output trefwoord vertelt Bicep dat u een uitvoer definieert.
  • appServiceAppName is de naam van de uitvoer. Wanneer iemand de sjabloon implementeert, bevatten de uitvoerwaarden de naam die u hebt opgegeven, zodat ze toegang hebben tot de waarden die ze verwachten.
  • string is het uitvoertype. Bicep-uitvoer ondersteunt dezelfde typen als parameters.
  • Er moet een waarde worden opgegeven voor elke uitvoer. In tegenstelling tot parameters moeten uitvoer altijd waarden hebben. Uitvoerwaarden kunnen expressies, verwijzingen naar parameters of variabelen zijn, of eigenschappen van resources die in het bestand zijn geïmplementeerd.

Tip

Uitvoer kan dezelfde namen gebruiken als variabelen en parameters. Deze conventie kan handig zijn als u een complexe expressie in een variabele samenstelt voor gebruik in de resources van uw sjabloon en u ook de waarde van de variabele als uitvoer moet weergeven.

Hier volgt een ander voorbeeld van een uitvoer. Deze heeft de waarde ingesteld op de FQDN (Fully Qualified Domain Name) van een openbare IP-adresresource.

output ipFqdn string = publicIPAddress.properties.dnsSettings.fqdn

Tip

Gebruik resource-eigenschappen als uitvoer in plaats van aannames te maken over hoe resources zich gedragen. Als u bijvoorbeeld een uitvoer wilt hebben voor de URL van de App Service-app, gebruikt u de eigenschap van defaultHostName de app in plaats van zelf een tekenreeks voor de URL te maken. Soms zijn deze veronderstellingen niet geldig in verschillende omgevingen, of de manier waarop de resource werkt, zodat de resource veiliger is om u de eigen eigenschappen te laten vertellen.

Let op

Maak geen uitvoer voor geheime waarden, zoals verbindingsreeks s of sleutels. Iedereen met toegang tot uw resourcegroep kan uitvoer van sjablonen lezen. Er zijn andere methoden die u kunt gebruiken om toegang te krijgen tot geheime resource-eigenschappen, die we in een latere module behandelen.

Een module definiëren

Met Bicep-modules kunt u uw Bicep-code ordenen en opnieuw gebruiken door kleinere eenheden te maken die in een sjabloon kunnen worden samengesteld. Elke Bicep-sjabloon kan worden gebruikt als een module door een andere sjabloon. In deze leermodule hebt u Bicep-sjablonen gemaakt. Dat betekent dat u al bestanden hebt gemaakt die kunnen worden gebruikt als Bicep-modules.

Stel dat u een Bicep-sjabloon hebt waarmee toepassings-, database- en netwerkresources voor oplossing A worden geïmplementeerd. U kunt deze sjabloon splitsen in drie modules, die elk zijn gericht op een eigen set resources. Als bonus kunt u nu ook de modules in andere sjablonen opnieuw gebruiken voor andere oplossingen; Dus wanneer u een sjabloon ontwikkelt voor oplossing B, die vergelijkbare netwerkvereisten heeft als oplossing A, kunt u de netwerkmodule opnieuw gebruiken.

Diagram met een sjabloon voor oplossing A die verwijst naar drie modules: toepassing, database en netwerken. De netwerkmodule wordt vervolgens opnieuw gebruikt in een andere sjabloon voor oplossing B.

Als u wilt dat de sjabloon een verwijzing naar een modulebestand bevat, gebruikt u het module trefwoord. Een moduledefinitie lijkt op een resourcedeclaratie, maar in plaats van een resourcetype en API-versie op te slaan, gebruikt u de bestandsnaam van de module:

module myModule 'modules/mymodule.bicep' = {
  name: 'MyModule'
  params: {
    location: location
  }
}

Laten we eens kijken naar enkele belangrijke onderdelen van deze moduledefinitie:

  • Het module trefwoord vertelt Bicep dat u een ander Bicep-bestand als module gaat gebruiken.
  • Net als resources hebben modules een symbolische naam nodig, zoals myModule. U gebruikt de symbolische naam wanneer u verwijst naar de uitvoer van de module in andere delen van de sjabloon.
  • modules/mymodule.bicep is het pad naar het modulebestand ten opzichte van het sjabloonbestand. Een modulebestand is slechts een gewoon Bicep-bestand.
  • Net als resources is de name eigenschap verplicht. Azure gebruikt de modulenaam omdat er een afzonderlijke implementatie wordt gemaakt voor elke module in het sjabloonbestand. Deze implementaties hebben namen die u kunt gebruiken om ze te identificeren.
  • U kunt parameters van de module opgeven met behulp van het params trefwoord. Wanneer u de waarden van elke parameter in de sjabloon instelt, kunt u expressies, sjabloonparameters, variabelen, eigenschappen van resources die in de sjabloon zijn geïmplementeerd en uitvoer van andere modules gebruiken. Bicep begrijpt automatisch de afhankelijkheden tussen de resources.

Modules en uitvoer

Net als bij sjablonen kunnen Bicep-modules uitvoer definiëren. Het is gebruikelijk om modules samen te koppelen binnen een sjabloon. In dat geval kan de uitvoer van de ene module een parameter voor een andere module zijn. Door modules en uitvoer samen te gebruiken, kunt u krachtige en herbruikbare Bicep-bestanden maken.

Uw modules ontwerpen

Een goede Bicep-module volgt enkele belangrijke principes:

  • Een module moet een duidelijk doel hebben. U kunt modules gebruiken om alle resources te definiëren die betrekking hebben op een specifiek deel van uw oplossing. U kunt bijvoorbeeld een module maken die alle resources bevat die worden gebruikt om uw toepassing te bewaken. U kunt ook een module gebruiken om een set resources te definiëren die bij elkaar horen, zoals al uw databaseservers en databases.

  • Plaats niet elke resource in een eigen module. U moet geen afzonderlijke module maken voor elke resource die u implementeert. Als u een resource hebt met veel complexe eigenschappen, kan het zinvol zijn om die resource in een eigen module te plaatsen, maar in het algemeen is het beter voor modules om meerdere resources te combineren.

  • Een module moet duidelijke parameters en uitvoer hebben die zinvol zijn. Houd rekening met het doel van de module. Bedenk of de module parameterwaarden moet manipuleren of of de bovenliggende sjabloon dat moet verwerken en vervolgens één waarde doorgeeft aan de module. Denk ook na over de uitvoer die een module moet retourneren en zorg ervoor dat deze nuttig zijn voor de sjablonen die de module gaan gebruiken.

  • Een module moet zo zelfstandig mogelijk zijn. Als een module een variabele moet gebruiken om een deel van een module te definiëren, moet de variabele in het algemeen worden opgenomen in het modulebestand in plaats van in de bovenliggende sjabloon.

  • Een module mag geen geheimen uitvoeren. Net als bij sjablonen maakt u geen module-uitvoer voor geheime waarden, zoals verbindingsreeks s of sleutels.