Hi everyone,
I am seeking advice on the recommended approach for designing a Snap application in a multi-process architecture. Specifically, I am considering a parent process with several worker processes. Should all these processes be contained within a single Snap package, or is it feasible to have separate Snaps for each process, with shared access to common resources?
Additionally, I understand that Snaps are typically designed as application containers rather than process containers. How does this approach translate to IoT environments? Would using MicroK8s be a viable solution for managing such a multi-process Snap application?
Thank you for your insights!
Ali Baghernejad
There’s already a Kubernetes snap that works for IoT, so yes, it’s viable (unfortunately I don’t use K8S and can’t actually speak much to it by itself).
In general, you’d likely be fine having multiple processes/binaries/etc in a single snap. You can assign different sandbox profiles to each specific application, have specific ones launch automatically as daemons, or on demand via the CLI, etc. They’ll share their $SNAP_DATA, $SNAP_COMMON, etc folders, as well as other critical folders, such as /dev/shm/ and /tmp which come into play every now and then.
Where you’d want to split snaps up is if their library dependencies are unmanageable. E.G, if you have an app that needs multiple versions of Python for several components, it might be easier to treat each component as a separate snap, or it might not. More specifically, if you have A that needs Core20, and B that needs Core22, that’s almost going to guarantee the need for two snaps.
However for the first approach, I’d encourage keeping everything singular until there’s reason not to. I can’t imagine many scenarios where a single publisher would need to split packages like that that wouldn’t be immediately obvious to its own developers.
Splitting into multiple snaps will essentially enforce the requirement for a content sharing interface, sockets, etc; that don’t necessarily benefit you practically in terms of security but will very quickly make your life harder since keeping one snap in lockstep with itself is trivial, but not when there’s several different snaps that might need to have a versioned API/protocol to communicate.
1 Like
