Distribuera Azure-landningszoner
I den här artikeln beskrivs de alternativ som är tillgängliga för att distribuera plattforms- och programlandningszoner. Plattformslandningszoner tillhandahåller centraliserade tjänster som används av arbetsbelastningar. Programlandningszoner är miljöer som distribueras för själva arbetsbelastningarna.
Viktigt!
Mer information om definitioner och implementeringar av plattforms- och programlandningszoner finns i Vad är en Azure-landningszon? i Cloud Adoption Framework för Azure.
Den här artikeln beskriver distributionsalternativen för plattforms- och programlandningszoner.
Välj en plattformslandningszonmetod
Följande plattformsdistributionsalternativ tillhandahåller en åsiktsbaserad metod för att distribuera och använda den konceptuella arkitekturen för Azure-landningszonen enligt beskrivningen i Cloud Adoption Framework. Beroende på anpassningar kanske den resulterande arkitekturen inte är densamma för alla distributionsalternativ som anges här. Skillnaderna mellan plattformsdistributionsalternativen baseras på hur de använder olika tekniker, använder olika metoder och anpassas på olika sätt.
Standarddistributionsalternativen
Standarddistributionsalternativen hanterar typisk azure-användning för företag.
| Distributionsalternativ för Azure-plattformens landningszon | beskrivning |
|---|---|
| Distribution av Azure-portalen | En Azure-portalbaserad distribution som ger en fullständig implementering av den konceptuella arkitekturen för Azure-landningszonen, tillsammans med åsiktsbaserade konfigurationer för viktiga komponenter, till exempel hanteringsgrupper och principer. |
| Bicep-utplacering | En modulär, infrastruktur-som-kod-baserad distribution där varje Bicep-modul kapslar in en kärnfunktion i den konceptuella arkitekturen Azure-landningszonen. Även om modulerna kan distribueras individuellt föreslår designen användning av orchestrator-moduler för att kapsla in komplexiteten i att distribuera olika topologier med modulerna. Bicep-distribution stöder offentliga Azure-moln, Azure China 21Vianet-regioner och Azure US Government-moln. |
| Terraform-distribution | Den här infrastruktur-som-kod-baserade distributionen med hjälp av Azure-verifierade moduler för plattformslandningszoner ger ett anpassningsbart sätt att distribuera ALZ med Terraform. |
Varianter och specialiseringar
Även om de standardalternativen för plattformsdistribution hanterar typisk Azure-användning för företag, finns det vissa distributionsalternativ som fokuserar på specifika specialiseringar.
| Distributionsalternativ | beskrivning |
|---|---|
| Nationell landningszon | Den suveräna landningszonen är en variant av de Azure-landningszoner som är avsedda för organisationer som behöver avancerade suveräna kontroller. |
Partnerimplementeringar
Partnerprogram som Azure Migrate och Modernisera kan hjälpa dig att utforma och implementera din plattforms landningszon som är specifik för organisationens behov. Dessa implementeringar börjar med den konceptuella arkitekturen i Azure-landningszonen och hjälper dig att utforma konfigurationer som är specifika för din molnimplementeringsstrategi, organisationstopologi och önskade resultat.
Företagsprincip som kod (EPAC) för principhantering
Företagspolicy som kod (EPAC) är en alternativ metod för att distribuera, hantera och använda Azure Policy i organisationens Azure-miljö. Du kan använda EPAC i stället för standardplattformsalternativ för att hantera principerna i en Azure-landningszonmiljö. Mer information om integreringsmetoden finns i Integrera EPAC med Azure-landningszoner.
Företagspolicy som kod passar bäst för mer avancerade och mogna DevOps- och infrastruktur-som-kod-kunder. Kunder av valfri storlek kan dock använda EPAC om de vill när de har utvärderat det. För att säkerställa att du är justerad, se först Vem ska använda EPAC?.
Kommentar
Jämför livscykeln och flexibiliteten för de två metoderna innan du bestämmer dig för vilken metod du använder på lång sikt. Börja med att utvärdera den interna principhantering som tillhandahålls i standardimplementeringen som beskrivs i standardplattformsalternativ. Om implementeringen inte verkar vara idealisk för dina styrningsbehov kan du utföra en MVP eller ett konceptbevis med hjälp av EPAC. Det är viktigt att du jämför alternativ, validerar och bekräftar ditt val innan du implementerar en metod, eftersom det är en komplex process att ändra metoder för principstyrning när den väl har upprättats.
Använda Azure-landningszoner
När du har distribuerat plattformslandningszonen måste du driva och underhålla den. Mer information finns i vägledningen om hur du håller din Azure-landningszon uppdaterad.
Visualiserare för Azure-styrning
Azure Governance Visualizer är avsedd att hjälpa dig att få en holistisk översikt över din tekniska Azure-styrningsimplementering genom att ansluta punkterna och tillhandahålla avancerade rapporter.
Prenumerationsautomater
När plattformens landningszon och styrningsstrategi är på plats är nästa steg att etablera enhetlighet i hur prenumerationer skapas och tas i bruk för de ansvariga för arbetsbelastningen. Prenumerationsdemokratisering är en designprincip för Azure-landningszoner som använder prenumerationer som hanteringsenheter och skalningsenheter. Den här metoden påskyndar programmigreringar och ny programutveckling.
Prenumerationshantering standardiserar den process som plattformsteam använder för att arbetslag ska kunna begära prenumerationer samt för att plattformsteam ska kunna distribuera och styra dessa prenumerationer. Det gör det möjligt för programteam att få åtkomst till Azure med en konsekvent och styrd metod, vilket säkerställer att kravinsamlingen är klar.
Det är också vanligt att organisationer har flera olika typer av prenumerationer som kan skickas till deras klientorganisation, vilket ofta kallas "produktlinjer" i branschen. Se Upprätta vanliga produktrader för prenumerationsautomater för rekommenderade "produktlinjer" för din organisation.
Kom igång genom att följa vägledningen för implementering av prenumerationsförsäljning i . Granska sedan följande moduler för infrastruktur som kod, vilket ger flexibilitet för att passa dina implementeringsbehov.
| Distributionsalternativ | beskrivning |
|---|---|
| Bicep prenumerationsförsäljning | Bicep-modulerna för prenumerationshantering är utformade för att samordna distributionen av de enskilda programlandningszonerna, baserat på konfigurationen för respektive arbetsbelastning. De kan köras manuellt eller som en del av automatiseringen. |
| Terraform prenumerationsförsäljning | Dessa moduler använder Terraform för att samordna distributionen av de enskilda programlandningszonerna. |
Arkitekturer för programlandningszoner
Programlandningszoner består av en eller flera prenumerationer som distribueras som godkända mål för programteamägda resurser i en arbetsbelastning. En arbetsbelastning kan dra nytta av tjänster som distribueras i plattformslandningszoner eller isoleras från dessa centraliserade resurser. Programlandningszonerna ska användas för centralt hanterade program, decentraliserade arbetsbelastningar som ägs av programteam och centralt hanterade värdplattformar som Azure Kubernetes Service (AKS) som kan vara värd för program för flera affärsenheter. Om de inte tvingas av onormala begränsningar innehåller prenumerationer i programlandningszonen endast resurser från en enda arbetsbelastning eller en logisk programgräns, till exempel dess livscykel eller dess klassificering av kritiskhet.
Arbetsbelastningsteam kommunicerar sina arbetsbelastningskrav genom en formell process som upprättats av plattformsteamet. Plattformsteamet distribuerar vanligtvis en tom prenumeration som innehåller all nödvändig styrning. En arbetsbelastningsarkitekt utformar sedan en lösning som fungerar inom begränsningarna för den programlandningszonen och drar nytta av delade plattformsfunktioner (till exempel brandväggar och routning mellan premisis), där det är praktiskt.
Det är möjligt att en arkitekt kan anpassa en referensarkitektur som inte är särskilt utformad med en programlandningszon i åtanke. Microsoft Learn innehåller dock också vägledning för applikations- och dataplattformar för team som arbetar med arbetsbelastning och specifikt hanterar kontexter för applikationslandningszoner. Plattformsteam bör informeras om den vägledning som är tillgänglig för arbetsbelastningsteam så att plattformsteamet kan förutse de arbetsbelastningstyper och egenskaper som kan finnas i organisationen.
| Arkitektur för applikationslandningszon | beskrivning |
|---|---|
| Azure App Service-miljö | Beprövade rekommendationer och överväganden för användningsfall för både multitenant- och App Service-miljöer med en referensimplementering. |
| Azure API Management (APIM) | Beprövade rekommendationer och överväganden för att distribuera en intern API Management-instans som en del av en referensimplementering. Scenariot använder Azure Application Gateway för att tillhandahålla säker ingresskontroll och använder Azure Functions som serverdel. |
| Azure Arc för hybrid- och multimolnscenarier | Azure Arc-aktiverade servrar, Kubernetes och Azure Arc-aktiverad SQL Managed Instance. |
| Azure Container Apps | Den här vägledningen för Azure Container Apps beskriver den strategiska designvägen och definierar det tekniska måltillståndet för distribution av Azure Container Apps. Ett dedikerat arbetsbelastningsteam äger och driver den här plattformen. |
| Azure Data Factory | Lär dig hur du tar en traditionell medallion lakehouse och hostar den i en applikationslandningszon. |
| Azure OpenAI-chattarbetsbelastning | Beskriver hur du integrerar ett typiskt Azure OpenAI-chattprogram i Azure-landningszoner för att använda centraliserade delade resurser samtidigt som du följer styrning och kostnadseffektivitet, vilket ger vägledning för arbetsbelastningsteam om distribution och hantering. |
| Azure Kubernetes Service (AKS) | Vägledning och relaterade kodmallar för infrastruktur som representerar den strategiska designväg och det måltekniska tillståndet för en AKS-distribution som körs i en programlandningszon. |
| Azure Red Hat OpenShift | En samling Terraform-mallar med öppen källkod som representerar en optimal Azure Red Hat OpenShift-distribution som innehåller Azure- och Red Hat-resurser. |
| Azure Synapse Analytics | En arkitekturmetod för att förbereda programlandningszoner för en typisk företagsdistribution av Azure Synapse Analytics. |
| Azure Virtual Desktop | ARM-, Bicep- och Terraform-mallar som ska refereras när du utformar Azure Virtual Desktop-distributioner, inklusive skapande av värdpooler, nätverk, lagring, övervakning och tillägg. |
| Azure Virtual Machines | Den här arkitekturen utökar vägledningen från baslinjearkitekturen för virtuella Azure-datorer (VM) till en programlandningszon, med vägledning om prenumerationskonfiguration, korrigeringsefterlevnad och andra problem med organisationsstyrning. |
| Azure VMware Solution | ARM-, Bicep- och Terraform-mallar som är användbara när du utformar VMware-distributioner, inklusive privata Moln för Azure VMware Solution, jump box, nätverk, övervakning och tillägg. |
| Citrix på Azure | Designriktlinjer för Cloud Adoption Framework för Citrix Cloud i en landningszon i Azure i företagsskala täcker många designområden. |
| Red Hat Enterprise Linux (RHEL) på Azure | Landningszonen för Red Hat Enterprise Linux (RHEL) i Azure är en samling arkitekturvägledning och referensimplementeringsrekommendationer med öppen källkod som används för att utforma RHEL-baserade arbetsbelastningar på Microsoft Azure. |
| HPC-arbetsbelastningar (High Performance Compute) | En HPC-klusterlösning från slutpunkt till slutpunkt i Azure som använder verktyg som Terraform, Ansible och Packer. Den hanterar metodtips för Azure-landningszoner, inklusive implementering av identitet, åtkomst till jump box och autoskalning. |
| Verksamhetskritiska arbetsbelastningar | Adresserar hur en arbetsbelastning som klassificeras som verksamhetskritisk ska utformas för att köras inom en programlandningszon. |
| SAP-arbetsbelastningar | Ger vägledning och rekommendationer för SAP-arbetsbelastningar som följer bästa praxis för Azure-landningszoner. Ger rekommendationer för att skapa infrastrukturkomponenter som beräkning, nätverk, lagring, övervakning och bygge av SAP-system. |
Arbetsbelastningar är ofta en samling olika tekniker och klassificeringar. Vi rekommenderar att du granskar relaterat referensmaterial för alla tekniker i din arbetsbelastning. Till exempel är det viktigt att förstå vägledningen från Azure OpenAI-chatten och Azure API Management för att förstå om ditt generativa AI-scenario skulle ha nytta av att lägga till en API-gateway.