Docker — isolerade containrar för stabila webbplatser
Hela 4buildsite-plattformen — editorn, API:et, renderingsmotorn och tjänsten som levererar de publicerade webbplatserna — körs i Docker-containrar: isolerade paket som innehåller allt varje tjänst behöver. Din webbplats renderas statiskt och levereras som en komplett version som växlas atomiskt vid varje publicering. Resultatet, på ett begripligt sätt: publiceringar stoppar den inte, och om något går fel går du tillbaka till föregående version.
Vad en container är — och varför det spelar roll för din webbplats
En container är ett standardiserat paket som innehåller applikationen och absolut allt den behöver för att köras: runtime, bibliotek, konfiguration. Containern körs isolerad från resten av servern, men använder värdens Linux-kärna direkt — utan ett separat operativsystem per applikation. Docker, som lanserades 2013, gjorde tekniken till en lättillgänglig standard; avbildningsformatet är i dag standardiserat som OCI (Open Container Initiative) och körs identiskt på vilken Linux-server eller molntjänst som helst.
Den klassiska liknelsen är sjöcontainern: oavsett vilken last den innehåller har den samma standardform och kan flyttas till vilket fartyg, tåg eller lastbil som helst. På samma sätt är 4buildsite-tjänsterna som bygger och levererar din webbplats — editorn, FastAPI-API:et, renderingsmotorn — paketerade i standardimages som körs likadant på testservern och på produktionsservern. För dig som ägare av en webbplats eller butik innebär det förutsägbarhet: det du såg i förhandsvisningen är exakt det besökarna får.
- Container = applikationen + dess beroenden, i ett enda isolerat paket
- OCI-standardformat — samma image körs på vilken server eller molntjänst som helst
- Inget separat operativsystem per tjänst — start på sekunder, inte minuter
- På 4buildsite hanteras containeriseringen av plattformen — du publicerar bara
Isolering: din webbplats är inte beroende av grannarna
På klassisk delad hosting delar hundratals webbplatser samma server, samma processer och ofta samma PHP-installation. Om en granne får en trafikvåg eller ett dåligt skrivet skript tar all processorkraft blir din webbplats långsammare — fenomenet ”noisy neighbour”. 4buildsite angriper problemet från två håll. Det första: publicerade webbplatser renderas statiskt — på de servrar som levererar dem körs ingen kod per webbplats (PHP, plugin, skript), så det finns inget dåligt skrivet skript hos en granne som kan äta upp processorn. Det andra: plattformens tjänster körs var och en i sin egen container, med separata processer och filer (via namespaces) och med möjlighet till gränser för CPU och minne (via cgroups, mekanismerna i Linux-kärnan).
Isoleringen är lika viktig för säkerheten. På delad hosting kan en komprometterad webbplats bli en port till grannwebbplatserna på samma server. På 4buildsite är den publicerade webbplatsen en uppsättning statiska filer — ingen kod körs som kan komprometteras via plugin eller teman — och plattformens tjänster som behandlar data (ordrar, betalningar, editor) ligger i separata containrar: filsystemet är isolerat, och en eventuell incident stannar inom den aktuella containern.
- Publicerad webbplats = statiska filer — ingen kod per webbplats som kan komprometteras
- Plattformens tjänster: separat filsystem och separata processer per container
- Förutsägbart beteende: statisk leverans, lika stabil klockan 3 på natten som under en kampanjtopp
Samma version överallt: noll ”det fungerar hos mig, men inte live”
Den vanligaste källan till fel på den klassiska webben är skillnaden mellan miljön där webbplatsen testades och servern där den körs live: en annan språkversion, ett tillägg som saknas, en annan konfiguration. En Docker-image eliminerar hela den kategorin av problem: imagen byggs en enda gång, med alla beroenden fastlåsta, och exakt samma artefakt körs i test och i produktion. Det finns ingen ”manuellt konfigurerad på servern”.
För dig översätts det direkt till stabilitet. När du ändrar webbplatsen i den visuella editorn på panel.4buildsite.net och trycker på publicera har versionen som når besökarna gått igenom samma steg, genom samma containeriserade tjänster, varje gång. Färre överraskningar efter publicering ger färre nätter med en butik som ligger nere — och för en webbutik innebär varje timmes avbrott förlorade ordrar.
Publiceringar och återgång till föregående version
På 4buildsite betyder en publicering inte ”vi stänger av webbplatsen, kopierar filer och hoppas”. Varje publicering genererar en ny, komplett version av din webbplats — statiskt renderad, skild från den som är live — och växlingen till den är atomisk: i en enda operation börjar leveranstjänsten servera den nya versionen. Samma princip gäller plattformens tjänster: den nya versionen av en container startar bredvid den gamla och tar över trafiken först efter hälsokontrollerna.
Lika viktig är vägen tillbaka. Varje publicerad version av webbplatsen bevaras intakt, så att gå tillbaka till föregående version innebär helt enkelt att växla tillbaka — en enkel växling, inte en återställning från backup som tar timmar. Om en publicering orsakar ett problem blir din butik inte fast på den felaktiga versionen. Den enda ärliga nyansen: data (ordrar, produkter, innehåll) lever i databasen, åtskilt från de publicerade versionerna — därför hanteras de på beständiga volymer, skilda från webbplatsens filer.
- Varje publicering = en ny, komplett version, växlad atomiskt
- Återgång = växling tillbaka till föregående version
- Du publicerar ändringar när som helst, även mitt i försäljningssäsongen
Effektivitet och kostnader: mer kapacitet för samma pengar
En klassisk virtuell maskin kör ett fullständigt operativsystem för varje applikation — gigabyte av minne och minuter av starttid som förbrukas bara på ”förpackningen”. Containrar delar värdens kärna, så på samma server ryms många fler webbplatser, var och en med sin egen isolering. Den här tätheten är orsaken till att 4buildsite kan inkludera hosting och SSL i abonnemanget, utan en separat infrastrukturkostnad per webbplats.
För din publicerade webbplats är skalningen vid trafik ännu enklare: eftersom det är statiska filer är det extremt billigt att servera dem — en topp av besökare innebär fler levererade filer, inte fler processer som trampar varandra på tårna. Och plattformens tjänster, som är containrar som startar på sekunder, kan få extra instanser när det behövs. Du betalar ett förutsägbart abonnemang, inte en infrastruktur som permanent dimensioneras för årets mest hektiska dag. Läs sidan Cloud & DevOps om hur vi faktiskt driver dessa containrar — orkestrering, proxy, CI/CD, övervakning.
Fördelar och begränsningar
Fördelar
- Den publicerade webbplatsen serveras statiskt och plattformen körs i isolerade containrar — en överbelastad eller komprometterad granne påverkar den inte.
- Samma plattformsimages i test och produktion — noll ”det fungerar hos mig, men inte live”.
- Publiceringar: den nya versionen av webbplatsen genereras separat och växlas atomiskt.
- Återgång till den tidigare publicerade versionen om en ändring inte fungerar.
- Containrar startar på sekunder — plattformens tjänster kan utökas vid trafiktoppar.
- Hög täthet per server — hosting ingår i abonnemanget, utan separat kostnad.
Begränsningar
- Isoleringen använder värdens delade kärna — svagare än hårdvaruisoleringen i en dedikerad virtuell maskin.
- Containern är kortlivad: beständig data (databas, uppladdade filer) kräver volymer och backup som hanteras separat.
- Images och deras lager tar diskutrymme — utan regelbunden rensning ackumuleras de.
- För team som administrerar Docker själva finns en verklig inlärningskurva — på 4buildsite hanteras det helt av plattformen.
Kort slutsats
Docker-containerisering är branschens de facto-standard för att köra webbapplikationer: isolering, konsekvens mellan test och produktion samt enkel återgång. På 4buildsite körs plattformen som bygger och levererar din webbplats containeriserad, och publiceringarna av din webbplats är versionerade, växlas atomiskt och går att återställa — hur infrastrukturen drivs (orkestrering, proxy, CI/CD) beskrivs på sidan Cloud & DevOps.
Specifikationstabell
| Förmåga | Gräns / tröskel | Typisk användning | |
|---|---|---|---|
| Resursisolering | CPU-/RAM-gränser per container (cgroups, namespaces) | Delad kärna — ingen hårdvaruisolering som i en VM | Webbplatser och butiker på delad infrastruktur |
| Start / driftsättning | Containern startar på sekunder | Första nedladdningen av imagen tar längre tid | Täta publiceringar och uppdateringar |
| Återgång | Du går tillbaka till vilken tidigare image som helst | Data i databasen återställs inte tillsammans med imagen | Återgång när en uppdatering inte fungerar |
| Portabilitet | OCI-image — körs på vilken Linux-värd eller molntjänst som helst | Images är arkitekturspecifika (x86/ARM) | Flytt mellan servrar utan att skriva om applikationen |
| Täthet / kostnad | Dussintals isolerade containrar på en enda server | Alla delar värdens kärna och disk | Låg kostnad per webbplats — hosting ingår i abonnemanget |
Docker jämfört med virtuella maskiner och delad hosting (cPanel)
| Kriterium | Docker (containrar) | Virtuella maskiner | Delad hosting (cPanel) |
|---|---|---|---|
| Isolering | Per container (processer, filer, resurser) | Fullständig (virtualiserad hårdvara) | Svag — hundratals webbplatser på samma server |
| Start- / driftsättningshastighet | Sekunder | Minuter (fullständig OS-start) | Ändringar direkt på den levande servern (FTP) |
| Resursförbrukning | Minimal — inget separat OS per applikation | Hög — ett fullständigt OS per maskin | Låg, men oreglerat delad mellan grannar |
| Återgång | Återgång — du startar om den tidigare imagen | Från snapshot — långsammare | Manuellt, från backup |
| Säkerhet | Incidenten begränsas till containern | Starkast isolering | En komprometterad webbplats kan påverka grannarna |
| Kostnad per webbplats | Låg — hög täthet per server | Hög — du betalar för hela maskinen | Mycket låg, men oförutsägbar prestanda |
Vanliga frågor
Påverkar Docker min webbplats hastighet?
Nej. Containrar körs nativt på Linux-kärnan, utan hårdvaruvirtualisering, så overheaden är försumbar. Webbplatsens hastighet styrs av kod, cache och nätverk — och resursisoleringen gör den till och med mer förutsägbar än på delad hosting.
Varför inte klassisk hosting med cPanel, som för WordPress?
På klassisk delad hosting delar hundratals webbplatser samma server utan strikta gränser: en överbelastad granne gör dig långsammare, och en komprometterad kan påverka dig. På 4buildsite serveras den publicerade webbplatsen statiskt — ingen kod per webbplats som kan komprometteras — och plattformens tjänster körs isolerade i containrar, med publiceringar via atomisk växling. Saker som cPanel inte erbjuder.
Vad händer om en publicering förstör min webbplats?
Den tidigare publicerade versionen finns kvar, intakt, så återgången består i att leveranstjänsten växlar tillbaka till den. Butiken blir inte fast på en felaktig version, och data i databasen förblir orörda.
Måste jag kunna Docker för att använda 4buildsite?
Nej. Containeriseringen hanteras helt av plattformen: du bygger webbplatsen i den visuella editorn på panel.4buildsite.net och publicerar. Docker arbetar ”under huven” — fördelarna (isolering, återgång) får du utan någon konfiguration.
Är Docker säkert för en webbutik?
Ja. Isoleringen av processer och filer begränsar en eventuell incidents räckvidd till den aktuella containern, inte hela servern. Kortuppgifter passerar i vilket fall inte genom containern — betalningar behandlas av Stripe, på Stripes certifierade infrastruktur.
Är Docker samma sak som en virtuell maskin?
Nej. En virtuell maskin virtualiserar hela hårdvaran och kör sitt eget operativsystem — den startar på minuter och förbrukar mycket. En container delar värdens kärna: den startar på sekunder, förbrukar en bråkdel av resurserna och behåller applikationens isolering.