4 ms·

The concept is great but it's also not original. It's called "processes". Docker is little more than a mass of complication laid atop fork+exec. That's why nob

by ChoHag 10y ago

The concept is great but it's also not original. It's called "processes". Docker is little more than a mass of complication laid atop fork+exec. That's why nobody can get it right - because we already did.

IshKebab 10y ago
I totally agree. The real issue is dynamic libraries and how hard it is to compile C/C++ code statically with GCC. If you could just pass `-static` to gcc and it actually worked like you expect this would never have happened. Fortunately that seems to be changing somewhat. Go is totally static, and Rust can easily be made totally static using muscl. You can even do totally static C/C++ apps fairly easily with muscl.
- jjnoakes 10y ago
  Dynamic libraries (in the C/C++ sense) only scratch the surface. Containers give you your own file system namespace (among other namespaces), which means all of the files that make up your complicated application unit can be put together and work together in isolation, separate from the machine's main file system.
  - jalfresi 10y ago
    Isn't that chroot jails?
    - icebraining 10y ago
      Yes, quite literally, in fact: https://github.com/opencontainers/runc/blob/ee992e5ff7143ea3fedb1bb4aa88a41d65a0bd66/libcontainer/rootfs_linux.go#L616 https://github.com/opencontainers/runc/blob/ee992e5ff7143ea3...
  - nix0n 10y ago
    What advantages do file system namespaces have over separating by directories and users?
    - acdha 10y ago
      A big one is managing software which you didn't write: if you have two things which expect to be able to write to /etc/mydaemon.conf etc. you either need to burn a VM for each one, fork the startup scripts or take the Debian-style approach of maintaining patches which make everything configurable, or manage something like maintaining chroots directory hierarchies. (repeat for network namespacing: it's really nice not to need to play games to have your CI server start 3 running jobs which all think they're listening on port 80) None of that is impossible – in the case of chroot there's many years of precedent - but if you do it regularly, there's a strong appeal to automating a common pattern. This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw. (Not saying that Docker is perfect or necessarily the long-term winner in this space, only that there's a usability gap which a lot of people fall into).
      - mmarx 10y ago
        > This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw. On the contrary, any user that can run arbitrary containers (such as rootplease[0], for example) has root-level privileges on the host system. [0] https://hub.docker.com/r/chrisfosterelli/rootplease/ https://hub.docker.com/r/chrisfosterelli/rootplease/
        acdha 10y ago
        What I was thinking about wasn't protecting against outright malice but rather mistakes and errors: If you give developers sudo access and you don't have an extremely diligent team with strong system administration experience, you're going to run into problems where people made incompletely documented changes or cause problems while working which aren't caught early enough – ever see someone break out sudo or chmod 777 as their first debugging step or even write that into the install process because it was too much work to do it right? Docker is an enormous win here both because it sharply reduces the number of times someone needs privilege escalation and because it ensures that the end result of their work can be reliably audited and repeatedly deployed. It's true that Docker doesn't protect against compromised or malicious users with privileged access. That's a very hard problem in general which can only partially be addressed at this level — especially since many of the most damaging attacks don't need it (“The bad news: they exfiltrated our customer database. Good news: they didn't get root on the EC2 instance”). I think most of the answers for this problem are going to continue to rely on existing practices like code review, auditing, getting finely-grained SELinux / seccomp rules into the development mainstream, etc.
jjnoakes 10y ago
How is "your own network, your own view of the file system, your own view of the process table, your own view of the user IDs, ..." the same as "processes"?
- elsonrodriguez 10y ago
  On modern Linux distros every process is running in a cgroup and namespace by default. So these days the main difference between a "container" and a regular process is that regular processes are all jumbled together in the same root namespace, and containers are in separate namespaces.
  - jjnoakes 10y ago
    Which Linux distributions do this? I'd like to read how "most" instances of fork and exec end up with unique networks and file system namespaces.
    - elsonrodriguez 10y ago
      I didn't say unique, I said "jumbled together". Now as far as which distros put processes in a namespace and cgroup by default, I know at least CentOS 7 and Ubuntu 15 do this. And those two distros on their own would qualify for "most". To check if your distro does it, one way of checking is just doing a `cat /proc/1/cgroup`. This will show you what cgroups process 1 is in. By default you will be in the "root" cgroup. To check your namespaces, `ls -l /proc/1/ns/`. You'll see the process is in some randomly generated namespace ID per item. I'm sure you could recompile your kernel to disable this behavior, but the default reality of modern Linux is that everything is already running in a "container". Now the question is whether or not people want to take advantage of that reality, and separate out processes in isolation, or keep running everything on a system in such a way that any single process can impact the whole system.
- zeveb 10y ago
  Plan 9 is knocking on the door and would like to have a word …
brazzledazzle 10y ago
Wouldn't it be more akin to jails?

by ChoHag 10y ago

IshKebab 10y ago

I totally agree. The real issue is dynamic libraries and how hard it is to compile C/C++ code statically with GCC. If you could just pass `-static` to gcc and it actually worked like you expect this would never have happened. Fortunately that seems to be changing somewhat. Go is totally static, and Rust can easily be made totally static using muscl. You can even do totally static C/C++ apps fairly easily with muscl.

jjnoakes 10y ago
Dynamic libraries (in the C/C++ sense) only scratch the surface. Containers give you your own file system namespace (among other namespaces), which means all of the files that make up your complicated application unit can be put together and work together in isolation, separate from the machine's main file system.
- jalfresi 10y ago
  Isn't that chroot jails?
  - icebraining 10y ago
    Yes, quite literally, in fact: https://github.com/opencontainers/runc/blob/ee992e5ff7143ea3fedb1bb4aa88a41d65a0bd66/libcontainer/rootfs_linux.go#L616 https://github.com/opencontainers/runc/blob/ee992e5ff7143ea3...
- nix0n 10y ago
  What advantages do file system namespaces have over separating by directories and users?
  - acdha 10y ago
    A big one is managing software which you didn't write: if you have two things which expect to be able to write to /etc/mydaemon.conf etc. you either need to burn a VM for each one, fork the startup scripts or take the Debian-style approach of maintaining patches which make everything configurable, or manage something like maintaining chroots directory hierarchies. (repeat for network namespacing: it's really nice not to need to play games to have your CI server start 3 running jobs which all think they're listening on port 80) None of that is impossible – in the case of chroot there's many years of precedent - but if you do it regularly, there's a strong appeal to automating a common pattern. This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw. (Not saying that Docker is perfect or necessarily the long-term winner in this space, only that there's a usability gap which a lot of people fall into).
    - mmarx 10y ago
      > This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw. On the contrary, any user that can run arbitrary containers (such as rootplease[0], for example) has root-level privileges on the host system. [0] https://hub.docker.com/r/chrisfosterelli/rootplease/ https://hub.docker.com/r/chrisfosterelli/rootplease/
      - acdha 10y ago
        What I was thinking about wasn't protecting against outright malice but rather mistakes and errors: If you give developers sudo access and you don't have an extremely diligent team with strong system administration experience, you're going to run into problems where people made incompletely documented changes or cause problems while working which aren't caught early enough – ever see someone break out sudo or chmod 777 as their first debugging step or even write that into the install process because it was too much work to do it right? Docker is an enormous win here both because it sharply reduces the number of times someone needs privilege escalation and because it ensures that the end result of their work can be reliably audited and repeatedly deployed. It's true that Docker doesn't protect against compromised or malicious users with privileged access. That's a very hard problem in general which can only partially be addressed at this level — especially since many of the most damaging attacks don't need it (“The bad news: they exfiltrated our customer database. Good news: they didn't get root on the EC2 instance”). I think most of the answers for this problem are going to continue to rely on existing practices like code review, auditing, getting finely-grained SELinux / seccomp rules into the development mainstream, etc.

jjnoakes 10y ago

How is "your own network, your own view of the file system, your own view of the process table, your own view of the user IDs, ..." the same as "processes"?

elsonrodriguez 10y ago
On modern Linux distros every process is running in a cgroup and namespace by default. So these days the main difference between a "container" and a regular process is that regular processes are all jumbled together in the same root namespace, and containers are in separate namespaces.
- jjnoakes 10y ago
  Which Linux distributions do this? I'd like to read how "most" instances of fork and exec end up with unique networks and file system namespaces.
  - elsonrodriguez 10y ago
    I didn't say unique, I said "jumbled together". Now as far as which distros put processes in a namespace and cgroup by default, I know at least CentOS 7 and Ubuntu 15 do this. And those two distros on their own would qualify for "most". To check if your distro does it, one way of checking is just doing a `cat /proc/1/cgroup`. This will show you what cgroups process 1 is in. By default you will be in the "root" cgroup. To check your namespaces, `ls -l /proc/1/ns/`. You'll see the process is in some randomly generated namespace ID per item. I'm sure you could recompile your kernel to disable this behavior, but the default reality of modern Linux is that everything is already running in a "container". Now the question is whether or not people want to take advantage of that reality, and separate out processes in isolation, or keep running everything on a system in such a way that any single process can impact the whole system.
zeveb 10y ago
Plan 9 is knocking on the door and would like to have a word …

brazzledazzle 10y ago

Wouldn't it be more akin to jails?