Docker — isolerte containere for stabile nettsteder

Hva er en container — og hvorfor spiller det en rolle for nettstedet ditt

En container er en standardisert pakke som inneholder applikasjonen og absolutt alt den trenger for å kjøre: runtime, biblioteker, konfigurasjon. Containeren kjører isolert fra resten av serveren, men bruker direkte Linux-kjernen til verten — uten et eget operativsystem per applikasjon. Docker, lansert i 2013, gjorde denne teknologien til en tilgjengelig standard; image-formatet er i dag standardisert som OCI (Open Container Initiative) og kjører likt på hvilken som helst Linux-server eller sky.

Den klassiske analogien er skipscontaineren: uansett hva den inneholder, har den den samme standardformen og kan flyttes på hvilket som helst skip, tog eller lastebil. På samme måte er 4buildsite-tjenestene som bygger og leverer nettstedet ditt — editoren, FastAPI-API-et, rendermotoren — pakket i standardimages som kjører likt på testserveren og på produksjonsserveren. For deg som eier av et nettsted eller en nettbutikk betyr det forutsigbarhet: det du så i forhåndsvisningen er nøyaktig det de besøkende får.

• Container = applikasjonen + avhengighetene, i én enkelt isolert pakke
• Standardformat OCI — samme image kjører på hvilken som helst server eller sky
• Uten eget operativsystem per tjeneste — ingen full OS-oppstart
• På 4buildsite håndteres containeriseringen av plattformen — du publiserer bare

Isolasjon: nettstedet ditt er ikke avhengig av naboene

På klassisk delt hosting deler hundrevis av nettsteder den samme serveren, de samme prosessene og ofte den samme PHP-installasjonen. Hvis en nabo får en trafikkbølge eller et dårlig skrevet skript bruker opp hele prosessoren, blir nettstedet ditt tregere — fenomenet «noisy neighbour». 4buildsite angriper problemet fra to retninger. Den første: de publiserte nettstedene rendres statisk — på serverne som leverer dem kjører det ingen kode per nettsted (PHP, plugins, skript), så det finnes ikke noe dårlig skrevet skript hos en nabo som kan bruke opp prosessoren. Den andre: plattformens tjenester kjører hver i sin egen container, med separate prosesser og filer (via namespaces) og med mulighet for CPU- og minnegrenser (via cgroups, mekanismene i Linux-kjernen).

Isolasjon betyr like mye for sikkerheten. På delt hosting kan et kompromittert nettsted bli en inngangsport til nabonettstedene på den samme serveren. På 4buildsite er det publiserte nettstedet et sett med statiske filer — det kjører ingen kode som kan kompromitteres gjennom plugins eller temaer — og plattformens tjenester som behandler data (ordrer, betalinger, editor) ligger i separate containere: filsystemet er isolert, og en eventuell hendelse blir innestengt i den aktuelle containeren.

• Publisert nettsted = statiske filer — null kode per nettsted som kan bli kompromittert
• Plattformens tjenester: separat filsystem og separate prosesser per container
• Statisk levering: siden serveres som ferdige filer

Samme versjon overalt: null «det virker hos meg, men ikke live»

Den vanligste kilden til feil i klassisk web er forskjellen mellom miljøet nettstedet ble testet i og serveren det kjører på live: en annen språkversjon, en manglende utvidelse, en annen konfigurasjon. Et Docker-image fjerner hele denne kategorien av problemer: imaget bygges én gang, med alle avhengigheter låst, og nøyaktig samme artefakt kjører i test og i produksjon. Det finnes ikke noe «manuelt konfigurert på serveren».

For deg gir dette direkte stabilitet. Når du endrer nettstedet i den visuelle editoren på panel.4buildsite.net og trykker publiser, har versjonen som når de besøkende gått gjennom de samme trinnene, via de samme containeriserte tjenestene, hver eneste gang. Færre overraskelser etter publisering — og for en nettbutikk betyr hver time uten drift tapte ordrer.

Atomiske publiseringer og tilbakerulling til forrige versjon

På 4buildsite betyr ikke en publisering «vi stopper nettstedet, kopierer filer og håper». Hver publisering genererer en ny, komplett versjon av nettstedet ditt — rendret statisk, adskilt fra den som er live — og byttet til den er atomisk: i én enkelt operasjon begynner leveringstjenesten å servere den nye versjonen. Byttet skjer først når den nye versjonen er ferdig. Det samme prinsippet gjelder plattformens tjenester: den nye versjonen av en container starter ved siden av den gamle og overtar trafikken først etter helsesjekkene.

Like viktig er veien tilbake. Hver publiserte versjon av nettstedet beholdes intakt, så tilbakerulling til forrige versjon betyr rett og slett å bytte tilbake — ikke en gjenoppretting fra backup. Hvis en publisering fører til et problem, kan du gå tilbake til forrige versjon. Den eneste ærlige nyansen: dataene (ordrer, produkter, innhold) lever i databasen, adskilt fra de publiserte versjonene — derfor håndteres de på persistente volumer, adskilt fra nettstedets filer.

• Hver publisering = en ny, komplett versjon, byttet atomisk
• Tilbakerulling = bytte tilbake til forrige versjon
• Du publiserer endringer når som helst, også midt i salgssesongen

Effektivitet og kostnader: mer ytelse for de samme pengene

En klassisk virtuell maskin kjører et helt operativsystem for hver applikasjon — gigabyte med minne og minutter med oppstartstid brukt bare på «emballasjen». Containere deler vertens kjerne, så på den samme serveren er det plass til mange flere nettsteder, hver med sin egen isolasjon. Denne tettheten er grunnen til at 4buildsite kan inkludere hosting og SSL i abonnementet, uten en egen infrastrukturkostnad per nettsted.

For det publiserte nettstedet ditt er skalering ved trafikk enda enklere: siden de er statiske filer, er det ekstremt billig å servere dem — en topp av besøkende betyr flere filer levert, ikke flere prosesser som tråkker hverandre på tærne. Og plattformens tjenester, som kjører i containere, kan få ekstra instanser når det trengs. Du betaler et forutsigbart abonnement, ikke en infrastruktur som er dimensjonert permanent for årets travleste dag. Om hvordan vi faktisk driver disse containerne — orkestrering, proxy, CI/CD, overvåking — kan du lese på siden Cloud & DevOps.