Methods and Practices for Generating Dockerfile from Docker Images

Technical Background and Requirement Analysis

In Docker containerized development practices, developers often need to analyze the build process of existing images. This requirement primarily stems from two scenarios: first, when downloading third-party images from repositories, understanding their build recipes facilitates security auditing and customized modifications; second, in snapshot-based development workflows, converting temporary modifications into structured Dockerfiles enhances development efficiency.

Core Tool: alpine/dfimage

The most effective current solution is using the alpine/dfimage tool. By mounting the Docker daemon socket, this tool can deeply analyze the layer structure of images and generate corresponding build instructions.

Here is the basic usage method:

alias dfimage="docker run -v /var/run/docker.sock:/var/run/docker.sock --rm alpine/dfimage"
dfimage -sV=1.36 nginx:latest

It is particularly important to note that the generated output is primarily for reference purposes and cannot be directly used with the docker build command. The parameter -sV=1.36 specifies the Docker API version and can often be omitted in most cases.

Image Layer Analysis Technology

Modern Docker images employ a layered storage architecture, where each layer corresponds to a build instruction. By analyzing these layers, an approximate build process can be reconstructed.

Using the dive tool enables deep analysis of file changes in each layer:

alias dive="docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive"
dive nginx:latest

The tool interface displays build commands for each layer on the left, while the right side highlights files and directories changed in that layer using yellow markers. The space key can be used to expand or collapse directory structures.

Traditional Method: docker history Command

In the absence of specialized tools, the docker history --no-trunc command can be used to obtain image build history. This method can extract key information including MAINTAINER, ENV, EXPOSE, VOLUME, WORKDIR, ENTRYPOINT, CMD, and ONBUILD.

The following script demonstrates how to extract Dockerfile elements from image history:

#!/bin/bash
docker history --no-trunc "$1" | \
sed -n -e 's,.*/bin/sh -c #(nop) \(MAINTAINER .*[^ ]\) *0 B,\1,p' | \
head -1
docker inspect --format='{{range $e := .Config.Env}}
ENV {{$e}}
{{end}}{{range $e,$v := .Config.ExposedPorts}}
EXPOSE {{$e}}
{{end}}{{range $e,$v := .Config.Volumes}}
VOLUME {{$e}}
{{end}}{{with .Config.User}}USER {{.}}{{end}}
{{with .Config.WorkingDir}}WORKDIR {{.}}{{end}}
{{with .Config.Entrypoint}}ENTRYPOINT {{json .}}{{end}}
{{with .Config.Cmd}}CMD {{json .}}{{end}}
{{with .Config.OnBuild}}ONBUILD {{json .}}{{end}}' "$1"

Advanced Script Implementation

For scenarios requiring more complete Dockerfile output, the following bash script can be used:

docker history --no-trunc $argv | tac | tr -s ' ' | cut -d " " -f 5- | sed 's,^/bin/sh -c #(nop) ,,g' | sed 's,^/bin/sh -c,RUN,g' | sed 's, && ,\n  & ,g' | sed 's,\s*[0-9]*[\.]*[0-9]*\s*[kMG]*B\s*$,,g' | head -n -1

The processing flow of this script includes: reversing history records, compressing whitespace characters, removing leading fields, cleaning shell call formats, beautifying multi-command displays, and removing layer size information.

Technical Limitations and Best Practices

It is important to recognize that Dockerfiles generated from images have inherent limitations. Images may be created through tar backup methods, in which case the build history only shows file import operations. Additionally, certain build optimization steps may be lost during the reverse engineering process.

Image building based on Dockerfile remains the recommended best practice, as it provides repeatable, version-controlled build processes that effectively avoid image bloat issues.

Practical Application Scenarios

In containerized development workflows, these technologies are primarily used for: security auditing, learning third-party image building techniques, and converting experimental containers into repeatably buildable Dockerfiles. For multi-container applications, it is recommended to use docker-compose for orchestration management, ensuring service dependencies through depends_on.