During a backup audit, I wanted to document exactly how a long-running Docker container had been started, specifically the full docker run command, including environment variables, port mappings, volume mounts, and restart policies.

Take this example:

docker run -m 100M --name testbed-mysql --restart=always \
  -e MYSQL_ROOT_PASSWORD=foo \
  -e MYSQL_DATABASE=bar \
  -e MYSQL_PASSWORD=foo \
  -e MYSQL_USER=foo \
  -v /tmp/etc:/etc/mysql/conf.d \
  -v /tmp/mysql:/var/lib/mysql \
  -p 127.0.0.1:7308:3306 \
  -d mysql

A docker ps -a shows you almost nothing useful:

CONTAINER ID   IMAGE          COMMAND                  CREATED      STATUS    PORTS                         NAMES
a32bdcbb36c7   mysql:latest   "docker-entrypoint..."   2 days ago   Up 2 days 127.0.0.1:7308->3306/tcp   testbed-mysql

docker inspect gives you everything in JSON, but parsing it by hand is tedious. Two tools do this automatically.

runlike (Python) Link to heading

runlike takes a container name or ID and reconstructs the docker run command:

pip install runlike
runlike testbed-mysql

Output:

docker run --name=testbed-mysql --hostname=a73900fe9af6 \
  --env="MYSQL_ROOT_PASSWORD=foo" \
  --env="MYSQL_DATABASE=bar" \
  --env="MYSQL_PASSWORD=foo" \
  --env="MYSQL_USER=foo" \
  --env="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" \
  --env="GOSU_VERSION=1.7" \
  --env="MYSQL_MAJOR=5.7" \
  --env="MYSQL_VERSION=5.7.20-1" \
  --volume="/tmp/etc:/etc/mysql/conf.d" \
  --volume="/tmp/mysql:/var/lib/mysql" \
  --volume="/var/lib/mysql" \
  -p 127.0.0.1:7308:3306 \
  --restart=always \
  --detach=true \
  mysql:latest mysqld

Note that resource constraints (-m 100M) are not recovered; docker inspect doesn’t expose them in a way runlike can reconstruct. Everything else comes through cleanly.

rekcod (Node.js) Link to heading

rekcod is the JavaScript alternative and works the same way. Either tool gets the job done; runlike is my preference since I’m more likely to have Python available.

Practical use Link to heading

Both tools are valuable for:

  • Documentation: capturing how containers are configured before you forget
  • Disaster recovery: reconstructing a setup from a running container when you’ve lost the original scripts
  • Migration: moving from bare docker run commands to Docker Compose by using the reconstructed command as a starting point

If you’re using Docker Compose or Kubernetes already, this problem mostly goes away: the configuration is already in declarative files. But for containers started manually months ago, these tools are a lifesaver.