Shameless plug: I'm also developing a GUI for Docker Swarm, if you don't feel like fiddling with command line too much: https://lunni.dev/
The getting started guide will walk you through setting up a single-node Docker swarm from a clean Debian / Ubuntu install: https://lunni.dev/docs/install/
> I'm also developing a GUI for Docker Swarm, if you don't feel like fiddling with command line too much: https://lunni.dev/
This seems like a cool idea, I wish you the best of luck!
I will, however, also link Portainer, which I've used for both Docker Swarm and Kubernetes management: https://www.portainer.io/
It does basically everything you might want (it even gives you redeployment webhooks, which will make new containers be pulled, if you enable them), with the caveats that they're focusing a lot on adding paid functionality nowadays and infrequently you might have connectivity issues, which a redeploy of Portainer will fix.
When I did use it, however, it did feel a little bit broken in places and the experience wasn't quite as smooth as Portainer was (also, for whatever reason, it seemed to give me back different YAML than the one that I had last deployed, maybe generating it on the fly?). No idea what was up there, but the UI was pleasant regardless.
So I think it'd be pretty cool if someone were to borrow the ideas that work from either those as inspiration for their own tool! :)
On the CLI, there's also ctop, which is nice for inspecting the current containers on a node, even if it doesn't really have much to do with Swarm: https://ctop.sh/
Lunni actually uses Portainer as a backend right now. Portainer is a very powerful tool, a Swiss army knife of sorts, but I find the UI a bit complicated. (That's actually one of the reasons I started Lunni!) E. g. to deploy a new stack, you've got to wait for environment list to load, select an environment, go to Stacks, wait for stack list to load and only then click New stack. In Lunni that is one click away from the dashboard.
Swarmpit is also pretty nice, but yeah, broken in a couple ways. The quirk you encountered is actually pretty easy to explain: I think old versions of Swarmpit didn't store the YAML, but reconstructed it from the current stack state. It's actually pretty neat: if you deploy something outside of Portainer, it will complain that it doesn't know this stack and won't let you update it. Swarmpit however would show you what YAML could produce this stack, so you have at least something to work with. I might borrow this idea at some point, too :-)
As a satisfied Swarm user, and with positive signs regarding Docker Swarm's future (repo activity up, Mirantis talking about it and its future), I wondered if there would be an opportunity to propose managed hosting of Swarm deployments. Not having much time to work on it right now, I'm happy to see someone else doing it. Best of luck!
I built my own GUI along similar lines using ImGui/Wasm for personal use; figured that as K8s/complexity already won the mindshare there wasn't much point in releasing tooling for simple (aka unfashionable) tech.
I think simple tech is underrated nowadays. Kubernetes is nice and cool when you're Google or Amazon or a startup with enough investor cash to buy a whole team of devops engineers. When you're a small team that tries to bootstrap something, or a single human being just want to run a thing or two for yourself – not so much.
Docker Swarm to me is the balance point: it's easy enough to learn to start small, but it's powerful enough to scale if you need it later.
^ takes you through a 3 server setup and deploying services via the CLI rather than a docker "stack" file, which is basically a compose file with the ability to set additional deployment specific properties.
just set up the one manager and skip anything about additional worker nodes or draining nodes.
for docker stack files -- see the docker compose v3 reference but take heed of any `docker stack deploy` caveats in the compose documentation. anything about docker stack deploy` is "stack file" territory.
compose file v3 is being depreciated this year, with a new specification aiming to unify the two. but it gives you an idea of the historical differences between old `docker-compose up` and `docker stack deploy` (swarm).
