Tijdelijke omgevingen implementeren voor beoordelingen
Door uw Bicep-code te linten, krijgt u een indicatie of uw Azure-implementatie waarschijnlijk zal slagen. U vindt het ook handig om uw Bicep-code ergens te implementeren om te zien hoe uw omgeving eruitziet nadat de pull-aanvraag is samengevoegd en de implementatie is voltooid.
In deze les leert u hoe u uw code implementeert in een tijdelijke omgeving vanuit een pull-aanvraag.
Waarom uw code implementeren vanuit een pull-aanvraag?
Wanneer u een pull-aanvraag bekijkt die Bicep-code bevat, is het een goede gewoonte om de Bicep-code te implementeren in een echte Azure-omgeving. Door dit te doen, kunt u vertrouwen opbouwen dat uw wijzigingen werken wanneer ze uw productieomgeving bereiken. Als er een probleem is, wilt u het snel ontdekken. Pull-aanvragen bieden u een geweldige kans om problemen te detecteren en te markeren, omdat u direct feedback krijgt van uw revisoren.
U bent nu gewend aan het idee om uw wijzigingen te implementeren in een of meer niet-productieomgevingen, zoals Testen, QA en Fasering, voordat u ze implementeert in uw productieomgeving. In veel organisaties zijn deze omgevingen langdurig, wat betekent dat ze worden bijgewerkt wanneer wijzigingen worden geïmplementeerd en de omgevingen meestal niet worden verwijderd.
Een tijdelijke omgeving is daarentegen een omgeving die u dynamisch maakt en een omgeving die u gemakkelijk kunt verwijderen wanneer deze niet meer nuttig is. Tijdelijke omgevingen zijn alleen bedoeld om gedurende korte tijd te bestaan (bijvoorbeeld alleen lang genoeg om uw wijzigingen te controleren).
Kortstondige omgevingen zijn een goede keuze wanneer u omgevingen implementeert voor pull-aanvragen, omdat u mogelijk veel afzonderlijke pull-aanvragen tegelijk hebt geopend, die verschillende typen wijzigingen vertegenwoordigen. Als u meerdere pull-aanvragen hebt geopend, betekent het delen van uw niet-productieomgevingen dat u slechts één wijziging tegelijk kunt bekijken.
Tijdelijke omgevingen maken
Omdat u zo gewend bent om uw Azure-infrastructuur op te bouwen als code en u hebt geïnvesteerd in het bouwen van uw Bicep-bestanden om uw resources te implementeren, kunt u dezelfde assets opnieuw gebruiken om een tijdelijke omgeving te implementeren. U kunt zelfs meerdere tijdelijke omgevingen tegelijk implementeren, als dat nodig is. U hoeft er alleen voor te zorgen dat uw implementaties voldoende geparameteriseerd en gegeneraliseerd zijn, zodat u eenvoudig onafhankelijke omgevingen kunt maken. U moet er bijvoorbeeld voor zorgen dat sommige Azure-resources wereldwijd unieke namen krijgen, die niet hetzelfde kunnen zijn als resourcenamen in een andere kortstondige of langdurige omgeving.
Kortstondige omgevingen bieden veel voordelen:
- U kunt veilig nieuwe functies en mogelijkheden testen in een geïsoleerde omgeving die geen invloed heeft op uw andere productie- of niet-productieworkloads.
- U kunt uw wijzigingen in uw eigen vertakking weergeven, zodat u uw werk eenvoudig aan uw collega's kunt laten zien of toegang kunt bieden tot revisoren.
- U kunt meerdere teamleden afzonderlijke wijzigingen tegelijk laten testen, zelfs als de wijzigingen niet compatibel zijn.
- Omdat ze betrekking hebben op het regelmatig uitvoeren van uw Bicep-bestanden, helpen tijdelijke omgevingen u voortdurend de nauwkeurigheid en volledigheid van uw Bicep-code en andere scripts te testen. Als gevolg hiervan kunt u er zeker van zijn dat de code perfect wordt uitgevoerd in uw productieomgeving.
In deze module maakt u kortstondige omgevingen om u te helpen bij het opbouwen van vertrouwen over de wijzigingen in pull-aanvragen. Iedereen die de pull-aanvraag beoordeelt, heeft toegang tot de tijdelijke omgeving, inclusief eventuele nieuwe toevoegingen en updates, voordat de pull-aanvraag wordt goedgekeurd en samengevoegd.
Implementatie
Wanneer u met tijdelijke omgevingen werkt, kunt u het beste een afzonderlijke Azure-resourcegroep maken voor elke pull-aanvraag die uw team maakt. Als één auteur twee afzonderlijke pull-aanvragen heeft geopend, heeft elk een eigen tijdelijke omgeving. Dit helpt om elke wijziging gescheiden te houden van de andere, en het kan helpen om verwarring te voorkomen of resources per ongeluk te overschrijven.
Voor deze aanpak werkt de validatiewerkstroom voor pull-aanvragen dynamisch om resourcegroepen te maken. Resourcegroepen vereisen unieke namen en u moet de resourcegroep ook eenvoudig kunnen vinden om de resources te testen en te verwijderen wanneer uw pull-aanvraag wordt gesloten. Als u de namen van resourcegroepen effectief wilt afhandelen, kunt u het pull-aanvraagnummer binnen de naam van de resourcegroep gebruiken. In de volgende oefening ziet u hoe u dit doet.
Wanneer het tijd is om de tijdelijke omgeving te verwijderen, is het eenvoudig voor uw werkstroom om de hele resourcegroep te vinden en te verwijderen. Alle resources die in de tijdelijke omgeving worden gebruikt, worden tegelijkertijd verwijderd.
Machtigingen
Voor het maken van resourcegroepen zijn machtigingen op abonnementsniveau vereist. Doorgaans moet de rol Inzender worden toegewezen aan de workloadidentiteit van uw werkstroom.
Het is een goed idee om een toegewezen Azure-abonnement te gebruiken voor tijdelijke omgevingen. Door deze aanpak te volgen, kunt u toegang verlenen tot de workloadidentiteit van uw werkstroom en aan uw teamleden zonder per ongeluk toegang te verlenen tot uw andere omgevingen.
Belangrijk
Inzenders met abonnementsbereik zijn krachtig, dus u moet ervoor zorgen dat u voldoende governance hebt rond de workloadidentiteit van uw werkstroom en de wijzigingen die kunnen worden geïmplementeerd. Door een speciaal abonnement te gebruiken voor tijdelijke omgevingen, vermindert u het risico voor uw andere omgevingen.
De identiteit van uw werkstroom
Uw implementatiewerkstroom maakt gebruik van een workloadidentiteit en federatieve referenties om te verifiëren bij Azure. Wanneer u validatiewerkstromen voor pull-aanvragen gebruikt, moet u de federatieve referentie configureren voor gebruik met pull-aanvragen.
In een vorige oefening in deze module hebt u een opdracht uitgevoerd om een federatieve referentie te maken. De beleidsreeks ziet er ongeveer als volgt uit:
repo:my-github-user/my-repo:pull_request
Aan pull_request het einde van de tekenreeks wordt aangegeven dat de federatieve referentie werkt met validatiewerkstromen voor pull-aanvragen.
Kostenbeheer
Wanneer u dynamisch tijdelijke omgevingen maakt, is er een risico dat uw Azure-kosten kunnen toenemen. Als uw team een groot aantal pull-aanvragen heeft geopend, kunt u een groot aantal kostbare resources implementeren in Azure.
Tip
Als uw team pull-aanvragen snel sluit, zijn hogere kosten minder belangrijk omdat een tijdelijke omgeving wordt verwijderd wanneer de bijbehorende pull-aanvraag wordt gesloten.
Met behulp van een toegewezen Azure-abonnement kunt u ook eenvoudig de kosten van uw kortstondige omgevingen bewaken. En u kunt abonnementsbrede beleidsregels toepassen die de SKU's van uw kortstondige resources beperken, zodat u kostenoverschrijdingen kunt voorkomen.
Daarnaast biedt Azure veel manieren om u te helpen de kosten van tijdelijke omgevingen te beheren, waaronder:
- Met Microsoft Cost Management kunt u budgetten instellen voor een abonnement. Budgetten activeren meldingen, zodat uw team er rekening mee houdt dat de kosten de drempelwaarde naderen die u hebt opgegeven.
- Veel Azure-resourcetypen bieden goedkopere of zelfs gratis lagen voor niet-productieworkloads. Overweeg of u deze prijscategorieën en SKU's kunt gebruiken.
- Prijzen voor Azure Dev/Test zijn beschikbaar voor sommige klanten die ze kunnen gebruiken voor hun niet-productieabonnementen.
- Met resourcetags kunt u de resources identificeren die zijn gekoppeld aan elke tijdelijke omgeving en de kosten van elke tijdelijke omgeving berekenen.
- U kunt automatiseringsscripts maken om uw kortstondige resources te verwijderen na een gedefinieerde periode of zelfs elke nacht na kantooruren.
U kunt ook overwegen om bepaalde resources te delen tussen tijdelijke omgevingen. Uw Bicep-code kan bijvoorbeeld veel resources definiëren, waarvan een aantal kostbaar zijn of die lang duren voordat ze zijn ingericht. U kunt een gedeelde, langdurige resourcegroep maken voor al uw pull-aanvragen om de kostbare resources te delen en afzonderlijke tijdelijke resourcegroepen te maken voor de andere resources. Deze aanpak maakt het echter moeilijk en foutgevoelig om uw kortstondige omgevingen te beheren en om ze gescheiden te houden om nuttig te zijn tijdens uw beoordelingsproces. U kunt deze aanpak het beste vermijden, tenzij de kosten van uw kortstondige omgevingen te hoog worden.