Show HN: Slim – Build and run tiny VMs from Dockerfiles

https://github.com/ottomatica/slim

by chrisparnin • 7 years ago

389 139 7 years ago

github.com

tomglynch• 7 years ago

This has good potential, what are the limitations on the VM?

chrisparnin2• 7 years ago

Some limitations in terms of the vms and providers:

* If the size of the initrd is too large, it cannot properly unpack into vm's RAM --- size of RAM must be increased accordingly. We could also change [boot params](https://www.lightofdawn.org/blog/?viewDetailed=00128), or use shared disks, etc.

* For hyperkit, apple's vmnet requires sudo to create a bridge interface on host. We've played with a version that use's vpnkit and port forwarding (like linuxkit/Docker for Mac), but this adds lots of complexity in image, and opted for the simpler approach.

* We would like a better template mechanism for reusing base images and extending. Right now, we support using base image reuse, with extensions through docker buildargs---ideally, we would want something like %include support in Dockerfiles.

* Finally, we're investigating how to make images work well on multiple providers. For example, ubuntu does not play nice with hyperkit out-of-the-box, but works fine for vbox and kvm.

sansnomme• 7 years ago

What about swarm mode and orchestration? Also I presume like LinuxKit, there will be configs for different clouds e.g. Digital Ocean and AWS run ISOs slightly differently.

hardwaresofton4• 7 years ago

Recently on HN (I think) and related:

- https://micromind.me/en/posts/from-docker-container-to-boota...

- https://godarch.com/

Really like seeing these new usecases for containers -- would have never thought to mix the two technologies in this way.

juliangoldsmith• 7 years ago

Darch reminds me a bit of Tiny Core Linux. That uses loopback images for packages, and puts them together with UnionFS, IIRC.

Koshkin• 7 years ago

Well, containers and VMs are two different things (are they not?).

derimagia• 7 years ago

They are different, yes.

vkaku2• 7 years ago

Yes, but the cool thing is definitely the single system image

eeZah7Ux3• 7 years ago

They seem to do very little that SystemD cannot already do with services and overlayFS, with the added benefit of being already available on most systems.

hn232• 7 years ago

SystemD does not run on Windows which ist still being used in many companies..

pknopf3• 7 years ago

Author of Darch here, if anyone has any questions.

Here are my personal recipes: https://github.com/pauldotknopf/darch-recipes

oconnore• 7 years ago

I love that your website is “god arch[itecture].com”. Was that intentional?

mathnmusic• 7 years ago

Shameless plug about containers: We recently launched https://cloudcron.polyglot.network

Tell us a Docker image, a command with arguments to run and a cron schedule - and we will execute the task and send its STDOUT to your preferred endpoint (either an email or webhook). We're in beta and are offering 15$ worth of execution time as free trial and would really appreciate HNers giving it a try.

Our blog post has more details: http://polyglot.network/cloudcron

hedora• 7 years ago

I’d love to see an orchestrator that made switching between bare metal, vm and containers a simple configuration option.

This is a step in that direction. Cool stuff!

_frkl• 7 years ago

Yes, I want the same thing. I do hope dockerfiles won't be the underlying configuration files to describe the machine setups though...

pushpop2• 7 years ago

Proxmox did a pretty good job of that in my opinion. Albeit it was more inspired by vSphere than Docker (it predates Docker).

pcnix2• 7 years ago

There's this[1], though not exactly what you asked for.

[1] https://github.com/firecracker-microvm/firecracker-container...

shaklee3• 7 years ago

Kubevirt will deploy vms on kubernetes. No bare metal option though.

peterwwillis2• 7 years ago

If this works, this is fantastic. Getting away from the stupidly complex abstractions around Docker is a welcome change, especially if we can still package and deploy immutable images. We already manage containers like tiny VMs, so ditching the abstractions should simplify life a bit.

tssva• 7 years ago

Have you looked at LXD/LXC? I find it to be a great compromise between the high overhead of VMs and the complex abstractions around Docker.

peterwwillis2• 7 years ago

Yes, it's still just more abstractions. If you look at the way people use ECS, allocating specific resource limits to each container, it's basically a micro EC2 node. And for me, the only reason I use containers is to make it easier to package and run applications immutably. If I can do that without "containerisms", all the better. It also seems like VMs would solve a good deal of multi-tenancy issues.

eeZah7Ux3• 7 years ago

SystemD does that.

seabrookmx2• 7 years ago

stupidly complex abstractions

Not sure what you mean.. could you give some examples?

In my experience, people prefer Docker over VM's because they _like_ the abstractions and tooling associated with it. It's a lot friendlier to developers and makes immutable infrastructure a much more realistic goal for ops folks, IMO.

IloveHN84• 7 years ago

Why JavaScript instead of something more performant?

oblio2• 7 years ago

What for? It's just glue code, it doesn't actually run the micro-VMs.

mfatica2• 7 years ago

Because I don't want to have to install the massive nodejs runtime just to glue things together.

pjc50• 7 years ago

Normally the language for doing this kind of system building would be .. Bourne shell. Or Perl/Python.

GordonS2• 7 years ago

I was actually expecting Bash scripts before I looked at the GitHub repo.

TBH, I think the code would be a lot simpler if it was just Bash.

Hortinstein• 7 years ago

this is great! This might have saved me some time I was planning on spending to learn packer. I have a docker based project and I wanted to add VM generation to the CI pipeline.

Really excited to play with this tonight

gravypod• 7 years ago

Would be really cool to use this to predictably build images for booting from PXE.

wmf• 7 years ago

Try LinuxKit.

AlphaSite• 7 years ago

On the same vain, there is: https://github.com/vmware/vic a docker engine for esx/vsphere.

Note work at VMware but not on this project.

vkaku2• 7 years ago

This is great! I really wish we'd always create a single system image for both Docker and Physical/VM, preferably with minimal/no-init.

This is very useful when trying to create a basic datacenter specific distro/deployment, preferably Pixie bootable as well.

saurabhnanda• 7 years ago

Can someone dumb this down for me? What _exactly_ is going on here?

slim will build a micro-vm from a Dockerfile. Slim works by building and extracting a rootfs from a Dockerfile, and then merging that filesystem with a small minimal kernel that runs in RAM.
This results in a real VM that can boot instantly, while using very limited resources. If done properly, slim can allow you to design and build immutable unikernels for running services, or build tiny and embedded development environments.

dharmab3• 7 years ago

Docker images contain a filesystem for an operating system, minus the OS kernel. This project uses Docker to build a tiny OS, extracts all the files out of the Docker image, adds a small OS kernel and re-packages that as a VM image.

RyanShook• 7 years ago

So why was Docker needed to create a lightweight VM? I thought Docker was supposed to replace VMs.

fenollp• 7 years ago

Maybe going a bit off tangent here but really let's all agree that Dockerfile.s are just not good enough for building any kind of software through time. There's no lockfile system and caching is just awkward to work with.

Dockerfile.s must be progressively replaced with Nix recipes then we'd get lockfiles, upgradable dependencies, some day even reproducible builds!

sitkack• 7 years ago

Project Nix recipes into Dockerfiles, use the nix hash in the dockerfile name.

nerd7473• 7 years ago

A neat idea

idlewords• 7 years ago

Stuff used to boot off of a floppy disk!

shereadsthenews2• 7 years ago

Used to have self-replicating persistent malware hidden inside filed that fit on floppy disks.

yjftsjthsd-h3• 7 years ago

And now we have compromised NPM packages and Dockerhub accounts. What's your point?

yjftsjthsd-h3• 7 years ago

Pretty sure you still can, if you throw out all the drivers and libraries we've invented since then. Like, we waste lots of space, but a lot of it really is going to useful features.

quickthrower22• 7 years ago

And it took ages. What’s your point?

ph0rque2• 7 years ago

Does this allow for a docker image to be run inside a browser tab?

pas3• 7 years ago

Naturally. With this and a bit of hacking: https://bellard.org/jslinux/

ph0rque2• 7 years ago

Forgive my lack of technical depth, but is it actually running client-side, in the memory allocated to my newly-opened browser tab, or on bellard.org's server and syncing the input/output to my browser?

smattiso• 7 years ago

What would it take to get this running on iOS and Android?

seabrookmx2• 7 years ago

You'd never be able to run this on iOS. It's far too locked down.

You might be able to add QEMU support to this, and then run it on an Android device if you have root. But it would perform terribly because mobile chips generally don't have virtualization extensions and ARM as a virtualization host is a pretty immature platform.

TL;DR - far too much to be practical.

buildbuildbuild2• 7 years ago

I’m curious how this approach compares with Kata Containers. Very cool.

lwb• 7 years ago

Wait a minute. I thought Docker was useful because you didn't want to run a whole VM. But this project turns a Dockerfile into a VM specification? Have we come full circle?

gjmacd• 7 years ago

I was also thinking the same thing. I also think that the prior person wanting to SSH into their docker instance hasn't quite grasped that you can already do that.

I'm not sure what the value of this is.

pknopf3• 7 years ago

The "building" feature of Docker is very much applicable to VMs/bare metal. There spirit of this feature is just "building a root fs". There is no concept of "containers" or "vms".

turtlebits• 7 years ago

Well, containers generally run headless applications/servers. I can see this for VM sandboxed GUI apps.

zarmin• 7 years ago

You should check out that Docker project where you take most of the files from a Docker VM and spin up a Docker container. It's called Docker.

root_axis2• 7 years ago

Docker can replace a VM for many use-cases, but there are times when a VM is still preferable. If you find yourself in such a situation, this tool allows you to leverage declerative Dockerfiles to build your VM. Pretty handy.

freedomben2• 7 years ago

Yep, I could see this being a nice option if you're running something very security sensitive and want some extra defense by isolating the kernel.

robbomacrae• 7 years ago

Thank you!! I always wanted to have a way of quickly ssh'ing into my docker image with some sort of virtual box implementation so I could poke around. I always felt the debug tools lacking. This is perfect. Can't wait to try it out!

nine_k• 7 years ago

Here comes!

Getting shell in a new copy of container:

docker run -it --entrypoint=/bin/sh ${container}

Running shell inside a running container:

docker exec -it ${container} /bin/sh

Running sshd inside a container to let you peek inside is bad taste, and bad security, too.

pard68• 7 years ago

Can slim be used to create an iso? So:

Dockerfile > slim > iso

PhilippGille• 7 years ago

From the GitHub README:

`$ slim build images/alpine3.8-simple`
This will add a bootable iso in the slim registry.

dastx• 7 years ago

Why does everything in node have to have all the dependencies in the world?

``` @sindresorhus/is JSONStream ansi-regex ansi-styles archive-type argparse asn1 async balanced-match base64-js bcrypt-pbkdf bl bluebird brace-expansion buffer buffer-alloc buffer-alloc-unsafe buffer-crc32 buffer-fill buffer-from cacheable-request camelcase caw chalk chownr cliui clone-response color-convert color-name commander concat-map concat-stream config-chain content-disposition core-util-is cross-spawn debug decamelize decode-uri-component decompress decompress-response decompress-tar decompress-tarbz2 decompress-targz decompress-unzip docker-modem dockerode download duplexer3 emoji-regex end-of-stream escape-string-regexp esprima execa ext-list ext-name fd-slicer file-type filename-reserved-regex filenamify find-up from2 fs-constants fs-extra fs-minipass fs.realpath get-caller-file get-proxy get-stream glob got graceful-fs graceful-readlink has-flag has-symbol-support-x has-to-string-tag-x hasbin http-cache-semantics ieee754 inflight inherits ini into-stream invert-kv ip is-fullwidth-code-point is-natural-number is-object is-plain-obj is-port-available is-retry-allowed is-stream isarray isexe isurl js-yaml json-buffer jsonfile jsonparse keyv lcid locate-path lodash lowercase-keys make-dir map-age-cleaner md5-file mem mime-db mimic-fn mimic-response minimatch minimist minipass minizlib mkdirp ms mustache nice-try node-virtualbox normalize-url npm-conf npm-run-path object-assign once os-locale p-cancelable p-defer p-event p-finally p-is-promise p-limit p-locate p-timeout p-try path-exists path-is-absolute path-key pend pify pinkie pinkie-promise prepend-http process-nextick-args progress proto-list pump query-string readable-stream require-directory require-main-filename responselike safe-buffer safer-buffer scp2 seek-bzip semver set-blocking shebang-command shebang-regex signal-exit simple-git sort-keys sort-keys-length split-ca sprintf-js ssh2 ssh2-streams streamsearch strict-uri-encode string-width string_decoder strip-ansi strip-dirs strip-eof strip-outer sudo-prompt supports-color tar tar-fs tar-stream through timed-out to-buffer trim-repeated tunnel-agent tweetnacl typedarray unbzip2-stream universalify url-parse-lax url-to-options util-deprecate uuid which which-module wrap-ansi wrappy xtend y18n yallist yargs yargs-parser yauzl ```

montecarl• 7 years ago

This is what you get when you combine a really easy to use package management ecosystem and the standard library is really bad. You don't see this in Python for example, because its not so easy (its getting better though) to create packages and because its standard library is massive.

krapp• 7 years ago

Javascript's standard library isn't bad, it's perfectly adequate for its intended use case - acting as a lightweight scripting language for the web, within a browser. Javascript as a system or backend language was a mistake, but there's no putting that genie back into the bottle.

ManuelKiessling• 7 years ago

Yesterday a friend of mine told me about how they got a Node.js application from a vendor that was about 3 MiB, and after running npm install, it was over 1 GiB.

I half-jokingly said that Node apps are the new ZIP bombs.

hn232• 7 years ago

good luck to your friend with repeatable installations :P

xienze• 7 years ago

Isn’t that because every Node dependency stores its own dependencies within itself? So you could literally end up with multiple copies of the exact same version of the same library.

I’ve never understood why they didn’t go with the Maven approach: all dependencies stored in a central location, separated by version.

stcredzero2• 7 years ago

Back in the late 90's, I got into a USENET flame war, because the smallest, easily pruned ObjectStudio executable was an entire 4MB. Not small enough. Someone around that time got Squeak Smalltalk down to around 380KB. Not small enough. Back in the late 90's, you could still meet people who would insist that even your hyper-complex business app should be written entirely in C, because anything else was sinfully slow and wasteful. Any language with a VM was automatically too slow to be useful at all.

root_axis2• 7 years ago

Is it really that strange? The transitive dependency graph for my iOS and Android apps are similarly complex.

ricardobeat2• 7 years ago

These are the first-level dependencies:

    chalk: log formatting
    dockerode: docker API
    download: file download?
    fs-extra: functions like mkdirp, emptyDir
    hasbin: check if bin exists in PATH
    js-yaml": yaml parser
    mustache: templating
    node-virtualbox: VB API
    progress: terminal progress bar
    simple-git: Git API
    sudo-prompt
    tar
    uuid

It looks reasonable at first sight. Of all these, fs-extra is the only one you can argue should be part of the standard lib.

A lot of the other dependencies are simply cruft, for example, `safe-buffer, `safer-buffer`, `buffer-alloc`, `buffer-alloc-unsafe` all patch the same issue and haven't been necessary since ~2016 / node 6.0. Same for `sort-keys`, object key sort order was baked into the ES2015 spec and has been the default behaviour since the beginning of the decade.

As mentioned by other commenters, this is a result of an extremely easy-to-use packaging system, coupled with a culture of sharing and reusability. The dark side of it is (justified) laziness and reinvention of the wheel - the core functionality of many of these modules can be written in one or two lines of code, but it is indeed faster and safer to just import something that exists and has been tested. The vast number of choices means it's hard to find standard solutions, and this also encourages developers to create their own 'improved' version of everything, in a self-reinforcing loop. The language itself has been in constant change, meaning new flavours of previously stable modules pop up to support new patterns (promises, generators, await, classes, etc etc). Then you get egos, marketing and corporate sponsorship added to the mix :)

tylerl2• 7 years ago

This is exactly why we don't allow our employees to use Node.js for company software development, even though in theory a fair chunk of the runtime is our own software that we maintain. But the npm ecosystem has a really awful signal-to-dogturd ratio, and developers appear to put very little effort into critically analyzing their dependencies.

The topic has come up, but I'm generally against it; sure, we could spend all the resources on doing all the filtering and analysis and change management that it would take to establish a sane package base that we could officially support for internal development work... But why? We do it for other languages, but Node has a lot of "my first programming language" bs going on in the ecosystem. I strongly suspect that allowing Node development would be a net negative for our company.

sealthedeal• 7 years ago

What would an ideal re-world scenario look like for using these micro vms?

pcnix2• 7 years ago

Docker containers don't have a robust security boundary, due to the kernel sharing that they do. These micro VMs combine the low resource cost of a container with the solid security boundary of a VM, which is very useful in a multi tenant architecture.

AWS Fargate and AWS Lambda run entirely on micro VMs.

JustSomeNobody2• 7 years ago

Are we just going in circles now?

Why not just start with a tiny vm and call it a day?

yjftsjthsd-h3• 7 years ago

Tooling matters. Building and managing VMs has, historically, been more work.

eeZah7Ux3• 7 years ago

Debootstrap has been doing the work with pretty much one command for 10+ years.

40four• 7 years ago

This sounds interesting, I want to look into it further. However, my immediate thought is what about the naming conflict with the very popular PHP framework?

http://www.slimframework.com/

ajsharp• 7 years ago

This is cool. For dev, the docker runtime consumes an enormous amount of host system resources. Even with a 16gb RAM host machine, docker is really resource heavy for a development environment. If this can cut down on host system resource usage, that's a major win.

kristianp• 7 years ago

Are you on a non linux host? I assume docker is a lot less heavy on resources on linux than on mac&win.

freedomben2• 7 years ago

they have to be. Docker is extremely light weight on a linux host.

dlespiau• 7 years ago

Yet another different take: footloose – Containers that look like Virtual Machines!

https://github.com/weaveworks/footloose

(Disclamer: I'm the author of footloose)

Show HN: Slim – Build and run tiny VMs from Dockerfiles

Related Stories