4 ms·

Well, I always had problems differentiating "opaque" and "transparent" because depending on your point of view often both concepts can be applied interchangeabl

Well, I always had problems differentiating "opaque" and "transparent" because depending on your point of view often both concepts can be applied interchangeably. For instance in your post I didn't really get your point because at one time you seem to favor containers as a single entity from the perspective of the OS so they can be easily managed. This is what I understand you called "transparent to the OS". The is opposed to the container root fs that you call "opaque", supposedly because it cannot be easily mounted from the host OS etc. As the implementor of container runtimes you know that there's not a container entity but an agglomeration of isolation techniques such as namespaces, cgroups etc. including some kind of overlay fs that make up an actual container. For me that's not very transparent. VMs on the other hand are in that respect – in a similar way Solaris zones and Jails are, as they are actual entities that can be seen and managed on the host OS.

cyphar 8y ago
I mean "transparent to the OS" in reference to operating system tooling rather than the kernel objects that make up containers (there is an argument that these are related concepts -- but I think we can have cohesive tooling without redesigning how Linux handles containers). The lack of a 'struct container_t' in Linux definitely makes containers quite complicated to set up, and is a constant source of pain. But this also allows for lots of flexibility with different userspace programs to use various subsets of containers as part of their operation (the Chrome sandbox is a good example of this). > The is opposed to the container root fs that you call "opaque", supposedly because it cannot be easily mounted from the host OS etc. Well, you can mount it and you can manually funge with it using 'nsenter' but that's not really ideal. Why (from the perspective of a user) can't you run a package upgrade across your containers? Why can't you get the free memory across all containers? Free disk space? And so on. This information is _available_ but it's not cohesive for _users_. > VMs on the other hand are in that respect – in a similar way Solaris zones and Jails are I agree that Solaris Zones and FreeBSD Jails are transparent (in fact that level of tooling transparency is what I wish we had on Linux). I don't agree that VMs are transparent in the same way -- they are an opaque DRAM blob from the perspective of the host kernel. You can dtrace zones/jails, you cannot dtrace a VM (and get meaningful results about what the guest kernel is doing) AFAIK.
- ofrzeta 8y ago
  > I mean "transparent to the OS" in reference to operating system tooling rather than the kernel objects that make up containers (there is an argument that these are related concepts -- but I think we can have cohesive tooling without redesigning how Linux handles containers). The lack of a 'struct container_t' in Linux definitely makes containers quite complicated to set up, and is a constant source of pain It makes it difficult to reason about containers, as well. For instance do you see confinement technologies such as AppArmor or SELinux belonging to the container or are they slapped on top of containers? Where do you draw the boundary? And does it make sense to talk about "containers" when it's such a vague concept. Also, there are now "VM containers" such as Kata.
  - cyphar 8y ago
    > And does it make sense to talk about "containers" when it's such a vague concept. Well at some point we have to be able to talk about the widely-used and glued-together namespaces+cgroups+... concept. "Containers" is a perfectly fine thing to discuss (especially since the history of namespaces was definitely based in more "fully fledged" container technologies like Xen). > Also, there are now "VM containers" such as Kata. ... which are just VMs that can interact with container tools. I'm pretty sure that most people would not call these "containers" from an OS point of view because they do not share any of the primary properties that containers (or Jails/Zones) have -- the host kernel actually knows what the container processes are doing.

cyphar 8y ago

I mean "transparent to the OS" in reference to operating system tooling rather than the kernel objects that make up containers (there is an argument that these are related concepts -- but I think we can have cohesive tooling without redesigning how Linux handles containers). The lack of a 'struct container_t' in Linux definitely makes containers quite complicated to set up, and is a constant source of pain. But this also allows for lots of flexibility with different userspace programs to use various subsets of containers as part of their operation (the Chrome sandbox is a good example of this). > The is opposed to the container root fs that you call "opaque", supposedly because it cannot be easily mounted from the host OS etc. Well, you can mount it and you can manually funge with it using 'nsenter' but that's not really ideal. Why (from the perspective of a user) can't you run a package upgrade across your containers? Why can't you get the free memory across all containers? Free disk space? And so on. This information is _available_ but it's not cohesive for _users_. > VMs on the other hand are in that respect – in a similar way Solaris zones and Jails are I agree that Solaris Zones and FreeBSD Jails are transparent (in fact that level of tooling transparency is what I wish we had on Linux). I don't agree that VMs are transparent in the same way -- they are an opaque DRAM blob from the perspective of the host kernel. You can dtrace zones/jails, you cannot dtrace a VM (and get meaningful results about what the guest kernel is doing) AFAIK.

ofrzeta 8y ago
> I mean "transparent to the OS" in reference to operating system tooling rather than the kernel objects that make up containers (there is an argument that these are related concepts -- but I think we can have cohesive tooling without redesigning how Linux handles containers). The lack of a 'struct container_t' in Linux definitely makes containers quite complicated to set up, and is a constant source of pain It makes it difficult to reason about containers, as well. For instance do you see confinement technologies such as AppArmor or SELinux belonging to the container or are they slapped on top of containers? Where do you draw the boundary? And does it make sense to talk about "containers" when it's such a vague concept. Also, there are now "VM containers" such as Kata.
- cyphar 8y ago
  > And does it make sense to talk about "containers" when it's such a vague concept. Well at some point we have to be able to talk about the widely-used and glued-together namespaces+cgroups+... concept. "Containers" is a perfectly fine thing to discuss (especially since the history of namespaces was definitely based in more "fully fledged" container technologies like Xen). > Also, there are now "VM containers" such as Kata. ... which are just VMs that can interact with container tools. I'm pretty sure that most people would not call these "containers" from an OS point of view because they do not share any of the primary properties that containers (or Jails/Zones) have -- the host kernel actually knows what the container processes are doing.