Portfolio |

Patch Management the easy way

Ansible eignet sich hervorragend für das automatisierte Patch Management. Wir nehmen euch mit auf eine fiktive Reise, wir ihr euch manuelle Arbeit spart und trotzdem einen stabilen Systembetrieb erreicht.

Hallo, ich bin Jane und Systemadministratorin bei Doe Pharma, einem Hersteller für Arzneimittel. Mein Team verwaltet ca. 800 virtuelle Server – ein Mix aus Windows und Linux. Die Sicherheit unserer IT-Systeme und ein effektives Patch-Management sind bei uns allgegenwärtige Themen. Besonders durch unsere Produktion, die durch gesetzliche Vorgaben und Richtlinien geregelt ist. Die Frage nach dem „Warum?“ ist für uns also eigentlich keine Frage mehr: Sicherheit, Systemverfügbarkeit und Compliance. Anwendungen und Betriebssysteme sind anfällig für Angriffe. Das regelmäßige Einspielen von Patches hilft, Angriffe abzuwehren und das Sicherheitsrisiko zu minimieren.

Patches helfen zudem einen reibungslosen und stabilen Betrieb zu gewährleisten, was letztendlich der Verfügbarkeit unserer IT-Systeme und Anwendungen zugutekommt. Eine intelligente Automatisierung hilft, diesen leidigen Prozess angenehmer zu gestalten und nebenbei Überstunden und Wochenendarbeiten zu reduzieren, wenn nicht sogar ganz zu eliminieren.

Wir suchten eine Antwort auf das „Wie?“

Die Mehrzahl kennt das Phänomen: Automatisierung? Unbedingt! Aber wie sollen wir das bewerkstelligen? Knappes Budget, zu wenige und ausgelastete Ressourcen, Daily Business, Projekte. Gute Ansätze, wenig Know-How. Viele Baumstämme, die man erstmal überwinden muss. Umso besser, einen kompetenten Partner wie die proficom an seiner Seite zu wissen. Am Anfang der Reise stand eine Bestandsaufnahme. Schonungslos und ehrlich. Durch unsere jährlichen Wartungsfenster, vier Stück an der Zahl, kämpfen wir uns mühsam und mit viel manuellen Aufwand. Bei der Vielzahl an Systemen bleiben Fehler nicht aus. Meistens ausgelöst durch Unachtsamkeit und Stress. Der Aufbau der Infrastruktur spielt auch eine Rolle. Unsere Server werden nach einem standardisierten Verfahren bereitgestellt. So sehen die Server immer gleich aus. Zudem verfügt jeder Service bzw. jede Anwendung über drei Servergruppen: Development, Quality und Productive. Ein Test der anstehenden Patches findet auf den „Quality“-Systemen statt. Läuft dort alles ohne Störungen, wandern die Updates auf die Systeme in der Gruppe „Productive“. Eine gute Grundlage, um mit der Automatisierung zu starten. Fehlt nur noch das Tool. Die Kosten sollten gering, das Tool leicht verständlich und die Syntax ohne Schwierigkeiten zu erlernen sein. Schließlich haben wir für unserer Reise die Siebenmeilenstiefel eingepackt. Schnell fiel die Wahl auf Ansible & AWX.

About Ansible

Ansible ist ein Open-Source-Tool für die Automatisierung von IT-Infrastruktur. Es ermöglicht die Automatisierung von Aufgaben wie Konfiguration, Bereitstellung und Management von Systemen. Ansible ist einfach zu verwenden und hat eine große Community von Entwicklern, die ständig neue Funktionen hinzufügen. AWX ist eine webbasierte Oberfläche für Ansible. Es ermöglicht die einfache Ausführung und Überwachung von Jobs. Es bietet eine rollenbasierte Zugriffssteuerung und Job-Scheduling. Über Workflows können mehrere Playbooks verkettet werden.

Der Einstieg in die Welt der Playbooks verlief ohne Schwierigkeiten. Ein Play zum Patchen von Windows- und Linux-Servern? Easy peasy lemon squeezy!

name: Update Windows host
  hosts: "{{ hostname }}"
  tasks:
    - name: Install latest patches
      ansible.windows.win_updates:
        state: installed
        category_names:
          - CriticalUpdates
          - DefinitionUpdates
          - SecurityUpdates
          - UpdateRollups
          - Updates
        reboot: yes
        reboot_timeout: 3600

Abbildung 1: Playbook Windows Updates

name: Update SLES host
  hosts: "{{ hostname }}"
  become: yes
  tasks:
    - name: Install latest patches
      community.general.zypper:
        name: '*'
        state: latest

    - name: Reboot
      ansible.builtin.reboot:
        reboot_timeout: 1200

Abbildung 2: Playbook SLES Updates

name: Update RHEL host
  hosts: "{{ hostname }}"
  become: yes
  tasks:
    - name: Install latest patches
      ansible.builtin.yum:
        name: '*'
        state: latest

    - name: Reboot
      ansible.builtin.reboot:
        reboot_timeout: 1200

Abbildung 3: Playbook RHEL Updates

So weit, so gut.

Damit Ansible weiß, wie es mit den Servern kommunizieren kann, benötigen wir ein Inventory

Wie bei der Entwicklung von Playbooks gibt es auch hier nicht den einen goldenen Weg. Das ist das Schöne an Ansible: Viele Wege führen nach Rom. Da wir sämtliche Daten zu unserer Infrastruktur in einer CMDB (Configuration Management Database) vorhalten, haben wir uns für die Erstellung eines Skripts entschieden, welches lokal auf der Ansible Control Node läuft und regelmäßig Daten aus der Datenbank abfragt und diese zu einer Inventory-Datei zusammenbaut. Diese Datei wird in einem Git-Repository abgelegt. Dort liegen auch die Playbooks. Jetzt können wir Playbooks auf Hosts bzw. Hostgruppen ausführen. Das ist schon eine enorme Erleichterung. Und wie es immer so ist, wachsen mit den neu gewonnenen Möglichkeiten auch die Ansprüche – Reporting, Logging, Vorab- und Erfolgsprüfungen.

Alles kein Problem! Nach einigen Brainstorming-Sessions und vielen Entwicklungsstunden haben wir mittlerweile einen Stand erreicht, der gemessen an den ersten Playbooks ein riesiger Sprung ist. Einige Vorab-Prüfungen stellen beispielsweise sicher, dass der zu patchende Server bereit ist für die Installation. Nach dem Installieren der Updates erfolgt ebenfalls eine Prüfung, ob tatsächlich die ausstehenden Patches eingespielt wurden.

Zudem haben wir die einzelnen Schritte in Rollen überführt. Diese wiederum sind die Grundlage eines Job-Workflows im AWX, der nun das Patchen der Systeme übernimmt. Es muss sich niemand mehr an der Konsole des Ansible Hosts anmelden und das Playbook über den entsprechenden Befehl ausführen. Eine Survey sammelt beim Start des Job-Workflows alle wichtigen Informationen und Parameterwerte ein und triggert anschließend die Playbook-Kette. Das ist so benutzerfreundlich, dass auch der First-Level-Support beim Patchen unterstützen kann.

Abbildung 4: Job Schedule in AWX

Über verschiedene Benachrichtigungen werden wir über den Status der Ausführung informiert. Die Playbooks reagieren zwar eigenständig mit Rettungsmaßnahmen auf verschiedenste Fehler, die hartnäckigsten müssen wir allerdings nach wie vor von Hand lösen.

Abbildung 5: Das AWX Dashboard gibt einen Überblick zum Status der Patches

Das kommt aber aufgrund unserer Standardisierung und der Reduzierung der menschlichen Fehler durch die Automatisierung selten vor. Unsere Wartungstermine laufen seither wesentlich entspannter.

Mit Ansible & AWX sind wir also nun in der Lage, Updates und Patches schneller und zuverlässiger zu installieren. Außerdem können wir sicherstellen, dass alle Systeme im Unternehmen konsistent aktualisiert und keine Systeme vergessen oder ausgelassen werden. Wartungsfenster sind für uns kein Problem mehr. Auch außerplanmäßige Updates sorgen nicht mehr für Albträume.

Momentan sind wir dabei, ein Prozessorchestrierungstool einzuführen, welches es den Fachteams in der Produktion und den Anwendungsentwicklern ermöglichen soll, auch außerhalb unserer festen Wartungsfenster, Server zu patchen. Eine einfache Bedienoberfläche führt den Nutzer durch den kompletten Prozess, von Anfang bis Ende. E2E (End-to-End), wie man so schön sagt. Die Reise ist zweifellos noch nicht zu Ende!