Seite wählen

NETWAYS Blog

Icinga mit IcingaDB auf Ubuntu 20.04 / 22.04 installieren

Wer nach einer Open Source Monitoring Lösung zur System- und Netzwerküberwachung sucht, kommt an Icinga (auch als Icinga 2 bekannt) nicht vorbei. Es hilft dir dabei Verfügbarkeit, Leistung und Trends der gesamten IT-Infrastruktur zu überwachen. Dank individualisierbarer Benachrichtigungseinstellungen kommen die Informationen immer genau an der gewünschten Stelle an.

Mit diesem Guide wollen wir dir dabei helfen, einen leichten Einstieg ins Icinga Monitoring zu finden und Icinga, Icinga DB und Redis erfolgreich installierst.
In diesem Guide spielt die IDO keine Rolle mehr, da diese von Icinga DB als Datenbackend abgelöst wurde. Die neue Komponente sorgt für eine bessere Performance und Skalierbarkeit von Icinga.

Voraussetzungen für die Icinga und Icinga DB Installation

Damit dieser Guide erfolgreich umgesetzt werden kann, gibt es einige wichtige Voraussetzungen:

  • Einen Ubuntu 20.04 / 22.04 Server mit mindestens 2 GB RAM und 20 GB freiem Speicherplatz
  • Der sudo – Benutzer ist auf dem Server eingerichtet und du hast das Recht, ihn zu nutzen
  • Zugriff auf eine SQL-Datenbank (in diesem Guide wird MariaDB verwendet)
  • Die aktuellste PHP-Version ist auf dem Server installiert
  • Eine Internetverbindung auf den Server
  • Optional: Ein Webserver (Apache, Nginx, etc.) ist auf dem Server installiert (als Teil des LAMP-Stack)

Du kannst hinter alle diese Punkte einen Haken setzen? Dann legen wir los!

Anmerkung: Alle nachfolgende Schritte werden als root-User durchgeführt. Überprüfe, ob du den richtigen Benutzer verwendest!

Schritt 1: Icinga Repository hinzufügen

Um die aktuelle Version von Icinga zu installieren, wird das offizielle Icinga-Repository zu unserem System hinzugefügt. Dazu führst du in deinem Terminal die folgenden Befehle aus:

apt update 
apt -y install apt-transport-https wget gnupg 
wget -O - https://packages.icinga.com/icinga.key | gpg --dearmor -o /usr/share/keyrings/icinga-archive-keyring.gpg
. /etc/os-release; if [ ! -z ${UBUNTU_CODENAME+x} ]; then DIST="${UBUNTU_CODENAME}"; else DIST="$(lsb_release -c| awk '{print $2}')"; fi; \
 echo "deb [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/ubuntu icinga-${DIST} main" > \
 /etc/apt/sources.list.d/${DIST}-icinga.list  
echo "deb-src [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/ubuntu icinga-${DIST} main" >> \
 /etc/apt/sources.list.d/${DIST}-icinga.list
apt update

Sobald dieser Befehlsblock erfolgreich durchgelaufen ist, siehst du in deinem Terminal, dass die neuen Repos nun in deiner Liste zu finden sind. Es sollte in etwa so aussehen:

Screenshot eines Ubuntu Terminals, bei dem eine Auflistung aller dem System hinzugefügten Repositories zu sehen ist. Der Screenshot soll verdeutlichen wie es aussieht, wenn die offiziellen Icinga Repositores zum System hinzugefügt wurden

Schritt 2: Icinga-Paket auf Ubuntu 20.04 oder Ubuntu 22.04 installieren

Da du nun Zugriff auf das Icinga-Repository hast, kannst du direkt damit weiter machen und das Icinga Paket installieren. Dafür nutzt du:

apt install -y icinga2

Dieses Paket ist die Basis der gesamten Icinga 2 Monitoring Installation. Um zu überprüfen, ob die Installation erfolgreich war, nutzt du

icinga2 daemon -C

Mithilfe dieses Befehls kannst zukünftige Konfigurationsanpassungen mit einem Terminalbefehl überprüfen.

Screenshot eines Ubuntu Terminals, bei dem das Kommando icinga2 daemon -C inklusive seiner Ausgabe zu sehen ist. Der Screenshot soll verdeutlichen wie die Ausgabe dieses Befehls im Terminal visualisiert wird

Schritt 3: Aktivieren der Icinga API und Installieren der Monitoring Plugins

Ein Monitoringsystem ist nur so gut wie die Daten, die es sammelt und die Checks, die ausgeführt werden.
Für moderne, aus Nagios hervorgegangene Open Source Monitoring Systeme haben sich die bereits am Anfang angesprochenen Monitoring Plugins etabliert. Diese installierst du im nächsten Schritt.

Damit kannst du direkt nach Abschluss dieses Icinga Installationsguides die ersten Checks anlegen und mit deinem System Monitoring oder Netzwerk Monitoring starten. Dafür nutzt du im Terminal den folgenden Befehl:

apt install monitoring-plugins

 

Um die Ergebnisse der Check Plugins abzurufen oder mit Icinga zu interagieren, muss die Icinga API eingerichtet werden. Das machst du ganz einfach mit diesen beiden Befehlen:

icinga2 api setup
systemctl restart icinga2

Damit legst du in der Konfigurationsdatei /etc/icinga2/conf.d/api-users.conf einen API-User (inkl. zufallsgeneriertem Passwort) an.
(Die hier erzeugten Zugangsdaten benötigst du im weiteren Verlauf bei der Einrichtung von Icinga Web. Du wirst im entsprechenden Schritt noch einmal darauf hingewiesen!)

Falls du bestimmte Vorgaben erfüllen musst oder generell mehr über die Icinga API erfahren willst, lege ich dir entsprechende Seite in den Icinga Docs ans Herz.

Weiter geht es mit der Einrichtung von Icinga DB.

Schritt 4: Icinga DB einrichten

Icinga DB ist keine, wie der Name vielleicht vermuten lässt, eigenständige Datenbank.
Vielmehr handelt es sich hierbei um eine Sammlung von Komponenten zur Veröffentlichung, Synchronisierung und Visualisierung von Überwachungsdaten im Icinga-Ökosystem. Dazu gehören Redis, das IcingaDB-Feature des Icinga Core und der Icinga DB-Daemon.

Schritt 4.1: Redis Server installieren

Um Icinga DB zu nutzen, benötigst du einen Redis Server. Für einen reibungslosen Installations- und Konfigurationsprozess bietet das Icinga Team ein eigenes Redis-Paket an, das speziell auf Icinga zugeschnitten ist.
icindadb-redis umfasst deshalb eine aktuelle Version von Redis und kommt out of the box mit Anpassungen der Freigabe auf Port 6380 statt dem sonst für Redis üblichen Port 6379.
Das Paket installierst du mit:

apt install icingadb-redis

Hinweis: Der Redis Server kann grundsätzlich überall in deiner Icinga Umgebung installiert werden. Es ist jedoch sinnvoll, diesen auf dem zentralen Icinga-Node zu installieren, um die Latenz so niedrig wie möglich zu halten.
Ein bereits vorhandener und selbst konfigurierter Redis Server kann ebenso verwendet werden. Hier sind jedoch entsprechende Anpassungen notwendig, weshalb die Nutzung des entsprechenden Icinga-Pakets empfohlen wird.

Schritt 4.2: Aktivieren von Redis

Die Installation von icingadb-redis installiert automatisch alle systemd Dateien, die Icinga DB Redis braucht. Der Service kann also direkt aktiviert und gestartet werden:

systemctl enable --now icingadb-redis-server

Standardmäßig lauscht icingadb-redis nur auf 127.0.0.1, also deinem localhost. Wenn Icinga Web 2 oder Icinga 2 auf einer anderen Node laufen als Redis, dann muss das in der Konfigurationsdatei

/etc/icingadb-redis/icingadb-redis.conf

angepasst werden.

Auch wenn in diesem Guide alle Schritte auf einer Icinga-Node durchgeführt werden, wird die Konfigurationsdatei so angepasst, dass das Aufsetzen weiterer Nodes in der Zukunft kein Problem darstellen.
Dafür sind innerhalb der Konfigurationsdatei zwei kleine Anpassungen notwendig:

  • protected-mode von yes auf no
  • bind von 127.0.0.1 auf 0.0.0.0 –> Dadurch können alle Interfaces auf Redis zugreifen

Um die Änderungen zu aktivieren, muss der Service neu gestartet werden:

systemctl restart icingadb-redis

Damit Icinga über Icinga DB später Daten an Redis weitergibt, muss das entsprechende Feature aktiviert und Icinga anschließend neu gestartet werden:

icinga2 feature enable icingadb 
systemctl restart icinga2

Sicherheitshinweis:
Redis hat standardmäßig KEINE Authentifizierung aktiviert!
Mit der Änderung von bind auf 0.0.0.0 wird dringend, um unbefugten Zugriff zu verhindern, empfohlen, einige Sicherheitsmaßnahmen durchzuführen. Dazu gehören: Einrichten eines Passworts, Aufstellen von Firewall-Regeln oder Einrichten von TLS.
Zur einfacheren Installation wird in diesem Guide jedoch auf diese Schritte verzichtet! Diese Anpassungen lassen sich ebenfalls nachträglich durchführen.

Schritt 4.3: Installieren von Icinga DB und einrichten der Datenbank

Nachdem im gerade abgeschlossenen Schritt die Schnittstelle von Icinga 2 zu Icinga DB aktiviert wurde, wird nun Icinga DB selbst installiert:

apt-get install icingadb

Damit das gerade installierte Paket die verarbeiteten Daten auch speichern kann, muss eine Datenbank für Icinga DB angelegt und Zugriff dazu gewährt werden. (In diesem Guide wird MariaDB 10.6.12 verwendet. Die Einrichtung von MySQL ist mit den gleichen Befehlen möglich. Nutzt du PostgreSQL findest du die entsprechenden Befehle in den offiziellen Icinga Docs.)

mysql -u root -p 
CREATE DATABASE icingadb; 
CREATE USER 'icingadb'@'localhost' IDENTIFIED BY 'SAFEPASSWORDINHERE'; 
GRANT ALL ON icingadb.* TO 'icingadb'@'localhost';

Damit hast du die Datenbank und den Datenbank-Nutzer erfolgreich angelegt. Icinga DB stellt zudem ein Datenbankschema zur Verfügung, dass nun importiert wird:

mysql -u root -p icingadb </usr/share/icingadb/schema/mysql/schema.sql

Schritt 4.3: Zugriffsberechtigungen anpassen

Während der Installation von Icinga DB wird unter /etc/icingadb/config.yml eine Konfigurationsdatei angelegt, die mit Standardwerten gefüllt ist. Damit die Verbindung von Icinga DB zu Redis und MariaDB erfolgreich stattfinden kann, müssen diese Werte überprüft und gegebenenfalls angepasst werden.

Öffne also den Pfad mit einem Texteditor deiner Wahl und passe die folgenden Parameter gegebenenfalls an.

Für die Datenbank:
host mit dem entsprechenden Hostname/Host-IP deiner Datenbank, database mit dem Namen deiner Datenbank (in diesem Guide icingadb), user mit dem Namen deines Datenbanknutzers und password mit dem Passwort, dass du für deine Datenbank vergeben hast.

Für Redis:
host mit dem entsprechenden Hostname/Host-IP deiner Redis Instanz. Wenn du während der Installation deines Redis-Servers den port geändert oder ein password gesetzt hast, musst du dies hier ebenfalls eintragen.

Sobald diese Änderungen abgeschlossen sind, kann der Icinga DB Service aktiviert werden:

systemctl enable --now icingadb

Schritt 5: Icinga Node Wizard ausführen

Nachdem die Grundkomponenten für die Nutzung von Icinga installiert und konfiguriert wurden, muss noch er Node Wizard ausgeführt werden. Dieses interaktive Skript hilft dir dabei, Zonen einzustellen und die Endpunkte deines Icinga Monitoring festzulegen.

Dafür gibst du im Terminal diesen Befehl ein:

icinga2 node wizard

Da hier einige wichtige Einstellungen vorgenommen werden, hier eine Übersicht der einzelnen Punkte:

  • Is this agent/satellite setup? –> Hier ’n‘ eingeben und mit Enter bestätigen
  • Specifiy common name (FQDN of your master) –> Nichts eingeben und mit Enter bestätigen
  • Master zone name –> Nichts eingeben und mit Enter bestätigen
  • Specify additional global zones –> Nichts eingeben und mit Enter bestätigen
  • Specify API bind host/port –> Nichts eingeben und mit Enter bestätigen
  • Bind Host –> Nichts eingeben und mit Enter bestätigen
  • Bind Port –> Nichts eingeben und mit Enter bestätigen
  • Disable inclusion of conf.d directory –> Nichts eingeben und mit Enter bestätigen

Screenshot der Ubuntu Terminalausgabe, bei dem das Kommando icinga2 node wizard inklusive seiner Ausgabe zu sehen ist. Der Screenshot soll verdeutlichen wie die Ausgabe dieses Befehls im Terminal visualisiert wird

Im Anschluss verifizierst du die getätigte Konfiguration und lädst Icinga 2 neu:

icinga2 daemon -C 
systemctl reload icinga2

Damit hast alle wichtigen Schritte zur Icinga und Icinga DB abgeschlossen!

Wie gehts es nun weiter?

Herzlichen Glückwunsch, du hast erfolgreich ein lokales Icinga installiert und konfiguriert! Damit könntest du nun direkt loslegen und über die Icinga2 API deine ersten Objekte anlegen, Actions triggern oder Templates bauen. Welche API-Calls dir dafür zur Verfügung stehen, kannst du übersichtlich in den Icinga Docs nachlesen.

Grundsätzlich ist die Icinga Installation nun einsatzbereit. Damit eine Open Source Monitoring Lösung wie Icinga aber produktiv genutzt werden kann, müssen die gesammelten Daten noch visualisiert werden.
Dabei helfen Icinga Web und Icinga DB Web. Wie diesen beiden Tools installiert und mit der hier aufgesetzten Basis verbunden werden erfährst du im Installationsguide zu Icinga Web und Icinga DB Web auf Ubuntu 20.04 / 22.04.

ServiceNow Data Asset Import mit dem Director

Hallo Liebe Leser dieses Blogs,

nach einer weile der Abwesenheit hab ich heute die Freude ihnen etwas näher bringen zu dürfen.
Da viele unserer Kunden inzwischen auch ServiceNow verwenden und diese auch als Assetmanagement / CMDB verwenden.

Kommt doch die Frage auf wie man gegebenenfalls hier die Daten abfragen kann um Sie in den Director zu importieren um daraus dann Hosts/Services zur Überwachung zu formen.Ich versuche in diesem kleinen Blogpost zumindest einen Ansatzpunkt hierzu aufzuzeigen. Viele verwenden in diesem Fall ja ServiceNow als SaaS, aber es gibt auch Kunden welche es als On Prem einsetzen.
Aber fangen wir an 🙂 in diesem Fall ist der Anlaufpunkt hier die ServiceNow API, wer hätte es gedacht.
In diesem Fall ziehe ich mal die folgende API (Link) zur rate:

Hier wird die ‚cmdb-instance‘ in welcher die CMDB Daten landen dokumentiert. Es ist aber zu bedenken, dass die Instanz natürlich abweichen kann daher ist dies bitte nicht direkt 1:1 zu übernehmen.
Wir feuern per curl gegen die ServiceNow API, die folgende Abfrage… in Hoffnung, dass wir valides JSON zurückerhalten mit all unseren Objekten.


curl -k -s -S -i -u 'servicenow_apiuser:servicenow_apiuserpassword' -H 'Accept: application/json' -H 'X-HTTP-Method-Override: GET' -X POST 'https://instance.servicenow.com/api/now/cmdb/instance/cmdb_ci_linux_server'

und wir erhalten als Antwort das folgende JSON:


{
"result": {
...
"attributes": {
"firewall_status": "Intranet",
"os_address_width": "",
"sys_updated_on": "2020-07-08 11:16:51",
"sys_created_by": "glide.maint",
"warranty_expiration": "",
"ram": "2048",
"cpu_name": "",
"cpu_speed": "2800",
"classification": "Production",
"disk_space": "40",
"dns_domain": "",
"assigned": "2020-01-04 07:00:00",
"floppy": "",
...
"sys_class_name": "cmdb_ci_linux_server",
...
"cpu_count": "1",
...
"os_version": "2.6.9-22.0.1.ELsmp",
"serial_number": "",
"attributes": "",
...
"form_factor": "",
"cpu_core_count": "",
"sys_updated_by": "system",
"sys_created_on": "2008-10-26 17:17:28",
...
"name": "PS LinuxApp01",
"default_gateway": "",
"chassis_type": "",
"sys_id": "3a290cc60a0a0bb400000bdb386af1cf",
"po_number": "",
"checked_in": "",
...
"comments": "",
"os": "Linux Red Hat",
"sys_mod_count": "24",
"monitor": "false",
"model_id": {
"display_value": "Iris 5875",
"link": "https://instance.servicenow.com/api/now/table/cmdb_model/5f5fbcc3c0a8010e00f3b27814f3b96b",
"value": "5f5fbcc3c0a8010e00f3b27814f3b96b"
},
"ip_address": "192.168.178.1",
"duplicate_of": "",
"location": {
"display_value": "Somewhere Street, Someplace, State",
},
"category": "Do not migrate to asset",
"fault_count": "0",
"host_name": "",
"lease_id": ""
},
}

Den Output schreiben wir als Datei raus, so dass wir hier als Beipiel eine Datei haben, mit der wir weiterarbeiten können. Als Beispiel nennen wir diese servicenow.json
(Exclaimer) Ich habe das JSON hier als Beispiel mal extrem zusammengekürzt, damit wir thementechnisch nicht zu weit Abdriften.
Anyway, aber damit lässt sich arbeiten.
Damit wir mit diesem JSON arbeiten können, verwenden wir das Tool ‚jq‘, um relevante key/value Paare herauszufiltern.
Ich habe hier mal den folgenden ‚jq‘ Aufruf verwendet:


jq -j '.result.attributes.os,",",.result.attributes.ip_address,",",.result.attributes.classification,",",.result.attributes.sys_class_name,",",.result.attributes.name,",",.result.attributes.location.display_value,","' servicenow.json

Der somit gewonnene Output ist der folgende, bitte beachtet die ‚,‘ Kommata. Die meisten werden schon ahnen worauf ich gleich hinaus will.
Zurück zu dem nun mit ‚jq‘ aufbereiteteb Output, dieser ist der folgende:


Linux Red Hat,192.168.178.1,Production,cmdb_ci_linux_server,PS LinuxApp01,Somewhere Street, Someplace, State,

Mit etwas Bash Scripting kann man das schön automatisieren und hat am Ende dieses Vorgangs eine CSV Datei, die man hervorragend im Director per Fileshipper weiterverarbeiten kann.
Das mit dem CSV ist eine Geschmacksfrage, denn man kann auch direkt JSON per Fileshipper importieren … ich würde aber dazu tendieren, die Datenmenge durch etwas vorfiltern zu verkleinern. So eine Filterung, wie gesehen, kann auch per ‚jq‘ erfolgen, so dass man ein kleineres JSON File erhält.
Wer wissen möchte, wie man mit dem Director einen Fileshipper-Import durchführt, dem sei der Blogpost meines Kollegen Johannes empfohlen.

Blogpost Director Fileshipper Import

Das war schon mein kleines Intermezzo wie ServiceNow-Data-Assets per Fileshipper in den Director zu importiert sind.
Bis zum nächsten Mal

Mit freundlichem Gruß
David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Icinga2 und Influx2: So bringen wir beide zum reden

Influxdata LogoAuch wenn die Überschrift es vermuten lässt. Das hier ist kein Clickbait sondern eine Kurzanleitung zum Thema.

Das Problem: Seitdem die time series database influxdb in der Version 2.0 erschienen es kann man das icinga2 influx feature nicht mehr ohne weiteres nutzen. Ein Grund ist, es gibt keine influx database und keine influx retention policy mehr. Beides ist konzeptuell jetzt in sogenannten buckets zusammengefasst. Damit nicht genug. Man greift nicht mehr mit einem user/password auf influx zu, sondern mit Hilfe eines Tokens

Die Lösung: Es gibt den v1 compatibility mode. So legt man einen bucket mit einer retention policy von 14 Tagen an und nutzt ihn.

$ influx bucket create --name icinga2 --org myCompany --retention 336h
$ influx bucket list
ID Name Retention Organization ID
9be740dd7f1e5dd0 _monitoring 168h0m0s e3010cef6e5b64bf
d6e0a548f3ea1451 _tasks 72h0m0s e3010cef6e5b64bf
4d59849554d88e25 icinga2 336h0m0s e3010cef6e5b64bf
$ influx v1 auth create --username icinga2 --write-bucket 4d59849554d88e25
$ influx v1 dbrp create --bucket-id 4d59849554d88e25 --db icinga2 --rp 14Tage

Das ganze lässt sich jetzt einfach auf Seiten Icinga nutzen:

$ cat /etc/icinga2/features-enabled/influxdb.conf

object InfluxdbWriter „influxdb“ {
host = „127.0.0.1“
port = 8086
database = „icinga2“
flush_threshold = 1024
flush_interval = 10s
username = „icinga2“
password = „password“
enable_send_thresholds = true
enable_send_metadata = true
[…]
}

Nach einem icinga restart kann man im influx Frontend sehen, dass Informationen eingehen. Um mehr über influx und grafana zu lernen bietet Netways eine 2-tägige InfluxDB Schulung  an.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Zugangsdaten und globale Variablen in Icinga 2

Viele Kunden fragen mich, wie man zentral Zugangsdaten oder allgemeine Variablen in Icinga 2 verwalten kann. Icinga 1.x und Nagios hatte für solche Zwecke die resources.cfg, dort wurden zentrale Macros wie $USER1$ usw. konfiguriert.

Nun hat Icinga 2 einen relativen ähnlichen Mechanismus, mit dem man an einer zentralen Stelle globale Konstanten bzw. Variablen speichern kann. Dann können diese überall in der Konfiguration benutzt werden. Aber leider nicht als Macro, was die Verwendung mit dem Director etwas schwieriger macht.

Aber dafür gibt es Abhilfe, auch dafür pflegen wir die Werte in der /etc/icinga2/constants.conf

const GlobalVars = {
  OracleDbUser = "svcicinga"
  OracleDbPassword = "hunter2"
}

Nun fehlt noch eine kleine Konfiguration, damit diese Variablen auch überall verfügbar sind, dazu bearbeiten wir die Datei /etc/icinga2/conf.d/app.conf und die IcingaApplication.

object IcingaApplication "app" {
  vars = GlobalVars
}

Jetzt sind die Variablen überall auch als Macro verfügbar.

vars.oracle_health_username = "$OracleDbUser$"
vars.oracle_health_password = "$OracleDbPassword$"

Ich wünsche viel Spaß beim Ausprobieren, und hoffentlich ruhige Feiertage und einen guten Rutsch ins Jahr 2020!

Bildrechte: Wikimedia Commons – von Psyomjesus

Managing your Ansible Environment with Galaxy

Ansible is known for its simplicity, lightweight footprint and flexibility to configure nearly any device in your infrastructure. Therefore it’s used in large scale environments shared between teams or departments. This leads to even bigger Ansible environments which need to be tracked or managed in version control systems like Git.

Mostly environments grow with their usage over time, in this case it can happen that all roles are managed inside one big repository. Which will eventually lead to quite messy configuration and loss of knowledge if roles are tested or work the way they supposed to work.

Ansible provides a solution which is called Galaxy, it’s basically a command line tool which keeps your environment structured, lightweight and enforces your roles to be available in a specific version.

First of all you can use the tool to download and manage roles from the Ansible Galaxy which hosts many roles written by open-source enthusiasts. 🙂


# ansible-galaxy install geerlingguy.ntp -v
Using /Users/twening/ansible.cfg as config file
 - downloading role 'ntp', owned by geerlingguy
 - downloading role from https://github.com/geerlingguy/ansible-role-ntp/archive/1.6.4.tar.gz
 - extracting geerlingguy.ntp to /Users/twening/.ansible/roles/geerlingguy.ntp
 - geerlingguy.ntp (1.6.4) was installed successfully

# ansible-galaxy list
# /Users/twening/.ansible/roles
 - geerlingguy.apache, 3.1.0
 - geerlingguy.ntp, 1.6.4
 - geerlingguy.mysql, 2.9.5

Furthermore it can handle roles from your own Git based repository. Tags, branches and commit hashes can be used to ensure it’s installed in the right version.


ansible-galaxy install git+https://github.com/Icinga/ansible-icinga2.git,v0.2.0
 - extracting ansible-icinga2 to /Users/twening/.ansible/roles/ansible-icinga2
 - ansible-icinga2 (v0.2.0) was installed successfully

It’s pretty neat but how does this help us in large environments with hundreds of roles?

The galaxy command can read requirement files, which are passed with the „-r“ flag. This requirements.yml file can be a replacement for roles in the roles path and includes all managed roles of the environment.


# vim requirements.yml
- src: https://github.com/Icinga/ansible-icinga2.git
  version: v0.2.0
  name: icinga2

- src: geerlingguy.mysql
  version: 2.9.5
  name: mysql

Then run ansible-galaxy with the „–role-file“ parameter and let galaxy manage all your roles.


# ansible-galaxy install -r requirements.yml
 - icinga2 (v0.2.0) is already installed, skipping.
 - downloading role 'mysql', owned by geerlingguy
 - downloading role from https://github.com/geerlingguy/ansible-role-mysql/archive/2.9.5.tar.gz
 - extracting mysql to /Users/twening/.ansible/roles/mysql
 - mysql (2.9.5) was installed successfully

In case you work with Ansible AWX, you can easily replace all your roles with this file in the roles directory and AWX will download and manage your roles directory automatically.

A example project could look like this.


awx_project/
├── example_playbook.yml
├── group_vars
├── host_vars
├── hosts
└── roles
    └── requirements.yml

In summary, in large environments try to keep your code and configuration data separated, try to maintain your roles in their own repository to avoid conflicts at the main project.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Manager Consulting

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.