10 ms·

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 descriptio

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

FooBarWidget 13y ago
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.
- justinsb 13y ago
  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.
  - 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.
philips 13y ago
This is where we are going next; CoreOS is super young today though. 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.
- dschiptsov 13y ago
  So, you are not encountered the dependency and version hell yet and just assumed that maintaining all the libs and tools a rails app is implicitly requires is a easy task?) Good luck, then.)
  - RickHull 13y ago
    No, that part is already solved. That's what containers do. 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.
    - dschiptsov 13y ago
      So, basically, it looks like as if I move my /usr/local directory between hosts to be run under chroot, using aufs instead of tar.gz, lxc instead of chroot and some wrapper around ssh and scp? but with all that hype and memes? It looks like implementation of FreeBSD's jails with impoverished ports and fancy command-line tool. OK. 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.)
      - justincormack 13y ago
        SSD and 10Gb Ethernet are big changes...
jon-wood 13y ago
I just threw together a really simple proof of concept which uses a shell script to spin up a Docker instance running NGinx, and then register the port that instance is listening on with Etcd. Because it's quite so simple, here it is: `INSTANCE=$(docker run jonwood/nginx-node) && curl http://127.0.0.1:4001/v1/keys/nginx-nodes/$INSTANCE 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.
- ideal0227 13y ago
  "for example if one of your NGinx instances goes down there's nothing to remove it from the pool" For now, you can set up a node with TTL and update it. If the server goes down, the node will disappear. We are going to provide a client that will keep long connection with the server.
- johnbellone 13y ago
  > (for example if one of your NGinx instances goes down there's nothing to remove it from the pool) 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.

FooBarWidget 13y ago

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.

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

philips 13y ago

This is where we are going next; CoreOS is super young today though. 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.

dschiptsov 13y ago
So, you are not encountered the dependency and version hell yet and just assumed that maintaining all the libs and tools a rails app is implicitly requires is a easy task?) Good luck, then.)
- RickHull 13y ago
  No, that part is already solved. That's what containers do. 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.
  - dschiptsov 13y ago
    So, basically, it looks like as if I move my /usr/local directory between hosts to be run under chroot, using aufs instead of tar.gz, lxc instead of chroot and some wrapper around ssh and scp? but with all that hype and memes? It looks like implementation of FreeBSD's jails with impoverished ports and fancy command-line tool. OK. 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.)
    - justincormack 13y ago
      SSD and 10Gb Ethernet are big changes...

jon-wood 13y ago

I just threw together a really simple proof of concept which uses a shell script to spin up a Docker instance running NGinx, and then register the port that instance is listening on with Etcd. Because it's quite so simple, here it is: `INSTANCE=$(docker run jonwood/nginx-node) && curl http://127.0.0.1:4001/v1/keys/nginx-nodes/$INSTANCE 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.

ideal0227 13y ago
"for example if one of your NGinx instances goes down there's nothing to remove it from the pool" For now, you can set up a node with TTL and update it. If the server goes down, the node will disappear. We are going to provide a client that will keep long connection with the server.
johnbellone 13y ago
> (for example if one of your NGinx instances goes down there's nothing to remove it from the pool) 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.