for example.. if i m deploying a rails apps, how would coreos make it possible to install web servers, databases and rubygems? all through dockerfile descriptions? an app level getting started would be great..
We want to build an environment where you run and manage all of those servers and databases inside of containers and via APIs. Or even better skip the APIs and just add nodes and have something like etcd help you configure it dynamically
But, we needed to get all of the foundations solid and that is where we are today.
I believe philips is saying that CoreOS is still experimenting with and reifying exactly what the layer above containerized applications should be composed of and look like.
Update: what is really interesting is the amount of hype the Docker project created, having no fundamentally new ideas or technological advances, just well-written (we must admit) web pages full of buzzwords.
As a person who ran FreeBSD jail-based virtual hosting in production, I would say that disk and network I/O will be a bottleneck, because either interface does not scale well enough.)
On performance: containerization > virtualization. Containerization is also not just about performance (people are running it in virtualized environments) it's also about contained configurations.
Your tone is unnecessarily belligerent (I could be reading into what you wrote though).
Also - I know people who know people and are pushing for the Docker team to support containerizing FreeBSD jails too. Since the primary work horse right now for Docker is lxc, it should be possible to generalize it enough to include support for FreeBSD jails.
Docker does more than just "jail"; it does for jails what package managers did for programs.
I have tried to make minimalist but compatible system. It doesn't happen. Things like kerberos, sasl, ldap, pam messes everything up. I ended up with almost exactly the "minimum install". Paraphrasing a bit "dependencies! dependencies! dependencies!" and minimal install of Fedora or Ubuntu Server is almost optimal.
Well there's still no usable (web) gui for managing zfs (tell me what you want, but that IS wha is needed to make zfs more popular).
Would a minimal install of [your_server] into kvm give more rough performance than LXC+Docker?
One downside of Docker & LXC is that applications CAN breakout of the "jail" and affect the host machine. The docker guys told me about that fact and that they will work on that in the future.
After all that fizzbuzz, I'm not sure anymore, maybe chef/puppet/ansible or salt would be a much better solution than dealing with bits "manually". Because that would be the Model Driven Approach.
Close to so-called real life notion might be one like this: some guys managed to get funding for an mix of buzzwords they not fully understood themselves, especially an OS design. But after placing Minimum Viable Buzzwords website they got a lot of hype, so, magically, it became a "great idea" a "big thing" being absolutely nothing new and solving no real problems.
There is no problem with installation of packages or tarbals on the same system, through network, on multiple hosts, whatever. As long as it is the same version of the system. There is nothing to fix. It is optimal already and package managers and ports systems doing the job well enough, taking care of dependencies, security updates, restarts, etc.
All the buzz and hype is about people who do does not know and do not want to know how underlying system works, what are the basic ideas, etc. For such guys the promise of a simple interface (they can see it is simple on the site) which requires no thinking or understanding, is, of course, a piece of cake.
This is exactly how we have all the piles upon piles of Java crap. There is no need to think or understand and deployment is easy - just dumb all the shit in the same dir. Now we have all the mess and some smartases talking "JVM optimizations" but forgetting to mention, than a slight change in workload, leave alone the code, will make all their prior assumption invalid. OK, fuck it.
`INSTANCE=$(docker run jonwood/nginx-node) && curl http://127.0.0.1:4001/v1/keys/nginx-nodes/$INSTANCE -d $(docker port $INSTANCE 80)`
You'd then use Etcd's tree listing interface to grab the JSON fragments for each of those NGinx nodes, and configure Varnish or HAProxy or something to hit those backends.
Obviously this isn't anywhere near production ready (for example if one of your NGinx instances goes down there's nothing to remove it from the pool), but so far I'm impressed with what CoreOS is doing.
My plan to solve this was to use Doozer with a small daemon in each agent server which would keep some kind of registry of the services running on the machine. I think that could be relatively lightweight and with the ability to broadcast via watches there could be some kind of action attached to a node being removed and added.
In other words, it does not replace Chef/Puppet. Maybe only for the configuration part, but not for the installation part. You may still want to use Chef/Puppet for creating the container in the first place.
This means that your Docker container doesn't need to run a Chef/Puppet/SSH configuration agent. It will need some sort of "discover my config and configure myself" process running, which would perform much the same role though.
In other words, the container is "smart" and self-assembles. If you need to add more webserver capacity (for scaling), you just launch more webserver containers; they will register themselves with the load balancer and attach to the database.
Of course, building these smart containers is non-trivial, so I'm eager to see some real-world examples.
So, just like Heroku buildpacks, you can create your own, and you can even create one with your app baked in; but most people would end up using an off-the-shelf container.
But this is just my interpretation! Your approach may be better, and it doesn't look like CoreOS will care which way you want to do things!
Also, not quite sure I understand config "inside vs outside" being the big idea. You can easily include Puppet manifests and have Puppet run in standalone mode from within the container with no outside access to config. That's not new.
What I want from something like CoreOS is a stripped-down container host that will host stripped-down app containers. I want to package my app in the most-stripped-down fashion possible and deploy it on this stripped-down container host.
The idea of using Chef/Puppet to deploy an app onto a full-blown install of Ubuntu/CentOS/etc. seems like overkill. There's a lot of superfluous crap on that full install that consumes storage, memory, and CPU resources. Having a full OS also creates more attack vectors. If you were an attacker, would you rather root some Rails app on a full install of Ubuntu, complete with shells, compilers, etc., or a box with only the bare essentials required to run that Rails app?
I suppose that an argument for having a full-OS install is to make it easy for things like Chef/Puppet to update the server in situ. Stripped-down containers could make that unnecessary. Imagine an app container so small that it's easier to just blow away the container and create a new one with the freshest software.
If that's all you want then use Ubuntu Server.
Look at concepts like Puppet's exported resources. The tools to accomplish service discovery have been around (and many of us have been using them) for year. I'm just excited to see the concept finally getting a bit more mindshare via Docker and now CoreOS.