I think a lot of folks are going out of their way to misunderstand what happened. Yes there are other similar projects and containers. No, none come from a long established COMMUNITY RUN PROJECT. This is something akin to the difference between VirtualBox and OpenBSD’s vmd. Ones a product with a “free” tier, the other is a community project.
Execute Docker Containers as QEMU MicroVMs
41–50 of 66 posts
Re: Execute Docker Containers as QEMU MicroVMs
#42Earlier quoted context omitted.
> > the single important binary > This is also such a weird thing to throw out there. I like a good Go program myself, but most companies are not only deploying single-binary statically linked applications. Most companies are also deploying some kind of Ruby, Python, or Java application... none of which are likely to be a single file in practice. Sure, but usual practice with containers is to put each thing in its ow…
> Sure, but usual practice with containers is to put each thing in its own, unless they are very tightly coupled. Web-app with a SQL database and a memory cache? Three containers. You can do otherwise, but that's typical. Usually each container ends up with one main, important running process, and not much else. I agree, but... getting all the application dependencies in there is more than just getting a single binar…
FreeBSD introduced Jails in 1999.
I used my first Jail in 2001.
Docker was started over a decade later in 2013.
It’s reasonable to be confused why Jails lacks the mindshare. “Because it lacks all these other over-the-top features that we need” might be reasonable in response, except that Docker didn’t have any of these things on day 0 either.
Jails had a 14 year head start, Docker reinvents the wheel, and nor particularly well at first. Why did it succeed more than Jails did? It wasn’t because of the piss-poor native Mac support.
Re: Execute Docker Containers as QEMU MicroVMs
#43Earlier quoted context omitted.
Is this what gvisor is? https://github.com/google/gvisor
No, gVisor is from Google. They emulate system calls in user-space and use VMs, which increases runtime performance overhead. We use hardware virtualization to directly run containers -- no I/O emulation, no expensive VM exits, scale as needed. Initial comparison with FC/GVisor/Xen here: https://github.com/ashishbijlani/kwarantine
I'm not sure gvisor requires vm exits. Their first backend used ptrace very similarly to how user mode Linux worked.
Minor quip though since ptrace might even be slower than vm exits; your core point stands.
Re: Execute Docker Containers as QEMU MicroVMs
#44Earlier quoted context omitted.
> Sure, but usual practice with containers is to put each thing in its own, unless they are very tightly coupled. Web-app with a SQL database and a memory cache? Three containers. You can do otherwise, but that's typical. Usually each container ends up with one main, important running process, and not much else. I agree, but... getting all the application dependencies in there is more than just getting a single binar…
FreeBSD introduced Jails in 1999. I used my first Jail in 2001. Docker was started over a decade later in 2013. It’s reasonable to be confused why Jails lacks the mindshare. “Because it lacks all these other over-the-top features that we need” might be reasonable in response, except that Docker didn’t have any of these things on day 0 either. Jails had a 14 year head start, Docker reinvents the wheel, and nor particu…
It seems pretty obvious that the big thing here is that most people ship apps on Linux, not on FreeBSD.
Re: Execute Docker Containers as QEMU MicroVMs
#45Something I'd be very interested in: building a PXE image from something declarative like Dockerfiles.
Google Container Optimized OS is basically this I think. It's what's used when you start a GCE instance with a docker image.
Re: Execute Docker Containers as QEMU MicroVMs
#46Something I'd be very interested in: building a PXE image from something declarative like Dockerfiles.
Try LinuxKit https://github.com/linuxkit/linuxkit
Re: Execute Docker Containers as QEMU MicroVMs
#47Why not run containers in VMs in containers in VMs? :) Seriously, VMs are hardly as secure as many people want to believe unless you're utilizing enclaves and even that has vulnerabilities. I think a better approach is Seccomp and whatever other filtering makes sense.
Machine Turducken.
Re: Execute Docker Containers as QEMU MicroVMs
#48> Can we somehow combine the advantages of the docker ecosystem with VMs? Shameless plug: this is exactly what our goal is with https://kwarantine.xyz We are creating a new hypervisor (from scratch) that can run strongly isolated Docker/LXC containers.
The "fork" sounds like you blue pill the OS for each container? I'm assuming the concept is like Cappsule [1] or Bromium [2]?
[1] https://cappsule.github.io/ [2] https://en.wikipedia.org/wiki/Bromium#/media/File:Bromium-en...
Re: Execute Docker Containers as QEMU MicroVMs
#49Earlier quoted context omitted.
A while back I did some looking at FreeBSD jails to try to figure out why they don't have more mindshare (especially when paired with the nigh-superpower-granting ZFS). I came away baffled that they weren't more widely-promoted, compared with Docker and friends. After thinking about it for a while, all I can figure is they're so straightforward to use and well-documented that there's no room to make one's name, or to…
If technically best in the container space mattered, Illumos would be everywhere...
Or z/OS
Re: Execute Docker Containers as QEMU MicroVMs
#50> Can we somehow combine the advantages of the docker ecosystem with VMs? Shameless plug: this is exactly what our goal is with https://kwarantine.xyz We are creating a new hypervisor (from scratch) that can run strongly isolated Docker/LXC containers.
The "fork" sounds like you blue pill the OS for each container? I'm assuming the concept is like Cappsule [1] or Bromium [2]? [1] https://cappsule.github.io/ [2] https://en.wikipedia.org/wiki/Bromium#/media/File:Bromium-en...
fork here is COW on the host kernel (i.e., copying EPT entries). We will post detailed technical documentation soon.