Information Technology Reference
In-Depth Information
that the global zone's management tools need, it may become difficult or
impossible to manage the system.
Users and processes in the global zone aren't subject to all of the rules
of Containers. One example is process observability. A process in one
Container cannot detect processes in other Containers. As with a one-way
mirror, processes in the global zone, even nonprivileged ones, can see pro-
cesses in the Containers, even though users in the Containers cannot see
processes in the global zone.
Although a Container is a slightly different environment from a normal Oracle
Solaris system, a basic design principle underlying all Containers is software com-
patibility. A good rule of thumb is this: “If an application runs as a nonprivileged
user in a Solaris 10 system that doesn't have Containers, it will run properly in a
Container.” Nevertheless, some applications must run with extra privileges—tra-
ditionally, applications that must run as the root user. These applications may not
be able to gain the privileges they need and, therefore, may not run correctly in
a Container. In some cases, it is possible to enable such applications to run in a
Container by adding more privileges to that Container, a topic discussed later in
this chapter.
Containers have their own life cycle, which remains largely separate from
the life cycle of the base instance of Solaris. After Solaris has been installed and
booted, Containers can be configured, installed, booted, and used as if they were
discrete systems. They can easily and quickly be booted, halted, and rebooted. In
fact, booting or halting a Container takes less than five seconds, plus any time to
start or halt applications running in the Container. When you no longer need a
Container, you can easily destroy it.
Containers are very lightweight, because they are not an entire operating sys-
tem instance. They do not need to test the hardware or load a kernel or device
drivers. The base OS instance does all that work once—and each Container then
benefits from that work when it boots.
Given these characteristics, Containers, by default, use very few resources.
A default configuration uses approximately 100 MB of disk space, and approxi-
mately 40 MB of RAM when running. When it is not running, a Container does
not use any RAM at all. Further, because there is no virtualization layer to run on
a CPU, Containers have negligible performance overhead (which is a trait all OSV
technologies should have). In other words, a process in a Container follows the
same code path that it would outside of a Container unless it attempts to perform
an operation that is not allowed in a Container. Because it follows the same code
path, it has the same performance.
 
Search WWH ::




Custom Search