Interoperabilität und Sicherheit

DevOps-Workflows – integrierte Tools und Methoden

| Autor / Redakteur: Filipe Pereira Martins und Anna Kobylinska * / Stephan Augsten

Jenkins hat sich zur zentralen Drehscheibe für DevOps entwickelt, wie auch die Jenkins World 2016 in Santa Clara, Kalifornien, beweist.
Jenkins hat sich zur zentralen Drehscheibe für DevOps entwickelt, wie auch die Jenkins World 2016 in Santa Clara, Kalifornien, beweist. (Bild: Jenkins World)

Die Art und Weise, wie moderne Software entsteht, hat sich im Zuge der DevOps-Revolution grundlegend geändert. Innovative DevOps-Workflows versprechen den Entwicklern eine bisher ungekannte Flexibilität, die ihre Produktivität auf ein neues Niveau hebt.

DevOps verbindet die Softwareentwicklung (Dev) mit kontinuierlicher Bereitstellung (Ops) von neuem Code. Mit dieser neuen Denkweise gehen neue Werkzeuge und neue Arbeitsmethoden einher. Unternehmen müssen Wege finden, um ihre Dev- und Ops-Aktivitäten möglichst reibungslos zu koordinieren, damit Softwareentwickler und Administratoren ihre vorprogrammierten Grabenkämpfe beilegen können.

Solange das nicht der Fall ist, stehen sich die betroffenen Abteilungen gegenseitig im Wege. Aus der Sicht der Ops-Fachkräfte ist an etwaigen Ausfallzeiten der Dienste neuer Code und somit die Dev-Abteilung schuld. Aus der Sicht der Dev-Abteilung sind die Admins der Ops-Sparte schuld, weil der Code in der Testumgebung ja problemlos lief.

Solange sich die Entwicklungs- und Testumgebungen in der Produktion nicht mit absoluter Vorhersehbarkeit reproduzieren lassen, ist eine produktive und effiziente Zusammenarbeit im Rahmen von DevOps einfach nicht möglich. Wenn es dann aber klappt, kommt ein wahrer Quantensprung an Produktivität zustande.

Puppet Labs fand seinerzeit heraus, dass hochperformante IT-Teams dank DevOps neuen Code 30 Mal häufiger mit 200-mal kürzeren Vorlaufzeiten bereitstellen. Dabei haben sie 60-mal weniger Ausfälle und eine im Durchschnitt 168 Mal schnellere Wiederherstellungsrate vorzuweisen. Wenn es um DevOps geht, gilt die Maxime: Der Workflow macht die Musik.

Automatisierter Nachschub für verteilte Anwendungen und Microservices

Das DevOps-Modell setzt auf einen ständigen Fluss von Code-Verbesserungen, die im Zuge kontinuierlicher Bereitstellung über automatisierte Nachschubwege in Betrieb genommen werden. Dabei hat sich der Charakter von Anwendungen im Laufe der vergangenen Jahre dramatisch geändert.

Software entsteht längst nicht mehr in einer einzigen Entwicklungssprache. Vermehrt kommen völlig verschiedene Entwicklungs- und Skriptsprachen zum Einsatz, die ihre verschiedenen Stärken idealerweise in unterschiedlichen Aufgabenbereichen und im Zusammenhang mit diversen APIs ausspielen. Verteilte Anwendungen werden als Microservices konzipiert, containerisiert und orchestriert, vorzugsweise unter Gewährleistung vollautomatischer Selbstheilung.

Eine Entwicklungs-, Test- oder Produktionsumgebung auf einer physikalischen Maschine oder in einer VM degradiert im Laufe der Zeit; Builds gehen schon mal alleine deswegen schief, weil sich der Systemunterbau im Zuge der Benutzung „verbraucht“. Container können Abhilfe schaffen. Container-Frameworks wie Docker oder Rocket erlauben eine portable Entwicklung und die elastische Bereitstellung von Applikationen und Microservices unter Gewährleistung von garantiert reproduzierbaren Leistungsmerkmalen.

Bereitstellung und Konfiguration containerisierter Microservices lassen sich mit einer Vielzahl von Orchestrierungs-Werkzeugen wie Chef, Puppet oder Ansible wie auch mit Hilfe von proprietären verwalteten Cloud-Diensten implementieren. Doch wenn es darum geht, das Erzeugen von Builds sowie das Verpacken, Testen und Bereitstellen von Software-Versionen zu koordinieren, greifen diese Lösungen derzeit noch zu kurz. Klassische Build-Werkzeuge wie make, MSBuild, Ant, Maven und Gradle reichen in einem DevOps-Workflow auch nicht mehr aus.

Zum Glück sind im Schatten der Container-Revolution inzwischen ganze Ökosysteme vorwiegend quelloffener DevOps-Lösungen entstanden. Es gibt nahezu so viele Referenzarchitekturen für DevOps wie DevOps-Workflows selbst. Die Mehrheit der bewährten DevOps-Workflows setzt neuerdings auf Jenkins auf.

Jenkins als zentrale Drehscheibe für DevOps-Workflows

Mit dem quelloffenen Framework Jenkins lassen sich Softwareentwicklungs- und -Bereitstellungs-Workflows in nahezu beliebigem Umfang orchestrieren. Dank seiner beachtenswerten Fähigkeit, sich in eine Vielzahl bestehender Umgebungen zu integrieren, hat sich Jenkins zur zentralen Drehscheibe für DevOps entwickelt.

Jenkins verwaltet die Entstehung und Ablieferung von Code als eine Continuous Integration and Deployment (CI/CD) Engine für die Automatisierung und Orchestrierung von Abläufen im Rahmen der Softwareentwicklung. Ein Ökosystem von über tausend Plug-Ins hat dem Framework eine ganze Schar eingeschworener Benutzer beschert.

Durch die Integration mit einem Quelltextkontrollsystem kann Jenkins mehrere Build-Prozesse für verschiedene Umgebungen auslösen. Die Ausgabe resultiert – in Abhängigkeit von der gewünschten Zielplattform – in einer Sammlung von Dateien im .exe-, .dll- oder .jar-Format.

Eine Pipeline (ab Jenkins 2) wird in einer Groovy-basierten DSL-Sprache definiert. Pipeline-Jobs lassen sich mit Hilfe von Jenkins- und Java-APIs beschreiben. Wer seine Pipelines in einem Versionskontrollsystem verwaltet, kann sie sogar von dort aus via Jenkins zur Laufzeit beziehen. Eine Pipeline ermöglicht das Steuern der Job-Ausführung über die Jenkins-API, lässt sich zu einem beliebigen Zeitpunkt anhalten und überlebt sogar einen Neustart von Jenkins.

Jenkins kann sich mittels Plug-Ins mit Build-Werkzeugen wie Ant und Maven integrieren. Darüber hinaus kann das Framework unter Verwendung von einfachen Shell-Skripten auch andere Umgebungen wie Node.js, Python oder Ruby ansprechen. So lassen sich in der Pre-Build- und in der Post-Build-Phase praktisch beliebige notwendige Schritte durchführen: Build-Jobs bei Bedarf verwerfen, Deployment-Jobs abbrechen, Deployments mittels Replikation hinaus skalieren, etc.

Auf der Ops-Seite kann Jenkins Konfigurationsmanagementsysteme wie Chef oder Puppet mit Hilfe von Plug-Ins in die Pipeline einbinden; darüber hinaus lässt sich die Ausgabe dieser Orchestrierungswerkzeuge dann auch Jenkins-gesteuert auswerten. Auch für die Integration mit Cloud-Umgebungen hält die Jenkins-Gemeinde passende Erweiterungen parat.

Dank der nahtlosen, engen Integration mit Versionskontrollsystemen wie Git kann Jenkins ein Build-Prozess automatisch auslösen wann immer ein Entwickler seinen Code bereitstellt. Dieser Vorgang resultiert jedes einzelne Mal in einem neuen Docker-Image, welches unmittelbar in allen Umgebungen der DevOps-Pipeline verfügbar gemacht wird.

Interoperabilität und Cyber-Sicherheit von DevOps-Workflows

Vierzehn führende DevOps-Technologieführer kamen auf der Jenkins World-Konferenz im vergangenen Jahr zusammen, um den Grundstein für eine erfolgreiche DevOps-Zukunft zu legen. Unter der Leitung von CloudBees haben unter anderem Atlassian, BlazeMeter, CA Technologies, Chef, DevOps Institute, GitHub, Infostretch, JFrog, Puppet, Sauce Labs, SOASTA, SonarSource und Sonatype eine Allianz geschlossen.

Gemeinsam wollen die Anbieter die Softwareentwicklung nach dem DevOps-Paradigma kontinuierlicher Bereitstellung mit einer Initiative namens „DevOps Express“ zu vereinfachen. Das Ziel besteht in der Gewährleistung langfristiger Interoperabilität verschiedener einzelner Ökosysteme von DevOps-Lösungen

DevOps als ein Prozessverbesserungsansatz mag einen Quantensprung für die Softwareentwicklung darstellen, dies befreit betroffene Unternehmen jedoch nicht von ihren Compliance-Pflichten. Die unmittelbare Bereitstellung von Code gemäß dem DevOps-Paradigma hat vielmehr ein neues Problem auf den Plan gerufen: die Sicherheit unternehmenskritischer Systeme. Diese Problematik taufte die Industrie auf den Namen SecOps/DevSecOps.

Fazit

Heutige Unternehmen stehen unter einem enormen Druck, ihre Geschäftstätigkeiten unter Gewährleistung von Hochverfügbarkeit durch modernste Software zu unterstützen. Für die Entwickler gilt es, auf die Wünsche der Benutzer und die Innovationen der Mitbewerber in möglichst kurzen Release-Zyklen zu reagieren.

Leistungsstarke DevOps-Workflows bieten in dieser Hinsicht einen enormen Wettbewerbsvorteil. Doch ohne den Schritt von DevOps zu SecOps/DevSecOps — also DevOps unter Einhaltung von Cybersicherheitsrichtlinien — lassen sich weder der Datenschutz noch die Cybersicherheit gewährleisten. Dieser Problematik ist der nächste Beitrag dieser zweiteiligen Serie gewidmet.

* Filipe Pereira Martins und Anna Kobylinska schreiben unabhängig für die Insider-Portale und sind bei der Soft1T S.a r.l. Beratungsgesellschaft mbH, McKinley Denali Inc. (USA), beschäftigt.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44654067 / Configuration-Management)