I'm stunned that nobody has brought up the idea of 'immutable architecture' -- the idea that you create an image and deploy it, and then there is no change of state after it's deployed. If you want a change to that environment, you create a new image and deploy that instead.
Docker gives you the ability to version your architecture and 'roll back' to a previous version of a container.
In the full-OS VM (KVM, VMWare, etc) this is known as disk snapshotting. Another way to look at it is putting an RDBM in full-recovery mode, so the database itself remains the same and replaying logs is required to get the data's true state.
You shut down a VM and instruct the hypervisor system to take a "snapshot" which locks the original VHD file and creates a new one. When writes happen, they're performed on the new VHD, and reads have to use both the main and the snapshot VHD. And you can create a chain of snapshots, each pointing to the previous snapshot, for versioning. Or you can have several VM snapshots use the same master VHD, like for CI or data deduplication.
To roll back, it's usually as simple as shutting down the VM and removing the snapshot file.
The way VMs handle this doesn't carry the same semantics as the way you can with Docker. There's a finer-grain composability with Docker that is much more awkward with VMs.
Docker may not be as great as a virtualization tool as VMs -- security concerns, complexity, etc. -- but it is a much better package management tool.
My shell glue and apt-magic I wrote for my personal servers does that too... And people have been doing that for decades, just not as often, because servers used to be expensive.
Yep, I haven't specifically mentioned it, but check my top level reply to this thread. Clarify.io practices immutable architecture down to a T, and benefit greatly from it.
Docker gives you the ability to version your architecture and 'roll back' to a previous version of a container.