Docker — isolerede containere til stabile websites

Hvad en container er — og hvorfor det betyder noget for dit site

En container er en standardiseret pakke, der indeholder applikationen og absolut alt, hvad den skal bruge for at køre: runtime, biblioteker og konfiguration. Containeren kører isoleret fra resten af serveren, men bruger værtens Linux-kerne direkte — intet separat operativsystem pr. applikation. Docker, lanceret i 2013, gjorde denne teknologi til en tilgængelig standard; image-formatet er i dag standardiseret som OCI (Open Container Initiative) og kører identisk på enhver Linux-server eller cloud.

Den klassiske analogi er skibscontaineren: uanset hvilken last den rummer, har den samme standardform og kan flyttes over på ethvert skib, tog eller enhver lastbil. På samme måde er de 4buildsite-tjenester, der bygger og leverer dit site — editoren, FastAPI-API'et, renderingsmotoren — pakket i standardimages, der kører ens på testserveren og i produktion. For dig som ejer af et site eller en webshop betyder det forudsigelighed: det, du så i forhåndsvisningen, er præcis det, dine besøgende får.

• Container = applikationen + dens afhængigheder, i én isoleret pakke
• Standard OCI-format — det samme image kører på enhver server eller cloud
• Intet separat operativsystem pr. tjeneste — starter på sekunder, ikke minutter
• På 4buildsite håndteres containerisering af platformen — du udgiver bare

Isolation: dit site afhænger ikke af sine naboer

På klassisk shared hosting deler hundredvis af sites den samme server, de samme processer og ofte den samme PHP-installation. Hvis en nabo får en trafikspids, eller et dårligt skrevet script æder al CPU'en, bliver dit site langsommere — problemet med den »støjende nabo«. 4buildsite angriber det fra to sider. For det første: publicerede sites renderes statisk — der kører ingen kode pr. site (PHP, plugins, scripts) på de servere, der leverer dem, så der er ikke noget dårligt skrevet script hos en nabo, der kan æde CPU'en. For det andet: platformens tjenester kører hver i sin egen container, med adskilte processer og filer (via namespaces) og mulighed for CPU- og hukommelsesgrænser (via cgroups, Linux-kernens mekanismer).

Isolation betyder lige så meget for sikkerheden. På shared hosting kan ét kompromitteret site blive en indgang til nabosites på samme server. På 4buildsite er et publiceret site et sæt statiske filer — der er ingen kode pr. site, som kan kompromitteres via plugins eller temaer — og de platformstjenester, der behandler data (ordrer, betalinger, editoren), ligger i separate containere: filsystemet er isoleret, og en hændelse forbliver indesluttet i den container.

• Publiceret site = statiske filer — ingen kode pr. site, der kan kompromittere det
• Platformstjenester: separat filsystem og separate processer pr. container
• Forudsigelig ydeevne: statisk levering, lige så hurtig kl. 3 om natten som under kampagnespidsen

Den samme version overalt: aldrig »det virker på min maskine«

Den hyppigste kilde til fejl på det klassiske web er kløften mellem miljøet, hvor et site blev testet, og serveren, hvor det kører live: en anden sprogversion, en manglende udvidelse, en anden konfiguration. Et Docker-image fjerner hele denne klasse af problemer: imaget bygges én gang med alle afhængigheder fastlåst, og præcis det samme artefakt kører i test og i produktion. Der er ingen »manuelt konfigureret på serveren«.

For dig bliver det direkte til stabilitet. Når du redigerer dit site i den visuelle editor på panel.4buildsite.net og trykker udgiv, har den version, der når de besøgende, gennemgået de samme trin, gennem de samme containeriserede tjenester, hver eneste gang. Færre overraskelser efter udgivelsen betyder færre nætter med webshoppen nede — og for en webshop betyder hver time offline tabte ordrer.

Udgivelser og rollback til den forrige version

På 4buildsite betyder udgivelse ikke »tag sitet ned, kopiér filer, og håb«. Hver udgivelse genererer en ny, komplet version af dit site — renderet statisk, adskilt fra den, der er live — og skiftet til den er atomisk: i én enkelt operation begynder leveringstjenesten at servere den nye version. Besøgende oplever ingen afbrydelse — ikke engang midt i en ordre, med varer i kurven. Det samme princip gælder platformens tjenester: en containers nye version starter ved siden af den gamle og overtager først trafikken efter health checks.

Lige så vigtig er vejen tilbage. Hver publiceret version af sitet bevares intakt, så at gå tilbage til den forrige version blot betyder at skifte tilbage — en omskiftning, ikke en timelang gendannelse fra backup. Hvis en udgivelse introducerer et problem, sidder din webshop ikke fast på den fejlbehæftede version. Den ene ærlige nuance: data (ordrer, produkter, indhold) ligger i databasen, adskilt fra de publicerede versioner — og derfor håndteres de på persistente volumener, adskilt fra sitets filer.

• Hver udgivelse = en ny, komplet version, skiftet atomisk — ingen afbrydelse
• Rollback = at skifte tilbage til den forrige version
• Udgiv ændringer når som helst, selv i højsæsonen

Effektivitet og pris: mere ydeevne for de samme penge

En klassisk virtuel maskine kører et komplet operativsystem for hver applikation — gigabytes af hukommelse og minutters opstartstid brugt alene på »indpakning«. Containere deler værtens kerne, så langt flere sites kan være på den samme server, hver med sin egen isolation. Denne tæthed er grunden til, at 4buildsite kan inkludere hosting og SSL i abonnementet uden en særskilt infrastrukturomkostning pr. site.

For dit publicerede site er trafikskalering endnu enklere: da det er statiske filer, er det ekstremt billigt at servere dem — en spids af besøgende betyder flere leverede filer, ikke ekstra processer, der træder hinanden over tæerne. Og platformens tjenester, der er containere som starter på sekunder, kan få ekstra instanser, når det er nødvendigt. Du betaler et forudsigeligt abonnement, ikke en infrastruktur, der permanent er dimensioneret til årets travleste dag. For hvordan vi i praksis driver disse containere — orkestrering, proxy, CI/CD, overvågning — se siden Cloud & DevOps.