Docker init: Zo initialiseer je een project met Docker (stap-voor-stapgids)

Om de een of andere reden duurt het opzetten van een nieuw project met Docker altijd langer dan zou moeten.

Je Googelt een template, plakt het erin, past een paar regels aan en hoopt op het beste. De build faalt, dus ga je finetunen en herhaal je de cyclus tot het werkt. Elk nieuw project begint hetzelfde: met een leeg bestand en een vage herinnering aan wat de vorige keer werkte. Dit is duidelijk een setupprobleem, en Docker is niet de schuldige.

Het goede nieuws is dat docker init dit oplost. Het is een CLI-commando dat je projecttype detecteert en een Dockerfile, .dockerignore en een Compose-bestand genereert.

In dit artikel laat ik je zien hoe docker init werkt, hoe je het stap voor stap gebruikt met een echt Python-project en wanneer het de juiste tool is voor de klus.

Ben je helemaal nieuw met Docker en containerization? Ontdek waarom het een essentieel onderdeel is van de toolkit van een dataprofessional met onze Introduction to Docker-cursus.

Wat is Docker init

docker init is een CLI-tool die Docker-configuratie voor je project opzet. Het genereert de bestanden die je nodig hebt om je app te containerizen. Je hebt dus geen templates of copy-paste meer nodig.

Het produceert drie bestanden:

• Dockerfile - definieert hoe je containerimage wordt gebouwd
• .dockerignore - vertelt Docker welke bestanden het moet weglaten uit de buildcontext
• compose.yml - optioneel, maar handig voor multi-service-opzetten

Het slimme deel is automatische projectdetectie. docker init kijkt naar je projectstructuur en bepaalt welke stack je gebruikt - Python, Node.js, Go en andere. Vervolgens genereert het bestanden op basis van die stack in plaats van met een generiek template te komen.

Het is geen deploymenttool en het beheert je containers niet in productie. Het zorgt er alleen voor dat je configuratie van start kan, zodat jij je op het echte werk kunt richten.

Hoe Docker init werkt

docker init volgt een flow van vier stappen elke keer dat je het draait.

Eerst draai je docker init binnen je projectmap. Docker scant de directory, detecteert je projecttype en kiest de juiste configuratietemplate. Daarna leidt het je door een korte reeks interactieve prompts - dingen als op welke poort je app draait en welk commando deze start. Zodra je die beantwoordt, genereert het je bestanden.

Het hele proces duurt minder dan een minuut.

De prompts zijn eenvoudig te beantwoorden en hebben zelden extra uitleg nodig. Je kunt de standaardwaarden accepteren door op Enter te drukken, of je eigen waarden invullen als de defaults niet werken. 

Dit is wat je ziet wanneer je het commando voor het eerst draait:

Docker init-setupscherm

Ik laat je dit proces zo meteen in meer detail zien.

Docker init stap voor stap gebruiken

Hier is een overzicht van hoe je van een projectmap naar een draaiende container gaat.

Stap 1: Navigeer naar je projectdirectory

Open je terminal en navigeer naar de root van je project - de map die je applicatiecode bevat.

cd /path/to/your/project

docker init genereert bestanden relatief ten opzichte van waar je het draait, dus zorg dat je in de juiste directory bent voordat je verdergaat.

Stap 2: Draai Docker init

Voer het volgende commando uit:

docker init

Docker scant je projectmap, detecteert je stack en start de interactieve setupprompt.

Stap 3: Beantwoord de prompts

docker init stelt je een paar vragen:

• Applicatieplatform - de taal of het framework dat je project gebruikt (Python, Node.js, Go, enz.)
• Poort - de poort waar je app op luistert
• Startcommando - het commando dat Docker moet draaien om je app te starten

Je kunt de voorgestelde standaardwaarden accepteren door op Enter te drukken, of je eigen waarden invoeren. Als docker init je stack detecteert, zijn de defaults meestal goed genoeg om te beginnen.

Stap 4: Bekijk de gegenereerde bestanden

Zodra je de prompts hebt beantwoord, schrijft docker init drie bestanden naar je projectmap:

.
├── Dockerfile
├── .dockerignore
└── compose.yaml

Open elk bestand en lees het door. De gegenereerde bestanden bevatten comments die uitleggen wat elke regel doet, dus het is de moeite waard om een paar minuten te nemen om te begrijpen wat er is aangemaakt voordat je iets bouwt.

Stap 5: Bouw en draai je container

Bouw en start je container met Docker Compose:

docker compose up --build

De vlag --build vertelt Docker om de image vanuit je Dockerfile te bouwen voordat de container wordt gestart. Zodra deze draait, zou je app bereikbaar moeten zijn op de poort die je in stap 3 hebt opgegeven.

Ondersteunde projecttypen in Docker init

docker init ondersteunt de meest gangbare applicatiestacks out of the box. Hier zijn er een paar:

• Python
• Node.js
• Go
• Java
• .NET

Het detecteert de stack automatisch. Wanneer je docker init draait, scant het je projectmap op taalspecifieke bestanden - dingen als requirements.txt voor Python of package.json voor Node.js - en kiest het juiste template op basis van wat het vindt.

Elk template is toegespitst op de stack. Een Python-project krijgt een andere base image, installcommando's en startcommando dan een Go-project. Je krijgt niet één generieke Dockerfile met alleen een taalvariabele die wordt vervangen. De structuur zelf verandert afhankelijk van wat je bouwt.

Als docker init je stack niet kan detecteren, vraagt het je om er handmatig een te kiezen uit de lijst.

Bestanden die door Docker init worden gegenereerd

docker init genereert drie bestanden, en elk heeft een andere rol in je setup.

Dockerfile

De Dockerfile definieert hoe Docker je containerimage bouwt. Het vertelt Docker vanaf welke base image te starten, hoe je afhankelijkheden te installeren en welk commando te draaien wanneer de container start.

Hier is een voorbeeld van hoe een gegenereerde Python-Dockerfile eruitziet:

FROM python:3.14-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Je wilt dit bestand even nakijken voordat je gaat bouwen. De gegenereerde output is een goed startpunt, maar mogelijk moet je het finetunen - bijvoorbeeld om omgevingsvariabelen toe te voegen of de versie van de base image aan te passen.

.dockerignore

Het .dockerignore-bestand vertelt Docker welke bestanden moeten worden uitgesloten van de buildcontext. Dit is de set bestanden die Docker naar de buildengine stuurt bij het maken van je image.

Zonder dit bestand zou Docker alles in je projectmap in de image kopiëren, inclusief dingen als .git, node_modules of lokale configbestanden die je niet in productie nodig hebt. Dat vergroot je image en kan bestanden blootstellen die je niet wilde meenemen.

Een typische .dockerignore ziet er zo uit:

.git
.env
__pycache__
*.pyc
node_modules

Docker Compose-bestand

Het bestand compose.yaml is voor het draaien van multi-container-opzetten. Het definieert je services, poorten, volumes en hoe containers met elkaar verbinden.

Voor een eenvoudige single-container-app heb je het misschien niet nodig. Maar als je project een database, cache of andere service naast je app omvat, is het Compose-bestand de plek waar je dat allemaal op één plek configureert.

Voorbeeld: Docker init gebruiken met een Python-project

Laten we docker init op een echt project draaien. Ik gebruik een minimale FastAPI-app met één route als voorbeeld.

Dit is de projectstructuur vóór het draaien van docker init:

my-fastapi-app/
├── app.py
└── requirements.txt

app.py heeft één Hello World-route:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello, World!"}

En requirements.txt bevat deze twee dependencies:

fastapi
uvicorn

docker init draaien

Ga om te beginnen naar de projectmap en draai:

docker init

Docker init project gedetecteerd

docker init detecteert Python via requirements.txt en stelt je een paar vragen. Zo zien de prompts eruit en dit kun je beantwoorden:

Docker init-prompts voor een Python-project

Wat er wordt gegenereerd

Na het beantwoorden van de prompts ziet je projectmap er zo uit:

Nieuwe projectmapstructuur

Er zijn drie nieuwe bestanden. Laten we elk van hen bekijken.

De Dockerfile

# syntax=docker/dockerfile:1

ARG PYTHON_VERSION=3.14
FROM python:${PYTHON_VERSION}-slim as base

ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1

WORKDIR /app

ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser

RUN --mount=type=cache,target=/root/.cache/pip \
    --mount=type=bind,source=requirements.txt,target=requirements.txt \
    python -m pip install -r requirements.txt

USER appuser

COPY . .

EXPOSE 8000

CMD uvicorn 'app:app' --host=0.0.0.0 --port=8000

Een paar dingen vallen op. PYTHONDONTWRITEBYTECODE=1 voorkomt dat Python .pyc-bestanden naar disk schrijft, en PYTHONUNBUFFERED=1 zorgt dat logs realtime verschijnen in plaats van in een buffer te blijven hangen - beide zijn goede defaults voor gecontainerizeerde apps.

Het adduser-blok maakt een niet-geprivilegieerde gebruiker genaamd appuser aan om de applicatie te draaien. Standaard draaien Docker-containers als root, wat een beveiligingsrisico is. Draaien als niet-root beperkt wat een aanvaller kan doen als die uit je app weet te breken.

De vlag --mount=type=cache bij de stap pip install vertelt Docker om gedownloade pakketten tussen builds te cachen. Hierdoor hoeven volgende builds dependencies niet opnieuw from scratch te downloaden, wat de boel versnelt.

De .dockerignore

**/.DS_Store
**/__pycache__
**/.venv
**/.env
**/.git
**/.gitignore
**/node_modules
**/Dockerfile*
**/compose.y*ml
README.md

Het .dockerignore-bestand sluit bestanden uit die niet in je image thuishoren. Lokale omgevingsbestanden zoals .env, versiebeheermappen zoals .git en Python-cachebestanden zoals __pycache__ worden allemaal overgeslagen. De Dockerfile en compose.yaml zelf zijn ook uitgesloten - Docker heeft ze niet nodig binnen de image die het bouwt.

De compose.yaml

services:
  server:
    build:
      context: .
    ports:
      - 8000:8000

Het Compose-bestand definieert je app als een service genaamd server, bouwt deze vanuit de Dockerfile in de huidige directory en koppelt poort 8000 op je host aan poort 8000 binnen de container.

Alle drie de gegenereerde bestanden bevatten wat comments die ik heb weggelaten om het overzichtelijk te houden.

Draai docker compose up --build en je FastAPI-app staat live op http://localhost:8000.

FastAPI-app draait in een container

Docker init vs handmatige Dockerfile-setup

Beide aanpakken leveren je een werkende Dockerfile op, dus het gaat erom hoeveel controle je nodig hebt en hoe snel je daar wilt komen.

Docker init

docker init is de snellere optie. Je beantwoordt een paar prompts en krijgt in minder dan een minuut een werkende, redelijk veilige configuratie. De gegenereerde bestanden volgen Docker’s eigen best practices - niet-rootgebruikers, buildcaching, juiste .dockerignore-patronen - zodat je niet from scratch begint.

Het is een goede match wanneer je een nieuw project start, een teamgenoot inwerkt of gewoon een solide basis wilt zonder tijd aan boilerplate te besteden.

Maar er is een vraagstuk van flexibiliteit. De templates dekken gangbare stacks goed af, maar het blijven templates. Als je project een ongebruikelijke structuur of specifieke buildvereisten heeft, loop je tegen de grenzen aan van wat docker init kan genereren.

Handmatige setup

Je Dockerfile met de hand schrijven geeft je volledige controle over elke laag, elke instructie en elke buildbeslissing. Je kunt multi-stage builds implementeren om de imagegrootte te minimaliseren, aangepaste base images gebruiken of cachinggedrag finetunen op manieren die docker init niet kan voorzien.

Maar dan moet je wel weten wat je doet. Een slecht geschreven Dockerfile kan te grote images opleveren, beveiligingsproblemen introduceren of falen op manieren die lastig te debuggen zijn, zeker als je nog niet ervaren bent.

Welke kies je

Zo kun je er eenvoudig over nadenken:

Docker init versus handmatige setup vergeleken

Een goede aanpak is om te beginnen met docker init en de gegenereerde bestanden daarna handmatig te bewerken naarmate je eisen groeien.

Wanneer gebruik je Docker init

docker init is niet in elke situatie de juiste tool. Dit is wanneer het logisch is en wanneer niet.

Kies voor docker init wanneer:

• Je een nieuw project start: Het krijgt je Docker-configuratie binnen een minuut van de grond, zodat jij je kunt focussen op code schrijven in plaats van containerization opzetten

• Je Docker aan het leren bent: De gegenereerde bestanden zijn goed becommentarieerd en volgen best practices. Ze zijn een beter startpunt dan een willekeurige Stack Overflow-snippet

• Je aan het prototypen bent: Wanneer je snel een gecontainerizeerde omgeving nodig hebt en het fijnslijpen van de build niet uitmaakt, geeft docker init je iets dat werkt

• Je aan het standaardiseren bent binnen een team: In plaats van dat elke developer z’n eigen Dockerfile maakt, geeft docker init iedereen een consistent startpunt met dezelfde structuur en defaults

Dat gezegd hebbende, sla docker init over wanneer:

• Je multi-stage builds nodig hebt: Als je de imagegrootte optimaliseert door je build in aparte stages te splitsen - compileren in de ene, draaien in de andere - moet je dat handmatig schrijven. De gegenereerde Dockerfile is single-stage

• Je complexe productievereisten hebt: Aangepaste base images, geavanceerde cachingstrategieën, niet-standaard projectindelingen - dat zijn geen dingen die docker init kan voorzien. Je besteedt meer tijd aan het omzeilen van de gegenereerde bestanden dan aan het zelf schrijven ervan

Kortom, docker init is een startpunt. Gebruik het om op gang te komen en bewerk de gegenereerde bestanden naarmate je behoeften groeien.

Beperkingen van Docker init

Naarmate je project groeit, kun je tegen beperkingen aanlopen. Hier zijn er een paar.

De gegenereerde bestanden zijn template-based. Ze zijn ontworpen om de meest voorkomende gevallen per ondersteunde stack te dekken, wat betekent dat ze goed werken voor gangbare projecten en minder goed voor alles daarbuiten. Als je project een ongebruikelijke structuur heeft, houden de gegenereerde bestanden daar misschien geen rekening mee.

Een andere veelvoorkomende beperking is dat handmatige tuning bijna altijd nodig is. De defaults zijn goed, maar het blijven defaults. Je zult waarschijnlijk de versie van de base image moeten aanpassen, omgevingsvariabelen bijstellen of het startcommando wijzigen voordat de configuratie bij je project past. Zie de gegenereerde bestanden als een eerste versie, niet meer dan dat.

docker init ondersteunt ook geen geavanceerde buildpatronen. Multi-stage builds, aangepaste buildargumenten, voorwaardelijke logica en andere technieken waar ervaren Docker-gebruikers op vertrouwen voor productieimages vallen buiten de scope van wat de tool genereert. Maar als je dat nodig hebt, schrijf je de Dockerfile sowieso zelf.

Geen van dit alles maakt docker init een slechte tool. Het betekent alleen dat je met de juiste verwachtingen moet beginnen - het haalt het blanco-pagina-probleem weg, maar vervangt niet de noodzaak om te begrijpen wat er in je Dockerfile staat.

Best practices na het gebruik van Docker init

De bestanden die docker init genereert zijn een startpunt. Dit zijn de stappen die je moet nemen om ze productierijp te maken.

• Bekijk de gegenereerde bestanden: Lees de Dockerfile, .dockerignore en compose.yaml regel voor regel door. De bestanden zijn goed becommentarieerd, dus dit kost niet veel tijd. Je wilt begrijpen wat er staat voordat je erop voortbouwt

• Optimaliseer je imagegrootte: De standaard base image is python:3.x-slim, wat al een lichte keuze is. Maar je kunt verder gaan door te zorgen dat je .dockerignore alles uitsluit wat het moet, en te controleren dat je geen bestanden in de image kopieert die daar niet hoeven te staan

• Verplaats secrets en omgevingsspecifieke waarden naar omgevingsvariabelen: Hardcode geen API-sleutels, database-URL’s of omgevingsflags in je Dockerfile. Gebruik omgevingsvariabelen en beheer ze lokaal via een .env-bestand of via het secret management van je deploymentplatform in productie

• Test lokaal voordat je iets pusht: Draai docker compose up --build en verifieer dat je app zich binnen de container hetzelfde gedraagt als daarbuiten. Check je logs, ga naar je endpoints en bevestig dat de poortmapping werkt

• Verfijn je buildstappen naarmate het project groeit: De gegenereerde Dockerfile installeert dependencies in één laag. Naarmate je project volwassener wordt, denk na over de volgorde van lagen. Zet stappen die minder vaak veranderen eerder in het bestand zodat Docker ze kan cachen. Als je buildtijden oplopen, is dat meestal de eerste plek om te kijken

Veelvoorkomende issues en troubleshooting

Zoals altijd in tech kan er van alles misgaan. Hier is waar je op moet letten en hoe je het oplost.

Onjuiste projectdetectie

Als docker init de verkeerde stack kiest, genereert het bestanden die niet bij je project passen. Dit gebeurt meestal wanneer je projectmap bestanden in meerdere talen bevat of het bestand mist waar docker init naar zoekt - zoals requirements.txt voor Python of package.json voor Node.js.

Wanneer de prompt om je applicatieplatform vraagt, selecteer dan handmatig de juiste in plaats van de gedetecteerde default te accepteren.

Poortconflicten

Als je container start maar je je app niet kunt bereiken, of Docker een fout geeft over een poort die al in gebruik is, draait er waarschijnlijk een ander proces op je machine op dezelfde poort.

Zoek en stop het conflicterende proces, of wijzig de poort aan hostzijde in je compose.yaml:

ports:
  - 8001:8000  # maps host port 8001 to container port 8000

De linkerkant is de poort op je machine. De rechterkant moet overeenkomen met wat je app binnen de container beluistert.

Ontbrekende dependencies

Als je container bouwt maar crasht bij het starten, zijn ontbrekende dependencies vaak de oorzaak. Controleer of je requirements.txt (of equivalent) volledig en up-to-date is. Als je lokaal een pakket hebt toegevoegd zonder dat bestand bij te werken, heeft de container het niet.

Draai docker compose logs om de foutoutput te zien:

docker compose logs

De foutmelding vertelt meestal precies welk pakket ontbreekt.

Container start niet

Als de container helemaal niet wil starten, zit het probleem bijna altijd in de CMD-regel van je Dockerfile. Controleer of het startcommando overeenkomt met hoe je je app daadwerkelijk draait.

Voor het FastAPI-voorbeeld zou het er zo uit moeten zien:

CMD uvicorn 'app:app' --host=0.0.0.0 --port=8000

Als je entrypoint-bestand een andere naam heeft of het pad naar de module niet klopt, stopt de container. Corrigeer de CMD, rebuild met docker compose up --build en check de logs opnieuw.

Conclusie

docker init vervangt geen diepgaand begrip van Docker, maar het haalt wel het blanco-pagina-probleem weg.

Met één commando krijg je een werkende Dockerfile, .dockerignore en compose.yml - allemaal volgens Docker’s eigen best practices. Dat is een goede basis voor elk nieuw project en een veel beter startpunt dan een gekopieerd template van Stack Overflow of ChatGPT.

Stop daar alleen niet. De gegenereerde bestanden zijn bedoeld om te worden bewerkt. Bekijk ze, pas de buildstappen aan, pin de versie van je base image vast en voeg je omgevingsvariabelen toe. Naarmate je project groeit, wijk je steeds verder af van de defaults.

Als je de basis van Docker kent, is de logische volgende stap om te leren over multi-stage builds, networking-tools en Docker Compose - dit alles komt aan bod in onze Intermediate Docker -cursus.