Planera dina miljöer

8 minuter

Din Azure-egendom består av många komponenter, inklusive grundläggande konfiguration, organisationsomfattande resurser och inställningar samt programarbetsbelastningar. Du har förmodligen också spridit din egendom över flera miljöer, var och en med ett annat syfte.

I den här lektionen lär du dig om fördelarna med att konsekvent använda kod för all distribution och konfiguration. Sedan kan du överväga de nivåer av kontroll och automatisering som du kan tillämpa på var och en av dina miljöer. Du kan också tänka på hur dina ändringar går igenom varje steg i distributionsprocessen och vilka kontroller och typer av styrning som du behöver för att stödja den valda distributionsstrategin.

Definiera infrastrukturen som kod

Distribution och konfiguration av Azure omfattar mycket mer än program, virtuella datorer, lagringstjänster och nätverk. Till exempel är vart och ett av följande objekt en form av konfiguration, med motsvarande Azure-resurser:

Organisera dina resurser genom att skapa resursgrupper, prenumerationer och hanteringsgrupper.
Kontrollera hur dina andra resurser ska konfigureras genom att definiera och tillämpa Azure Policy-definitioner, initiativ och tilldelningar.
Tilldela roller så att användare, grupper och arbetsbelastningsidentiteter kan komma åt Azure-resurser.
Konfigurera övervakning, inklusive aviseringar, för att observera dina Azure-resurser och se till att de fungerar som förväntat.

När du börjar definiera infrastrukturen som kod kanske du inte känner till alla objekt som kan definieras i dina mallar eller definitioner. Men när användningen av automatisering mognar är det en bra idé att definiera allt om din miljö som kod. På så sätt kan du använda en konsekvent, testad och godkänd process för hela Din Azure-konfiguration. Och eftersom koden är versionshanterad och spårad på en Git-lagringsplats kan du granska hur din Azure-miljö har ändrats över tid. Du kan använda Git-lagringsplatsen för att spåra historiken för varje ändring.

Anta till exempel att du behöver konfigurera dina Azure Monitor-aviseringar. Först kanske du tror att det inte skulle vara meningsfullt att använda automatisering för att distribuera aviseringar. Men aviseringar är en viktig del av din Azure-konfiguration. Om en avisering inte har skapats korrekt kan du missa meddelanden om kritiska produktionsproblem. Genom att definiera dina aviseringar i kod:

Dina teammedlemmar kan granska aviseringarna och deras konfiguration.
Du kan distribuera aviseringarna till icke-produktionsmiljöer först så att du kan testa dem.
Du har fullständig spårning av ändringarna i Din Azure-konfiguration.

Miljöer

När du planerar att distribuera infrastrukturen automatiskt är det bra att lista ut de miljöer som du planerar att använda. Många organisationer har olika miljötyper, var och en med olika egenskaper. Till exempel:

Vissa miljöer kör produktionskod, medan andra kör icke-produktionsversioner av samma kod, kanske med olika konfigurationer.
Vissa miljöer är långlivade och är aldrig avsedda att tas bort. Andra är tillfälliga: skapas automatiskt och förstörs när de inte längre används.
Vissa miljöer används av infrastruktur- eller programvaruutvecklingsteamet. Andra används av ditt säkerhetsteam, eller till och med av ditt säljteam när det behöver demonstrera en produkt för potentiella kunder.

Tänk på de miljöer som leksaksföretaget kan använda för din webbplats:

Diagram som visar sekvensen av miljöer.

När du gör och genomför ändringar i ditt program eller din infrastruktur distribuerar pipelinen dina ändringar via en sekvens av icke-produktionsmiljöer: utveckling, test och mellanlagring. Du kan också ha manuella godkännandesteg på vissa platser så att definierade teammedlemmar kan verifiera konfigurationen eller titta på pipelineloggen innan distributionen fortsätter. Sedan distribuerar pipelinen dina ändringar till produktionsmiljön.

Förutom dessa miljöer har säljteamet en egen demomiljö som används för att prata med kunder. Säljteamet tar en kopia av produktionsmiljön för att skapa sin demomiljö. Dina säkerhets- och testteam skapar ibland tillfälliga kopior av produktionsmiljön för intrångstestning respektive prestandatestning.

Utvecklingsteamet har också en egen uppsättning miljöer. Den har sandbox-miljöer som utvecklingsteamets medlemmar kan använda när de utforskar nya funktioner eller experimenterar med Azure-tjänster. Utvecklingsteamet skapar även PR-granskningsmiljöer för varje GitHub-pull-begäran som den granskar och sammanfogar.

Kontrollerade miljöer

I vissa av dessa miljöer är det klokt att kräva en formell process för att granska och tillämpa ändringar. Miljöer av den här typen kallas kontrollerade miljöer. Produktionsmiljön bör alltid kontrolleras. Det är en bra idé att tillämpa kontroller på vissa icke-produktionsmiljöer också. På så sätt kan du se till att alla begränsningar som kontrollerna medför är väl förstådda och testade före produktionsdistributionen.

Däremot har okontrollerade miljöer inte många, eller några, formella kontroller. De kan ha samma kod och liknande konfiguration som dina andra miljöer, men de möjliggör fler experimenterings- och ad hoc-konfigurationsändringar. I en okontrollerad miljö kan användare få ändra konfigurationen med hjälp av Azure Portal eller genom att köra Azure CLI/Azure PowerShell-kommandon direkt. De kan också skapa resurser utan att använda organisationens godkända process. Ändringar som görs i okontrollerade miljöer måste samlas in i kod innan de kan börja tillämpas på kontrollerade miljöer som produktionsmiljön.

Kommentar

Ibland kan en miljö faktiskt representera flera fysiska miljöer eller distributioner. När du till exempel skapar tillfälliga miljöer för granskningar av pull-begäranden kan flera separata miljöer vara aktiva samtidigt eftersom teamet har flera pull-begäranden öppna. Men för att planera dina miljöer kan du betrakta dem som likvärdiga eftersom de har samma egenskaper och kontroller.

Efter några diskussioner med ditt team anger du vilka miljöer som är kontrollerade och okontrollerade. Du bestämmer också vem som äger varje miljö.

Miljönamn	beskrivning	Ägare	Livstid	Kontrollnivå
Utveckling	Integrerar ändringar från flera utvecklare i en enda miljö.	Driftteam	Långlivade	Styrd
Test	En miljö för att köra manuella och automatiserade tester mot ändringar.	Driftteam	Långlivade	Styrd
Mellanlagring	Den slutliga icke-produktionsmiljön där ändringar distribueras före produktion, med produktionsliknande konfiguration.	Driftteam	Långlivade	Styrd
Produktion	Kör dina produktionsarbetsbelastningar.	Driftteam	Långlivade	Styrd
Demo	Används av säljteamet för att demonstrera produkten för nya kunder.	Säljteamet	Långlivade	Okontrollerad
Prestandatest	Dynamiskt skapad som en dubblett av produktionsmiljön för att köra prestanda- och stresstester och sedan tas bort när testerna har slutförts.	Testteam	Kortlivade	Okontrollerad
Intrångstest	Skapas dynamiskt som en dubblett av produktionsmiljön för att köra intrångs- och säkerhetstester och tas sedan bort när testerna har slutförts.	Säkerhetsteamet	Kortlivade	Okontrollerad
PR-recensioner	Skapas dynamiskt för varje pull-begäran som en teammedlem skapar för att ändra programmet eller infrastrukturen. Miljön tas bort när pull-begäran stängs.	Utvecklingsteam	Kortlivade	Okontrollerad
Sandbox-miljö för utveckling	Skapad av medlemmar i utvecklingsteamet för att experimentera eller utforska och tas sedan bort när de inte längre behövs.	Utvecklingsteam	Kortlivade	Okontrollerad

Föregående lista över miljöer är bara ett exempel. I din egen organisation måste du bestämma vilka miljöer du använder, vilken livslängd de ska ha och vilken kontrollnivå varje miljö behöver.

Dricks

Det är mycket enklare att lint, testa och granska din infrastrukturkod när du tillämpar dessa processer tidigt i distributionerna i stället för att lägga till dem senare och behöva åtgärda massor av bruten kod.

På samma sätt är det mycket enklare att arbeta med säkerhetskontroller när de finns från början och när de också tillämpas på vissa av dina icke-produktionsmiljöer. På så sätt vänjer sig teamet vid att arbeta i en kontrollerad miljö.

Under utbildningsvägarna har vi introducerat några av dessa begrepp gradvis. Det är ofta en bra idé att lägga till dessa element i distributionsprocessen så tidigt som möjligt.

Isolering av varje miljö

Det är viktigt att separera var och en av dina miljöer och att göra dem självständiga när det är möjligt. Att använda dedikerade Azure-prenumerationer för varje miljö kan vara till hjälp, men du måste ändå vara noga med att hålla dina miljöer åtskilda.

Undvik att ansluta från en miljö till en annan. Peer-koppla till exempel inte en produktionsmiljös virtuella nätverk till en icke-produktionsmiljös virtuella nätverk. Om du gör det är det enkelt för någon att oavsiktligt ändra produktionsdata från en icke-produktionsmiljö eller att läcka känsliga produktionsdata till en icke-produktionsmiljö.

Kontroller och portar

När distributionsprocessen fortsätter bör den köra en serie kontroller för att öka ditt förtroende för distributionen. Du måste fastställa vilka kontroller som är meningsfulla för var och en av dina miljöer som distributionerna går igenom.

Exempel på infrastrukturkontroller är:

Kodgranskningar.
Distribution av din in-review-kod till tillfälliga miljöer och körning av automatiserade eller manuella tester mot miljöer.
Linting.
Preflight-validering.
Manuell testning.
Manuellt godkännande.
Automatiserad funktionstestning.
Automatiserad röktestning.
Väntar på hälsosignaler från en tidigare miljö innan du går vidare till nästa miljö.

Du kan köra några av dessa kontroller flera gånger i distributionsprocessen, till exempel för varje kontrollerad miljö.

Dricks

När du utformar distributionsprocessen anger du alla steg som du behöver utföra, oavsett hur liten eller uppenbar. Var så detaljerad som möjligt. Du kanske inte väljer att automatisera allt först, men genom att följa den här metoden kan du skapa en skiss för dina automatiserade distributionsprocesser i framtiden.

En grind är en automatiserad eller manuell kontroll som måste lyckas för att distributionen ska fortsätta.

Manuella åtgärder

Det är en bra idé att automatisera så många kontroller som möjligt under kodgransknings- och distributionsprocesserna. Din organisation kan dock kräva manuellt godkännande för distribution till produktion eller andra kontrollerade miljöer.

Om du använder manuella godkännandegrindar för distributioner följer du dessa rekommenderade metoder:

Definiera tydligt vem som får godkänna en distribution. Använd Microsoft Entra-grupper för att definiera godkännare i stället för att ange enskilda användare. Du kan enkelt ändra listan över godkännare i framtiden.
Ha en process för nöddistributioner. Planera vem som kan godkänna en distribution om de normala godkännarna inte är tillgängliga. En nödsituationsdistribution kan behöva ske mitt i natten eller under en semesterperiod.
Begränsa mänsklig inblandning till att bara godkänna eller avvisa en distribution. Undvik att kräva att människor kör någon av distributionsåtgärderna om det inte finns ett steg som du inte kan automatisera.

Kontroll

Azure tillhandahåller verktyg och funktioner som hjälper dig att styra din miljö, inklusive:

Azure Policy för att identifiera resurser som har konfigurerats på sätt som inte passar organisationens krav. Det kan också bidra till att förhindra att resurser skapas eller konfigureras om på ett sätt som gör att de inte uppfyller kraven.
Låser för att förhindra ändringar i eller borttagning av viktiga resurser.
Hanteringsgrupper som hjälper dig att organisera dina Azure-prenumerationer och konfigurera rollbaserad åtkomstkontroll och principer konsekvent i dina miljöer.
Azure Monitor för att registrera mått och loggar från dina resurser, presentera dem i instrumentpaneler och automatiskt varna dig när de avviker från dina förväntade värden.

När du skapar din Azure-egendom bör du överväga att använda Azure-landningszoner. Genom att använda en landningszon kan du skapa styrning i din miljö från början. Många landningszoner innehåller fördefinierade Bicep- och Terraform-filer som hjälper dig att konfigurera din miljö. Vi länkar till mer information i sammanfattningen.