What to people use and recommend for this? I’ve read a bit about portainer, but I’m still learning - and don’t know what the best solutions are.

Today I have a handful of selfhosted services running on my home machine - mostly installed directly, but a couple running as docker containers. As the scale of my selfhosting has grown, I’ve realized that things would be a lot easier to manage if each service was run as its own container, so that installed services are isolated.

The solution I’m looking for would make it easy (possibly a web UI) for me to monitor, modify, update, and remove containerized services, including networking and storage.

Edit: Also I would only want a FOSS solution.

  • Joker@lemmy.mlEnglish
    11·
    11 days ago

    I personally like dockge, it’s simple and lightweight and I like the fact that the webui has a good phone interface.

  • jrgd@lemmy.zipEnglish
    10·
    11 days ago

    Might take a little bit of effort to do a conversion if you’re locked into explicitly how Docker interacts with OCI containers, but over in the Podman camp you have two options.

    • Cockpit with the Podman containers interface: a graphical web-based solution for managing podman containers and the rest of the system.
    • Podman Quadlets: a config file-based way to manage Podman containers, volumes, pods, networks with custom SystemD units. Great if you want to version control your deployments.

    Other than that, the more usable solutions I’ve tried of graphical Docker container management interfaces would be the ones in Unraid and Proxmox, though those solutions may not be suitable depending on your use case and have their own caveats to be aware of.

    • valar@lemmy.caOPEnglish
      2·
      11 days ago

      Im not locked into docker, but it’s what I have experience with so far, and a lot of services seem to have docker installation as a default option.

      Do you think those things make it difficult to switch to podman? What are the differences?

      • jrgd@lemmy.zipEnglish
        51·
        11 days ago

        Starting with confirmation of what others have said, yes you can use compose tools with Podman and Podman can hook directly with Docker Compose (the tool), but it really isn’t recommended. Compatibility with compose now is better than it used to be, but there are still edge cases. For a lot of projects that just pre-write a compose file that they expect to cover the general use case of their container, you’re best to take the compose file and write it out to Quadlet unit(s).

        Other differences not mentioned can include:

        • Podman alongside containers has optional pods, which let you wrap multiple containers together, sharing the same IP internally. Useful for having a service and their sidecar containers (e.g. Valkey, Postgres, Meilisearch, etc.) be bundled under the same IP address and simply reference each other as localhost, 127.0.0.1, or ::1. If you utilize pods for certain split-container applications, you may need to remap certain service ports as they can overlap and cause binding failures.
        • Podman has multiple networking modes. If you use Podman at the system level (rootful) like Docker expects you to, you’re not really going to encounter any quirks with the default networking setup. Per-user Podman (rootless) defaults to using the Pasta backend for networking, which is still very highly performant, but is a bit clunky to configure (if ever actually necessary) and inter-pod communication can be difficult to get right. Alternatively, registering rootless pods with a bridge network makes inter-pod communication easy, but can cause problems if accurate source IPs are needed (e.g. upstream reverse proxies, accurate client IP logging, etc.).
        • Because Podman is daemonless, there is also no persistent API socket loaded by default (an intentional security choice). For both rootful and rootless containers, you can enable this manually and mount it to containers that need it. For containers that expect docker.sock explicitly for API manipulation, your mount will need to reflect the name change of the podman.socket to what the container expects.
        • Podman by default won’t shorthand container pulls from docker.io by default: a sin I see constantly done in so many compose files. When pulling a container from DockerHub, you need to put the docker.io/ prefix, just as you would but the appropriate prefix with Quay, Github, Gitlab, or any other distributor.
        • Podman can optionally let you auto-update containers based on the release tag specified for the container.
        • Because of Podman’s integration with SystemD, a lot of oddball integrations (external cron jobs, one-shot services, etc.) can be pulled together with extra SystemD units (services, timers, etc.).
      • Meron35@lemmy.worldEnglish
        3·
        11 days ago

        Docker’s main advantage is just being more well known and hence more supported as a default option.

        Even then, I feel that this availability of docker compose files is an illusion, due to their verbosity and limitations inherent to docker. Less granular control of permissions, clunkiness in updating images, and multi container stacks feeling like an afterthought.

        In pretty much all other ways podman feels superior. Cockpit provides a basic web gui, but quadlets are the main draw. Way easier to configure, explicitly designed for multi containers, and updating all images is a single command.

        Roughly, the different ecosystems from least to most complex are:

        Docker/Portainer -> Podman/Cockpit/Quadlets -> Kubernetes

  • GunnarGrop@lemmy.mlEnglish
    7·
    11 days ago

    I’d absolutely recommend Kubernetes (k3s/rke2) or podman quadlets. Quadlets are a lot easier to get started with, but are still very flexible.

    I’d recommend against using portainer. I tried it quite recently and I did not like it at all. A lot of features are paywalled, and was overall just a frustrating experience. I’ve heard it was a lot better some years ago.

  • talkingpumpkin@lemmy.worldEnglish
    6·
    11 days ago

    In your shoes (and, in fact, in mine) I’d try to move away from interactive tools and into file-driven ones.

    Personally I use nixos, run WUD (what’s up docker) to be notified of available updates, and manually test/update the containers once in a while (every couple weeks or so?)

    There are a bazillion other solutions (from stuff like ansible/chef/puppet, to docker-compose, to kubernetes, to… a hand-written bash script) - the idea is to setup stuff via files that you can version, reference and write comments in rather than using some gui for interactive steps that you’ll forget to document in some wiki.

    Monitoring is a whole different beast than configuring: you’ll be probably better off using something that does just that instead of some all-in-one solution. Try looking into something like beszel before going for the full prometheus/graphana stack.

  • jimmy90@lemmy.worldEnglish
    5·
    11 days ago

    try NixOS

    all your containers and other services will be managed through one re-usable file

    if your server is >= 8GB then proxmox gives a nice interface builtin. i use it to make nixos lxc containers in which i run my containers. which does actually make sense

      • talkingpumpkin@lemmy.worldEnglish
        4·
        11 days ago

        you will have to spend a lot of time learning the Nix language

        I’d say you shouldn’t use any system (be it nixos, ansible or even bash scripts) if you are not willing to learn it.

        That said, I too find pre-made modules less useful that I initially thought when I got into nixos: unless you want to do very basic stuff, a lot of times it’s easier to just generate whatever scripts/configuration files you need directly (using one of the trivial builders in lib or writing a custom derivation) rather than learning how the corresponding nixos module works.

        One could say nixos modules make easy things slightly easier, and hard things much harder (this is adapted - possibly imprecisely - from a quote on ORMs, I think by Joel Spolsky).

  • irmadlad@lemmy.worldEnglish
    41·
    10 days ago

    I’ve read a bit about portainer, but I’m still learning

    I started with Portainer, and I still use it. It checks all the boxes for me. I would be remiss if I didn’t mention there are other such platforms to manage Docker containers with such as Podman, Dockage, etc. Like I said, I started with Portainer, and I know how to drive that bus, so I stuck with it.

  • gedaliyah@lemmy.worldEnglish
    3·
    11 days ago

    I was using CLI exclusively for a year or so, but recently added DockMon and it’s helped with updates and at-a-glance management.

  • Daniel Quinn@lemmy.caEnglish
    41·
    11 days ago

    Kubernetes. For a homelab, the stripped-down k3s is fantastic and surprisingly easy to get going.

    Once you’ve got Kubernetes set up, you can lean on all the many tools already out there for things like deploying complex projects (Helm) and monitoring (Prometheus/Grafana). OpenLens is a nice piece of software you can use to monitor and control your cluster too, as is k9s.

    • thejml@sh.itjust.worksEnglish
      3·
      11 days ago

      This is how I went and what I’d recommend. But that said, it’s a bit of a steep learning curve as not everything in the self hosted/home lab community comes with helm charts.

      • motruck@lemmy.zipEnglish
        2·
        10 days ago

        Generally my suggestion is if you use kubernetes at work or want to learn it, self host that way to learn. If not don’t add all the complexity and use docker, docker compose, podman, etc. Kubetnetes is overkill for 90% of the use xases Ost companies have but here we are.