[ClusterLabs] are there equivalent restful apis for crm commands

Jan Pokorný jpokorny at redhat.com
Tue Nov 7 17:01:45 EST 2017


On 07/11/17 09:14 -0600, Ken Gaillot wrote:
> On Tue, 2017-11-07 at 16:06 +0800, he.hailong5 at zte.com.cn wrote:
>> For some purpose, I have to acquire some info within the docker
>> container that usually can be made by executing crm commands on the
>> host. Importing this tool into the container may involve fixing lots
>> of dependency issues and you still need to figure out how to connect
>> to the server from within the container. So I am wondering if there
>> are already equivelent restful apis I can facilitate via network
>> tools in the container to achieve this. Or other good ideas?
> 
> If you launch the container via Pacemaker's new "bundle" feature
> (available in 1.1.17 and later), Pacemaker will set up a Pacemaker
> Remote connection to the container, which can proxy the command-line
> tools.

Or, if your container is otherwise unrelated to the cluster stack on
the host (I suspect that's the case), there are other options to choose
from:

1. Using (non-standard, security relaxing!) --network=host, you can
   actually equip the container with libqb, pacemaker libraries and
   CLI tools (like crm_mon) and the inherent sharing of the abstract
   unix sockets should make these tools just work on behalf of the
   node representing the host machine when run under root or hacluster
   users (or haclient group) -- that illustrates one of the hazards, as
   you can have a custom users/groups in the possibly deemed
   "unprivileged" container that suddently get to be privileged
   within the cluster layer.  Depending on whether crm does any
   extra probing of the environment, you may be able also then to
   use crm directly from such a container.

2. You can get machine parsable XML of the cluster status in the
   container by curl'ing there the content served with something like
   this on the host (assuming proper port mapping; here, port 1500 is
   the source):
   
   while true; do echo -e "HTTP/1.1 200 OK\n\n $(crm_mon -1X)" \
   | nc -l localhost 1500; done

   Security considerations needed!

3. Similar to 2. if you'd be OK to parse HTML content on your own and
   provided that you would be using release candidates for pacemaker
   1.1.18 (as these received some minor but nonetheless enabling fixes)
   or newer, you can setup crm_mon in the role of the CGI script on
   the host like in the mini how-to embedded in the commit message:
   https://github.com/ClusterLabs/pacemaker/commit/e438181c0e88879a32c63ae892d07d2c33ebc6f9
   while ensuring the particular (host+)port serving that script on
   the host is accessible from the container, and also keep in mind
   that such a setup also requires plenty of security considerations
   (such as you likely don't want to expose that CGI script to the
   outer world).
   
   Thinking of it, perhaps it would make sense to return the
   possibility to make CGI serve the XML data again, exactly
   for cases like this...
 
> At the recent ClusterLabs Summit, RESTful APIs came up as a future
> enhancement, but it would be a big project, so I don't know what the
> time frame would be.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20171107/4760937f/attachment-0003.sig>


More information about the Users mailing list