zur Verfügung, die sich sowohl mit Amazons übrigen Cloud-Diensten als auch zum Teil mit konventionellen On-Premise-Umgebungen (etwa mit On-Premise-Jenkins-Installationen) und externen Diensten (etwa GitHub) integrieren lassen. AWS bietet inzwischen auch rein proprietäre und vollständig verwaltete DevOps-Dienste. Damit Coder und Administratoren in einem cloudbasierten DevOps-Workflow im Gleichschritt miteinander arbeiten können, müssen sie die verschiedenen AWS-Bauteile geschickt aneinander anbinden.

Als die wichtigsten Stützpfeiler von DevOps-Workflows auf AWS gelten folgende Dienste:

• CodeCommit: ein Cloud-Dienst für die Versionskontrolle in privaten Repositories,

• CodePipeline: ein Cloud-Dienst für die kontinuierliche Bereitstellung und Release-Automatisierung,

• CodeDeploy: ein Cloud-Dienst zur Automatisierung der Übergabe von Code an eine beliebige Serverinstanz (sowohl On-Premise als auch in AWS EC2).

Bereits mit Hilfe dieser drei Dienste lässt sich eine vollständige CI/CD-Pipeline (mit oder auch ohne Jenkins) auf AWS implementieren. Seit der AWS re:Invent kam auch noch AWS Code Build hinzu.

Der Dienst CodeCommit stellt Entwicklern ein privates, vollständig verwaltetes und automatisch skalierendes Git-Repository mit Unterstützung für AWS-Identitäts- und AWS-Zu-griffsmanagementdienste bereit. Der Dienst verwaltet sowohl öffentliche als auch private Repositories und ist auch bei den Letzteren - anders als GitHub - für die ersten fünf Entwickler rein kostenfrei. CodeCommit ist in der EU derzeit nur in der Region eu-west-1 verfügbar.

Bei AWS CodePipeline handelt es sich um einen verwalteten Continuous-Delivery-Dienst (CD), der es erlaubt, den

Listing 1: buildspec.yml

pre_build:

commands:

- echo Logging in to Docker Hub...

- docker login --username="$DOCKER_HUB_USERNAME" --password="$DOCKER_HUB_PASSWORD"

build:

commands:

- echo Build started on 'date'

- echo Building the Docker image...

- docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .

- docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $IMAGE_RE-PO_NAME:$IMAGE_TAG

post_build:

commands:

- echo Build completed on 'date'

- echo Pushing the Docker image...

- docker push $IMAGE_REPO_NAME:$IMAGE_TAG

Integral: CodeBuild integriert sich in den BuiLd-Schritt der AWS Pipeline (Bild 3)

Softwarebereitstellungsprozess in der Cloud nachzubilden und zu orchestrieren. CodePipeline orchestriert jede Phase der Bereitstellung: Der Dienst befragt ein Versionskontroll-Repository nach Code-Änderungen, sendet diese durch automatisierte Build- und Test-Zwischenstufen der Bereitstellungspipeline und initiiert anschließend den Release-Vorgang. In jeder Zwischenstufe lassen sich Werkzeuge von Dritt anbietern hinzuschalten.

Elastic Compute Cloud

Sie können CodeDeploy an eine CI/CD-Pipeline anbinden, um den resultierenden Anwendungscode auf Servern zu installieren. Dazu wird lediglich ein sogenannter Agent benötigt, der sowohl auf Elastic-Compute-Cloud-Instanzen (EC2) als auch auf On-Premise-Servern laufen darf.

Wann immer sich neuer Code durch die Bereitstellungspipeline durcharbeitet, übernimmt CodePipeline die Ausgabe vom Buildprozess und übergibt diese zur Installation und Ausführung auf den Applikationsservern an CodeDeploy.

AWS CodeBuild lässt sich unter anderem direkt in die Build-Stufe einer AWS CodePipeline integrieren, aber auch via AWS Management Console, über das AWS CLI, über ein HTTP-API und nicht zuletzt auch unter Verwendung von AWS SDKs ansprechen.

Quellen für AWS CodeBuild können auf GitHub oder in Amazons Objektspeicher AWS EC3 liegen, aber auch via AWS CodeCommit bereitgestellt werden. Die unterstützten Sprachen beinhalten neben Python und Ruby unter anderem auch Node.js und Scala. Eine Übergabe der resultierenden Artefakte ist unter anderem an Amazon ECR, an Docker Hub (Listing 1) und an AWS Elastic Beanstalk (zum Beispiel unter Verwendung von Apache Maven) möglich.

Die Dienste AWS Elastic Beanstalk (ein Anwendungscontainer für die beliebtesten Stacks) und AWS OpsWorks unterstützen die kontinuierliche Bereitstellung von Code- und Infrastruktur-Änderungen auf AWS.

AWS Elastic Beanstalk reduziert die Komplexität durch eine automatische Handhabung der Kapazitätenbereitstellung, horizontale Skalierung, Lastverteilung und einen

DevOps in der Wolke: Beispiel eines Jenkins-Deployments auf Amazon AWS (Bild 4)

git push und fertig: Bereitstellung von containerisierten Anwendungen mittels Jenkins auf AWS ECS (Bild 5)

Health Check Ihrer Anwendungen. Der Dienst verwaltet die verschiedenen Versionen der betreffenden Applikation und diverse Varianten der Konfiguration der Infrastruktur, um Rollbacks zu gewährleisten. Darüber hinaus arbeitet der Dienst Hand in Hand mit Auto-Scaling-Gruppen zusammen, um die Hochverfügbarkeit Ihrer Webapplikation beim Versionswechsel zu gewährleisten.

Beim Einsatz von AWS OpsWorks können Sie festlegen, welche Instanzen in welcher Reihenfolge aktualisiert werden sollen. AWS OpsWorks kann außerdem zusätzliche Befehle und Chef-Rezepte zur Laufzeit ausführen.

Asynchrone Updates

Die Praxis asynchroner Updates wurde in der DevOps-Ge-meinde auf den Namen rollendes Deployment (rolling deployment) getauft: Aktualisierungen einer Webanwendung werden nicht auf alle Instanzen gleichzeitig, sondern auf eine Instanz nach der anderen eingespielt; so lässt sich die kontinuierliche Betriebsbereitschaft einer gewissen Anzahl von Servern gewährleisten und jegliche Ausfallzeiten der eigenen Dienste verhindern.

Die eigentliche Bereitstellung der benötigten InfrastrukturBauteile auf AWS erfolgt typischerweise unter Verwendung einer CloudFormation-Vorlage. Hierbei handelt es sich um

Listing 2: AWS CodeCommit

{

"repositoryMetadata": {

"repositoryName": "neuesRepository", "repositoryDescription": "Kurzbeschreibung in HTML- oder Unicode-Zeichen",

"repositoryld":

"f3559e23-b31e-7523-aaef-950c0BEISPIEL", "accountId": "Ihre-Account-ID"

}

}

ein JSON-Dokument, das die Zusammenstellung der benötigten Ressourcen durch den Dienst CloudFormation ermöglicht.

Um ein neues Repository mit Hilfe von AWS-CodeCommit zu erstellen, können Sie wahlweise das AWS CLI oder die AWS Konsole für CodeCommit (Bild 3) verwenden. Zum jetzigen Zeitpunkt haben Sie bei der Wahl der AWS-Regionen aber leider keine wirkliche Auswahl, denn Sie müssen bisher mit der Region EU (Ireland) oder mit der US-amerikanischen Ostküste (Region North Virginia oder Region Ohio) Vorlieb nehmen. In der deutschen Region Frankfurt wird der Dienst derzeit leider noch nicht unterstützt.

Mit dem Befehl aws configure können Sie die Region überprüfen und gegebenenfalls anpassen. Die eigentliche Erstellung eines AWS CodeCommit-Repositorys mit den AWS-Tools ist ein Einzeiler:

aws codecommit create-repository --repository-name neuesRepository --repository-description "Kurzbeschreibung in HTML- oder Unicode-Zeichen"

Im Erfolgsfall gibt der Befehl ein repositoryMetadata-Objekt zurück (Listing 2). Sie können sich mit dem neuen Repository unmittelbar verbinden (wahlweise via SSH oder HTTPS) und Ihren Code committen sowie das Repository an die AWS Code Pipeline anbinden.

Mit Amazons proprietären AWS-Diensten CodeCommit, CodePipeline, Elastic Beanstalk, CodeDeploy und Cloud Formation erschöpft sich bei Weitem nicht das überaus vielfältige Repertoire von DevOps-Lösungen auf AWS.

Eingeschworene Befürworter von Jenkins-zentrierten Workflows brauchen beim Einsatz von AWS auf ihre bevorzugte Lösung keinesfalls zu verzichten. Ganz im Gegenteil: Zahlreiche Jenkins-Plug-ins wurden mit dem Ziel entwickelt, DevOps auf AWS zu ermöglichen. Im Amazon Marketplace nehmen Jenkins-AMIs (Amazon Machine Images) einen prominenten Platz ein.

Jenkins kommt auf AWS in zwei grundlegenden Einsatzszenarien zum Einsatz:

• in Amazon EC2: Serverinstanzen mit Netzwerkspeicher (Bild 4),

• Container im Rahmen von Amazon ECS: verwaltete Docker-Container auf EC2-Clustern (Bild 5).

Das Jenkins-Ökosystem unterstützt unter anderem die folgenden AWS-Dienste unter Verwendung von Jenkins-Plug-

ins:

• Amazon EC2 (Elastic Compute Cloud): Ausführung von beliebigen Serverinstanzen in virtuellen Maschinen,

• Amazon ECR (Docker Container Registry): Speichern, Verwalten und Bereitstellen von Docker-Containern,

• Amazon SNS (Simple Notification Service): Versenden von Push-Benachrichtigungen,

• Amazon ECS (EC2 Container Service): Ausführen von containe-risierten Applikationen in Produktionsumgebungen,

• Amazon S3 (Simple Storage Service): Aufbewahren von Daten im verwalteten Objektspeicher,

• AWS CloudFormation: Infrastrukturvorlagenverwaltung,

• AWS CodeDeploy: Automatisierung der Bereitstellung von Code,

• AWS CodePipeline: Code-Bereitstellung und Release-Automatisierung,

• AWS CodeCommit: Versionskontrolle in privaten oder öffentlichen Repositories,

• AWS Device Farm: Testen von mobilen Anwendungen auf mehreren Zielgeräten gleichzeitig,

• AWS Elastic Beanstalk: Bereitstellen und Skalieren von J ava-, .NET-, PHP-, Node.js-, Python-, Ruby-, Go-Anwendungen und Docker-Containern auf NGINX-, Apache-, IIS- und Passenger-Servern.

Microsoft Azure und die Google Cloud Platform haben im Vergleich zu dem DevOps-as-a-Service-Platzhirsch AWS noch einen großen Nachholbedarf.

DevOps auf Microsoft Azure

Microsofts Aufholjagd in Sachen DevOps hat beim Cloud-Riesen ein umfassendes Umdenken ausgelöst. Nicht nur hat sich Microsoft entschieden, die eigene Cloud Azure für Linux zu öffnen, um den Betrieb von quelloffenen Lösungen wie Docker zu ermöglichen, sondern die Redmonder haben auch die hauseigenen Entwicklungswerkzeuge um die Unterstützung relevanter Technologien ausgebaut, das Betriebssystem Windows Server Container-fähig gemacht und die Datenbank SQL Server auf Linux portiert.

Bereits mit der Ankündigung von Windows Server Containern, verschachtelbaren Hyper-V-Containern in Windows Server 2016 und dem Nano Server, einer leichtgewichtigen Windows-Variante, sorgte Microsoft seinerzeit für viel Aufregung. Docker läuft unter Windows Server 2016 auf einer vir-tualisierten Linux-Schicht in einer VM oder nativ auf Microsofts Hyper-V-Hypervisor (ohne eine virtuelle Maschine). Software-Entwickler auf Azure kommen zudem in den Ge-

Vagrant versus Docker

Container-Frameworks wie Docker erleichtern die Bereitstellung von Anwendungen und verbessern die Auslastung der vorhandenen Hardware.

Inzwischen sind alle relevanten Anbieter von IT-Diensten, darunter Betreiber von Mega-Datencentern, auf den Container-Zug aufgesprungen: von dem Ubuntu-Haus Canonical über Red Hat, Google, AWS, VMware und Pivotal bis hin zu Microsoft. Allein Google startet jede Woche eigenen Aussagen zufolge über 2 Milliarden Container. Die Container-Revolution wird primär von zwei Faktoren getrieben: dem explodierenden Bedarf nach einer höheren DevOps-Agilität dank möglichst kurzer Release-Zyklen und dem enormen Kostendruck der Software-Entwicklung und -Bereitstellung. Hinzu kommt die Herausforderung, eine hohe Portabilität von Anwendungen zwischen den verschiedenen IT-Umgebungen - On-Premise und Clouds - zu gewährleisten.

Bei Containern handelt es sich um ultraleichtgewichtige, hochportable Laufzeitumgebungen. Container-Frameworks wie Docker führen einzelne Anwendungen in dem Sandkasten der jeweiligen Laufzeitumgebung direkt auf dem Kernel des Host-Sys-tems, also ohne einen Hypervisor, aus. Daraus ergibt sich der größte Vorteil von Containern gegenüber VMs, nämlich die Fähigkeit, einmalig bereitgestellte Ressourcen des Host-Systems gemeinsam zu gebrauchen, um auf derselben physischen Hardware eine höhere Nutzungsdichte zu erzielen. VMs haben eine längere

Start-up-Phase als Container, sind vergleichsweise ressourcenhungrig und generell etwas träge. Intelligente Orchestrierungslösungen für Container können daher eine bessere Auslastung der vorhandenen Hardware gewährleisten als virtuelle Maschinen. Container-Images können schichtenweise aufeinander aufbauen, um die Ressourcenanforderungen für die Datenübertragung nach einer Pull-Anfrage und somit die Latenz weiter zu minimieren. Alles in allem sind Container wesentlich schneller und um ein Vielfaches kosteneffizienter als VMs.

Container erleichtern die Inbetriebnahme von virtualisierten Anwendungen. Vagrant zeichnet dagegen für die Erstellung leichtgewichtiger und gleichzeitig portabler Entwicklungsumgebungen verantwortlich (unabhängig von dem Systemunterbau).

Es ermöglicht die Automatisierung portabler Entwicklungsumgebungen für DevOps und DevSecOps und erlaubt es, die Parität des technischen Unterbaus von Dev und Ops zu garantieren.

Vagrant wurde von einem Entwickler namens Mitchell Hashimoto erstmals im Januar 2010 veröffentlicht. Die Lösung war auf Anhieb ein Selbstläufer. Durch das aktive Sponsoring von Fastly, Kiip, Typekit und Softlayer wurde dann im November 2012 das Unternehmen HashiCorp aus der Taufe gehoben. HashiCorp fokussiert primär darauf, kommerzielle Add-ons und professionellen Support und Training für Vagrant bereitzustellen; Vagrant an sich ist kostenfrei. Die treibende Kraft hinter Vagrant ist die lebhafte Open-Source-Gemeinde.

nuss eines umfassenden Satzes von Docker-spezifischen Tools für Visual Studio und ASP.NET Core von Microsoft. Darüber hinaus können Entwickler ein Docker-Image direkt aus dem Azure Marketplace beziehen und in Microsofts Cloud auf einer Ubuntu-Instanz starten. Mit der Azure-Docker-VM-Erweiterung für den Azure-Linux-Agenten können Sie unter Verwendung der CLI-Schnittstelle eine Docker VM mit jedem beliebigen unterstützten Linux-System als eine ContainerPlattform provisionieren. Die Unterstützung für Container hat Microsoft auch für Windows 10 fest verplant.

Windows 10 bietet Entwicklern bereits das Linux-Subsys-tem einschließlich der CLI-Schnittstelle Bash von Ubuntu (portiert durch den Linux-Spezialisten Canonical). Doch damit nicht genug: .NET Core läuft inzwischen sogar unter Linux. Nach der Akquisition der beliebten plattformübergrei-fenden Entwicklungsumgebung Xamarin Studio stellte Microsoft das zugehörige SDK unter eine Open-Source-Lizenz und bündelt sie mit Visual Studio.

Mitte April 2016 schaltete Microsoft die allgemeine Verfügbarkeit von Azure Container Service, einer gehosteten Lösung für Container, frei. Der Dienst bietet Entwicklern inzwischen die Wahl zwischen drei Orchestrierungs-Engines: Apache Mesos DC/OS, Docker Swarm und Google Kubernetes. Gleichzeitig beteiligt sich Microsoft an Mesosphere DC/OS, einem Datencenter-Betriebssystem für die Container-Orchestrierung, und ist kürzlich sogar ganz offiziell als ein Pla-tinum-Mitglied der Linux Foundation beigetreten.

Der Softwareriese hat sich diese Ehre eine halbe Million US-Dollar pro Jahr kosten lassen. Immerhin zählen zu dieser erlesenen Gruppe ja insgesamt nur elf Unternehmen, und diese dürfen die Richtung für so wichtige Initiativen wie das Hyperledger-Projekt vorgeben. Ohne eine enge Kooperation mit der Linux Foundation würde Microsoft in einer DevOps-dominierten Welt tatsächlich nicht allzu weit kommen.

Zu den prominentesten DevOps-Benutzern von Microsoft Azure zählt der Shell-Konzern mit seinen circa 2800 Software-Entwicklern, die ihren Code in Visual Studio für Linux, Windows, Android und macOS entwickeln.

Shell stellt seine Websoftware via Azure bereit. »Wir betreiben längst keine eigenen Server mehr«, sagt Johan Krebbers, CTO der IT-Sparte und stellvertretender Vorsitzender von Shell Global Solutions International. Der Trend, weg von der Administration (Ops) hin zur Software-Entwicklung (Dev) und Cybersicherheit (Sec) - von DevOps zu DevSecOps zu DevSec - ist somit auch im Fall von Microsoft Azure eindeutig erkennbar.

DevOps-Automatisierung in der Google-Cloud

Die Automatisierung von DevOps-Abläufen in der Google Compute Engine (GCE) dreht sich nicht ganz so stark um plattformspezifische Dienste wie im Fall von Amazon AWS. GCE trumpft im Hinblick auf die benutzerfreundliche Bedienung und wettbewerbsfähige Preise auf (unter anderem dank der minutenweisen Abrechnung), kann jedoch mit der Vielfalt von APIs und Diensten von AWS nicht mithalten.

Dafür sind viele GCE-Dienste Open Source; das Risiko eines Vendor-Lock-ins fällt damit bei den beiden anderen An-

Diensterkennung: Consul von HashiCorp, eine DNS-basierte Diensterkennungslösung, kommt auf GCE im Rahmen eines HAProxy-basierten Lastverteilers zum Einsatz (Bild 6)

bietern weitaus höher aus als bei der GCE. Dennoch sind sich die drei verschiedenen Clouds - AWS, Azure und GCE - im Prinzip recht ähnlich. So bietet Google beispielsweise verwaltete Instanzgruppen, das heißt, Vorlagen für die Bereitstellung identischer Instanzen mit der Fähigkeit zur automatischen Skalierung der Gruppe auf der Basis von Richtlinien für die optimale Auslastung. Das ist ein Feature, das sich in einer ähnlichen Form auf AWS vorfinden lässt, zum Beispiel in Form von Autoscaling Groups.

Typische Aufgaben von DevOps-Teams, die GCE einsetzen, umfassen laut dem Anbieter:

• das Aufsetzen neuer Systemarchitekturen (zum Beispiel Workloads rund um High-Availability-Datenbanken wie Apache Cassandra oder Redis),

• die Entwicklung von robusten, sicheren und Hacker-festen Anwendungen,

• das Bereitstellen von Webapplikationen und -Diensten in neuen geografischen Orten (zum Beispiel im Rahmen der Ausweitung der Geschäftstätigkeiten von Europa auf Nordamerika und Asien),

• Inbetriebnahme von leistungsfähigen, DDoS-resistenten Deployments.

Was GCE von den anderen beiden Clouds - Amazon AWS und Microsoft Azure - unterscheidet, ist Googles klare Präferenz für quelloffene Lösungen, die sich in zahlreichen Open-Source-Projekten aus Googles eigener Feder und in den gebotenen Cloud-Diensten reflektiert.

So bietet Google auf GCE unter anderem diverse Lösungen für die automatische Diensterkennung, um die Automatisierung von DevOps-Abläufen zu vereinfachen. Erfahrungsgemäß können sich scheinbar minimale Änderungen der Infrastruktur auf so viele verschiedene Aspekte des Deployments auswirken (zum Beispiel geänderte IP-Adressen, Passwörter und Schlüsselpaare et cetera), dass manuelle Nachbesserungen einfach nicht in Frage kommen.

Erst der völlige Verzicht auf starre, hart codierte Konfigurationen und der konsequente Einsatz von Diensterkennung schaffen hier Abhilfe. ►

0; CONSUL in HashiCorp lHl Int,

Service discovery and j

configuration made easy. § •

Distributed, highly i • •••

available, and datacenter- 1

aware. \ •

Lösen Sie die wirklichen Probleme

Erstellen Sie eine Infrastruktur mit Watson, Software und Services auf der Bluemix-Cloud-Plattform

Anpassung und Bereitstellung von Bare-Metal-Servern in Bluemix

Integrieren Sie

kognitive Watson-Services in Ihre Systeme

Erstellen, migrieren oder erweiterrpSie II erste App in Bluemix

Konfigurieren und erstellen Sie eine leistungsfähige, skalierbare private OpenStack-Cloud

Kronjuwelen: IBM strickt seine DevOps-Dienste rund um kognitive Lösungen herum (Bild 7)

Die GCE stellt DevOps-Anwendern für ebendiese Aufgabe eine Vielzahl von Werkzeugen zur Verfügung, darunter:

• Consul (http://consul.io): ein Diensterkennungswerkzeug von HashiCorp (Bild 6),

• etcd (http://coreos.com/etcd): ein verteilter Speicher von Schlüssel-Wert-Paaren,

• Apache Zookeeper (http://zookeeper.apache. org): ein quelloffener Dienst für die Verwaltung von Konfigurationsdaten.

Erst der Einsatz dieser Werkzeuge ermöglicht es DevOps-Teams auf GCE, eine hohe Verfügbarkeit ihrer Dienste zu gewährleisten.

IBM Bluemix DevOps Services

IBM bietet mit Bluemix DevOps Services eine eigene DevOps-Plattform in der Cloud und trumpft dabei mit kognitiven Diensten der Wat-son-Plattform auf (Bild 7). Zu den deutschen Anwendern von IBMs Lösungen zählen Organisationen wie die Technische Universität München, die Technische Universität Berlin, Airbus Helicopters, die Deutsche Nationalbibliothek, die DATEV eG, die Deutsche Rentenversicherung BadenWürttemberg und ThyssenKrupp Marine Systems.

In IBM-zentrischen Umgebungen ist quelloffene Software überaus willkommen. Anstelle von Jenkins kommen aber des Öfteren IBMs hauseigene Bluemix DevOps Services in Kombination mit Node.js und Grunt zum Einsatz. Die Nutzung dieser Werkzeuge lässt sich anhand einer Applikation zur Verwaltung von Lizenzbedingungen erläutern.

Nichts ist einfacher, als im Eifer des DevOps-Gefechts die Lizenzbedingungen der eingesetzten Bibliotheken zu vernachlässigen. Spätestens vor der Freigabe einer neuen Softwareversion müssen die Entwickler und Release-Manager sicherstellen, dass die verwendeten Bibliotheken den avisierten Einsatz - zum Beispiel die kommerzielle Nutzung - explizit zulassen. Wer etwa eine Node.js-Applikation baut, sollte besondere Aufmerksamkeit den zahlreichen Dependencies und ihren jeweiligen Lizenzbedingungen widmen. Das ma-

^ Eine Runtime-unabhängige Spezifikation

Bei App Container handelt es sich um eine Spezifikation der DevOps-Gemeinde für portable Anwendungscontainer (https://github.com/appc).

Die Spezifikation definiert gewisse Aspekte des Betriebs von Anwendungscontainern, darunter das Image-Format, die Laufzeitumgebung und die Mechanismen zum Erkunden von Anwendungscontainern. Die Spezifikation ist nicht an eine Implementierung gekoppelt. Sie legt lediglich fest, wie die betreffende Applikation in ein App-Container-Image verpackt werden soll, wie sie aus dem Netzwerk heruntergeladen und schließlich als ein Container ausgeführt werden kann.

nuelle Zusammenstellen dieser Informationen ist nicht nur mühsam und zeitraubend, es ergibt ja auch im DevOps-Zeit-alter einfach überhaupt keinen Sinn mehr.

Um dieses Beispiel einer Applikation zur Verwaltung von Lizenzbedingungen in einem DevOps-Workflow nachzuvollziehen, benötigen Sie vier Komponenten:

• eine Node.js-Applikation,

• die neueste Version von NPM,

• eine IBM Bluemix DevOps Services Pipeline,

• Grunt, den JavaScript-Taskrunner ab der Version 0.45 (sowohl das Grunt CLI als auch das Node-Modul).

Zwar bringt Node.js NPM vorinstalliert mit, doch in der Regel wird der Paketmanager deutlich häufiger aktualisiert als das Framework selbst. Aus diesem Grund empfiehlt es sich, NPM-Aktualisierungen regelmäßig aufzuspielen, um die Software auf dem neuesten Stand zu halten.

Um Grunt zu installieren, führen Sie erst einmal aus dem root-Verzeichnis Ihres Projekts heraus folgenden Befehl aus:

npm install -g grunt-cli

Jetzt benötigen Sie noch den Grunt-Taskrunner. Mittels npm install grunt --save-dev

fügen Sie der Datei package.json Grunt als eine der Abhängigkeiten Ihres Projekts hinzu. Als Nächstes benötigen Sie gruntfile.js; diese unbedingt gültige JavaScript-Datei gehört zusammen mit der Datei package.json in das root-Verzeichnis Ihres Projekts. Diese beiden Dateien sollten Ihrem Quell-code-Repository beigefügt werden. Ihre Datei gruntfile.js könnte zum Beispiel wie folgt aussehen:

module.exports = function(grunt) { grunt.initConfig({

pkg: grunt.file.readJSON('package.json')

});

grunt.registerTask('default');

};

Nachdem Sie Grunt in Ihrem Projekt eingerichtet haben, können Sie jetzt ein Grunt-Taskfile erzeugen, damit Grunt Ihren benutzerspezifischen Code ausführt.

Erstellen Sie ein Verzeichnis mit dem Namen build_tasks im Wurzelverzeichnis Ihres Projekts und hierin eine Datei namens licenses.js. Diese beinhaltet Ihre Grunt-Tasks und kann zum Beispiel so aussehen:

module.exports = function (grunt) {

'use strict';

grunt.registerTask('example', 'Example task', function () {

});

};

Dieser Code registriert einen Task, der mittels gruntfile.js aufgerufen werden kann. Hierzu müssen Sie diese Datei entsprechend anpassen:

npm install grunt --save-dev module.exports = function(grunt) { grunt.initConfig({

pkg: grunt.file.readJSON('package.json')

});

grunt.task.loadTasks('build_tasks'); grunt.registerTask('default', ['example']);

};

Zum Testen Ihres Grunt-Tasks geben Sie in der Kommandozeile ganz einfach den Befehl grunt ein. Im Erfolgsfall erwartet Sie das folgende Resultat:

Listing 3: gruntfile.js für zwei Lizenzumgebungen

grunt.initConfig({

pkg: grunt.file.readJSON('package.json'), license_finder: { dev: {

options: {

production: false,

out: 'npm-dev-licenses.csv',

csv: true

}

},

prod: { options: {

production: true, out: 'npm-prod-licenses.csv', csv: true }}}

});

Running "example" task Done, without errors.

Fügen Sie zu Ihrem Projekt das Node-Modul grunt-license-finder hinzu, indem Sie im Wurzelverzeichnis Ihres Projekts den folgenden Befehl ausführen:

npm install grunt-license-finder --save-dev

Das soeben installierte Plug-in müssen Sie jetzt noch aktivieren, indem Sie der Datei gruntfile.js die folgende Zeile hinzufügen:

grunt.loadNpmTasks('grunt-license-finder');

Fügen Sie dem Datenobjekt, das in der gruntfile.js-Datei Ihres Projekts an die Methode grunt.initConfig() übergeben wird, einen Abschnitt namens license_finder hinzu:

grunt.initConfig({ pkg: grunt.file.readJSON('package.json'), license_finder: {

}

});

In diesem Abschnitt legen Sie dann die gewünschten Optionen fest.

Sie können bei Bedarf auch zwei Berichte für serverseitige Abhängigkeiten erzeugen: einen für die Produktionsumgebung und einen für die Entwicklungsumgebung. Bei den Abhängigkeiten der Entwicklungsumgebung handelt es sich um solche, die ausschließlich in der Phase der Entwicklung und Automatisierung zum Einsatz kommen (zum Beispiel grunt und grunt-license-finder), während es sich bei den Abhängigkeiten der Produktionsumgebung um solche handelt, die zur Laufzeit der Anwendung auf dem Produktionsserver zum Einsatz kommen.

Wenn Sie in der Datei package.json eine neue Abhängigkeit definieren, können Sie diese entweder der Produktionsoder der Entwicklungsumgebung zuweisen. Erstellen Sie im Abschnitt license_finder für jede der beiden Kategorien der Abhängigkeiten jeweils eine eigene Zielumgebung (target). So können Sie die Produktions- und Entwicklungsumgebung sauber auseinanderhalten (Listing 3).

Sie können die Optionen Ihren eigenen Bedürfnissen anpassen. Die Option production gibt an, ob es sich um die Produktions- oder die Entwicklungsumgebung handelt. Die Option out legt die Ausgabedatei fest. Mit der Option csv entsteht eine CSV-Datei.

Weiterhin benötigen Sie einen sogenannten Target-Task, um die beiden Tasks von license_finder aufrufen zu können, also einen für den Bericht zur Produktions- und einen anderen für den Bericht zur Entwicklungsumgebung. Hierzu fügen Sie die folgende Zeile in Ihre gruntfile.js-Datei ein:

grunt.registerTask('server-side-license', ['license_finder:dev', 'license_finder:prod']); ►

Das vollständige gruntfile.js-Skript nach dem Einbinden der serverseitigen Änderungen finden Sie in Listing 4.

Nun können Sie den Task server-side-license auf die Probefahrt nehmen, indem Sie Folgendes in die Kommandozeile eingeben:

grunt server-side-license

Ist alles glatt gelaufen, so erhalten Sie eine Erfolgsmeldung.

Anstatt die clientseitigen Abhängigkeiten mühsam zu Fuß abzustecken, indem Sie alle benötigten Bibliotheksdateien herunterladen, können Sie diesen Prozess viel komfortabler mittels einer Bower-Konfigurationsdatei automatisieren.

Nachdem Sie Bower auf Ihrem System installiert und für Ihr Projekt angepasst haben, werden alle clientseitigen Abhängigkeiten in einer Datei namens bower.json gespeichert. Achten Sie unbedingt darauf, dass alle clientseitigen Abhängigkeiten nicht direkt im Quelltext referenziert, sondern durchgängig von Bower eingebunden werden. Nur auf diese Weise können Sie sicherstellen, dass der dadurch generierte Bericht auch akkurat ist.

Um alle benötigten Abhängigkeiten zu ermitteln, fügen Sie das Node-Modul bower-license Ihrem Projekt hinzu, indem Sie im Wurzelverzeichnis Ihres Projekts den folgenden Befehl eingeben:

npm install bower-license --save-dev

Nachdem das Plug-in installiert ist, sollten Sie dieses innerhalb der Datei license.js mit einer Zeile JavaScript-Code wie folgt aktivieren:

var license = require('bower-license');

Listing 4: gruntfile.js

module.exports = function (grunt) { grunt.initConfig({ pkg: grunt.file.readJSON('package.json'), license_finder: { dev: {

options: { production: false, out: 'npm-dev-licenses.csv', csv: true }}, prod: { options: {

production: true, out: 'npm-prod-licenses.csv', csv: true

}}}

});

grunt.task.loadTasks('build_tasks'); grunt.loadNpmTasks('grunt-license-finder'); grunt.registerTask('server-side-license', ['license_finder:dev', 'license_finder:prod']);

};

Nach dem erfolgreichen Laden des Node-Moduls bower-license coden Sie jetzt Ihren benutzerdefinierten Task, der dieses Modul aufruft.

Erzeugen Sie einen Task namens run_bower_license, um alle Abhängigkeiten zu ermitteln und in eine Datei auszugeben. Den hierfür benötigten Code können Sie Listing 5 entnehmen.

Der Code registriert einen Grunt-Task namens run_bower_ license, der zwei Parameter entgegennimmt. Der eine Parameter legt das Verzeichnis fest, in dem die Bower-Komponen-ten abgelegt werden sollen. Der zweite Parameter definiert den Namen der Ausgabedatei.

Um Verwechslungen zu vermeiden, löscht der Task zudem bereits existierende Ausgabedateien und ruft die bower-li-cense-Bibliothek auf, um alle clientseitigen Abhängigkeiten zu ermitteln.

Für jede Abhängigkeit, die der Grunt-Task run_bower_li-cense findet, versucht die Software, die folgenden Informationen zu ermitteln und, falls vorhanden, in der Ausgabedatei zu notieren:

• den Namen der Bibliothek,

• die Versionsnummer,

• den URL des Git-Repository,

• die Lizenz,

• die Homepage.

Registrieren Sie jetzt in der Datei gruntfile.js einen neuen sogenannten Target-Task, der den run_bower_license-Task aufrufen soll, und nennen Sie ihn client-side-license:

grunt.registerTask('client-side-license',

['run_bower_license:all']);

Lassen Sie den neuen Task client-side-license von der Grunt-Kommandozeile aus ablaufen:

grunt client-side-license

Im Erfolgsfall sollte die Ausgabe in der Grunt-Kommandozei-le folgendermaßen aussehen:

Running "run_bower_license:all" (run_bower_license) task

Executing run_bower_license task

Output file already exists. Will delete it

End of run_bower_license task

Done, without errors.

Erzeugen Sie jetzt einen Task namens get-licenses, der sowohl die clientseitigen als auch die serverseitigen Versionen der Tasks aufruft:

grunt.registerTask('client-side-license',

['run_bower_license:all']);

Nach all diesen Erweiterungen sollte Ihre voll ausgebaute Datei gruntfile.js dem Inhalt von Listing 6 entsprechen. ►

Indem Sie den Task get-licenses von der Grunt-Komman-dozeile aus aufrufen, können Sie sowohl den clientseitigen als auch den serverseitigen Bericht abrufen:

grunt get-licenses

Zu guter Letzt folgt noch die Anbindung an die IBM Bluemix DevOps Services. Navigieren Sie zur Ansicht Build & Deploy Ihres Projekts im Dashboard von IBM Bluemix DevOps Services. Aktivieren Sie das Pipeline-Feature und erstellen Sie eine neue Pipeline. Sie besteht aus zwei Phasen: In der einen Phase (Build Stage) wird der Build ausgeführt, in der anderen (Deploy Stage) wird er via Bluemix bereitgestellt.

Nach dem Erstellen der Pipeline konfigurieren Sie diese wie folgt:

• Input Type: Build Artifacts,

• Stage: Build Stage,

• Job: Build,

• Stage Trigger: Run jobs when the previous stage is completed.

Erstellen Sie eine neue Job-Instanz vom Typ Build. Im Abschnitt Execute License tasks wählen Sie im Menü Builder

Type den Eintrag Grunt und tragen dort die folgenden CLI-Befehle ein:

#!/bin/bash npm install

node_modules/bower/bin/bower install grunt get-licenses

Speichern Sie die so erstellte Konfiguration der PipelineStage ab und führen Sie diese aus (Bild 8). Mit einem Klick auf View Logs and History können Sie die Logs und die Liste der Artefakte einsehen.

Die Ausführung der Skripts in der Bluemix-Pipeline ist natürlich sehr IBM-spezifisch. Die Bower-Tasks können Sie jedoch auch sehr leicht anpassen, sodass diese in entsprechender Weise in Gulp oder in einem anderen Task-Automatisie-rungsframework funktionieren.

AWS CodeCommit in DevOps-Workflows

Kaum jemand möchte im laufenden Betrieb von seinem bisherigen Git-Repository-Server direkt auf eine neue Lösung wie den Dienst AWS CodeCommit umstellen.

Der Grund: Bereits die kleinsten Abweichungen der Funktionsweise dieser beiden Lösungen können den Workflow ernsthaft ins Stottern bringen. Sollten Sie ohnehin bereits in der AWS-Cloud arbeiten, möchten Sie sicherlich nur ungern an einem laufenden, wichtigen Projekt experimentieren. Doch hier gibt es Abhilfe. Sie können sich leicht aus dieser Situation herausmanövrieren, indem Sie die Push-Commits an zwei Git-Reposi-tories gleichzeitig senden.

Fazit

Die Entwicklung und die Bereitstellung von Software sind heutzutage zwei Seiten derselben Münze. Eine kontinuierliche und reibungslose Bereitstellung inkrementeller, zuverlässiger Software-Upgrades (Continuous Delivery) im Rhythmus vollautomatisierter Build-, Test- und Deploy-Abläufe gehört heutzutage ins Pflichtenheft der Entwicklung von Web- wie auch mobilen Anwendungen. Moderne Dev-Abteilungen müssen sich den dynamischen Anforderungen eines Dev-Ops-Workflows mit Agilität anpassen, und nirgendwo gelingt es einfacher als in der Cloud.

Die Fähigkeit, Ressourcen flexibel und bedarfsgerecht in der virtualisierten Umgebung einer Cloud elastisch zu provisionieren und umgehend zu konfigurieren, um skalierbare Applikationen möglichst kosteneffizient bereitzustellen, hat zu einer neuen Grundeinstellung geführt.

Erstmals arbeiten Entwickler, CybersecurityExperten und die Betreiber der resultierenden Anwendungen kontinuierlich Hand in Hand zusammen. Crossfunktionale Teams sorgen für einen Zufluss von Querdenkern und eine größere Vielfalt von Kompetenzen - zwei Merkmale, die sich auf die resultierenden Softwarelösungen generell sehr positiv auswirken. ■

Filipe Pereira Martins und Anna Kobylinska

sind international anerkannte IT-Berater mit Schwerpunkt auf Cloud-Lösungen. Sie stehen den Lesern der web & mobile developer gern per Twitter via @D1gitalPro und @D1gitalInfo zur Verfügung.