Many Nanos/OPS users come from a docker background and there is a hidden implication that they might be working on a Mac for dev purposes. This can pose a problem for those that want to create their own software on a mac to run as a Nanos unikernel as Nanos consumes ELF binaries just like Linux does. It also prevents users from running software that might not have an ops package created for it already.
This is actually the same problem that Docker itself has as Docker inherently uses Linux to do it's work - on a Mac that means it runs inside of a virtual machine. For most use-cases many users will simply pick a pre-made package from the ops package repo and they are off to the races:
ops pkg listTry Building By Hand
However, what if the package you want isn't in the official repo? You could try your hand at making a package but this typically involves needing to work on a Linux system as you'll need to find all the different libraries that your application is linked to and put them in their respective places. Again this is easy on Linux but not so straight-forward on a mac as you'll need to crossbuild. Some languages make this super easy and others - not so much. It doesn't stop there though, even if you have a language that cross-builds easily there are typically other files that need to be on your fs to make things like dns work.
Why is This Necessary?
First, it should be noted that nanos is not Linux. It exports a portion of the syscall interface that Linux uses so that we can run ordinary Linux programs without having to re-compile or re-link or do other things that would prevent a user from just running 3rd party software such as redis or mysql or nginx. Some people have likened Nanos to small Linux distros such as an Alpine with a heavy handed seccomp profile but that is not the case. Alpine, still being Linux underneath has the same sort of limitations and weaknesses that Nanos wishes to address.
However, there are some major differences between Linux and Nanos, that are conciously chosen so that Nanos can run server-side workloads faster and safer than Linux - so much that a simple fork or ifdef patch can't deal with. Multiple process support, for instance touches everything from the scheduler to permissions to IPC - you can't just provide a patch for things like that. The vast majority of server-side operating systems were simply not built for public cloud workloads and predate not just public cloud but commercialized virtualization in general. Nanos is one call to action to remedy that. If you want to look at the code it's open source.
Second, macs use a different object format that practically no one uses to deploy to servers as most servers are running Linux. Yes, macs are popular for development but it does complicate development even without containers or unikernels and the new ARM based ones exacerbate that - that is until we see ARM based servers come into vogue.
Throwing Up Your Hands
Needless to say - this is the part that most users will throw their hand up and say screw it. Also, what if you don't want to make your own package? What if you want to use one of the 100,000 images available on Docker Hub or another registry? That's where this new feature comes into play.
Ops can now consume a package directly from a docker image and if you don't have that image it will download it first. It then creates a new ops pkg by copying over the program in question and it's linked libraries. The package itself is simply a tarball of a filesystem with some configuration attached. It isn't until you run the program that the filesystem is built on-demand, a disk image is produced, and your application is running as a unikernel. We can demonstrate how easy this with the following command:
console.log("hi from Nanos!");ops pkg from-docker node:16.3.0 -f node
ops pkg load -l node-16.3.0 -a a.js
This entire process doesn't take almost anytime - really just the time it takes to download the image. There is certainly more work to make this experience better but we're happy there is now an easy way for those used to working with containers to immediately try deploying their software as Nanos unikernels. This should also help automate a lot of existing pipelines for easier adoption.
