Een module publiceren naar een privéregister

4 minuten

U begrijpt nu wat Bicep-registers zijn en hoe ze nuttig kunnen zijn wanneer u modules in uw organisatie deelt. In deze les leert u hoe u een module publiceert in een privéregister.

Modulepaden

Wanneer u in het verleden met modules hebt gewerkt, hebt u waarschijnlijk het bestandspad van de module gebruikt om ernaar te verwijzen in uw sjablonen. Wanneer u met modules en privéregisters werkt, moet u een ander modulepad gebruiken, zodat Bicep weet hoe u de module in uw register kunt vinden.

Hier volgt een voorbeeldpad voor een module in een privé-Azure-containerregister:

Diagram that shows the syntax for a module path.

Het pad bevat vier segmenten:

Schema: Bicep ondersteunt verschillende moduletypen, die schema's worden genoemd. Wanneer u met Bicep-registers werkt, is brhet schema .
Register: de naam van het register dat de module bevat die u wilt gebruiken. In het voorgaande voorbeeld is toycompany.azurecr.iode registernaam , de naam van het containerregister.
Module-id: het volledige pad naar de module in het register.
Tag: Tags vertegenwoordigen doorgaans versies van modules, omdat één module meerdere versies kan hebben gepubliceerd. In de volgende sectie vindt u meer informatie over tags en versies.

Wanneer u uw eigen module-id publiceert, gebruikt u een zinvolle id die het doel van de module aangeeft. U kunt desgewenst naamruimten gebruiken, waarbij u slashes (/) gebruikt om onderscheid te maken tussen delen van een naam. Azure Container Registry en Bicep begrijpen echter geen hiërarchie. Ze behandelen de module-id als één waarde.

Tags en versies

Een tag vertegenwoordigt de versie van een module. Eén module in een register kan meerdere versies hebben. Alle versies delen een module-id, maar ze hebben verschillende tags. Wanneer u een module gebruikt, moet u een tag gebruiken om de versie op te geven die u wilt gebruiken, zodat Bicep weet welk modulebestand moet worden opgehaald.

Het is een goed idee om zorgvuldig te plannen hoe u uw modules gaat versien. Twee belangrijke beslissingen die u moet nemen, zijn het versiebeheerschema en het versiebeheerbeleid dat u wilt gebruiken.

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. U kunt ook een voorvoegsel toevoegen aan elk versienummer, zoals v1 en v2.
Datums maken ook goede versienummers. Als u bijvoorbeeld de eerste versie van uw module publiceert op 16 januari 2022, kunt u de versie 2022-01-16 een naam geven (met de notatie jjjj-mm-dd ). Wanneer u een andere versie publiceert op 3 maart, kunt u deze 2022-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 wilt, is het een goed idee om iets te kiezen dat in een zinvolle volgorde kan worden gesorteerd. Getallen en datums zijn vaak goede keuzes.

Notitie

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

Versiebeheerbeleid

Modules bieden u de flexibiliteit om te kiezen wanneer u nieuwe versies maakt of een bestaande versie bijwerkt. U kunt zich bijvoorbeeld effectief afmelden voor versiebeheer door één versie met de naam latestte maken en te publiceren. Wanneer u de module 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 module die niet van invloed is op de manier waarop deze wordt gebruikt, is het maken van een nieuwe versie waarschijnlijk geen goed idee. U moet het nieuwe versienummer doorgeven aan iedereen die de module gebruikt.

Hier volgt een versiebeheerbeleid dat vaak goed werkt:

Wanneer u belangrijke wijzigingen aanbrengt in een module, maakt u een nieuwe versie. Belangrijke wijzigingen zijn alles wat een verschil kan maken voor iemand die uw module gebruikt. Voorbeelden zijn het toevoegen van een andere resource aan de module of het wijzigen van de eigenschappen van een resource.
Wanneer u kleine wijzigingen aanbrengt in een module, die ook wel een hotfix wordt genoemd, werkt u de bestaande moduleversie 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 uw module en denk na over wat ze verwachten. Als iemand uw module meerdere keren gebruikt en één resultaat krijgt en deze vervolgens opnieuw gebruikt na een hotfix en een ander resultaat krijgt, zullen ze waarschijnlijk verrast zijn. Probeer te voorkomen dat uw gebruikers verrassend zijn.

Uw module publiceren

Wanneer u een Bicep-module maakt die u wilt delen, maakt u het Bicep-bestand als normaal. Vervolgens publiceert u het bestand naar een register met behulp van de bicep publish opdracht. Wanneer u publiceert, moet u het modulepad opgeven om de module op te slaan in:

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

bicep publish module.bicep `
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

De publicatiebewerking voert dezelfde validatiestappen uit als wanneer u een Bicep-bestand bouwt of implementeert. Hieronder vallen de volgende stappen:

Controleren of uw code geen syntactische fouten bevat.
Controleer of u geldige resourcedefinities opgeeft.
Voer de Bicep linter uit om te controleren of uw code een reeks kwaliteitscontroles doorgeeft.