Docker på servern: när containrar lönar sig

En utvecklare sa ”lägg det i Docker”, och nu kör servern sex containrar och ingen vet exakt vad var och en gör. Eller tvärtom: applikationen installerades för hand på servern för flera år sedan, och varje uppdatering känns skrämmande eftersom ingen minns vilka bibliotek och inställningar den bygger på.

Docker är varken bra eller dåligt i sig. Det är ett verktyg som löser ett specifikt problem — applikationen och dess miljö följer med varandra — och tar med sig ett par nya. Nedan beskriver jag när jag rekommenderar det och när inte.

Kort svar: Docker lönar sig när servern kör flera applikationer med olika versionskrav, när applikationen måste installeras upprepade gånger på samma sätt, eller när en gammal applikation behöver isoleras från ett nytt system. För en enkel webbplats som ingen uppdaterar ger det oftast bara mer komplexitet.

När containrar verkligen hjälper

• Flera applikationer, olika krav. En behöver en gammal Java- eller PHP-version, en annan en ny. Utan containrar blir det versionsröra på servern; i en container har varje applikation sin egen miljö.
• Uppdatering och återgång. En ny version är en ny image. Går något fel startar du föregående image och är tillbaka där du var på några minuter.
• Flytt. När applikationen ligger i en container och data är tydligt separerat blir flytten till en ny server mycket mer förutsägbar. Samma sak gäller vid byte till en ny Ubuntu LTS — uppgraderingen av värdsystemet förstör inte biblioteken inne i applikationen.
• Repeterbar installation. Utvecklings-, test- och produktionsmiljö byggs från samma beskrivning, inte för hand till ”ungefär samma” läge.

När Docker bara är extra komplexitet

• Servern kör en enkel applikation som fungerar och sällan ändras.
• Ingen finns som övervakar och uppdaterar containrarna. En container uppdaterar sig inte själv — en gammal image förblir gammal även om värden är patchad.
• Applikationen är tätt knuten till själva servern (hårdvara, filsystem, specifika tjänster), och att containerisera den skulle innebära ett stort omarbete utan tydlig nytta.

Vad som ändras med containrar

Uppdateringar. Utöver operativsystemet måste även images uppdateras. En gammal image med taggen latest som inte hämtats på flera månader kan innehålla lika föråldrad programvara som en försummad server. Jag kommer alltid överens om vem som uppdaterar images och hur ofta.

Backup — här görs flest misstag. En container är engångs, data får inte vara det. Databasen, uppladdade filer och konfiguration måste ligga i volymer eller på värden, och backupen måste täcka just dem. Lever databasen i en container utan volym försvinner den med containern. Jag säkerhetskopierar alltid en databas med dess eget verktyg (till exempel en PostgreSQL- eller MySQL/MariaDB-dump), inte genom att kopiera volymfilerna medan den körs.

Loggar. Containerloggar måste skickas någonstans där de går att läsa och där de inte fyller disken. Annars hittar du ett halvår senare gigabyte av loggar som ingen har tittat på.

Säkerhet. En container är ingen säkerhetsgräns i sig. Kör inte applikationen som root, exponera inte databasporten publikt och baka inte in lösenord i imagen. Säkringen av själva servern är densamma — se även min checklista för att säkra en Linuxserver.

En typisk uppsättning

För ett småföretags applikation använder jag oftast detta mönster:

1. Nginx framför — tar emot HTTPS-anslutningar och skickar förfrågningar till rätt container. Nginx kan själv köras i en container eller på värden.
2. Applikationen i en container — med sina egna versioner, utan att störa något annat.
3. Databasen — antingen i en egen container med volym eller direkt på värden. När det finns mycket data och prestanda är viktigt föredrar jag ofta databasen på värden: den är lättare att övervaka, finjustera och säkerhetskopiera.

Samma logik gäller tyngre komponenter som Tomcat, Elasticsearch eller OpenSearch — var och en i sin egen container med tydligt avgränsade datakataloger.

Flytta en gammal applikation till containrar steg för steg

Allt behöver inte göras om på en gång. Jag brukar gå till väga så här:

1. Kartlägg vad som verkligen körs på servern: versioner, konfiguration, schemalagda jobb, var data finns.
2. Lägg applikationen i en container medan databasen tills vidare får vara som den är. Testa i en separat miljö.
3. Växla över när testerna går igenom — den gamla installationen finns kvar som reserv.
4. Först därefter avgör man om databasen och övriga delar också ska in i containrar.

Om själva applikationen behöver en verklig modernisering, läs även inlägget om att modernisera eller bygga om gammal mjukvara och tjänsten modernisering av mjukvara. Om även servern byts ut hjälper guiden för servermigrering.

Om din server kör Docker som ingen längre underhåller, eller om du funderar på om din applikation är värd att containerisera, skriv till mig. Beskriv med ett par meningar här vad som körs på servern — jag svarar inom en arbetsdag och säger ärligt om containrar skulle ge dig något. Mer om serverdrift finns på sidan om Linux-serverdrift.

Vanliga frågor

Blir servern snabbare med Docker?

Inte märkbart. En containers overhead är liten, men det är ingen prestandavinst. Docker är ett verktyg för installation och underhåll, inte en accelerator.

Ska databasen köras i en container?

Det kan den, så länge data ligger i en volym och backupen är i ordning. Med större datamängder och högre krav föredrar jag ofta databasen direkt på värden.

Räcker Docker Compose eller behövs Kubernetes?

För ett småföretags applikationer på en server räcker Docker Compose oftast. Kubernetes blir vettigt först när det finns många servrar och tjänster som måste skalas automatiskt.

Uppdaterar containrar sig själva?

Nej. Images måste uppdateras regelbundet och containrarna startas om — det är något av det första jag kommer överens om i ett underhållsavtal.