Konkrete Umsetzung von DevOps und Continuous Delivery mit Chef

Inhaltsverzeichnis

Die strenge Trennung der Bereiche Betrieb und Entwicklung sorgt für Reibungsverluste. Gerade wenn Systeme in Produktion gehen sollen, werden die Schwierigkeiten offensichtlich. Die beiden Bereiche sprechen nicht dieselbe Sprache und haben völlig unterschiedliche Sichten auf das System. Bei DevOps ist der Name Programm: Development (Entwicklung) und Operations (Betrieb) wachsen zu einer Einheit zusammen. Eine Beispielumsetzung mit Chef.

Die Zusammenarbeit zwischen Entwicklung und Betrieb wird vor allem bei der Produktivstellung von Software relevant, denn dort sind beide Bereiche involviert. Die Kollaboration erzeugt Synergien, da die Entwicklung den Betrieb beispielsweise unmittelbar mit spezifischen Tools beim Troubleshooting unterstützen und der Betrieb die Verwaltung einer Umgebung für Tests oder Staging optimieren kann [1].

Mehr Infos

Sonderheft "Bessere Software"

Dieser Artikel ist einer von 35 Artikeln eines von heise Developer produzierten Sonderhefts zur Softwarequalität, das ab soforti in jedem gut sortierten Zeitschriftenhandel oder im heise shop zu kaufen ist.

Zur Optimierung der Prozesse ist Continuous Delivery in den Mittelpunkt des Interesses gerückt. Das grundlegende Buch zum Thema [2] beschreibt den Prozess für die Produktivstellung als eine Art Pipeline, durch die Anforderungen von der Implementierung bis zur Auslieferung laufen. Zunächst werden die Änderungen in der Versionskontrolle eingestellt. Dann laufen einfach Unit-Tests und gegebenenfalls eine statische Codeanalyse der Software. Im nächsten Schritt erfolgen automatisierte Akzeptanztests. Sie überprüfen, ob die Features fachlich korrekt implementiert sind. Schließlich werden Kapazitätstests durchgeführt. Diese überprüfen, ob die Software die gewünschte Performance erreicht. Zuletzt finden manuelle Tests statt.

Obgleich bereits automatisierte Tests der Anforderungen stattgefunden haben, ist das nicht ausreichend. Gerade bei neuen Funktionen müssen Fachexperten die Software manuell prüfen. Dabei können sie die neuen Features explorativ testen. Dabei greifen die Tester auf ihr fachliches Verständnis zurück und können so auch vollständig neue Teile der Anwendung überprüfen. Danach kann die Software in Produktion gehen.

Ziel von Continuous Delivery ist es, die Durchlaufzeit durch die Pipeline zu erhöhen. Dadurch wird die Zeit optimiert, die ein Requirement bis in die Produktion braucht. Gerade für Startups ist es wichtig, neue Features Kunden schneller zur Verfügung zu stellen und so rasch auf Änderungen im Markt zu reagieren. Gleichzeitig verringert sich das Risiko eines neuen Releases: Wenn öfter Software in Produktion gebracht wird, ist jedes Release eine kleinere Änderung. Wenn weniger Änderungen in Produktion gehen sollen, sinkt das Risiko, dass sich Fehler einschleichen.

Für die Optimierung der Pipeline ist die automatische Installation der Software eine wesentliche Grundlage. Nur so lassen sich die Umgebungen effizient aufbauen, die für die Tests in der Pipeline notwendig sind. Das Vorgehen hat noch einen weiteren positiven Effekt: Der Aufbau der Produktionsumgebung ist letztlich nur ein weiterer Durchlauf der Automatisierung. Dadurch kann man eine viel höhere Zuverlässigkeit beim Aufbau der Produktionsumgebung erreichen.

Maître de cuisine

Ein wesentliches Werkzeug für die automatisierte Installation von Umgebungen ist das Open-Source-Werkzeug Chef. Es "kocht" sozusagen Systeme zusammen, auf denen die richtige Software installiert und passend konfiguriert ist. Im Wesentlichen lässt sich Chef auf dreierlei Weise benutzen:

• Chef Solo ist die einfachste Variante. Dabei wird Chef als Kommandozeilen-Tool verwendet. Dafür muss allerdings die gesamte Konfiguration auf dem Rechner vorhanden sein.
• Der Chef Server konfiguriert und verwaltet eine Menge von Clients. Der Client hat dann nur einen kleinen Kern. Der Ansatz ist vor allem bei der Installation mehrerer Rechner hilfreich. Außerdem ermöglicht er es, dass der Server Buch über alle Rechner führt. Dadurch lässt sich beispielsweise auf einem Monitoring-System für jeden Rechner ein passender Eintrag erzeugen. Ebenso kann man die Abfragen über die Rechner und die installierte Software ausführen.
• Die Opscode-Plattform ist dem Chef Server sehr ähnlich. Sie ist ein kommerzielles Angebot der Firma Opscode, den Entwicklern von Chef. Sie stellt den Betrieb des Servers sicher. So lassen sich Rechner im gesamten Internet mit Installationsanweisungen versorgen. Die Infrastruktur skaliert gut, sodass sich selbst umfangreiche Cloud-Installationen verwalten lassen.

Chef unterstützt verschiedene Unix-Derivate (Linux, Mac OS X usw.), aber auch Windows. Über Plug-ins kann man Plattformen wie Amazon EC2, OpenStack oder VMware integrieren, sodass sich eine neue virtuelle Machine starten lässt, die dann mit Software "betankt" wird. Der Einfachheit halber beschäftigt sich der Rest des Artikels vor allem mit Chef Solo. Damit lassen sich die wesentlichen Funktionen von Chef erläutern. Chef beruht auf drei wesentlichen Begriffen:

• Ressourcen sind alles, was sich konfigurieren oder installieren lässt. Dazu zählen beispielsweise Dateien oder Linux Packages. Chef unterstützt eine Vielzahl von Ressourcen – etwa Code Repositories, Netzwerk-Adapter und Dateisysteme.
• Policies definieren, wie die Ressourcen beschaffen sein sollen. So kann eine Policy aussagen, dass der Benutzer "adesso" vorhanden oder das Package "tomcat" installiert sein soll.
• Provider sind dafür zuständig, den Zustand einer Ressource zu ermitteln und so zu ändern, dass er einer Policy entspricht.

Chef definiert Policies, in welchem Zustand die Ressourcen sein sollen. So lassen sich Chef-Skripte immer wieder ausführen (Idempotenz). Wenn die Ressourcen alle im richtigen Zustand sind, passiert nichts. Sonst werden nur die notwendigen Änderungen vorgenommen – und nichts mehr. Oft sind Installationsskripte nur in der Lage, eine Software auf einem völlig neuen System zu installieren. Soll sie erneut installiert werden, sind Fehlschläge nicht ungewöhnlich, da die Skripte mit der Installation nicht geeignet umgehen.

Chef ist in Ruby geschrieben und daher erweiterbar. Für den Nutzer gibt es eine DSL (Domain Specific Language), die die Konfiguration einfacher Systeme auch ohne Ruby-Kenntnisse ermöglicht. Power-User, die ihr System mit Ruby erweitern, schreiben sogenannte Rezepte (Recipes). Der folgende Code-Part zeigt einen Ausschnitt aus einem solchen Rezept – in diesem Fall für Tomcat.

template "/etc/tomcat6/server.xml" do
  source "server.xml.erb"
  owner "root"
  group "root"
  mode "0644"
  notifies :restart, resources(:service => "tomcat")
end

Der Ausschnitt definiert, dass die Ressource /etc/tomcat6/ server.xml – also eine Datei – aus dem Template server.xml.erb erzeugt werden soll. Außerdem legt das Rezept fest, welchem Benutzer und welcher Gruppe die Datei sowie die Rechte auf die Datei gehören sollen. Wird die Datei geändert, soll der Service Tomcat neu gestartet werden. Er ist eine weitere Chef-Ressource, die an anderer Stelle in der Datei definiert ist.

Chef würde also zunächst überprüfen, ob die Datei dem Template entspricht. Wenn das nicht der Fall ist, ersetzt es die Datei. Eine eventuell vorhandene Datei wird archiviert, sodass nachvollziehbar ist, welche Änderung wann vorgenommen wurde. Danach passiert dasselbe für den Besitzer der Datei und die Zugriffsrechte. Nur wenn eine Änderung der Dateien notwendig war, wird der Tomcat-Service neu gestartet.