4 ms·

I understand that it's your preference, but the namespacing of processes that's the root of container technology is not really that different from conventional

by pcnix 9y ago

I understand that it's your preference, but the namespacing of processes that's the root of container technology is not really that different from conventional wisdom, is it?

hguhghuff 9y ago
There's a string of words you've put together but I can't pull them into a sentence I understand sorry. Are these docker terms? If so then perhaps my despair is illustrated.
- nine_k 9y ago
  If you understand cgroups, then namespacing of processes makes perfect sense. If you don't, chances are it's too early to produce conclusions about containers. Also, docker is not the only solution for Linux containers; rkt is also developing, and Intel had its own interesting approach.
- deleted 9y ago
  [deleted]
- raesene9 9y ago
  one of the most interesting things for me about learning Docker is how it's improved my understanding of Linux. Ultimately Docker is just a set of linux features bundled together in a nice package, so you can learn the underlying features (and their pros and cons) without having to actually use Docker, if you don't want to.
  - subway 9y ago
    Ultimately Docker is just a set of linux features bundled together in a nice package And that's where it gets kinda scary. In Zones/Jails, you started with as little shared as possible. A jail/zone is a fresh isolated environment. With Docker (and really all Linux container implementations) you have hack-and-slash isolation going on. It's a loosely coupled collection of namespacing mechanisms that relies on whatever spawns the container to coordinate all these mechanisms. By default, they all will happily put the process in a shared space.
- monktastic1 9y ago
  You have this set of processes which can reference each other by PID, and that set of processes that can reference each other, and the twain shall (mostly) never meet?
- cookiecaper 9y ago
  Docker's killer feature is the packaging mechanism. A Docker image is like a virtual machine image and contains an executable environment, sometimes sans kernel since the host's kernel is used. It always includes a userland, but usually stripped down to support the bare minimum (busybox-ish). A "container" is simply a process that has some extra annotations on it, which various systems understand to represent some type of "namespacing" or information about the domain in which the process is allowed to operate. In Docker, these are implemented via the Linux cgroups mechanisms, which offers these and various types of annotations, including annotations that the kernel understands to constrain resource usage, etc. I don't know the details of the kernels well enough to discuss this next part in detail, but Linux containers implemented via cgroups are generally considered a "weak" security barrier, i.e., there are ways in which the isolation leaks out. illumos calls containers "zones" and is understood to have a stronger security/process isolation barrier, and I believe the same is true for FreeBSD jails, etc. "Containers" are a very old idea. Docker is an attempt to dumb them down for the masses by pretending that they're actually virtual machines and making it easy to "push" or "pull" the zip files^W^WDocker images. This assumption has caused many terrible container-based deployments. Most of the people running around tooting the horn of Docker and Kubernetes no doubt maintain these misconceptions and very superficial comprehensions of what's happening under the covers, and that's why they believe it's so magical and simple. Engineers who are trying to solve actual problems in a consistent, repeatable, and reliable manner will avoid any unnecessary complications -- including Kubernetes and/or Docker -- unless they are truly warranted by the unique circumstances in play, rather than seeking them out because they need a new flashy bullet point on their resume.
  - zrm 9y ago
    > Docker's killer feature is the packaging mechanism. That seems to be its Achilles' heel. Instead of having packages maintained by dedicated people (as with package managers like apt), you get a program that comes together with a collection of dependencies and libraries that aren't maintained by anyone. The average developer maintains their own program but doesn't have the resources to backport every bug fix and security update to the specific version of every library they use, and neither does anyone else when every program is using a different version of every dependency.
- lobster_johnson 9y ago
  This stuff isn't anything new or unproven, conceptually. Kernel-level namespacing has existed as a tool for decades (BSD jails, Solaris Zones, etc.) before Linux got it and Docker adopted it for use in Docker containers. It's hard to take seriously criticism when it comes from someone who doesn't even bother to read up on it enough to understand the terminology before commenting on HN.

by pcnix 9y ago

I understand that it's your preference, but the namespacing of processes that's the root of container technology is not really that different from conventional wisdom, is it?

hguhghuff 9y ago

There's a string of words you've put together but I can't pull them into a sentence I understand sorry. Are these docker terms? If so then perhaps my despair is illustrated.

nine_k 9y ago
If you understand cgroups, then namespacing of processes makes perfect sense. If you don't, chances are it's too early to produce conclusions about containers. Also, docker is not the only solution for Linux containers; rkt is also developing, and Intel had its own interesting approach.
deleted 9y ago
[deleted]
raesene9 9y ago
one of the most interesting things for me about learning Docker is how it's improved my understanding of Linux. Ultimately Docker is just a set of linux features bundled together in a nice package, so you can learn the underlying features (and their pros and cons) without having to actually use Docker, if you don't want to.
- subway 9y ago
  Ultimately Docker is just a set of linux features bundled together in a nice package And that's where it gets kinda scary. In Zones/Jails, you started with as little shared as possible. A jail/zone is a fresh isolated environment. With Docker (and really all Linux container implementations) you have hack-and-slash isolation going on. It's a loosely coupled collection of namespacing mechanisms that relies on whatever spawns the container to coordinate all these mechanisms. By default, they all will happily put the process in a shared space.
monktastic1 9y ago
You have this set of processes which can reference each other by PID, and that set of processes that can reference each other, and the twain shall (mostly) never meet?
cookiecaper 9y ago
Docker's killer feature is the packaging mechanism. A Docker image is like a virtual machine image and contains an executable environment, sometimes sans kernel since the host's kernel is used. It always includes a userland, but usually stripped down to support the bare minimum (busybox-ish). A "container" is simply a process that has some extra annotations on it, which various systems understand to represent some type of "namespacing" or information about the domain in which the process is allowed to operate. In Docker, these are implemented via the Linux cgroups mechanisms, which offers these and various types of annotations, including annotations that the kernel understands to constrain resource usage, etc. I don't know the details of the kernels well enough to discuss this next part in detail, but Linux containers implemented via cgroups are generally considered a "weak" security barrier, i.e., there are ways in which the isolation leaks out. illumos calls containers "zones" and is understood to have a stronger security/process isolation barrier, and I believe the same is true for FreeBSD jails, etc. "Containers" are a very old idea. Docker is an attempt to dumb them down for the masses by pretending that they're actually virtual machines and making it easy to "push" or "pull" the zip files^W^WDocker images. This assumption has caused many terrible container-based deployments. Most of the people running around tooting the horn of Docker and Kubernetes no doubt maintain these misconceptions and very superficial comprehensions of what's happening under the covers, and that's why they believe it's so magical and simple. Engineers who are trying to solve actual problems in a consistent, repeatable, and reliable manner will avoid any unnecessary complications -- including Kubernetes and/or Docker -- unless they are truly warranted by the unique circumstances in play, rather than seeking them out because they need a new flashy bullet point on their resume.
- zrm 9y ago
  > Docker's killer feature is the packaging mechanism. That seems to be its Achilles' heel. Instead of having packages maintained by dedicated people (as with package managers like apt), you get a program that comes together with a collection of dependencies and libraries that aren't maintained by anyone. The average developer maintains their own program but doesn't have the resources to backport every bug fix and security update to the specific version of every library they use, and neither does anyone else when every program is using a different version of every dependency.
lobster_johnson 9y ago
This stuff isn't anything new or unproven, conceptually. Kernel-level namespacing has existed as a tool for decades (BSD jails, Solaris Zones, etc.) before Linux got it and Docker adopted it for use in Docker containers. It's hard to take seriously criticism when it comes from someone who doesn't even bother to read up on it enough to understand the terminology before commenting on HN.