Skip to content

Allow IPC namespace to be shared between containers or with the host#8835

Closed
crosbymichael wants to merge 1 commit intomoby:masterfrom
crosbymichael:dan-ipc
Closed

Allow IPC namespace to be shared between containers or with the host#8835
crosbymichael wants to merge 1 commit intomoby:masterfrom
crosbymichael:dan-ipc

Conversation

@crosbymichael
Copy link
Copy Markdown
Contributor

Replaces #8211

Some workloads rely on IPC for communications with other processes. We
would like to split workloads between two container but still allow them
to communicate though shared IPC.

This patch mimics the --net code to allow --ipc=host to not split off
the IPC Namespace. ipc=container:CONTAINERID to share ipc between containers

If you share IPC between containers, then you need to make sure SELinux labels
match.

Docker-DCO-1.1-Signed-off-by: Dan Walsh dwalsh@redhat.com (github: rhatdan)
Signed-off-by: Michael Crosby crosbymichael@gmail.com

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"create a"

@crosbymichael crosbymichael force-pushed the dan-ipc branch 2 times, most recently from 0989141 to 0f43e5b Compare October 29, 2014 00:19
Some workloads rely on IPC for communications with other processes.  We
would like to split workloads between two container but still allow them
to communicate though shared IPC.

This patch mimics the --net code to allow --ipc=host to not split off
the IPC Namespace.  ipc=container:CONTAINERID to share ipc between containers

If you share IPC between containers, then you need to make sure SELinux labels
match.

Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
@jessfraz
Copy link
Copy Markdown
Contributor

LGTM

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I get the same output if I create a 4th container that uses the container id of the 3rd?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, the container:<id> syntax feels strange when you have more than one container joining a namespace. A use-case we have for this, is that we use IPC semaphores for accessing external resources (for control in latent conditions)—in that case, we'd share this between every container running web workers on the system. Orchestrating this sharing during deployments (and replacing containers) seems non-trivial with this model. Although I don't have a better idea right now.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes all namespaces should be shared.

We could add a --ipc ipcns:/proc/PID/ns/ipc

Which seems like a logical addition. I love the idea of this for netns.

@rhatdan
Copy link
Copy Markdown
Contributor

rhatdan commented Oct 30, 2014

@crosbymichael Do you want me to take this back to make the changes?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this mean there's a default of "", where the container can only talk to itself?

if so, please mention it - personally, I'd rather it be default ==none, empty strings are always such a pain.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it means that it will be the default which has a private IPC Namespace.

@SvenDowideit
Copy link
Copy Markdown
Contributor

mmm, cli.md should have a mirror of what is in the man page, and run.md should really be the one that provides more details - so most of the examples should go there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants