4 ms·

That's true, isn't it? It was one of those features you'd think they would have had figured out, but no.

prmoustache 11mo ago
Isn't the ability to do blue/green deployments, canary releases and easy rollbacks huge incentives to use containers? I think virtually nobody cares about being able to change the image of a container when you can so easily start a new one.
- formerly_proven 11mo ago
  People figuring out how to use containers as pets.
- esseph 11mo ago
  * blue/green deployments * canary releases * easy rollback Have never needed containers to do any of these things.
  - prmoustache 11mo ago
    Has anyone said that?
    - esseph 11mo ago
      If we could already do it with some loadbalancer changes, I don't understand your comment that it was an incentive to move to containers. 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.
danudey 11mo ago
The idea is that your container image is the thing you want, and is (relatively) immutable, so you delete and create containers when you want things to change. If you need state you can do that with volume mounts, but the idea is that you don't need to 'update' a container, you just replace it with a new one. 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.
- martijnvds 11mo ago
  To the end user, this looks exactly the same as "updating". 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"?
  - estimator7292 11mo ago
    It is exactly the same thing except you as the user are wrong for wanting to "update an application" Docker is weird and they sure do have some Opinions. I try to avoid it.

Isn't the ability to do blue/green deployments, canary releases and easy rollbacks huge incentives to use containers? I think virtually nobody cares about being able to change the image of a container when you can so easily start a new one.

formerly_proven 11mo ago
People figuring out how to use containers as pets.
esseph 11mo ago
* blue/green deployments * canary releases * easy rollback Have never needed containers to do any of these things.
- prmoustache 11mo ago
  Has anyone said that?
  - esseph 11mo ago
    If we could already do it with some loadbalancer changes, I don't understand your comment that it was an incentive to move to containers. 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.

danudey 11mo ago

The idea is that your container image is the thing you want, and is (relatively) immutable, so you delete and create containers when you want things to change. If you need state you can do that with volume mounts, but the idea is that you don't need to 'update' a container, you just replace it with a new one. 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.

martijnvds 11mo ago
To the end user, this looks exactly the same as "updating". 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"?
- estimator7292 11mo ago
  It is exactly the same thing except you as the user are wrong for wanting to "update an application" Docker is weird and they sure do have some Opinions. I try to avoid it.