6 ms·

> Docker is operating system level virtualization. Unlike hypervisor virtualization, where virtual machines run on physical hardware via an intermediation layer

> 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.
    - cma 12y ago
      chroot + buzzwords (but it does ultimately have a legitimately simpler interface/workflow)
      - evol262 12y ago
        Sort of yes, sort of no. I also agree that Docker is incredibly buzzwordy and that most of the bullshit and hype around Docker could be done with other tools But the libcontainer networking stuff and integration with cgroups does provide more segmentation than chroots, and the networking parts are nice. Granted, I think the best possible use case for Docker is in shipping fat apps (ala OSX or Windows) so Spotify for Linux can run on anything that supports Docker instead of anything which supports dpkg, but eh.
        quesera 12y ago
        For me, Docker brings to mind the Henry Spencer quote, originally implicating Microsoft, that "Those who don't understand Unix are condemned to reinvent it"[1]. I totally understand the enthusiasm around OS containers. I forget sometimes that this is a new thing on Linux. Running Solaris and FreeBSD is like living in the future! [1] The full quote ends "...poorly", but Docker seems to done well-enough, just rather late to the party.
        evol262 12y ago
        But it isn't a new thing on Linux. lxc, vserver, openvz, and other projects also do what zones and jails do. Docker is not the same.
        quesera 12y ago
        That's fair, I was writing imprecisely. The functionality has existed (at least primitively) on Linux for some time, but culturally Linux admins have been more drawn to HW level virtualization instead. OS-level virtualization has been a part of the FreeBSD and Solaris cultures for much longer. Another fair argument is that Docker does such a good job at abstracting the configuration and management of OS-level virtualization that it truly changes things. Maybe. But if that's true, it means that Linux admins have ignored this hugely useful technology because it was hidden behind an impenetrable wall of text-based configuration.

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.
  - cma 12y ago
    chroot + buzzwords (but it does ultimately have a legitimately simpler interface/workflow)
    - evol262 12y ago
      Sort of yes, sort of no. I also agree that Docker is incredibly buzzwordy and that most of the bullshit and hype around Docker could be done with other tools But the libcontainer networking stuff and integration with cgroups does provide more segmentation than chroots, and the networking parts are nice. Granted, I think the best possible use case for Docker is in shipping fat apps (ala OSX or Windows) so Spotify for Linux can run on anything that supports Docker instead of anything which supports dpkg, but eh.
      - quesera 12y ago
        For me, Docker brings to mind the Henry Spencer quote, originally implicating Microsoft, that "Those who don't understand Unix are condemned to reinvent it"[1]. I totally understand the enthusiasm around OS containers. I forget sometimes that this is a new thing on Linux. Running Solaris and FreeBSD is like living in the future! [1] The full quote ends "...poorly", but Docker seems to done well-enough, just rather late to the party.
        evol262 12y ago
        But it isn't a new thing on Linux. lxc, vserver, openvz, and other projects also do what zones and jails do. Docker is not the same.
        quesera 12y ago
        That's fair, I was writing imprecisely. The functionality has existed (at least primitively) on Linux for some time, but culturally Linux admins have been more drawn to HW level virtualization instead. OS-level virtualization has been a part of the FreeBSD and Solaris cultures for much longer. Another fair argument is that Docker does such a good job at abstracting the configuration and management of OS-level virtualization that it truly changes things. Maybe. But if that's true, it means that Linux admins have ignored this hugely useful technology because it was hidden behind an impenetrable wall of text-based configuration.