VMware Photon: Minimal Linux Container Host
github.com
github.com
People don't want containers on VMs. They just want containers. There are many reasons for that.
> just let me run containers on bare metal
Look at SmartOS for example - their zones run on bare metal and provide most of the vm features as well as strong seperation.
Containers run on a shared kernel. That kernel should run on metal, not in a hypervisor.
For someone so confident in their technical abilities, I'm surprised you suggest running a general purpose OS as a container parent.
I guess by your reasoning you could talk about running your nodejs services "on the bare metal" because it's obvious you need a kernel and nodejs too. I think it might be similarly misleading.
Linux containers rely on the operating system via cgroups and namespace isolation to do virtualisation. That's bare-metal under ordinary virtualisation terminology.
"No, because of the heavy IO load we run it on bare metal"
Doesn't sound odd to me.
When life imitates art.
The alternative is a Hybrid Virtual Machine (HVV), where you run the hypervisor as a seperate program on a host operating system. VirtualBox is one if the better known examples of a HVV, or type-2 hypervisor.
With containers, you could argue that they are actually bare-metal because they share more in common with a type-1 hypervisor, because it is the operating system itself that is creating an efficient and isolated environment within which the application runs. In terms of Linux containers, a combination of resource isolation (cgroups [2]) and namespace isolation [3] achieves operating system level virtualisation.
So actually, containers are really bare-metal.
1. http://cs.nyu.edu/courses/fall14/CSCI-GA.3033-010/popek-gold...
If you're wedded to Linux, check these guys out:
All those years bashing Windows administrators....
Think about working somewhere really big: it's both hard and risky to split a huge business system into containers in one release. Imagine instead doing something like carving out the database, load balancer, task queue workers, etc. piecemeal with a discrete component being containerized in each release. If you were taking the agile approach like that, not saying “Here's a completely different way to manage all of the new services” has significant value.
Do you also expect your email client to manage your photo library and keep track of your phone calls?
Gmail will basically do that, what with tight integration with Picassa and Google Voice...
Can you explain why you believe this to be true? Consider my database server example – if I want to have a MySQL/Postgres service available for our developers to use why would it matter whether it runs inside a VM or a container at the level where I'm saying “Keep 2 copies running on separate hosts for HA” or “Block network access except for hosts in this service group”?
To me, it's a sign of bad system design if the consumers of a service need to know whether it's running on a VM or a container. Only the developers and operators should need to care at that level.
This. The advantage of containers is that you isolate and control your resources more precisely - if those using the software running in the container find they have differing requirements, you should just be able to change the resources allocated to the container - in much the same way you would with a normal server.
Unless your environment is 100% application-level clustered these will be invaluable features.
In those situations you specifically do want containers on VMs because Docker containers do not provide the same level of security and isolation that VMs do.
However, check out hyper.sh, the project uses hypervisors to run Docker images, which completely eliminates the need of guest OS, making the whole stack immutable while just offering the hypervisor-level isolation.
In my opinion, Hyper is the way to go, instead of the minimalist guest OS distro.
You don't eliminate minimalist VM even with hyper.sh
I could see vmware doing something like that -- implementing the docker api, but actually running containers on very lightweight vms, so they can leverage their existing virt infrastructure (memory ballooning, cpu allocation, migration, etc) with it.
This is the opposite of "turtles all the way down" - it's like a veritable layer cake of system isolation. It's the turducken of server systems.
"a new, open-source, yum-compatible package manager that will help make the system as small as possible, but preserve the robust yum package management capabilities."
To me, for this to be widely successful it should work well across any VM solution
Look's like it's only for the VMWare platform.
The README also says "An official Vagrant box is available on Hashicorp Atlas, to get started: vagrant init vmware/photon"[1] and they include instructions for Google Compute Engine[2]. It may be optimized to run on a VMware product, but doesn't seem that's a requirement.