Chef, Puppet, Ansible in der Cloud AWS OpsWorks for Chef Automate, Teil 1

Die Architektur von Chef Automate

Viele Admins stellen sich die Frage, wie sie Änderungen für instal­lierte Anwen­dungen, in der Konfigu­ration von Betriebs­systemen oder von Dien­sten (etwa der IIS) über dutzende oder gar hunderte Server in der Cloud ver­walten sollen. Hier kommen Tools für das Konfigu­rations-Manage­ment wie Chef, Puppet oder Ansible ins Spiel. Bevor wir uns ansehen, wie sich Puppet und Chef unter AWS anfühlen, erörtern wir die Grundzüge von Config-Management in der Cloud. 

Große Unter­nehmen können heute ohne Lösungen für das Konfigurations-Management kaum ein sinnvolles Operations-Management betreiben, egal ob es sich bei den verwalteten Systemen um physische oder virtuelle Server im eigenen Rechen­zentrum oder in der Cloud handelt.

Im letzteren Fall ist die Wahr­scheinlich­keit höher, dass die Anzahl zu ver­waltender Systeme nicht nur größer ist, sondern auch stark fluktuiert (Auto Scaling), und hinsichtlich der Konfiguration (Betriebssystem, Anwendung) großen und häufigen Schwankungen unter­liegt.

Wozu Konfigurations-Management?

Während man Anpassungen mit langer Lebensdauer, wie das Austauschen von Treibern, Agenten oder Tools auch auf andere Weise automa­tisieren kann und für Betriebs­system-Patches auch spezialisierte Lösungen zur Verfügung stehen, stellt das Management vom Anwendungs-Releases eine große Heraus­forderung besonders in Devops-Szenarien dar.

Lösungen für das Konfigurations-Management konzen­trieren sich daher meist auf das Management von Applikationen, können sich aber je nach Konzeption auch um Betriebs­systeme und auch Hardware (physisch oder virtuell) kümmern.

Dabei möchte man zudem sicher­stellen, dass die ver­schiedenen Einstellungen immer in einem definierten und guten Zustand bleiben. Das Problem tritt insbesondere in der Cloud auf, wenn Nutzer Systeme in großem Maßstab erstellen und verwalten.

Entdeckt man etwa einen Fehler in einem laufenden Web-Dienst, der durch eine einfache Änderung der Konfigurations­datei behoben werden könnte, dann muss man sich mit der Frage auseinander­setzen, wie man eine solche Änderung auf sämtliche in der jeweiligen Flotte laufenden Instanzen mit möglichst geringer Ausfallzeit anwendet.

Anwendungen für Konfigurations-Management

Wurden die Änderungen dann vorgenommen, muss man zuverlässig verhindern, dass andere Admini­stratoren sie aus Versehen zurück­nehmen. Summa summarum lässt sich festhalten, dass IT-Infrastruktur jeglicher Art permanent verwaltet werden muss. Dazu gehören

  • Paket­aktuali­sierungen
  • Neue Software
  • Neue Konfigu­rationen
  • Neue Anwendungs­bereit­stellungen
  • Umgebungs­spezifische Änderungen

Vieles kann man zwar mit Infrastructure as Code (IaC) und Automatisierung lösen, wie etwa mit Terraform oder CloudFormation in AWS. Trotzdem braucht es dann aber immer noch eine Strategie zur Installation und Wartung einzelner Instanzen bzw. Server.

Web-Server-Farmen als Admin-Herausforderung

Zu den alltäglichen Heraus­forderungen im Config-Management gehört etwa das Ändern einer vhost-Konfiguration auf jedem Web-Server in mehreren Umgebungen (Development, Stage, Produktion), das Instal­lieren eines Pakets auf bestimmten Hosts, um neuere Versionen zu testen oder das Ändern der LDAP-Konfiguration auf jedem laufenden Linux-Host.

Folgende Abbildung zeigt eine allgemeine Architektur mit einem nicht näher spezifizierten Configuration server im Kontext der AWS-Cloud für das Management von Web-Server-Instanzen (Windows oder Linux). Dies funktioniert so aber auch mit anderen Cloud-Anbietern (Azure, Google) oder on premises.

Config-Management mit AWS-Tools

Typen von Änderungen

Änderungen sind dabei stets:

  • idempotent (findet nur einmal statt, bzw. werden nicht noch einmal angewendet)
  • erzwungen (nicht autorisierte Änderungen werden zurückgesetzt)
  • verteilt (Updates können auf eine ganze Flotte von Servern übertragen werden)

Vergleich von Puppet, Chef und Ansible

Die derzeit populärsten Vertreter sind Chef, Puppet, Ansible und Salt Stack. Die wichtigsten Gemeinsam­keiten und Unterschiede dieser Tools zeigt folgende Tabelle:

PUPPET CHEF ANSIBLE
Kommerzielle Version Puppet Enterprise Chef Automate Ansible Tower
Skriptsprache Custom DSL auf Basis von Ruby Pures Ruby YAML
DSL-Stil deklarativ Deklarativ imperativ
Mechanismus Puppet-Master synchronisiert Änderungen auf die verwalteten Puppet-Knoten Chef-Workstation pusht/pollt Änderungen zum/vom Chef-Server, der sie an die verwalteten Knoten pusht Controller-Maschine verteilt Änderungen per SSH an den angegeben Knoten, sofern dieser SSH und Python ausführt.
Zentralisierte Kontrolle Per Puppet Master Per Chef Server Jeder beliebige PC kann Ansible Controller sein.
Script-Terminologie Manifeste und Module Cookbooks und Rezepte Playbooks und Rollen
Taskausführungs-Order Nicht sequentiell Sequentiell Sequentiell

Hier weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.