3 ms·

> I mean I see a lot of folks doing hyper-scaling with containers, indeed you can get a lot of containers on a host and they are blindingly fast. But that doesn

by revscat 12y ago

> I mean I see a lot of folks doing hyper-scaling with containers, indeed you can get a lot of containers on a host and they are blindingly fast. But that doesn't excite me as much as people using it to automate their dev-test-build pipeline. This is it exactly. When I can develop locally using my favorite editor and my favorite OS, but then deploy -- still locally, mind -- to what is more or less the production environment... This has huge benefits for avoiding the "works on my box" problems that arise as code makes its way to prod.

mpdehaan2 12y ago
Run ALL the distributions and versions in prod? :)
- vidarh 12y ago
  I'd rather have the opportunity to re-test and re-deploy one component at a time than be forced to do "big bang upgrades". In the long run I hope we start seeing distros or tools targeted specifically at building minimal Docker images. E.g. if I'm going to deploy a Ruby based web app in Docker, the stuff I need present in the container is _very_ limited.
- PaulHoule 12y ago
  No, if your environment is standardized and stripped down you can run something that is very close to prod in your dev environment. Note docker isn't the only answer for this, for instance, you can use ordinary VMs with vagrant, but docker does it at ludicrous speed.
  - octix 12y ago
    So, basically to achieve this you need to run production env using docker too? So that docket could match it. Also, production data has to be copied over separately? Are these correct assumptions? PS: I'm still trying to understand how docket/containers may fit in current process.
    - jayfehr 12y ago
      You don't have to, but it would probably be best to keep it consistent. You could run your live server on barebones OS as you normally would, then create a docker image to mirror that. However, as we all know, mirrors often get out of sync fairly quick. But if you use the same image and only update using a Fabric or Ansible script, then you can be pretty certain that all your environments are identical. Not to mention that any newly created environments will brought up to the same point in no time at all.
    - tlrobinson 12y ago
      If you don't want to use Docker in production you could use something like Packer to build Docker base images (http://www.packer.io/docs/builders/docker.html http://www.packer.io/docs/builders/docker.html) and VM images (AMIs, OpenStack, whatever) using the same templates. There would still be some differences, like if the kernel version on your local machine didn't match. Note: I haven't tried this. Maybe it's a bad idea.
  - contingencies 12y ago
    if your environment is standardized and stripped down you can run something that is very close to prod in your dev environment. Sounds a lot like FreeBSD's release process, though personally I find that limiting! The problem is of course that 'very close to' is not 'equal to'. My own thoughts in this space are detailed at http://stani.sh/walter/cims/ http://stani.sh/walter/cims/ and http://stani.sh/walter/pfcts/ http://stani.sh/walter/pfcts/
Kiro 12y ago
They keep saying Vagrant and Docker are two different things but isn't that the whole point with Vagrant?
- NDizzle 12y ago
  Your username is the same as my (jindo) dog! So I'll reply to you. I've been using vagrant to fix exactly the problem of "works on my box" for years. Docker is way too much to explain to my small development team. They struggled to deal with vagrant for some time before figuring it out. Vagrant is perfect for us right now, and it would take a force of nature for me to even begin to push docker on them.
  - s_baby 12y ago
    I believe there are plans for offering a Vagrant api to Docker and vice-versa.
- revcbh 12y ago
  In many cases, Docker can be treated like a more lightweight Vagrant. One important benefit I get is more efficient use of machine resources. Running 5-10 fully virtualized Vagrant instances on my laptop hurts. Running the same number of Docker containers is trivial. The ability to version your images and easily build on them is nice too.
- quaunaut 12y ago
  Yes! But using Docker can help several problems: First time provisioning of a box can take up to 30 minutes even with a non-mature app. Mature apps with many moving parts can easily get near an hour- using Docker, you can bring that down to 5 minutes or less, with the majority of that being downloading the containers. Neat thing though, is that you can use Docker WITH Vagrant to do this. The setup I'm doing on my side projects, essentially goes like this: If I'm developing, I use Vagrant to spin up Docker containers(using Docker as the provisioner) for supporting items- databases, memcached, things like elasticsearch or a message queue- then develop from my machine(a mac). If I want to get someone else in on the project, I don't have to care one iota about what they're on, Docker will make it work. On top of that, there's the capability to have your app itself running in Docker containers for development. This means no having to worry about dependencies, environment variables, etc- and if you keep things up to date, you can even just upload your app to a private Docker repo, and use that to deploy to your server(though in a team this may not be the most realistic option at the moment, I've not given it a shot, though I don't see why it wouldn't work). For me, Vagrant is the tool I use to tie everything together for development. Docker is what I have it run off of, instead of Chef/Puppet/Salt/Ansible, so that my build times go from 30 minutes to whatever download speed I get.

by revscat 12y ago

mpdehaan2 12y ago

Run ALL the distributions and versions in prod? :)

vidarh 12y ago
I'd rather have the opportunity to re-test and re-deploy one component at a time than be forced to do "big bang upgrades". In the long run I hope we start seeing distros or tools targeted specifically at building minimal Docker images. E.g. if I'm going to deploy a Ruby based web app in Docker, the stuff I need present in the container is _very_ limited.
PaulHoule 12y ago
No, if your environment is standardized and stripped down you can run something that is very close to prod in your dev environment. Note docker isn't the only answer for this, for instance, you can use ordinary VMs with vagrant, but docker does it at ludicrous speed.
- octix 12y ago
  So, basically to achieve this you need to run production env using docker too? So that docket could match it. Also, production data has to be copied over separately? Are these correct assumptions? PS: I'm still trying to understand how docket/containers may fit in current process.
  - jayfehr 12y ago
    You don't have to, but it would probably be best to keep it consistent. You could run your live server on barebones OS as you normally would, then create a docker image to mirror that. However, as we all know, mirrors often get out of sync fairly quick. But if you use the same image and only update using a Fabric or Ansible script, then you can be pretty certain that all your environments are identical. Not to mention that any newly created environments will brought up to the same point in no time at all.
  - tlrobinson 12y ago
    If you don't want to use Docker in production you could use something like Packer to build Docker base images (http://www.packer.io/docs/builders/docker.html http://www.packer.io/docs/builders/docker.html) and VM images (AMIs, OpenStack, whatever) using the same templates. There would still be some differences, like if the kernel version on your local machine didn't match. Note: I haven't tried this. Maybe it's a bad idea.
- contingencies 12y ago
  if your environment is standardized and stripped down you can run something that is very close to prod in your dev environment. Sounds a lot like FreeBSD's release process, though personally I find that limiting! The problem is of course that 'very close to' is not 'equal to'. My own thoughts in this space are detailed at http://stani.sh/walter/cims/ http://stani.sh/walter/cims/ and http://stani.sh/walter/pfcts/ http://stani.sh/walter/pfcts/

Kiro 12y ago

They keep saying Vagrant and Docker are two different things but isn't that the whole point with Vagrant?

NDizzle 12y ago
Your username is the same as my (jindo) dog! So I'll reply to you. I've been using vagrant to fix exactly the problem of "works on my box" for years. Docker is way too much to explain to my small development team. They struggled to deal with vagrant for some time before figuring it out. Vagrant is perfect for us right now, and it would take a force of nature for me to even begin to push docker on them.
- s_baby 12y ago
  I believe there are plans for offering a Vagrant api to Docker and vice-versa.
revcbh 12y ago
In many cases, Docker can be treated like a more lightweight Vagrant. One important benefit I get is more efficient use of machine resources. Running 5-10 fully virtualized Vagrant instances on my laptop hurts. Running the same number of Docker containers is trivial. The ability to version your images and easily build on them is nice too.
quaunaut 12y ago
Yes! But using Docker can help several problems: First time provisioning of a box can take up to 30 minutes even with a non-mature app. Mature apps with many moving parts can easily get near an hour- using Docker, you can bring that down to 5 minutes or less, with the majority of that being downloading the containers. Neat thing though, is that you can use Docker WITH Vagrant to do this. The setup I'm doing on my side projects, essentially goes like this: If I'm developing, I use Vagrant to spin up Docker containers(using Docker as the provisioner) for supporting items- databases, memcached, things like elasticsearch or a message queue- then develop from my machine(a mac). If I want to get someone else in on the project, I don't have to care one iota about what they're on, Docker will make it work. On top of that, there's the capability to have your app itself running in Docker containers for development. This means no having to worry about dependencies, environment variables, etc- and if you keep things up to date, you can even just upload your app to a private Docker repo, and use that to deploy to your server(though in a team this may not be the most realistic option at the moment, I've not given it a shot, though I don't see why it wouldn't work). For me, Vagrant is the tool I use to tie everything together for development. Docker is what I have it run off of, instead of Chef/Puppet/Salt/Ansible, so that my build times go from 30 minutes to whatever download speed I get.