Planlæg dine miljøer

Fuldført

Din Azure-ejendom består af mange komponenter, herunder grundlæggende konfiguration, ressourcer og indstillinger for hele organisationen og arbejdsbelastninger for programmer. Du har sandsynligvis også spredt din ejendom på tværs af flere miljøer, hver med et andet formål.

I dette undermodul får du mere at vide om fordelen ved konsekvent at bruge kode til hele udrulningen og konfigurationen. Derefter skal du overveje de niveauer af kontrol og automatisering, som du kan anvende på hvert af dine miljøer. Du kan også overveje, hvordan dine ændringer skrider frem i hver fase i installationsprocessen, og hvilke kontrolelementer og typer af styring du skal bruge for at understøtte din valgte udrulningsstrategi.

Definer din infrastruktur som kode

Azure-udrulning og -konfiguration dækker langt mere end programmer, virtuelle maskiner, lagertjenester og netværk. Hvert af følgende elementer er f.eks. en form for konfiguration med tilsvarende Azure-ressourcer:

• Organisering af dine ressourcer ved at oprette ressourcegrupper, abonnementer og administrationsgrupper.
• Styring af, hvordan dine andre ressourcer skal konfigureres, ved at definere og anvende Azure Policy-definitioner, -initiativer og -tildelinger.
• Tildeling af roller for at give brugere, grupper og arbejdsbelastningsidentiteter adgang til Azure-ressourcer.
• Konfiguration af overvågning, herunder beskeder, for at overvåge dine Azure-ressourcer og sikre, at de fungerer på den måde, du forventer.

Når du først begynder at definere din infrastruktur som kode, er du muligvis ikke opmærksom på alle de elementer, der kan defineres i dine skabeloner eller definitioner. Men efterhånden som din brug af automatisering modnes, er det en god idé at definere alt om dit miljø som kode. Ved at gøre dette kan du bruge en ensartet, testet og godkendt proces til alle af din Azure-konfiguration. Og da koden er versionsstyring og spores i et Git-lager, kan du gennemse, hvordan dit Azure-miljø er blevet ændret over tid. Du kan bruge Git-lageret til at spore historikken for hver ændring.

Lad os f.eks. antage, at du skal konfigurere dine Azure Monitor-beskeder. I første omgang tror du måske, at det ikke giver mening at bruge automatisering til at udrulle beskeder. Men beskeder er en vigtig del af din Azure-konfiguration. Hvis en besked ikke oprettes korrekt, kan du gå glip af meddelelser om kritiske produktionsproblemer. Ved at definere dine beskeder i kode:

• Dine teammedlemmer kan gennemse beskederne og deres konfiguration.
• Du kan udrulle beskederne til ikke-produktionsmiljøer først, så du kan teste dem.
• Du har fuld sporing af ændringerne i din Azure-konfiguration.

Miljøer

Når du planlægger at udrulle din infrastruktur automatisk, er det nyttigt at angive de miljøer, du planlægger at bruge. Mange organisationer har forskellige miljøtyper, der hver især har forskellige egenskaber. For eksempel:

• Nogle miljøer kører produktionskode, mens andre kører ikke-produktionsversioner af den samme kode, måske med forskellige konfigurationer.
• Nogle miljøer har en lang levetid og er aldrig beregnet til at blive slettet. Andre er flygtighed: oprettes automatisk og destrueres, når de ikke længere bruges.
• Nogle miljøer bruges af infrastruktur- eller softwareudviklingsteamet. Andre bruges af dit sikkerhedsteam eller endda af dit salgsteam, når det skal demonstrere et produkt for potentielle kunder.

Overvej de miljøer, som dit legetøjsfirma kan bruge til dit websted:

Når du foretager og bekræfter ændringer af dit program eller din infrastruktur, udruller din pipeline dine ændringer via en række ikke-produktionsmiljøer: udvikling, test og midlertidig lagring. Du har muligvis også manuelle godkendelsestrin på visse punkter, så definerede teammedlemmer kan bekræfte konfigurationen eller se på pipelineloggen, før udrulningen fortsætter. Derefter udruller din pipeline dine ændringer i dit produktionsmiljø.

Ud over disse miljøer har dit salgsteam sit eget demo- miljø, som det bruger til at tale med kunder. Salgsteamet tager en kopi af produktionsmiljøet for at oprette demomiljøet. Dine sikkerheds- og testteams opretter lejlighedsvis midlertidige kopier af produktionsmiljøet til henholdsvis indtrængningstest og test af ydeevne.

Dit udviklingsteam har også sine egne sæt miljøer. Den har sandkasser, som medlemmer af udviklingsteamet kan bruge, når de udforsker nye funktioner eller eksperimenterer med Azure-tjenester. Udviklingsteamet opretter også miljøer til gennemsyn af pullanmodninger for hver GitHub-pullanmodning, som den gennemser og fletter.

Kontrollerede miljøer

I nogle af disse miljøer giver det mening at kræve en formel proces for at gennemse og anvende ændringer. Miljøer af denne type kaldes kontrollerede miljøer. Produktionsmiljøet skal altid styres. Det er også en god idé at anvende kontrolelementer på nogle af de ikke-produktionsmiljøer. På denne måde kan du sikre, at alle begrænsninger, som kontrolelementerne pålægger, forstås og testes godt før produktionsudrulningen.

I modsætning hertil har ukontrollerede miljøer, ikke har mange eller nogen formelle kontrolelementer. De kan have den samme kode og samme konfiguration som dine andre miljøer, men de giver mulighed for flere eksperimentering og ændringer af ad hoc-konfiguration. I et ukontrolleret miljø kan brugerne få tilladelse til at ændre konfigurationen ved hjælp af Azure Portal eller ved at køre Azure CLI/Azure PowerShell-kommandoer direkte. De kan muligvis også oprette ressourcer uden at bruge organisationens godkendte proces. Ændringer, der foretages i ukontrollerede miljøer, skal registreres i kode, før de kan begynde at blive anvendt på kontrollerede miljøer, f.eks. produktionsmiljøet.

Seddel

Nogle gange kan et miljø faktisk repræsentere flere fysiske miljøer eller udrulninger. Når du f.eks. opretter flygtighedsmiljøer til pullanmodningsgennemgange, kan flere separate miljøer være aktive på samme tid, fordi dit team har flere åbne pullanmodninger. Men med henblik på planlægning af dine miljøer kan du betragte dem som ækvivalente, fordi de har de samme egenskaber og kontrolelementer.

Efter nogle diskussioner med dit team angiver du, hvilke miljøer der styres og ikke kontrolleres. Du bestemmer også, hvem der ejer hvert miljø.

Miljønavn	Beskrivelse	Ejer	Levetid	Kontrolniveau
Udvikling	Integrerer ændringer fra flere udviklere i et enkelt miljø.	Operationsteam	Længe levet	Kontrolleret
Test	Et miljø til kørsel af manuelle og automatiserede test mod ændringer.	Operationsteam	Længe levet	Kontrolleret
Midlertidige	Det endelige ikke-produktionsmiljø, hvor ændringer udrulles før produktion, med produktionslignende konfiguration.	Operationsteam	Længe levet	Kontrolleret
Produktion	Kører dine produktionsarbejdsbelastninger.	Operationsteam	Længe levet	Kontrolleret
Demo	Bruges af salgsteamet til at demonstrere produktet over for nye kunder.	Salgsteam	Længe levet	Ukontrolleret
Test af ydeevne	Dynamisk oprettet som en dublet af produktionsmiljøet til kørsel af ydeevne- og stresstest og slettes derefter, når testene er fuldført.	Testteam	Kortlivet	Ukontrolleret
Indtrængningstest	Dynamisk oprettet som en dublet af produktionsmiljøet til kørsel af indtrængnings- og sikkerhedstests og slettes derefter, når testene er fuldført.	Sikkerhedsteam	Kortlivet	Ukontrolleret
Anmeldelser af pullanmodninger	Dynamisk oprettet for hver pullanmodning, som et teammedlem opretter for at ændre programmet eller infrastrukturen. Miljøet slettes, når pullanmodningen lukkes.	Udviklingsteam	Kortlivet	Ukontrolleret
Sandkasser til udvikling	Oprettet af medlemmer af udviklingsteamet for at eksperimentere eller udforske og derefter slette, når det ikke længere er nødvendigt.	Udviklingsteam	Kortlivet	Ukontrolleret

Den foregående liste over miljøer er blot et eksempel. I din egen organisation skal du beslutte, hvilke miljøer du bruger, hvad deres levetid skal være, og hvilket niveau af kontrol hvert miljø har brug for.

Drikkepenge

Det er meget nemmere at sammentrække, teste og gennemse din infrastrukturkode, når du anvender disse processer tidligt i dine udrulninger i stedet for at tilføje dem senere og skulle rette en masse ødelagt kode.

På samme måde er det meget nemmere at arbejde med sikkerhedskontrolelementer, når de er til stede fra starten, og når de også anvendes på nogle af dine ikke-produktionsmiljøer. På den måde vænner dit team sig til at arbejde i et kontrolleret miljø.

Gennem læringsforløbene har vi introduceret nogle af disse begreber gradvist. Det er ofte en god idé at føje disse elementer til din udrulningsproces så tidligt som muligt.

Isolation af hvert miljø

Det er vigtigt at adskille hvert af dine miljøer og gøre dem selvstændige, hvor det er muligt. Brug af dedikerede Azure-abonnementer til hvert miljø kan hjælpe, men du skal stadig være forsigtig med at holde dine miljøer adskilt.

Undgå at oprette forbindelse fra ét miljø til et andet. Du skal f.eks. ikke sidestille et produktionsmiljøs virtuelle netværk med et virtuelt netværk for et ikke-produktionsmiljø. Hvis du gør det, er det nemt for nogen ved et uheld at ændre produktionsdata fra et ikke-produktionsmiljø eller at lække følsomme produktionsdata til et ikke-produktionsmiljø.

Kontrol og porte

Efterhånden som udrulningsprocessen fortsætter, bør den køre en række kontroller for at øge din tillid til installationen. Du skal finde ud af, hvilke kontroller der giver mening for hvert af dine miljøer, som dine udrulninger skrider frem i.

Kontrollen af infrastrukturen omfatter ofte:

• Kodegennemgange.
• Udrulning af din korrekturkode i flygtighedsmiljøer og kørsel af automatiserede eller manuelle test mod miljøerne.
• Linting.
• Validering af forhåndskontrol.
• Manuel test.
• Manuel godkendelse.
• Automatiseret funktionstest.
• Automatiseret røgtest.
• Venter på tilstandssignaler fra et tidligere miljø, før du går videre til det næste miljø.

Du kan køre nogle af disse kontroller flere gange i installationsprocessen, f.eks. for hvert kontrolleret miljø.

Drikkepenge

Når du designer din udrulningsproces, skal du angive alle de trin, du skal udføre, uanset hvor lille eller indlysende. Vær så detaljeret som muligt. Du vælger muligvis ikke at automatisere alt i starten, men hvis du følger denne fremgangsmåde, kan du oprette en kursusplan for dine automatiserede udrulningsprocesser i fremtiden.

En port er en automatiseret eller manuel kontrol, der skal lykkes, for at installationen kan fortsætte.

Manuel indgriben

Det er en god idé at automatisere så mange kontroller som muligt under din kodegennemgang og udrulningsprocesser. Din organisation kan dog kræve manuel godkendelse til udrulning til produktion eller andre kontrollerede miljøer.

Hvis du bruger manuelle godkendelsesporte til udrulninger, skal du følge disse anbefalede fremgangsmåder:

• Definer tydeligt, hvem der har tilladelse til at godkende en udrulning. Brug Microsoft Entra-grupper til at definere godkendere i stedet for at angive individuelle brugere. Du kan nemt ændre listen over godkendere i fremtiden.
• Hav en proces til udrulninger i nødstilfælde. Planlæg, hvem der kan godkende en udrulning, hvis de normale godkendere ikke er tilgængelige. En nødudrulning kan være nødvendigt at ske midt om natten eller i en ferieperiode.
• Begræns menneskelig indgriben til kun at godkende eller afvise en udrulning. Undgå at kræve, at mennesker kører nogen af udrulningshandlingerne, medmindre der er et trin, som du ikke kan automatisere.

Styreformer

Azure indeholder værktøjer og funktioner, der kan hjælpe dig med at styre dit miljø, herunder:

• Azure Policy til at registrere ressourcer, der er konfigureret på måder, der ikke passer til organisationens krav. Det kan også hjælpe med at forhindre, at ressourcer oprettes eller omkonfigureres på en måde, der medfører, at de ikke overholder angivne standarder.
• Låser for at forhindre ændringer i eller sletning af vigtige ressourcer.
• Administrationsgrupper, der hjælper dig med at organisere dine Azure-abonnementer og konfigurere rollebaseret adgangskontrol og politikker på en ensartet måde på tværs af dine miljøer.
• Azure Monitor til at registrere målepunkter og logge fra dine ressourcer, præsentere dem i dashboards og automatisk advare dig, når de afviger fra dine forventede værdier.

Når du bygger din Azure-ejendom, kan du overveje at bruge Azure-landingszoner. Ved hjælp af en landingszone kan du bygge styring i dit miljø fra starten. Mange landingszoner omfatter færdigbyggede Bicep- og Terraform-filer, der kan hjælpe dig med at konfigurere dit miljø. Vi linker til flere oplysninger i oversigten.