Blog Details Title Goes Here
26.06.2022

Playing with ansible-collection-icinga

Having implemented multiple different solutions for managing and integrating icinga into ansible roles and frameworks on my own, a standardized and “official” approach comes in quite handy. A few weeks ago a first version - 0.1.0 - was released by the icinga team.

I often used jinja2 templates for rendering and managing icinga2 config files. It feels like the universal approach to me. Not very intuitive, but flexible and kinda bullet-proof.

The new collection uses a different way: everything is configured by setting variables. The roles then compile everything into icinga2-DSL files and assambles the whole configuration together. It then fully overrides the existing one! Isn’t this risky? I’ll find out!

Setup

To install the current version of the collection just run:

ansible-galaxy collection install icinga.icinga

on your bastion host.

I created a simple inventory (inventory.yml) to configure the target machine:

all:
  children:
    icingatest:
      hosts:
        <your servername / ip address>

The icinga roles can be easily used by attaching the collection and roles to a playbook (test.yml):

---
- name: Install and configure icinga
  hosts: icingatest
  remote_user: manager
  collections:
    - icinga.icinga
  roles:
    - repos
    - icinga2
  become: yes
  vars:
    icinga2_features:
      - name: checker
      - name: mainlog
      - name: graphite
        host: localhost
        port: 3000

By executing the playbook, icinga with the given features is being installed on the target server (Debian 11):

ansible-playbook -i inventory.yml test.yml

As shown by systemd, icinga is running and doing preconfigured checks on localhost:

So far, so good.

Now let’s create some services by adding a host variable to our inventory:

all:
  children:
    icingatest:
      hosts:
        icinga1.internal.cloudapp.net:
          ansible_host: <your servername / ip address>
          icinga2_objects:
            icinga1.internal.cloudapp.net:
              - name: ftp localhost
                type: Service
                order: 11
                file: conf.d/services.conf
                apply: true
                imports:
                  - generic-service
                check_command: ftp
                assign:
                  - host.address

Important note: the variable icinga2_objects needs the ansible_fqdn as the second level of the dictionary. It wont render the configuration if it is not matched. Check your ansible_fqdn, maybe it does not match the ansible_hostname from your inventory! You can see it here within the source-code: ansible-collection-icinga

To be sure, you could print the variable within a task in the playbook:

  tasks:
    - name: debug
      debug:
        msg: "{{ ansible_fqdn }}"

As the roles automatically delete files and folders which are not configured explicitly, you will likely screw up the default installation when starting a new project and running the playbook for the first time.

But nevertheless, the service is configured correctly:

I definitely need to configure a bigger installation and see how good the configuration scales.

There are still plenty of important things missing - like configuring satellites and agents easily -, but it is a very solid start!

You can find the playground of this post at my Github!