5 ms·

I played with this a bit today. Only downside is, no easy way to update containers yet. But on the other hand, no more dealing with macvlan or custom docker n

• dijit 11mo ago
  “update”, I assume you mean “recreate with new image”? I think docker itself doesn’t support that.
  • doubled112 11mo ago
    I use Docker compose to recreate containers with a new image regularly. I'm sure you could be creative with volumes in Proxmox and build a new LXC container from a new OCI image with the old volumes attached.
    • dijit 11mo ago
      > I use Docker compose to recreate containers with a new image regularly. try doing so without the compose file though.
      • doubled112 11mo ago
        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.
      • kcb 11mo ago
        Not too hard. The original run command is stored if you inspect a running container.
      • bikezen 11mo ago
        With podman its just `podman auto-update` Will pull the latest version of the image down.
        • Aluminum0643 11mo ago
          For some reason though that command updates all containers configured to auto-update (ex, "AutoUpdate=registry" in the quadlet file). It would be nice to be able to pass a container name after the command, but that is unsupported.