This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/mesos-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 1ee7bc2 Updated the website built from mesos SHA: aeeda40aa.
1ee7bc2 is described below
commit 1ee7bc23bab452e1ac6239ce4bed0e21e4fc45c5
Author: jenkins <[email protected]>
AuthorDate: Fri Jul 12 19:20:08 2019 +0000
Updated the website built from mesos SHA: aeeda40aa.
---
.../latest/isolators/namespaces-ipc/index.html | 60 +++++++++++++++++++---
1 file changed, 52 insertions(+), 8 deletions(-)
diff --git a/content/documentation/latest/isolators/namespaces-ipc/index.html
b/content/documentation/latest/isolators/namespaces-ipc/index.html
index 9b238c5..3c11005 100644
--- a/content/documentation/latest/isolators/namespaces-ipc/index.html
+++ b/content/documentation/latest/isolators/namespaces-ipc/index.html
@@ -107,14 +107,58 @@
<div class="col-md-8">
<h1>IPC Namespace Isolator in Mesos Containerizer</h1>
-<p>The IPC Namespace isolator can be used on Linux to place tasks
-in a distinct IPC namespace. The benefit of this is that any
-<a href="http://man7.org/linux/man-pages/man7/svipc.7.html";>IPC objects</a>
created
-in the container will be automatically removed when the container is
-destroyed.</p>
-
-<p>To enable the IPC namespace isolator, append <code>namespaces/ipc</code> to
the
-<code>--isolation</code> flag when starting the agent.</p>
+<p>The IPC Namespace isolator can be used on Linux to place container in a
+distinct IPC namespace (for isolating System V IPC resources and POSIX
+message queue) and provide the container its own /dev/shm (for isolating
+POSIX shared memory). The benefits of this are:</p>
+
+<ol>
+<li><p>Visibility: Any IPC objects created in the container are private and
+cannot be seen by any other containers.</p></li>
+<li><p>Clean termination: When the container is destroyed, any IPC objects
+created in the container will be automatically removed.</p></li>
+</ol>
+
+
+<p>To enable the IPC namespace isolator, append <code>namespaces/ipc</code> to
the <code>--isolation</code>
+flag when starting the agent. Note that <code>filesystem/linux</code> isolator
is required
+for turning on IPC namespace isolator.</p>
+
+<p>Framework users can control the behavior of a container’s IPC
namespace
+and /dev/shm by setting the <code>ContainerInfo.linux_info.ipc_mode</code>
field:</p>
+
+<ol>
+<li><p>If set to <code>SHARE_PARENT</code>, the container will share the IPC
namespace and
+/dev/shm with its parent. If the container is a top level container,
+it will share the IPC namespace and /dev/shm with the agent host, if
+the container is a nested container, it will share the IPC namespace
+and /dev/shm with its parent container. The implication is if a nested
+container wants to share the IPC namespace and /dev/shm with the agent
+host, its parent container has to do it first.</p></li>
+<li><p>If set to <code>PRIVATE</code>, the container will have its own IPC
namespace and
+/dev/shm.</p></li>
+<li><p>If not set, for backward compatibility we will keep the previous
behavior:
+Top level container will have its own IPC namespace and nested container
+will share the IPC namespace with its parent container. If the container
+does not have its own rootfs, it will share agent’s /dev/shm, otherwise
+it will have its own /dev/shm.</p></li>
+</ol>
+
+
+<p>As a security measure, operators can disallow any containers to share the
+agent’s IPC namespace and /dev/shm by setting the agent flag
+<code>--disallow_sharing_agent_ipc_namespace</code> to <code>true</code>. If
this agent flag is set to <code>false</code>
+and the framework requests to launch a top level container to share the
+agent’s IPC namespace and /dev/shm, the container launch will be
rejected.</p>
+
+<p>Framework users can specify the size of a container’s /dev/shm in MB
by
+setting the <code>ContainerInfo.linux_info.shm_size</code> field, and
operators can specify
+the default size of /dev/shm via the agent flag
<code>--default_shm_size</code>. So if the
+<code>ContainerInfo.linux_info.shm_size</code> field is not set, the size of
container’s
+/dev/shm will be value of the <code>--default_shm_size</code> agent flag, if
that flag is
+not set too, the size of the /dev/shm will be half of the agent host RAM
+which is the default behavior of Linux. The
<code>ContainerInfo.linux_info.shm_size</code>
+field will be ignored for the container which shares its parent’s
/dev/shm.</p>
</div>
</div>
