By john 
A surprising share of Docker frustration traces back to one blurred line. People say “I updated the container” when they mean the image, or “my data is in the image” when it is in a writable layer that is about to be deleted. The vocabulary is not pedantry. The two things have different lifecycles, and the difference in lifecycle https://saborcitosrestaurant.com/ is exactly what bites.
An image is a stack of read-only layers
An image is built from multiple read-only layers. Each instruction in a build produces a layer, and those layers stack. Nothing in an image ever changes after it is built — that is the point. An image is a template, and it is immutable.
This immutability is what makes images shareable and cacheable. Two containers started from the same image do not each get their own copy of it; they share the same read-only layers underneath. It is also why image size behaves unintuitively: deleting a file in a later layer does not remove it from the earlier layer where it was added. The bytes are still there, hidden rather than gone.
A container adds one writable layer on top
When you start a container, the runtime adds a thin writable layer on top of the image’s read-only stack. Every file the container creates, every config it modifies, every log line it writes goes into that writable layer. A union filesystem presents the whole stack as one coherent directory tree.
That writable layer is bound to the container’s lifecycle. Remove the container and the writable layer is removed with it. There is no confirmation prompt and no recovery. This is the single most important consequence of the distinction, and it is the origin of the classic “I restarted my database and lost everything” story.
What follows from this
Several practical rules fall directly out of the model rather than needing to be memorised separately.
Updating an application means replacing the container, not editing it. You pull a new image and start a fresh container from it. Changes made by hand inside a running container are in the writable layer and will vanish on replacement. If a change matters, it belongs in the image build or in configuration mounted from outside.
Persistent data must live outside the writable layer. That is what volumes and bind mounts exist for. Writing important data into the container layer ties that data to one specific container instance.
Writing to the container layer is also slower. It requires the storage driver to manage a union filesystem, an abstraction that writing directly to the host filesystem avoids.
Image is the template. Container is the running instance plus its disposable scratch space. Almost everything else follows.