> I use Docker compose to recreate containers with a new image regularly.
try doing so without the compose file though.
try doing so without the compose file though.
That's also what docker compose does, under the hood. It doesn't 'update' a container, it just deletes it and recreates it with the new image and the same settings/name/ports/volumes/etc.
If replacing a "regular" program that's just an executable and then restarting it is "updating", why isn't it the same for containers? Except theb the "executable" is the container image and the "running program" is the actual container.
Another level would be "immutable" distributions: would you say they don't "update", they just "download a fresh image to boot from"?
Docker is weird and they sure do have some Opinions. I try to avoid it.
I think virtually nobody cares about being able to change the image of a container when you can so easily start a new one.
* canary releases
* easy rollback
Have never needed containers to do any of these things.
Containers are separate from their deployment method. To be able to do those things with containers, some will go to docker, docker swarm, hashicorp nomad, or kubernetes.
So if people could already do these deployment methods, and given the HUGE organizational lift in training and platform investment for Ops to do that shift, your comment about those reasons being incentives to move to containers doesn't make sense.