There's also the Andrey Mirtchovski and Latchesar Ionkov implementation of go9p, but all I can find is a dead Google Code link from here: http://9p.cat-v.org/implementations
- It puts Mirage in use in real production systems.
- It strengthens the ecosystem around Hypervisor.framework. After xhyve and Veertu, this is really nice. So much for the meme that newer OS X versions only integrate iOS features.
Open sourcing our libraries is obviously just the start. We're really keen to hear about any other uses that people might have and move HyperKit in the direction of easy integration with higher-level frameworks.
For instance, direct ports of unikernel projects to run against the HyperKit kexec APIs would be really fun. Any takers for MirageOS or HalVM? :-)
We're taking it in a fairly different direction from upstream xhyve and bhyve, with the integration with other kits like VPNKit, DataKit (and soon, FSKit). We wanted to be able to diverge the build system in particular, and this makes it difficult to maintain a direct fork.
However, we're committed to upstreaming patches to their relevant projects where relevant, and so the HyperKit Git repository is as close as we can make it. If it diverges a lot in the future with file renames, we'll have to figure out the Git-fu to make cherry-picks easier...
I wonder if we'll see a move towards getting Docker working on FreeBSD using either Jails or bhyve finally, since it talks about using bhyve hypervisor... That would be really great.
It should be possible to build a simpler port for FreeBSD with the recent Docker 1.11 release. It moved the container execution to containerd (https://github.com/docker/containerd), so that's where a bunch of the Jails logic would go.
I'm quite keen to see Docker running on FreeBSD so I can use it for my CI pipelines. I'm less interested in Linux emulation to run Linux images -- I'd like Docker support on FreeBSD to run FreeBSD images first!
Can't speak for anyone else, but while I think jails are "better" for a variety of reasons it seems clear there is far more market momentum behind Docker. More particularly, its toolchain. Given the choice between building myself (or relying upon a small, but talented, pool of devs) and drafting off tens of millions in VC cash and a much larger community I think some would prefer the ability to have a *BSD CI chain that is just a config setting in a Docker setup.
Containerd is just one part of what Docker does. There is also image management (signing via Notary), distribution (pull/push to the Hub), orchestration (Swarm and friends), linked services (Compose), etc. You could reuse all the rest of it while running containers in FreeBSD jails as the method of containment.
Seems like only a year ago Docker changed how it used Virtualbox to boot VMs using machine (and caused me endless amounts of suffering trying to figure out how to fix it). Now it would seem they are getting rid of Virtualbox entirely with their own VM...which needs contributions.
getting rid of Virtualbox entirely with their own VM...
Not really. This builds heavily upon Hypervisor.framework, which is included in new OS X versions. Hypervisor.framework is pretty cool, because it allows for building VM applications that are sandboxed and don't require kernel modules. As a result, Hypervisor.framework applications can even be distributed via the App Store (see e.g. Veertu).
The drawback is that now VM manager is at mercy of what Hypervisor.framework provides. For example, Veertu does not support redirection of USB devices into VM because the framework does not support it. That makes it rather useless for my usage and I stick with VirtualBox for now.
Of cause, this is not an issue for Docker as the framework covers all its needs.
Have your encountered any major bugs with Docker for OSX? I've been running docker-machine without any major issues for months but have noticed in the last few weeks that I need to reboot the VM lately due to weird caching issues.
I had it crash a couple times when it printed lots of text from the container to the terminal. I haven't had that happen since the update from today, though.
Docker is still pretty bleeding edge, and was never designed to work with Mac OS X or Windows from the get-go.
The fact that the proposed experience for OS X and Windows is so good is a testament to how hard the community and the Docker team have been working! It's natural that there would be some growing pains.
My understanding is not great, but it looks like they're bypassing a host VM entirely and using a shim (HyperKit) to talk to whatever virtualization the underlying OS supplies.
Very interesting work. I find go-9p quite fascinating and think it could really have broader applications. Docker if you see this, I actually think you're on to something for microservice development thats native to the docker world. I've been trying to come up with ways of replicating the unix philosophy around programs that do one thing well and the use of pipes but was always limited in my thinking in terms of http, json, etc, etc.
My advice, as a guy who's currently building something in the microservice space, explore this further. Spend some time building fit for purpose apps with this and see where it goes.
docker/go-9p https://github.com/docker/go-p9p
rminnich/ninep: https://github.com/rminnich/ninep
rminnich/go9p: https://github.com/rminnich/go9p
There's also the Andrey Mirtchovski and Latchesar Ionkov implementation of go9p, but all I can find is a dead Google Code link from here: http://9p.cat-v.org/implementations