Neben jedem Update des NetWorker-Servers soll natürlich auch die NetWorker-Client-Software auf den einzelnen zu sichernden Clients aktuell gehalten werden. Zwar besagt die Regel, dass der NetWorker-Server die höchste Version haben muss, aber den vollen Funktionsumfang hat man nur, wenn alle Komponenten auf dem aktuellen Stand sind. Hierzu gehören auch sämtliche Zusatz-Pakete, von grundlegenden man-pages oder dem Extended-Client, bis hin zu Datenbank-spezifischen Modulen wie beispielsweise NMDA oder NMSAP. Eine lästige, monotone Aufgabe, die in einer großen Serverlandschaft mit zahlreichen verschiedenen Systemen viel Zeit in Anspruch nimmt, wenn man sich jedes Client-System für das Update individuell vornehmen muss.

Als Alternative bietet sich ein Automatisierungstool wie Ansible an, um wiederkehrende, immer gleiche Aufgaben wie beispielsweise Updates von Clients zentralisiert, effizient und automatisiert zu erledigen.

Ansible? – Kurz erklärt

Ansible ist ein Open-Source-Tool, welches Konfigurationsmanagement, Softwareverteilung und Kommandoausführung kombiniert. Mittels eines zentralen Nodes können so einzelne Tätigkeiten auf über Listen (in einer Datei festgelegte Gruppen) ausgewählten Systemen durchgeführt werden – von der Ausführung einzelner Kommandozeilen-Befehle, bis hin zur Erstellung von kompletten Systemkonfigurationen.

Ansible wurde unter anderem in folgenden ORDIX-Blogartikeln näher beleuchtet:

• Ansible – Warum selber machen, wenn es sich auch automatisieren lässt?
• Einfach. Einfacher. Ansible. Automatisierung mit Ansible.
• Große Versionssprünge in Ansible, was tun?
• Open-Source-Software Ansible – Continuous Ansible mit Jenkins
• PostgreSQL wie von Zauberhand: Automation mit Ansible

Vor der Installation ist nach der Installation

Ein Playbook für das Update der NetWorker-Client-Software soll durch Ansible möglichst idempotent gestaltet werden. Als idempotent bezeichnet man Arbeitsabläufe, welche immer zu einem identischen Ergebnis führen, unabhängig, wie oft diese Schritte wiederholt werden. Ist beispielsweise die benötigte Version der Software bereits installiert, sollen durch wiederholtes Ausführen des Playbooks keine ungewollten Veränderungen hervorgerufen werden.

Für das Update der NetWorker-Client-Software wird die exakte NetWorker-Versionsnummer in einer Variable festgelegt. Mithilfe dieser Variable lässt sich im nächsten Schritt überprüfen, ob diese Version auf einem Client eventuell bereits installiert ist.

Eine Variable lässt sich bei Ansible mit verschiedenen Methoden deklarieren. Eine Möglichkeit ist, die Variable für die Versionsnummer innerhalb des Playbooks zu definieren:

vars:
rpm_networker_version: "19.6.0.2"

Statisch, aber funktionell. Hierbei muss darauf geachtet werden, dass bei Wiederverwendung des Playbooks für ein Update auf eine andere Versionsnummer, die Variable auch entsprechend angepasst werden muss.

Alternativ lässt sich eine Variable auch beim Aufruf des Playbooks auf der Kommandozeile als Parameter übergeben, wie beispielsweise folgend:

ansible-playbook playbook.yml --extra-vars "rpm_networker_version=19.6.0.2"


Zur Feststellung der aktuell auf einem System installierten NetWorker-Client-Software-Version werden über das Playbook Kommandos der Paketverwaltung des Betriebssystems (z. B. rpm/yum/zypper) ausgeführt. Unser Beispiel liefert die Versionsnummer des Paketes 'lgtoclnt' zurück. Vom Ergebnis des Vergleichs der installierten Version mit der neuen Zielversion ist dann abhängig, ob sämtliche NetWorker-Software-Pakete des Systems auf die neue Version aktualisiert werden oder die Installation im bisherigen Zustand belassen wird. So eine Funktion ist möglich mit folgendem Play innerhalb eines Playbooks:

Der weitere Verlauf des Playbooks wird so gestaltet, dass beim Vorfinden einer von der Zielversion abweichenden Client-Version alle auf dem System installierten Pakete des NetWorker identifiziert und ebenfalls aktualisiert werden. Hierdurch werden Probleme mit inkompatiblen Versionen vermieden.

Im Detail lässt sich durch diesen Task mittels des Return-Codes des ausgeführten Befehls ermitteln, ob die gewollte Version der Software vorhanden ist. Die Versionsnummer des abgefragten Paketes wird mit der Anweisung register in der Variable networker_installed_version abgelegt. Der Return-Code des Kommandos lässt sich mittels <Variablenname>.rc für Abfragen verwenden. Hiermit lässt sich für nachfolgende Plays folgende Bedingung implementieren:

when: networker_installed_version.rc != 0


So werden diese Plays nur ausgeführt, wenn die aktuell installierte Version nicht der gewünschten Zielversion entspricht.

Im Weiteren können hier auch Checks implementiert werden, um mögliche Abhängigkeiten zu bestimmten NetWorker-Zusatzmodulen zu ermitteln. Hierzu gehören beispielsweise Datenbank-spezifische Module wie NMDA (wird verwendet z. B. für Oracle, Informix und weitere) oder NMSAP (wird verwendet für SAP-Oracle, SAP-HANA). Die Möglichkeiten hierfür sind vielfältig. Einerseits kann überprüft werden, ob spezifische Module bereits in veralteter Version installiert sind. Alternativ könnte auch allgemein getestet werden, ob ein bestimmter Datenbanktyp auf dem System installiert bzw. aktiv ist.

Immer der Reihe nach

Plays werden in Ansible immer nacheinander ausgeführt. Daher ist es wichtig, in welcher Reihenfolge die Plays im Playbook definiert werden. Nachdem sämtliche Vorprüfungen durchgeführt wurden, werden die NetWorker-Prozesse vor dem Update gestoppt. Dies wäre mit folgendem Play realisierbar für Linux-Distributionen, die eine Steuerung der Dienste über systemd ermöglichen: 

Bei älteren Linux-Systemen, die noch mit Skripten unter /etc/init.d/ arbeiten, muss hier ggf. mit sysvint statt service gearbeitet werden.

Zusätzlich noch der Hinweis, dass nach dem Abschluss der Aufgaben auch der Start der NetWorker-Software als Play implementiert werden muss.

Hiernach folgt die Deinstallation der vorhandenen NetWorker-Software, gefolgt von der Installation der Zielversion an gleicher Stelle. Da sämtliche NetWorker-Pakete eine Abhängigkeit zum Paket lgtoclnt aufweisen, wird folgende Reihenfolge benötigt:

• Deinstallation aller alten NetWorker-Pakete außer lgtoclnt
• Deinstallation des alten lgtoclnt
• Installation des neuen lgtoclnt
• Installation aller weiteren NetWorker-Pakete außer lgtoclnt

Die Deinstallation von lgtoclnt könnte wie folgend als Play definiert werden:

Nach der Installation der Softwarepakete fallen eventuell noch Nacharbeiten an, die nicht von den Installationsroutinen der Pakete erledigt werden. Ein Beispiel dafür ist bei NMSAP das Verlinken der von NetWorker bereitgestellten hdbbackint Datei. Solche Nacharbeiten können mittels when-Bedingungen auch in ein Playbook implementiert werden. Zur Übersichtlichkeit können solche zusätzlichen Aufgaben auch in ein separates Playbook oder Skript ausgelagert werden, welches innerhalb von einem anderen Playbook aufgerufen wird. Dies kann die Lesbarkeit eines Playbooks verbessern, ohne dabei an Funktionalität einzusparen. 

Fazit

Durch die Verwendung von Ansible lassen sich monotone, zeitraubende Tätigkeiten wie das Update zahlreicher NetWorker-Clients effizienter und konsistenter durchführen. Je nach der Anzahl der zu aktualisierenden Clients und eingesetzten Zusatzmodulen lassen sich sowohl Zeit einsparen als auch mögliche Fehlerquellen vermeiden. Ein solches Playbook kann modular erweitert werden, falls neue Clients mit weiteren Softwarepaketen hinzukommen. Alles in allem bietet ein Playbook somit viel Potenzial für Zeitersparnisse zum Aktualisieren der Clients und gesteigerte Stabilität, sofern die Infrastruktur in Form von Ansible hierfür vorhanden ist. 

Seminarempfehlung