I have built all our infrastructure on Docker Swarm before learning about its state. Currently waging migrating to Nomad out of fear for K8s complexity - I’ve worked with it in a previous job with more employees than now, and it still was a big hassle - but am afraid I’ll repeat the same mistake and should just bite the bullet. Does anyone have suggestions?
Swarmlet: A self-hosted, open-source Platform as a Service
31–40 of 47 posts
Re: Swarmlet: A self-hosted, open-source Platform as a Service
#32I really like the option to deploy through a git push without additional setup, and I am looking for something similar to host a bunch of containers. Does anyone here have experience with such a tool, and what is your experience regarding reliability?
Re: Swarmlet: A self-hosted, open-source Platform as a Service
#33I really like the option to deploy through a git push without additional setup, and I am looking for something similar to host a bunch of containers. Does anyone here have experience with such a tool, and what is your experience regarding reliability?
https://pypi.org/project/docker-harbormaster
It's great if you want to run generic utilities at home (though I've used it at work in internal production and it was good), but it doesn't do ingress, so you have to bring your own.
It's basically a fancy/opinionated wrapper over "git pull && docker-compose up", with allowing you to specify all configuration in one file/repo.
Re: Swarmlet: A self-hosted, open-source Platform as a Service
#34Earlier quoted context omitted.
Nomad running as a server (manager) and client (worker) on the main server, and as a client on a rpi3, through systemd on both, the install [0] and deploy [1] instructions worked well enough. It has constraints to control which client takes what workload (ex. I don't care which runs ddclient, but photoprism can't move to the rpi, and the sensor readers can't leave the rpi). Caddy for reverse proxy and tls handling ru…
> services have a static port and I just route to the port in the caddyfile Just so I understand - this means deploying a new service involves building a docker image, deploy it, then manually update the caddyfile (ie manual ingress)? > There's a couple ways to mount the volumes, which is annoying, Fwiw this is annoying on multi-node docker swarm too - i even consider proper volume support to be one of the strongest…
And I'd agree that the volume story isn't great compared to what I know of k8s. There's info out there for setting up NFS volumes, or something like portworx or ceph, but that's going beyond what I want to do for 1-3 pet nodes on a home server, I can deal with volumes staying bound to a node.
[0] https://traefik.io/blog/traefik-proxy-fully-integrates-with-...
Re: Swarmlet: A self-hosted, open-source Platform as a Service
#35Swarm was great. Docker/Moby should never have abandoned it. Kubernetes solves a similar class of problems to Swarm, but in a much more complex way. Sometimes that complexity helps solve problems. For many organizations, though, Swarm would have been the better option. Both Swarm and Kubernetes have their purposes. I'm sad that no option has popped up to replace Swarm in the "simple and easy container orchestration"…
This doesn't look that abandoned? https://github.com/moby/swarmkit Or are you talking about swarm the product (versus docker swarm mode)
Re: Swarmlet: A self-hosted, open-source Platform as a Service
#36I really like the option to deploy through a git push without additional setup, and I am looking for something similar to host a bunch of containers. Does anyone here have experience with such a tool, and what is your experience regarding reliability?
A 2nd for Dokku. It's dead simple and works on any host. Yes, it is limited to single server architecture, but for most people this shouldn't be a problem. Vertical scaling can go a long way.
Dokku does support both Kubernetes and Nomad as deployment targets, so it's not strictly single-server (though app builds currently are).
Re: Swarmlet: A self-hosted, open-source Platform as a Service
#37Earlier quoted context omitted.
> services have a static port and I just route to the port in the caddyfile Just so I understand - this means deploying a new service involves building a docker image, deploy it, then manually update the caddyfile (ie manual ingress)? > There's a couple ways to mount the volumes, which is annoying, Fwiw this is annoying on multi-node docker swarm too - i even consider proper volume support to be one of the strongest…
yeah, that's what I have now. I see the path to letting nomad deal with the addressing (rather than specifying static ports), but setting up a route in caddy for a new service would still be manual. I expect you could do some fancy scripting/go templating with the caddyfile and template block to make it spin up new routes more "automatically", but at that point I think you'd be better off seeing what Consul could do…
Re: Swarmlet: A self-hosted, open-source Platform as a Service
#38Swarm was great. Docker/Moby should never have abandoned it. Kubernetes solves a similar class of problems to Swarm, but in a much more complex way. Sometimes that complexity helps solve problems. For many organizations, though, Swarm would have been the better option. Both Swarm and Kubernetes have their purposes. I'm sad that no option has popped up to replace Swarm in the "simple and easy container orchestration"…
Re: Swarmlet: A self-hosted, open-source Platform as a Service
#39I have built all our infrastructure on Docker Swarm before learning about its state. Currently waging migrating to Nomad out of fear for K8s complexity - I’ve worked with it in a previous job with more employees than now, and it still was a big hassle - but am afraid I’ll repeat the same mistake and should just bite the bullet. Does anyone have suggestions?
Re: Swarmlet: A self-hosted, open-source Platform as a Service
#40Swarm was great. Docker/Moby should never have abandoned it. Kubernetes solves a similar class of problems to Swarm, but in a much more complex way. Sometimes that complexity helps solve problems. For many organizations, though, Swarm would have been the better option. Both Swarm and Kubernetes have their purposes. I'm sad that no option has popped up to replace Swarm in the "simple and easy container orchestration"…
Docker should have built a "better" K8s distro. Right now what they have is junk. Even Rancher isn't filling the niche. I don't think K8s is such a huge hill for new folks. Anyone who spends 5 minutes looking at basic deployment YAML can figure out what to do next. Getting a cluster up and running is the hardest part these days. Minikube, K8s in Docker, and even K3s all suck. There is still ample opportunity for them…