Git Product home page Git Product logo

ansible-icinga2's Introduction

Attention: This role is no longer maintained. See: https://github.com/Icinga/ansible-collection-icinga

Icinga 2 Role for Ansible

Ansible role to install and configure Icinga 2.

The scope of this role is to handle the installation and configuration of Icinga 2. In the future it will be possible to configure Icinga as master, satellite or agent. This role handles only Icinga 2 and not any third-party software (like databases, nrpe, UI etc.). The installation and configuration of Icinga Web 2 is currently not part of this role.

The role is supported on the following platforms:

  • Ansible >= v2.8
  • Icinga 2 >= v2.8
  • Ubuntu: 18.04, 20.04
  • Debian: 9, 10
  • CentOS/RHEL: 7, 8

Other operating systems or versions may work but have not been tested.
Platform support may be extended after a v1.0 release.

Installation

Using ansible-galaxy:

ansible-galaxy install icinga.icinga2

Using requirements.yml:

---

- src: icinga.icinga2

Requirements

Prerequisites that you may need, but are not covered by this role:

  • Database (MySQL/MariaDB/Postgres)
  • Web UI (icingaweb2)
  • NRPE

Role Configuration

By default this role adds the official Icinga Repository to the system and installs the icinga2 package.

- name: Default Example
  hosts: localhost
  roles:
    - icinga2

Disable repository management

You may choose to use your own or the systems default repositories. Repository management can be disabled:

- name: Example without repository
  hosts: all
  roles:
    - icinga2
  vars:
    - i2_manage_repository: false

Variables

Variable: i2_manage_repository

Whether to add the official Icinga Repository to the system or not. Defaults to true.

Variable: i2_manage_package

Whether to install packages or not. Defaults to true.

Variable: i2_manage_epel

Whether to install the EPEL release package. Defaults to true.

Variable: i2_manage_service

Whether to start, restart and reload the Icinga 2 on changes or not. Defaults to true.

Variable: i2_apt_key

GPG key used to verify packages on APT based system. The key will be imported. Defaults to https://packages.icinga.com/icinga.key.

Variable: i2_apt_url

Repository URL for APT based systems. Defaults to deb http://packages.icinga.com/{{ ansible_distribution|lower }} icinga-{{ ansible_distribution_release }} main. This may be customized if you have a local mirror.

Variable: i2_yum_key

GPG key used to verify packages on YUM based sytems. The key URL will be added to the repository file. Defaults to https://packages.icinga.com/icinga.key.

Variable: i2_yum_url

Repository URL for YUM based sytem. Defaults to http://packages.icinga.com/epel/$releasever/release/. This may be customized if you have a local mirror.

Variable: i2_confd

By default, configuration located in /etc/icinga2/conf.d is included. This list may be modified to include additional directories or set to [] to not include conf.d at all (e.g. on distributed installations). Defaults to [ "conf.d" ].

Variable: i2_include_plugins

The ITL comes with a set of pre-configured check commands. This variable defines what to include. Defaults to ["itl", "plugins", "plugins-contrib", "manubulon", "windows-plugins", "nscp"]

Variable: i2_const_plugindir

Set PluginDir constant. Defaults to {{ i2_lib_dir }}/nagios/plugins.

Variable: i2_const_manubulonplugindir

Set ManubulonPluginDir constant. Defaults to {{ i2_lib_dir }}/nagios/plugins.

Variable: i2_const_plugincontribdir

Set PluginContribDir constant. Defualts to {{ i2_lib_dir }}/nagios/plugins.

Variable: i2_const_nodename

Set NodeName constant. Defaults to {{ ansible_fqdn }}.

Variable: i2_const_zonename

Set ZoneName constant. Defaults to {{ ansible_fqdn }}.

Variable: i2_const_ticketsalt

Set TicketSalt constant. Empty by default.

Variable: i2_custom_constants

Add custom constants to constants.conf. Must be a dictionary. Defaults to: {}

Some default required values are specified in i2_default_constants and merged with this variable. Use this variable to override these default values, or add your own constants.

Default values of i2_default_constants:

  PluginDir: "{{ i2_lib_dir }}/nagios/plugins"
  ManubulonPluginDir: "{{ i2_lib_dir }}/nagios/plugins"
  PluginContribDir: "{{ i2_lib_dir }}/nagios/plugins"
  NodeName: "{{ ansible_fqdn }}"
  ZoneName: "{{ ansible_fqdn }}"
  TicketSalt: ""

Example usage:

  vars:
    - i2_constants:
        TicketSalt: "My ticket salt"
        Foo: "bar"

Variable: i2_zones

Replaces zones.conf with configured zones.

Example:

  vars:
    i2_zones:
      - name: master
        is_parent: true
        endpoints:
          - name: master1.example.tom
            host: master1.example.tom
            port: 15667
          - name: master2.example.tom
            host: 128.0.0.1
          - name: global-templates
            is_global: true
          - name: director-global
            is_global: true

is_parent = sets the parent zone to this zonename (optional). is_global = sets the zone to a global zone (optional). host = sets the host ip/fqdn to connect to this endpoint (optional). port = sets the port (optional). Defaults to 5665. Requires host do be set.

System specific variables

The following variables are system specific and don't need to be overwritten in most cases. Be careful when making changes to any of these variables.

Variable: i2_conf_dir

Base Icinga 2 configuration directory. Defaults to /etc/icinga2.

Variable: i2_user

Icinga 2 running as user. Default depends on OS.

Variable: i2_group

Icinga 2 running as group. Default depends on OS.

Variable: i2_lib_dir

Lib dir. Default depends on OS.

Feature Usage

Variable: i2_custom_features

Features are maintained over the dictionary i2_custom_features. By default features won't be managed until i2_custom_features has further values.

Example usage:

vars:
  i2_custom_features:
    ApiListener:                #ObjectType
      api:                      #ObjectName
        accept_command: true    #ObjectAttribute
        accept_config: true     #ObjectAttribute
    GraphiteWriter:
      graphite:
        host: "127.0.0.1"
        port: "2004"

Variable: i2_remove_unmanaged_features

The variable i2_remove_unmanaged_features change the behaviour of the feature handling. It will remove all unmanged .conf files from the directory /etc/icinga2/features-enabled and let you manage only your defined features.

Handlers

Handler: start icinga2

This handler starts Icinga 2. It is only used to make sure Icinga 2 is running. You can prevent this handler from being triggered by setting i2_manage_service to false.

Handler: reload icinga2

This handler reloads Icinga 2 when configuration changes. You can prevent this handler from being triggered by setting i2_manage_service to false.

Examples

Example Agent Config:

Example usage (api featuer will NOT be enabled in this example):

- name: icinga Package
  hosts: icingaagents
  roles:
    - icinga2
  vars:
    i2_confd: [] #don't include conf.d
    i2_zones:
      - name: master
        is_parent: true
        endpoints:
          - name: master1.example.tom
            host: master1.example.tom
            port: 15667
          - name: master2.example.tom
            host: 128.0.0.1

Dependencies

None

Example Playbook

---

- name: Playbook
  hosts: all

  roles:
    - icinga.icinga2

Contributing

When contributing several steps such as pull requests and proper testing implementations are required. Find a detailed step by step guide in CONTRIBUTING.md.

Testing

Testing is essential in our workflow to ensure a good quality. We use Molecule to test all components of this role. For a detailed description see TESTING.md.

Release Notes

When releasing new versions we refer to SemVer 1.0.0 for version numbers. All steps required when creating a new release are described in RELEASE.md

See also CHANGELOG.md

Authors

AUTHORS is generated on each release.

License

This project is under the Apache License. See the LICENSE file for the full license text.

ansible-icinga2's People

Contributors

aflatto avatar arjanoosting avatar bobapple avatar flokoe avatar kwisatz avatar martialblog avatar mkayontour avatar neverusedid avatar rossbarnie avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ansible-icinga2's Issues

Main configuration handling

Default configuration files should be configurable based on templates. This affects:

  • icinga2.conf
    • include constants
    • include zones.conf
    • include plugins (itl, plugins, plugins-contrib, ...)
    • include features-enabled/*.conf
    • include conf.d directory or alternative
    • manage/create included config directories
  • constants.conf
    • add default constants like PluginDir, NodeName etc.
    • add custom constants

Don't touch any other directory or configuration file managed by the Icinga 2 package for now. Files and directories should only be managed by Ansible if necessary.

Take care that the Icinga process is reloaded/restarted after configuration changes.

i2_features not working

When executing this Playbook:

- name: icinga Package
  hosts: icingaagents
  roles:
    - icinga2
  vars:
    - i2_custom_features:
      ApiListener:
        api:
          accept_command: true
          accept_config: true
    - i2_confd: []

I get this Error:

TASK [icinga2 : include icinga2-features.yml] ****************************************************************************************************************************************************************
fatal: [1.1.1.1]: FAILED! => {"msg": "The conditional check 'i2_features|flatten|length > 0' failed. The error was: Unexpected templating type error occurred on ({% if i2_features|flatten|length > 0 %} True {% else %} False {% endif %}): 'NoneType' object is not iterable\n\nThe error appears to be in '/etc/ansible/roles/icinga2/tasks/main.yml': line 21, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: include icinga2-features.yml\n  ^ here\n"}

When i change this task to "is defined":

- name: include icinga2-features.yml
  include_tasks: icinga2-features.yml
  #when: i2_features|flatten|length > 0
  when: i2_features is definded

i get:

`TASK [icinga2 : generate enabled feature configuration] ******************************************************************************************************************************************************
fatal: [1.1.1.1]: FAILED! => {"msg": "with_dict expects a dict"}

`

It looks like variable i2_features is empty when the task is executed, but i can't find a solution for that.

The Release package without i2_features works, but can't enable features. I also had some problems to understand why there is i2_features and i2_custom_features at the beginning. Why not use only one variable for both and add switches to custom_features like enable: true

Testing Environment

Decide what’s the best method to run unit and integration tests and implement basic tests that are extended as the development continues.

Potential options:

Implement some basic testing with TravisCI to catch syntax, linting and gross errors.

Repository Management

The official repository packages.icinga.com is added before installing any package. The default behavior is to add this repository, it can be disabled optionally by the user.

Keep the supported distributions in mind.

Generic feature handling

A general helper that can enable and disable features and change configuration for a feature.

Following options come to my mind:

  • Use the existing icinga2_feature module. Don't know if this is sufficiant
  • Extend the existing icinga2_feature module.
  • Use a generic template and enable features by adding symlinks, like icinga2 does.

No specific feature options are set here.

A reload/restart of Icinga is triggered if a feature is enabled/disabled or the configuration changes.

Every specific feature allows the configuration of its settings. Some features may have extended functionality, such as importing data schemas.

Example implementation with templates: https://github.com/mkayontour/icinga2-ansible/tree/master/roles/icinga2-feature-handler
Another example implementation with templates: https://github.com/chrnie/ansible-role-icinga2

Feedback is very welcome, I don't know what's the best "ansible way" here.

Changing the feature handling to be more like the official Icinga2 way?

Hi there,

what do you all think about changing the behavior of i2_custom_features to use the feature-available folder instead of the features-enabled folders and use the original icinga command "icinga2 feature enable/disable" to manage the features?

Changes needed:

i2_custom_features

  • i2_custom_features need to create new feature configs inside features-available instead of features enabled.
  • Maybe rename i2_custom_features to i2_create_features

I would add another variable to make it possible to name the config file other then the feature. F.e. name the file for the ApiListener "api" too.

i2_features

  • i2_features need to use the icinga command to enable/disable commands instead of deleting them, directly in the folder.
  • i2_feature need to get config option like i2_custom_feature, but instead of replacing the feature like i2_custom_features will do, it will regex replace lines in the exiting configs.
  • Add "enabled: true/false" as config variable
  • Maybe renaming i2_features to i2_manage_features

Maybe add a "disable_none_managed: true" variable to remove all conf files in features-enabled before configuring. Still not sure, how to do that without doing it on every run.

Example:

i2_manage_features:
  disable_none_managed: "true"
  api: 
    enable: true 
    config: 
      accept_commands: "true"
  notifications:  
    enable: false 

i2_custom_constants for ApiListner creates faulty config

looks like the template creates a faulty configuration for the api feature.

the variables used as mentioned in the README

i2_custom_features:
  ApiListener:
    api: 
       accept_config: true
       accept_commands: true

The result ansible creates

# cat features-enabled/ApiListener.conf 
// Ansible managed

object ApiListener "api" {
   accept_config = "True"
accept_commands = "True"
}

syntax complain

# icinga2 daemon -C
[2020-01-28 16:14:53 +0100] information/cli: Icinga application loader (version: r2.11.2-1)
[2020-01-28 16:14:53 +0100] information/cli: Loading configuration file(s).
[2020-01-28 16:14:53 +0100] information/ConfigItem: Committing config item(s).
[2020-01-28 16:14:53 +0100] critical/config: Error: Error while evaluating expression: Can't convert 'True' to a floating point number.
Location: in /etc/icinga2/features-enabled/ApiListener.conf: 4:4-4:25
/etc/icinga2/features-enabled/ApiListener.conf(2): 
/etc/icinga2/features-enabled/ApiListener.conf(3): object ApiListener "api" {
/etc/icinga2/features-enabled/ApiListener.conf(4):    accept_config = "True"
                                                      ^^^^^^^^^^^^^^^^^^^^^^
/etc/icinga2/features-enabled/ApiListener.conf(5): accept_commands = "True"
/etc/icinga2/features-enabled/ApiListener.conf(6): }

[2020-01-28 16:14:53 +0100] critical/config: 1 error
[2020-01-28 16:14:53 +0100] critical/cli: Config validation failed. Re-run with 'icinga2 daemon -C' after fixing the config.

Result expected is

cat features-enabled/ApiListener.conf 
// Ansible managed
object ApiListener "api" {
   accept_config = true
   accept_commands = true

Looks like the api follows a different syntax then the other features.

unfortunately my ansible skill is not enough to make PR. :(

Thanks for your feedback.

SLES Support

In the ansible_collections/icinga/icinga the role for SLES is missing. Is its possible to add SLES support?

user@host:~/.ansible/collections/ansible_collections/icinga/icinga/roles/icinga2/tasks$ ls
configure.yml features features.yml install.yml install_on_Debian.yml install_on_RedHat.yml main.yml objects.yml service.yml

Gentoo support?

Is there any interest in supporting gentoo, particularly gentoo with openrc (as opposed to systemd)? I'd be happy to contribute, but first I need to know if this is important to the maintainers.

Roadmap Contribution Request - Feature handling, CA, Cert generation, roles structure etc.

Hello @flokoe

as you are the new maintainer we are happy to see some change and results on the project.
We @lbetz (maintainer of the icinga puppet module) and I want to contribute and help out on a few topics. We have some time and motivation to spare.

We had a meeting the other day and discussed a few things, which we want to change or add.
Please feel free to comment on them, add your notes and share your thoughts.

Extract the repo management into an extra role.

In future we think that the role to install and configure Icinga 2 won't be the last one.
We need to consider, that after Icinga 2, we need the following roles to cover all Icinga 2 components.

  • icingaweb2
  • icingadb
  • icinga-redis
  • maybe more?

So to keep the repo management consistent over all icinga* roles we think its best to extract the part and publish it into an separate role. Then it would be possible to use it as a dependency for the roles.

Certificate Generation for Clients/Agents

As Icinga 2 provides a few ways to generate certificates for clients, we had the discussion which way would be the best to choose. Ansible provides a key feature which enables us to easily generate certificates on the CA system.

So we suggest to generate and sign the certificates on the CA system by using delegate_to and provide them to the client.

Manage "role" in Icinga Environment

On the topic how we define a client or master in Ansible we discussed it's best to let the user choose which features to use. As many our environments are so uniq and therefore we can't define how a master, satellite or agent should look like.

So we decided we should stick with using features to design the Icinga instance.

In addition to this, the CA isn't a feature in Icinga terms, but something we need to take care like a feature.
There should be a variable to define if the system contains the Icinga 2 CA.
i2_ca = true

Icinga 2 config, objects, attributes and parser

Config Path

Icinga 2 provides the possibility to distribute monitoring over multiple locations, but also as a single instance if the monitoring environment isn't that big or there are no remote/DMZ location.

So the user need to choose if he uses a single instance or want to use Icinga 2 distributed.
In this case we thought about how we want to provide the monitoring configuration over Ansible.

First of all, the user need a variable to choose whether he wants to define the configuration in zones.d, custom.d directory or none if the API maybe is used.

i2_objects_dir: custom.d/
or
i2_objects_dir: zones.d/

Monitoring Code/Config

With this information we know now, where to put monitoring configuration files per default.
Then we need to give the user the ability to use its own structure. Of course we can generate the configuration in one big blob and dump it into the configuration directory but in case anyone want to debug something manually it won't be easy and frustrating.

So we came up with the following example:

i2_objects:
  - path: "{{ i2_objects_dir }}/satellite/hosts.conf"
    objects:
      - Host:                       #object type
          client01.localdomain:     #object name
            display_name: client01  #object attributes
            [...]
      - Host:
          client02.localdomain:
            display_name: client02
            [...]
      - Service:
          disk:
            check_command: disk
            host_name: client01.localdomain
            [...]
            apply:

For every object in this array we will prepare the path and generate the file with the defined objects.
The user can choose which objects he/she needs in the specific file, this enables complete control over the structure and configuration.

Parser

I already started to create something like a parser https://github.com/Icinga/ansible-icinga2/blob/master/templates/object_attributes.j2, because the quoting is in many cases very important.
For the Puppet module there's a custom parser provided, for Ansible it should be similar.
The parser should be working like a filter plugin and will return a string.

Basically we would try to replicate the parser from the puppet module https://github.com/Icinga/puppet-icinga2/blob/master/lib/puppet_x/icinga2/utils.rb and rewrite it for python.

Feel free to add your thoughts and comments. We would be happy to help out!

mkay

Future of this project; Refactoring of this role

Hi,

over the past few months, this repository got slowly abandoned, therefore, I had a talk with Feu in the forum and later with @bobapple to see how I can help.

To revive this repository I would like to make a few changes or rather a basic refactoring of this repository.

This includes the following steps:

  1. Housekeeping (clean up repo, remove unused files, update information/documentation)
  2. Rework testing setup
  3. See if refactoring of existing functionality is necessary
  4. Introduce new branching strategy (just add a devel branch; the master/main branch should only contain the latest working, tagged version)
  5. Start adding new features

I hope we can revive this repository and get this Ansible role working again :)

Best regards
Florian

sorry, icinga.icinga2 was not found on https://galaxy.ansible.com

I tried to install this ansible role but the command:

ansible-galaxy install icinga.icinga2

failed with the message:

- downloading role 'icinga2', owned by icinga [WARNING]: - icinga.icinga2 was NOT installed successfully: - sorry, icinga.icinga2 was not found on https://galaxy.ansible.com. ERROR! - you can use --ignore-errors to skip failed roles and finish processing the list.

Feature IDO PostgreSQL (IdoPostgresqlConnection)

Configuration of all IDO PostgreSQL configuration parameters. Enable and disable the feature. Additionally it can import the basic schema to a defined database. If importing is enabled, it expects an existing database, user and password.

refs #12

i2_const_* not used

The variables beginning in i2_const_ don't seem to be used anywhere.
Only the variable i2_custom_constants is.

Feature IDO MySQL (IdoMysqlConnection)

Configuration of all IDO MySQL configuration parameters. Enable and disable the feature. Additionally it can import the basic schema to a defined database. If importing is enabled, it expects an existing database, user and password.

refs #12

Installation

The Icinga 2 package is installed from the official repository by default. If the official repo is not included, the operating systems default is used.

Keep the supported distributions in mind.

Take care that the Icinga process is running and is enabled after the installation. Be mindflus of RHEL/CentOS SElinux limitations.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.