Select Page

NETWAYS Blog

Ansible – How to create reusable tasks

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. Often tasks could be used in multiple playbooks to combine update routines, setting downtimes at an API or update data at the central asset management.

To use external tasks in Ansible we use the include_task module. This module dynamically includes the tasks from the given file. When used in a specific plays we would assign play specific variables to avoid confusion. For example:


vim tasks/get_ldap_user.yml

- name: get user from ldap
  register: users
  community.general.ldap_search:
    bind_pw: "{{ myplay_ad_bind_pw }}"
    bind_dn: "{{ myplay_ad_bind_dn }}"
    server_uri: "{{ myplay_ad_server }}"
    dn: "{{ myplay_ad_user_dn }}"
    filter: "(&(ObjectClass=user)(objectCategory=person)(mail={{ myplay_usermail }}))"
    scope: children
    attrs:
      - cn
      - mail
      - memberOf
      - distinguishedName

If this task should be used in another playbook to reduce the amount of code or is used again with other conditions or values. Therefore the variables need to be overwritten or if it is another playbook the variables are named wrong.

The solve this problem change the variables to unused generic variables. And assign your own variables in the include_task statement.


vim tasks/get_ldap_user.yml

- name: get user from ldap
  register: users
  community.general.ldap_search:
    bind_pw: "{{ _ad_bind_pw }}"
    bind_dn: "{{ _ad_bind_dn }}"
    server_uri: "{{ _ad_server }}"
    dn: "{{ _ad_user_dn }}"
    filter: "(&(ObjectClass=user)(objectCategory=person)(mail={{ _ad_usermail }}))"
    scope: children
    attrs:
      - cn
      - mail
      - memberOf
      - distinguishedName

The include_task vars parameter provides own variables to the tasks.


vim plays/user_management.yml
[...]
- name: check if user exists in ldap
  include_tasks:
    file: tasks/get_ldap_user.yml
  vars: 
    _ad_bind_pw: "{{ play_ad_pw }}"
    _ad_bind_dn: "{{ play_ad_user }}"
    _ad_server: "{{ play_ad_server }}"
    _ad_user_dn: "OU=users,DC=example,DC=de"
    _ad_usermail: "{{ play_usermail }}"

This can be easily combined with loops, to enhance the reusability of your tasks even more! Checkout this blogpost about looping multiple tasks. Ansible – Loop over multiple tasks

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.

Neues vom Icinga-Installer

Mein letzter Blog Icinga Installation mit Director in 10 Minuten zeigte wie man mit dem Icinga-Installer und etwas Nacharbeit per Hand zu einem arbeitsfähigen Icinga-Server mit Director bekam.

Inzwischen ist eine neue Version 0.5.0 vom Icinga-Installer veröffentlicht, die einem auch komplett die Installation und Konfiguration des Directors inkl. Datenbank-Setup und erstem Kickstart-Lauf abnimmt.

Abschließend noch ein kleiner Tipp, wie unter zur Hilfenahme des Installers, die GUI des Icinga Webs ausschließlich per HTTPS ereichbar gemacht wird. Voraussetzung sind natürlich ein vorhandenes Zertifikat nebst privatem Schlüssel und das CA-zertifikat bzw. ein Chain-File. Diese müssen zuvor an den angegeben Orte im Dateisystem abgelegt werden. Die erforderlichen Einstellungen können nicht interaktiv vorgenommen werden, lassen sich aber in /etc/icinga-installer/custom-hiera.yaml (hier ein Beispiel für ein RedHat basiertes System) festlegen:


---
apache::default_vhost: false
apache::default_ssl_vhost: true
apache::default_ssl_cert: /etc/pki/tls/certs/apache.crt
apache::default_ssl_key: /etc/pki/tls/private/apache.key
apache::default_ssl_ca: /etc/pki/tls/certs/my-ca.crt

Möchte oder muss man eine CA-Chain angeben, lautet die Option apache::default_ssl_chain. Diese ersetzt die Zeile mit default_ssl_ca.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Ansible – check your data

The automation and deployment tool Ansible is able to configure applications in multiple environments. This is possible due to variables used in Roles.

Variables are key to make roles reusable, but without proper documentation or descriptions they can get complicated.
If you want to provide different scenarios which are defined by specific variables, you can provide a good documentation and hope it will be seen and understood, otherwise users will get failed runs.

But instead of failed runs with cryptic messages which show that the used variables are wrong, we can easily check beforehand if the variables are set correctly.

The Ansible module ansible.builtin.assert can provide the solution to this problem.

With Ansible when expressions you can define rules and check variables. If the conditions aren’t true the module will fail with a custom message or if true, reward the user with a custom “OK” message.


- assert:
    that: role_enable_feature is true and role_feature_settings is defined 
    success_msg: The feature is configured correctly and will be managed. 
    fail_msg: To use the feature please configure the variable role_feature_settings, please look at the documentation section X.

With this module it’s easy to guide users when they forgot to use a specific variable or if they use multiple variables which shouldn’t be used together.

If you want to learn more about Ansible, checkout our Ansible Trainings or read more on our blog.

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.

Foreman 3.0 – Was bedeutet der neue Major-Release

Wer erinnert sich noch an die letzte Versionsnummer bei Foreman mit einer 1 am Anfang? Es war eine 1.24, also 25 Minor-Releases und ein ganzer Haufen Bugfix-Releases, bis zur 2.0! Und nun nach nur 6 Releases mit einer 2.x, kommt schon die 3.0? Hat die Entwicklung hier so viel Fahrt aufgenommen? Um gleich alle Bedenken vorweg zu nehmen: Nein, Foreman nutzt die Major-Versionen um eine größere Änderung an der Infrastruktur hinzuweisen. Mit 2.0 war es die Fokussierung auf PostgreSQL als einzige Datenbank und mit 3.0 ist es das Herauslösen von Puppet in ein separates Plugin.

Puppet als separates Plugin

Das Puppet bei Foreman eine Sonderstellung gegenüber den anderen Konfigurationsmanagementlösungen hat bzw. ab jetzt hatte, ist historisch leicht zu begründen, da Foreman als Managementoberfäche für Puppet entstanden ist. Schon lange sollten die anderen Lösungen aber möglichst gleiche Funktionalität bieten und als gleichwertig betrachtet werden können. Nachdem sowohl in der Community öfters die Frage aufkam, ob man Foreman auch ganz ohne Puppet nutzen kann, als auch sich für Red Hat die Strategie zu Ansible als einzige Konfigurationsmanagementlösung geändert hat, war es nur eine Frage der Zeit, dass Puppet mit den anderen Lösungen gleichgestellt und als ein Plugin heraus gelöst wurde. Das Red Hat hierfür verständlicherweise die Entwicklungszeit zurückfahren möchte, wurde auch bereits von Anfang an klar kommuniziert und somit hat Ondrej Ezr um Unterstützung aus der Community für die weitere Pflege gebeten. Hier geht der Dank ganz klar an die ATIX AG und dmTech, die sich hierzu bereit erklärt haben, sowie iRonin, die sie dabei unterstützen.

Bereits in den letzten Versionen war das Plugin verfügbar und konnte getestet werden. Mit 3.0 wird es immer noch standardmäßig installiert, kann aber falls Puppet nicht gewünscht ist einfach deinstalliert werden. Erst mit 3.1 ist es angedacht es nicht mehr direkt mit zu installieren.

Bis jetzt sind mir hier noch keine Probleme aufgefallen, aber wenn man bedenkt, dass hier dmTech mit wesentlich größerer Umgebung in Produktion testen kann, hätte mich das auch gewundert. Daher mein Aufruf an Foreman-Nutzer ohne Puppet-Umgebung, direkt mal das Plugin zu deinstallieren und zu testen, bzw. an die mit Puppet-Umgebung zu prüfen, ob nicht doch ein Fehler in ihrer Umgebung auftritt.

Neue Hostansicht als Preview

Natürlich bleibt die Entwicklung hier nicht stehen, der nächste große Schritt wird die Modernisierung der Hostansicht sein. Diese ist zwar immer noch funktional aber unbestreitbar in die Jahre gekommen. Wer möchte kann also die Chance nutzen, die neue Ansicht aktivieren und Feedback geben. Zwar sind bereits die ersten Detailverbesserungen für die 3.0.1 angekündigt, aber nur mit Feedback von Leuten die Foreman auch täglich nutzen, kann in meinen Augen auch das bestmögliche Ergebnis erzielt werden.

Wer also die neue Hostpage sehen möchte, muss unter “Administer -> Settings -> Generic” die Option “Show Experimental Labs” aktivieren. Nun taucht im Action-Menü der Hostübersicht eine neue Option “New Detail Page” auf.

Neue Host-Action 'New Detail Page'

Diese sieht aktuell folgendermaßen aus:

Neue Hostansicht

Teil der neuen Hostansicht ist bereits jetzt eine neue Statusübersicht, weitere Tabs für die verschiedenen Plugins werden in den nächsten Minor-Releases folgen.

Neue Statusübersicht

Über Lob, Kritik oder Anregungen freut sich der Feedback-Thread im Community-Forum.

Zukunftssicherheit

Die meisten anderen Änderungen möchte ich unter Zukunftssicherheit zusammenfassen. Zum einen setzt Foreman ab 3.0 auf mod_auth_gssapi für die Kerberos-Authentifizierung, damit steht dieser auch auf EL8 nichts mehr im Weg. Zum anderen wurde der Code zum Parsen der Systemdaten aus allen Quellen in Foreman selbst verschoben, was das angedachte Refactoring erleichtern sollte.

Dazu kommen noch kleine Änderungen an Permissions, Parametern und Defaults, die sich in der Upgrade-Warnings finden. Und zu guter Letzt wurde der Support für Ubuntu 18.04 und EL7 als Plattform abgekündigt, wobei für ersteres konkret mit 3.0 der Support ausläuft, bei EL7 gilt aktuell nur EL8 ab dieser Version als bevorzugte Plattform.

Zusätzlich listen die Release Notes noch eine große Menge an Detailverbesserungen und Bugfixes auf.

Ich wünsche allen ein erfolgreiches Update, Katello-Nutzer warten darum bitte noch auf den finalen Release der Version 4.2! Und wer sich fragt wovon ich hier überhaupt rede, kann sich ja mal unsere Produktseite anschauen, die wir vor kurzem aktualisiert und erweitert haben.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Cloud-Ressourcen effizient managen: Terraform Trainer Lennart in der aktuellen iX

Der heute erreichte Grad der Virtualisierung erlaubt es, nahezu ganze Rechenzentren und ihre Netzinfrastruktur virtuell abzubilden. Dazu bedarf es eines Infrastructure-as-Code-Werkzeugs wie Terraform, das sich dem Multicloud-Management verschrieben hat. Terraform stellt Rechenzentrumsressourcen unterschiedlicher Cloud-Provider bereit – bei Bedarf auch für andere Werkzeuge.

Wie das Ganze funktioniert, erklärt unser Terraform Trainer Lennart in der aktuellen iX Ausgabe. Wenn Dich das Thema interessiert und Du vor hast, mit Terraform zu arbeiten, dann solltest Du Dich unbedingt zu einer unserer Terraform Schulungen anmelden. Dein Trainer: Lennart Betz!

Wir haben die Terraform Schulung in drei Versionen im Programm, mit Fokus auf OpenStack, AWS oder Azure. Darum geht’s bei allen dreien: Mit der aktuellen Version von Terraform und seiner Konfigurationssprache HCL (Hashicorp Configuration Language) in Version 0.12 hat sich das Vorgehen zur Automatisierung von Cloud Infrastruktur weiterentwickelt. Unsere Terraform Schulung zeigt, wie Infrastruktur mit der Terraform eigenen DSL (HCL, Hashicorp Configuration Language) idempotent realisiert wird. Neben der Theorie mit vielen Beispielen beinhalten die Fortbildungen praktische Übungen anhand von OpenStack, AWS oder Azure. Ebenfalls erfolgt eine kurze Einführung in cloud-init, um weitere Software zu installieren und zu konfigurieren.

Die kommenden Terraform Schulungstermine

Melde Dich jetzt an und sichere Dir Deinen Platz!

Die genauen Inhalte, Voraussetzungen und alles weitere Wissenwerte erfährst Du auf unserer NETWAYS Trainings-Seite zur Terraform Schulung.