Complete dockerfile toolkit with generation and validation capabilities
74
92%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Risky
Do not use without reviewing
You are given the following Dockerfile for a Python web application:
FROM python:3.11-slim
WORKDIR /app
COPY . /app
RUN pip install -r requirements.txt
RUN apt-get update && apt-get install -y libpq-dev
RUN rm -rf /var/lib/apt/lists/*
RUN pip install gunicorn
USER appuser
EXPOSE 8000
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "wsgi:app"]Perform Stage 3 (Best Practices Validation) with a focus on layer ordering and build cache efficiency.
Identify the cache busting problem caused by the COPY ordering. Explain what happens to the pip install layer every time source code changes.
Identify the cache cleanup layer ordering problem. Explain why the separate RUN rm -rf /var/lib/apt/lists/* on its own line does NOT reduce the image size.
Identify the split pip install issue (requirements.txt installed separately from gunicorn).
Verify the USER directive is present and assess whether it is correctly placed (before or after COPY/RUN).
For each issue, provide a corrected code snippet demonstrating the fix.
Produce a brief summary of how many layers would be saved by applying the fixes.
COPY . /app before RUN pip install -r requirements.txt causes the pip install cache to be invalidated on every source code change, and propose copying requirements.txt firstRUN rm -rf /var/lib/apt/lists/* in a separate RUN instruction creates a new layer and does not reduce the size of the layer where apt-get ran; the cleanup must be in the same RUN layerCOPY . /app before RUN pip install -r requirements.txt causes the pip install cache to be invalidated on every source code change, and proposes copying requirements.txt firstRUN rm -rf /var/lib/apt/lists/* in a separate RUN instruction creates a new layer and does not reduce the size of the layer where apt-get ran; the cleanup must be in the same RUN layer