Docker-Setups für Python sind kein Nice-to-have mehr.
Sie sind Pflicht. Oder sollten es sein. Stellt euch euer Team vor: Um 9 Uhr Slack-Pings, ModuleNotFoundErrors überall, der Windows-Typ schwört Stein und Bein, sein Code sei perfekt. Klingt vertraut? Das war bei uns fünf Monate lang Realität. Peinlich.
Der Originalbeitrag trifft’s auf den Punkt. „Fünf Monate ‚Bei mir läuft’s‘. Fünf Monate Einarbeitungsfrust. Fünf Monate verschwendete Stunden.“ Auweia. Das ist kein Geständnis – das ist Produktivitäts-Massaker. Und klar, niemand gibt zu, dass er das hat eitern lassen. Aber die bittere Wahrheit: Kämpft ihr 2024 noch mit lokalen Env-Höllen, seid ihr das Problem.
Warum lokale Python-Setups ein totales Fiasko sind
Jedes Dev-Laptop? Ein Frankenstein-Monster. Jahre halbgarer pip-Installs, PATH-Hacks, Geisterpakete von Tools, die ihr falsch deinstalliert habt. Macs, Windows, Linux – jedes ein Unikat aus Schmerz. requirements.txt? Süß. Virtualenvs? Besser, aber zerbrechlich wie Glas. Ein Python-Minor-Update – 3.10.4 auf 3.10.11 – und zack, Deprecation-Apokalypse.
Wir haben einen Demo-Vorbereitungstag damit versaut. Drei Stunden Luftdebuggen. Erbärmlich.
Docker dreht den Spieß um. Euer Interpreter lebt nicht mehr auf dem Laptop. Er lebt im Projekt. Dockerfile diktiert: Python-Version, Deps, OS-Basis. Einmal bauen, überall laufen. Keine Ausreden.
Und VS Codes Dev Containers? Küsschen drauf. Es tunnelt rein – Terminal, Debugger, IntelliSense, alles containerisiert. Fühlt sich lokal an. Ist’s nicht. genial.
Wir hatten eine requirements.txt. Wir hatten Virtual Environments. Wir hatten ein gut gemeintes README mit Setup-Anweisungen, die schon sechs Wochen veraltet waren. Was wir nicht hatten: Garantie, dass der Python-Interpreter auf meinem Windows-Rechner dieselbe Welt sah wie der auf dem MacBook meines Kollegen oder der Ubuntu-Workstation des Dritten.
Voll ins Schwarze. Das ist der Geist, der jedes Team heimsucht.
Docker-Python-Setup: Der Guide ohne Füllmaterial
Nicht komplizieren. So haben wir’s gebaut. Projektwurzel:
my-project/ ├── .devcontainer/ │ └── devcontainer.json ├── Dockerfile ├── requirements.txt └── main.py
Dockerfile zuerst. Hammer-einfach:
FROM python:3.14.3-slim
RUN apt-get update && apt-get install -y --no-install-recommends git curl && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
Slim-Image? Klug – wirft Ballast ab, lädt schneller bei Scheiß-Verbindungen. WORKDIR /app? Vorhersehbare Pfade, keine Mapping-Kopfschmerzen. requirements.txt zuerst? Layer-Caching-Zauberei. Code ändert sich? Rebuild überspringt pip. Effizienz pur.
Jetzt devcontainer.json in .devcontainer/. Das verkabelt VS Code:
{
"name": "Python Dev",
"dockerfile": "../Dockerfile",
"workspaceFolder": "/app",
"features": {
"ghcr.io/devcontainers/features/python:1": {
"version": "3.14.3"
}
}
}
Reopen in Container anklicken. Zack – VS Code erwacht in Docker. Eure Extensions? Bleiben draußen. Terminal? Container-rein. Debugger? Springt an.
Ein Nachmittag Arbeit. Monate gerettet.
Ist Docker für euer Python-Team Overkill?
Auf keinen Fall. Solo-Dev? Trotzdem machen. Warum? Zukunft-ihr dankt’s euch 2027, wenn ihr das Repo abstaubt. Contractor einarbeiten? Minuten statt Tage.
Mein Hot Take – der Punkt, den keiner laut sagt: Das ist Pythons ‚npm install‘-Moment aus Nodes Steinzeit. Erinnert ihr an 2010? Node-Devs ertrinken in Shrinkwrap-Hölle, Versionen prallen aufeinander wie Scheidungskrieg. Yarn fixte die Hälfte; Docker alles. Pythons pipenv-poetry-conda-Kriege? Vorbei. Container siegen. Fetter Vorhersage-Tipp: Bis 2026 schlägt GitHub devcontainer.json für jedes Python-Repo vor. Ignoriert auf eigene Gefahr.
Corporate-Jargon nennt das „reproduzierbare Builds“. Quatsch – das ist Wahnsinnsversicherung.
Kritik am Original: Autor wartete fünf Monate. Warum? Faulheit? Angst vor Dockers ‚schwer‘-Ruf? Docker
