4 ms·

I've been waiting for the hype to die down a bit and for the project to stabilise before properly playing with it but, from the outside looking in, I must admit

by corford 12y ago

I've been waiting for the hype to die down a bit and for the project to stabilise before properly playing with it but, from the outside looking in, I must admit I struggle to see how it's gaining as much attention as it is. I can see the advantage for dev boxes where a developer might want to setup a load of containers on their machine to emulate a staging or production environment. But I don't really understand why you'd want to base your entire production infrastructure on it. What's wrong with setting up kvm "gold" images for your various server types (db server, redis instance, ha proxy server etc.) and then just dd'ing those images to host machines and using ansible/puppet/chef to do any final role configuration on first boot? At least that way you've got all the security and flexibility a proper vm implies with not much more admin overhead than if you'd used docker.

emeraldd 12y ago
That works if you have physical access to the machine/vm. What about EC2? Linode? Digital Ocean? etc.
- corford 12y ago
  Fair point. I guess for serious stuff I just find it bizarre that you'd want to run a load of containers in a vm (rather than just spooling up additional dropelts or linode instances). For non 'weekend project' stuff, surely it's cheaper and more efficient to lease a dedicated server and stick your own vms on that?
  - tethra 12y ago
    It almost certainly is cheaper, but it's more than some are willing to learn to do, I guess.
  - eropple 12y ago
    At Localytics, we wouldn't need to lease a dedicated server. We'd need to lease dozens. And we'd need to have the ability to spin up new hardware to accomodate more load in a minute or two. You don't get that with physical hardware unless you want to overpay. We could overpay for depreciating plant assets or we could overpay for variable costs that we can more directly control. The latter makes sense to us.
    - corford 12y ago
      Ok, that makes sense. For your workload (large and elastic), I guess I can see the advantage of using docker to quickly provision a newly created vm (assuming the vm's role is completely provided for by just that one container).
      - eropple 12y ago
        Totally. As mentioned in my other comment, it can also let us deploy a bunch of applications on the same virtualized node really quickly via Mesos or Flynn or whatever. That said, I use Docker at home too[1] because it does make thinking about things easier. I dump my blog in a thin container not because I urgently desire security (though with Wordpress I kind of do worry...), but because it lets me develop and deploy using the same tools. [1] - http://edcanhack.com/2014/07/docker-web-proxy-with-ssl-support/ http://edcanhack.com/2014/07/docker-web-proxy-with-ssl-suppo...
  - geekbri 12y ago
    Isn't it just as much about deployment though? The thing about docker is that deploying your new app basically means stopping your running instance and starting a new one. You actually don't even NEED to stop the current running one if you have something above it that just knows which instances / ports to route traffic to. I think docker is about ease of deployment. You still use the same server you just run a different command. As opposed to creating a new image and spinning up said image. You can imagine roll back / migration is pretty easy in this case.
- mmgutz 12y ago
  All of those have simple REST APIs to setup/teardown instances. Libraries exists for popular languages like node, ruby, java, etc.
jasode 12y ago
>What's wrong with setting up kvm "gold" images for your various server types (db server, redis instance, ha proxy server etc.) and then just dd'ing those images to host machines and using ansible/puppet/chef to do any final role configuration on first boot? You're leaving out the other attractive aspects of Docker/containers: performance, lower cpu utilization, instant spin up, less disk space, etc. Those factors lead to higher density of images on servers. Puppet/Chef + hypervisors can't compete with those particular factors. In summary: Containers have less isolation, but can be more densely packed. VMs have more isolation, but less densely packed. The 2 technologies have different tradeoffs and economics.
eropple 12y ago
What's wrong with that is that now your application--and, by extension, your developers--has (have) to care about a lot more stuff and needs to have its testing surface expanded appropriately. The potential interactions and therefore potential failures between, say, ops's cron jobs, the wire-up of stuff like logstash, changes to your chef configs, etc.means there's a ton more testing to be done. In a Docker world, the amount of stuff running in a context that the application can see is minimal and it's all related directly to the application in question. Your inputs and outputs can be clearly defined and this lets you present a stable API to the outside world (via volumes and links) while, as or even more importantly, providing a known-good, stripped-down environment for the application to run on. (chroot jails are a fine solution too, but I do prefer the relative handholding and easier application independence of Docker and AuFS.) The other problem with your suggestion -- dd'ing and then running Chef or whatever -- is boot time. I can spin up an AMI ready to deploy Docker apps in under sixty seconds. We work in AWS, so I can't speak to the actual time of deploying a physical server, but I can download and deploy a Docker image from an AWS-hosted private registry in ten seconds. Chef won't even get its act together in thirty seconds, let alone do your stuff; between downloading a full VM disk image, the startup time for that virtual machine, and the time to run chef, you've wasted so much time. Here at Localytics, we're trying to transition to an environment that is very comfortable with automatic scaling and can do so fast--seconds, rather than minutes--and Docker is a big part of that effort. Right now we deploy to AWS autoscaling groups (with AMIs defined via Packer). I'm pushing hard for us to use a clusterization system like Mesos/Deimos because it'll let us save money by introducing safe, sane multi-tenancy--and it'll let us react to changes in system load in mere seconds. (obligatory: we're hiring. we work on fun stuff. eropple@localytics.com)
josephg 12y ago
I setup docker for our server deployments here at lever.co. We deploy our application multiple times a day. We test our changes in our staging environment first, and its important that we deploy the exact same code to production that we tested. Its also important that we can rollback any changes we make. An application-image is the right way to do that. (With compiled dependancies and whatnot). And we could make an OS image every time we deploy code, but making a 600MB Ubuntu image to deploy a few lines of code change is ridiculous. There's certainly lots of things that docker could do better, but I haven't seen any tools that let me deploy so conveniently, easily & reliably.
- ndpu 12y ago
  You can create "base" image of your application and update only code. Part of our fabric deploy script: with api.settings(**env_vars): api.run('docker run baseimage sh -c "git pull && cp /src/webapp/settings/paths_docker.py /src/webapp/settings/paths.py"') d = datetime.datetime.now().strftime('%Y-%m-%d,%H-%M') # new image from last running container with updates api.run('docker commit $(docker ps -lq) baseimage:%s' % d) api.run('docker stop $(docker ps -aq)') api.run('docker run -d -p 127.0.0.1:8073:8083 baseimage:%s sh runindocker.sh' % d)
the_real_bto 12y ago
I've been playing around with docker, so I will lend my two cents. If kvm gold images work for you, then by all means use them! What I like about docker: The layered filesystem [0] is easy to work with and seems pretty smart. I can easily tweak an image, push it to docker hub and pull it back down. Only the delta is being pushed and pulled, not the whole filesystem. This seems like a pretty big win to me! Your db server and redis instance can share the same base system image. This makes updates and redeploying the images much faster! Also the containers are much lighter weight to run than a vm. You don't need a beefy machine to run a few containers. I'm under the impression that one can run 20-30 containers on a modern laptop, but haven't verified this for myself. [0] http://docs.docker.com/terms/layer/ http://docs.docker.com/terms/layer/
realusername 12y ago
The principal difference is that the virtual machine contains everything whereas you can spawn a container for all the components of your infrastructure. - It's easy to restart a container if it crashed and container can be tested individually before being pushed in production. - An application will not mess with the configuration of another app (that's solving the problem of virtualenv, rvm and apt incompatibilities). - The application is not tight to a physical machine, a container can connect to another machine instead of the local one just by changing the routing or environment variables if everything is done properly. It's the UNIX philosophy applied to applications, everything must be as small as possible, do only one task and do it properly and I think that's part of docker's popularity. However like most things, it's not really magic and it must be designed and maintained properly to get all these benefits.
vidarh 12y ago
Doing the kvm, plus ansible/puppet/chef approach has the overhead of making testing harder. I have Docker containers that I rebuild on every test/dev run on some applications, because it is so fast. It means I know the Dockerfile is 100% up to date with my dependencies etc. By the time I'm done testing the application, I'm done testing the container, and it's ready to deploy. If you need the added security of KVM or similar to isolate your app components, nothing stops you from isolating your Docker containers in a very minimal KVM - even just one container per VM if you prefer, and still get the containerization benefits (which to me is more about having "portable", deployable known fixed units with a repeatable build process than about how it is virtualised; the virtualisation/isolation is a bonus - we could have used Docker without it, by, as mentioned, just running one container per VM).
- corford 12y ago
  I like the single container on top of a very bare vm approach. That seems like the best of both worlds and (thanks to everyone's replies) I'm beginning to better understand the advantages to testing and deployment docker brings. Looks like it's time to get my hands dirty and experience first hand what all the fuss is about.

by corford 12y ago

emeraldd 12y ago

That works if you have physical access to the machine/vm. What about EC2? Linode? Digital Ocean? etc.

corford 12y ago
Fair point. I guess for serious stuff I just find it bizarre that you'd want to run a load of containers in a vm (rather than just spooling up additional dropelts or linode instances). For non 'weekend project' stuff, surely it's cheaper and more efficient to lease a dedicated server and stick your own vms on that?
- tethra 12y ago
  It almost certainly is cheaper, but it's more than some are willing to learn to do, I guess.
- eropple 12y ago
  At Localytics, we wouldn't need to lease a dedicated server. We'd need to lease dozens. And we'd need to have the ability to spin up new hardware to accomodate more load in a minute or two. You don't get that with physical hardware unless you want to overpay. We could overpay for depreciating plant assets or we could overpay for variable costs that we can more directly control. The latter makes sense to us.
  - corford 12y ago
    Ok, that makes sense. For your workload (large and elastic), I guess I can see the advantage of using docker to quickly provision a newly created vm (assuming the vm's role is completely provided for by just that one container).
    - eropple 12y ago
      Totally. As mentioned in my other comment, it can also let us deploy a bunch of applications on the same virtualized node really quickly via Mesos or Flynn or whatever. That said, I use Docker at home too[1] because it does make thinking about things easier. I dump my blog in a thin container not because I urgently desire security (though with Wordpress I kind of do worry...), but because it lets me develop and deploy using the same tools. [1] - http://edcanhack.com/2014/07/docker-web-proxy-with-ssl-support/ http://edcanhack.com/2014/07/docker-web-proxy-with-ssl-suppo...
- geekbri 12y ago
  Isn't it just as much about deployment though? The thing about docker is that deploying your new app basically means stopping your running instance and starting a new one. You actually don't even NEED to stop the current running one if you have something above it that just knows which instances / ports to route traffic to. I think docker is about ease of deployment. You still use the same server you just run a different command. As opposed to creating a new image and spinning up said image. You can imagine roll back / migration is pretty easy in this case.
mmgutz 12y ago
All of those have simple REST APIs to setup/teardown instances. Libraries exists for popular languages like node, ruby, java, etc.

jasode 12y ago

>What's wrong with setting up kvm "gold" images for your various server types (db server, redis instance, ha proxy server etc.) and then just dd'ing those images to host machines and using ansible/puppet/chef to do any final role configuration on first boot? You're leaving out the other attractive aspects of Docker/containers: performance, lower cpu utilization, instant spin up, less disk space, etc. Those factors lead to higher density of images on servers. Puppet/Chef + hypervisors can't compete with those particular factors. In summary: Containers have less isolation, but can be more densely packed. VMs have more isolation, but less densely packed. The 2 technologies have different tradeoffs and economics.

eropple 12y ago

What's wrong with that is that now your application--and, by extension, your developers--has (have) to care about a lot more stuff and needs to have its testing surface expanded appropriately. The potential interactions and therefore potential failures between, say, ops's cron jobs, the wire-up of stuff like logstash, changes to your chef configs, etc.means there's a ton more testing to be done. In a Docker world, the amount of stuff running in a context that the application can see is minimal and it's all related directly to the application in question. Your inputs and outputs can be clearly defined and this lets you present a stable API to the outside world (via volumes and links) while, as or even more importantly, providing a known-good, stripped-down environment for the application to run on. (chroot jails are a fine solution too, but I do prefer the relative handholding and easier application independence of Docker and AuFS.) The other problem with your suggestion -- dd'ing and then running Chef or whatever -- is boot time. I can spin up an AMI ready to deploy Docker apps in under sixty seconds. We work in AWS, so I can't speak to the actual time of deploying a physical server, but I can download and deploy a Docker image from an AWS-hosted private registry in ten seconds. Chef won't even get its act together in thirty seconds, let alone do your stuff; between downloading a full VM disk image, the startup time for that virtual machine, and the time to run chef, you've wasted so much time. Here at Localytics, we're trying to transition to an environment that is very comfortable with automatic scaling and can do so fast--seconds, rather than minutes--and Docker is a big part of that effort. Right now we deploy to AWS autoscaling groups (with AMIs defined via Packer). I'm pushing hard for us to use a clusterization system like Mesos/Deimos because it'll let us save money by introducing safe, sane multi-tenancy--and it'll let us react to changes in system load in mere seconds. (obligatory: we're hiring. we work on fun stuff. eropple@localytics.com)

josephg 12y ago

I setup docker for our server deployments here at lever.co. We deploy our application multiple times a day. We test our changes in our staging environment first, and its important that we deploy the exact same code to production that we tested. Its also important that we can rollback any changes we make. An application-image is the right way to do that. (With compiled dependancies and whatnot). And we could make an OS image every time we deploy code, but making a 600MB Ubuntu image to deploy a few lines of code change is ridiculous. There's certainly lots of things that docker could do better, but I haven't seen any tools that let me deploy so conveniently, easily & reliably.

ndpu 12y ago
You can create "base" image of your application and update only code. Part of our fabric deploy script: with api.settings(**env_vars): api.run('docker run baseimage sh -c "git pull && cp /src/webapp/settings/paths_docker.py /src/webapp/settings/paths.py"') d = datetime.datetime.now().strftime('%Y-%m-%d,%H-%M') # new image from last running container with updates api.run('docker commit $(docker ps -lq) baseimage:%s' % d) api.run('docker stop $(docker ps -aq)') api.run('docker run -d -p 127.0.0.1:8073:8083 baseimage:%s sh runindocker.sh' % d)

the_real_bto 12y ago

I've been playing around with docker, so I will lend my two cents. If kvm gold images work for you, then by all means use them! What I like about docker: The layered filesystem [0] is easy to work with and seems pretty smart. I can easily tweak an image, push it to docker hub and pull it back down. Only the delta is being pushed and pulled, not the whole filesystem. This seems like a pretty big win to me! Your db server and redis instance can share the same base system image. This makes updates and redeploying the images much faster! Also the containers are much lighter weight to run than a vm. You don't need a beefy machine to run a few containers. I'm under the impression that one can run 20-30 containers on a modern laptop, but haven't verified this for myself. [0] http://docs.docker.com/terms/layer/ http://docs.docker.com/terms/layer/

realusername 12y ago

The principal difference is that the virtual machine contains everything whereas you can spawn a container for all the components of your infrastructure. - It's easy to restart a container if it crashed and container can be tested individually before being pushed in production. - An application will not mess with the configuration of another app (that's solving the problem of virtualenv, rvm and apt incompatibilities). - The application is not tight to a physical machine, a container can connect to another machine instead of the local one just by changing the routing or environment variables if everything is done properly. It's the UNIX philosophy applied to applications, everything must be as small as possible, do only one task and do it properly and I think that's part of docker's popularity. However like most things, it's not really magic and it must be designed and maintained properly to get all these benefits.

vidarh 12y ago

Doing the kvm, plus ansible/puppet/chef approach has the overhead of making testing harder. I have Docker containers that I rebuild on every test/dev run on some applications, because it is so fast. It means I know the Dockerfile is 100% up to date with my dependencies etc. By the time I'm done testing the application, I'm done testing the container, and it's ready to deploy. If you need the added security of KVM or similar to isolate your app components, nothing stops you from isolating your Docker containers in a very minimal KVM - even just one container per VM if you prefer, and still get the containerization benefits (which to me is more about having "portable", deployable known fixed units with a repeatable build process than about how it is virtualised; the virtualisation/isolation is a bonus - we could have used Docker without it, by, as mentioned, just running one container per VM).

corford 12y ago
I like the single container on top of a very bare vm approach. That seems like the best of both worlds and (thanks to everyone's replies) I'm beginning to better understand the advantages to testing and deployment docker brings. Looks like it's time to get my hands dirty and experience first hand what all the fuss is about.