Docker: Wat is het en waarom is het belangrijk?

Docker is een open platform om applicaties te ontwikkelen, te distribueren en te draaien in containers. Het verpakt je code samen met de libraries, tools en instellingen die nodig zijn om te draaien, zodat dezelfde applicatie zich identiek gedraagt op een laptop, op een buildserver en in productie. Dat is het korte antwoord op de vraag wat Docker is.

Het langere antwoord gaat over waarom containers van een nichefunctie in de Linux-kernel zijn uitgegroeid tot de standaardeenheid waarin vrijwel alle moderne software wordt uitgeleverd. In dit artikel lees je wat Docker is en wat een container precies is, waarom Docker belangrijk is, waar je het voor gebruikt, hoe je het installeert en je eerste container draait, wat het kost, waar het misgaat, en hoe het zich verhoudt tot virtuele machines en alternatieven zoals Podman.

Wat is Docker?

De formele definitie is die van Docker zelf. Docker is een open platform om applicaties te ontwikkelen, te distribueren en te draaien, waarmee je je applicaties loskoppelt van je infrastructuur. De kern is containerisatie: Docker verpakt software in gestandaardiseerde eenheden die containers heten en die alles bevatten wat een applicatie nodig heeft om te draaien, namelijk de code, de libraries, de systeemtools en de runtime.

In tegenstelling tot een traditionele virtuele machine, die voor elke instantie een compleet besturingssysteem meedraagt, delen Docker-containers de kernel van het onderliggende besturingssysteem terwijl ze onderling gescheiden blijven. Die ene ontwerpkeuze verklaart waarom containers in seconden starten in plaats van in minuten, en waarom je er tientallen kunt draaien op hardware die met een handvol virtuele machines al moeite heeft.

Wat is een Docker-container?

Een container is een draaiend exemplaar van een Docker-image. De image is het read-only sjabloon: je applicatie, de afhankelijkheden en de configuratie, opgeslagen als een stapel filesystem-lagen. De container is wat je krijgt als je die image start, namelijk een geïsoleerd proces met een eigen beeld van het filesystem, een eigen netwerkinterface en een eigen procesboom, draaiend op de kernel van de host.

Containers zijn bewust wegwerpbaar. Je stopt er een, start een nieuwe uit dezelfde image en krijgt een identieke omgeving terug. Alles wat je wilt bewaren moet naar een volume of naar een externe dienst worden geschreven. Dat verrast bijna iedereen die van virtuele machines komt. Verderop staat hoe je dat oplost.

Is Docker een platform, een framework of een tool?

Docker is een platform en geen framework. Een framework bepaalt hoe je je applicatie schrijft. Docker heeft geen mening over je programmeertaal, je framework of je architectuur. De enige eis is dat je applicatie als image beschreven kan worden en als proces gestart kan worden.

Het helpt om de onderdelen uit elkaar te houden die in de praktijk allemaal “Docker” worden genoemd:

• Docker Engine is de runtime die containers bouwt en draait. Daaronder gebruikt Docker containerd, een CNCF-project met graduated-status, en runc, de referentieruntime van het Open Container Initiative.
• Docker CLI is het docker-commando dat je intypt.
• Docker Desktop is de kant-en-klare applicatie voor Windows, macOS en Linux, met daarin de Engine, de CLI, Compose, een optioneel Kubernetes-cluster en een grafische interface.
• Docker Hub is de registry waar images worden opgeslagen, gevonden en gedeeld.
• Docker, Inc. is het bedrijf achter de commerciële producten en abonnementen.

Het imageformaat en de runtime zelf zijn open standaarden onder het Open Container Initiative. Dat is precies waarom Docker geen lock-inrisico oplevert: een OCI-image die je met Docker bouwt draait ook op Podman, containerd, Kubernetes en elke grote cloudcontainerdienst.

Waar gebruik je Docker Desktop voor?

Docker Desktop is wat de meeste ontwikkelaars daadwerkelijk installeren. Op Windows en macOS draait het een kleine Linux virtuele machine en geeft het je daarbinnen Docker Engine. Daar komen schermen bij om images en containers te beheren, een Kubernetes-cluster met één node dat je kunt aanzetten, en een overzicht van kwetsbaarheden in de images die je binnenhaalt.

Op Linux heb je Docker Desktop niet nodig. Docker Engine installeer je daar gewoon uit de pakketrepositories van je distributie. Docker Desktop voor Linux bestaat vooral voor teams die op alle drie de besturingssystemen dezelfde werkwijze willen.

Docker Desktop is gratis voor persoonlijk gebruik, onderwijs, opensourceprojecten en organisaties met minder dan 250 medewerkers en minder dan 10 miljoen dollar jaaromzet. Zit je boven een van die twee grenzen, dan is een betaald abonnement verplicht. De kosten komen verderop aan bod.

Korte geschiedenis van Docker

Solomon Hykes liet Docker in maart 2013 voor het eerst zien op PyCon in Santa Clara, als intern project van het platform-as-a-service-bedrijf dotCloud. Diezelfde maand werd het open source, en versie 1.0 verscheen in juni 2014. dotCloud werd later omgedoopt tot Docker, Inc., en verkocht in 2019 de Docker Enterprise-tak aan Mirantis om zich op tooling voor ontwikkelaars te richten. Dat verklaart waarom de commerciële producten van vandaag draaien om Docker Desktop en Docker Hub.

Containers waren op dat moment niet nieuw. Linux had al control groups en namespaces, en LXC bestond al jaren. Wat Docker toevoegde was een imageformaat, een publieke registry en een command line die eenvoudig genoeg was om containers bruikbaar te maken voor gewone ontwikkelaars in plaats van alleen voor kernelspecialisten. Die toegankelijkheid heeft de markt veranderd, niet de onderliggende techniek.

Waarom is Docker belangrijk?

Docker is belangrijk omdat het een concreet en duur probleem heeft opgelost: software die in de ene omgeving werkt en in de andere niet.

Voordat er containers waren, betekende het uitrollen van een applicatie dat je de omgeving handmatig of via configuratiebeheer moest reproduceren. Versies van het besturingssysteem, versies van libraries, omgevingsvariabelen, bestandspaden en geïnstalleerde tooling moesten allemaal kloppen. Dat lukte zelden in één keer, en het gat tussen “bij mij werkt het” en “in productie werkt het” kostte een aanzienlijk deel van de ontwikkeltijd.

Een image laat dat gat verdwijnen door de omgeving onderdeel te maken van het artefact. Wat je hebt getest is precies wat je uitrolt. Daar volgen vier dingen uit, en die verklaren waarom Docker belangrijk is:

• Consistentie. Dezelfde image draait op een laptop, in de CI-pipeline en in productie, zonder verschillen die onderweg insluipen.
• Snelheid en efficiënt hardwaregebruik. Containers delen de kernel van de host, dus ze starten in seconden en je draait er veel op één machine.
• Portabiliteit. Een OCI-image draait op elke compatibele runtime en bij elke cloud, zonder opnieuw te bouwen of te verpakken.
• Samenstelbaarheid. Kleine, los uitrolbare services worden praktisch beheersbaar. Dat is wat microservices en later serverless containerplatformen mogelijk maakte.

Het gevolg is dat containers geen keuze meer zijn maar een aanname. Kubernetes, GitHub Actions runners, de meeste CI-systemen, de meeste platform-as-a-service-diensten en de meeste AI-inferentiestacks nemen allemaal een containerimage als invoer. Docker begrijpen is daarmee verschoven van specialisme naar basiskennis voor ontwikkelaars, DevOps-engineers en datateams.

Waar kun je Docker voor gebruiken?

Docker vervult meerdere rollen in de softwareontwikkelcyclus.

Applicaties uitrollen en schalen

Met Docker draai je dezelfde workload op de laptop van een ontwikkelaar, op fysieke of virtuele machines in een datacenter of bij een cloudprovider. Die portabiliteit maakt het eenvoudig om workloads te verplaatsen en applicaties op of af te schalen naarmate de vraag verandert, omdat je voor extra capaciteit meer kopieën van een image start in plaats van een extra server in te richten en te configureren.

Ontwikkelomgevingen standaardiseren

Docker maakt een einde aan het probleem dat iets alleen op de machine van de ontwikkelaar werkt, doordat alle teamleden in dezelfde omgeving werken. Omdat een Dockerfile die omgeving beschrijft en in versiebeheer staat, worden verschillen tussen machines kleiner en werkt iedereen met dezelfde setup. Nieuwe collega’s klonen de repository en draaien één commando, in plaats van een installatiedocument te volgen dat altijd net verouderd is.

Continuous integration en delivery

Doordat ontwikkelaars lokaal in gestandaardiseerde containers werken, verkort Docker de weg van code naar productie. Dezelfde image die in de pipeline is gebouwd en getest, gaat door naar productie. Dat elimineert een hele categorie deployfouten. De meeste CI-platformen, waaronder GitHub Actions en GitLab CI, draaien hun jobs standaard al in containers.

Microservices-architectuur

Doordat containers licht zijn, passen ze goed bij een microservices-architectuur, waarin een applicatie wordt opgeknipt in kleinere, los uitrolbare services. Elke service draait in een eigen container met eigen afhankelijkheden, zodat teams losse onderdelen kunnen bijwerken, schalen en terugdraaien zonder één grote release te hoeven coördineren.

AI- en machine learning-workloads

AI-projecten hebben een afhankelijkheidsprobleem waar containers een antwoord op zijn. CUDA-versies, Python-packages, modelruntimes en systeemlibraries moeten exact op elkaar aansluiten, en die stack handmatig reproduceren op een werkstation, een trainingsserver en een cloudinstantie is onbetrouwbaar. Een image legt de hele stack in één keer vast.

Docker speelt hier zelf ook op in. Docker Model Runner draait lokale taalmodellen achter een OpenAI-compatibele API, zodat je bestaande tooling kunt richten op een model op je eigen hardware in plaats van op een cloudendpoint. De Docker MCP Catalog en MCP Toolkit leveren Model Context Protocol servers als containers, waardoor je niet voor elke tool die een AI-assistent gebruikt een aparte runtime hoeft te installeren. Docker Sandboxes draaien coding agents in geïsoleerde microVM’s, wat een verstandige voorzorgsmaatregel is zodra een agent shelltoegang tot een machine krijgt.

Hoe begin je met Docker?

Beginnen met Docker gaat in een paar overzichtelijke stappen.

Installatie

Docker is beschikbaar als Docker Desktop voor Windows en macOS, en als Docker Engine-pakketten voor Linux-distributies. Compose zit tegenwoordig in de Docker CLI en roep je aan als docker compose, niet meer als de losse docker-compose. Op Windows gebruikt Docker Desktop standaard de WSL 2-backend, met Hyper-V en Docker VMM als alternatieven, dus controleer vóór de installatie of Windows en WSL aan de gedocumenteerde versievereisten voldoen.

Hoe installeer je Docker?

Windows en macOS: installeer Docker Desktop, inclusief Docker Engine, Buildx en Compose. Controleer daarna met docker --version en docker compose version in een terminal.

Linux (Ubuntu of Debian): installeer Docker Engine uit de apt-repository van Docker. De actuele pakketten zijn docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin en docker-compose-plugin, die de oude losse docker-compose vervangen.

Voorbeeldstappen voor Ubuntu, in een terminal met sudo-rechten:

# Voorbereiding
sudo apt update
sudo apt install -y ca-certificates curl
 
# Keyring
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
 
# Repository, in het deb822-formaat dat Docker nu documenteert
sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<SOURCES
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
SOURCES
 
# Engine, Buildx en de Compose-plugin installeren
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Je eerste Docker-container

Controleer na de installatie meteen of alles werkt. Op Linux zet je er sudo voor, tenzij je gebruiker aan de docker-groep is toegevoegd.

sudo docker run hello-world

Verschijnt er een welkomstbericht, dan is de Engine geïnstalleerd, kan hij Docker Hub bereiken en kan hij een container starten. Je gebruiker aan de docker-groep toevoegen scheelt het sudo-voorvoegsel, maar houd er rekening mee dat dit rechten geeft die gelijkstaan aan root op de host.

Dockerfiles begrijpen

Een Dockerfile is een tekstbestand met de instructies om een containerimage te bouwen. Die legt de base image vast, welke bestanden worden gekopieerd, welke afhankelijkheden worden geïnstalleerd en welk commando er draait. Daarmee worden builds reproduceerbaar en automatiseerbaar.

Kies een onderhouden base image. Een runtime draaien die end-of-life is, is een van de meest voorkomende en makkelijkst te vermijden bronnen van kwetsbaarheden in containerimages. Pin daarom op een ondersteunde LTS-versie in plaats van op een meebewegende latest-tag. Slim- en Alpine-varianten schelen fors in omvang, en Docker publiceert daarnaast Hardened Images die vrijwel geen bekende kwetsbaarheden bevatten, voor situaties waarin dat uitmaakt.

Voorbeeld van een Dockerfile voor een Node.js-applicatie, met een multi-stage build en een gebruiker zonder rootrechten:

# Build-fase
FROM node:lts-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
 
# Runtime-fase
FROM node:lts-alpine
WORKDIR /app
COPY --from=build /app/node_modules ./node_modules
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]

De buildfase lost de afhankelijkheden op, de runtimefase begint met een schone base en kopieert alleen de geïnstalleerde modules en je applicatiecode over, en USER node zorgt dat de container niet als root draait. Alle drie zijn gewoontes die je beter meteen aanleert.

Images bouwen en containers draaien

Bouw een image uit de Dockerfile en start een container, waarbij je een poort van de host koppelt aan een poort in de container zodat je erbij kunt.

docker build -t my-app .
docker run -p 3000:3000 my-app

Het eerste commando bouwt een image met de tag my-app uit de Dockerfile in de huidige map. Het tweede start daar een container uit en koppelt poort 3000 in de container aan poort 3000 op je host. Met -d draait hij op de achtergrond, en met docker ps, docker logs en docker stop bekijk en stop je hem.

Werken met Docker Compose

Compose beschrijft in één compose.yaml applicaties die uit meerdere containers bestaan, zodat een webserver, een API en een database samen starten met één commando. Compose zit in de Docker CLI als docker compose en wordt meegeleverd als docker-compose-plugin op Linux en binnen Docker Desktop.

Let op de versienummering, want die zorgt voor verwarring. Compose v1 was het Python-script docker-compose en is uitgefaseerd. Compose v2 was de herbouw in Go, aan te roepen als docker compose. Compose v5 verscheen in 2025, is functioneel gelijk aan v2 en voegt een officiële Go SDK toe om Compose in je eigen tooling te gebruiken. Het commando dat je typt is niet veranderd.

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 5
 
volumes:
  pgdata:

Je beheert de stack met docker compose up, docker compose down en docker compose logs. Wees voorzichtig met docker compose down -v, want de -v verwijdert benoemde volumes en daarmee de inhoud van je database.

Twee details zorgen vaak voor verwarring. Een groot deel van het deploy-blok hoort bij Swarm en wordt door docker compose up stilzwijgend genegeerd, waaronder placement, update_config, rollback_config, endpoint_mode en mode: global. De uitzonderingen zijn replicas, resources en restart_policy, die Compose wel respecteert, en met docker compose up --scale web=3 overschrijf je het aantal instanties tijdens het starten. De tweede valkuil is container_name: stel je die in, dan kan de service helemaal niet meer schalen, omdat twee containers niet dezelfde naam kunnen hebben.

Werken met Docker Hub

Docker Hub is de officiële registry van Docker om images te vinden, op te slaan en te delen. Naast miljoenen community-images staan er Docker Official Images en Verified Publisher-content. Een gratis account krijgt één private repository, betaalde abonnementen een onbeperkt aantal. Je haalt een publieke image zoals nginx of postgres binnen voor lokaal gebruik, en je pusht eigen images met de standaard-CLI naar een persoonlijke of organisatierepository.

Eén praktisch punt waar CI-pipelines regelmatig op stuklopen: Docker Hub hanteert limieten op het aantal pulls. Anonieme pulls worden per IP-adres begrensd, een geauthenticeerd Personal-account krijgt meer ruimte en betaalde abonnementen zijn onbeperkt. Haalt je pipeline images anoniem op vanaf een gedeeld netwerk of een cloud-runner, dan loop je vroeg of laat tegen die grens aan. Log in vanuit je pipeline, of spiegel de images waarvan je afhankelijk bent naar je eigen registry. De actuele limieten staan in de documentatie van Docker.

Data bewaren met volumes

Alles wat binnen een container wordt weggeschreven verdwijnt zodra die container wordt verwijderd. Om data te bewaren koppel je een volume, opslag die door Docker wordt beheerd en die losstaat van de levensduur van de container.

# Benoemd volume, beheerd door Docker
docker run -e POSTGRES_PASSWORD=example -v pgdata:/var/lib/postgresql/data postgres:17
 
# Bind mount, een map van de host in de container
docker run -v $(pwd)/src:/app/src my-app

Benoemde volumes zijn de juiste standaardkeuze voor databases en applicatiegegevens. Bind mounts zijn handig tijdens ontwikkeling, omdat wijzigingen op je host direct zichtbaar zijn in de container. Eén valkuil is het weten waard: een bind mount verbergt wat er op dat pad al in de image stond, en dat is een veelvoorkomende oorzaak van de klacht dat bestanden ineens verdwenen zijn.

Risico’s en nadelen

Docker levert echte voordelen op, maar het is verstandig om de beperkingen te kennen voordat je erop overstapt.

Leercurve en complexiteit

Docker kent een steile leercurve, vooral rond netwerken, opslag en de gelaagdheid van images. Eén container draaien is eenvoudig. Een productieomgeving beheren is dat niet, en de meeste teams komen op het punt dat ze een orkestrator zoals Kubernetes nodig hebben, met daarbovenop een tweede en veel steilere leercurve.

Uitdagingen rond persistente opslag

Standaard verdwijnt alle data in een container zodra die wordt verwijderd, tenzij die data eerst ergens anders is weggeschreven. Volumes en bind mounts lossen dat op, maar back-up en migratie blijven bewerkelijker dan bij een traditionele server, en de prestaties van containeropslag vallen vaker tegen. Veel teams houden hun primaire database in productie daarom bewust buiten Docker.

Beperkte ondersteuning voor grafische applicaties

Docker is ontworpen voor serverapplicaties zonder grafische interface. Een GUI-applicatie in een container draaien kan met X11-forwarding of een VNC-server, maar de inrichting is omslachtig en zelden de moeite waard buiten specifieke toepassingen zoals browsertesten.

Security en het aanvalsoppervlak van containers

Containers isoleren processen, maar ze delen de kernel van de host. Dat vergroot het aanvalsoppervlak: een kwetsbaarheid in die kernel heeft een grotere impact dan bij virtuele machines. Het vaker voorkomende probleem is simpeler dan dat: containers gebouwd op verouderde base images, draaiend als root, met secrets die in de imagelagen zijn meegebakken.

De maatregelen zijn bekend en goed uitvoerbaar. Pin base images en werk ze regelmatig bij, draai als gebruiker zonder rootrechten, scan images in de pipeline, houd secrets uit de image en injecteer ze bij het starten, en overweeg rootless mode, waarbij de daemon en de containers zonder rootrechten op de host draaien. Docker Scout laat kwetsbaarheden per imagelaag zien, en Docker Hardened Images bieden minimale, continu gepatchte base images met een ondertekend herkomstbewijs, voor teams die de herkomst van hun software moeten kunnen aantonen.

Wat kost Docker?

Docker Engine op Linux is gratis en open source. Waar je wel voor betaalt, zijn Docker Desktop en de diensten van Docker Hub en het Docker-platform eromheen.

Docker Desktop blijft gratis voor persoonlijk gebruik, onderwijs, opensourceprojecten en organisaties met minder dan 250 medewerkers en minder dan 10 miljoen dollar jaaromzet. Grotere organisaties, en overheidsinstanties ongeacht hun omvang, hebben een betaald abonnement nodig. De betaalde varianten heten Pro, Team en Business en worden per gebruiker per maand afgerekend. Daar horen onbeperkte pulls van Docker Hub, private repositories en centraal beheer bij, en op de hogere niveaus single sign-on. Docker publiceert de actuele grenzen en tarieven in de plans FAQ.

De kostenpost die organisaties verrast is niet de licentie. Het is het werk dat een containerplatform met zich meebrengt: registries, de levenscyclus van images, patchen, orkestratie en de mensen die dat begrijpen. Begroot dat voordat je aanneemt dat containers de operationele kosten verlagen.

Docker versus virtuele machines

Het verschil tussen containers en virtuele machines maakt duidelijk wanneer je wat gebruikt. Een virtuele machine virtualiseert een complete computer tot op hardwareniveau en draait een volledig gastbesturingssysteem. Een container virtualiseert alleen de applicatielaag en deelt de kernel van de host. Containers zijn daardoor lichter en sneller te starten, terwijl virtuele machines een stevigere isolatiegrens bieden.

Aspect	Docker-containers	Virtuele machines
Architectuur	Deelt de kernel van de host	Elke VM draait een eigen besturingssysteem
Resourcegebruik	Licht, megabytes per image	Zwaar, gigabytes per image
Starttijd	Seconden	Tientallen seconden tot minuten
Isolatie	Op procesniveau, gedeelde kernel	Op hardwareniveau, eigen kernel
Security	Gedeelde kernel vergroot de impact	Sterkere isolatiegrens
Portabiliteit	Zeer portabel als OCI-image	Minder portabel tussen hypervisors
Keuze besturingssysteem	Moet passen bij de kernel van de host	Elk ondersteund besturingssysteem
Typisch gebruik	Microservices, CI/CD, cloud-native apps	Multi-tenancy, legacy, strikte isolatie

In de praktijk vullen ze elkaar aan in plaats van dat ze concurreren. De meeste containers in productie draaien binnen virtuele machines van een cloudprovider. Dat geeft je de isolatie van een VM op de grens tussen klanten en de dichtheid van containers daarbinnen.

Docker versus Podman, containerd en Kubernetes

Docker is niet de enige manier om containers te draaien, en de alternatieven worden vaak als concurrenten gezien terwijl ze op een andere laag zitten.

• Podman is een daemonloze container-engine, ontstaan bij Red Hat en inmiddels een CNCF Sandbox-project, die standaard rootless draait en een CLI heeft die grotendeels gelijk is aan die van Docker. Het spreekt teams met strenge beveiligingseisen en Red Hat-omgevingen aan, en het bouwt en draait dezelfde OCI-images.
• containerd is de laag eronder, de runtime die Docker Engine zelf gebruikt en waar Kubernetes rechtstreeks mee praat. Het is infrastructuur in plaats van een ontwikkeltool, dus je gebruikt het zelden met de hand.
• Kubernetes is een orkestrator en geen alternatief voor Docker. Het plant en beheert containers over een cluster van machines en draait dezelfde images die Docker bouwt. Kubernetes verwijderde in versie 1.24 zijn Docker-specifieke shim, wat veel verwarring gaf, maar in de praktijk veranderde er voor ontwikkelaars niets: images die met Docker zijn gebouwd draaien gewoon op Kubernetes.

Voor de meeste teams is het verstandige antwoord dat je lokaal met Docker bouwt en draait op wat je platform biedt. Omdat het imageformaat gestandaardiseerd is, blijft die keuze omkeerbaar.

Wanneer kun je Docker beter niet gebruiken?

Containers zijn met goede reden de standaard geworden, maar ze kosten je wel iets en ze zijn niet altijd het juiste antwoord.

• Voor één kleine applicatie op één server die zelden verandert, voegt een container een laag tooling toe zonder dat het een probleem oplost dat je werkelijk hebt.
• Voor desktopsoftware met een grafische interface werkt het containermodel eerder tegen je dan voor je.
• Voor workloads die een andere kernel nodig hebben dan die van de host, zoals Windows-applicaties op Linux-hosts, heb je een virtuele machine nodig.
• Voor harde isolatie tussen workloads die je niet vertrouwt, is de gedeelde kernel een reëel risico en zijn virtuele machines of microVM’s de veiligere grens.
• Voor stateful databases in productie kiezen veel teams nog steeds voor een managed service of een dedicated server, en zetten ze containers alleen in voor de stateless lagen.

De vraag die telt is of je een omgevingsprobleem, een schaalprobleem of een probleem met opleversnelheid hebt. Is dat zo, dan verdient Docker zijn complexiteit terug. Zo niet, dan is het overhead.

Conclusie

Docker heeft het denken over het uitrollen van applicaties veranderd. Containers zijn nu de vanzelfsprekende vorm waarin software wordt opgeleverd, geen optie meer die je afweegt. De interessante ontwikkelingen zitten niet meer in de runtime, die stabiel en gestandaardiseerd is, maar in alles wat eromheen staat.

Twee richtingen zijn het volgen waard. De eerste is beveiliging van de toeleveringsketen: ondertekende herkomst, een software bill of materials en minimale hardened base images zijn van compliance-oefening naar standaardverwachting geschoven, mede gedreven door regelgeving zoals de Europese Cyber Resilience Act. De tweede is AI. Containers zijn het verpakkingsformaat geworden voor modellen, inferentieservers en agent-tooling, en Docker heeft die vraag gevolgd met Model Runner, de MCP Toolkit en geïsoleerde sandboxen voor coding agents.

Voor organisaties betekent dat vooral dat containerkennis nu op het kritieke pad ligt voor zowel softwareoplevering als het uitrollen van AI. De leercurve is stevig, maar wat je ervoor terugkrijgt zijn consistente omgevingen, reproduceerbare deployments en infrastructuurkeuzes die omkeerbaar blijven.

Veelgestelde vragen (FAQ) over Docker

Zet de volgende stap met DataNorth AI

Containerisatie is zelden het lastigste deel van een project. Bepalen wat er in een container hoort, hoe images worden gebouwd en gepatcht, waar de data staat en hoe deployments worden beheerd, dáár gaat de tijd in zitten, en daar levert meekijken van buitenaf het meeste op.

Bij DataNorth AI werken we daar met organisaties aan: het ontwerpen van containerarchitecturen voor AI- en softwareworkloads, het inrichten van build- en deploypipelines die elke keer hetzelfde artefact opleveren, het verhuizen van bestaande applicaties naar containers zonder ze te breken, en het inregelen van imagebeveiliging en kwetsbaarheidsscans voordat het een auditbevinding wordt. In de meeste gevallen is dit een praktisch onderdeel van een bredere digitale transformatie, geen project op zichzelf.

Overweeg je containerisatie, of gebruik je Docker al en wil je dat iemand meekijkt met je inrichting? Neem contact op met DataNorth AI en we nemen je situatie samen door.