Dive into the world of Docker Swarm Mode with us as we uncover its user-friendly setup and Windows compatibility. In this article, we’ll navigate the challenges, from port mappings to scheduled tasks, shedding light on the nuances that make it a powerful yet evolving container orchestration tool.
There is a lot going for Docker Swarm Mode, as I discussed in the last article. It’s easy to install and set up. The learning curve is really quite small if you’ve already used Docker Compose. The Windows support is strong, and setting up a development environment, if you’ve already got Docker installed, is literally one command.
What are the downsides then? Why isn’t everyone using it if it’s so good? Well, that last point is deeper than I particularly want to get into today but let’s cover some of the key points. Swarm Mode hasn’t had many updates and new features recently, and significantly, there is considerable industry momentum towards k8s. Let’s talk about missing Swarm Mode features that you’re going to notice pretty quickly.
When you deploy your first web app in Swarm Mode, you’ll set up your port mappings so that port 80 and 443 map to that container. All great stuff. You’ll test it and it’ll work nicely. Then you come along to deploy your second web app. What do you do about the port mappings? Oh, you can map to port 8080, or 8081, and 8443, etc, etc, but that starts to be a maintenance nightmare pretty quickly. What you need is a reverse proxy, to handle HTTP->HTTPS redirection, virtual sites based on different DNS names, SSL/TLS termination so you don’t have to worry about that in your individual web apps. What does Swarm Mode give you? [tumble weed rolls past, to the sound of crickets chirping] Yes, that’s right. Nothing. You’re on your own, left to manage that reverse proxy yourself. What fun. We’re back to managing a custom solution, with your own scripts, custom configuration. Yes, it really is that disappointing. Well, it’s certainly possible, and you can provision an Nginx or Apache HTTPD reverse proxy, but make sure you get those config files right or you’ll be debugging connection failures and web socket issues for ages.
Fortunately, a very clever person created the Nginx Proxy Manager (https://nginxproxymanager.com/), which deals with this exact issue. Just use that, don’t try setting up Nginx config files yourself.
The next thing that I came up against when running a Swarm Mode cluster, was the lack of scheduled tasks. Now, when you go searching for information on this, you’ll get all sorts of false positive results as the term ‘scheduling’ is used to describe how containers (‘tasks’ in Swarm Mode parlance) are allocated to a particular host. That’s all really important stuff to understand, but it doesn’t help you get a container to run on a time schedule. You’ve actually got a couple of options here:
1 – build the scheduling mechanism into your app or image, e.g. using cron or Task Scheduler within your container. This isn’t ideal, as you’re managing schedules in lots of different containers.
2 – Fortunately, another smart person created ‘Swarm Cronjob’ (https://crazymax.dev/swarm-cronjob/). Yes, it is Linux only, but it works really well and is very easy to use. If you’ve got a mixed cluster with Linux and Windows hosts, it’ll happily run the Windows containers on a schedule too.
A couple of other areas that I’ve found added friction to the experience with Swarm Mode, as compared to various k8s distributions are related to container images registries and dashboards. These aren’t deal breakers, and are relatively easily addressed, but just make things a bit more barebones for the out-of-the-box experience.
Once you get into the realms of multi-host clusters, you don’t want to have to deploy your custom images to each host manually, you really want to have an image registry. There are a couple of options here. If your images aren’t proprietary/confidential then you can add them to Docker Hub. You can also pay for private image registries either from Docker directly or from the major cloud vendors. Your other option is to deploy the ‘registry’ container to your swarm and store your images there. There’s a bit of set up involved, and it only works on Linux, but you can get there. A pretty small thing to complain about, sure, but it’s friction like that and the lack of a decent default that gets in your way.
There are a couple of dashboard options for Swarm Mode, both available as containers. There is the ‘visualizer’ (https://hub.docker.com/r/dockersamples/visualizer) which is a simple view of which containers are running on which hosts. It’s nice and lightweight, simple, but as you’ll see in the comments, isn’t designed for production use and needs securing. Then there’s Swarmpit (https://swarmpit.io/) which is much more fully functioned and displays a lot more information.
These options are perfectly useable, but the problem here again really is that there isn’t a defacto standard dashboard unlike k8s, so you have to go off the beaten path to get one going, and then there is less knowledge around the internet on any issues you might encounter. Now, none of that is going to put you off, you’re an adventurous person with a keen interest in exploring technology! It’s just another little bit of friction that gets in your way.
Right then, so you’ve read my last couple of articles about how great containers are, and how much you can achieve with a simple Docker setup. Next time, I’m going to talk about why you might actually want to use Kubernetes instead. I’ll do a comparison of Swarm Mode and k8s so you can make informed choices, and so that you can also see the learning path from Swarm Mode to k8s. See you then.
 I’m going to do a comparison of Swarm Mode and k8s next time, so you’ll see how they directly compare, where the similarities lie and where they differ.
 the rubbish, tedious kind of fun that no one likes.
 Although, if you’re running a Windows only cluster, you are going to have to look elsewhere. Nginx and Apache both run on Windows, so you could set up your own Docker image. You could always use IIS with the ARR module, if you were so inclined: https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222
 Finally! Blimey, he doesn’t half waffle on. When are we getting to the good bits?