Container Orchestration and Device Mapping

StrangeWill

Administrator
Staff member
So some background: I've been a fan of using Docker Swarm for smaller deployments, I'd argue it fits a massively needed niche where Kubes is way overkill or less accessible for a long list of reasons.

So I recently moved a project that uses as a bunch of Raspberry Pis to handle a bunch of printer and COM devices on the network from standalone Docker instances (because the peripheral code almost never gets updated) to Docker Swarm and joining them all together, because we had a couple patches to push to the standalone instances and I had to reimage most of them anyway -- take advantage of that needing to be done.

However, I found major critical issues:

You cannot mount hardware devices within the docker container, they cannot run privileged, they cannot (effectively) map /dev/bus/usb:/dev/bus/usb (it requires privileged containers).


So far all I can think of is:

  • Go back to unmanaged instances
    • Not a huge deal, they patch infrequently, but still super annoying
  • Use swarm to manage containers that exist not managed as part of a stack.
    • This is almost silly but should work
  • Use something like k3s, lightweight kubes (assuming it allows access to hardware)
    • The idea of deploying any flavor of kubes on Raspberry Pis makes me feel sick, overkill on low-power hardware.

My main goal is to have our software, when it deploys a new version of the app to Swarm, to automatically update the child nodes.


I'm super tempted to basically just make a sidecar image who's entire purpose is to just work with the docker engine locally, deploy that globally on the instances and it should get me the best of both worlds (even if the nested image is somewhat "hidden" at the Swarm level)


Thoughts?
 
I like your suggestion to go with a sidecar image, particularly if you just need to get this solved and move on.

I'm curious how Balena approaches this.
 
Back
Top