DevOps Teil 7: Automatisierung

Bewerten Sie diesen Beitrag!

Ein zentraler Gedanke von DevOps ist die Automatisierung von Vorgängen, die sonst manuell durchgeführt werden und daher wenig transparent sind beziehungsweise sich nur schlecht für eine Qualitätskontrolle eignen. Ermöglicht wird eine Automatisierung durch die Nutzung geeigneter Tools. Viele DevOps-Anhänger bezeichnen Infrastructure as Code als wichtigsten Bestandteil der Automatisierung. Mit diesem Ansatz werden sämtliche benötigten Vorgänge zum Aufsetzen von Infrastruktur oder zum Durchführen von Deployments in Quellcode repräsentiert. Es können dann viele der in der Softwareentwicklung üblichen Lösungen zur Qualitätskontrolle auch vom Betrieb eingesetzt werden. Mögliche Vorzüge des Infrastructure-as-Code-Ansatzes sind folgende:

  • Zentrale Verwaltung des Quellcodes unter Nutzung von Versionskontrolle.
  • Hohe Transparenz und Vermeidung von Wissensinseln.
  • Automatisiertes Testen der Konfiguration von Servern und virtuellen Maschinen.
  • Automatisiertes Testen von Deployments und der anschließenden Verfügbarkeit von beteiligten Systemen und geschäftskritischen Softwarefunktionen.
  • Gemeinsame Nutzung von Konfigurations- und Deployment-Vorschriften durch Entwicklung und Betrieb.

Ein zentraler Gedanke von DevOps ist die Automatisierung von Vorgängen.

Grundlegend für eine Realisierung von Infrastructure as Code sind Tools zum Konfigurationsmanagement, zum Beispiel Puppet [3], Chef [4] (siehe auch Artikel von Martin Eigenbrodt, im Java Magazin 1.2012, Seite 53) oder das ältere CFengine [5]. Diese Tools bieten domänenspezifische Sprachen (DSLs) an, um den gewünschten Endzustand des Systems auf einer abstrakten, plattformübergreifenden Ebene zu beschreiben. Hinter den Kulissen werden diese Vorgaben dann mittels vordefinierter Abbildungen auf den jeweiligen Zielsystemen ausgeführt. Eine verwandte Gruppe von Tools konzentriert sich auf ein automatisiertes Deployment und die koordinierte Ausführung von Aktionen auf laufenden, verteilten Servern. In der Regel bieten diese Tools ebenfalls DSLs an, um Abfolgen von Kommandos zu beschreiben. Vertreter dieser Kategorie sind Capistrano [6], ControlTier [7], Fabric [8], RunDeck [9] und Marionette Collective [10]. Zur Versionskontrolle der formulierten Vorschriften (in der jeweils verwendeten DSL) sind die üblichen Verdächtigen wie Mercurial oder Git einsetzbar.

Zum automatisierten Testen der Quellcodes bietet sich ein BDD-Tool wie Cucumber [11] an, das gemeinsam mit Puppet oder Chef genutzt werden kann. Erweiterungen wie Cucumber-Nagios [12] ermöglichen es außerdem, die Ausgaben direkt im Format bestimmter Monitoring-Tools zu erzeugen. Ein BDD-Ansatz ist besonders deshalb zu empfehlen, weil er eine Kultur des Testens mit sich bringt, bei der interessante Anwendungsfälle und nicht nur die bloße Verfügbarkeit von Servern getestet werden. Mit Continuous-Integration- Servern wie Hudson [13] oder Jenkins [14] können diese Tests zudem automatisiert ausgeführt werden. Besonders für Entwickler interessant dürften Tools zur vollautomatischen Installation von Betriebssystemen oder virtuellen Maschinen sein. Neuere Vertreter dieser Kategorie sind zum Beispiel Cobbler [15] oder Vagrant [16].

Es ist ein erklärtes Ziel der DevOps-Bewegung, die Automatisierung von Vorgängen im IT-Betrieb und die gemeinsame Nutzung von Tools zwischen Entwicklung und Betrieb zu fördern. Beispielsweise können die Entwickler ihre verwendete Konfiguration der Infrastruktur (z. B. als Puppet-Manifeste) an den Betrieb weitergeben und mit diesem abstimmen. Oder aber Entwicklung und Betrieb entwickeln den Infrastrukturcode direkt gemeinsam und schließen somit von vornherein Inkompatibilitäten zwischen den Entwicklungs-, Test- und Produktivumgebungen aus.

Links & Literatur

[3] http://puppetlabs.com

[4] http://www.opscode.com/chef

[5] http://cfengine.com

[6] http://github.com/capistrano

[7] http://controltier.org

[8] http://fabfile.org

[9] http://rundeck.org

[10] http://docs.puppetlabs.com/mcollective

[11] http://cukes.info

[12] http://auxesis.github.com/cucumber-nagios

[13] http://hudson-ci.org

[14] http://jenkins-ci.org

[15] http://fedorahosted.org/cobbler

[16] http://vagrantup.com

Dies ist ein Teil des Artikels „Die DevOps-Bewegung – Was ist das eigentlich und was bedeutet es für uns?“ von Dr. Patrick Peschlow.

Die Einleitung zum Artikel finden Sie hier. Das vorige Kapitel erreichen Sie hier, und hier geht es weiter zum nächsten Kapitel.

Stichworte:

Schreibe einen Kommentar

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

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close