Das IT-System in einem Unternehmen manuell zu patchen, ist mit hohen Aufwänden und einem gewissen Risiko verbunden. Diese Umständlichkeit lässt sich am Beispiel von Oracle gut nachvollziehen: Der Patch-verantwortliche IT-Experte muss zunächst einen aktuellen Patch identifizieren und ihn nach manuell durchgeführten Befehlen herunterladen. Anschließend spielt er den Patch auf ein Testsystem auf, prüft ihn auf mögliche Fehler und rollt ihn danach auf dem Produktivsystem aus.
Ein Prozedere, das Personal und Zeit gleichermaßen bindet. Dabei sollte nur jener erste Schritt der Patch-Identifikation in den Händen eines IT-Experten liegen, da er die Infrastruktur und Sicherheitsstrategie seines Unternehmens kennt. Alle weiteren Schritte lassen sich mit Ansible automatisieren.
Möglichkeiten der Automatisierung durch Ansible
Bei GISA haben wir uns entschieden, Ansible für die Automatisierung von Patches zu nutzen – und das hat gute Gründe:
- Die Open Source-Lösung von RedHat arbeitet ohne Agenten, sodass sich damit auch Systeme betreuen lassen, die nur schwer zugänglich sind oder bei denen die Installation von Drittsoftware wegen Verfügbarkeits- oder Sicherheitsbedenken nicht möglich ist.
- Ansible ist kompatibel mit Windows und allen Unix-Derivaten und fügt sich problemlos in unsere bestehende Infrastruktur ein.
- Nicht zuletzt sind die genutzten Sprachen YAML und Python einfach und verständlich und lassen sich komfortabel für die Konfiguration verwenden.
Viele gute Gründe, die dazu geführt haben, dass Ansible heute eines der besten etablierten Open Source-Orchestrierungstools ist.
Das Konzept hinter Ansible
Mit Ansible ist es möglich, von einen für Ansible konfigurierten Linux-Server andere Server (sog. Nodes aka Knoten) über Secure Shell (SSH) aus der Ferne konfigurieren zu lassen. Dies erfolgt in sogenannten Tasks. Die Installation eines neuen Patches kann beispielsweise solch ein Task sein.
Auf die Knoten werden kleine Programme (sog. Module) übertragen, die dazu verwendet werden, Automatisierungsaufgaben in Ansible durchzuführen. Ist solch ein Modul ausgeführt, entfernt es Ansible wieder vom System. Das ist das agentenlose Prinzip von Ansible: Die Lösung kann so Knoten managen, ohne das darauf erst eine Software installiert werden muss.
Damit klar definiert ist, welche Tasks in den übertragenen Modulen durchgeführt werden, entstehen im Vorfeld sogenannte Playbooks. Ein Playbook ist eine YAML-Datei, die einen oder mehrere Abläufe („Plays“) enthält und den Patch-Wunschzustand eines Systems definiert. Im Playbook werden somit Aufgaben abgelegt, die dann in einer festgelegten Reihe durchgeführt werden.
Ansible scannt ein System und vergleicht es mit dem Wunschzustand im Playbook – gibt es hier Unterschiede, nimmt Ansible automatisch alle notwendigen Patches vor, um das System auf den Wunschstatus zu bringen. Der Nutzer kann immer wieder prüfen, ob die Playbook-Aufgaben tatsächlich ein System sinnvoll patchen, bevor es zur tatsächlichen Änderung kommt. Zusammengefasst werden Playbooks, Module, entsprechende Rollen und etwaige Plugins in sogenannten Collections.
Mehr Überblick, Zeitgewinn, weniger Kosten
Auf diese Weise lässt sich klar erkennen, welches System, welchen Patch, zu welchem Zeitpunkt erhalten soll – und sie dann auch automatisiert durchführen. Damit gewährleisten wir Unternehmen ein sicheres, effizientes und kostengünstiges Patchen, das dank Automatisierung auch zu Zeiten stattfinden kann, in denen das IT-System nur wenig genutzt wird. Es braucht dafür keine ausgemachten IT-Spezialisten, sodass Mitarbeiterinnen und Mitarbeiter die Datenbanken eigenständig überwachen, kontrollieren und ausführen können. Ein automatisches Reporting ist Stand heute allerdings noch nicht möglich – ein kleiner Wermutstropfen bei einer ansonsten ungemein hilfreichen und komfortablen Lösung für mehr Sicherheit und Entlastung bei Patch-Aufgaben.
Mehr erfahren: IT-Systeme mit Ansible automatisch und individuell patchen
