Dockerfile härten und verschlanken
Scannt ein Dockerfile auf Größe, Sicherheit, Cache-Effizienz - mit konkretem Patch statt Generalkritik.
Zuletzt geprüft 23. April 2026
Prompt
Review this Dockerfile for a [LANGUAGE/STACK] app. Focus on three axes: size, security, build cache. Findings in this structure: 1. SIZE - concrete reductions (base image, multi-stage, cache-clean, .dockerignore gaps) 2. SECURITY - non-root user, secrets in layers, pinned versions, apt/apk best practices 3. BUILD CACHE - layer ordering, COPY granularity, dependency install before app copy 4. RUNTIME - HEALTHCHECK? EXPOSE? Entrypoint vs. CMD clarity? Each finding: - Line/block reference - Impact (small / medium / large) - Concrete diff (show the before/after snippet) At the end: RECOMMENDED DOCKERFILE - full rewrite showing all fixes, only if changes are substantial. Rules: - Pin versions where drift would break builds silently - Non-root user for anything beyond static-file serving - Do not add COPY --chown unless user changed - No `latest` tag for base images in production - Do not suggest alpine blindly - if the stack has glibc deps, flag the tradeoff Dockerfile: [PASTE] .dockerignore (optional): [PASTE]
Wann nutzen
Wenn das Image zu groß oder der Build langsam wird. Auch als Security-Baseline, bevor ein Image nach prod geht.
Use-Cases
- CI-Build dauert 8 Minuten, Image 1.2 GB.
- Audit vor Registry-Push.
- Multi-Stage-Migration eines einstufigen Dockerfile.
Getestet mit
Bei Tool-Versions wie Node oder Python: Haupt-Minor fixieren, Patch floaten (z.B. node:22-alpine), je nach Stabilitäts-Anforderung.