Cross compiling Linux containers for embedded devices

dockerembedded-systemslinuxmicroservices

I have recently been exposed to Docker and found it to be an excellent tool for making production deployments very less risky that what I was used to (coming from an embedded world, embedded as "Linux ported on custom arm PCB-s with complete system images cross-build").

However, I've soon experienced that building Docker images is somewhat of a "execute runtime steps" process instead of building in terms one does a rootfs using Yocto. This was a show stopper because it prevents cross compilation. Also, there is no notion of a sysroot on the host machine in that approach.

I've seen a cloud service offering options to build Docker images for Arm but don't feel comfortable with the idea given that again the sysroot is missing and it starts feeling like a hacky workaround… in addition what if you switch to a different processor platform, one for which you have to cross-compile…

So I was wondering, this risk free production update is a wonderful thing, there is surely someone who thought about that already, there all these smart boxes and routers that need to be updated remotely, surely they have some sort of a "supervisor with containers" architecture to prevent the system to die in case of a power failure or a critical application bug, but the furthest I got was a small lwm article just flirting with that idea.

UPDATE:
Found a new reference to something that seems to aim in that direction.

I would like to hear about the approaches you have seen so far addressing this problem and which technologies?

Did you use a failsafe bootloader that would wait for a complete new image (kernel and rootfs) in case something went wrong?

Any notion of building userspace containers with build systems?

Best Answer

I remember NOOBS for the raspberry pi, but that needs user interaction.

I'm new to the embed world, not so for Linux, but all the container/docker/x is a pretty recent stack so maybe it hasn't reached the embed world yet. :)

The systemd approach to containers is really neat, you can make really packed sysroot containers (dnf = fedora, debootstrap = debian) and supervise them with systemd pretty neat. For instance: 

 mkdir /tmp/myimage 
 dnf --releasever=23 --installroot=/tmp/myimage install <package-name>
 rm -rf /tmp/myimage/var/cache/dnf
 # tar zcvf - /tmp/myimage | docker import - myimage ?

Gives you an image that is ~30M (15M compressed) plus the size of whatever package you are installing.

In case kernel failure, normal world would use kvm to test for it. I'm not aware of any systemd feature for kernel testing (I'm not a systemd expert ) but definitely there are some boot hooks for the kernel.

For example:

You could boot with systemd.unit=emergency.target, and tailor the emergency.target to do your stuff without "problem" I image that you could do "anything" there, like revert the kernel ... but you know you're in a broken system shell so maybe it doesn't turn out that easy... ;)

So I'd bet for the systemd approach if possible.

Are you using yocto? If yes then could you explain why?

Cheers and best luck. ;)

Related Topic