Det talas mycket om containers och orkestrering dessa dagar, och det blir alltmer vardag att hantera dessa begrepp för oss som arbetar med IT och mjukvara. Men hur förklaras dessa olika begrepp och var går gränsen mellan dem. För att reda ut vad det handlar om har vi pratat med Jan Lindström, senior konsult inom systemutveckling med fokus på komplexa miljöer, på Forefront, som har lång erfarenhet av att både sätta upp och använda dessa tekniker.

Hej Jan! Vad är en container, och vad är den bra för?

En container kan sägas vara ett virtualiserat operativsystem, som ger mjukvaran en standardiserad miljö att köra i. Det ger oss möjligheten att starta upp mjukvaran i en exakt likadan miljö många gånger utan att behöva installera mjukvaran och alla dess beroenden.

Detta sätt att driftsätta mjukvara på syftar till att kunna skala upp applikationen till en riktigt storskalig lösning. Du får möjligheten att automatisera många, och ibland alla, byggsteg. Då kan manuell hantering och administration minimeras och kvaliteten på lösningen bibehållas. Med traditionella metoder blir det alldeles för arbetsamt med installation, testning och drift i den här skalan för att du ska mäkta med.

Jan Lindström

Jan Lindström, Forefront Consulting

Ok, så det är driften av applikationen som drar nytta av containers?

Nej, inte bara. Hela utvecklingskedjan drar nytta av containers och orkestrering.

Applikationsutvecklarna och testarna får helt nya möjligheter att köra och testa applikationen lokalt i miljöer som är exakt likadana som driftmiljöerna. Det är ett mycket effektivt sätt att arbeta. En tjänst, som kanske bara är en del av en större lösning, behöver kommunicera med andra tjänster i applikationen. Dessa andra tjänster kan då lätt hämtas hem och köras som containers lokalt på utvecklarens eller testarens dator och upplevs då som en exakt kopia av driftmiljön utan jättestor administrativ insats.

När det sen är dags att driftsätta byggs pipeplines där hela processen för integration (Continuous Integration) och driftsättning (Continuous Deployment) kan automatiseras från kod till färdig container. I dessa automatiserade processer bygger du bort manuell hantering som kan leda till mänskliga misstag och kör tester som en del av byggprocessen.

Vi utgår idag från att du kör flera parallella driftmiljöer för olika syften, som utveckling, test och produktion. Det kan vara svårt att bygga bort alla skillnader mellan miljöerna på grund av behovet att interagera med andra system eller tillgång till data, men containers tar oss långt och gör det enklare att sätta upp.

I driftmiljön får du slutligen fördelen av att containers är flyttbara och lätt kan administreras. Det är nu skalningsfördelarna visar sig och du enkelt kan skala upp en tjänst att köra parallellt på många maskiner. Om behovet av processering ökar, till exempel på grund av många användare, kan du automatiskt lägga till fler instanser av en tjänst för att täcka behovet. När antalet användare minskar kan du självklart minska antalet instanser igen. På så sätt balanseras kapacitet mot kostnad på ett tryggt sätt.

Tyvärr är detta inte inbyggt i containers utan kräver någon form av orkestrering.

Du nämner orkestrering här, vad är det och hur relaterar det till containers?

Ja, det där kan kännas rörigt i början, och många har svårt att skilja på begreppen här. Som jag sa tidigare är containern en virtualiserad miljö för mjukvara, men hur du än går tillväga måste ju mjukvaran köras på någon form av dator, infrastruktur. Orkestrering syftar till att administrera många containers på kluster av datorer, oftast virtuella sådana. Med ett verktyg som Kubernetes eller Docker Swarm kan du samla ett antal maskiner och placera ut dina tjänster i containers på dessa. På det sättet bygger du ett robust och fel-tolerant system som tål att en instans av en tjänst exempelvis kraschar och måste startas om. Den typen av omstarter går blixtsnabbt och märks inte utifrån.

Klustret har många andra funktioner också, som att definiera hur de olika containers som körs i det kan kommunicera med varandra, säkerhet, loggning och så vidare.

Så sammanfattningsvis kan man säga att containers kapslar in och förpackar mjukvara, medan orkestrering administrerar infrastrukturen containrarna körs på och hur containrarna ska köras.

Containers i praktiken

Hur tycker du att man ska gå tillväga för att komma igång med containers?

Jag tycker att du ska börja smått. Försök inte flytta allt på en gång. Se till att få förståelse för varje del i kedjan och få alla verktyg och processer på plats så lär du dig stegvis hur det ska implementeras för just din organisation. Du kan börja med att utse en mindre tjänst och containerisera den, det vill säga bygga in den befintliga tjänsten i en container. Det är inte svårt, men kräver en del konfiguration. Duskapar då en så kallad conatainer-image. En container-image är en mall för vad en container ska innehålla när den startas. Detta gör du lokalt på din egen maskin.

Du kan bygga dina tjänster som containers som körs i den egna utvecklingsdatorn. De exponerar TCP-portar ut till sin omgivning, för andra tjänster att ansluta till. Bakom en exponerad port som tillhör en tjänst sitter oftast ett http(s) REST API. Det beror förstås på vad tjänsten ifråga är till för. Tjänsterna kan erbjuda dessa gränssnitt till världen utanför, men kan också samverka och fråga varandra efter information över dem.

För att tjänsterna ska fungera behöver de ofta lagra sin information i en databas. Och den installerar du med fördel i din lokala utvecklingsmiljö i form av eller flera containers. Det finns mängder av färdiga container-images att hämta och köra igång från Docker Hub för till exempel MySQL, PostGres, Redis, MongoDB och många fler.

Du tillverkar sedan container-images av de tjänster du utvecklat och kör igång dem som containers i utvecklingsdatorn och ser hur hela systemet fungerar. Det gör du antingen med docker eller med docker-compose, vilket innebär att du startar och kör flera containers på en gång med ett enda kommando.

Men hur får jag upp mina containers i klustret?

Du kan göra det manuellt genom att först pusha din container-image till ett registry som klustret hämtar den ifrån och startar dina containers. Men detta kan, och ska, så klart automatiseras.

Då tar du fram en CI/CD-pipeline, en kedja av byggsteg som automatiserar test av koden när den laddas upp till Git (CI = Continuous Integration) samt bygger och driftsätter container-images till klustret (CD = Continuous Deployment).

När du laddar upp din kod till Git, tar till exempel Git Actions vid och genomför CI-steget, det vill säga testar koden, bygger och skickar en container-image till ett registry som är källa för testklustret. Därefter kan CD-steget skötas av ett deployment-verktyg, till exempel ArgoCD, som får en signal från Git att en kodförändring skett, och ser till att driftsätta den eller de containers som ändrats eller kommit till.

Det där lät ju inte helt enkelt. Måste jag göra om allt detta för test- och produktionsmiljöerna nu?

Ja det är lite pyssel att få upp alla delar, men sen kan de återanvändas. Med de konfigurationer du skapat kan du enkelt kopiera strukturen och sätta upp likadana miljöer för test och produktion.

Från det att alla de noder, det vill säga de datorer klustret består av, är igång, kan det ta emot och köra samma containers som utvecklings- respektive test-klustren gjorde. Alla styrfiler som gällde där fungerar även i produktion.

Produktions- och testmiljöerna ska vara identiskt lika, använda samma container-registry och hanteras av samma CI/CD pipeline. När det fungerar i test vet du att det fungerar i produktion också. Åtminstone i teorin. Men det fungerar faktiskt många gånger riktigt bra i praktiken också, om alla delar jag gått igenom ovan är noggrant genomtänkta och realiserade.

Nu har du byggt hela kedjan, från utveckling till driftsättning, som ger dig möjlighet att lansera riktigt storskaliga lösningar. Varje organisation har såklart sina behov som styr hur du bygger upp processen och vilka verktyg du väljer. Men i princip är det dessa steg som krävs för att du ska lyckas!

Vill du veta mer om Containers?

Anmäl dig till webinaret ”Containers och Kubernetes – lyckas med DevOps och skalbarhet i komplexa miljöer”, som sänds 18 mars eller kontakta Peter: peter.d.lundgren@forefront.se

Skriven av: Peter D Lundgren – Konsult på Forefront och senior lösningsarkitekt med lång erfarenhet inom IoT och hårdvarunära systemutveckling.

Jan Lindström är senior konsult inom systemutveckling på Forefront, med fokus på komplexa miljöer.