Reverse-Engineering a Dockerfile from an Existing Docker Image

Reverse-Engineering a Dockerfile from an Existing Docker Image

This article explains how to recover a Dockerfile from an existing Docker image when the original file is lost. The process involves analyzing the image’s layers using the docker history command and reconstructing the Dockerfile step-by-step. While the generated Dockerfile may require adjustments, it provides a close approximation of the original build process.

---

Key Concepts and Methodology

Problem Scenario

• Dockerfiles are typically used to build images, but they can be accidentally deleted.
• When only the Docker image exists, developers may need to reverse-engineer the Dockerfile to reproduce the image or understand its construction.

Steps to Recover the Dockerfile

1. Download the Image: Pull the Docker image from a repository (e.g., AWS ECR).
2. Analyze Layers: Use docker history --no-trunc to inspect the image’s build layers. This command reveals the sequence of RUN, COPY, ADD, and CMD instructions used during the build.
3. Reverse the Layer Order: The docker history output lists layers in reverse chronological order (latest commands first). Reconstruct the Dockerfile by reversing this order, starting from the base image.
4. Extract Commands: Identify commands like RUN, COPY, ENV, and CMD from the history and format them into a Dockerfile structure.

Generated Dockerfile Example

The following Dockerfile was reconstructed from the docker history output of a Tomcat-based image:

FROM tomcat:9.0.111
ENV TOMCAT_VERSION=9.0.111
ENV TOMCAT_MAJOR=9
ENV LD_LIBRARY_PATH=/usr/local/tomcat/native-jni-lib
ENV TOMCAT_NATIVE_LIBDIR=/usr/local/tomcat/native-jni-lib
WORKDIR /usr/local/tomcat
RUN /bin/sh -c mkdir -p "$CATALINA_HOME"
ENV PATH=/usr/local/tomcat/bin:/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV CATALINA_HOME=/usr/local/tomcat
CMD ["catalina.sh", "run"]

Key Observations

• Layer Order: The docker history command shows the last executed command first (e.g., CMD ["tomcat.sh"]). Reversing this order is critical to reconstructing the correct sequence.
• BuildKit Metadata: The # buildkit comments in the history output indicate commands executed during the build process but are not part of the Dockerfile itself.
• Versioning: The Dockerfile includes specific versions of Tomcat (9.0.111) and Java (temurin-jdk-17), which are critical for reproducibility.

Limitations and Adjustments

• The generated Dockerfile may lack comments or optimizations present in the original.
• Some commands (e.g., RUN steps with complex logic) may require manual refinement to match the original Dockerfile’s intent.

---

Working Example

# Reconstructed Dockerfile from docker history
FROM tomcat:9.0.111
ENV TOMCAT_VERSION=9.0.111
ENV TOMCAT_MAJOR=9
ENV LD_LIBRARY_PATH=/usr/local/tomcat/native-jni-lib
ENV TOMCAT_NATIVE_LIBDIR=/usr/local/tomcat/native-jni-lib
WORKDIR /usr/local/tomcat
RUN /bin/sh -c mkdir -p "$CATALINA_HOME"
ENV PATH=/usr/local/tomcat/bin:/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV CATALINA_HOME=/usr/local/tomcat
CMD ["catalina.sh", "run"]

---

Recommendations

• Use --no-trunc Flag: Always use docker history --no-trunc to see full command details.
• Verify the Generated File: Test the reconstructed Dockerfile with docker build to ensure it produces the same image.
• Handle BuildKit Output: Remove # buildkit comments and adjust layer order manually if needed.
• When to Use This Approach: Ideal for debugging, auditing, or recovering lost Dockerfiles. Avoid for production environments where original files should be preserved.
• Common Pitfalls:
  • Misinterpreting layer order (e.g., CMD appearing first in history).
  • Missing environment variables or dependencies in the reconstructed file.
  • Incomplete RUN commands that require additional context.

---

For more details, refer to the original article: https://dev.to/purnima_upadhyaya/how-to-generate-a-dockerfile-from-the-docker-image-3k5d