Möchtest du das nicht manuell einrichten? Füge einen Link zu dieser Seite in eine Devin-Sitzung ein und bitte Devin, alles für dich einzurichten. Wenn du dir nicht sicher bist, von welchen Services deine Django‑App abhängt oder wie das Projekt aufgebaut ist, nutze [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery), um das zuerst zu analysieren: ```txt Analysiere das Django-Projekt für die Containerisierung theme={null} Auf welche Komponenten ist unsere Django-App in src/ angewiesen? 1. Mit welchen Datenbanken und Caches verbindet sie sich? 2. Verwendet sie Celery oder andere Background-Worker? 3. Was steht in requirements.txt oder pyproject.toml? 4. Gibt es bereits Dockerfiles oder Deployment-Konfigurationen? 5. Wie verarbeitet die App statische Dateien und Medien? ``` Du kannst auch direkt aus Ask Devin eine Devin-Session starten; dabei werden alle bisherigen Erkenntnisse als Kontext übernommen. Weise Devin an, das Django-Projekt zu containerisieren, und erwähne alle Besonderheiten – etwa bevorzugte Basis-Images, Dienste, von denen die App abhängt, oder Einschränkungen bei der Image-Größe. Devin liest deine `requirements.txt` oder `pyproject.toml`, um den Rest herauszufinden. ```txt Django-API mit Postgres und Redis dockerisieren theme={null} Dockerisiere die Django-API in src/. Sie verwendet PostgreSQL für die Datenbank und Redis für Caching und Celery-Task-Queues. - Multi-Stage-Dockerfile: Installiere Abhängigkeiten in einer Builder-Stage und kopiere nur das venv in ein schlankes python:3.12-slim-Runtime-Image - docker-compose.yml mit Django (gunicorn), PostgreSQL 16 und Redis 7 - .dockerignore, das tests, docs, .git und __pycache__ ausschließt - Als Non-Root-User ausführen - Health-Check auf /api/health/ - Celery-Worker als separater Service in Compose ## Testen & Verifikation - Baue das Image und führe docker-compose up aus - Warte, bis alle Services als „healthy“ markiert sind - Überprüfe, dass die API auf localhost:8000/api/health/ antwortet - Führe die Django-Test-Suite im Container aus - Wenn irgendetwas fehlschlägt – Build-Fehler, fehlende Umgebungsvariablen, Verbindungsprobleme, fehlschlagende Tests – analysiere und behebe sie. Iteriere weiter, bis der gesamte Stack sauber startet und alle Tests bestehen. - Öffne keinen PR, bevor nicht alles End-to-End funktioniert ``` Devin liest Ihr Django-Projekt und die Abhängigkeitsdateien, um den Build-Prozess zu verstehen, und erstellt dann die Docker-Konfiguration: 1. **Liest Abhängigkeitsdateien** — Parst `requirements.txt` oder `pyproject.toml` und identifiziert Django, psycopg2, redis, celery und gunicorn 2. **Schreibt das Dockerfile** — Erstellt einen mehrstufigen Build, der Abhängigkeiten in einer Builder-Stage installiert und die virtuelle Umgebung in ein minimales `python:3.12-slim`-Laufzeit-Image kopiert ```dockerfile theme={null} # ---- Builder ---- FROM python:3.12-slim AS builder WORKDIR /app COPY requirements.txt . RUN python -m venv /opt/venv \ && /opt/venv/bin/pip install --no-cache-dir -r requirements.txt # ---- Runtime ---- FROM python:3.12-slim RUN groupadd -r django && useradd -r -g django django COPY --from=builder /opt/venv /opt/venv ENV PATH="/opt/venv/bin:$PATH" WORKDIR /app COPY src/ . RUN python manage.py collectstatic --noinput EXPOSE 8000 USER django CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "3"] ``` 3. **Erstellt docker-compose.yml** — Fügt Django, PostgreSQL, Redis und einen Celery-Worker mit Healthchecks, Volumes und einem gemeinsamen Netzwerk hinzu ```yaml theme={null} services: web: build: . ports: - "8000:8000" env_file: .env depends_on: db: condition: service_healthy redis: condition: service_healthy healthcheck: test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/api/health/')"] interval: 10s retries: 3 db: image: postgres:16-alpine environment: POSTGRES_DB: app_db POSTGRES_USER: app_user POSTGRES_PASSWORD: app_pass volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U app_user -d app_db"] interval: 5s retries: 5 redis: image: redis:7-alpine healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 5s retries: 5 celery: build: . command: celery -A config worker -l info env_file: .env depends_on: db: condition: service_healthy redis: condition: service_healthy volumes: pgdata: ``` 4. **Fügt .dockerignore hinzu** — Schließt Dateien aus, die nicht in den Build-Kontext gehören (`__pycache__`, `.git`, `tests/`, `docs/`, `*.pyc`) 5. **Führt `docker compose up --build` aus** — Baut das Image und startet alle Services im Devin-Terminal 6. **Überprüft die App** — Führt einen curl-Aufruf auf `/api/health/` aus, um zu bestätigen, dass Django sauber startet, sich mit PostgreSQL verbindet und Redis erreicht Verwenden Sie während der Sitzung Slash-Befehle, um den Devin-Workflow zu steuern: * **`/plan`** — Bitten Sie Devin, seinen Ansatz zu skizzieren, bevor es eine Docker-Konfiguration schreibt. Überprüfen Sie den Plan und schlagen Sie Änderungen vor. * **`/test`** — Weisen Sie Devin an, den Container-Stack neu aufzubauen und erneut zu überprüfen. Verwenden Sie diesen Befehl nach jeder Änderung, um Probleme frühzeitig zu erkennen. * **`/review`** — Bitten Sie Devin, sein eigenes Dockerfile und die Docker-Compose-Konfiguration auf Sicherheitsprobleme, Imagegröße und Best Practices zu prüfen, bevor der PR erstellt wird. Sobald Devin den Pull Request (PR) eröffnet, überprüfe die generierten Dateien. Häufige Folgeaufgaben: ```txt Imagegröße optimieren theme={null} Das Docker-Image ist 520 MB groß. Verkleinere es – stelle sicher, dass wir keine unnötigen Dateien kopieren, entferne .pyc-Dateien aus dem venv und entferne pip aus dem finalen Image. ``` ```txt Dev-Hot-Reload hinzufügen theme={null} Füge eine docker-compose.override.yml für die lokale Entwicklung hinzu, die das Quellverzeichnis mountet und den Django-Dev-Server mit Auto-Reload anstelle von gunicorn ausführt. ``` ```txt CI-Docker-Build hinzufügen theme={null} Erstelle einen GitHub-Actions-Workflow, der das Docker-Image für jeden PR baut, pytest im Container ausführt und es bei einem Merge nach main in ECR pusht. Tagge es mit dem Git-SHA. ``` Sobald Devin den PR eröffnet hat, verwenden Sie [Devin Review](https://app.devin.ai/review?utm_source=docs\&utm_medium=use-case-gallery), um die Docker-Konfiguration zu überprüfen. Devin Review kann Sicherheitsprobleme erkennen (Ausführung als root, offengelegte Geheimnisse), fehlende Best Practices identifizieren (keine `.dockerignore`, keine Health Checks) sowie Inkonsistenzen mit Ihrer bestehenden Infrastruktur aufdecken.

{title}