Du brauchst tatsächlich nur einen kleinen Kern, um sichere, wartbare Services zu deployen. Hier die Essenz:

1. Grundkonzepte (wichtiger als jeder Befehl)

• Image: unveränderliches Template, gebaut aus einem Dockerfile
• Container: laufende Instanz eines Images
• Registry: wo Images gespeichert werden (Docker Hub, private Registry, GitHub Container Registry …)
• Volume: persistenter Speicher außerhalb des Containers (Container selbst sind flüchtig!)
• Network: wie Container sich untereinander erreichen

Alles andere ist Ausschmückung dieser fünf Begriffe.

2. Dockerfile – das Wesentliche

Nur diese Instruktionen brauchst du wirklich: FROM, WORKDIR, COPY, RUN, ENV, EXPOSE, CMD/ENTRYPOINT.

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
RUN useradd -m appuser && chown -R appuser /app
USER appuser
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Best Practices, die 90% der Probleme verhindern:

• requirements.txt vor COPY . . kopieren → Docker cached den pip-install-Layer, solange sich Dependencies nicht ändern (schnellere Builds)
• Nie :latest in Produktion – immer Version pinnen (python:3.12-slim, nicht python:latest)
• Multi-Stage-Builds bei kompilierten Sprachen oder wenn Build-Tools nicht ins Runtime-Image sollen
• .dockerignore (analog zu .gitignore) – sonst landen .env, .git, venv/ etc. im Image
• Nicht als root laufen (USER appuser)

3. Docker CLI – die Befehle, die du wirklich brauchst

docker build -t myservice:1.0 .
docker run -d -p 8080:8000 --name myservice myservice:1.0
docker ps                    # laufende Container
docker ps -a                 # alle Container
docker logs -f myservice     # Logs live verfolgen
docker exec -it myservice bash   # reinschauen/debuggen
docker stop myservice && docker rm myservice
docker images
docker system prune -a       # Aufräumen (Speicherplatz)

Das ist wirklich schon der Großteil, den man im Alltag braucht.