7 ms·

Is there a very specific use case someone could share so I can visualize what docker really is? Something more than a hello world.

by dpcan 12y ago

jacquesm 12y ago
Let me try: Say you're going to deploy an open source application that requires a whole pile of dependencies. Normally you would have two choices: ship the source with a bunch of readme's and let the recipient figure out how to install your software and all dependencies and to resolve any conflicts with other software already on the machine (aka version hell). Or you could ship a relatively large fully installed VM image of the OS+all the application parts and dependencies (this may be problematic if your target is a licensed OS). Docker gives you something in between. Think of a chroot'd environment (not that that's what it is, but it shares some concepts) with all the application code, libs and dependencies pre-packaged that should run theoretically out of the box. That way you can have a 'war' like file that contains everything required to run your app and you're 100% sure that it will just work, rather than to have to field a million questions about how to make your app run on 'obscure distro x' or 'obsolete version y'. Another use-case would be that if you're deploying something distributed across a large cluster that you can build your docker container on your desktop box, test it until you're happy and then deploy to your cluster without having to re-test everything. Since the container wasn't changed it should work. It's a way of isolating dependencies between various pieces of software using one single container to hold them all. Of course this approach has its own unique set of problems, but it solves certain things quite elegantly. I hope that explains it and that if it is wrong in some aspect that someone will correct me.
- sigil 12y ago
  Normally you would have two choices: ship the source with a bunch of readme's and let the recipient figure out how to install your software and all dependencies and to resolve any conflicts with other software already on the machine (aka version hell). Or you could ship a VM image. Option 3: use a package manager. Now, I realize this doesn't solve the existing software conflict problem you mention. Nor is it mutually exclusive with shipping an image: you could always construct an image by installing packages into it. I've always been a little wary of the "ship a golden image" idea. How do Docker images get updated? What if there's a security issue with software in the Docker image -- can my package manager automatically apply security updates? How do I push other upgrades to the client once they have a Docker instance -- do they need a whole new image from me? Package managers have solved these problems, and I hope we're not reinventing those solutions in the Docker world. If you're familiar with Docker, please enlighten me on these points.
  - justincormack 12y ago
    If your container has a whole OS image in it, then you can run the package manager for that OS to update it. If you just have the application running in the container then you just replace it with an updated container.
  - aidenn0 12y ago
    In many cases, package managers are insufficient to solve the problem. A lot of times they don't handle "Service A must use dependency version X.* but Service B must use version Y.*"
    - vertex-four 12y ago
      I'll point out that Nix, which is used by NixOS but also runs perfectly on other distros, does handle this wonderfully.
  - vezzy-fnord 12y ago
    Option 4: Statically link your binaries. By the way, I do have a basic idea of what Docker is, as well as some inclination with OS-level virtualization (FreeBSD jails and LXC), but OP's example wasn't particularly inspiring.
    - heavenlyhash 12y ago
      This. Or, similarly, just put all your dependencies in a path relative to your executable. Problem solved. I'm an enormous fan of docker for solving linux sysad woes (stacking up magic numbers in /etc/passwd, etc), and it's also great as an asylum for badly designed or badly packaged applications, but let's not forget the utter magic of paths beginning in "./".
  - grosskur 12y ago
    My understanding: If you provide an image then, yes, you're supposed to build a new image every time there's an OS security update. Users of docker containers aren't supposed to run 'apt-get upgrade' themselves inside containers. In fact, people build who build app images on top of base images aren't even supposed to run 'apt-get upgrade' in their Dockerfile---it's the responsibility of the base image to be up-to-date. See: http://crosbymichael.com/dockerfile-best-practices-take-2.html http://crosbymichael.com/dockerfile-best-practices-take-2.ht... This does seem to get a bit cumbersome. I'm at DockerCon today and Fabio Kung mentioned in his talk that this is one difference from Heroku's container platform---they provide the base image and can update it without requiring you to rebuild your application slug. He said there's been some discussion of a possible "docker rebase" command that would produce new images by replacing lower-level layers while keeping higher-level layers the same.
- raquo 12y ago
  So, it's a general-purpose version of python's virtualenv. Neat.
jhorey 12y ago
The comments here do a pretty good job explaining the technical details and common use cases. If, however, you'd like a more narrative-based explanation, you might want to check out my PyData conference presentation (http://bit.ly/1l1PPSe http://bit.ly/1l1PPSe). It's a bit long (about 20 mins), but I try to explain the circumstances in which Docker makes sense.

Is there a very specific use case someone could share so I can visualize what docker really is? Something more than a hello world.

by dpcan 12y ago

Is there a very specific use case someone could share so I can visualize what docker really is? Something more than a hello world.

jacquesm 12y ago

Let me try: Say you're going to deploy an open source application that requires a whole pile of dependencies. Normally you would have two choices: ship the source with a bunch of readme's and let the recipient figure out how to install your software and all dependencies and to resolve any conflicts with other software already on the machine (aka version hell). Or you could ship a relatively large fully installed VM image of the OS+all the application parts and dependencies (this may be problematic if your target is a licensed OS). Docker gives you something in between. Think of a chroot'd environment (not that that's what it is, but it shares some concepts) with all the application code, libs and dependencies pre-packaged that should run theoretically out of the box. That way you can have a 'war' like file that contains everything required to run your app and you're 100% sure that it will just work, rather than to have to field a million questions about how to make your app run on 'obscure distro x' or 'obsolete version y'. Another use-case would be that if you're deploying something distributed across a large cluster that you can build your docker container on your desktop box, test it until you're happy and then deploy to your cluster without having to re-test everything. Since the container wasn't changed it should work. It's a way of isolating dependencies between various pieces of software using one single container to hold them all. Of course this approach has its own unique set of problems, but it solves certain things quite elegantly. I hope that explains it and that if it is wrong in some aspect that someone will correct me.

sigil 12y ago
Normally you would have two choices: ship the source with a bunch of readme's and let the recipient figure out how to install your software and all dependencies and to resolve any conflicts with other software already on the machine (aka version hell). Or you could ship a VM image. Option 3: use a package manager. Now, I realize this doesn't solve the existing software conflict problem you mention. Nor is it mutually exclusive with shipping an image: you could always construct an image by installing packages into it. I've always been a little wary of the "ship a golden image" idea. How do Docker images get updated? What if there's a security issue with software in the Docker image -- can my package manager automatically apply security updates? How do I push other upgrades to the client once they have a Docker instance -- do they need a whole new image from me? Package managers have solved these problems, and I hope we're not reinventing those solutions in the Docker world. If you're familiar with Docker, please enlighten me on these points.
- justincormack 12y ago
  If your container has a whole OS image in it, then you can run the package manager for that OS to update it. If you just have the application running in the container then you just replace it with an updated container.
- aidenn0 12y ago
  In many cases, package managers are insufficient to solve the problem. A lot of times they don't handle "Service A must use dependency version X.* but Service B must use version Y.*"
  - vertex-four 12y ago
    I'll point out that Nix, which is used by NixOS but also runs perfectly on other distros, does handle this wonderfully.
- vezzy-fnord 12y ago
  Option 4: Statically link your binaries. By the way, I do have a basic idea of what Docker is, as well as some inclination with OS-level virtualization (FreeBSD jails and LXC), but OP's example wasn't particularly inspiring.
  - heavenlyhash 12y ago
    This. Or, similarly, just put all your dependencies in a path relative to your executable. Problem solved. I'm an enormous fan of docker for solving linux sysad woes (stacking up magic numbers in /etc/passwd, etc), and it's also great as an asylum for badly designed or badly packaged applications, but let's not forget the utter magic of paths beginning in "./".
- grosskur 12y ago
  My understanding: If you provide an image then, yes, you're supposed to build a new image every time there's an OS security update. Users of docker containers aren't supposed to run 'apt-get upgrade' themselves inside containers. In fact, people build who build app images on top of base images aren't even supposed to run 'apt-get upgrade' in their Dockerfile---it's the responsibility of the base image to be up-to-date. See: http://crosbymichael.com/dockerfile-best-practices-take-2.html http://crosbymichael.com/dockerfile-best-practices-take-2.ht... This does seem to get a bit cumbersome. I'm at DockerCon today and Fabio Kung mentioned in his talk that this is one difference from Heroku's container platform---they provide the base image and can update it without requiring you to rebuild your application slug. He said there's been some discussion of a possible "docker rebase" command that would produce new images by replacing lower-level layers while keeping higher-level layers the same.
raquo 12y ago
So, it's a general-purpose version of python's virtualenv. Neat.

jhorey 12y ago

The comments here do a pretty good job explaining the technical details and common use cases. If, however, you'd like a more narrative-based explanation, you might want to check out my PyData conference presentation (http://bit.ly/1l1PPSe http://bit.ly/1l1PPSe). It's a bit long (about 20 mins), but I try to explain the circumstances in which Docker makes sense.