2000 Build-Jobs, 35 aktive Entwicklungsprojekte, 250 Entwickler – um in diesem Setting die Build-Umgebung flexibel und gleichzeitig reproduzierbar zu halten, kommt bei Infonova ein Technologie-Stack bestehend aus Mesos, Docker, CoreOS und OpenStack zum Einsatz. Welche Lektionen daraus zu lernen sind, haben wir im Rahmen der DevOpsCon 2015 mit Georg Öttl besprochen.

JAXenter: Hallo Georg. Wir sind hier auf der DevOps-Konferenz – doch es zeigt sich in den Diskussionen immer wieder, dass es ganz unterschiedliche Ansichten gibt, was den Kern der DevOps-Bewegung ausmacht. Was ist für dich das Spannende an DevOps?

Georg Öttl: Beim Thema DevOps geht es mir vor allem darum, Continuous Delivery einzuführen, zu verbessern, und – wenn möglich – zu vereinheitlichen; und das in unterschiedlichen Organisations- oder Projektstrukturen, mit unterschiedlichen Entwicklungsprozessen und Entwicklungstools und bei unterschiedlichen Kunden. Was ist spannend daran? Alles! Aktuell begeistert mich, dass es mit Container-Technologien wie z.B. Docker nun tatsächlich möglich ist, Software reproduzierbar auszuliefern.

JAXenter: Dein Thema auf der DevOpsCon ist die Reproduzierbarkeit von Builds. Auf welche typischen Probleme stößt man dabei?

Georg Öttl: Aktuelle Build Server wie z.B. Jenkins oder Teamcity sind so aufgebaut, dass ein zentraler Build Server Builds an Build Slaves zur Ausführung weitersendet. Die Build Slaves sind typischerweise VMs, die aus Performancegründen wiederverwendet werden, d.h. sie überdauern einen Build. Daraus ergibt sich im Betrieb, dass der Zustand des Build Slaves den aktuellen Build beeinflussen und verfälschen kann. Falsche Build- und Testresultate können auftreten.

Ein weiteres Problem ist der Configuration Drift von unterschiedlichen Build-Slave-Typen. In unserem Fall brachte die Wartung und zur Verfügungstellung von aktuell 54 (Zahl steigend) Build-Slave-Typen das DevOps-Team an seine Grenzen.

Beide Punkte führten zu einer vom Entwickler als instabil wahrgenommenen Build-Umgebung.

JAXenter: Und wie sehen hier Lösungsansätze aus?

Georg Öttl: Durch eine Provisionierungsstrategie, die vorgibt, dass ein Build Slave genau einmal für einen Builld verwendet wird, stellen wir sicher, dass es keine Seiteneffekte zwischen den Builds gibt. Durch die direkte Anbindung von Jenkins an Mesos werden Build-Slaves-Typen konfiguriert und dynamisch je nach Bedarf provisioniert.

JAXenter: Ihr verwendet selbst einen Technologie-Stack bestehend aus Mesos, Docker und CoreOS. Wie genau spielen diese Komponenten zusammen?

Georg Öttl: Mesos verwaltet die Hardware-Ressourcen des CoreOS Clusters und der Build Slaves, die von Mesos gestartet werden. Die Build Slaves werden als Docker-Container gelauncht, die sich beim Start über JNLP zum zentralen Jenkins Server verbinden. CoreOS stellt die unterste Schicht unseres Technologie-Stacks dar und bietet ein leichtgewichtiges, schnell startendes OS, das eine aktuelle Kernel-Version und Docker bereits vorinstalliert hat.

JAXenter: Lief die Migration von VMs auf Mesos/Docker problemlos ab?

Georg Öttl: Die Migration auf Server-Seite lief in Bezug auf die Migration von VMs auf Mesos/Docker gut. Herausfordernd war für das DevOps-Team die Umstellung auf die neuen Technologien und das Debugging im Fehlerfall. Für die Benutzer der Build-Umgebung waren eher die strikteren Regeln bzgl. Ressourcen-Nutzung problematisch, da in unserem aktuellen Setup Überschreitungen strikt mit einem Abbruch des Prozesses gehandhabt werden.

JAXenter: Wo siehst du die größten Vorteile Eures jetzigen Systems?

Georg Öttl: In der Reproduzierbarkeit der Builds, der dynamischen Ausnutzung von vorhandenen Hardware-Ressourcen und der Abkapselung von Prozessen auf geteilten Ressourcen.

JAXenter: Und was ist die Kernbotschaft deiner Session auf der DevOpsCon? Was willst du den Besuchern auf jeden Fall mit auf den Weg geben?

Georg Öttl: Kein Entwickler oder Opsler will aufgrund von Fehlern im automatisierten Build und Delivery Environment in seiner Arbeit, nämlich der Software-Entwicklung, behindert werden. Keine Firma will unnötig Geld für statisch reservierte Ressourcen verschwenden, die eigentlich nicht mehr gebraucht werden.

Mit dem aktuellen Technologie Stack, den wir verwenden, kommen wir einer Lösung für obige Anforderungen sehr nahe. Wenn Fehler passieren, sind sie auf tatsächliche Software/Delivery-Fehler zurückzuführen. Wenn Ressourcen nicht mehr gebraucht werden, dann werden sie dynamisch wiederverwendet.

JAXenter: Vielen Dank für dieses Interview!