Varför är containrar viktiga?
- 7 minuter
I den här lektionen följer du Tailspin-teamet när de diskuterar några välbehövliga förbättringar av devops-processen. I det här scenariot använder teamet Docker för att containerisera sina webbprogram. Teamet uppdaterar sedan sin CI/CD-pipeline för att stödja den.
Det har varit några tuffa veckor.
De senaste veckorna har varit en utmanande tid på Tailspin. Team kämpar för att uppfylla tidsgränser av flera skäl, och det har funnits en oro över produktiviteten i hela företaget. Andy har kallat ihop några viktiga intressenter från Space Game-webbplatsteamet för att samla in feedback för en kommande presentation för ledningen.
Andy: Tack för att du kom förbi. Jag vet att de senaste veckorna har varit tuffa för alla, men jag har några goda nyheter. Ledningen håller en konferens utanför arbetsplatsen i morgon för att lyssna på förslag om förändringar vi kan göra för att förbättra prestationen. De har bjudit in mig att presentera en fallstudie om våra DevOps-framgångar och sagt att de också är öppna för andra idéer vi kan ha. Jag hoppades att vi kunde använda det här mötet som en möjlighet att brainstorma. Vem vill gå först?
Alla tittar på Amita. Hon har varit särskilt frustrerad på sistone.
Amita: Jag går först. Som ni vet testar jag för flera team, och det kan vara svårt eftersom varje team använder sin egen teknikstack. Även om de använder samma underliggande plattformar, som .NET eller Java, riktar de sig ofta mot olika versioner. Det känns som om jag ibland tillbringar halva min dag med att bara få testmiljöer i ett tillstånd där de kan köra koden jag behöver testa. När något inte fungerar är det svårt att avgöra om det finns en bugg i koden eller om jag av misstag har konfigurerat version 4.2.3 i stället för 4.3.2.
Andy skriver "Utmaningar med versionshantering för QA" på whiteboarden.
Tim: Jag vill lägga till åtgärder till den frustrationen. Vi har några team med unika versionskrav, så vi måste publicera deras appar på sina egna virtuella datorer bara för att säkerställa att deras version och komponentkrav inte strider mot våra andra appar. Förutom de omkostnader som krävs för att underhålla den extra uppsättningen virtuella datorer kostar det oss också mer än det skulle göra om dessa appar kunde köras sida vid sida.
Andy skriver "Överbelastning på grund av att lösa appisolering med virtuella maskiner" på whiteboarden.
Mara: Jag har något från utvecklingssidan. För några veckor sedan arbetade jag med peer-to-peer-uppdateringssystemet och fick allt att fungera på min dator, men när jag lämnade ut det för distribution fungerade det inte i produktion. Jag hade glömt att jag behövde öppna port 315 som en del av tjänsten. Det tog oss över en dag av felsökning för att inse vad som pågick. När vi öppnade upp det i produktionen fungerade saker som förväntat.
Andy skriver "Konfigurationsinkonsekvenser mellan distributionssteg" på whiteboard-tavlan.
Andy: Jag tycker att det här samtalet är en bra början. Låt mig undersöka dessa frågor och se vad jag kan komma på. Här är de farhågor som jag hörde:
- Utmaningar med versionshantering av beroenden för QA
- Omkostnader på grund av att du löser appisolering med virtuella datorer
- Konfigurationsinkonsekvenser mellan distributionsfaser
Sätta ihop allt (i en container)
Nästa morgon kallar Andy till möte för att presentera en ny idé för teamet.
Andy: Jag pratade med några kollegor igår om de utmaningar vi står inför, och de gav några intressanta förslag. Det jag ser fram emot att prova är Docker. Det är en teknik för att paketera hela program som containrar.
Amita: Vad är en container? Är det som en .zip fil?
Andy: Inte exakt. Det är mer som en lätt virtuell dator som är utformad för att köras direkt på värdoperativsystemet. När du skapar projektet är utdata en container som innehåller din programvara och dess beroenden. Det är dock inte ett komplett virtualiserat system, så det kan starta på så lite som mindre än en sekund.
Tim: Hur hanterar den säkerhet och isolering?
Andy: Säkerhet och isolering hanteras av värdoperativsystemet. När containern körs i en värdprocess isoleras containern från de andra processerna på samma värddator. Med den här isoleringen kan din container läsa in de versioner av komponenter som behövs, oavsett vad andra containrar gör. Det innebär också att du enkelt kan köra flera containrar på samma värd samtidigt.
Amita: Det låter bra för produktionsmiljön, men löser det de utmaningar som vi står inför tidigare i pipelinen?
Andy: Absolut, jag håller med! I stället för att skicka källkod eller en uppsättning binärfiler blir hela containern artefakten. Det innebär att när Mara utvecklas körs hennes felsökningssessioner lokalt mot containern som finns på hennes dator. När Amita testar testar hon mot en kopia av samma container, som redan innehåller alla nödvändiga versioner av dess beroenden. När Tim hanterar vår produktionsmiljö är de containrar han övervakar fristående kopior av samma containrar som har utvecklats av Mara och testats av Amita.
Mara: Hur svårt är det att utveckla ett containerprogram? Måste vi göra betydande ändringar i vår befintliga kod?
Andy: Containrar är mer av en paketerings- och distributionsteknik. De påverkar inte den grundläggande programvara som vi skriver. Vi kan bara instruera våra verktyg att skapa en Docker-container i slutet av bygget. När vi sedan felsöker körs programmet från den lokala containern i stället för från vår lokala webbserver. Med verktyg som Visual Studio kan du till och med växla mellan felsökningsmiljöer som Docker och IIS Express för att ge oss den flexibilitet vi behöver. Jag förgrenade faktiskt vårt webbplatsprojekt igår kväll och konverterade det till att bygga som en Docker-container för att testa processen. Jag behövde bara lägga till några grundläggande containerkonfiguration; Jag behövde inte ändra någon av vår befintliga kod.
Mara: Det är fantastiskt att veta. Jag slår vad om att vi till och med kan uppdatera versionspipelinen i Azure Pipelines från din förgrening för att skapa och distribuera Docker-versionen.
Andy: Du läste mitt sinne.
Vad är Docker?
Docker är en teknik för att automatisera paketering och distribution av bärbara, självförsörjande containrar. Docker-containrar kan köras var som helst där en Docker-värd hittas, oavsett om det är på en utvecklingsdator, en avdelningsserver, ett företags datacenter eller i molnet. Azure tillhandahåller flera sätt att köra containerbaserade program, inklusive App Service eller som en del av kluster som hanteras med orkestreringstekniker som Kubernetes.
Tailspin-teamet valde Docker-containrar för det här scenariot eftersom det uppfyllde alla deras behov:
Problem med versionshantering av beroenden för QA: Program paketeras som containrar som tar med sig rätt versioner av deras beroenden.
Omkostnader på grund av att du löser appisolering med virtuella datorer: Många isolerade containrar kan köras på samma värd med fördelar jämfört med virtuella datorer, inklusive snabbare starttid till större resurseffektivitet.
Konfigurationsinkonsekvenser mellan DevOps-steg: Containrar levereras med manifest som automatiserar konfigurationskraven, till exempel vilka portar som måste exponeras.
Att använda Docker-containrar kan vara ett viktigt steg mot en arkitektur för mikrotjänster. Vi diskuterar mer om det senare.