Taking a Look at the Ansible Integration in Bright Cluster Manager 9.1

page_header_divider_line

By Robert Stober | March 11, 2021 |

   

 

Late last year, we announced an integration with Ansible to enable organizations who have standardized on Ansible to gain the power and flexibility that Bright Cluster Manager provides, using their configuration tool of choice.

Ansible is an open source community project sponsored by Red Hat. We included the Ansible integration in Bright Cluster Manager 9.1 to enable administrators to use their skills and knowledge of Ansible to build and manage Bright clusters using a familiar Ansible “playbook” approach. The Bright Ansible module is a collection of Ansible modules that allow Bright clusters to be configured from Ansible playbooks. It is distributed through Ansible Galaxy, which provides pre-packaged units of work known to Ansible as roles and collections. Content can be referenced in Ansible PlayBooks and immediately put to work, for example, content for provisioning infrastructure and deploying applications. 

One of the main benefits of our Ansible integration is that you can use an infrastructure-as-code approach to configure and manage your Bright cluster. It isn’t mandatory to do it this way, but if you have the discipline to do it, it will be possible. And, if you are prepared to take the time to use an infrastructure as a code approach, you can reap many benefits, such as being able to roll out changes to large numbers of Bright clusters. 

Our Ansible integration also helps with “parallel upgrades”. A parallel upgrade is a very low-risk alternative to upgrading a cluster in-place using the standard upgrade procedure. Unlike an in-place upgrade, a parallel upgrade requires no downtime - the production cluster remains up and running while the new cluster is being installed, configured, and tested. In a parallel upgrade, a new version of Bright is installed on a new head node in parallel with the existing head node(s). The new head node can be a net new node, or it can be the existing secondary head node. The new version is installed on bare metal, resulting in a new cluster of one node (the head node itself). The new cluster needs to be configured identically to the existing cluster, which is where the Ansible integration comes in. If the existing cluster has been configured using an Ansible playbook from day one, that playbook can be used to quickly and accurately configure the new cluster identically to the production cluster. 

Similarly, the Ansible playbook can be used for disaster recovery. If disaster were to strike, an organization needs to be able to stand up a brand new cluster in a new location, configured exactly the same way as the production cluster. In a case like this, you would be able to recreate your cluster exactly, using the Ansible playbook. 

Watch the Bright Ansible demo, here.

For more information about the Bright Ansible integration, please contact us.

resource_asset_divider_image

COMMENTS