Docker数据持久化入门：commit容器后无关联卷的疑问

Hey there! Let's cut through the confusion here—you're new to Docker, don't want to slog through 40 hours of training, and you've hit a weird spot with docker commit and volumes. I've been there, so let's break this down step by step.

First: What docker commit Actually Does #

When you run a command like docker container commit -m "postinstall, web3" a6a5be991ca5 web3, you're taking a snapshot of your running container's writable filesystem layer and turning it into a new image. Here's the key thing to remember:

• This snapshot only includes changes made inside the container itself—not data stored in external volumes. Volumes live outside the container's filesystem (usually in /var/lib/docker/volumes/ on your host), so commit can't capture or reference them at all.

Why You Don't See Volumes in Kitematic for Your Committed Image #

Kitematic displays volumes in two specific scenarios:

1. The image was built from a Dockerfile that includes a VOLUME instruction (this tells Docker to auto-create a volume for that directory when a container starts).
2. You explicitly mounted a volume when launching the container (using docker run -v or --mount parameters).

Since docker commit doesn't copy over any volume configuration from the original container, your new web3 image has no volume definitions baked into it. That's exactly why Kitematic's Volumes tab looks empty for containers started from this image.

Will Your Data Disappear When You Restart the Machine? #

It depends entirely on where your data is stored:

• If data lives in the container's writable layer (not a volume): The commit captured this data, so containers started from your new image will have it—but this data is still tied to the container's temporary layer. If you delete the container, that data is gone for good. Restarting the machine won't delete the container, but this is still not a safe way to persist important data.
• If data was in a volume: The volume itself lives on your host's filesystem, so restarting the machine won't delete it. However, your committed image has no idea this volume exists—so if you start a new container from the web3 image without explicitly mounting the original volume, you won't see that data at all.

The Better Approach (No Commit Needed) #

docker commit is handy for quick tests, but it's not the right tool for creating reusable images or persisting data. Here's what to do instead:

• Use a Dockerfile: Write a Dockerfile that installs your dependencies (like web3) and uses the VOLUME instruction to define directories where you need persistent data. This way, every container started from the image will automatically use a volume for that directory.
• Explicitly mount volumes: When starting containers, use docker run -v my-web3-volume:/path/in/container ... to attach a named volume to your container. This ensures your data lives outside the container and stays safe even if the container is deleted.
• Recover existing data: If you need to access data from your original container's volume, run docker inspect a6a5be991ca5 to find the volume's name or path, then start a new container with docker run -v <volume-name>:/target/path web3 to access that data.

内容的提问来源于stack exchange，提问作者Martin Thompson