I’m trying to access /dev/ttyUSB0 from a container running zigbee2mqtt. This works fine with plain docker run … --device=/dev/ttyUSB0 … and docker-compose.yaml using the device: entry.
But the device: entry is gone from the swarm stack definition. If I instead volume mount it, it fails to open properly. Why is that?
I get that swarm is for clusters, and the devices cannot be guaranteed to exist on all nodes, or even support being used from multiple process in case of replicas. But the same can be said with files, directories, and volumes which all can be volume mounted.
With careful node pinning using constrains, I’d argue that a safe setup can be achieved and devices accessed.
So why does swarm not support device files?
(Or have I misunderstood something?)
I don’t recall that device was ever supported by swarm stacks. From what I remember you would need to start the container with privileged mode (Which does not exist for swarm service tasks, but might be solved via cap_add if you find out which capabilities are required), and you would need to mknod the device. It might work, but might also not.
Swarm was never designed for hardware close or low level container features
What a great proposal; it looks very detailed and pretty much ready to implement, at least parts of it to begin with. The PR would surely be a welcomed addition!
I don’t mind development on Swarm being dead if Swarm is feature complete. But it isn’t at this point. Where are all the devs at? Doing Docker Desktop? =\
Right, bad wording from my side perhaps; I didn’t mean to imply that it has been removed; I simple meant: Why isn’t it there?
Thanks for the suggestion. I added this for starters:
cap_add:
- ALL
user: "0:0"
command: >
sh -c "id && mknod -m 666 /dev/zigbee-serial c 188 0 && ls -l /dev/zigbee-serial && docker-entrypoint.sh /sbin/tini -- node index.js"
and it looks like zigbee2mqtt has slightly better success opening the file, meaning it doesn’t fail immediately, but it does later on during init, perhaps when it tries to write to the device.
I’m not sure how to debug this further. I think I’ll start this service as a docker-compose thing for now, and see if I can make it talk to mqtt in my swarm cluster.
I know, but it makes sense to have this option. And perhaps naive, but I thought it would be a low-effort feature since it’s already present in docker (and compose).
The challenge is that no one cares about Docker Swarm.
Docker Inc sold the Swarm business to Mirantis, they promise to maintain it (blog), but it seems most development is only happening on their close source paid version.
There is still a public repository, there are even ready pull requests (like this one from a Docker developer), some even for years, but they are just not merged. Complaining and begging does not help.
And device support would be really essential today, to support AI cards and Confidential Computing.
There are active maintainers for open source moby (Docker Engine CE), but they rarely touch swarmkit, especially not for new features. And the final approval seems to be with people from Mirantis, who usually never respond.
I think it’s a very sad story, Swarm works, it’s so much easier than k8s, bugs are sometimes fixed, but no new features added. So you have to live with the existing feature set or move on.
From a business perspective there is no money to be made, Docker focuses on the Desktop product, which has its own challenges, as most people don’t understand it’s a development tool (not for production) and uses a VM on Windows to run Linux.
I asked Gordon which confirmed what I would have said anyway and what was already said in this topic, but I still share Gordon’s response:
My question: Is Docker Swarm still under active development? Gordon’s Answer:
Docker Swarm, specifically the Swarm mode integrated into Docker Engine, is still supported and maintained, but it is not the primary focus of Docker’s development efforts. The classic Docker Swarm, which was a standalone tool, has been deprecated and is no longer actively developed. Docker Swarm mode, which is built into the Docker Engine, continues to receive updates and bug fixes, as seen in various release notes over the years.
However, Docker’s development focus has shifted more towards Kubernetes and other container orchestration solutions, as Kubernetes has become the industry standard for container orchestration. Docker Swarm mode remains a viable option for simpler use cases and smaller-scale deployments where its ease of use and integration with Docker Engine are beneficial.