3 ms·

To my mind, the big idea here is that containers will self-configure. This is configuration _inside_ the container, rather than configuration from _outside_ th

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.

adient 13y ago
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.
- justinsb 13y ago
  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!
  - kekumu 13y ago
    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.
- chrissnell 13y ago
  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.
  - s_baby 13y ago
    >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.
    - chrissnell 13y ago
      That's not stripped down nearly enough for my tastes. I'm talking about the absolute bare minimum to make an app fully function.
      - justincormack 13y ago
        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 https://github.com/justincormack/ljsyscall
FooBarWidget 13y ago
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.
- justinsb 13y ago
  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!
justincormack 13y ago
Indeed. It will happen. chef and puppet are replicating manual config. You need your app to configure its whole environment.
- subway 13y ago
  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.
dalore 13y ago
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.

adient 13y ago

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.

justinsb 13y ago
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!
- kekumu 13y ago
  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.
chrissnell 13y ago
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.
- s_baby 13y ago
  >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.
  - chrissnell 13y ago
    That's not stripped down nearly enough for my tastes. I'm talking about the absolute bare minimum to make an app fully function.
    - justincormack 13y ago
      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 https://github.com/justincormack/ljsyscall

FooBarWidget 13y ago

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.

justinsb 13y ago
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!

justincormack 13y ago

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

subway 13y ago
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.

dalore 13y ago

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.