3 ms·

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 sys

by 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.
prodigal_erik 12y ago
> 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) If two servers require different versions of a library, I see that as not a use case but a problem of technical debt, to be solved by repackaging and retesting with the correct version. > export LD_LIBRARY_PATH='/opt/oracle/lib' I guess some people are required to run such badly-maintained software, but I don't see why anyone's excited about the prospect.
- evol262 12y ago
  You're missing the point, which isn't that "badly-maintained software" and "technical debt" are the problems. It's that I, as a developer who writes Python which runs on Fedora, EL[6|7], Gentoo, Debian, Ubuntu, and Arch have to go through an inordinate amount of testing and hoop-jumping in order to make sure that my application runs on EL6 and Fedora, to say nothing of systems which aren't guaranteed to have the same package names, library locations, or major versions of Python, much less having it at all (especially a problem on EL6 and Gentoo). It makes sense for me, as a developer, not to go through repackaging and retesting for 7 distros with 4 different packaging paradigms and 3 init systems when I could simply tell you to run a container. None. Disk space and memory are now cheap. Statically linked binaries are coming back. Containers as the new /opt strike a middle ground between distro portability and developer effort. It must be nice for you to live in an ivory tower.
  - prodigal_erik 12y ago
    If you're throwing proprietary binaries over the wall for clients who aren't paying enough to support all their platforms, I guess picking one is a necessary evil. But it seems strange to set up a container, which is essentially your own custom distro which nobody else uses, rather than just picking a well-supported distro. And if I had a goal of minimizing any interaction between my code and its environment, Linux syscalls are a much bigger API than I would choose. It's not as if you can claim to support a distro whose kernel or docker version you haven't tested on.

by evol262 12y ago

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.

prodigal_erik 12y ago

> 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) If two servers require different versions of a library, I see that as not a use case but a problem of technical debt, to be solved by repackaging and retesting with the correct version. > export LD_LIBRARY_PATH='/opt/oracle/lib' I guess some people are required to run such badly-maintained software, but I don't see why anyone's excited about the prospect.

evol262 12y ago
You're missing the point, which isn't that "badly-maintained software" and "technical debt" are the problems. It's that I, as a developer who writes Python which runs on Fedora, EL[6|7], Gentoo, Debian, Ubuntu, and Arch have to go through an inordinate amount of testing and hoop-jumping in order to make sure that my application runs on EL6 and Fedora, to say nothing of systems which aren't guaranteed to have the same package names, library locations, or major versions of Python, much less having it at all (especially a problem on EL6 and Gentoo). It makes sense for me, as a developer, not to go through repackaging and retesting for 7 distros with 4 different packaging paradigms and 3 init systems when I could simply tell you to run a container. None. Disk space and memory are now cheap. Statically linked binaries are coming back. Containers as the new /opt strike a middle ground between distro portability and developer effort. It must be nice for you to live in an ivory tower.
- prodigal_erik 12y ago
  If you're throwing proprietary binaries over the wall for clients who aren't paying enough to support all their platforms, I guess picking one is a necessary evil. But it seems strange to set up a container, which is essentially your own custom distro which nobody else uses, rather than just picking a well-supported distro. And if I had a goal of minimizing any interaction between my code and its environment, Linux syscalls are a much bigger API than I would choose. It's not as if you can claim to support a distro whose kernel or docker version you haven't tested on.