9 ms·

How is this different from what you can already do with lxc on, for example, Ubuntu Server?

by rlpb 14y ago

derefr 14y ago
It's not that it's any different, it's that it's standardized. The idea is that a Docker container would be portable between different PaaS hosts (and from your own staging environment to those hosts!) without rebuilding, because they'd all be using the "Docker standard for deployment." A PaaS host saying they supported Docker would imply that they'd be using, for example, SquashFS for container format, AuFS instead of OverlayFS for union-mounts, LXC instead of OpenVZ/Xen/KVM for isolation, and any other set of things your container might subtly rely upon. The culmination of this, I imagine, would be a PaaS host allowing you to specify the "stuff" you want to run just by the URL of the container-image.
- shykes 14y ago
  Correct. Docker is the direct result of dotCloud's experience running hundreds of thousands of containers in production over the last 2 years. We tried very hard to put it in a form factor which makes it useful beyond the traditional PaaS. We think Docker's API is a fundamental building block for running any process on the server.
- batgaijin 14y ago
  What about virtsandbox from fedora? how does this project overlap with that? can this handle certain situations better?
- peterwwillis 14y ago
  Doesn't a standard involve, you know, standards? AFAIK a product name is not a standard. What if the namespace changes? What if AuFS changes? What if LXC changes? Independently or all together? ABI changes? Version changes? Feature changes? Are all the licenses compatible? Will it ever support platforms other than just certain versions of Linux? Or languages other than Go? I don't see a standard. I see marketing for a product and a mailing list to collect potential customers. But maybe i'm missing something.
  - derefr 14y ago
    I'm just presuming, but: 1. every one of those attributes would be fixed against a given version of the (coming) Docker spec, and a given host would specify what version(s) of the spec they were compatible with. 2. Go is, I think, just the language the glue code is written in; not the language your own things-deployed-using-Docker must be written in. 3. It might support other Linux distros (Fedora, probably), but it won't support other OSes as hosts--because the whole point is to run things that need a POSIX-alike as their "outer runtime" (i.e. not Windows programs, etc.) The way to run these containers on another host will be to run Linux in a VM on that host, and run the containers in the VM--just like the way to play a Super Nintendo game "container" on your computer is to run them in a Super Nintendo VM. [Actually, come to think of it, game ROMs are a great analogy for precompiled SquashFS containers. I would adopt it if I were them :)]
    - peterwwillis 14y ago
      The trick here is that their xmame (Docker) may not be the same build on all hosts, so it may not play the ROMs all in the same way or support all ROMs. A standard works to improve interoperability between different builds/hosts/etc as well as provide an expected set of operations and their results. If all they provide is just one version of one product and call that standardized, that's like releasing a new version of Internet Explorer and calling it a web standard.
      - derefr 14y ago
        Well, this is a good first step in the "free market" standardization process, though: get a public implementation out of what you would imagine standard-conformance to look like. Then, let the other guys (e.g. Heroku) get out their competing implementations. Then, find the similarities, resolve the differences, and write it down. Now you've got a standard.
        peterwwillis 14y ago
        In practice that does not work. Things get broken, people end up having to support 20 edge cases to use this "universal", "standardized" thing. Depends on the implementation, though.
- rlpb 14y ago
  So why not use VM images? Why not a VMware vagrant box, for example?
  - derefr 14y ago
    This might work if you only have to run three or four VMs on a box, and run several applications in each container. Full PC virtual machines are much too heavyweight, though, for isolating thousands of individual processes per box, especially when most of them might just sit there doing nothing most of the time. Though! If you want to, you can think of this standard as specifying an "ABI format" for high-level, lightweight VMs that happens to run on a "Linux machine" instead of, say, an "IA32 machine."
  - niall_ohiggins 14y ago
    One major benefit over VM images is Linux Containers have very fast spin-up time. This can be especially useful for PaaS providers and CI servers.
    - shykes 14y ago
      Other benefits: docker images are basically tarballs, which means they are much smaller. And, importantly, Docker maintains a filesystem-level diff between versions of an image, and only needs to transmit each diff once. So you get tremendous bandwidth savings when transmitting multiple images created from the same base.
    - emidln 14y ago
      If your images use kvm+qcow2 you can just spin up new vms as a delta image using qcow2's support for a backing store. I want a new instance of WEBSERVER.qcow2? qemu-img create -b WEBSERVER.qcow2 -t qcow2 WEBSERVER-$SERIALNUMBER.qcow2 If you're doing this as a PaaS or for CI, you do this as part of your new image creation and then pass in the new qcow2 to your vm (maybe via libvirt). If you aren't doing this or something very similar, you're spinning your wheels and wasting time/resources.

How is this different from what you can already do with lxc on, for example, Ubuntu Server?

by rlpb 14y ago

How is this different from what you can already do with lxc on, for example, Ubuntu Server?

It's not that it's any different, it's that it's standardized. The idea is that a Docker container would be portable between different PaaS hosts (and from your own staging environment to those hosts!) without rebuilding, because they'd all be using the "Docker standard for deployment." A PaaS host saying they supported Docker would imply that they'd be using, for example, SquashFS for container format, AuFS instead of OverlayFS for union-mounts, LXC instead of OpenVZ/Xen/KVM for isolation, and any other set of things your container might subtly rely upon. The culmination of this, I imagine, would be a PaaS host allowing you to specify the "stuff" you want to run just by the URL of the container-image.

shykes 14y ago
Correct. Docker is the direct result of dotCloud's experience running hundreds of thousands of containers in production over the last 2 years. We tried very hard to put it in a form factor which makes it useful beyond the traditional PaaS. We think Docker's API is a fundamental building block for running any process on the server.
batgaijin 14y ago
What about virtsandbox from fedora? how does this project overlap with that? can this handle certain situations better?
peterwwillis 14y ago
Doesn't a standard involve, you know, standards? AFAIK a product name is not a standard. What if the namespace changes? What if AuFS changes? What if LXC changes? Independently or all together? ABI changes? Version changes? Feature changes? Are all the licenses compatible? Will it ever support platforms other than just certain versions of Linux? Or languages other than Go? I don't see a standard. I see marketing for a product and a mailing list to collect potential customers. But maybe i'm missing something.
- derefr 14y ago
  I'm just presuming, but: 1. every one of those attributes would be fixed against a given version of the (coming) Docker spec, and a given host would specify what version(s) of the spec they were compatible with. 2. Go is, I think, just the language the glue code is written in; not the language your own things-deployed-using-Docker must be written in. 3. It might support other Linux distros (Fedora, probably), but it won't support other OSes as hosts--because the whole point is to run things that need a POSIX-alike as their "outer runtime" (i.e. not Windows programs, etc.) The way to run these containers on another host will be to run Linux in a VM on that host, and run the containers in the VM--just like the way to play a Super Nintendo game "container" on your computer is to run them in a Super Nintendo VM. [Actually, come to think of it, game ROMs are a great analogy for precompiled SquashFS containers. I would adopt it if I were them :)]
  - peterwwillis 14y ago
    The trick here is that their xmame (Docker) may not be the same build on all hosts, so it may not play the ROMs all in the same way or support all ROMs. A standard works to improve interoperability between different builds/hosts/etc as well as provide an expected set of operations and their results. If all they provide is just one version of one product and call that standardized, that's like releasing a new version of Internet Explorer and calling it a web standard.
    - derefr 14y ago
      Well, this is a good first step in the "free market" standardization process, though: get a public implementation out of what you would imagine standard-conformance to look like. Then, let the other guys (e.g. Heroku) get out their competing implementations. Then, find the similarities, resolve the differences, and write it down. Now you've got a standard.
      - peterwwillis 14y ago
        In practice that does not work. Things get broken, people end up having to support 20 edge cases to use this "universal", "standardized" thing. Depends on the implementation, though.
rlpb 14y ago
So why not use VM images? Why not a VMware vagrant box, for example?
- derefr 14y ago
  This might work if you only have to run three or four VMs on a box, and run several applications in each container. Full PC virtual machines are much too heavyweight, though, for isolating thousands of individual processes per box, especially when most of them might just sit there doing nothing most of the time. Though! If you want to, you can think of this standard as specifying an "ABI format" for high-level, lightweight VMs that happens to run on a "Linux machine" instead of, say, an "IA32 machine."
- niall_ohiggins 14y ago
  One major benefit over VM images is Linux Containers have very fast spin-up time. This can be especially useful for PaaS providers and CI servers.
  - shykes 14y ago
    Other benefits: docker images are basically tarballs, which means they are much smaller. And, importantly, Docker maintains a filesystem-level diff between versions of an image, and only needs to transmit each diff once. So you get tremendous bandwidth savings when transmitting multiple images created from the same base.
  - emidln 14y ago
    If your images use kvm+qcow2 you can just spin up new vms as a delta image using qcow2's support for a backing store. I want a new instance of WEBSERVER.qcow2? qemu-img create -b WEBSERVER.qcow2 -t qcow2 WEBSERVER-$SERIALNUMBER.qcow2 If you're doing this as a PaaS or for CI, you do this as part of your new image creation and then pass in the new qcow2 to your vm (maybe via libvirt). If you aren't doing this or something very similar, you're spinning your wheels and wasting time/resources.