Linux container support

[geloizi]

Is there an possibility to run "full linux" in nabla container? I found this image: https://hub.docker.com/r/nablact/ubuntu/ but it doesn't start.

[lumjjb]

No worries, this is a very valid and interesting issue to discuss. Which takes into account various aspects, including trade-offs of security (i.e. potentially exposing more interfaces to support more), the direction of the community (i.e. development of other solo5 unikernels based on different interfaces - LKL, mirage, etc.), as well as the use case of generality (i.e. fork vs event loop).

In terms of direct linux specific support. There are several approaches can think about: adding a compatibility layer between rump and the linux interface, or just running LKL directly on top of solo5. @djwillia and @ricarkol probably can shed more light on the developments in this area.

Currently, we maintain a list of known limitations that we've listed which we are tackling: https://github.com/nabla-containers/runnc#limitations

BTW, do you have plans to start a mailing list?

That is a good suggestion, we will discuss this and decide what we should use. Slack is a potential candidate too!

Is there an possibility to run "full linux" in nabla container? I found this image: https://hub.docker.com/r/nablact/ubuntu/ but it doesn't start.

That's probably a debugging container we used. : ). Sorry if it caused any confusion.

[retrage]

I ported Linux Kernel Library (LKL) and musl libc to Solo5, and I also adapted Nabla Containers to it.
https://github.com/retrage/frankenlibc/tree/solo5
https://github.com/retrage/runnc/tree/lkl-musl
It may be too early to send a pull request, but it already runs applications such as Python. Here is the log:

If anyone interested in this work, I would like to provide an introduction and container images.

[lumjjb]

This is really cool! Would love to hear more about this! :D

[retrage]

I wrote a short introduction to LKL Nabla Containers.

• Porting Linux to Nabla Containers.

I also provided LKL-Nabla version of nabla-containers/nabla-base-build:

• https://github.com/retrage/lkl-nabla-base-build

[lumjjb]

Awesome! This looks great and nice blog post!

Yea about having it specify a rootfs, that's current limitation of container runtime stack afaik since it unpacks into a rootfs as the interfacing point by default. Network has some external operations on it that vary depending on whether running k8s or docker as well... (and i'd assume podman would be different too). Hope that doesn't affect it too much.

Looking forward to getting some time to dive a bit deeper the libc patches!

[ricarkol]

Hi @retrage, sorry for replying so late. Would you mind sharing more details about the rump integration part (the frankenlibc port) please? some summary of the the approach would be great as the patch is quite large. Or maybe, if you have, some info about ukcontainer would be great as well please. Thank you very much!

[retrage]

I am writing a blog post about the design and implementation of Solo5 port for frankenlibc. I would like to publish it within a week. Unfortunately, I can not provide details about uKontainer. It is another approach for LKL based container runtime. Both OCI runtime uses the same frankenlibc code base, however, it is not related to LKL Nabla.

[retrage]

I published a post.

• Linux Kernel Library Nabla Containers Internals

As I noted in the conclusion, it would be better to have an option to switch modes between Rumprun and LKL on runnc.

[q2dg]

Last commit was from one year ago.
I don't think this effort is worthy...

[retrage]

@q2dg Even it is not actively developed, it is still useful for unikernels. What's more, this is my side project for fun.

[lumjjb]

Yea I think the work you've done is great and brings up more interesting questions and exploratory options to work with LKL. :). Having libc bindings for LKL and being able to run arbitrary linux binaries on top a small syscall surface is valuable. All in good science!

There have been a few challenges with unikernels in the container world, one of it is the general mindset of what unikernels are for - specialization. And the fact that containers want to be generic. This is a point in time statement though, since industry has a tendency to move in cycles.