Відео

This video deals with unikernels not containers but if you need help with unikernels you can reach out to the folks at nanovms.com .

Good question and it's something *everyone* has trouble grokking until they push their unikernels to the cloud for the first time. Essentially kubernetes exist because you need something to deal with networking and storage and things of that nature. However, unikernels are virtual machines at the end of the day, albeit just specialized ones, and so they get to re-use all the existing primitives that every single cloud providers has. That is - while you configure your unikernel to your hearts content you don't actually manage the networking and storage and such of it. The clouds do. So to scale you spin up as many instances you need or want and if you're unsure and want to use something like auto-scaling-groups that just works out of the box.

No. Quite a few companies/organizations are explicitly building for wasm on the server-side, in particular in the 'function-as-a-service' space there is quite a lot of attention to using wasm in this manner.

You don't need to know c nor kernel fundamentals in order to use unikernels. The only reason you might wish to know that is if you want to develop in nanos.org itself. If you just want to use unikernels check out ops.city && github.com/nanovms/ops-examples for your favorite language. If you are interested in developing kernels itself we'd recommend "Operating Systems: Three Easy Pieces" by the Arpaci-Dusseaus.

This video show-cases shipping nanos logs to AWS cloudwatch but there is no reason why you couldn't hook up something on your app to consume from cloudwatch and then pipe it back out via a websocket. You should be aware that browsers don't allow you to send raw UDP because of security reasons.

@@nanovms7360 That’s right yeah, through tcp. That was the original plan, was just curious about other options

We'd suggest two ways: 1) Try running your program via 'ops run' or 'ops pkg load' first. If that works then you can create a pkg from 'ops pkg from-run' or 'ops pkg from-pkg'. 2) You can try 'ops pkg from-docker' which will import docker containers as pkgs.

This particular feature was made mainly for dev workflows. Depending on where you are deploying you can potentially use it in a prod setting (eg: aws metal instances) but most users will use a combination of instance groups and cloud init instead: docs.ops.city/ops/klibs#cloud-init-http-s-to-file-env-klib .

@@nanovms7360 want to do it on aws...also if I am picking same instance size as I normally would with a linux VM to host bunch of containers etc(say m4.xlarge)..what cost savings are unikernels giving me especially when each unikernel will be a separate ec2 instance?

​@@kk-pi4hj There might be some misunderstanding. Plenty of people have been deploying to prod AWS for a while now. An ec2 small can go quite a long ways for many apps as well. This particular feature, the compose functionality, was written for a dev workflow, not a prod one. If you wanted to you could use a metal instance to use this workflow though and then all of the unikernels would live on that instance like you do with containers now. There are trade-offs though. In the typical deploy workflow of 'image create', and 'instance create' you don't have to manage storage, networking, etc. whereas with the metal/compose workflow you would.

So Nanos runs great on Xen and that was either the first or second hypervisor we supported. While we aren't explicitly targeting general-purpose desktop os applications you could certainly create something like Qubes using Nanos. Our focus today is more based on server-side daemonized applications.

It depends on what image you are creating. For something like a go/rust binary that is only 20mb yes you can create vms that large but if you hand us a 5gb jar file we aren't doing any magic tricks - it'll still be the size of your application.

Definitley positive.

added a new version - happy to look at other versions too repo.ops.city/v2/packages/eyberg/node/v20.0.0/x86_64/show (I think ops from-docker does a good import as well)

No. Forking is explicitly disallowed and is a core architecture constraint all unikernels share on purpose. Nanos does support mulit-threading so your application can use as many threads as the underlying platform exposes. For scripting languages such as javascript, ruby, python, etc. that don't support multi-threading you scale up much the same way as you do now by spinning up N instances that support your load.

@@nanovms7360 understood. thank you

What kind of proxy are you trying to create? A reverse proxy or ? Did you have a particular piece of software you were wanting to use?

Thought this was unlisted. ;) Anyways I think we are shooting for May 24th - stay tuned to platformengineering.org/ .

Yes. Although, it is common to have many rake tasks and other scripts that shell out repeatedly in rails envs so might not be appropriate for dev work but could be an excellent pair for prod deploys.

@@nanovms7360 That's really cool! I could not find any guidance online about how you would go about running a large monolith with nanos :/

I don't think you should be getting this error but can you open a github issue at github.com/nanovms/ops please?

well, because it's really really really fast :|