My homelab is essentially my own passion project and only really I access it except for when I spin up the occasional game server for friends.

I’m currently running Proxmox and run a debian LXC container for each docker stack I have, and have OpnSense routing incoming traffic with Haproxy with ssl offloading. My currently running LXCs are: mediawiki, amp game server(2 Minecraft servers), freshrss, and currently playing around with n8n.

I’m looking to collapse my LXC’s to just VMs. I’d like to be able to have 3 VMs running in a Docker Swarm together so I can upgrade a VM at a time and just swing my running containers to another docker node and then swing back when the VM is stable again.

I’ve looked at k0s, k3s, and k8s and it just seems way too much work and overhead for what I’m willing to do. I also want to keep using docker compose and want a decent webgui to manage my containers/nodes/swarm. I’m using DockHand right now, but need to research swarm support.

Anyone have any advice for something like this? Any specific terms, tech, software I should look into?

Also, gonna throw a curveball, but what would the effects be of running 3 different distros as my nodes in my swarm? Like a Debian node, Rocky Linux node and potentially arch node? I’m guessing I shouldn’t due to docker engine differences potentially.

I’m just trying to have fun with things, break things, fix them, learn, etc.

  • moonpiedumplings@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 days ago

    Hello, I also run k3s on a single node here.

    Yes, it is more complex in some ways. But what I love about kubernetes, is the helm package manager and it’s ecosystem, that makes it easier to user packages from other people and organizations.

    They can be searched here: https://artifacthub.io/

    There are many that you may be interested in, like forgejo.

    The big thing I like about helm vs docker-compose, is helm is another layer on docker-compose. If an app receives an update that causes it to need another service/container deployed, that will be reflected in the helm release, which orchestrates containers. But with docker-compose, you would have to manually update the config file format in order to handle such changes.

    Because this setup is more resilient, I actually just auto update all my apps to the latest version on kubernetes, and this is one of the big reasons why I use kubernetes instead of docker. Yes, things do occasionally break, but they mostly break in predictable, easy to handle ways like “config option changed” or “database needs migration”. Plus backups/snapshots to ensure if there is a bug or something I can simply roll back.