Das Verwalten und Managen von vielen Servern mit ähnlichen Konfigurationen ist anstrengend und kann sehr viel Zeit in Anspruch nehmen. Konfigurationsdateien müssen auf unterschiedlichen Servern verteilt und angepasst werden. Zertifikate oder Keys müssen aufwendig kopiert werden damit die Server sicher miteinander kommunizieren können.
Mit neuen Anforderungen an den Servern ändern sich auch die Konfigurationen auf dem Server. Das hat zur Folge, dass durch lokale Einstellungen die Serverkonfigurationen von den Dokumentierten abweisen kann. Gerade die Dokumentation der Firewall für jeden einzelnen Server gibt es meist nicht, sondern nur für eine Gruppe von Servern.
Mit einer zentralen Serveradministration und Konfigurationsanwendung, wie zum Beispiel Ansible oder Ansible AWX kann bei jeder Änderung der gewünschte Konfigurationszustand wieder hergestellt werden. Ansible ist eine Open Source Anwendung, die von Red Hat und einer starken Community weiterentwickelt wird.
Es gibt zwei unterschiedliche Klassen von Konfigurationsmanagement Tools.
Die erste Klasse setzt auf eine Server-Client Architektur, bei der auf jedem Client ein eigener Agent installiert werden muss, der die Konfiguration auf dem Client vornimmt. Dazu gehören zum Beispiel Puppet und Chef. Mit dem Agent ist es möglich, dass die Clients sich selbständig die neuesten Richtlinien und Konfigurationen vom zentralen Server herunterladen und anwenden. Wenn zum Beispiel eine Firewall Richtlinie auf dem Server hinterlegt und dem Client zugeordnet ist wird diese jedes Mal erneut kontrolliert und auf dem Client erzwungen. Es ist nicht mehr möglich die Firewall lokal auf dem Client zu ändern, da diese jedesmal wieder auf die firewall Richtlinie des Servers zurückgesetzt wird.
Die zweite klassen von CMs besteht nur aus einer Serverkomponente. Ansible AWX oder Ansible CLI ist diese Komponente. Auf dem Client muss kein Agent installiert werden. Die Kommunikation zwischen dem Server und dem Client erfolgt bei Ansible über SSH und dem SSH Key. Mit Ansible ist es auch möglich, die Firewall zu konfigurieren. Dabei dir auf dem Server ein Playook erstellt, in dem beschrieben wird, wie die Firewall auf dem Client aussehen soll. Mit dem Befeht ansible playbook firewall.yml wird das Playook firewall auf dem Client umgesetzt. Nachdem das Playbook durchgelaufen ist, könnten noch eigene Einstellung auf dem Client vorgenommen werden. Erst beim nöchsten Duchlauf des Playbooks Firewall werden erneut die Firewall Richtlinien aus dem Playbook angewendet.
Ansible Playbooks sagen genau wie es gemacht werden muss. Puppet Module beschreiben was gemacht werden muss aber nicht wie es umgesetzt werden muss.
Bei Ansible kann es nach einiger Zeit zu einer Anweichung zwischen Playbook und Konfigurationen auf dem Server und dem Client kommen, da Konfigurationen auf dem Client per Hand geändert werden können. Puppet kontrolliert alle Einstellungen und erzwingt die Serverkonfiguration auf dem Client.
Da Ansible keinen Agent auf dem Client benötigt kann mit Ansible direkt angefangen werden einen Client zu provisionieren. Es muss nur eine SSH Verbindung hergestellt werden.
Puppet benötgigt einen Agent auf dem Client. Dieser muss erst von Hand oder mit einem Master Image auf dem Client installiert werden. Danach muss der Agent noch mit dem Server verbunden werden und das Provosioning kann losgehen.
Mit Ansible kann der Puppet Agent auf dem Client installiert werden. Mit Puppet kann eine einheitliche Konfiguration auf Servern umgesetzt werden. Es geht daher nicht darum welches Tool besser geeignet ist, es können generell beide Tools zusammen verwendet werden, da beide Tools für unterschiedliche Zwecke eingesetzt werden können.
Benötigen Sie Unterstützung bei Ihrer Transformation?
Zögern Sie nicht mit uns Kontakt
aufzunehmen.