6 ms·

Why is Docker the new craze in virtualization and cloud computing?

78 points by jhibbets 12y ago

jhibbets 12y ago
My favorite quote from the article/interview: "Its mission is basically: make it easy to package and ship code"
j45 12y ago
Docker to me makes things an order of magnitude (or two) easier than previously possible. In time these additional layers will be as central as virtualization itself was in arriving with VMware.
emeraldd 12y ago
I'm just start to play with Docker, it seems like a nice way to build out contained systems that you don't want to change much ... but feels like it could lead to problems when it comes time to do updates to software inside the container. It feels like Docker offloads alot of responsibility for security updates from the ops to people in development. Or am I missing something ...
- chc 12y ago
  When you want to do updates, you can just replace the old container with a new one reflecting the updates.
  - Leynos 12y ago
    The conceptual leap that I missed initially is the use of volumes, either mapped to data containers or to directories on the host system. These allow the persistent data used by the application in the container to live on, and for the container itself to be seen as immutable and easily replaceable.
- vidarh 12y ago
  It forces co-operation. As someone doing ops, and with years and years of development: ops teams should not do software upgrades without cooperating with developers and re-testing the full stack anyway. The odds of seemingly "safe" OS upgrades breaking applications are often high. If used properly Docker enforces pushing those upgrades back up the pipeline as far as they should.
  - shykes 12y ago
    That's exactly right. Upgrades should be higher up in the process and involve the development and testing team. It doesn't mean the same people who run production can't also participate and offer guidance in the upgrade process upstream.
- nubs 12y ago
  Docker provides more flexibility. So while you can have developers managing security updates that is definitely not the only way of handling things. I see a process where ops are responsible for the base images (base os images, and layers for different software stacks) and can handle security updates at will. Developers can maintain small dockerfiles that just install their application on top of the ops-managed image. ops can then be in charge of building (and re-building) the images and deploying them. Of course, that can all be fine-tuned to your liking.
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.
      - 12y ago
ForHackernews 12y ago
Docker is great because it allows you to avoid simulating an entire virtual machine. Think how ridiculous it is that in many cases today we run an entire simulated computer, with a full general-purpose operating system, just to power a single application (e.g. web server, database, etc).
- crdoconnor 12y ago
  Why is it so ridiculous? It's pretty cheap these days.
  - adeptus 12y ago
    It's not ridiculous at all, given production deployments need segmentation to maximize security. Docket may be fine for Dev environments with no real customer data being used, but to deploy to production if you use Docker, you will get shot... by the security guys.
    - yebyen 12y ago
      I don't know about this, if you are following best practices and then add "with docker" you don't really change anything for the worse. There's just a whole new layer of best practices with docker that you have to learn, namely single-process container ideas and volume/image separation. If you're using Docker in development and then not using it in production, I hope you're using chef too, or something like it. The point to me is embracing the whole idea of "replaceable, reusable, disposable" components and DRY. If you're repeating by hand any complex steps in production that you also did in your development environment; never mind the time wasted, you now have twice as many chances to make mistakes.
  - _dark_matter_ 12y ago
    There are plenty of wasted resources. Virtualization itself incurs a 30% overhead.
    - csixty4 12y ago
wfjackson 12y ago
It's nice to have logically independent code bases on separate environments just so that they don't step over each other toes with dependencies etc. and can be moved around easily.
octix 12y ago
I don't understand the part with scaling with containers on the same host. I mean if it's the same host, what kind of scaling is it?
- scott_karana 12y ago
  Yeah, I have some guesses but if anyone here can clear that up, I'd appreciate it.
- kilburn 12y ago
  The scaling part is generally about running and managing multiple containers on multiple machines. In that sense, the advantage of going from virtualization to containerization is the same as going from bare-metal to virtualization: better computation density and more agile deployments. On the one hand, containers are more efficient than virtual machines. Hence, you get more efficient usage of your hardware. Also, you can pack more containers in a given host than if you use virtualization. Net result: less hardware to run the same services. In turn, this also readuces the network load because the more services in the same machine, the less traffic on your network and better latencies between colocated services. On the other hand, containers (as envisioned by docker) are much faster to deploy. You build images which are compositions of layers. You have a base layer containing the base OS, and then a "stack" layer containing your application stack, and finally your app on another layer. An image is a consolidated view of all these layers, but the layers can be fetched and managed independently. Hence, you can deploy containers much faster (no need to re-download every layer each time you want to deploy a new service). Additionally, they build faster and they launch faster (nearly as fast as a non-containerized application). This allows you to do even cooler things such as socket-activated containers, which would be painful with the startup times of virtual machines. Obviously, this blends very well with the idea of building applications in terms of distributed services (or components or whatever). As a result, there are multiple projects pushing for "cluster-aware" (replicated, varying levels of consistency) services. People from the virtualization camp was already pushing for that, but now it is even more important because containers are leaner and cheaper to deploy.
  - octix 12y ago
fideloper 12y ago
> Docker is operating system level virtualization. Unlike hypervisor virtualization, where virtual machines run on physical hardware via an intermediation layer ("the hypervisor"), containers instead run user space on top of an operating system's kernel. That makes them very lightweight and very fast. This is one of the best explanations of Docker I've read. (Altho I suppose it requires knowing what Hypervisor is, if just at a topical level...perhaps the same for a "kernel")
- evol262 12y ago
  Except that this also describes vserver, lxc, solaris zones, freebsd jails, and numerous other container virtualization solutions. Docker is best described as application virtualization.
  - Kiro 12y ago
    And we're back to square 1. What does application mean in this context? I have a really hard time figuring out what Docker really is.
    - evol262 12y ago
      Docker was a wrapper around lxc which ran an executable as PID1. Docker is now a wrapper around libcontainer which runs an executable as PID1, with a build system for those containers (Dockerfiles) and support for features exposed by libcontainer (ports, bind mounts, etc). The use case of "operating system level virtualization" is "I'm already running Linux, Solaris, BSD, AIX, or whatever, but I want to run another copy on top of it in order to segment off my clients/webserver/business unit/whatever". There's an implication that there'll be a real init as PID1, you may want to run sshd or another access point to let users in, and it's a "pet" in the pets v. cattle parlance. The use case of Docker is "I built my application with this set of libraries on top of Ubuntu, but I want to deploy it alongside applications with different versions of libraries (also on Ubuntu or RHEL or whatever), and my application is the only thing that'll be running". Remember when you got tarballs to unpack in /opt/${application} which came with start scripts which started with "export LD_LIBRARY_PATH='/opt/oracle/lib'"? Docker does that in a modern way. It can also do more than that with etcd, fleet, haproxy, and bits tacked on top to shuffle containers around, but that's the core of docker. You, the developer, ship your application along with all the libraries it needs and it runs in a container on top of Ubuntu but it's using RHEL glibc/libwhatever without starting logind and all the other services associated with RHEL.
bithush 12y ago
Because Docker just makes more sense. Why should I run multiple versions of the whole OS for near-to-identical setups? That is just a waste of resources. Docker makes much more sense when you have multiple applications you want in separate instances on the same stack. There benefits far outweigh the disadvantages in my experience.
- octix 12y ago
  Yes, I can see a great deal of benefits for development part, _if_ you're sticking with the same OS. Currently I have a bunch VMs (using kvm/qemu + libvirt) that are created and dropped as needed. The biggest advantages I see is that I can create a near identical environment with our VPSs... + I can test different OSs too (Linuxe vs *BSD). My current pain point is the hdd space, since I have to resize VMs storage when needed. Even though it was automated, but still I'd prefer to use some shared hdd space and not to worry about it.
jokoon 12y ago
can it help game developers ?
- quaunaut 12y ago
  Probably not at current. Most game developers, for one, develop for Windows. Even if you are developing for Linux, this would only really help if you were exclusively Linux.
CSDude 12y ago
I'm using Docker as different than most people intended: To grade student programming assignments on different physical machines. And I can distribute the docker images to students, so they stop complaining "But it works on my machine". So it is a different usage of packaging and shipping code.
- fideloper 12y ago
  Sort of - the 'works on my machine' issue is definitely something Docker helps with in DevOps settings too.
- tlrobinson 12y ago
  IMHO every open source project should come with either a Vagrantfile or Dockerfile, if only to allow potential users to quickly try out the project in a known good environment. Of course then you risk developers of libraries/tools only developing/testing against that particular environment, but that could be solved by having a variety of Docker/Vagrantfiles integrated with a CI system.
  - justincormack 12y ago
    That is very fragile, you want to make sure your code is not that dependent on a very specific environment really.
    - tlrobinson 12y ago
      Yes, hence the second sentence: "Of course then you risk developers of libraries/tools only developing/testing against that particular environment, but that could be solved by having a variety of Docker/Vagrantfiles integrated with a CI system."
jaequery 12y ago
After having used many years of virtualization stacks (openvz, xen, vmware, kvm), I believe using docker on production is still quite tricky, if not very tricky. Especially for larger apps, at the very moment it's like juggling eggshells. It requires a great deal of orchestration as you gradually involve many docker instances and especially when the host is involved (volumes, links). So yeah , I wouldn't call it actual "containerizing" the app and it's more like containerizing "processes". I for one would love to see a day where openvz gets docker-like cli and having repository for creating/pushing/pulling images.
JoshTriplett 12y ago
Containers are the new craze, because they're much lighter-weight and easier to deploy than full-system virtual machines. Docker is simply a convenient approach to container distribution and deployment, designed to package up an application as a self-contained invokable container.
- Svenstaro 12y ago
  Excuse me, but isn't this essentially chroots reinvented?
  - VLM 12y ago
    That is exactly it, with a couple more isolation features added. So more than just the FS but also some memory / cpu limiting and general sandboxing. Interestingly most "real virtualization" requires somewhat recent hardware but LXC containers don't take much if any, so "free machine off junk heap" is good enough for experimentation. Historically there have been strange intercontainer isolation problems so don't assume its as perfect as hardware assisted virtualization. Also you're sharing a kernel which is both good and bad, if you were hoping to test out a new kernel or run an entirely different OS, thats too bad. Edited to add, another fun analogy if you like the chroot analogy, is when spinning up a process was glacial on windows (but not too bad on linux) that lead to the development and push to use threads which were a huge win on slow windows not so much on linux but we got dragged along anyway. In a similar manner, full virtualization is really slow to deploy and spin up and spin down, containers are smaller and weaker but much like threads vs processes are much faster to start up or shutdown. A really low latency or fast spinup spindown virtualization tech would probably wipe most demand for containerization. Or what I'm getting at is, spawning processes on windows was super slow, so we got threads, and spawning full hardware virt is slow, so we get containerization aka chroot++
    - Svenstaro 12y ago
      Alright, thanks a lot for the explanation then! Then my concept wasn't entirely wrong.
octix 12y ago
Every time I see a post like this, I see lots of folks are super exited, but I still fail to see benefits, perhaps is the nature of my/our architecture/setup. So, let's say I have a fairly typical setup, 1 web app, 1 database. Normally I would have 2 VM instances to start with. When I need to scale I add more nodes for web and/or db... both are load balanced, of course. How would docker help me? I guess I should google for docker use cases, but I thought I'll try my luck here too. Test/dev environments are pretty close to production ones. It seems there is a lot of hype, but I fail to see it through. I'm wondering if all this hype is artificial, time will tell of course. Thanks.

78 points by jhibbets 12y ago

My favorite quote from the article/interview: "Its mission is basically: make it easy to package and ship code"

j45 12y ago

Docker to me makes things an order of magnitude (or two) easier than previously possible. In time these additional layers will be as central as virtualization itself was in arriving with VMware.

emeraldd 12y ago

I'm just start to play with Docker, it seems like a nice way to build out contained systems that you don't want to change much ... but feels like it could lead to problems when it comes time to do updates to software inside the container. It feels like Docker offloads alot of responsibility for security updates from the ops to people in development. Or am I missing something ...

chc 12y ago
When you want to do updates, you can just replace the old container with a new one reflecting the updates.
- Leynos 12y ago
  The conceptual leap that I missed initially is the use of volumes, either mapped to data containers or to directories on the host system. These allow the persistent data used by the application in the container to live on, and for the container itself to be seen as immutable and easily replaceable.
vidarh 12y ago
It forces co-operation. As someone doing ops, and with years and years of development: ops teams should not do software upgrades without cooperating with developers and re-testing the full stack anyway. The odds of seemingly "safe" OS upgrades breaking applications are often high. If used properly Docker enforces pushing those upgrades back up the pipeline as far as they should.
- shykes 12y ago
  That's exactly right. Upgrades should be higher up in the process and involve the development and testing team. It doesn't mean the same people who run production can't also participate and offer guidance in the upgrade process upstream.
nubs 12y ago
Docker provides more flexibility. So while you can have developers managing security updates that is definitely not the only way of handling things. I see a process where ops are responsible for the base images (base os images, and layers for different software stacks) and can handle security updates at will. Developers can maintain small dockerfiles that just install their application on top of the ops-managed image. ops can then be in charge of building (and re-building) the images and deploying them. Of course, that can all be fine-tuned to your liking.

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.
    - 12y ago

ForHackernews 12y ago

Docker is great because it allows you to avoid simulating an entire virtual machine. Think how ridiculous it is that in many cases today we run an entire simulated computer, with a full general-purpose operating system, just to power a single application (e.g. web server, database, etc).

crdoconnor 12y ago
Why is it so ridiculous? It's pretty cheap these days.
- adeptus 12y ago
  It's not ridiculous at all, given production deployments need segmentation to maximize security. Docket may be fine for Dev environments with no real customer data being used, but to deploy to production if you use Docker, you will get shot... by the security guys.
  - yebyen 12y ago
    I don't know about this, if you are following best practices and then add "with docker" you don't really change anything for the worse. There's just a whole new layer of best practices with docker that you have to learn, namely single-process container ideas and volume/image separation. If you're using Docker in development and then not using it in production, I hope you're using chef too, or something like it. The point to me is embracing the whole idea of "replaceable, reusable, disposable" components and DRY. If you're repeating by hand any complex steps in production that you also did in your development environment; never mind the time wasted, you now have twice as many chances to make mistakes.
- _dark_matter_ 12y ago
  There are plenty of wasted resources. Virtualization itself incurs a 30% overhead.
  - csixty4 12y ago

wfjackson 12y ago

It's nice to have logically independent code bases on separate environments just so that they don't step over each other toes with dependencies etc. and can be moved around easily.

octix 12y ago

I don't understand the part with scaling with containers on the same host. I mean if it's the same host, what kind of scaling is it?

scott_karana 12y ago
Yeah, I have some guesses but if anyone here can clear that up, I'd appreciate it.
kilburn 12y ago
The scaling part is generally about running and managing multiple containers on multiple machines. In that sense, the advantage of going from virtualization to containerization is the same as going from bare-metal to virtualization: better computation density and more agile deployments. On the one hand, containers are more efficient than virtual machines. Hence, you get more efficient usage of your hardware. Also, you can pack more containers in a given host than if you use virtualization. Net result: less hardware to run the same services. In turn, this also readuces the network load because the more services in the same machine, the less traffic on your network and better latencies between colocated services. On the other hand, containers (as envisioned by docker) are much faster to deploy. You build images which are compositions of layers. You have a base layer containing the base OS, and then a "stack" layer containing your application stack, and finally your app on another layer. An image is a consolidated view of all these layers, but the layers can be fetched and managed independently. Hence, you can deploy containers much faster (no need to re-download every layer each time you want to deploy a new service). Additionally, they build faster and they launch faster (nearly as fast as a non-containerized application). This allows you to do even cooler things such as socket-activated containers, which would be painful with the startup times of virtual machines. Obviously, this blends very well with the idea of building applications in terms of distributed services (or components or whatever). As a result, there are multiple projects pushing for "cluster-aware" (replicated, varying levels of consistency) services. People from the virtualization camp was already pushing for that, but now it is even more important because containers are leaner and cheaper to deploy.
- octix 12y ago

fideloper 12y ago

> Docker is operating system level virtualization. Unlike hypervisor virtualization, where virtual machines run on physical hardware via an intermediation layer ("the hypervisor"), containers instead run user space on top of an operating system's kernel. That makes them very lightweight and very fast. This is one of the best explanations of Docker I've read. (Altho I suppose it requires knowing what Hypervisor is, if just at a topical level...perhaps the same for a "kernel")

evol262 12y ago
Except that this also describes vserver, lxc, solaris zones, freebsd jails, and numerous other container virtualization solutions. Docker is best described as application virtualization.
- Kiro 12y ago
  And we're back to square 1. What does application mean in this context? I have a really hard time figuring out what Docker really is.
  - evol262 12y ago
    Docker was a wrapper around lxc which ran an executable as PID1. Docker is now a wrapper around libcontainer which runs an executable as PID1, with a build system for those containers (Dockerfiles) and support for features exposed by libcontainer (ports, bind mounts, etc). The use case of "operating system level virtualization" is "I'm already running Linux, Solaris, BSD, AIX, or whatever, but I want to run another copy on top of it in order to segment off my clients/webserver/business unit/whatever". There's an implication that there'll be a real init as PID1, you may want to run sshd or another access point to let users in, and it's a "pet" in the pets v. cattle parlance. The use case of Docker is "I built my application with this set of libraries on top of Ubuntu, but I want to deploy it alongside applications with different versions of libraries (also on Ubuntu or RHEL or whatever), and my application is the only thing that'll be running". Remember when you got tarballs to unpack in /opt/${application} which came with start scripts which started with "export LD_LIBRARY_PATH='/opt/oracle/lib'"? Docker does that in a modern way. It can also do more than that with etcd, fleet, haproxy, and bits tacked on top to shuffle containers around, but that's the core of docker. You, the developer, ship your application along with all the libraries it needs and it runs in a container on top of Ubuntu but it's using RHEL glibc/libwhatever without starting logind and all the other services associated with RHEL.

bithush 12y ago

Because Docker just makes more sense. Why should I run multiple versions of the whole OS for near-to-identical setups? That is just a waste of resources. Docker makes much more sense when you have multiple applications you want in separate instances on the same stack. There benefits far outweigh the disadvantages in my experience.

octix 12y ago
Yes, I can see a great deal of benefits for development part, _if_ you're sticking with the same OS. Currently I have a bunch VMs (using kvm/qemu + libvirt) that are created and dropped as needed. The biggest advantages I see is that I can create a near identical environment with our VPSs... + I can test different OSs too (Linuxe vs *BSD). My current pain point is the hdd space, since I have to resize VMs storage when needed. Even though it was automated, but still I'd prefer to use some shared hdd space and not to worry about it.

jokoon 12y ago

can it help game developers ?

quaunaut 12y ago
Probably not at current. Most game developers, for one, develop for Windows. Even if you are developing for Linux, this would only really help if you were exclusively Linux.

CSDude 12y ago

I'm using Docker as different than most people intended: To grade student programming assignments on different physical machines. And I can distribute the docker images to students, so they stop complaining "But it works on my machine". So it is a different usage of packaging and shipping code.

fideloper 12y ago
Sort of - the 'works on my machine' issue is definitely something Docker helps with in DevOps settings too.
tlrobinson 12y ago
IMHO every open source project should come with either a Vagrantfile or Dockerfile, if only to allow potential users to quickly try out the project in a known good environment. Of course then you risk developers of libraries/tools only developing/testing against that particular environment, but that could be solved by having a variety of Docker/Vagrantfiles integrated with a CI system.
- justincormack 12y ago
  That is very fragile, you want to make sure your code is not that dependent on a very specific environment really.
  - tlrobinson 12y ago
    Yes, hence the second sentence: "Of course then you risk developers of libraries/tools only developing/testing against that particular environment, but that could be solved by having a variety of Docker/Vagrantfiles integrated with a CI system."

jaequery 12y ago

After having used many years of virtualization stacks (openvz, xen, vmware, kvm), I believe using docker on production is still quite tricky, if not very tricky. Especially for larger apps, at the very moment it's like juggling eggshells. It requires a great deal of orchestration as you gradually involve many docker instances and especially when the host is involved (volumes, links). So yeah , I wouldn't call it actual "containerizing" the app and it's more like containerizing "processes". I for one would love to see a day where openvz gets docker-like cli and having repository for creating/pushing/pulling images.

JoshTriplett 12y ago

Containers are the new craze, because they're much lighter-weight and easier to deploy than full-system virtual machines. Docker is simply a convenient approach to container distribution and deployment, designed to package up an application as a self-contained invokable container.

Svenstaro 12y ago
Excuse me, but isn't this essentially chroots reinvented?
- VLM 12y ago
  That is exactly it, with a couple more isolation features added. So more than just the FS but also some memory / cpu limiting and general sandboxing. Interestingly most "real virtualization" requires somewhat recent hardware but LXC containers don't take much if any, so "free machine off junk heap" is good enough for experimentation. Historically there have been strange intercontainer isolation problems so don't assume its as perfect as hardware assisted virtualization. Also you're sharing a kernel which is both good and bad, if you were hoping to test out a new kernel or run an entirely different OS, thats too bad. Edited to add, another fun analogy if you like the chroot analogy, is when spinning up a process was glacial on windows (but not too bad on linux) that lead to the development and push to use threads which were a huge win on slow windows not so much on linux but we got dragged along anyway. In a similar manner, full virtualization is really slow to deploy and spin up and spin down, containers are smaller and weaker but much like threads vs processes are much faster to start up or shutdown. A really low latency or fast spinup spindown virtualization tech would probably wipe most demand for containerization. Or what I'm getting at is, spawning processes on windows was super slow, so we got threads, and spawning full hardware virt is slow, so we get containerization aka chroot++
  - Svenstaro 12y ago
    Alright, thanks a lot for the explanation then! Then my concept wasn't entirely wrong.

octix 12y ago

Every time I see a post like this, I see lots of folks are super exited, but I still fail to see benefits, perhaps is the nature of my/our architecture/setup. So, let's say I have a fairly typical setup, 1 web app, 1 database. Normally I would have 2 VM instances to start with. When I need to scale I add more nodes for web and/or db... both are load balanced, of course. How would docker help me? I guess I should google for docker use cases, but I thought I'll try my luck here too. Test/dev environments are pretty close to production ones. It seems there is a lot of hype, but I fail to see it through. I'm wondering if all this hype is artificial, time will tell of course. Thanks.