Hacker News Reader

Comment by saurabhnanda | Hacker News Reader

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.

View on HN

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.

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

I assume it's mostly to make it easier for people to test this out with existing stuff. Docker containers are the standard for taking a base image and adding stuff on top of it.

It's a VM for Docker, not a VM using Docker.

I think it's a VM made using the Docker ecosystem (file system segregation, siloing of other dependencies to the container, etc)

If you have a Docker creation script (that many people distribute), you use this tool to turn it into a disk image you can run in a VM.

Working with VM images was PITA, I don't know if anything changed. Having recipe (Dockerfile) and required files in VCS is useful as reference even when setting up bare metal machines. So Docker (and Puppet/Ansible) might have bigger impact on work organisation than on anything else.

It's not such a PITA anymore. Most distros have automated build systems to create VM images from a config file. For example, we use FAI + Ansible to entirely automate the creation of a Debian AMIs for AWS, deployment, and provisioning.

You still have the Dockerfile and the required files in a VCS, but now what you have running is a full VM instead of a somewhat isolated process sharing kernel with other containers.

So far so good, for individual/standalone containers. But if you need thightly integrated containers (sharing networks, volumes, ports and so on) things may be a bit more complicated. And not sure about Kubernetes. YMMV

Docker containers do not yet offer the same security or “bring your own kernel” flexibility of full VMs, such as access to a CPU’s VT-x features.

You think they will, one day?

You can tighten containers but at the end of the day they are running as native processes on the same kernel. Any vulnerability and game is over. VM offers an easier (maybe heavy) mental model of security. Between guests and between guest and host.

A jail breakout, it being from a process namespace or a VM, is always a security-risk - whatever it's breaking out of. Both are sensitive to this. VM's are maybe a bit more mature and handle some stuff on hardware - but given the recent Intel oops thingies - I wouldn't rely on that too much...

"Containers are less secure" is just FUD. That VM's or containers alike are running on the same CPU is currently a much more real threat.

Docker- probably not. Other runtimes like Kata and Firecracker? Probably.

The docker daemon itself - sure, but on OS/kernel level, they're doing exactly the same thing, where docker is probably the more scrutinized implementation out-there...

Docker is not intended to replace VMs. It provides lightweight isolation for processes within a host but shares a kernel between processes, and some handy tooling for building images that works well with version control. (Building a CentOS based image is under a dozen LOC in Docker, and a few hundred LOC in Packer+Kickstart.)

Kata Containers (https://katacontainers.io) is more along the lines of a "VM replacement", although it is doing so using VMs.

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!

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

Reply on news.ycombinator.com