Distribuera med förtroende
 Nå önskat distributionstillstånd med förutsägbarhet. |
|---|
Skapa en leveranskedja för arbetsbelastningar som gör att du konsekvent kan nå målet för förutsägbarhet i alla dina miljöer, på arbetsbelastningens värdplattformar, program, data och konfigurationsresurser. Distributionsmekanismen måste kunna automatiseras, testas, övervakas och versionshanteras. Den bör vara modulariserad och redo att köras på begäran. Den ska inte representeras som en monolitisk process från slutpunkt till slutpunkt. Leveranskedjan är inte nödvändigtvis för snabbare körning, utan för att uppnå konsekvens och självdokumentation över flera iterationer.
Arbetsbelastningsteamet är ansvarigt för leveranskedjan när det gäller deras egen arbetsbelastning.
Exempelscenario
Contoso Manufacturing har utvecklat ett Java-baserat program som används för att övervaka och optimera deras tillverkningsprocesser. Arbetsbelastningen har nyligen migrerats till Azure och körs nu på Azure Spring Apps, Azure Database for MySQL och Azure IoT Hub.
Distribuera infrastruktur via kod
Använd Infrastruktur som kod (IaC) för att definiera de upprepningsbara aspekterna av leveranskedjan som är produktionsklar. Föredrar deklarativa metoder framför imperativa metoder.
Deklarativa IaC-tekniker är utformade med automatisering och återanvändning i åtanke. Du kan avlasta infrastrukturdistributioner från enskilda användare till verktyg och uppnå konsekvent kvalitet.
Ur ett infrastrukturperspektiv tar färre teknikval bort variansen i verktygen och gör konfigurationsavvikelsen enkel att identifiera. Underhåll blir också enklare. Om du anpassar val till teamets befintliga kompetensuppsättning kan teamet enkelt anta dem.
Contosos utmaning
- Den lokala versionen av arbetsbelastningen använde en kombination av skript och manuella steg för att bygga ut infrastrukturen och distribuera programmet mellan miljöer. Tidigt under Azure-migreringen gjorde teamet ändringar i de befintliga imperativa skripten för att rikta in sig på den nya plattformen så att de kunde återanvända så mycket av den befintliga automationskodbasen som möjligt. Den här metoden togs också på grund av bristande expertis med Azure- och IaC-tekniker som Bicep.
- När migreringen fortskred och teamet blev mer bekanta med plattformen blev de övertygade om att användning av en IaC-metod med Bicep skulle bli en bättre lösning på längre sikt.
Tillämpa metoden och resultaten
- I brist på kunskap internt kontrakterade teamet arbetet med att migrera och utöka distributionsautomatiseringsskripten för arbetsbelastningen till erfarna entreprenörer, som arbetade inbäddade med utvecklingsteamet under projektets inledande faser, samtidigt som de gav kunskapsöverföring till resten av teamet.
- Den resulterande Bicep-baserade implementeringen ger ett mer tillförlitligt, hanterbart och effektivt sätt att etablera infrastruktur i Azure. Koden är nu mer läsbar och underhållsbar, med bra verktygsstöd i VSCode. Det är också helt idempotent och förenklar tillståndshanteringen, som de aldrig kunde utföra fullt ut med den tidigare/imperativa versionen.
Behandla din IaC på samma sätt som programkoden
Följ programvarurekommendationerna för utveckling och underhåll av IaC: Modularisera med måtta, undvik anpassade abstraktioner eller lågvärdesabstraktioner och följ en skiktad metod för att återspegla olika livscykeler. Forma grundläggande lager där de nedre lagren förblir konstanta och de övre lagren ändras efter behov.
Distributionsartefakter, till exempel programbinärfiler, IaC-mallar och parametrar, är en del av attackytan. Tillämpa försäkringar, till exempel hemlig hantering, åtkomstkontroll och andra principer i säkerhetspelare.
Artefakter har samma tekniska stränghet som programkod. Kvalitetskontroller via peer-granskningar och testning ger dig förtroende för distributionen.
En skiktad metod gör underhåll enklare och skapar gränser som upprättar tydliga ansvarslinjer.
Genom att lägga till säkerhetskontroller i artefakter kan systemet härdas under distributionsprocessen.
Contosos utmaning
- Projektteamet hade en generös budget i början av migreringsarbetet, så de anställde mycket erfarna entreprenörer som levererade med hög kvalitet och på kort tid. Leverantörerna använde en separat lagringsplats för sin utveckling och den lagringsplatsen har inte regelbundet granskats för säkerhet medan den huvudsakliga lagringsplatsen för programkod är det.
- Teamet gör sig redo att släppa en större omdesign av lösningen och distributionskoden behöver betydande ändringar. På grund av brist på utvecklingsresurser görs den senaste batchen med ändringar av två praktikanter. När en av de ledande utvecklarna i teamet kallas in för att hjälpa praktikanterna märker han flera incheckningar på lagringsplatsen som inte är i nivå med teamets utvecklingsstandarder, inklusive att ha programhemligheter som API-nycklar hårdkodade i kodbasen.
Tillämpa metoden och resultaten
- Teamet bestämmer sig för att flytta kodbasen för bygg- och distribution till samma lagringsplats som används för programkoden och börja tillämpa samma tekniska stränghetsnivå som andra områden i kodbasen. Koden skickas till teamstandarder innan den första incheckningen, programhemligheter tas bort och alla andra standarder och verktyg för teamets kvalitet tillämpas på den.
- Därför har teamet skyddat det här avsnittet av kodbasen samtidigt som kodkvaliteten ökar. Framöver följer ändringar i det här området av kodbasen samma standarder och använder samma verktyg som används för kärnprogramkodbasen, inklusive peer-kodgranskningar och automatisk genomsökning av koden med kvalitets- och säkerhetsverktyg.
Standardisera distributioner på ett enda manifest
Utveckla ett vanligt distributionsmanifest som används i alla miljöer. Använd manifestet som standardmekanism för greenfield-projekt, inkrementella arbetsbelastningsuppdateringar eller haveriberedskap.
Om du använder den här metoden kan du ta bort kostnaderna för att underhålla flera tillgångar.
Om det uppstår en katastrof blir återställningen snabb och tillförlitlig eftersom du kan distribuera ett provat och testat manifest i stället för att skapa en improviserad miljö.
Contosos utmaning
- Contoso Manufacturing använder en helt automatiserad pipeline för att distribuera infrastruktur, programkod och konfigurationsändringar i utvecklings- och produktionsmiljön. Programmet är konfigurerat för hög tillgänglighet i en enda region. De flesta programkomponenter är tillståndslösa, förutom MySQL-databasen. Databasen säkerhetskopieras enligt den etablerade RTO/RPO och säkerhetskopian replikeras till en sekundär region.
- Om ett större eller oåterkalleligt fel inträffar i den primära regionen planerar teamet att skapa en ny miljö som är värd för programmet i den sekundära regionen. Under ett planerat detaljtest för att testa DR-procedurerna misslyckas distributionsskripten när de försöker återskapa miljön i den sekundära regionen på grund av bristen på tillgänglighet för flera resurser och andra tjänstbegränsningar.
Tillämpa metoden och resultaten
- Teamet minimerar de problem de påträffade när de försökte etablera i den sekundära regionen genom att ersätta användningen av vissa resurser med motsvarande SKU:er som är tillgängliga i båda regionerna och göra vissa alternativ konfigurerbara så att ett annat, men giltigt, värde kan användas i den sekundära.
- Övningen har ökat teamets förtroende för deras förmåga att återhämta sig från större infrastrukturfel.