JAX 2017, Mainz: Vortrag von Josef Fuchshuber (@fuchshuber, Cheftechnologe bei QAware) und Tobias Placht (@knacht, Software Ingenieur bei QAware). Abstract: Wie oft kannst du ein neues Feature releasen? Jede Woche? Jeden Tag? Jede Stunde? Continuous Delivery ist einer der wesentlichen Treiber, warum wir Cloud-native Anwendung bauen. Für Software-driven Organisationen ist das der Schlüssel für eine sicherere, stabilere Software bei minimiertem Risiko und kurzen Feedbackschleifen. Die Herausforderung dabei ist, aus jeder Codeänderung möglichst schnell eine lauffähige und gründlich getestete Software zu machen. Das ist für viele Firmen ein wesentlicher Wettbewerbsvorteil. Wir zeigen in diesem Vortrag eine Werkzeugkette, mit der Continuous Delivery nicht nur für Cloud-native Anwendungen, sondern auch auf Cloud-nativer Infrastruktur möglich ist. Ganz im Gedanken von „Everything is Code“ betrachten wir dabei nicht nur das Bauen und Testen von Software, sondern auch die Automatisierung der Infrastrukturbereitstellung, der Deployments und Roll-outs. Dabei treffen alte Bekannte (z.B. Jenkins, SonarQube) auf Cloud-Computing-Technologien wie z.B. Docker für Betriebssystemvirtualisierung und DC/OS für das Clustermanagement.

1. Continuous Delivery für Cloud-native Anwendungen auf
Cloud-nativer Infrastruktur
Mainz, 09.05.2017
Josef Fuchshuber (@fuchshuber) & Tobias Placht (@knacht)
QAware GmbH

2. 2
Sorry für den Titel dieser Session: Denn wir sind nicht die
Blah-Blah-Dudes.
Quelle: http://dilbert.com/strip/2011-01-07

3. 3
Josef Fuchshuber
Cheftechnologe
• Architekt & irgendwo zwischen Dev&Ops
• #CloudNativeNerd
Mail: josef.fuchshuber@qaware.de
Twitter: @fuchshuber
Tobias Placht
Software Engineer
• Java-Dev frisch von der Hochschule
• #CommandLineNinja mit Faible für
Sticker
Mail: tobias.placht@qaware.de
Twitter: @knacht

4. 4
#GIFEE
Google‘s
(and Facebook‘s, Twitters‘s, Airbnb‘s, Netfix, …)
Infrastructure
For
Everyone
Else

5. 5
CLOUD NATIVE APPLICATIONS
HYPERSCALE
Traffic, Data, Features
ANTIFRAGILITÄT
CONTINUOUS DELIVERY &
DEVOPS
OPEX SAVINGS
(automation & utilization)
DISRUPTINDUSTRIALIZE

6. 6
BUILD AND COMPOSED
AS MICROSERVICES
PACKAGED AND
DISTRIBUTED AS CONTAINERS
DYNAMICALLY
EXECUTED IN THE CLOUD
3KEYPRINCIPLES
CLOUD NATIVE APPLICATIONS

7. 7
Die Anatomie des Cloud Native Stack
Cluster Virtualization Resources
Cluster Scheduler Containers
Cluster Orchestrator Applications
Application Platform Cloud Native Apps
Cluster Operation System
Verwaltet
Ressourcen für
die Ausführung
von Containers
Stellt Ablauf-
Umgebung und
APIs für Apps
bereit
Führt
Applikationen auf
dem Cluster aus
Entkoppelt von
physischer
Hardware

8. Dev
Build
Test
8
Continuous Delivery: Build und Release Modell
DEV
OPS
Micro-
services
Micro-
services
Release x.y.1
Release x.y.2

9. Mit der DevOps-Brille betrachtet kann alles in einem Punkt
zusammengefasst werden: Die Applikationen werden zu Betriebseinheiten.
9
■ Microservices haben eine eigenständige Release-Einheit.
■ Container sind eine eigenständige Deployment-Einheit.
■ Container werden als isolierte Laufzeiteinheiten ausgeführt.
■ Container sind eine eigenständige Skalierungseinheit.

10. 11
Our solution. And this is just one of many.

11. 12
Die Werkzeugkette: Erfinderwerkstatt und Fließband.
Die Erfinderwerkstatt Das Fließband
Wissensarbeit und Kreativität Integration und Qualitätssicherung
Fertig? Fertig!

12. VCS Continuous Delivery - Cluster Test - Cluster
Docker
Registry
IaaS:
Scheduler
Orchestrator
Dev-1
Dev-2
Staging
Build Push
Analyze
Deploy & Test
Code push
Pull

13. 14
Dynamic Build Nodes

14. Dynamic Build Nodes lösen zwei Probleme:
1. Problem: Statische Partitionierung
15
Master
Java-7-Agent Java-8-Agent Project-A-Agent Project-B-Agent
0
5
10
15
20
25
0
5
10
15
20
25
Master
Ressourcen-Pool
0
5
10
15
20
25

15. 16
Dynamic Build Nodes lösen zwei Probleme:
2. Problem: Pets & Scale-Up
Anti-Pattern:
■ Pflegt eure Jenkins-Nodes nicht wie Haustiere und macht sie nicht zu einem Individuum, bei dem keiner mehr die
Konfiguration kennt: „Also auf genau diesem Server baut die Software“.
■ Erhöht nicht ständig die Ressourcen für einen Build-Node (z.B. bei paralleler Ausführung von Pipelines), sondern verwendet
Ressourcen-Pool und mehr Build-Nodes.
Besser: Ephemeral Build Nodes

16. Mit dem Mesos-Plugin wird DC/OS zur Jenkins-Cloud.
17
■ Dynamic Build Nodes werden vom Jenkins-Master „on-demand“ erzeugt.
■ Die Basis Build-Images der Nodes werden im Jenkins-Master zentral konfiguriert.
■ Build-Jobs können diese Basis-Images referenzieren.
■ Der Jenkins-Master übernimmt das Lifecycle-Management der Dynamic Build Nodes:
■ Startet vor einem Build-Job einen Container des referenzierten Docker-Images. Dabei kommuniziert der Master mit dem
DC/OS Scheduler und Orchestrator. DC/OS Node und Ressourcen werden dabei automatisch zugewiesen.
■ Führt den Build-Job im Docker-Container aus.
■ Sammelt Build-Artefakte zusammen und kopiert sie zurück auf den Master.
■ Stoppt den Dynamic Build Node
■ Parallele Ausführung von Jobs ist durch die Isolierung der Docker-Container kein Problem.
■ Die Grenzen sind nur durch die Verfügbaren Ressourcen des DC/OS Clusters gegeben. Je nach IaaS-Provider
können aber auch weitere Ressourcen hinzugefügt werden.

17. 18
■ Die Basis-Images können über eigene Build-Pipelines gebaut und veröffentlicht werden.
■ Infos zum Bau von eigenen Images: https://docs.mesosphere.com/service-
docs/jenkins/custom-docker/

18. 19
Everything as C<>de

19. Damit diese CD-Umgebung aufgesetzt und mit Leben befüllt
werden kann, brauchen wir an allen Stellen Code aus dem VCS.
20
■ Build-as-Code
■Maven, Gradle, …
■ Test-as-Code
■Unit-, Component-, Integration-, API-, UI-, Performance-Tests
■ Pipeline-as-Code
■Build-Pipeline per Jenkinsfile
■ Infrastructure-as-Code
■Docker, Terraform, Vagrant, Ansible, Marathon-Deployments

20. Beispiel Declarative Pipeline: Jenkinsfile

21. 22
Beispiel: Bootstrapping unserer CD-Umgebung
Infrastructure:
• CoreOS VMs
• DC/OS Nodes (Master, Private, Public)
• NFS
Platform:
• Jenkins
• SonarQube (mit Datenbank)
• NGINX Reverse Proxy
• Artifactory
Services:
• Marathon Event Subscriber
• OpsBot
Terraform
Marathon-
Deployments
Marathon-
Deployments

22. Was macht der Bootstrapping Prozess?
23
<<Infrastructure>>
Bootstrap Node
<<Infrastructure>>
Master
<<Public Node>>
<<Private Node>>
Node1
<<Private Node>>
Node2
<<Private Node>>
Node3
NFS
Marathon-API
(HTTPS)
UIs&APIs
(HTTPS)
OPS
DEV
NGINX Proxy
APP
APP
APP
Jenkins
SonarQube
Artifactory
Event
Subscriber
OpsBot

24. 25
Self service & Blueprints

25. Damit Entwickler schnell arbeitsfähig sind, sind Generatoren
und Blueprints wichtig (1/2).
26
ChatBots sind eine Lösung zur intuitiven
Steuerung von Generatoren.
■ Direkte Integration in HipChat / Slack /
Mattermost
■ Aufträge an den OpsBot werden einfach per
Message gestellt
■ Feedback von CI/CD Ereignissen und
Aufträgen kommen als Antwort zurück

26. Damit Entwickler schnell arbeitsfähig sind, sind Generatoren
und Blueprints wichtig (2/2).
27
Blueprints & Templates:
■ Die Microservice Build-Pipelines in einem
Projekt sind sich sehr ähnlich.
■ Blueprints und Templates geben einen
Rahmen vor und schaffen implizit
Konventionen.
■ Beispiele:
■Durch die Verwendung des Pipeline Multibranch
lugins wird für jeden Branch automatisch eine
eigene Pipeline angelegt.
■Identische Anbindung / Integration von Plattform-
Komponenten (z.B. SonarQube, Artifactory)

28. 29
Advanced & Enterprise Topics
• Diagnosability
• CD für CD
• Deployments

29. Nicht nur unsere Cloud Native Anwendungen müssen
diagnostizierbar sein, sondern auch unsere CD-Umgebung. (1/2)
30
Monitoring mit Prometheus:
■ Prometheus kann für das Monitoring der CD-Plattform sowie für das Monitoring der
Applikationsumgebungen benutzt werden.
■ Prometheus kann Marathon als Service Discovery nutzen.
■ Client Libraries zur Instrumentierung sind für alle wichtigen Programmiersprachen vorhanden.
■ Dashboards können einfach mit Grafana angelegt werden.
■ Alert-Manager kann Störungen per E-Mail, Pager-Duty, HipChat, Slack … melden.

30. Nicht nur unsere Cloud Native Anwendungen müssen
diagnostizierbar sein, sondern auch unsere CD-Umgebung. (2/2)
31
Log-File Auswertung mit ELK/EFK:
■ Elasticsearch als DB und Kibana für Dashboards und Auswertungen
■ Auch hier sollte die Plattform (DC/OS, Jenkins, …) und die Applikationsumgebungen integriert
werden.
■ Für Docker Container, die auf stdout loggen, können Log-Driver (z.B. Fluentd) konfiguriert
werden.
■ Log-Files in den Containern können per Logstash & Filebeat integriert werden.

31. Continuous Delivery für Continuous Delivery
32
■ Auch Änderungen und Erweiterungen der CD Plattform müssen getestet werden.
■ Durch den „Everything-as-Code“ Ansatz ist das aber sehr einfach:
■Komplette Klone der Testumgebung (z.B. für Infrastruktur-Tests) können unter einer Stunde instanziiert
werden.
■Build-Plattform kann für Tests (z.B. bei Jenkins-Update) als weitere Instanz in DC/OS angelegt werden.
Plattform (Prod) Plattform (Test) Plattform (Prod)

32. Wie kommen die Microservices in die Testumgebung? (1/2)
33
■ Das ist projektspezifisch, aber alles was die Zielumgebung (DC/OS) ermöglicht ist erlaubt.
Direkt über Gradle-Tasks

33. Wie kommen die Microservices in die Testumgebung? (2/2)
34
■ Canary-Release mit Vamp (Very Awesome Microservices Platform)
Alte Version
Neue Version
Router
Deployment-Test
Benutzer / Tester
1. Nur der Post-Deployment
Test aus der Pipeline
heraus wird auf die neue
Version geleitet.
2. Erst danach wird die erste
Teilgruppe der Benutzer /
Tester auf umgeleitet.
3. Die alte Version wird offline
genommen

34. 35
Show-Case: Zwitscher Big Picture
Link: https://github.com/qaware/cloud-native-zwitscher

36. 37
Summary

37. Summary
38
■ Automate everything & Everything as Code
■ Ein Vendor Lock-In auf Cloud-Native Plattformen ist möglichst zu vermeiden und auch nicht
nötig.
■ Der initiale Aufwand, im Gegensatz zum „klassischen Weg“, ist höher. Durch einen
projektübergreifenden Einsatz aber auch wieder schnell negiert.
■ Die Fokussierung auf einfache und wenige Schnittstellen für den User haben sich bewährt.

38. 39
IT-Probleme lösen.
Digitale Zukunft gestalten.
Mit Erfindergeist
und Handwerksstolz.
qaware.de/karriere | München | Mainz