Docker has a big community, lots of guides, and ready-to-use containers. It became pretty much a de facto standard for self-hosting things. You also have a very high chance of getting a piece of software to work out of the box as intended with Doker. The only way this or some other way of running stuff will overtake Doker is if it will match the Docker in these aspects. As much as I'd love to try this lightweight VM…
Maybe try out kraft.cloud: we take Dockerfiles as input and automatically convert to lightweight VMs/unikernels when deploying (disclaimer: I'm one of the paper's authors and one of the people behind KraftCloud).
My VM is lighter (and safer) than your container (2017)
121–130 of 184 posts
Re: My VM is lighter (and safer) than your container (2017)
#122Earlier quoted context omitted.
I tell people "An OCI container is a way to turn any random runtime into a statically linked binary." It is very useful for managing dependency hell, or at least moving it into "API dependencies" not "Library dependencies", it is handy for pickling a CI/CD release engineering infrastructure. It's not a security boundary. (I'm 100% agreeing with parent, in case I sound contentious)
> It's not a security boundary. It is a security boundary, just not necessarily the best one.
Re: My VM is lighter (and safer) than your container (2017)
#123OS: I provide isolation where needed, handle safely interacting with outside world, and abstract away all the pesky stuff so programmers can just get stuff done. Container / VM: I provide isolation where needed, handle safely interacting with outside world, and abstract away all the pesky stuff so programmers can just get stuff done. I get that a dev machine (OS) isn't usually suitable for deployment or shared develo…
Linux tried to fix that with namespaces and it turned out to be more or less successful, but Linux is not an OS, it's just a kernel, and it's up to real OSs built atop Linux to use namespaces as an implementation detail for real application isolation.
One way to do that is OCI-containers, the other way is Flatpak. Neither of those is not a proper OS yet, but you could call Kubernetes an operating system which uses containers as means for application and resource isolation. Naturally that means Kubernetes is a complex beast, but that's what it takes to provide what users expect from an OS.
Android also comes to mind, they managed to isolate applications between each other quite safely.
Re: My VM is lighter (and safer) than your container (2017)
#124Earlier quoted context omitted.
And these overheads are even smaller if you use unikernels as per the paper. Eg, cold starts of a few milliseconds depending on the app/size of the image.
I'm struggling a little bit to grasp all the concepts when we start talking about unikernels, wasm and so on. Hopefully that's just a sign of the maturity of it, and not a sign of my mental decline. But on paper (as I understand it) it looks /so cool/.
First off, a unikernel is a virtual machine, albeit a pretty specialized one. They're are often based on modular operating systems (e.g., Unikraft), in order to be able to easily pick the OS modules needed for each application, at compile time. You can think of it as a VM that has a say NGINX-specific distro, all the way down to the OS kernel modules.
VMs provide what's called hardware-level isolation, running on top of a hypervisor like KVM, Xen or Hyper-V. Wasm runs higher up the stack, in user-space, and provides what's called language-level isolation (i.e., you could even create a wasm unikernel, that is, a specialized VM that inside runs wasm (eg, see https://docs.kraft.cloud/guides/wazero/). Generally speaking, the higher you go up the stack, the more code you're running and the higher the chances of a vulnerability.
Re: My VM is lighter (and safer) than your container (2017)
#125OS: I provide isolation where needed, handle safely interacting with outside world, and abstract away all the pesky stuff so programmers can just get stuff done. Container / VM: I provide isolation where needed, handle safely interacting with outside world, and abstract away all the pesky stuff so programmers can just get stuff done. I get that a dev machine (OS) isn't usually suitable for deployment or shared develo…
Re: My VM is lighter (and safer) than your container (2017)
#126From 2017, before rootless containers caught on I think. The conclusions on safety might be due for re-evaluating.
Why weren't containers rootless from the start anyway? What did they need that user space doesn't provide? Wine, emulators and VMs didn't require it either (with the exception of some VMs needing a kernel module for performance reasons like memory management, which I also find stupid, the OS should provide all the performance in user space).
Re: My VM is lighter (and safer) than your container (2017)
#127Earlier quoted context omitted.
Containers are perfect for build environments and for creating the root filesystem. The issue is that the kernel these days are super bulky and are intended for multi-user, multi-process environments. Running a container runtime on top just makes it worse when you're looking for "isolation". This paper argues that when you build a extremely minimal kernel (i.e. ditch Linux entirely) and link your application against…
I am looking at the examples. They all have a Docker file. If that just for local development on my laptop? Using the deploy command line tool is the Docker file used to determine dependencies for the hosted VM? What if a developer is using an unusual programming language, like Common Lisp. Is that doable?
Re: My VM is lighter (and safer) than your container (2017)
#128From 2017, before rootless containers caught on I think. The conclusions on safety might be due for re-evaluating.
I don't really see how rootless containers change anything at all. You're still "just" one kernel privilege escalation away from breaking out. The level of isolation is much better in virtual machines, and the performance penalty is comparable these days. The virtual machine images are a bit heavier, since you need a kernel and whatnot, but it's negligible at best. The memory footprint of virtual machines with memory…
There are also significant operational concerns. With containers you can just have your CI/CD system spit out a new signed image every N days and do fairly seamless A/B rollouts. With VMs that's a lot harder. You may be able to emulate some of this by building some sort of static microvm, but there's a LOT of complexity you'll need to handle (e.g. networking config, OS updates, debugging access) that is going to be some combination of flaky and hard to manage.
I by no means disagree with the security points but people are overstating the case for replacing containers with VMs in these replies.
Re: My VM is lighter (and safer) than your container (2017)
#129I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.
The isolation could be achieved using namespaces directly. But the API, tooling and registry add a lot of value that would otherwise require a lot of development.
Also last time I looked hypervisors aren't possible on all cloud vendors, unless you have a bare metal server. This matters in my case. Maybe it has changed in the past 3 years.
When docker fits it's great. Same can be said of k8s, where there are a whole bunch of additional benefits.
Swings and roundabouts.
Re: My VM is lighter (and safer) than your container (2017)
#130Docker has a big community, lots of guides, and ready-to-use containers. It became pretty much a de facto standard for self-hosting things. You also have a very high chance of getting a piece of software to work out of the box as intended with Doker. The only way this or some other way of running stuff will overtake Doker is if it will match the Docker in these aspects. As much as I'd love to try this lightweight VM…
The ready-to-use is only true for the most popular software like PostgreSQL. Anything else is often broken and/or unmaintained.