[HN Gopher] Run Docker containers natively in Proxmox 9.1 (OCI i...
       ___________________________________________________________________
        
       Run Docker containers natively in Proxmox 9.1 (OCI images)
        
       Author : jandeboevrie
       Score  : 62 points
       Date   : 2025-11-20 21:05 UTC (1 hours ago)
        
 (HTM) web link (raymii.org)
 (TXT) w3m dump (raymii.org)
        
       | nirav72 wrote:
       | 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 networks.
        
         | dijit wrote:
         | "update", I assume you mean "recreate with new image"?
         | 
         | I think docker itself doesn't support that.
        
           | doubled112 wrote:
           | 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 wrote:
             | > I use Docker compose to recreate containers with a new
             | image regularly.
             | 
             | try doing so without the compose file though.
        
               | doubled112 wrote:
               | That's true, isn't it? It was one of those features you'd
               | think they would have had figured out, but no.
        
               | prmoustache wrote:
               | 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.
        
               | danudey wrote:
               | 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.
        
               | kcb wrote:
               | Not too hard. The original run command is stored if you
               | inspect a running container.
        
       | k__ wrote:
       | Is this similar to what FlyIO is doing? Running containers as
       | microVMs?
        
         | indigodaddy wrote:
         | Perhaps in spirit? But I don't think you can term LXC a
         | microVM, and I doubt they start close to as fast as Firecracker
         | or smolbsd, and similar ilk. EDIT - appears I am probably wrong
         | about firecracker being faster than LXC as LXC is kernel based
         | virtualization and likely has faster startup than microVMs?
        
       | _ache_ wrote:
       | I have an "error" "I am not a teapot"
       | 
       | 719 - I am not a teapot Espresso Web (Red Hat Enterprise Linux)
       | at raymii.org
       | 
       | Looks suspicious, ... not 418, 719.
        
         | radiator wrote:
         | I think 418 is 'I _am_ a teapot ' so it would not be correct to
         | use it in your case. 719 must be a typo though, perhaps it
         | should be 419.
        
       | dizhn wrote:
       | They are converted to LXC images then run. No compose file
       | either. Still pretty neat.
        
       | caymanjim wrote:
       | It's unclear to me why running Docker directly in Proxmox (it's
       | just Debian) and using it like any other Docker host is a bad
       | idea, and why this extra layer of abstractions is preferable.
       | 
       | Docker has security issues if you're not careful, and it's
       | frankly kind of a shitshow out of the box with defaults. Maybe
       | that's part of the reason. But I struggle to see how a bespoke
       | solution like this is the right answer.
        
       ___________________________________________________________________
       (page generated 2025-11-20 23:00 UTC)