Toepassingsontwikkelingsomgevingen beheren in Azure-landingszones
In dit artikel wordt beschreven hoe cloudplatformteams kaders kunnen implementeren voor het beheren van toepassingsomgevingen in Azure-landingszones. Ook wordt uitgelegd hoe u verschillende ontwikkelomgevingen voor toepassingen kunt uitlijnen met hun framework. Een belangrijk aspect bij het maken van de juiste omgeving is het plaatsen van abonnementen in de juiste beheergroepen.
De basis instellen
Ontwikkelteams vereisen de mogelijkheid om snel te herhalen, en cloudgovernance- en platformteams moeten organisatierisico's, naleving en beveiliging op schaal beheren. U kunt toepassingsomgevingen op de juiste manier beheren door u te richten op twee belangrijke ontwerpprincipes voor Azure-landingszones: beleidgestuurde governance en democratisering van abonnementen. Deze principes bieden fundamentele kaders en beschrijven hoe u besturingselementen kunt delegeren aan toepassingsteams. De toepassingsteams gebruiken richtlijnen voor Azure Well-Architected Framework om hun workload te ontwerpen. Ze implementeren en beheren hun eigen landingszone-resources en het platformteam beheert de resources door Azure-beleid toe te wijzen.
Het is belangrijk om sandbox-resources te bieden voor semi-beheerde resources, zodat toepassingsteams kunnen experimenteren met technologieën en mogelijkheden.
Wanneer toepassingseigenaren abonnementsautomaat of andere processen voor het maken van abonnementen gebruiken, moeten ze weten hoe ze abonnementen moeten aanvragen voor meerdere ontwikkelomgevingen.
In dit artikel wordt de Azure-landingszone beschreven, waaronder de beheergroepen, beleidsregels en de architectuur van het gedeelde platform en de workload of landingszone van toepassingen.
Notitie
De richtlijnen in dit artikel zijn alleen bedoeld voor landingszones voor workloads of toepassingen. Zie Testbenadering voor Azure-landingszones, waarin de canary-benadering wordt beschreven voor testen en omgevingsscheiding voor het Azure-landingszoneplatform zelf.
In de praktijk kunt u elk gewenst aantal en type gefaseerde omgeving gebruiken. Dit artikel verwijst naar de volgende gefaseerde omgevingen.
| Environment | Beschrijving | Beheergroep |
|---|---|---|
| Sandbox | De omgeving die wordt gebruikt voor snelle innovatie van prototypen, maar niet voor productiegebonden configuraties | Sandbox-beheergroep |
| Ontwikkeling | De omgeving die wordt gebruikt om potentiële releasekandidaten te bouwen | Archetype-beheergroep, zoals corp of online |
| Testen | De omgeving die wordt gebruikt om tests uit te voeren, waaronder eenheidstests, gebruikersacceptatietests en kwaliteitscontroletests | Archetype-beheergroep, zoals corp of online |
| Productie | De omgeving die wordt gebruikt om waarde te leveren aan klanten | Archetype-beheergroep, zoals corp of online |
Zie de video's voor het verwerken van ontwikkel-, test- en productieomgevingen voor toepassingsworkloads en hoeveel abonnementen moet ik gebruiken in Azure voor meer informatie?
Omgevingen, abonnementen en beheergroepen
Zie het ontwerpgebied van de resourceorganisatie als vereiste voor deze sectie.
U moet uw abonnementen op de juiste manier organiseren wanneer u azure-landingszoneprocedures gebruikt. In het ideale geval moet elke toepassingsomgeving een eigen abonnement hebben. Deze methode biedt besturingselementen voor beveiliging en beleid die de omgevingen geïsoleerd houden. Het bevat potentiële problemen in één omgeving.
Afzonderlijke abonnementen hebben hetzelfde beleid op archetypeniveau. Indien nodig kunnen toepassingseigenaren abonnementsspecifieke beleidsregels toewijzen om toepassings- en omgevingsspecifiek gedrag af te dwingen.
Voor sommige toepassingsarchitecturen is vereist dat services worden gedeeld tussen omgevingen. Als dat het geval is, kunt u één abonnement gebruiken voor meerdere omgevingen. We raden u aan om workloadeigenaren te laten samenwerken met cloudplatformteams om te bepalen of één abonnement voor meerdere omgevingen nodig is.
Gebruik één abonnement voor meerdere toepassingsomgevingen als:
De omgevingen kunnen niet worden geïsoleerd in hun eigen abonnementen.
De omgevingen hebben dezelfde teams toegewezen aan functionele rollen, zoals netwerkoperators.
De omgevingen kunnen hetzelfde beleid gebruiken.
Als een toepassing of serviceworkload zich in één abonnement moet bevinden en u wijzigingen moet aanbrengen in het beleid dat van toepassing is op elke omgeving, kunt u het volgende doen:
Maak een nieuwe , archetype uitgelijnde beheergroep onder de beheergroep voor landingszones. Zie de hiërarchie van beheergroepen in dit artikel voor meer informatie.
Gebruik sandbox-abonnementen voor ontwikkelingsactiviteiten. Sandboxes hebben een minder beperkende beleidsset.
Gebruik beleidsregels die worden toegepast op abonnementsniveau in plaats van het niveau van de beheergroep. U kunt tags toevoegen in de beleidsdefinities om beleid te filteren en toe te passen op de juiste omgeving. U kunt beleidsregels ook toewijzen aan of uitsluiten van specifieke resourcegroepen.
U kunt beleidsregels toewijzen tijdens het maken van het abonnement als onderdeel van abonnementsautomaat.
Voor beleidsregels die u implementeert om de kosten te beheren, past u waar nodig de beleidsdefinitie toe op abonnementsniveau. Of u kunt de eigenaar van de landingszone verantwoordelijk maken voor kosten, wat echte autonomie biedt. Zie Platformautomatisering en DevOps voor meer informatie.
Waarschuwing
In tegenstelling tot beleidsregels en besturingselementen op beheergroepsniveau kunnen beleidsregels en tags op basis van abonnementen worden gewijzigd door personen met verhoogde machtigingen voor het abonnement. Beheer istrators met de juiste rollen kunnen deze besturingselementen omzeilen door beleidsregels uit te sluiten, beleidsregels te wijzigen of de tags op resources te wijzigen.
Als gevolg hiervan moet u geen tags toepassen in de definities van beveiligingsbeleid. Wijs bovendien geen machtigingen toe zoals altijd actief voor de volgende acties:
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
U kunt deze acties beheren met behulp van Privileged Identity Management (PIM).
Hiërarchie van beheergroepen
Vermijd ingewikkelde hiërarchieën van beheergroepen. Ze kunnen frequente wijzigingen vereisen, efficiënt schalen en gebrek aan waarde. Om deze potentiële problemen te voorkomen, worden azure landingszonebeheergroepen uitgelijnd op archetype van de workload. Zie Beheergroep en abonnementsorganisatie voor meer informatie.
Archetype uitgelijnd betekent dat beheergroepen alleen worden gemaakt voor specifieke workload archetypen. In de conceptuele architectuur heeft de beheergroep landingszones bijvoorbeeld corp- en online onderliggende beheergroepen. Deze onderliggende beheergroepen zijn afgestemd op afzonderlijke archetypepatronen voor de workloads die ze bevatten. De onderliggende beheergroepen richten zich op vereisten voor hybride connectiviteit (VPN/Azure ExpressRoute), zoals alleen intern versus openbaar gerichte toepassingen en services.
Met uitzondering van sandbox-omgevingen moeten verschillende toepassingsomgevingen hetzelfde archetype gebruiken voor implementatie. Zelfs als omgevingen zijn verdeeld over verschillende abonnementen, worden ze bewaard binnen dezelfde enkele beheergroep (corp of online), op basis van het archetype van de beheergroep en de vereisten.
U kunt sandbox-abonnementen gebruiken voor ongestructureerde ontwikkeling, zoals persoonlijke labs of voor een workload die geen archetype heeft. Een toepassings- of serviceworkloadteam gebruikt een sandbox-beheergroep om verschillende Azure-services te testen om te bepalen wat het beste werkt voor hun vereisten. Nadat ze over services hebben besloten, kunnen ze een landingszone inrichten (in de juiste workload archetype-uitgelijnde beheergroep in de beheergroephiërarchie van landingszones ) voor het team.
De sandbox-omgevingen kunnen worden gebruikt voor specifieke toepassingen of een workloadteam kan deze gebruiken voor experimenten.
Zie voor meer informatie:
- Beheergroepen.
- Ontwerpgebied van resourceorganisatie.
- Pas de architectuur van de Azure-landingszone aan om te voldoen aan de vereisten.
Uitdagingen voor beheergroepen op basis van een omgeving
Beheergroepen voor omgevingen binnen archetypen kunnen beheeroverhead toevoegen en minimale waarde bieden.
De beheergroep voor landingszones moet universeel beleid hebben dat kaders afdwingt voor zowel corp - als online onderliggende beheergroepen. Corp en online hebben unieke beleidsregels die bedrijfsrichtlijnen afdwingen met betrekking tot openbare en privégerichte workloads.
Veel organisaties maken afzonderlijke beheergroepen voor SDLC-omgevingen (Workload Software Development Lifecycle) om beleidsregels en controles toe te wijzen. In de praktijk creëert deze methode meer uitdagingen voor workloadteams dan deze oplost. SDLC-omgevingen mogen geen ander beleid hebben, dus we raden geen afzonderlijke beheergroepen aan.
Eigenaren van toepassingen kunnen de topologie of resourceconfiguratie van een workload wijzigen om te worden afgestemd op beleidsregels in meerdere SDLC-omgevingen die worden gepromoveerd. Deze methode verhoogt het risico. Regels die specifiek zijn voor elke omgeving, kunnen leiden tot een slechte ontwikkelervaring voor ontwikkelaars- en kwaliteitscontroleteams. Er kunnen zich ook problemen voordoen als een toepassing één set beveiligingsbeleidsregels heeft dat in één omgeving werkt en de toepassing later in de promotiecyclus wordt blootgesteld aan een andere set beleidsregels. Mogelijk moet u wijzigingen aanbrengen in een toepassing als de besturingselementen veranderen.
Om dit extra werk te voorkomen, maakt u consistent beleid tijdens de promotie van code in SDLC-omgevingen. U moet geen beleid maken voor elke omgeving, maar in plaats daarvan een consistente set bieden voor alle ontwikkelomgevingen, met uitzondering van sandbox-omgevingen.
Stel dat een organisatie een beleid definieert waarvoor opslagaccounts moeten worden geconfigureerd met specifieke firewallregels om inkomend verkeer van openbare netwerken te voorkomen. In plaats daarvan gebruiken de opslagaccounts privé-eindpunten in de Azure-landingszonenetwerken voor communicatie. Als de ontwikkelomgeving geen dergelijk beleid heeft, vindt het testen van de workload geen onjuiste configuratie van het opslagaccount dat openbare toegang toestaat. De testimplementaties werken in de ontwikkelomgeving en worden gecontroleerd. Wanneer de oplossing wordt gepromoveerd naar een andere omgeving met het beleid voor het opslagaccount, mislukt de implementatie vanwege het afgedwongen beleid.
Als gevolg hiervan moet het ontwikkelteam van de toepassing hun implementatie en architectuur opnieuw bewerken, nadat ze al aanzienlijke inspanningen hebben geïnvesteerd. In dit voorbeeld ziet u hoe verschillende beleidsregels in verschillende omgevingen problemen kunnen veroorzaken.
Notitie
In de volgende vergelijking ziet u waarom een afzonderlijke beheergroep voor elke omgeving of workload niet goed wordt geschaald: N-werkbelastingen x Z-beheergroepen = totaal aantal beheergroepen.
Als een organisatie 30 workloads heeft waarvoor elk een beheergroep en een onderliggende beheergroep nodig zijn voor ontwikkelings-, test- en productieomgevingen, blijft de organisatie over:
N = het aantal workloads/apps = 30
Z = het aantal beheergroepen voor de workload en omgevingen (1 voor de workload + 3 voor de omgevingen) = 4
N (30) x Z (4) = 120 totale beheergroepen
Eigenaren van toepassingen hebben mogelijk beleidsregels nodig om anders toe te passen op meerdere omgevingen. Toepassingseigenaren kunnen bijvoorbeeld back-upconfiguraties vereisen voor productieomgevingen, maar niet voor andere omgevingen.
Sommige beleidsregels kunnen worden ingeschakeld als controlebeleid op beheergroepsniveau. Toepassingsteams bepalen hoe het besturingselement moet worden geïmplementeerd. Deze methode voorkomt geen implementaties, maar zorgt voor bewustzijn en stelt toepassingsteams in staat om hun unieke behoeften te beheren. Ze kunnen vervolgens subniveaubeleid maken of deze vereisten opnemen in hun IaC-implementatiemodules (Infrastructure as Code).
In dit model voor gedeelde verantwoordelijkheid controleert het platformteam de procedures en beheert het toepassingsteam de implementatie. Dit model kan de flexibiliteit van implementaties verbeteren.
Platformoperators moeten samenwerken met elk toepassings- of serviceworkloadteam (eigenaren van landingszones) om inzicht te hebben in hun vereisten. De platformoperators kunnen abonnementen bieden op basis van de toepassingsvereisten en -plannen. De platformoperators kunnen ook besluiten om productlijnen aan te wijzen voor verschillende typen workloads, zodat ze processen en hulpprogramma's voor het maken van abonnementen kunnen bouwen op basis van algemene vereisten van teams voor toepassings- of serviceworkloads.
Scenario: workloads op basis van virtuele machines (VM's)
Vroege workloads in Azure-landingszones bestaan vaak uit Azure-VM's. U kunt deze workloads in Azure implementeren of migreren vanuit bestaande datacenters.
In plaats van VM's in meerdere omgevingen in één abonnement te implementeren, kunt u het volgende doen:
Stel abonnementen in voor elke toepassingsomgeving en plaats ze allemaal in dezelfde archetypebeheergroep.
Implementeer een virtueel netwerk voor elke toepassingsomgeving in het juiste abonnement. U kunt de grootte van het virtuele netwerk bepalen op basis van de grootte van de toepassingsomgeving.
Implementeer de VM's naar het juiste abonnement. VM's kunnen voor elke omgeving verschillende SKU's en verschillende beschikbaarheidsconfiguraties gebruiken, indien van toepassing.
Verschillende toepassingsomgevingsbronnen worden beveiligd door verschillende toegangsbeheer. Als toepassingsontwikkelaars implementatiepijplijnen instellen, kan de identiteit van elke pijplijn worden beperkt tot de omgeving. Deze configuratie helpt de omgevingen te beschermen tegen onbedoelde implementaties.
Scenario: Azure-app Service
Een workload met omgevingsabonnementen die App Service gebruiken, kan uitdagingen opleveren. Voor toepassingsontwikkelaars is het best practice om implementatiesites te gebruiken om wijzigingen en updates voor een web-app te beheren.
Deze functie kan echter alleen worden gebruikt met de app die zich in het App Service-plan bevindt, die slechts binnen één abonnement kan leven. Als de platformoperators verplicht stellen dat de eigenaren van toepassingen afzonderlijke abonnementen gebruiken voor ontwikkelings-, test- en productieomgevingen, is de levenscyclus van de toepassingsimplementatie mogelijk moeilijker te beheren.
In dit voorbeeld is de beste optie één abonnement voor de toepassing of serviceworkload. Toepassingseigenaren kunnen op rollen gebaseerd toegangsbeheer (RBAC) van Azure gebruiken met PIM op het niveau van de resourcegroep voor betere beveiliging.