I don’t use any GUI… I use terraform in the terminal or via CI/CD. There is an API and also a Terraform provider for Proxmox, and I can use that, together with Ansible and shell scripts to manage VMs, but I was looking for k8s support.

Again, it works fine for small environments, with a bit of manual work and human intervention, but for larger ones, I need a bit more. I moved away from a few VMs acting as k8s nodes, to k8s as a service (at work).

I do the same in Proxmox VMs, in my homelab, which is… fine. I was talking more about native support, manageable via an API or something.

Say I need to increase the number of nodes in my cluster. I spin up a new VM using the template I have, adjust the network configuration, update the packages, add it to the cluster. Oh, maybe I should also do an update on all of them while I’m there, because now the new machine runs a different docker version. I have some Ansible and bash scripts that automates most of this. It works for my homelab.

At work however, I have a handful of clusters, with dozens of nodes. The method above can become tedious fast and it’s prone to human errors. We use external Kubernetes as a service platforms (think DOKS, EKS, etc), who have Terraform providers available. So I open my Terraform config and increase the number of nodes in one of my pre-production clusters from 9 to 11. I also change the version from 1.32 to 1.33. I then push my changes to a new merge request, my Gitlab CI spins up, who calls Atlantis to run a terraform plan, I check the results and ask it to apply. It takes 2 minutes. I would love to see this work with Proxmox.

Man, I’ve been living and working in Germany for close to 10 years now. Proxmox is like that 50yo colleague of mine. Hard worker, reliable, really knowledgeable, a treasure trove of info, but he can’t be budged. He insists on installing any new VM using the GUI (both Windows and Linux), he avoids learning “new things” like Docker or Kubernetes, and really distrusts “the cloud”.

I will keep using Proxmox, as I have for many years both at work and at home, but we are migrating from a VM (with Docker) setup to Kubernetes. It would have been great for Proxmox to offer some support there, but…

I see what you mean, interesting. Didn’t really look at NixOS as a server os. I personally prefer using multiple compose files (in the process of migrating to k8s). I share resources too, like in your example, I just point to the existing DB instance, not create a new one for each new service.

May I ask what you mean by NixOS support? There’s a docker compose you could use in their repo…

I believe R-- stands for Readarr and G–R-- stands for GoodReads.

Hosted with Jellyfin, for clients I use Symfonium on Android and Feishin on desktop.

ansible can seem like just a fancy way to run shell scripts with extra syntax, but the real power shows up when you start managing more than one machine or need repeatable, “idempotent” (i love this word) setups. ansible handles state rather than just running commands, so you can describe what you want instead of how to do it step by step. it’s also easier to maintain over time, especially if your setup grows or changes. just add that new vm to the inventory list.

if you’re already comfortable with shell scripts and just want to get a few vms going, you could totally get by without ansible. but if you’re planning to do this more than once, or want to be able to rebuild things cleanly, it’s worth it, imo. it could save you a lot of headaches later on.

i use it at work, i manage about 40 vms in our pre-production environment with ansible. if i need to install a new package on all, it’s one line and one command (ran in a pipeline). if i need to change the settings for unattended-upgrades on the debian machines only, same thing.

however, our “production” environment is k8s and a handful of external services, and we use terraform to manage all that.

i guess it all depends on your needs.

They also have an API, I think a chunk of that revenue comes from there. Think 3rd party apps and services having chat bots, writing assistants, etc that use openai’s API.

Oversimplifying it, Ansible playbooks are nothing more than some commands that should be run on a remote machine via ssh. Ansible knows or has modules for a variety of different package managers (apt, yum, etc) and automagically knows how to handle services or various config files.

It can get complex, but I think just the startup phase, until you have an inventory of remote machines, the ssh keys are in place, etc. I second the Jeff Geerling recommendation, his stuff is solid, both ready to use playbooks, and tutorials.

I would suggest to also look into cloudinit. Makes setting up VMs on proxmox easier, faster, more consistent, with users, networking, ssh keys, etc ready to use (by you or by Ansible).