Seite wählen

NETWAYS Blog

IDO-Snap: war vorher wirklich alles besser?

Kürzlich entstand im Rahmen eines Kundenprojektes ein nettes kleines Icinga-Modul, welches ich hier vorstellen möchte.

Ein Monitoring-System ist abgesehen vom Desasterfall immer dann gefragt, wenn man Änderungen an seiner IT-Umgebung vornimmt. Firmware- oder Betriebssystemupgrades, Ausrollen von Patches, Änderungen an Sicherheitsrichtlinien – es gibt ja immer was zu tun.

Von seinem Monitoring-System möchte man dann wissen, ob hinterher alles noch so schön grün ist wie vorher. Das klappt aber nur, wenn man eine überschaubare, liebevoll gehegte und gepflegte Umgebung hat.

Die Realität sieht meist ganz anders aus. Je größer die Umgebung, desto mehr Objekte sind ständig bunt. In das schöne Grün mischt sich das kritische Rot, das meist vernachlässigte Gelb der Warnings oder das nervige Lila der Objekte mit unbekanntem Zustand.

Dann hat man noch Teams, die das Monitoring zwar mit nutzen – Instrumente wie Acknowledgements und Downtimes aber nicht einsetzen. Schließlich wissen sie ja, was gerade rot sein darf. Dies erschwert dann leider die Arbeit anderer Teams, welche plattformübergreifend Änderungen an den Systemen ausrollen müssen. Woher sollen sie wissen, welche der unbestätigten Probleme nach dem Change denn vorher schon da waren? Klar, die Historie verrät es. Aber spätestens da wird die Arbeit mühsam.

In hoch automatisierten Umgebungen ist es zudem gang und gäbe, dass deprovisionierte Systeme auch automatisiert aus dem Monitoring fallen. Wie soll man dann aber noch überprüfen können, ob denn auch wirklich die richtigen verschwunden sind? Und nicht am Ende ein paar Server zu viel, für die es dann dank Automatisierung schlimmstenfalls keine Alarmierung mehr gibt?

Diese und ähnliche Fragen stellten sich auch besagtem Kunden. Als Lösung dafür konnte ein nützliches kleines Modul entwickelt werden: IDO Status Snapshots (idosnap)

Damit lässt sich jederzeit der Status sämtlicher Objekte, die von Icinga überwacht werden, sichern. Neben dem aktuellen Zustand wird auch vermerkt, ob sich das Objekt gerade in einer Downtime befand, und im Falle eines Problems, ob dieses bereits bestätigt worden ist (Acknowledgement).

Zusätzlich lässt sich das Modul so konfigurieren, dass vor jedem Deployment aus dem Director automatisch ein Snapshot erstellt wird. Und das unabhängig davon, ob dieses Deployment manuell oder automatisiert erfolgt. Denn oft bemerkt man erst im Nachhinein, dass ein vorheriger Snapshot praktisch gewesen wäre.

Weitere Details finden sich in der Dokumentation des Moduls, viel Spaß!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Terraform – was ist das eigentlich?

Am Tag vor der OSMC finden verschiedene Workshops statt, so auch am Tag vor der OSMC 2019. Ich habe mich dazu entschieden, den Terraform Workshop zu besuchen, weil dieser am interessantesten für mich schien. Zu dem Zeitpunkt dachte ich noch nicht, dass ich in Zukunft mehr damit Arbeiten würde – doch falsch gedacht, tatsächlich habe ich mich direkt anschließend eine ganze Zeit lang damit auseinandergesetzt und vor kurzem nochmals. Ich hatte das Ziel, die Schulungsunterlagen für unsere Trainings zu prüfen und mir die User Experience anzuschauen. Dabei habe ich schnell bemerkt, dass mehr als ein Provider problematisch ist, nicht weil Terraform das nicht kann, sondern weil ein entsprechender Lehrinhalt innerhalb dieser 3 Tage mit mehr als einem Provider nur schwer zu vermitteln wäre.  

 

Jetzt zu der Frage was ist Terraform überhaupt? 

Terraform ist ein Produkt der Firma HashiCorp, welche ihren Sitz in San Francisco hat. Terraform ist nur eines der praktischen Programme des Unternehmens, weitere Programme sind Packer und Vagrant. Terraform gehört zur Gruppe IAC (Infrastructure as Code), durch diese werden Infrastrukturen durch Code verwaltet, menschliche Fehler verringert und die Produktivität gesteigert. 

 Mit Terraform lassen sich automatisiert Maschinen deployen und verwalten. Das alles geht recht einfach und schnell auf der CLI. Ein weiterer Vorteil ist, dass Terraform mit vielen unterschiedlichen Providern und Cloud Services zur Cloud Infrastructure Automation genutzt werden kann und das sogar zeitgleich. Man kann beispielsweise unsere OpenStack Maschinen verwenden, VM’s bei Amazon Web Services und Microsoft Azure haben und kann alle Maschinen über eine Terraform Instanz steuern und kontrollieren. Wie alle Produkte, die wir verwenden und lieben, ist Terraform natürlich keine Ausnahme und auch Opensource. Alle Produkte von HashiCorp sind Opensource (ausgenommen Enterprise Versionen). 

 

Man muss sich zwar erst mit Terraform vertraut machen, aber sobald man das hat, ist Terraform sehr einfach zu bedienen. Allerdings muss man sich immer fit halten, was die Programmsprache angeht, da HashiCorp in neuen Versionen gerne mal einiges ändert. Je nachdem wie man es sieht ist Terraform Vagrant für Server. Aber nicht nur große Cloud Provider lassen sich verwalten, sondern auch DNS-Dienste (hier eine detaillierte Liste mit unterstützten Providern https://www.terraform.io/docs/providers/index.html).  

 

Die Konfiguration von Terraform erfolgt über eine oder mehrere Dateien welche auf .tf enden. Wie die Datei(en) heißen, ist dabei völlig egal. Wie bereits angedeutet ist es egal, ob alles in einer Datei steht oder man mehrere Dateien hat. Es empfiehlt sich aus Gründen der Übersichtlichkeit eine Provider-, Main- und Resources.tf Datei anzulegen. In der Provider.tf (wie der Name schon verrät) wird der Provider bzw. die Provider und deren Zugangsdaten und Projekte angelegt. In der Main.tf stehen Dinge wie Image (Betriebssystem), Ressourcen, Größe der Festplatte, aber auch der SSH Key des Nutzers. In der Ressources.tf stehen Dinge wie Security Groups, Konfiguration der Subnetzeaber auch IP-Konfigurationen, usw…  

 

Sobald alles vollständig konfiguriert ist, führt man $ terraform init und $ terraform apply aus und, wenn alles richtig ist, hat man seine laufende(n) VM(s). Und das, ohne jede einzeln deployen zu müssen. Das verringert den Zeitaufwand sehr stark und minimiert die Fehlerquote. 

 

Terraform ist also gerade wenn man viel mit virtuellen Maschinen und unterschiedlichen Providern arbeitet ein sehr hilfreiches und praktisches Tool, welches sehr nützlich sein kann. Ich kann Terraform (wie auch die anderen Produkte von HashiCorp) nur empfehlen. Es ist wirklich leicht zu bedienen und erleichtert die Arbeit ungemein. 

Nathaniel Donahue
Nathaniel Donahue
Technical Service Manager

Nathaniel hat 2022 seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS erfolgreich abgeschlossen. Seitdem unterstützt er sein Team im Bereich Operations vor allem beim Betriebsconsulting. In seiner Freizeit ist Nathaniel gerne unterwegs mit Freunden oder reist in der Gegend herum. Ansonsten schnappt er sich gerne mal sein Fahrrad oder geht Schwimmen.

Ansible – AWX|Tower State handling on Workflows

The Ansible Tower or its upstream AWX provides an easy to use GUI to handle Ansible tasks and schedules. Playbooks are configured as templates and as the name suggests, they can be modified to the needs, extended by variables, a survey or tags.

Furthermore those templates can be logically grouped, connected and visualised in Workflows.

The downside to those Workflows, all playbooks affected by this are executed separately and can’t access each others variables. On first glance we maybe only spot that we can define variables for the whole workflow but those are not changeable throughout the flow.

But there is a solution, which is the module set_stats. This module allows to save or accumulate variables and make them available for other playbooks within the workflow.

As an example we could use the monitoring environment when setting downtimes.

workflow

As a downtime is created before a maintenance and should be gone when the maintenance is done. This creates a dependency on the first task, which can be solved as we save the result of the first tasks with the set_stats module.


      - name: schedule downtimes
        icinga2_downtimes:
          state: "{{ downtime_icinga_state | default('present') }}"
          host: ***
          author: "{{ icinga2_downtimes_author | default('ansible_downtime') }}"
          comment: "{{ icinga2_downtimes_comment | default('Downtime scheduled by Ansible') }}"
          duration: "{{ icinga2_downtimes_duration | default(omit) }}"
        register: content
 
      - set_stats:
          data:
            downtime: "{{ content }}"

The content of the data will be now available to all playbooks included by the workflow. The variable is also shown as artefacts in the GUI.

artefacts

Keep in mind that the variable will be part of the extra variables for all other playbooks. As covered in the variable precedence it will overwrite any other variable named the same.

With this module you can reorganise your playbooks and connect them in workflows. This allows you to have a more flexible automation than before.

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.

Ansible – Loop over multiple tasks

ansible logo

The last time I wrote about Ansible and the possibility to use blocks to group multiple tasks. Which you can read here. Sadly this feature does not work with loop, so there is no clean way to loop over multiple tasks in a play without writing the same loop statement at tasks over and over.

But when we come across the need of tasks which depend on each other, for example, we execute a script with a certain parameter and its result is necessary for the upcoming tasks.

Let’s go through a common example, creating a site consists of a few steps. Creating the directory, creating the vhost and then enabling the site.


- name: "create {{ site }} directory"
  file:
    ensure: directory
    dest: "/var/www/{{ site }}"
    
- name: "create {{ site }}"
  template:
    src: vhost.j2
    dest: "/etc/apache2/sites-available/{{ site }}"
  register: vhost

- name: "enable {{ site }}"
  command: /usr/sbin/a2ensite "{{ site }}"
  register: result
  when: vhost.changed
  changed_when: "'Enabling site' in result.stdout"
  notify: apache_reload

We could use a loop for each tasks and afterwards find the right result for the next task to depend on. But the styleguide will warn you if you try to use Jinja2 syntax in when statements.

So the best solution to this is to use include_tasks, which can include a file with tasks. This task is allowed to have a loop directive and so we can include it multiple times.
Lets see how this would apply to our scenario:


- set_fact:
    sites:
      - default
      - icingaweb2

- name: create vhosts
  include_tasks: create-vhosts.yml
  loop: "{{ sites }}"
  loop_control:
    loop_var: site


In the Result we can see clearly that all tasks are applied for each element in the sites variable.


TASK [set_fact] *********************************************
ok: [localhost]

TASK [create vhosts] ****************************************
included: /Users/twening/Documents/netways/ansible_test20/create-vhosts.yml for localhost => (item=default)
included: /Users/twening/Documents/netways/ansible_test20/create-vhosts.yml for localhost => (item=icingaweb2)

TASK [create default directory] *****************************
ok: [localhost]

TASK [create default] ***************************************
ok: [localhost]

TASK [enable default] ***************************************
ok: [localhost]

TASK [create icingaweb2 directory] **************************
ok: [localhost]

TASK [create icingaweb2] ************************************
ok: [localhost]

TASK [enable icingaweb2] ************************************
ok: [localhost]

PLAY RECAP **************************************************
localhost                  : ok=10   changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0


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.

Ansible Host-Gruppen: Wer gehört zu wem?

Immer wieder kommt es vor, dass ich in größeren Ansible-Umgebungen arbeite. Diese enthalten eine Vielzahl von verschiedenen Gruppen im Inventory, die sich auch mal aus anderen Host-Gruppen zusammen setzen. Da ist es nicht immer leicht den Überblick zu behalten.
Da kommt es schon mal vor, prüfen zu wollen oder zu müssen ob alle Gruppen richtig aufgebaut sind oder korrekt interpretiert werden.
Nach ein wenig Recherche war auch schnell mit einem einfachen Ein-Zeiler eine Lösung gefunden, um sich anzeigen zu lassen in welcher Gruppe die einzelnen Server einsortiert sind oder wie sich die Gruppe im Ansible-Inventory zusammen setzt

[code lang=“plain“]
ansible -i <inventory> localhost -m debug -a ‚var=groups‘
[/code]

Dabei lässt sich entweder das Inventory-Verzeichnis oder eine konkrete Inventory-Hostdatei angeben.
Und weil es mit einem Beispiel immer besser ist:

[code lang=“bash“]
ansible -i hosts localhost -m debug -a ‚var=groups‘
localhost | SUCCESS => {
"groups": {
"all": [
"maja42310",
"maja42444",
"willy1334",
"willy24242",
"koenigin_blau"
],
"drohnen": [
"willy1334",
"willy24242"
],
"honigbienen": [
"maja42310",
"maja42444"
],
"honigbienenvolk": [
"maja42310",
"maja42444",
"willy1334",
"willy24242",
"koenigin_blau"
],
"koenigin": [
"koenigin_blau"
],
"ungrouped": []
}
}
[/code]

Da ich mir das nun mehr als ein mal nicht merken konnte, dachte ich mir ich schreib das mal hier auf. Vielleicht hilft es ja dem ein oder anderen und ich kann es mir jetzt besser merken:)

Wenn Ihr noch mehr über Ansible erfahren wollt, dann besucht doch einfach eines unserer Trainings bei Netways Events. Sollte es schon etwas konkreter sein und Ihr benötigt gezielt Hilfe, fragt doch gerne unsere Kollegen vom Sales Team ob Ihr nicht Unterstützung von Netways Professional Service bekommt.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.