Dear Brian,

please take the time to read about Linux Kernel namespaces as the technical 
base of containers. It's like two viewpoints to one thing. Take the network 
namespace as an example: From the conceptual point of view it looks like you 
have N indipended, functional identical "IP Stacks". But from the technical 
point of view, it's just the "well known" single instance just with an 
additional field at all items that need this (packets, routing tables, ...) to 
take a tag value that identify the namespace instance.

You may use namespaces with the raw tools like enterns or with LXC or Dockers. 
During runtime of a started container, there's nothing more you have to trust 
but the kernel because for the basics, there's no need of additional userland 
processes to keep a container running.

To run an application in a "container", you start it with a bunch of instances 
of this namespaces, at least the process namespace. You'll probably take the 
same name for the technical namespace instances - from the conceptual point of 
view this is the name of the container.

Most will start something like the init binary located in a directory tree of a 
small Linux distribution userland. This may "boot" common services and the 
result may act like an "indipended platfrom". But you may also launch just 
single high-level applications like a JVM running a Tomcat.

That's very close to your architecture, but much more easy to handle. For the 
network stack e.g. you may use the same ports for listeners and have the full 
range of ports available for connections in each namespace. There are different 
ways available to route the traffic, but in any case you may use individual IPs 
in each namespace.



On 2021-06-28 19:22, Brian Wolfe wrote:
> Generally, I'd agree too. We are considering using containers, but I'm not
> yet sure what that buys us in terms of stability.

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to