DevOps

DevOps – Jenkins, Puppet & Co … wie kommt Docker jetzt ins Spiel?

Mit Docker kündigt sich gerade ein neuer – teilweise euphorisch anmutender – Hype am DevOps Horizont innerhalb der OpenSource Welt an. Ist ein reinigendes Gewitter zu erwarten oder folgt nur ein frischer Wind? Warum kündigen große Player im IT-Markt die Unterstützung dieses Themas an?

Das Konzept ist anders als die bekannte Virtualisierung, es basiert auf der Unabhängigkeit von Prozessen und Ressourcen. Es muss nicht für jeden virtuellen Server ein komplettes Betriebssystem inklusive Kernel erstellt werden. Docker ist als eine Art prozessorientierte und editierbare Konfigurationsinstanz zu verstehen, die auf unterschiedliche (read only) Images zurückgreift. Images beinhalten beispielsweise einmal Betriebssystem, einmal Applikation, einmal Infrastrukturkomponenten.

Was auf den ersten Blick fasziniert ist die Schnelligkeit, mit der Entwicklungs- und Betriebsumgebungen erstellt werden können. Benötigte ein System Engineer Stunden, vielleicht auch Tage, für die Installation und Konfiguration von Systemen, gelingt es mittels Docker – zu mindestens aktuell theoretisch – innerhalb von Minuten eine komplette Produktionstrecke Development Environment –> Test Environment –> Acceptance Test Environment –> Production Environment aufzusetzen. Hierbei kommt Jenkins zu Hilfe, der den kompletten Erstellungsprozess aus seiner GUI heraus steuerbar macht.

Cool ist, einmal erstellte Images werden gecached und können so die extrem hohe Performance in der Erstellung der oben genannten Umgebungen gewährleisten. Durch Anbindung von Repositories kann auf eine unendlich wachsende Anzahl von Imagevarianten zugegriffen werden. Images können über einzelne Layer zu dem jeweils gewünschten „SW-Infrastruktur-Stack“ zusammengestellt werden. Zum entsprechend naheliegenden Thema Sicherheit stellt RedHat erste Konzepte in Form von Zertifizierungen von Containern auf.

Was könnten nun Vorteile aus Dev und Ops Sicht sein?

Automatisch bereitgestellte Dev- und Systemumgebungen unterstützen die Agilität und Schnelligkeit für die Umsetzung von neuen Releases und Services für das Business. Die einheitliche Bereitstellung fast identischer Umgebungen für lokale Entwickler, für diverse Entwicklungs- und Testumgebungen und vielleicht auch Produktivumgebungen könnten viel Zeit einsparen und auch die Störungs- und Fehlersuche im späteren Betrieb eingrenzen. Es ergibt sich möglicherweise eine sehr viel höhere Flexibilität: Durch Docker lassen sich ganze Installationen inklusive Applikationen problemlos zu Kunden, Partnern und Cloudprovidern transferieren – follow the sun and follow the customer. Auch müssen die in der Vergangenheit immer mächtiger gewordenen Anwendungsserver nicht mehr alle Eigenschaften für Performance und Hochverfügbarkeit leisten, da diese durch die Skalierung übernommen werden. An dieser Stelle könnten so auch leichtgewichtige Anwendungsserver wie Glassfish eingesetzt werden. Freuen wir uns also auf weitere spannende (DevOps-)Zeiten und der sich damit ergebenden Chancen.

 

Gastbeitrag von unserem Kollegen Olaf Garves. Mehr zu Thema erfahrt ihr auch in dieser itSMF-Gruppe.

Schreibe einen Kommentar

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