ClusterControl CLI Secrets - Things You Can Do That Are Not in the GUI

Everybody has a secret, and ClusterControl is not the exception… ClusterControl has a powerful, easy-to-use, and friendly UI, but using this UI is not the only way to manage your clusters. ClusterControl has a CLI called s9s, which is even more powerful than the UI, having features that are not available there yet. In this blog, we will show you how to use the ClusterControl CLI and what are the secret things that you can do using it.

ClusterControl CLI

Also known as s9s, is a command-line tool introduced in ClusterControl version 1.4.1 to interact, control, and manage database clusters using the ClusterControl system. ClusterControl CLI opens a new door for cluster automation where you can easily integrate it with existing deployment automation tools like Ansible, Puppet, Chef, etc. The command-line tool is invoked by executing a binary called s9s added by default in the ClusterControl installation.

You can find more information in the official documentation or even by running the s9s command with the help parameter:

$ s9s --help

Usage:

  s9s COMMAND [OPTION...]

Where COMMAND is:

    account - to manage accounts on clusters.

      alarm - to manage alarms.

     backup - to view, create and restore database backups.

    cluster - to list and manipulate clusters.

 controller - to manage Cmon controllers.

        job - to view jobs.

maintenance - to view and manipulate maintenance periods.

   metatype - to print metatype information.

       node - to handle nodes.

    process - to view processes running on nodes.

replication - to monitor and control data replication.

     report - to manage reports.

     script - to manage and execute scripts.

     server - to manage hardware resources.

      sheet - to manage spreadsheets.

       user - to manage users.

…

Also, the s9s tool has a man page for each command to get more detailed information.

$ man s9s node

Now you know what s9s is, let’s what kind of things are available here that are not possible in the ClusterControl UI.

Cluster Tagging

When managing a large number of database clusters you need to be able to find the one you are looking for quickly and easily. Cluster Tagging allows you to add keyword tags to each cluster (e.g. Tag by department, project, application, server, cloud provider, etc). You can then look up clusters by the keyword tags.

A cluster can be created with tags using the --with-tags option:

$ s9s cluster --create --cluster-name="TAGGED_CLUSTER" --cluster-type=galera --provider-version="10.4" --vendor=mariadb  --nodes="mysql://10.10.10.10:3306" --os-user=centos --with-tags="CLUSTER1;PRODUCTION1" --log

Or you can tag an existing cluster:

$ s9s tree --add-tag --tag="PRODUCTION1" /TAGGED_CLUSTER

Then, you can filter by using the created tags:

$ s9s cluster --list --long --with-tags="PRODUCTION1"

Vault Integration

Vault by HashiCorp is a service that allows you to keep your sensitive data secure, even when deployed across multiple servers and clouds. ClusterControl can integrate directly with the Vault APIs from the ClusterControl CLI, allowing you to shift from the standard methods of security to a more dynamic infrastructure as defined by ephemeral applications and servers, trusted sources of user and application identity, and software-based encryption. 

You can find more details about this feature in the corresponding blog post.

Enabling ClusterControl HA

ClusterControl HA, also known as CMON HA, is not enabled by default for compatibility reasons. To implement this, you will need to run an s9s controller command with the “--enable-cmon-ha” parameter.

When the CMON HA is enabled, CmonController class objects will be created and used to implement the high availability features. So, if the controller has at least one CmonController object, the CMON HA is enabled.

$ s9s controller --enable-cmon-ha

The CMON HA is now enabled, but there is no redundancy, only one controller is running. The one existing controller in this stage should be a leader although there are no followers.

Now, you will need to install additional ClusterControl servers one by one. The next controllers should use the same CMON Database and should have the same configuration files. When the additional controllers are started, they will find the leader in the CMON Database and will ask the leader to let them join. When the join is successful, one more CmonController will be created for every joining controller.

You can find more information about this feature in the two-part blog series here: Part 1 and Part 2.

Abort/Restart Jobs

You can use the ClusterControl CLI to abort a running job. This command will send a signal to a running ClusterControl Job in order to abort the execution. The job only will be aborted if and when the job supports aborting what it is doing.

First, you will need to get the job id that is necessary to kill the job.

$ s9s job −−list

When you have it, just run the following command:

$ s9s job --kill --job-id=1172

When it is killed, you will see the ABORTED status in the job list.

Another option about the jobs is to create a copy of an existing job to re-run it. The cloned job will have all the properties that the original job had and will be executed in the same way.

$ s9s job --clone --job-id=1172 --log

Enabling SSL for MongoDB

In case you have a MongoDB cluster in place, and you want to enable SSL, it can be easily done using the ClusterControl CLI. You will need the cluster id number, and run the following command:

$ s9s cluster --cluster-id=22 --enable-ssl --log 

When it finishes, you will receive the message “SSL setup done”.

Note: You can get the cluster id by running the following command:

$ s9s cluster --list --long

Limitations

Currently, the s9s command-line tool has a user management module that is not yet fully integrated with the ClusterControl UI and the ClusterControl Controller. For example, there is no Role-Based Access Control for a user. This means that any user created to be used with the s9s command-line tool has full access to all clusters managed by the ClusterControl server.

Users created by the command line client will be shown in Job Messages, but it is not possible to use this user to authenticate and login from the UI. Also, the users created from the command line client are all super admins.

Conclusion

ClusterControl has a powerful, easy-to-use, and friendly UI, but that is not all the power of ClusterControl. It could be possible you need to use the command line to integrate ClusterControl with an existing tool or even for automation purposes. 

The ClusterControl CLI (s9s) allows you to use the same feature available in the UI, and even more, and it can be integrated with external tools like Ansible, Puppet, etc.

In this blog, we showed you how to use the ClusterControl CLI and what kind of things you can do using it that are not available in the UI yet. Most of the things that we mentioned in this blog will be integrated with the ClusterControl UI soon in a future release.