trusting an oci repository is the same as trusting a distro repository, if its a dodgey unknown you got from god knows where and you cant verify, dont use it

Why not put your wiki notes on your admin machine (whatever machine you use to manage the proxmox server)?

Security is a big reason to use VMs. Containers share the kernel with the host. That means that any of the kernel vulnerabilities from this year (like DirtyFrag and CopyFail) could have been used to compromise your host. Once the host is compromised, the only way to be safe is to literally buy a new machine. Seriously. Viruses can bury deep and even infect the motherboard firmware to persist indefinitely.

Kernel vulnerabilities are frequent enough that I find VMs worth it. I still use containers in my VMs though.

Docker has its uses, but it has gone to far.

I already have a webserver with Apache, mariadb and everything. Why does your PHP based website only come as a docker solution? Fuck you.

When you go all in with docker, it quickly becomes a mess with rando NICs and containers named "random 32 character string" and dependencies up the wazoo. Ending up running ancient packages because the developer refuses to apt upgrade their shit.

Proxmox or any other hypervisor platform gives you control. Whereas you have to take it for docker and youre still at the mercy or the developers to keep your shit secure.

Years ago I'd have one PHP app that required version X of PHP and another that required version Y and my distro often only had one of them (or you couldn't install both simultaneously), so I'd have to either compile myself (or later use a 3rd party repo). All solvable of course, but then throw in MySQL version requirements and PHP extensions and it's just extra crap that containers just take care of for you. I've had this kind of inter app requirements conflicts with stuff other than PHP, but I've had by far more of it with PHP. For a while I used FreeBSD jails to help, but jails was kind of a pain. I enthusiastically embraced docker for PHP stuff early on.

A benefit for application developers, particularly PHP is there's a lot of differences between distros and how people install and configure PHP. Even like which PHP extensions are available and their settings. Other languages things tend to be more consistent at the system level and customizations are app are usually application level (contrast with PHP extensions and system level configurations). It really helps reduce support issues due to distro/user differences if a developer just provides a working dockerfile as a reference implementation and in my experience this is far more likely with PHP than other languages. I realize this is mostly applicable outside of PHP, but I actually personally see more benefit with PHP based on my past experiences.

Do you have any sources on motherboard firmware viruses? I'm curious to know more about them

How's it compare to Portainer? I hear Portainer is about to be enshitified.

Nope. You don't need to trust a distro Repo's publishing infrastructure because the packages are cryptographically signed.

Whereas the oci repo had a ton of vectors for delivering maliciously modified code because they include image layers that are totally unsigned.

I could, but it’s more convenient for me to have it served up by an LXC container on the server. I’m usually interacting with things on a laptop or a phone, so it’s just easy being able to have a tab open with my wiki served through Tailscale, and ProxMox makes sure it stays backed up to an external drive and the cloud so I don’t lose anything.

The few times I’ve had a critical error with ProxMox, it’s been super simple to do a fresh install and just restore my daily backup.

There are many ways it could be done, but this way has been mine, and it’s worked for me.

Hard to describe, it's better to take a look at it.
https://github.com/Finsys/dockhand#screenshots

I secon running docker apps on a Proxmox VM. It has saved my homlab admin time significantly.

all the problems you expressed with docker aren't real problems.

I think you may not like it because you don't know how to use it.

don't like how often a maintainer updates their images? build your own.

don't like having multiple bridge interfaces on your host? configure and manage networks within docker and assign them to your containers.

don't like having dozens of containers with random names? use docker compose. bonus, you can set up networking with it even easier.

Ending up running ancient packages because the developer refuses to apt upgrade their shit.

Tell me you never really had to deal with dependency hell without telling me. That's literally the main problem docker solves.

I like running docker containers inside of specific unprivileged LXCs on my proxmox host. Why? Because it works and I'm not an expert.

I can spin up a new LXC and test things without fucking up my entire server. It allows me the flexibility to try new services or attempt things that I'd otherwise be too timid to try on the chance it fucks up my entire system and I have to spend two and half weekends trying to get back to where I was when things just worked.

Just look up firmware rootkits and UEFI rootkits. For example: https://arstechnica.com/information-technology/2022/07/researchers-unpack-unkillable-uefi-rootkit-that-survives-os-reinstalls/

Proxmox is a hypervisor, while docker is containerization.

Comparing them is like comparing an apple to a glass of milk. They have different use cases.

I run multiple VMs specifically for Docker services. I run other VMs for other things. And LXCs for applications where containerization makes sense but I don't want to use Docker.

oci repositories support signing artifacts, container trust policies are a thing. bootc repos are both signed and are distro repos, ostree Fedora and ublue are using it

Just because quay.io or hub.docker can be accessed without signatures or trust doesn't mean there aren't repos out there using it.

My point is that they support unsigned packages.

It's not possible to download a package on apt without signatures, by default. All packages are signed.

We tell people to use Signal, not Telegram, because the later allows unencrypted messaged by default.

I don't know of any common oci repos that have many signed packages. If you make it your policy to require signatures, there's almost no images you'll be able to download because almost none are signed.

Whereas it's 100% of packages in Debian's apt that are signed.

I use VMs for OS isolated and hardware isolation. I run containers on top of OSs for apps.

That said I use Harvester so I can run containers on bare metal AND VMs as containers.

Even on one bare metal I do this, so I can spin up a test VM of harvester to confirm configs. If you one node is super beefy a neat trick is to have VMs running a cluster so you can have a kind of high availability even if your infra is a single point of failure.

Ram is expensive... so all my 24x7 things are containers (docker compose on Alpine Linux) or FreeBSD jails.

Why not have the option for both?

I dont see how this is a defense for jamming everything in to a container.

What? Outdated junk running in containers because the maintainer didnt update their shit is not a real problem?

Seems that it is perhaps you who doesnt know how to use it.

I have had to deal with dependency hells plenty, i am a Debian user after all.

But with that argument you're now just running outdated shit in a container. Not a great pro-docker argument tbh.

@SirLeToet @3abas It's not that I deny Docker's various pecadilloes, butMy servers run ZFS on platters separate from the boot disk(s). My services (self-hosted or whatever) mostly run in Docker containers with compose files. What I get from that, is that I can nuke my server anytime I like, re-import the zpool, go to my docker directory and get everything spinning back up in minutes. Nobody who has to deal with more than one server doesn't use some form of this virtualization, be it VMs, docker or some other Container solution.

yeah, it's not a problem because you can fix it.

it's a skill issue.

1. Why not both? Packaging multiple releases, documenting, and support is lessened with a single release. Officially supporting more ways to install is extra time and effort that is considerably worse with PHP than applications written in most (maybe all?) other popular languages due to the variety of ways people can configure PHP and how the web server executes it is huge and trying to support all of that is considerable. Even if you just narrow down to a single http server, there's a lot of variations just how the http server executes the scripts and that's ignoring the PHP/PHP extension level differences. I can't think of any popular languages that are worse or even in the same ballpark as PHP on execution environment inconsistencies.

2. The existence of the docker release doesn't prevent you from running it outside of docker and the Dockerfile/image serves as a reference implementation. It provides you the exact steps and working configuration to deploy it outside of docker.

Consider a PHP application with install instructions, you follow them and it doesn't work due to some non obvious configuration difference. With the docker image you have a reference of what should work and can use that to narrow down what is different between your PHP install/configuration and a working system.

If you've not run in to these kinds of situations, consider yourself lucky. It was a nightmare back in early 7.x releases and older.