Best Template from Proxmox List for Self-Hosting Services with/without Docker? Guide?

[SInisterPisces]

Hello,

I'm curious, as someone brand new to Proxmox/virtualization who has only ever used Docker, which of the built-in(?) container templates would be the best one to standardize on for learning to build containers running just one or a few related services (e.g., a Minecraft server and related tools that deploy via Docker, a logging system, etc.).

I'd like the containers to be as small as feasible (in terms of OS overhead), while still not making me jump through hoops to do things (I'm looking at you, Alpine).

I'd appreciate any opinions. (I know there are other, non-included templates, but most of those are still one or another flavor of one of the choices here).

I've listed out all the options included in PVE below, but my short list looks like:

1. Ubuntu Server
2. Fedora
3. AlmaLinux/RockyLinux ( I don't understand how these are functionally different, yet.)

The full list is:

1. ArchLinux: I know Manjaro best from using it as my Pi's OS, but I know enough to know it's not the best idea for a server template.
2. OpenSUSE 15.3: I assume this is Leap? I don't really have any experience with this beyond reading a tutorial and messing the the package manager five minutes one time. I've not read about the suitability of this one for server use.
3. CentOS 8 Stream: I'd prefer to avoid standardizing on this if only because at this point I'm not sure it's going to continue to exist in the medium- and long-term, and it's no longer "free RedHat."
4. Ubuntu 22.04 LTS Server: This would be my choice for a Debian-based server template. I'm the most familiar with Ubuntu out of all the non-Manjaro distros I've used, as it's almost always the base for whatever speciality OS I've decided to run on my Pi. I've been using Ubuntu Server 22.04 LTS in a tutorial, and I like the feel of it so far.
5. Debian 11 Standard: I'd just as soon use Ubuntu Server if I'm going to stay with this flavor of Linux.
6. Fedora 35: I'm very interested in Fedora just because of its age and history, and I hear good things about using it as a server OS. I'm interested in using it so I can learn about it, but I have no idea if it's the best choice to use for a server template. At least (I think) it's as well documented as Ubuntu.
7. AlmaLinux and RockyLinux: I understand these are both in the running to be what pre-Stream CentOS was. I have no idea of how to judge their suitability or choose between them.
8. Alpine: I don't want to use this. I've used Alpine via a number of embedded Linux installs on network devices and as the base image on several docker containers, and I continuously get frustrated with what isn't included, or what is included but pared down to the point where it's unclear how to use it (Sendmail in Busybox has burned years off my life, hello).
9. Devuan: Not to start a flame war, but I'm not really interested in Linux without SystemD. Of the various versions I've tried, one of the nice things is that they all have SystemD, which I know how to use well enough for my purposes.

 

[flames]

Hello,
Debian 11 Standard in CT (LXC).
Technically PVE is using a customized ubuntu kernel, but is debian 11 packaged. I would go for sake of dependencies with Debian 11, as a system container (LXC) is not fully independent, so is your application container (docker).
But wait for more answers from users, who are deeper into docker+pve.

 

[SInisterPisces]

Thanks!

I appreciate the note about Docker especially depending on the kernel; I had not thought about that.

I don't plan to dockerize everything, but I (finally) know how to bring up a reasonably well-appointed, stable Minecraft server with it, so I'll use it for at least that.

 

[alexskysilk]

There is nothing preventing you from just running docker there are two ways of doing this on proxmox- either in a VM or running on the hypervisor (you can also do it in a container, but the security tradeoffs make it effectively as running on the hypervisor.) Both have their pros and cons- search the forum for specifics.

But the answer to your question should probably follow what you're most comfortable with. Most people tend to gravitate to a specific way of doing things, usually the debian way or the centos way- honestly, there is no wrong answer. if you intend to use lxc containers, there are flavors of just about all the OS's you mentioned.

Lastly, maybe you should expand on what your concern with "I'd like the containers to be as small as feasible." Why is this important?

 

[Dunuin]

I personally prefer Debian over Ubuntu. I'm not a big fan of Ubuntu moving everything from apt to snap. I always run into problems when using snap and sometimes there is no maintained apt package anymore.
Then like flames already said, PVE is based on Debian. Besides the dependencies you also learn faster. All you learn while working with that Debian LXC you can also use to manage your PVE host and vice versa.
And lastly, I like that Debian is using more stable versions of packages. You don't get the latest versions like with Ubuntu, but at least your software is then well tested.

 

[SInisterPisces]

Thanks! Sounds like I'll be going with Debian.

And lastly, I like that Debian is using more stable versions of packages. You don't get the latest versions like with Ubuntu, but at least your software is then well tested.

That's not so bad. I have no problem using a different distro if I must have a newer version of something, but I really doubt that's going to be an issue too often.

There are some pre-made Linux flavors I want to run, and those will usually be Ubuntu, so I won't have to worry about it there.

Lastly, maybe you should expand on what your concern with "I'd like the containers to be as small as feasible." Why is this important?

Eventually, I'll have two nodes: a large, powerful node with a lot of mass storage (all high-endurance enterprise SSDs) for VMs and shared storage via iSCSI, and a smaller node for experiments and potentially more unstable things, OSes that need a dedicated GPU. The small node will share the storage via iSCSI, as well.

At the moment, I only have the small node deployed. It has a much simpler hardware setup (a single OS SSD, and a two SSD mirror pool for VM storage), and is much easier to learn from scratch on, since I'm not also trying to learn the enterprise hardware of the big node.

Unfortunately, the small node only has 1 TB of space for VM storage, and ideally I'd never like to go past 768 GB, so I'm conscious of managing my space usage and not going crazy on the consumer grade SATA SSDs' write endurance.

Once I have the big node set up, I won't have to worry about storage space so much, so this won't be a concern.

 

[flames]

@SInisterPisces there is not a lot to add, but still, i would like to add a bit and mention @alexskysilk 's post:
there are not two, but three ways to run docker on pve. Alex said either VM or on the PVE host. Yes, of course. the third way is a CT (LXC). to sum up:
1. VM
2. CT
3. PVE host
i would urgently not suggest the 3. way! you don't want to install stuff on your host of multiple reasons, tho its possible of course. but it defies the idea behind virtualization and containerization at all. which is to be hardware independent as far as you can go in first place. and if you go into docker networking, you might mess with pve networking stack and break it.
so again, there are only two _viable_ ways, docker in:
1. VM, best for security and independence from host about packages.
2. CT, best for performance, since an LXC container is "nearly" host native performance and more flexible at same time, but less isolation so security holes possible. ofc. there are mechanisms to prevent that, but as always, it is possible.

i am running docker app-cts only in lxc sys-cts and only debian since half of a decade and its good.

in any of your decisions, i think debian is best way to go and as @Dunuin said, its more stable and packaging with snap is cool but sheeeth yet. see it like playstore or something, we are here for servers and have control in hands, not to install apps.