Genom att modularisera hanteringen av dina Azure Resource Manager-mallar (ARM-mallar) kan du minska upprepningen, modellera metodtips för infrastrukturutveckling och ha konsekventa standarddistributioner.
Ett exempel på användningsfall för att implementera den här typen av modularisering är distribution av virtuella datorer med hjälp av metaforen för t-shirtstorlekar. Anta att du har distribuerat dussintals eller hundratals virtuella datorer. Dessa distributioner använder version 1.0.0 av dina mallar och har en medelstor standardstorlek för en äldre serie. För att övergå till en ny serie kan det kräva ett kort avbrott i tjänsten om du bara har distribuerat nya mallar. Men genom att skapa version 1.5.0 och använda modularisering kan du distribuera ny infrastruktur med den uppdaterade standarden samtidigt som den gamla infrastrukturen hålls i ett distributionsbart tillstånd. Genom att ha gamla versioner av infrastrukturen tillgängliga har dina produkt- och programteam en känd bra konfiguration att förlita sig på när de uppgraderar till den nya versionen eftersom de har tid.
Lagerkakan för lagringsplatser: Ett exempel för företag
När det gäller varför du kanske vill ha en stark inställning för vart dina mallar ska gå, hur de uppdateras och så vidare finns det två huvudsakliga överväganden: förgrening och innersourcing.
Förgrening. Det här exempelscenariot underlättar git-förgreningsmodeller som stöder Gitflow - och GitHub-flöde. Mer information om Gitflow finns i Använda git-flow för att automatisera ditt git-förgreningsarbetsflöde, ett blogginlägg av Jeff Kreeftmeijer. Mer information om GitHub-flödet finns i GitHub-flödet i GitHub-dokumentationen.
Innersourcing. Den andra är innersourcing, som ger samarbetsmetoderna för utveckling av programvara med öppen källkod till intern utveckling. I ett sådant scenario kan du mer säkert dela olika mallar och modulkällkod utan att nödvändigtvis behöva oroa dig för behörigheter för själva distributionsmodellerna. Mer information om utveckling av inre källor finns i En introduktion till innersource på GitHub,
Bicep är ett deklarativt språk för att distribuera Azure-resurser. Biceps återanvändbara kod kan använda Azure Container Registry som ett privat register som värd för versionshanterade ARM-mallar. Genom att använda Container Registry på det här sättet kan företaget ha en process för kontinuerlig integrering och kontinuerlig leverans (CI/CD) för infrastruktur. Du kan köra integrerings- och enhetstester som en del av CI-processen, och containerregistret kan ta emot moduler när de har skapats. Appteam kan fortsätta att använda äldre versioner tills de är redo att uppgradera, eller så kan de uppdatera för att dra nytta av funktioner i de nyare versionerna av mallar.
Utöver den här användningen av Container Registry kan du kombinera den här modellen med något som liknar Azure-verifierade moduler. Implementeringen kan förbrukas från det offentliga registret, eller helst övervaka de offentliga lagringsplatserna och hämta ändringar i det privata registret för vidare användning. Genom att hämta ändringar i ditt eget containerregister kan du köra tester mot offentliga moduler samtidigt som du ser till att de inte används i produktion förrän kvalitets- och säkerhetspraxis har införlivats.
Skikt
Den modell som föreslås i det här exempelscenariot är en som staplar. Lager som ligger närmare toppen av stacken har mer frekventa distributioner och distributioner som är mer skräddarsydda. Bicep-kod ger konsekventa distributioner. Utvecklingsteam, som arbetar i lagren för sina bidrag, bygger från de tjänster och den infrastruktur som tillhandahålls i lagren nedan. Ingenting i ett lägre lager bör förlita sig på resurser i ett lager ovan. Från lager 0 till 3 är globalt bibliotek, global infrastruktur (globalt delade tjänster), produktplattform (delade tjänster) och program.
Den här modellen skapar autonomi med anpassning, vilket innebär att ha:
Vanliga verktyg för att underlätta företag. Alla använder till exempel git för källkontroll och alla använder GitHub Actions för CI/CD. Men vi går inte för långt. Vi kräver till exempel inte att alla team använder Bicep; De kan använda Terraform, ARM-mallar och andra verktyg.
Möjligheten att dela metodtips. De kan ha formen av ARM-mallar, gyllene bilder eller kodfragment. Metodtips kan också vara dokumentation om specifika tekniker. Till exempel hur du roterar nycklar i din miljö och hur du testar kod.
Vissa tjänster flyttas nedåt i stacken. Ett appteam kan till exempel först utveckla en mall för att distribuera ett Kubernetes-kluster, som senare hämtas till produktplattformen som en delad tjänst. Den här mallen blir så användbar att den hämtas till exempelbiblioteket.
Layer 0 – Globalt bibliotek
Det nedre lagret är det globala biblioteket, som är en lagringsplats med användbara godbitar som inte distribueras till produktion. När det gäller åtkomstkontroll bör läsåtkomst ges till alla på företaget som begär det. För ändringar, förslag och så vidare godkänner din CCoE (Cloud Center of Excellence) PR:er och hanterar en kvarvarande information som om detta vore någon annan produkt.
Layer 0 får inte innehålla:
- Mallar som distribueras i produktion.
- Hemligheter eller miljöspecifika konfigurationer.
Layer 0 ska innehålla:
- Kodfragment (i Python, C# och så vidare).
- Azure Policy-exempel.
- ARM-mallar, Bicep-mallar eller Terraform-filer som kan användas som exempel.
Ett exempel på detta är en exempelarkitektur för hur ditt företag skulle skriva en distribution för ett program med tre nivåer utan någon miljöspecifik information. Den här exempelarkitekturen kan innehålla taggar, nätverk, nätverkssäkerhetsgrupper och så vidare. Att utelämna specifik information för miljön är användbart, eftersom inte allt kan vara eller behöver placeras i en modul. Om du försöker göra det kan det leda till överparameterisering.
Dessutom kan Layer 0 länka till andra kända bra källor till exempelkod, till exempel Terraform Registry eller Azure Resource Modules. Om din organisation antar kod eller ett mönster från någon av dessa källor rekommenderar vi att du hämtar koden eller mönstret till din egen Layer 0 i stället för att hämta direkt från de offentliga källorna. Genom att förlita dig på layer 0 kan du skriva egna tester, justeringar och säkerhetskonfigurationer. Genom att inte förlita dig på offentliga källor minskar du risken för att förlita dig på något som oväntat kan tas bort.
För att betraktas som bra exempelkod bör dina mallar och moduler följa goda utvecklingsmetoder, inklusive indatavalidering för säkerhet och för organisationens krav. För att upprätthålla den här nivån av stränghet bör du lägga till principer i huvudgrenen för att kräva pull-begäranden (PR) och kodgranskningar för föreslagna ändringar som skulle resultera i ändringar som flödar till huvudcontainerregistret om de sammanfogas.
Layer 0 matas in i Azure Pipelines eller GitHub Actions för att automatiskt skapa versionshanterade artefakter i Azure Container Registry. Du kan skapa automatisering för git-incheckningsmeddelanden för att implementera semantisk versionshantering av artefakterna. För att detta ska fungera korrekt måste du ha en deterministisk namngivningsstandard, till exempel <service.bicep>, för att automatiseringen ska kunna underhållas över tid. Med rätt grenprinciper kan du också lägga till integreringstester som en förutsättning för kodgranskningar. Du kan instrumentera detta med hjälp av verktyg som Pester.
Med sådana principer och skydd på plats kan containerregistret vara sanningskällan för alla infrastrukturmoduler i företaget som är redo att användas. Du bör överväga att standardisera ändringsloggar samt index för tillgängliga kodexempel för att möjliggöra identifiering av den här koden. Okänd kod är oanvänd kod!
Layer 1 – Global infrastruktur: Globalt delade tjänster
Layer 1 är lagringsplatsen för dina Konstruktioner av Azure-landningszoner. Microsoft tillhandahåller mallar för distribution av Azure-landningszoner, men du vill ändra vissa komponenter och ange en parameterfil. Detta motsvarar hur du hämtar offentliga register- och modullagringsplatser till Layer 0, enligt beskrivningen tidigare.
Azure Container Registry är en viktig del av den här arkitekturen. Även om företaget inte har några planer på att använda containrar måste du distribuera Container Registry för att lyckas med versionshantering av Bicep-mallar. Container Registry ger stor flexibilitet och återanvändning för dina moduler samtidigt som du ger säkerhet och åtkomstkontroll i företagsklass.
Lager 1 ska innehålla:
- Principtilldelningar och definitioner som tillämpas på hanteringsgrupps- eller prenumerationsnivå. Dessa principer bör matcha företagets styrningskrav.
- Mallar för kärnnätverksinfrastruktur, till exempel ExpressRoute, VPN, virtual WAN och virtuella nätverk (delad eller hubb).
- DNS.
- Kärnövervakning (log analytics).
- Företagscontainerregister.
Du bör konfigurera grenskydd för att begränsa möjligheten att skicka ändringar till den här lagringsplatsen. Begränsa godkännande av PR:er från andra utvecklare till medlemmar i CCoE eller molnstyrning. Deltagare i det här lagret är främst medlemmar i grupper som är historiskt associerade med komponenterna i det här lagret. Nätverksteamet skapar till exempel mallarna för nätverket, driftteamet konfigurerar övervakning och så vidare. Du bör dock bevilja skrivskyddad åtkomst till personer som begär det, eftersom du vill göra det möjligt för utvecklare från andra grupper att föreslå ändringar i kärninfrastrukturerna. De kan bidra med förbättringar, men du tillåter inte att ändringarna sammanfogas utan godkännande och testning.
Dessa filer bör använda modulerna i containerregistret för standardkomponenter. Men du har också en Bicep-fil, eller en serie Bicep-filer, som är anpassade till företagets implementering av Azure-landningszoner eller en liknande styrningsstruktur.
Layer 2 – Produktplattform: Delade tjänster
Du kan betrakta Layer 2, produktplattform, som delade tjänster för en viss produktrad eller affärsenhet. De här komponenterna är inte universella i hela organisationen, men de är avsedda att passa ett visst affärsbehov. Detta skulle vara ett lämpligt lager för ett virtuellt nätverk som är en peer med hubben i den globala infrastrukturen layer 1. Ett nyckelvalv är en annan exempelkomponent för det här lagret. Nyckelvalvet kan lagra delade hemligheter till ett lagringskonto eller en databas som delas av de olika programmen på den här plattformen.
Lager 2 ska innehålla:
- Principtilldelningar som tillämpas på en prenumeration eller resursgrupp för att matcha produktspecifika krav.
- ARM-mallar för nyckelvalv, logganalys, en SQL-databas (om olika program i produkten använder databasen) och Azure Kubernetes Service.
Du bör implementera behörigheter som begränsar möjligheten att skicka ändringar till den här lagringsplatsen. Precis som de andra lagren bör du använda grenskydd för att se till att en produktledare eller ägare kan godkänna pr från andra utvecklare. Det finns inga fasta regler för läsåtkomst till produktplattformen, men utvecklare från något av programteamen bör åtminstone beviljas läsbehörighet för att kunna föreslå ändringar. Eftersom Layer 2 kan innehålla viss egen arkitektur eller liknande information kan du välja att begränsa åtkomsten till dem i organisationen som använder plattformen. Men om så är fallet vill du se till att du skapar en process för att samla in bra metoder och kodfragment från den här lagringsplatsen för att dela med det globala biblioteket Layer 0.
Layer 3 – Program
Layer 3, programskiktet, innehåller de komponenter som är byggda ovanpå produktplattformen. Dessa komponenter levererar de funktioner som företaget begär. För en strömningsplattform kan till exempel en app tillhandahålla sökfunktionen medan en annan app ger rekommendationer.
Lager 3 ska innehålla:
- Programkod i C#, Python och så vidare.
- Infrastruktur för enskilda komponenter (som endast används i det här programmet): funktioner, Azure Container Instances, Event Hubs.
Behörigheter är begränsade för möjligheten att skicka ändringar till den här lagringsplatsen. Du bör använda grenskydd för att göra det möjligt för en teammedlem i det här programmet att godkänna en PR som gjorts av en annan gruppmedlem. Gruppmedlemmar bör inte tillåtas godkänna sina egna ändringar. Eftersom det här lagret kan innehålla upphovsrättsskyddad arkitektur, affärslogik eller liknande information kan du välja att begränsa åtkomsten till dem i organisationen som skapar det här programmet. Men om så är fallet bör du också skapa en process för att samla in bra metoder och kodfragment från det här lagret för att dela med det globala biblioteket, Layer 0.
Gemensamma förhållanden mellan lager
Den här artikeln beskriver vissa specifika detaljer för varje lager, men det finns även vissa egenskaper för alla lager som du bör tänka på.
Din infrastruktur bör fungera som om det vore ett program. Det innebär att du bör ha en process för kontinuerlig integrering (CI) där nya funktioner testas fullt ut, med enhetstester, röktester och integreringstester. Du bör bara slå samman kod som skickar dessa tester till huvudversionsgrenen.
Du bör också se till att du har avdelningsprinciper på plats för att förhindra att enskilda personer kringgår processen, även för lämplighet. Om din CI-process ses som ett hinder innebär det att du har ådragit dig tekniska skulder som måste hanteras. Det betyder inte att du behöver ta bort principer och skydd.
Slutligen, även om du kanske inte har ett index över alla lagringsplatser och koden i dem, bör din organisation utveckla en process för enskilda användare att begära åtkomst till lagringsplatser. Vissa regler kan vara helt automatiserade. Du kan till exempel implementera en regel som ger läsåtkomst, utan granskning, till en deltagare som är med i produktteamet för alla program under den produkten. Sådana regler kan ofta implementeras med gruppbaserat medlemskap och gruppbaserade rolltilldelningar i dina miljöer. Att konfigurera den här typen av åtkomst bör underlätta den inre källan och organisationens kunskaper.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudsakliga författare:
- Tim Sullivan | Senior Cloud Solution Architect
Övriga medarbetare:
- Gary Moore | Programmerare/skrivare
Nästa steg
- Designområde: Plattformsautomatisering och DevOps
- Mogna teamstrukturer
- Vad är infrastruktur som kod?
- Azure/ResourceModules: Den här lagringsplatsen innehåller en CI-plattform för och en samling mogna och kurerade Bicep-moduler. Plattformen stöder både Azure Resource Manager och Bicep, och du kan använda dess funktioner med GitHub-åtgärder och Azure Pipelines.
- Skapa ett privat register för Bicep-modulen