Hacker News Reader

Comment by FooBarWidget | Hacker News Reader

From what I understand, it doesn't. You're expected to already have a container with a web server in it, and a container that already has a database in it. The web server container then uses the CoreOS service discovery feature to find out what IP address the database container listens that, and configures itself.

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.

View on HN

To my mind, the big idea here is that containers will self-configure. This is configuration _inside_ the container, rather than configuration from _outside_ the container (like Chef/Puppet etc).

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.

What you're saying is exactly what I said in the first paragraph. Containers discover the config and configure themselves. But where do those containers come from in the first place and how to you build them? Where does that container, containing your in-house app, come from? That is where Chef/Puppet may come in.

I was thinking that there would be a generic Rails container (like a Heroku buildpack), that reads the location of your Rails code from the configuration, downloads it, and runs it.

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!

As mentioned, you would need "some sort of process" to config the host -- this is Puppet/Chef/etc. Replacing those is not trivial.

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.

Exactly. A container self-configuring by pulling it's config from an external service is pretty much the same as chef-client pulling down a configuration from the Chef server.

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.

>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.

If that's all you want then use Ubuntu Server.

That's not stripped down nearly enough for my tastes. I'm talking about the absolute bare minimum to make an app fully function.

Working on a scripting interface to Linux designed so you can configure everything internally to your application (ie it can run as the init process) with no significant dependencies (you can statically link it)[1]. Its not finished yet, but you can configure network interfaces, routing etc. Needs some more examples, build scripts etc...

[1] https://github.com/justincormack/ljsyscall

Have you tried https://help.ubuntu.com/12.04/serverguide/jeos-and-vmbuilder... ?

The minimum install has ~4 processes running. You can only get so much more bare then that.

Puppet could indeed be that process, and certainly replacing it isn't trivial. But I'm excited by the idea that we could replace it, by being able to rely on the configuration being directly available (provided by the OS). We'll have to see what gets created!

What's the advantage of it being built into the OS versus using chef or puppet? There's going to be some kind of process running to handle configuration no matter what. Docker also has Dockerfiles to handle configuration of containers. After seeing this article I looked into config management in Docker and containers and I'm having a hard time seeing why something like puppet/chef isn't the right solution.

You can design your containers/vm to self configure with puppet/chef. I have ec2 instance that you configure by telling it what role it is when you start it and then it has headless puppet scripts which configure it on boot.

Indeed. It will happen. chef and puppet are replicating manual config. You need your app to configure its whole environment.

If you're under the impression Puppet and Chef simply replicate a manual config, you're doing it wrong.

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.

Reply on news.ycombinator.com