Show HN: Bootrino.com – Netboot Run-From-RAM OS's on AWS, Google and Digital Ocean

Hi folks - bootrino author here.

marketing website https://www.bootrino.com/

technical documentation https://doc.bootrino.com/

bootrino console https://console.bootrino.com/

bootrino is new and in beta so I'm keen to find people who'd like to give it a try and let me know if it doesn't work.

Today, bootrino is not for booting unikernels, but that was the original idea.

bootrino lets you netboot Run-From-RAM operating systems on cloud servers, but the origin of the project goes back a few years ago to when I became interested in unikernels, and how they might improve security by running only application code and minimal operating system code on a server. That seemed to make a great deal of sense to me. If it's not possible to log in to a server because there is no login system then surely that's got to be alot harder for hackers to get in. So I fiddled around with unikernels and after significant pain, got the rump kernel up and running on EC2 (for the first time).

And I thought, "wow that was way too hard". So I set out to build some sort of application that would make it easy to build unikernel cloud images that would run on all the common clouds. And along that path I discovered the crushing pain, inconsistency and sometimes impossibility of building machine images for the common cloud platforms. I targeted Amazon, Rackspace, Azure, Softlayer, Google and Digital Ocean. All cloud platforms do machine images differently, all cloud platforms make it hard and slow and painful, some make it impossible. So I sat back and scratched my beard and thought "wow, actually maybe it's not practical to build something that makes it easy to boot unikernels on all the common clouds".

I can't remember where the idea came from, probably just woke up with it one morning, but it struck me like lightning "hang on, I don't need to build machine images for all these cloud platforms". Instead of making a machine image for each cloud via its own unique process, I realised that every single cloud vendor boots almost precisely the same version of Ubuntu, and that they all support some sort of mechanism for providing a startup script to the instance. I connected this realisation to something I had read recently on Hacker News describing a way of replacing the operating system of a live machine with a new operating system https://news.ycombinator.com/item?id=13622301 and my head exploded with excitement. Instead of building and uploading machine images, just use Ubuntu as a bootloader, format the root disk and replace it with whatever operating system I wanted. A MUCH better approach - faster, more consistent and guaranteed to work across all the clouds.

So I did alot of technology testing and got it to work - eureka!

The next major shift in the project was that I found that the unikernel technology wasn't really able to run on the cloud machines, or more correctly, it was able to run on some cloud machines under some circumstances. And at the same time I learned alot about embedded systems, Yocto Linux, and Run-From-RAM operating systems like Tiny Core Linux and Alpine Linux. And I realised that in fact Linux can be trimmed down so light that it has many of the characteristics of a unikernel - of specific interest to me is that it is possible to cut Linux down to not much more than the kernel and the application code, which makes things very similar to unikernels. Run-From-RAM Linux is extremely small, fast and can be configured to be quite secure. And I found that it's a real pain to boot Run-From-RAM operating systems in the cloud. So the focus of bootrino shifted from unikernels to being more generalised - bootrino would be a simple way to boot Run-From-RAM operating systems in the cloud.

Another idea occurred to me which was that the Run-From-RAM operating systems are so small that it would be possible to put them on web servers and have bootrino fetch the OS code from any web server along with a shell script (bootrino.sh) which put a huge amount of control and power into the bootrino user. My idea was that ll they would need to do is load a shell script onto a web server, and bootrino could then launch a cloud instance, pull down the bootrino.sh and there you have it - netboot Run-From-RAM operating systems on the major cloud platforms.

Along the way I dropped Rackspace (I think it was defeated by AWS and stopped being developer friendly). I dropped SoftLayer (it's extremely locked down and does not allow you to reformat your disk any way you want). I also dropped Microsoft Azure (because it's API and ways of going about doing things were so annoying I gave up on it).

So anyway thats the back story. If you've got time and inclination to boot up a Run-From-RAM OS on your cloud then I'd really appreciate to hear from you how it went so I can fix bugs and clean up documentation. thanks! Andrew bootrino@gmail.com

Wow I was just doing research on this exact topic. I’ve been trying to boot Alpine into RAM from the network, and then run my lxd containers off the storage drives. So imagine my happiness when I see this.

So, the issue I see here is that the run-from-ram aspect of this limits the use cases for the product.

What happens if you want to make changes to files/apps, or are using it as a webserver in conjunction with an SSG and git/CI, etc.

Anytime you want to update you'd have to update some other code on some other http server (which in itself is fine), but then, you'd have to reboot your run-from-ram instance to sync up to your updates/changes (which is the not so great part, IMO).

Am I correct on this assumption, or could this type of scenario work some other way that would prevent an instance reboot? I could be way off here, and only skimmed the bullet points of the website, and that was my first thought/takeaway.

In any case, this seems to be a great way to essentially package live environments as a PaaS, with the added full code customization benefit. Really creative, and hats off to you for thinking of this and providing it for free. Seems there would be plenty of use cases and needs for something like this!

Why Chrome only? Any Safari support planned?

There are folks who know much more about rump than I. They read HN and I stand to be corrected. But the description of bootrino seems like it is has a misleading definition of rump unikernels. It suggests because a Linux distribution and a rump kernel can both be made small enough to fit in RAM and perhap focus on a single application, they are therefore similar. That does not sound right.

On rump:

"Two different operating modes are explored: 1) a transparent mode, in which the file system is mounted in the typical fashion by using the kernel code as a userspace server, and 2) a standalone mode, in which applications can use a kernel file system as a library. The first mode provides isolation from the trusted computing base and a secure way for mounting untrusted file systems on a monolithic kernel. The second mode is useful for file system utilities and applications, such as populating an image or viewing the contents without requiring host operating system kernel support. Additional uses for both modes include debugging, development and testing."

source: https://www.usenix.org/legacy/event/usenix09/tech/full_paper...

As far as I can see (which is not far), this is quite different from, e.g., a "trimmed down" Linux kernel plus busybox. For example, I can utilise rump to mount corrupted filesystems that would otherwise crash the kernel. Maybe I am missing something here about the comparison.

I applaud the bootrino authors work and struggle against the incompatibilities between "cloud" hosting providers. Time well spent.

However I have a few alternative thoughts:

If I have an image, in a portable format such as ffs, with a bootloader and a custom kernel with embedded filesystem that I created myself that is small enough to fit in RAM, why do I need to bother with "cloud" hosting?

Why do I need to have a hosting provider run Linux (or another OS of the providers choosing) in order to boot the image when the image has everything it needs to boot on a wide variety of hardware? Is the reason one that benefits me in all use cases?

Assuming for whatever reason I am amenable to have my kernels running on the same computer as other customers software, along with the providers software running as well, then do I at least get to choose the host OS (e.g., in Xen, the dom0)? Why not? Even if my kernels run better under an alternative host OS?

If I have a bootloader that is compatible, e.g., with Xen, and does not require, e.g., Python or Grub to be used, why do I have to accept the hosting providers choice of host OS and bootloader?

There is a severe absence of choice and flexibility compared to what I get outside of the "cloud" hosting market.

What with Spectre and Meltdown, are there good reasons for me to not share a computer with other customers software and the providers software? What if there are alternatives to "cloud" hosting that do not involve running other peoples software on the computer I am using? What if the real advantages of "cloud" hosting are to the hosting provider?

Cloud hosting may not be for everybody. Personally, I have created enough of these small images to run from RAM that I have lost count, using small sized USB sticks, SD cards and CF cards to store a. kernels with embedded ramdisks and b. other stuff I might need before network access. The amount of configuration I can do is limited only by my imagination, but none of it ever requires a cloud hosting provider or some web-based "administration console".

I prefer having physical access to dedicated hardware, or paying someone to access it for me. I am willing to pay more for this peace of mind, but as others on HN have highlighted repeatedly over the years, many times dedicated hardware is actually more economical. As always, it depends on what the customer is doing.

Using "cloud" hosting providers is overkill for own custom kernels, and way too much hassle. For example, I use ffs for the images and it "just works" on every computer. The fact that every hosting provider has to have their own "proprietary" image format is enough to keep me away. That is not user-friendly.

But, to each her own. This is only one users opinion.