Containerisering av monolitisk programvara

Du kanske vill skapa ett enda, monolitiskt distribuerat webbprogram eller en tjänst och distribuera det som en container. Själva programmet kanske inte är internt monolitiskt, men strukturerat som flera bibliotek, komponenter eller till och med lager (programskikt, domänskikt, dataåtkomstskikt osv.). Externt är det dock en enda container – en enda process, ett enda webbprogram eller en enda tjänst.

För att hantera den här modellen distribuerar du en enda container som representerar programmet. För att öka kapaciteten skalar du ut, d.v.s. lägg bara till fler kopior med en lastbalanserare framför. Enkelheten kommer från att hantera en enskild distribution i en enda container eller virtuell dator.

Bild 4-1. Exempel på arkitekturen för ett containerbaserat monolitiskt program

Du kan inkludera flera komponenter, bibliotek eller interna lager i varje container, enligt bild 4–1. Ett monolitiskt containerbaserat program har de flesta av sina funktioner i en enda container, med interna lager eller bibliotek, och skalas ut genom att klona containern på flera servrar/virtuella datorer. Det här monolitiska mönstret kan dock stå i konflikt med containerprincipen "en container gör en sak och gör det i en process", men kan vara ok i vissa fall.

Nackdelen med den här metoden blir uppenbar om programmet växer, vilket kräver att det ska skalas. Om hela programmet kan skalas är det egentligen inget problem. I de flesta fall är dock bara några få delar av programmet de flaskhalsar som behöver skalas upp, medan andra komponenter är mindre använd.

I ett typiskt e-handelsprogram behöver du till exempel förmodligen skala undersystemet produktinformation eftersom många fler kunder bläddrar i produkter än köper dem. Fler kunder använder sin korg än att använda betalningspipelinen. Färre kunder lägger till kommentarer eller visar sin inköpshistorik. Och du kanske bara har en handfull anställda som behöver hantera innehåll och marknadsföringskampanjer. Om du skalar den monolitiska designen distribueras all kod för dessa olika uppgifter flera gånger och skalas i samma grad.

Det finns flera sätt att skala en programrät duplicering, dela upp olika delar av programmet och partitionera liknande affärsbegrepp eller data. Men förutom problemet med att skala alla komponenter kräver ändringar av en enskild komponent fullständig omtestning av hela programmet och en fullständig omdistribution av alla instanser.

Den monolitiska metoden är dock vanlig eftersom utvecklingen av programmet till en början är enklare än för mikrotjänstmetoder. Därför utvecklar många organisationer med den här arkitekturmetoden. Medan vissa organisationer har fått tillräckligt bra resultat, når andra gränser. Många organisationer utformade sina program med den här modellen eftersom verktyg och infrastruktur gjorde det för svårt att skapa tjänstorienterade arkitekturer (SOA) för flera år sedan, och de såg inte behovet förrän programmet växte.

Ur ett infrastrukturperspektiv kan varje server köra många program inom samma värd och ha ett acceptabelt förhållande av effektivitet i resursanvändningen, som visas i bild 4–2.

Bild 4-2. Monolitisk metod: Värd som kör flera appar, varje app körs som en container

Monolitiska program i Microsoft Azure kan distribueras med dedikerade virtuella datorer för varje instans. Med skalningsuppsättningar för virtuella Azure-datorer kan du dessutom enkelt skala de virtuella datorerna. Azure App Service kan också köra monolitiska program och enkelt skala instanser utan att du behöver hantera de virtuella datorerna. Sedan 2016 kan Azure App Services även köra enskilda instanser av Docker-containrar, vilket förenklar distributionen.

Som en QA-miljö eller en begränsad produktionsmiljö kan du distribuera flera virtuella Docker-värddatorer och balansera dem med hjälp av Azure-balanseraren, enligt bild 4–3. På så sätt kan du hantera skalning med en grovkornsmetod eftersom hela programmet finns i en enda container.

Bild 4-3. Exempel på flera värdar som skalar upp ett enda containerprogram

Distribution till de olika värdarna kan hanteras med traditionella distributionstekniker. Docker-värdar kan hanteras med kommandon som docker run eller docker-compose, antingen manuellt eller genom automatisering, såsom CD-pipelines (kontinuerlig leverans).

Distribuera ett monolitiskt program som en container

Det finns fördelar med att använda containrar för att hantera monolitiska programdistributioner. Skalning av containerinstanser är mycket snabbare och enklare än att distribuera ytterligare virtuella datorer. Även om du använder virtuella maskin skaluppsättningar, tar det tid för virtuella datorer att starta. När det distribueras som traditionella programinstanser i stället för containrar hanteras programmets konfiguration som en del av den virtuella datorn, vilket inte är idealiskt.

Att distribuera uppdateringar som Docker-avbildningar är mycket snabbare och nätverkseffektivt. Docker-avbildningar startar vanligtvis i sekunder, vilket påskyndar distributionen. Att riva en Docker-avbildningsinstans är lika enkelt som att utfärda ett docker stop kommando och slutförs vanligtvis på mindre än en sekund.

Eftersom containrar är oföränderliga av design behöver du aldrig oroa dig för skadade virtuella datorer. Uppdateringsskript för en virtuell dator kan däremot glömma att ta hänsyn till en viss konfiguration eller fil som finns kvar på disken.

Även om monolitiska program kan dra nytta av Docker berör vi bara fördelarna. Ytterligare fördelar med att hantera containrar kommer från distribution med containerorkestrerare, som hanterar de olika instanserna och livscykeln för varje containerinstans. Att dela upp det monolitiska programmet i undersystem som kan skalas, utvecklas och distribueras individuellt är startpunkten för mikrotjänster.

Publicera ett encontainerbaserat program till Azure App Service

Oavsett om du vill få validering av en container distribuerad till Azure eller när ett program helt enkelt är ett program med en enda container är Azure App Service ett bra sätt att tillhandahålla skalbara tjänster med en enda container. Det är enkelt att använda Azure App Service. Det ger bra integrering med Git för att göra det enkelt att ta din kod, skapa den i Visual Studio och distribuera den direkt till Azure.

Bild 4-4. Publicera ett program med en container till Azure App Service från Visual Studio 2022

Utan Docker var du tvungen att vänta tills Azure-teamet uppdaterade dessa beroenden i App Service om du behövde andra funktioner, ramverk eller beroenden som inte stöds i Azure App Service. Eller så var du tvungen att byta till andra tjänster som Azure Cloud Services eller virtuella datorer, där du hade ytterligare kontroll och du kunde installera en nödvändig komponent eller ett ramverk för ditt program.

Containerstöd i Visual Studio 2017 och senare ger dig möjlighet att inkludera vad du vill i din programmiljö, enligt bild 4–4. Eftersom du kör den i en container kan du inkludera beroendet i Dockerfile- eller Docker-avbildningen om du lägger till ett beroende i ditt program.

Som också visas i Bild 4-4 skickar publiceringsflödet en image genom ett containerregister. Detta kan vara Azure Container Registry (ett register nära dina distributioner i Azure och skyddat av Azure Active Directory-grupper och -konton) eller något annat Docker-register, till exempel Docker Hub eller ett lokalt register.