Currently, deploying an Icinga 2 Agent on a Linux system can be intricate, given the substantial variations in the process across different releases or OS families.
For instance:
The repository definition differs for each OS version and family
User and group specifications vary between Debian and RedHat
The environmental path for the Icinga installation also could differ
Fortunately, there’s no need to develop and maintain a custom script to manage these diverse scenarios. We can leverage the readily available Ansible Plugins for this purpose.
Given that our objectives are clearly defined, I developed a role that encompasses all the necessary steps. This allows you to effortlessly integrate it into your playbooks.
You can consult these links to better understand the topic:
Essentially, the role is structured around the following stages:
Gathering NetEye Information: Retrieving essential data from NetEye, including node role, NetEye version, and Icinga2 zone
Collecting Target Information: Gathering details about the target system, such as Linux version and hostname
Verifying Icinga Certificates: Checking for the existence of Icinga certificates on target systems
Token Generation: Creating a token either through the command-line interface (CLI) or by utilizing the API
Installing Icinga Repository and Agent: Setting up the Icinga repository and installing the agent on the designated target
Establishing Icinga Connection: Linking the Icinga agent to the master or satellite
Icinga 2 Restart: Initiating a restart of the Icinga 2 service
NB: When executing this role on a NetEye master or satellite node, there’s no requirement to input specific variables. All necessary data will be automatically collected and utilized.
The playbook will look something like this:
- hosts: all
remote_user: root
roles:
- icinga2-wp
As anticipated, the role can be executed from an external system, such as an Ansible server. In such cases, the following information needs to be provided:
For more information you can request the access to the bitbucket role
Conclusion
Deploying Icinga using Ansible greatly improves on manual deployment due to the efficiency, accuracy, and consistency of automation. Ansible eliminates human error, ensures uniformity across deployments, and adapts to various systems, reducing complexity. Centralized management and scalability enhances efficiency. In sum, Ansible accelerates deployment, minimizes mistakes, and boosts system reliability.
These Solutions are Engineered by Humans
Did you find this article interesting? Are you an “under the hood” kind of person? We’re really big on automation and we’re always looking for people in a similar vein to fill roles like this one as well as other roles here at Würth Phoenix.
When using Kibana in environments that require a proxy to reach external services, you might encounter issues with unrecognized SSL certificates. Specifically, if the proxy is exposed with its own certificate and acts as an SSL terminator, requests made by Read More
In a previous post we went through the configuration of Elastic Universal Profiling in NetEye, seeing how we can profile applications written in programming languages that do not compile to native code (for example Python, PHP, Perl, etc.) But what Read More
Elastic 8.16, which comes with NetEye 4.39, made Elastic Universal Profiling generally available for self-hosted installations. This means that NetEye SIEM installations will now be able to take advantage of the continuous profiling solution by Elastic. In this blog post Read More
In the first part of this series, we explored how Jira Service Management (JSM) helps streamline Incident Management, aligning with ITIL v4 best practices. Incident Management aims to restore normal service operation as quickly as possible after a disruption, ensuring Read More
Hello everyone! Today, I'd like to briefly discuss an improvement to the update and upgrade procedures that we've started to adopt with NetEye 4.39! What we wanted to improve One aspect that made quite an impact was that whenever the Read More