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.