”Installera en Linux-virtuell maskin och bygg upp exakt samma miljö.”
Tre månader efter att jag började på företaget var stämningen på kontoret märklig. Teamets enda senior hade blivit omplacerad till ett annat projekt och var så upptagen med att packa sina egna saker att någon ordentlig överlämning knappt gick att tänka på, medan teamleaden hade varit borta från praktiskt utvecklingsarbete länge och stod ganska långt ifrån de senaste tekniktrenderna.
En dag kallade teamleaden på mig. ”När din senior försvinner är du den enda som kommer att kunna sköta servrarna. Även om servern kraschar måste du kunna återställa den själv. Installera Linux som en virtuell maskin, VM, på din nuvarande utvecklingslaptop, Windows, och försök bygga exakt samma miljö som produktionsservern.”
Där började mitt slit. Jag installerade VMware, laddade ner Ubuntu-ISO:n, och bara installationen tog en halv dag. Jag grävde i företagets wiki för att installera Java, Node.js och PostgreSQL. Jag tänkte: ”Nyare måste vara bättre”, så jag installerade Java 17, bara för att upptäcka att legacy-koden byggde på Java 8 och inte ens gick att bygga. Jag fick radera allt och installera om. Varje gång jag ändrade en enda rad kod behövde jag köra mvn build, flytta jar-filen till VM:n och köra den där. Det var ren plåga.
Då slog en fråga mig plötsligt. ”Vänta lite. Senast vi deployade till produktionsservern, räckte det inte att bara skriva en enda docker service update-rad?”
Min lokala virtuella maskin var så här tung och krävde en hel hög med inställningar, så vad var egentligen det där ‘Docker’ på produktionsservern som kunde uppdatera allt med ett enda kommando?
Den tunga lösningen: den virtuella maskinen
Metoden som teamleaden bad mig använda, alltså att installera Linux ovanpå Windows, är precis vad en virtuell maskin, VM, är. Det är som att bygga ett helt ‘virtuellt hus’, ett guest OS, ovanpå en fysisk dator, hosten.
I slutändan isolerar en VM miljön på ett tillförlitligt sätt, men för utveckling eller deployment är den helt enkelt för tung och för långsam för att skickas fram och tillbaka varje gång.
Den lätta revolutionen: Docker
Det var därför Docker dök upp, alltså containertekniken. Docker bygger inte ett helt hus som en VM gör. I stället sätter den upp ett tält.
Kommandot update som jag körde på produktionsservern installerade alltså inte om ett tungt operativsystem. Det innebar bara att ”ta ner det gamla tältet och resa ett nytt tält med den nya kodversionen i.” Klart att det kunde bli färdigt nästan direkt.
[Code Verification] Är Docker verkligen så lätt?
Låt oss inte bara säga att Docker är lätt, utan faktiskt kontrollera det. Om målet är att köra en Linux-, Ubuntu-, miljö är skillnaden mellan en VM och Docker dramatisk.
# Kor Ubuntu via Docker-kommando (laddar ner image om den saknas)
$ docker run -it ubuntu:latest /bin/bash
Resultat:
I samma ögonblick som jag tryckte Enter befann jag mig redan i en Ubuntu-miljö. Det är möjligt därför att en Docker-container inte är ett riktigt operativsystem. Den är bara ”ett isolerat utrymme som lånar kärnan från host-OS, alltså min dator, samtidigt som den låtsas vara ett separat OS.”
Praktiskt råd: den verkliga anledningen att använda Docker
När vi väl införde Docker i det dagliga arbetet förändrades mitt liv helt.
Avslutning: vi levererar inte en körbar fil, utan en “miljö”
Med Docker förändrades utvecklingens paradigm. Vi skickar inte längre bara källkoden, .java, till servern. Vi fryser även OS-inställningar, bibliotek och miljövariabler som koden behöver till en ‘image’ och skickar hela paketet.
Men hur byggs egentligen denna nästan magiska ‘Docker image’? Är det bara en komprimerad fil? Överraskande nog sägs en Docker image vara uppbyggd i flera lager, layers, som en tårta.
Nästa gång ska vi gräva i hemligheten bakom Dockers effektivitet: images och deras lagerstruktur.