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.

  • talkingpumpkin@lemmy.worldEnglish
    1·
    27 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
    1·
    27 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

  • Daniel Quinn@lemmy.caEnglish
    0·
    28 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.

    • Jul (they/she)@piefed.blahaj.zoneEnglish
      0·
      28 days ago

      What do you use for repeatable recovery and deployment of systems?

      I’ve looked at ArgoCD and FlexCD. ArgoCD was too flaky. When I made changes to helm files it would often fail to deploy them and the UI often wouldn’t really show the detailed errors from things like helm syntax errors, so it was a pain to troubleshoot.

      FlexCD was just really a pain to configure in the first-place and I didn’t want to learn kustomize when I already have helm charts.

      And neither really supported staged deployments or dealt with dependant services well. So I couldn’t get it to deploy the infrastructure level helm charts like PostgreSQL before deploying the services that depend on it. Technically, with Kubernetes it shouldn’t matter about the order of deployment but in reality when ArgoCD would deploy the other stuff first and wait for it to come up and it never came up because the dependencies weren’t there, it caused it to choke a lot.

      Just an example of the issues I’ve had. But I really want an easy way to make lots of small changes to charts and deploy them quickly as well as being able to quickly recover the cluster from backups if something catastrophic happens like a fire without having to manually deploy each chart. Just curious how others handle it or if it’s always manual deployment of charts via CLI only.

      • Daniel Quinn@lemmy.caEnglish
        1·
        9 days ago

        I’ve used FluxCD in the past and have looked into ArgoCD, but honestly, I’ve not seen any big benefit from either to be honest. I use k8s both at home and at work, and in both cases, we do “imperative” deploys: you run helm install ... either directly or via the CI and stuff is deployed.

        So for example at my last job, our GitLab CI just had a section triggered exclusively for merges into master that ran helm install ... for all three environments. We had three values.yaml files, one for each environment, and when we wanted to deploy a new version, the process was:

        1. Create a tag for our release version (ie. 1.2.3) and push it to the repo. This would trigger a build and push the resulting image into the container registry.
        2. Push an update to the repo with the new tag set in the appropriate Helm values file. If we wanted to deploy 1.2.3 to development but not yet to staging or production, then the tag: value in each of the environment files would look like this:
        • k8s/chart/environments/development.yaml: tag: 1.2.3
        • k8s/chart/environments/staging.yaml: tag: 1.2.2
        • k8s/chart/environments/production.yaml: tag: 1.2.2

        Once that change is pushed, the CI will automatically apply it with helm install ... and make sure that all three environments are what they’re supposed to be.

        As for dependent services, that should all be in your Helm chart so they’re stood up and torn down together. The specific case you mention about “Service A” being dependent on “Service B” but stood up before “Service B” is ready is a classic problem, but easily solved:

        The dependent service (“A” in this case) should have an entrypoint that checks for everything else before starting. Here’s what I’m using right now in a project:

        #!/bin/sh

while ! nc -z "${POSTGRES_HOST}" 5432; do
  echo "Waiting for postgres..."
  sleep 0.1
done
echo "PostgreSQL started"

touch /tmp/ready

exec "$@"

        I’ve even got some code that checks that all the Django migrations have run first for the same situation. The Kubernetes philosophy is that any container should be able to die at any time and be eventually be brought back up and that every container needs to be prepared for this. Typically this means that your containers should operate on the basis of “if I can’t work, die, and hope the problem is solved by the time Kubernetes redeploys me”.

  • K3CAN@lemmy.radioEnglish
    0·
    28 days ago

    I’ll second podman quadlets. Good security, full integration with systemd, pods allow applications to easily share a namespace, and you can manage graphically through Cockpit if you really want to.

    • thirdBreakfast@lemmy.worldEnglish
      1·
      28 days ago

      As a tinkerer, I have tried Portainer a couple of times, and another similar thing, but I end up never looking at them, and revert to just jumping into the command line. A bonus of this approach is keeping a copy of all my compose files in a repo.

      If OP is being drawn to this because they want to know everything’s running, what they’re really looking for is monitoring - probably Uptime Kuma.

  • fozid@feddit.ukEnglish
    0·
    27 days ago

    I recently moved from docker compose to podman quadlets. Took a bit of effort, but fully foss, and for me it’s set and forget. Have about 30 containers across about 12 services. Have them set to auto update and it all runs through systemd.

    • motruck@lemmy.zipEnglish
      0·
      27 days ago

      This is the direction I’m headed. Goodbye docker. Quadlets everywhere. Im in the process of converting docker run scripts currently. Any tips or gotchas you can share that you learned?

      • fozid@feddit.ukEnglish
        1·
        27 days ago

        Permissions were a pain to get right for my volumes and data I migrated. Other than that, It’s really not that complicated, it was just a case of covering my compose files to systemd service files and starting the update timer.

    • valar@lemmy.caOPEnglish
      0·
      28 days ago

      Thanks, what have you liked about switching to this from portainer?

      • Kupi@sh.itjust.worksEnglish
        0·
        28 days ago

        I just recently switched from portainer to dockhand and I really like it. The UI is great and the setup and config wasn’t too complicated. I like that I can put both of my servers into one instance and can update all of my containers from dockhand vs manually. The other thing I like is being able to view the logs for my containers. Idk if it’s a me thing, but whenever I would try to view logs in portainer I would never be able to scroll up as it would update and send me back to the bottom. Again, I could’ve just been doing something wrong, but it always bothered me and I don’t have that issue with dockhand.