Unleashing the Power of Automation with Rundeck & Ansible

Say goodbye to manual tasks and hello to automation! Let’s talk about two game-changers in the world of IT operations: Rundeck and Ansible.

Rundeck is your go-to open-source automation platform. It’s all about making your life easier by automating recurring tasks. Whether you’re deploying applications, managing infrastructure, orchestrating workflows, or scheduling jobs, Rundeck has got you covered. Plus, it comes with enhanced security features to keep your operations safe and sound.

On the other hand, Ansible is another open-source hero in the automation arena. It’s a configuration management tool that treats system configuration as code. It’s cross-platform compatible (Linux, Windows, UNIX) and uses a main/central server to push configuration information to the nodes. And the best part? Its playbooks are written in YAML, making them easy to understand and use.

So, what can you do with Rundeck and Ansible? Here are some use cases:

1. Automate repetitive tasks: From software installations and configuration changes to system updates, automate it all. Save time, reduce human errors, and boost the productivity and reliability of your IT operations. As a result, this leads to reduced costs associated with manual labour and human errors.
2. Quickly Manage on-shot operations: Deploy applications across multiple servers and apply security patches. Ensuring consistency and standardization in your IT infrastructure.
3. Manage infrastructure: Automate tasks such as server provisioning, network configuration, and database management.
4. Enhance security: Automate tasks in vulnerable assets, patch management, and access control. To reduce the risk of security breaches and data loss, Developers, managers, and other stakeholders can deploy the application tier without requiring high-level server access to launch an application or start a service/database.

Next, we will describe a list of use cases implemented at La Redoute.

#1 – Adding a new server to the inventory list using only the Rundeck platform.

The automation that was created by us, which we will explain how it works (as can be observed in the Figure 1), is designed to prevent users from accessing the rundeck server via SSH and from needing elevated privileges on the server to add a new server to the Rundeck inventory list.

The addition of new servers to the Rundeck inventory list needs to be ‘on demand’ and not automatic when a new server is created, as it may be a server that does not need to use Rundeck or may just be a temporary server – this way optimizing the Rundeck inventory list.

To do that, the user must access the Rundeck GUI to initiate the process. They only need to trigger a job to add a new server to the inventory list by providing the server hostname as input.

We created a service called “checkhosts,” which checks if there are any changes in the host inventory. If there are no changes in the hosts file, the process ends without further action. However, if the hosts file has changed, the “checkhosts” service triggers a Rundeck API call. The Rundeck API then triggers another job to refresh the inventory list, updating it to include the new server. This process ensures that the inventory list is updated only when there are changes in the hosts, optimizing the workflow and ensuring accurate inventory management.

#2 – Server Integration

This automation is designed for system administrators who need to install and configure software packages and join newly created servers in our Active Directory.

In Figure 2, we can see the integration of 8 servers, which took about 1 hour and 20 minutes in total (in this case, it’s important to perform the integration sequentially rather than in parallel so that if an error occurs, it is isolated to a single server and doesn’t need to be fixed on all servers). Without the playbook, it could have taken 4 to 6 hours, with the possibility of human errors naturally occurring during the configuration of multiple servers.

#3 – Project Road to Cloud: Data migration of Elasticsearch from on-prem to cloud

In the Road to Cloud (R2C) project, one of the Elasticsearch clusters composed of physical servers was targeted for migration to virtual machines (VMs). The goal was to first migrate these physical servers to VMs, then decommission the physical servers, optimize the migrated VMs, and finally migrate the VMs to Azure instances. This approach successfully reduced infrastructure costs while optimizing Elasticsearch performance.

In Table 1, we can see the significant difference in migration time if Ansible & Rundeck were not used. The time difference between the two approaches is noticeable.

Table 1: Comparison between using or not using Rundeck & Ansible.

#4 – Installation of a package in its latest available version

We implemented a playbook in the scheduler (running once a day) that automates the process of getting the latest Tomcat version from the official Tomcat website. As shown in Figure 3, the installation playbook’s drop-down menu offers the user the most recent versions of Tomcat available for installation.

The playbook stores the data in JSON format to be used by Rundeck. A separate job to install Tomcat utilizes these JSON files to install the selected Tomcat version from the website. This ensures that users have the option to install the most recent version available on the official website, streamlining the installation and update process.

#5 – Installation of security updates

Based on some latest CVEs (Common Vulnerabilities and Exposures), it was necessary to update certain packages in the system. In this case, we needed to update OpenSSH on hundreds of machines.

We developed a playbook that upgrades OpenSSH (Figure 5 – Job to Update OpenSSH) to the system’s latest version and, upon completion, generates a CVE report detailing all servers where OpenSSH was updated along with their respective versions.

#6 – Initialization of Azure instances

The non-production websites used internally for performance tests are powered off outside of working hours to reduce costs. To ensure they are ready when people start working, there are Rundeck jobs that trigger GitLab pipelines. These pipelines initiate the setup of the non-production environments, ensuring the websites are ready when employees arrive at work.

#7 – Purges to clean-up data storage platform

We implemented Rundeck jobs scheduled daily, weekly, or monthly to clean up files on Qumulo (a platform that provides scalable, high-performance storage solutions). These jobs delete files older than x days based on the retention requirements of each share. This prevents shares from retaining files indefinitely and helps manage Qumulo’s storage usage effectively, allowing us to keep costs under control and a more manageable workspace.

Embrace the power of automation with Rundeck and Ansible. Enhance your IT operations and don’t waste time on tasks that can be automated. Let’s automate the world together! 🌍