Duet RPI and docker
-
RPI are supporting docker containers and there is a general trend towards containerization.
Wouldn't it be nice if DCS
DWCand DWS are running in on a docker container?Did somebody tried something similar?
What is your opinion about that? Do you see more advantages or disadvantages? -
Good question. I've only just started with docker myself. I'm not really sure when and where and why it would be appropriate.
Do YOU think it would be a good idea?
-
DWC runs on a client browser, so not sure why that'd be used inside a container.
DuetControlServer (not mentioned in the OP) needs access to the SPI. Can a docker container access SPI? (I don't know. I've never tried to virtualize anything on a Pi before.) I'm only mentioning DuetControlServer because I think it creates the unix socket that everything else talks to (CodeConsole, etc.)
DuetWebServer (DWS), I think, needs to be able to read/write the unix socket that DuetControlServer. If DWS is in the same container as DCS, that's not an issue (but then how does DCS talk to SPI?) If they are in separate containers, can DWS talk to the unix socket that DCS created in another container?
Even if there's a way to make all that work, what is the purpose of it? What problem, issue or desire does it resolve?
-
@garyd9 said in Duet RPI and docker:
Can a docker container access SPI?
sure, its just a device node in /dev/spidevn.n or something like that, you can share that with a container just like a serial port (/dev/ttyUSB0 etc) that is a very common use case
edit: but I can't say I see the value to the average user of having the devs containerize DSF when they already supply a custom image. maybe we'll see it as a result of oem needs in the future but not as just a "nice to have" feature.
-
is this really necessary? With a duet you are basically dedicating one rpi to one task, it is basically already compartmentalized. Why would you want to add a layer to a machine that is already doing one thing only?
-
It might be useful to an OEM for dealing with OTA updates and security/network stuff, as there are tools for that in Docker iirc.
But there are lots of other tools for doing the same thing without using containers.
Its going to depend on the OEM's staff skills, what are the tools they know/like.
Is it worth the core team spending time on it? Absolutely not. Would it get used if someone built it out for them, maybe.
The challenge for an OEM is that once you open up the 'network' box it becomes a giant sucking hole that all your support money gets pulled into.
(What do you mean the printer has become a spam server!? No we don't provide regular security updates!).
Although to be fair, that is probably an argument for Docker, rather than against it... -
There was a request to provide Docker support for DSF a while ago (see here) but I see no real benefit for most users. Upcoming plugins for DSF (or rather easy-to-use plugins) will have limited permissions enforced by AppArmor security profiles so I don't see any need for container solutions.
For users who don't want to use AppArmor it may be an alternative to run the plugin services in a Docker container but that will require extra configuration.
