11 ms·

How did we end up with containers?

133 points by mmphosis 9y ago

exabrial 9y ago
I like the focus on artifacts and repeatable testing. Are full blown containers even necessary though? The newest version of systemd can do filesystem namespaces, and use cgroups to limit access to resources. http://0pointer.de/blog/projects/changing-roots http://0pointer.de/blog/projects/changing-roots
- coldacid 9y ago
  Not even every Linux distro uses systemd, to say nothing about other systems on which one may want to host containers. Remember, there's more to containerization than just Docker and its consumers and dependencies.
  - bamboozled 9y ago
    Which production grade distros don't use systemd?
    - zokier 9y ago
      Gentoo! ducks
      - oblio 9y ago
        I think RHEL 6 also doesn’t use it. But then you have bigger problems :)
    - combatentropy 9y ago
      What do you mean by production grade?
      - bamboozled 9y ago
        A distro a sane person would put into a production environment. EL/Debian for example.
    - orthecreedence 9y ago
      Slackware.
    - mmphosis 9y ago
      Void Linux
wrs 9y ago
This is mostly a good post, but he doesn’t mention one huge security disadvantage of containers: When application artifacts all include their own versions of dependencies locked at build time, it becomes very hard to update a component that has a security fix. It’s somewhat tractable if you own all the images — you “just” have to rebuild every application with the vulnerable component. But once you start accepting prebuilt images from elsewhere, you are at the mercy of the external source unless you want to fork the Dockerfiles. It’s the same lesson that a lot of people learned about static linking, with the zlib vulnerabilities years ago. https://www.linux.com/news/linux-kernel-netscape-affected-major-zlib-security-vulnerability https://www.linux.com/news/linux-kernel-netscape-affected-ma...
- aeorgnoieang 9y ago
  Why's that a disadvantage of containers versus, e.g. third-party libraries used by an application?
  - Retric 9y ago
    Mostly scale, 3rd party libraries are a subset of the dependencies you see in a container.
  - wrs 9y ago
    You can update a shared library without regard to the applications using it. You just "apt update" the vulnerable library and all applications get it. (In theory--but the other side of this argument is that occasionally that will trigger a bug.) If it's a static library, see my zlib comment. Those have the same problem.
    - deathanatos 9y ago
      > You just "apt update" the vulnerable library and all applications get it. And restart every effected service. You can't "just" run the apt update; the binaries using any shared libraries must be restarted so as to load the newer version of the library. I find this is often the harder problem to solve. (If you can just reboot the machine, do that, it's easier; otherwise you have to track down who was using the old binary and restart each one of them…) (sorry, this is a rather critical step that I've seen missed before.)
neuromantik8086 9y ago
> In short, there’s no reason why apt and dnf or whatever couldn’t work in a similar way npm or bundle do, except that Linux distributions seem to be disinterested. (And occasionally throw a specious fit about “bundling” when features like this are proposed. Or are unwilling to understand why the ability to install multiple versions of a package is necessary.) Wouldn't this just require tighter integration with environment modules (http://modules.sourceforge.net/ http://modules.sourceforge.net/) or similar?
excalibur 9y ago
> How did we end up with containers? 1) You bought stuff. 2) Bonus!
glenjamin 9y ago
The description at the end of the article about how package management doesn't have to be done in a way that shares all the files sounds a lot like a description of https://nixos.org/nix/ https://nixos.org/nix/
gumby 9y ago
I have a less charitable explanation, but a container fan on our team convinced me recently to switch to fully static binaries which did indeed simplify many things. So there is something to be said for this in an age of cheap storage.
- jacquesm 9y ago
  Static linking was the norm until someone figured out that all the copies of glibc were taking up a lot of space in a time when disk space will still expensive. Today it makes much less sense than it did back then but there is one more advantage: updating a library (which is trivial because almost all these systems are online all the time now) will automatically cause all new instances of the rest of the software on the system to use the new library without having to re-link all the binaries.
  - gumby 9y ago
    > ...Static linking was the norm until someone figured out that all the copies of glibc were taking up a lot of space Dynamic (with and without relocation) linking far predates the existence of glibc, much less Linux, by decades.
    - jacquesm 9y ago
      Make that libc or the X libraries or any other large chunk of code that was replicated over and over again in every linked binary. The principle remains the same, and yes, it predates Linux by a comfortable margin. I'm trying to remember if the old mainframe I worked on had it but I'm not 100% sure.
      - gumby 9y ago
        It was core functionality of the design of Multics in the 1960s and Multics adopted it from prior art.
        jacquesm 9y ago
mlosapio 9y ago
I feel like containers (at-times) are the artifact organizational disfunction, the inability for teams to collaborate and a lack of engineering quality. What’s sad is that I believe this to be true for the overhwelming majority.
- jacquesm 9y ago
  Mixed bag: containers applied right can solve some real problems, containers applied wrong cause some real problems.
EngineerBetter 9y ago
Containers != Images
prewett 9y ago
I can't seem to find any easily accessible documentation on this, but it sounds like a container is basically an chroot jail: you copy over all the libraries and files into a subdirectory, chroot into it, and run. Am I right? And if so, what took people so long? Chroot has been around for quite a while. The article sort of makes it sound like a lightweight version of containers would be putting everything in its own directory, rather than scattering everything in /usr/lib, /usr/bin, /usr/share, etc. Which is basically macOS' app bundles. I've never understood why other OSes didn't steal that idea. And while I hear a lot of griping about iOS and static libraries, basically what iOS is doing is creating a container, only since they call it an "application bundle" instead of "container" they get all this hate. But... Grandma Tillie (or whoever the user story for Linux on the Desktop back in the The Day was named) can actually figure out how to delete her Mac and iOS apps. Seems like iOS is kind of containers writ large.
- abhorrence 9y ago
  Chroot is just part of it, there’s also cgroups and namespaces which are more recent.
- anonacct37 9y ago
  chroot is a filesystem namespace, and containers are basically just that plus some other namespaces. Prior to containers getting really popular I was using debian's schroot project and prior to that I was using solaris zones. There were other similar technologies prior to that but I wasn't really technical or even alive at the time. It's not new. Here's what's made them so popular lately IMO. Docker improved the usability by adding the container registry and adding some better tooling around running a container. Compare installing schroot plus configuring a new container plus running debootstrap plus potentially configuring lvm/btrfs/directory snapshotting to: docker run ubuntu:lts /bin/bash
deleted 9y ago
[deleted]

133 points by mmphosis 9y ago

I like the focus on artifacts and repeatable testing. Are full blown containers even necessary though? The newest version of systemd can do filesystem namespaces, and use cgroups to limit access to resources. http://0pointer.de/blog/projects/changing-roots http://0pointer.de/blog/projects/changing-roots

coldacid 9y ago
Not even every Linux distro uses systemd, to say nothing about other systems on which one may want to host containers. Remember, there's more to containerization than just Docker and its consumers and dependencies.
- bamboozled 9y ago
  Which production grade distros don't use systemd?
  - zokier 9y ago
    Gentoo! ducks
    - oblio 9y ago
      I think RHEL 6 also doesn’t use it. But then you have bigger problems :)
  - combatentropy 9y ago
    What do you mean by production grade?
    - bamboozled 9y ago
      A distro a sane person would put into a production environment. EL/Debian for example.
  - orthecreedence 9y ago
    Slackware.
  - mmphosis 9y ago
    Void Linux

wrs 9y ago

This is mostly a good post, but he doesn’t mention one huge security disadvantage of containers: When application artifacts all include their own versions of dependencies locked at build time, it becomes very hard to update a component that has a security fix. It’s somewhat tractable if you own all the images — you “just” have to rebuild every application with the vulnerable component. But once you start accepting prebuilt images from elsewhere, you are at the mercy of the external source unless you want to fork the Dockerfiles. It’s the same lesson that a lot of people learned about static linking, with the zlib vulnerabilities years ago. https://www.linux.com/news/linux-kernel-netscape-affected-major-zlib-security-vulnerability https://www.linux.com/news/linux-kernel-netscape-affected-ma...

aeorgnoieang 9y ago
Why's that a disadvantage of containers versus, e.g. third-party libraries used by an application?
- Retric 9y ago
  Mostly scale, 3rd party libraries are a subset of the dependencies you see in a container.
- wrs 9y ago
  You can update a shared library without regard to the applications using it. You just "apt update" the vulnerable library and all applications get it. (In theory--but the other side of this argument is that occasionally that will trigger a bug.) If it's a static library, see my zlib comment. Those have the same problem.
  - deathanatos 9y ago
    > You just "apt update" the vulnerable library and all applications get it. And restart every effected service. You can't "just" run the apt update; the binaries using any shared libraries must be restarted so as to load the newer version of the library. I find this is often the harder problem to solve. (If you can just reboot the machine, do that, it's easier; otherwise you have to track down who was using the old binary and restart each one of them…) (sorry, this is a rather critical step that I've seen missed before.)

neuromantik8086 9y ago

> In short, there’s no reason why apt and dnf or whatever couldn’t work in a similar way npm or bundle do, except that Linux distributions seem to be disinterested. (And occasionally throw a specious fit about “bundling” when features like this are proposed. Or are unwilling to understand why the ability to install multiple versions of a package is necessary.) Wouldn't this just require tighter integration with environment modules (http://modules.sourceforge.net/ http://modules.sourceforge.net/) or similar?

excalibur 9y ago

> How did we end up with containers? 1) You bought stuff. 2) Bonus!

glenjamin 9y ago

The description at the end of the article about how package management doesn't have to be done in a way that shares all the files sounds a lot like a description of https://nixos.org/nix/ https://nixos.org/nix/

gumby 9y ago

I have a less charitable explanation, but a container fan on our team convinced me recently to switch to fully static binaries which did indeed simplify many things. So there is something to be said for this in an age of cheap storage.

jacquesm 9y ago
Static linking was the norm until someone figured out that all the copies of glibc were taking up a lot of space in a time when disk space will still expensive. Today it makes much less sense than it did back then but there is one more advantage: updating a library (which is trivial because almost all these systems are online all the time now) will automatically cause all new instances of the rest of the software on the system to use the new library without having to re-link all the binaries.
- gumby 9y ago
  > ...Static linking was the norm until someone figured out that all the copies of glibc were taking up a lot of space Dynamic (with and without relocation) linking far predates the existence of glibc, much less Linux, by decades.
  - jacquesm 9y ago
    Make that libc or the X libraries or any other large chunk of code that was replicated over and over again in every linked binary. The principle remains the same, and yes, it predates Linux by a comfortable margin. I'm trying to remember if the old mainframe I worked on had it but I'm not 100% sure.
    - gumby 9y ago
      It was core functionality of the design of Multics in the 1960s and Multics adopted it from prior art.
      - jacquesm 9y ago

mlosapio 9y ago

I feel like containers (at-times) are the artifact organizational disfunction, the inability for teams to collaborate and a lack of engineering quality. What’s sad is that I believe this to be true for the overhwelming majority.

jacquesm 9y ago
Mixed bag: containers applied right can solve some real problems, containers applied wrong cause some real problems.

EngineerBetter 9y ago

Containers != Images

prewett 9y ago

I can't seem to find any easily accessible documentation on this, but it sounds like a container is basically an chroot jail: you copy over all the libraries and files into a subdirectory, chroot into it, and run. Am I right? And if so, what took people so long? Chroot has been around for quite a while. The article sort of makes it sound like a lightweight version of containers would be putting everything in its own directory, rather than scattering everything in /usr/lib, /usr/bin, /usr/share, etc. Which is basically macOS' app bundles. I've never understood why other OSes didn't steal that idea. And while I hear a lot of griping about iOS and static libraries, basically what iOS is doing is creating a container, only since they call it an "application bundle" instead of "container" they get all this hate. But... Grandma Tillie (or whoever the user story for Linux on the Desktop back in the The Day was named) can actually figure out how to delete her Mac and iOS apps. Seems like iOS is kind of containers writ large.

abhorrence 9y ago
Chroot is just part of it, there’s also cgroups and namespaces which are more recent.
anonacct37 9y ago
chroot is a filesystem namespace, and containers are basically just that plus some other namespaces. Prior to containers getting really popular I was using debian's schroot project and prior to that I was using solaris zones. There were other similar technologies prior to that but I wasn't really technical or even alive at the time. It's not new. Here's what's made them so popular lately IMO. Docker improved the usability by adding the container registry and adding some better tooling around running a container. Compare installing schroot plus configuring a new container plus running debootstrap plus potentially configuring lvm/btrfs/directory snapshotting to: docker run ubuntu:lts /bin/bash

deleted 9y ago

[deleted]