[ClusterLabs] are there equivalent restful apis for crm commands
Jan Pokorný
jpokorny at redhat.com
Tue Nov 7 23:01:45 CET 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: <http://lists.clusterlabs.org/pipermail/users/attachments/20171107/4760937f/attachment-0001.sig>
More information about the Users
mailing list