[ClusterLabs] how to connect to the cluster from a docker container

[Ken Gaillot]

On Tue, 2019-08-06 at 14:03 +0200, Jan Pokorný wrote:
> On 06/08/19 13:36 +0200, Jan Pokorný wrote:
> > On 06/08/19 10:37 +0200, Dejan Muhamedagic wrote:
> > > Hawk runs in a docker container on one of the cluster nodes (the
> > > nodes run Debian and apparently it's rather difficult to install
> > > hawk on a non-SUSE distribution, hence docker). Now, how to
> > > connect to the cluster? Hawk uses the pacemaker command line
> > > tools such as cibadmin. I have a vague recollection that there is
> > > a way to connect over tcp/ip, but, if that is so, I cannot find
> > > any documentation about it.

I think one of the solutions Jan suggested would be best, but what
you're likely remembering is remote-tls-port:

https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html-single/Pacemaker_Administration/#s-remote-connection

However that only works for the CIB, so anything that needed to contact
other daemons wouldn't work.

> > 
> > I think that what you are after is one of:
> > 
> > 1. have docker runtime for the particular container have the
> > abstract
> >    Unix sockets shared from the host (--network=host? don't
> > remember
> >    exactly)
> > 
> >    - apparently, this weak style of compartmentalization comes with
> >      many drawbacks, so you may be facing hefty work of cutting any
> >      other interferences stemming from pre-chrooting assumptions of
> >      what is a singleton on the system, incl. sockets etc.
> > 
> > 2. use modern enough libqb (v1.0.2+) and use
> > 
> >      touch /etc/libqb/force-filesystem-sockets
> > 
> >    on both host and within the container (assuming those two
> > locations
> >    are fully disjoint, i.e., not an overlay-based reuse), you
> > should
> >    then be able to share the respective reified sockets simply by
> >    sharing the pertaining directory (normally /var/run it seems)
> > 
> >    - if indeed a directory as generic as /var/run is involved,
> >      it may also lead to unexpected interferences, so the more
> >      minimalistic the container is, the better I think
> >      (or you can recompile libqb and play with path mapping
> >      in container configuration to achieve smoother plug-in)
> 
> Oh, and there's additional prerequisite for both to at least
> theoretically work -- 1:1 sharing of /dev/shm (which may also
> be problematic in a sense).
> 
> > Then, pacemaker utilities would hopefully work across the container
> > boundaries just as if they were fully native, hence hawk shall as
> > well.
> > 
> > Let us know how far you'll get and where we can colletively join
> > you
> > in your attempts, I don't think we had such experience disseminated
> > here.  I know for sure I haven't ever tried this in practice, some
> > one else here could have.  Also, there may be a lot of fun with
> > various
> > Linux Security Modules like SELinux.
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
-- 
Ken Gaillot <kgaillot at redhat.com>