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. greetings Guido 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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
