Door het beheer van uw ARM-sjablonen (Azure Resource Manager) te modulariseren, kunt u herhalingen verminderen, aanbevolen procedures voor modellen bij het ontwikkelen van infrastructuur en consistente standaardimplementaties hebben.
Een voorbeeld van een gebruiksvoorbeeld voor het implementeren van dit soort modularisatie is de implementatie van virtuele machines (VM's) met behulp van de metafoor van t-shirtgrootten. Stel dat u tientallen of honderden VM's hebt geïmplementeerd. Deze implementaties gebruiken versie 1.0.0 van uw sjablonen en hebben een standaard middelgrote grootte van een oudere serie. Als u wilt overstappen naar een nieuwe reeks, is mogelijk een korte onderbreking van de service vereist als u gewoon nieuwe sjablonen hebt geïmplementeerd. Door versie 1.5.0 te bouwen en modularisatie te gebruiken, kunt u echter nieuwe infrastructuur implementeren met de bijgewerkte standaard, terwijl de oude infrastructuur in een implementeerbare status blijft. Door oude versies van de infrastructuur beschikbaar te hebben, hebben uw product- en toepassingsteams een bekende goede configuratie waarop u kunt vertrouwen tijdens het upgraden naar de nieuwe versie wanneer ze tijd hebben.
De laagcake van opslagplaatsen: een voorbeeld voor ondernemingen
Als het gaat om de reden waarom u mogelijk een sterke voorkeur wilt hebben voor waar uw sjablonen naartoe gaan, hoe ze worden bijgewerkt, enzovoort, zijn er twee primaire overwegingen: vertakkingen en innersourcing.
Vertakking. Dit voorbeeldscenario faciliteert git-vertakkingsmodellen die ondersteuning bieden voor Gitflow en GitHub-stroom. Zie Git-flow gebruiken om uw git-vertakkingswerkstroom te automatiseren, een blogbericht van Jeff Kreeftopgegeven voor meer informatie over Gitflow. Zie De GitHub-stroom in de GitHub-documentatie voor meer informatie over De GitHub-stroom.
Innersourcing. De tweede is innersourcing, wat de samenwerkingspraktijken van opensource-softwareontwikkeling tot interne ontwikkeling brengt. In een dergelijk scenario kunt u met meer vertrouwen verschillende sjablonen en modulebroncode delen zonder dat u zich zorgen hoeft te maken over machtigingen voor de implementatiemodellen zelf. Zie Een inleiding tot innersource op GitHub voor meer informatie over innersource-ontwikkeling.
Bicep is een declaratieve taal voor het implementeren van Azure-resources. De herbruikbare code van Bicep kan Azure Container Registry gebruiken als een privéregister voor het hosten van ARM-sjablonen met versiebeheer. Door Container Registry op deze manier te gebruiken, kan uw onderneming een proces van continue integratie en continue levering (CI/CD) voor infrastructuur hebben. U kunt integratie- en eenheidstests uitvoeren als onderdeel van het CI-proces en het containerregister kan modules ontvangen nadat ze zijn gebouwd. App-teams kunnen oudere versies blijven gebruiken totdat ze klaar zijn om te upgraden of ze kunnen bijwerken om te profiteren van functies in de nieuwere versies van sjablonen.
Naast dit gebruik van Container Registry kunt u dit model combineren met iets als de geverifieerde Azure-modules. Uw implementatie kan gebruikmaken van het openbare register of bij voorkeur de openbare opslagplaatsen bewaken en wijzigingen in uw privéregister ophalen voor verder gebruik. Door wijzigingen in uw eigen containerregister op te halen, kunt u tests uitvoeren op openbare modules terwijl u ervoor zorgt dat ze niet in productie worden gebruikt totdat de kwaliteit en beveiligingsprocedures zijn opgenomen.
Lagen
Het model dat in dit voorbeeldscenario wordt voorgesteld, is een model dat wordt gestapeld. Lagen die zich boven aan de stapel bevinden, hebben vaker implementaties en implementaties die meer op maat zijn. Bicep-code biedt consistente implementaties. Ontwikkelteams, die in de lagen voor hun bijdragen werken, bouwen op basis van de services en infrastructuur die in de onderstaande lagen worden aangeboden. Niets in een lagere laag moet afhankelijk zijn van resources in een laag erboven. Van laag 0 tot en met 3 zijn globale bibliotheek, globale infrastructuur (wereldwijd gedeelde services), productplatform (gedeelde services) en toepassingen.
Dit model creëert autonomie met uitlijning, wat betekent dat:
Algemene hulpprogramma's voor bedrijfsgemak. Iedereen gebruikt bijvoorbeeld Git voor broncodebeheer en iedereen gebruikt GitHub Actions voor CI/CD. We zijn echter niet te laat. We verplichten bijvoorbeeld niet dat alle teams Bicep gebruiken; ze kunnen Terraform-, ARM-sjablonen en andere hulpprogramma's gebruiken.
De mogelijkheid om best practices te delen. Ze kunnen de vorm aannemen van ARM-sjablonen, gouden afbeeldingen of codefragmenten. Best practices kunnen ook documentatie zijn van specifieke technieken. Bijvoorbeeld het roteren van sleutels in uw omgeving en het testen van code.
Sommige services gaan omlaag in de stapel. Een app-team kan bijvoorbeeld in eerste instantie een sjabloon ontwikkelen voor het implementeren van een Kubernetes-cluster, dat later wordt opgehaald in het productplatform als een gedeelde service. Deze sjabloon wordt zo nuttig dat deze wordt opgehaald in de bibliotheek met voorbeelden.
Laag 0 - Globale bibliotheek
De onderste laag is de globale bibliotheek, een opslagplaats met nuttige tidbits die niet in productie zijn geïmplementeerd. Vanuit het perspectief van toegangsbeheer moet leestoegang worden verstrekt aan iedereen in het bedrijf die dit aanvraagt. Voor wijzigingen, suggesties, enzovoort, keurt uw Cloud Center of Excellence (CCoE) pull-aanvragen goed en beheert u een achterstand alsof dit een ander product was.
Laag 0 mag niet het volgende bevatten:
- Sjablonen die in productie zijn geïmplementeerd.
- Geheimen of omgevingsspecifieke configuraties.
Laag 0 moet het volgende bevatten:
- Codefragmenten (in Python, C#, enzovoort).
- Voorbeelden van Azure Policy.
- ARM-sjablonen, Bicep-sjablonen of Terraform-bestanden die kunnen worden gebruikt als voorbeelden.
Een voorbeeld hiervan is een voorbeeldarchitectuur voor de manier waarop uw bedrijf een implementatie zou schrijven voor een toepassing met drie lagen zonder omgevingsspecifieke informatie. Deze voorbeeldarchitectuur kan tags, netwerken, netwerkbeveiligingsgroepen, enzovoort bevatten. Het weglaten van specifieke informatie voor de omgeving is nuttig, omdat niet alles kan zijn of moet worden geplaatst in een module. Als u dit probeert te doen, kan dit leiden tot overparameterisatie.
Daarnaast kan Laag 0 een koppeling maken naar andere bekende goede bronnen van voorbeeldcode, zoals het Terraform Registry of Azure Resource Modules). Als uw organisatie code of een patroon uit een van deze bronnen gebruikt, raden we u aan om de code of het patroon in uw eigen laag 0 op te halen in plaats van rechtstreeks uit de openbare bronnen te halen. Door te vertrouwen op uw Laag 0, kunt u uw eigen tests, aanpassingen en beveiligingsconfiguraties schrijven. Door niet te vertrouwen op openbare bronnen, vermindert u het risico dat u vertrouwt op iets dat onverwacht kan worden verwijderd.
Om als goede voorbeeldcode te worden beschouwd, moeten uw sjablonen en modules goede ontwikkelprocedures volgen, inclusief invoervalidatie voor beveiliging en voor organisatorische vereisten. Als u dit niveau van striktheid wilt behouden, moet u beleidsregels toevoegen aan de hoofdvertakking om pull-aanvragen (PULL-aanvragen) en codebeoordelingen te vereisen voor voorgestelde wijzigingen die ertoe leiden dat wijzigingen naar het hoofdcontainerregister stromen als ze worden samengevoegd.
Laag 0-feeds in Azure Pipelines of GitHub Actions om automatisch versie-artefacten te maken in Azure Container Registry. U kunt automatisering bouwen voor git-doorvoerberichten om semantische versiebeheer van de artefacten te implementeren. Om dit goed te laten werken, moet u een deterministische naamgevingsstandaard, zoals <service.bicep>, hebben om de automatisering in de loop van de tijd onderhoudbaar te maken. Met het juiste vertakkingsbeleid kunt u ook integratietests toevoegen als een vereiste voor codebeoordelingen. U kunt dit instrumenteren met behulp van hulpprogramma's zoals Pester.
Met dergelijke beleidsregels en beveiligingen kan het containerregister de bron van waarheid zijn voor alle infrastructuurmodules in de onderneming die klaar zijn voor gebruik. U moet overwegen om wijzigingslogboeken, evenals indexen van beschikbare codevoorbeelden, te standaardiseren om detectie van deze code mogelijk te maken. Onbekende code is ongebruikte code.
Laag 1 - Globale infrastructuur: Wereldwijd gedeelde services
Laag 1 is de opslagplaats voor uw Azure-landingszone-constructies. Hoewel Microsoft sjablonen levert voor de implementatie van Azure-landingszones, wilt u bepaalde onderdelen wijzigen en een parameterbestand opgeven. Dit is vergelijkbaar met de manier waarop u openbare register- en moduleopslagplaatsen naar Laag 0 ophaalt, zoals eerder is beschreven.
Azure Container Registry is een essentieel onderdeel van deze architectuur. Zelfs als uw bedrijf geen containers wil gebruiken, moet u Container Registry implementeren om bicep-sjablonen te kunnen versiebeheer. Container Registry maakt aanzienlijke flexibiliteit en herbruikbaarheid mogelijk voor uw modules en biedt tegelijkertijd beveiliging en toegangsbeheer op bedrijfsniveau.
Laag 1 moet het volgende bevatten:
- Beleidstoewijzingen en -definities die worden toegepast op het niveau van de beheergroep of het abonnement. Deze beleidsregels moeten overeenkomen met uw vereisten voor corporate governance.
- Sjablonen voor de kernnetwerkinfrastructuur, zoals ExpressRoute, VPN's, virtual WAN en virtuele netwerken (gedeeld of hub).
- DNS.
- Kernbewaking (log analytics).
- Enterprise-containerregister.
U moet vertakkingsbeveiliging configureren om de mogelijkheid om wijzigingen naar deze opslagplaats te pushen, te beperken. Beperk de goedkeuring van PULL's van andere ontwikkelaars tot leden van de CCoE of Cloud Governance. Inzenders voor deze laag zijn voornamelijk leden van groepen die historisch zijn gekoppeld aan de onderdelen in deze laag. Het netwerkteam bouwt bijvoorbeeld de sjablonen voor het netwerk, het operations-team configureert bewaking, enzovoort. U moet echter alleen-lezentoegang verlenen aan personen die dit aanvragen, omdat u ontwikkelaars van andere groepen in staat wilt stellen wijzigingen in de kerninfrastructuren voor te stellen. Ze kunnen bijdragen aan verbeteringen, hoewel u niet toestaat dat hun wijzigingen worden samengevoegd zonder goedkeuring en testen.
Deze bestanden moeten de modules in uw containerregister gebruiken voor standaardonderdelen. U hebt echter ook een Bicep-bestand of een reeks Bicep-bestanden die zijn aangepast aan de implementatie van Azure-landingszones van uw bedrijf of een vergelijkbare governancestructuur.
Laag 2 - Productplatform: Gedeelde services
U kunt Laag 2, productplatform beschouwen als de gedeelde services voor een bepaalde productlijn of bedrijfseenheid. Deze onderdelen zijn niet universeel in de hele organisatie, maar ze zijn bedoeld om aan een bepaalde bedrijfsbehoefte te voldoen. Dit is een geschikte laag voor een virtueel netwerk dat een peer is met de hub in laag 1, globale infrastructuur. Een sleutelkluis is een ander voorbeeldonderdeel voor deze laag. De sleutelkluis kan gedeelde geheimen opslaan in een opslagaccount of een database die wordt gedeeld door de verschillende toepassingen binnen dit platform.
Laag 2 moet het volgende bevatten:
- Beleidstoewijzingen die worden toegepast op een abonnement of resourcegroep om te voldoen aan productspecifieke vereisten.
- ARM-sjablonen voor sleutelkluizen, log analytics, een SQL-database (als verschillende toepassingen binnen het product de database gebruiken) en Azure Kubernetes Service.
U moet machtigingen implementeren die de mogelijkheid beperken om wijzigingen naar deze opslagplaats te pushen. Net als bij de andere lagen moet u vertakkingsbeveiliging gebruiken om ervoor te zorgen dat een productleider of eigenaar pull-aanvragen van andere ontwikkelaars kan goedkeuren. Er zijn geen vaste regels voor leestoegang tot het productplatform, maar ontwikkelaars van een van de toepassingsteams moeten minimaal leestoegang krijgen om wijzigingen voor te stellen. Omdat laag 2 een eigen architectuur of vergelijkbare informatie kan bevatten, kunt u ervoor kiezen om de toegang te beperken tot degenen in de organisatie die het platform gebruiken. Als dat het geval is, moet u er echter voor zorgen dat u een proces bouwt voor het verzamelen van goede procedures en fragmenten uit deze opslagplaats om te delen met de globale bibliotheek, Laag 0.
Laag 3 - Toepassing
Laag 3, de toepassingslaag, bevat de onderdelen die op het productplatform zijn gebouwd. Deze onderdelen leveren de functies die het bedrijf aanvraagt. Voor een streamingplatform kan één app bijvoorbeeld de zoekfunctie bieden terwijl een andere app aanbevelingen biedt.
Laag 3 moet het volgende bevatten:
- Toepassingscode in C#, Python, enzovoort.
- Infrastructuur voor afzonderlijke onderdelen (die alleen in deze toepassing worden gebruikt): functies, Azure Container Instances, Event Hubs.
Machtigingen zijn beperkt voor de mogelijkheid om wijzigingen naar deze opslagplaats te pushen. U moet vertakkingsbeveiliging gebruiken om een teamlid van deze toepassing in staat te stellen een pull-aanvraag van een ander teamlid goed te keuren. Teamleden mogen hun eigen wijzigingen niet goedkeuren. Omdat deze laag bedrijfseigen architectuur, bedrijfslogica of vergelijkbare informatie kan bevatten, kunt u ervoor kiezen om de toegang te beperken tot degenen in de organisatie die deze toepassing bouwen. Als dat het geval is, moet u echter ook een proces bouwen voor het verzamelen van goede procedures en fragmenten uit deze laag om te delen met de globale bibliotheek, Laag 0.
Commonalities over lagen
Hoewel in dit artikel enkele specifieke details voor elke laag worden beschreven, zijn er ook enkele kwaliteiten voor alle lagen die u moet overwegen.
Uw infrastructuur moet werken alsof het een toepassing is. Dit betekent dat u een CI-proces (continue integratie) moet hebben waarin nieuwe functies volledig worden getest, met eenheidstests, betrouwbaarheidstests en integratietests. U moet alleen code samenvoegen die deze tests doorgeeft aan de hoofdreleasebranch.
U moet er ook voor zorgen dat u vertakkingsbeleid hebt ingesteld om te voorkomen dat personen het proces omzeilen, zelfs voor expediency. Als uw CI-proces wordt gezien als een belemmering, betekent dit dat u technische schulden hebt gemaakt die moeten worden afgehandeld. Het betekent niet dat u het beleid en de beveiliging moet verwijderen.
Ten slotte moet uw organisatie, hoewel u mogelijk geen index van alle opslagplaatsen en de code erin hebt, een proces ontwikkelen voor personen om toegang tot opslagplaatsen aan te vragen. Bepaalde regels kunnen volledig worden geautomatiseerd. U kunt bijvoorbeeld een regel implementeren die leestoegang verleent, zonder beoordeling, aan een inzender die zich in het productteam bevindt voor elke toepassing onder dat product. Dergelijke regels kunnen vaak worden geïmplementeerd met lidmaatschap op basis van groepen en roltoewijzingen op basis van groepen in uw omgevingen. Het configureren van dit soort toegang moet helpen bij het vergemakkelijken van interne sourcing en organisatiekennis.
Bijdragers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Belangrijkste auteurs:
- Tim Sullivan | Senior Cloud Solution Architect
Andere Inzenders:
- Gary Moore | Programmeur/schrijver
Volgende stappen
- Ontwerpgebied: Platformautomatisering en DevOps
- Volwassen teamstructuren
- Wat is Infrastructure as Code?
- Azure/ResourceModules: deze opslagplaats bevat een CI-platform voor en verzameling van volwassen en gecureerde Bicep-modules. Het platform ondersteunt zowel Azure Resource Manager als Bicep, en u kunt de functies ervan gebruiken met GitHub-acties en Azure Pipelines.
- Privéregister maken voor Bicep-module