[lxc-users] Unix Sockets communications between containers

Michael H. Warfield mhw at WittsEnd.com
Tue Nov 11 20:33:56 UTC 2014


On Tue, 2014-11-11 at 15:03 -0500, CDR wrote:
> This is fascinating. I will try and report if it does work.

> Now, suppose the container is a mount that at the same time it is
> exported an NFS share. Will the computers that are remotely mounting
> that share, be able to use the socket for querying mysql? That opens a
> realm of possibilities for my current business. Believe or not my
> client sells access to mysql databases, in real time. 

Not going to work.  Think about it.  You're exporting an AF_UNIX (local
pipe) socket defined in a directory over a UDP RPC interface.  The other
side will (if it understands it) see an AF_UNIX socket local to them.
They won't be connected.  That will be true of just about any remote
file system.

You also said in your OP...

> It is much faster and uses far less resources than tcp. Does this make
> any sense?

So, you'd be replacing TCP with a UNIX socket over RPC over UDP and
expect that to be more efficient?  You've got a higher respect for NFS
than most of us.  Over NFS, that scheme would consume more resources,
even if it could work.

It won't work and, even if it could work, it would be dog slow and
probably insecure.

Use TCP for your remote connections and a locally bound UNIX socket for
your host local connections.  If you have to have the connections be
homogeneous, then go with TCP.  From your description of that business
model, unless you are transferring truly massive amounts of data per SQL
query, the performance of the TCP connection for your local
container-to-container connections is not going to be your bottleneck
and NFS would only make things worse.

> On Tue, Nov 11, 2014 at 2:52 PM, Serge Hallyn
> <serge.hallyn at ubuntu.com> wrote:
>         Quoting Michael H. Warfield (mhw at WittsEnd.com):
>         > On Tue, 2014-11-11 at 20:20 +0100, Hans Feldt wrote:
>         > > With a dir potentially you get a bunch of other sockets
>         available in the container, how can such
>         > > security issue be handled?
>         >
>         > Use tailored application specific directories for the
>         sockets?  That's
>         > no different than using application specific subdirectories
>         for temp
>         > files.  Even if it's just one socket in one directory,
>         creating that
>         > additional directory provides the isolation from other
>         sockets you
>         > desire while supporting socket recreation as Serge points
>         out.
>         
>         Right, I was thinking like how cgmanager does it.
>         
>         -serge
>         _______________________________________________
>         lxc-users mailing list
>         lxc-users at lists.linuxcontainers.org
>         http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> 
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20141111/ea72635a/attachment.sig>


More information about the lxc-users mailing list