719 - I am not a teapot Espresso Web (Red Hat Enterprise Linux) at raymii.org
Looks suspicious, ... not 418, 719.
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.
There's also the security angle. Containers managed by Proxmox are strongly isolated from the host, but containers running on Docker sidestep this isolation model. Docker is not insecure by design, but it greatly increases the attack surface. If the hypervisor gets compromised, the entire cluster of servers will also get compromised. In general, as little software as possible should be installed on the host.
You have a bunch of tooling that deals with apples. You have a clear conceptual picture of what an apple is and what it does.
Then someone brings you a pear. It's kind of like an apple but not exactly. Their pear however works well with some other toolscape that's beyond the shire. You want to do things with their pears.
You invent a way to put a pear inside an apple (docker in VM). That works but you lose some functionality and break some stuff in the conversion, plus now you don't have the clean conceptual integrity of your apple-only system.
This is a way to transform a pear into an apple.
Im still on 8.x -- it was a fun way to consolidate my different hacky projects -- home assistant, frigate, wireguard, qbittorrent etc
Kinda scared to think of what it would take to upgrade to 9.1 :)
5 host cluster; rebooted them all at completion and all of the containers came back up without issue (combination of VMs and LXC)
Run the pve8to9 script first to do some sanity checks (it should already be installed if the system is up to date).
Update the box to latest 8.x with apt update etc. Change the package sources to the new ones and update the system.
The packages databases can be a bit confusing: You have two lots - stock Debian and Proxmox (enterprise OR no-subscription).
Stock Debian is in the single file /etc/apt/sources.list - change "bookworm" to "trixie".
Proxmox sources is in a file in /etc/apt/sources.list.d/ Remove all of the Proxmox related ones you have there and run this (or do it yourself with an editor). This example is no-sub - the official doc notes the enterprise equivalent:
cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
Job done.
I had put off the upgrade for a while figuring it would be a breaking change. But it went so smoothly I’ll probably be upgrading to 9.1 pretty soon.
I was (still am sadly) a VMware consultant for about 25 years. It makes me laugh when I hear breathless "enterprise noises" with regards VMware and how PVE isn't quite ready yet.
PVE is just so easy and accommodating. It's Linux on Debian with a few nobs on. The web interface is so quick and uncluttered and simple. The clustering arrangements are superb and simple. The biggest issue for me and many like me was how to deal with iSCSI SANS (no snapshots - long story) It turns out you can pull the SSDs out of a Dell Msomething SAN and wack them into the hosts and you have a hyperconverged Ceph thingie with little effort.
VMware rapidly gets very expensive. Nowadays with Broadcom you have to fork out for the full enterprise thing to get DRS and vDS - that's auto balancing clusters and funky networking. PVE gifts you Open vSwitch support out of the box and all clusters are equal. Storage DRS (migrate virty hard discs on the fly) is free on PVE too. Oh and you get containers too on PVE - VMware Tanzu is seriously expensive.
Anyway, I could grind on about this for quite some time but in my opinion, PVE is a far better base product in general for your VMs. A vCentre is a horrendous waste of resources and the rest of VMware's appliances are pretty tubby too. I recall evaluating their first efforts at SDN with edge firewalls and so on - no thanks!
too bad SUSE is doing the rancher prime stuff now as well.
In the end, Proxmox is based on KVM and KVM does run a workload or two across the world. VMware isn't KVM and I watched both be born and grow up oh and I should mention Xen but I can't be arsed. Most of the rest are Johnny come latelys.
If I need a massive cloud then I'll go all in on K8s or whatever and get my orchestration hat on big time but for my needs and my customer needs, PVE is more than enough, whilst being just enough.
I created an alpine container per app with "nesting=1". Inside each alpine container I installed podman (`apk install podman`). Then it's a couple init scripts inside each alpine container, one to work-around a cgroups issue, the other to start the app via podman:
atdr.meo.ws/archiveteam/reddit-grab
I cannot install this one to Proxmox VE, for instance
UPD. Query tag fails, but fetch is successful if I write "latest" tag
I don't think I've ever seen anyone mention using proxmox in a professional context.
None the less, nice progress I reckon.
I run a similar setup with a few VMs on a mini pc at home as well... It all works well enough for what I need. Lets me somewhat isolate the containers VM from other purpose-specific VMs.
nirav72•2mo ago
dijit•2mo ago
I think docker itself doesn’t support that.
doubled112•2mo ago
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•2mo ago
try doing so without the compose file though.
doubled112•2mo ago
prmoustache•2mo ago
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•2mo ago
esseph•2mo ago
* canary releases
* easy rollback
Have never needed containers to do any of these things.
prmoustache•2mo ago
esseph•2mo ago
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•2mo ago
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•2mo ago
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•2mo ago
Docker is weird and they sure do have some Opinions. I try to avoid it.
kcb•2mo ago
bikezen•2mo ago
Aluminum0643•2mo ago