LeanIX ist ein Startup aus Bonn, dass eine Software-as-a-Service Lösung anbieter, mit der Unternehmen wie z.B. Zalando, Axel Springer, RWE oder Helvetia Versicherung ihre IT Landschaft dokumentieren. Dank eines modernen Green-Blue Deployments können Releases und Hotfixes im laufenden Betrieb ausgerollt werden, ohne dass die Nutzer des Systems davon beeinträchtigt werden. In diesem Talk beim Bonn Agile Meetup gibt Co-CEO André Einblick in die Konzepte und zugrundeliegenden Technologien wie Docker, Ansible und Jenkins. === LeanIX offers an innovative software-as-a-service solution for Enterprise Architecture Management (EAM), based either in a public cloud or the client’s data center. Companies like Adidas, Axel Springer, Helvetia, RWE, Trusted Shops and Zalando use LeanIX Enterprise Architecture Management tool. Free Trial: http://bit.ly/LeanIXFreeTrial

1. Green-Blue
Deployment mit
Docker, Ansible &
Jenkins
André Christ,
Bonn Agile Meetup

2. Agenda
2
Warum Continuous Deployment?
Was macht unsere Dev-Ops Architektur aus?
Wie geht es in der Praxis?

3. Start-up Mentality:
Build Minimal Viable Products (“MVP”)
3

4. Vom MVP zum reifen Produkt
4Quelle: In Anlehnung an: @benorama

5. Elastic
Alle neu entwickelten Funktionen folgen
unserer Microservices Architektur
5
View
Controller
Model
DB
Single Page App
REST-API
DB
REST-API
Frontend
Service
Backend
Microservices
Infrastruktur
Services

6. Elastic
Green-Blue Deployment ist zentraler
Erfolgfaktor unserer Architektur
6
Single Page App
REST-API
DB
REST-API
1
3
2 2
1
2
4
3
2
3
5
Komfortable Anmeldung an allen Services via
Unternehmensverzeichnis (AD, LDAP, etc.)
Sichere Kommunikation mit APIs –
von Browser und zwischen Services.
Einfache Nutzung der APIs durch interaktive
Dokumentation und generierte SDKs.
OAuth2/JWT
SSO (SAML)
Swagger
Docker
Green-Blue
Deployment
Konsistente Paketierung und Plattform-
unabhängige Auslieferung aller Services.
Kontinuierliches Deployment und
Minimierung von Maintenance-Zeiten.
Alle: 4 5
x Details folgen

7. Agenda
7
Warum Continuous Deployment?
Was macht unsere Dev-Ops Architektur aus?
Wie geht es in der Praxis?

8. Kontinuierliches Deployment und
Minimierung von Maintenance-Zeiten
8
5
Load-Balancer (default = blue)
eam
1.18
mtm
1.0
Export
0.8
DB, Index, Queue DB, Elastic
Vorteile Green-Blue
• „Unterbrechungsfreies“
Deployment
• Test neuer Versionen in
Produktionsumgebung
• Schrittweiser Rollout
• Schnelles Rollback zu
alter Version
Herausforderungen
• Migration von Daten-
Containern (DB)
• Session-Handling
(Re-Login notwendig)

9. Kontinuierliches Deployment und
Minimierung von Maintenance-Zeiten
9
5
Load-Balancer (default = blue)
eam
1.18
eam
1.19
mtm
1.0
mtm
1.1
Export
0.8
export
0.9
DB, Index, Queue DB, Elastic
Test
Vorteile Green-Blue
• „Unterbrechungsfreies“
Deployment
• Test neuer Versionen in
Produktionsumgebung
• Schrittweiser Rollout
• Schnelles Rollback zu
alter Version
Herausforderungen
• Migration von Daten-
Containern (DB)
• Session-Handling
(Re-Login notwendig)

10. Kontinuierliches Deployment und
Minimierung von Maintenance-Zeiten
10
5
Load-Balancer (default = blue)
eam
1.18
eam
1.19
mtm
1.0
mtm
1.1
Export
0.8
export
0.9
DB, Index, Queue DB, Elastic
Vorteile Green-Blue
• „Unterbrechungsfreies“
Deployment
• Test neuer Versionen in
Produktionsumgebung
• Schrittweiser Rollout
• Schnelles Rollback zu
alter Version
Herausforderungen
• Migration von Daten-
Containern (DB)
• Session-Handling
(Re-Login notwendig)

11. Umsetzung mit drei zentralen Tools
11
“Build, ship, and run
distributed applications”
“Building/testing software
projects continuously”
“IT automation engine that
automates application
deployment, configuration
management, ….”

12. Production
Servers US
Production
Servers US
Develop, Build, Test, Deploy-Toolchain
12
Develop Build Test Deploy
Staging
Server
Production
Servers Europe
Developer
Machines
Docker Hub
GitHub Jenkins Ansible

13. Agenda
13
Warum Continuous Deployment?
Was macht unsere Dev-Ops Architektur aus?
Wie geht es in der Praxis?

14. Beispiel: LeanIX Website
14
leanix-website leanix-website
postfix redis
nginx
etcdconfd
Load-Balancer
Container
Ressources
Key-Value Store
User Request

15. Laufende Container
15
$ docker ps

16. 16
LIVE DEMO

17. Some numbers
17
20 days
3 hours
< 30 min
Effort for setup, learning and trouble shooting for
Ansible & Jenkins
Ramp-Up of a new employee untilfirst commit
Time untila fresh Server is setup with all required
services
14 days For changing our Vagrant based environmentto docker
& docker-compose

18. Issues
18
• Don’t underestimate orchestration effort (“New Monolith”)
• Green / Blue Marker in derived containers
• Docker Hub (Registry) often very slow in the afternoon
• Docker Version Updates can be very risky (Kernel Issue with 1.9.1
with AUFS Filesystem, required to downgrade kernel)
• Manual cleanup needed for unused containers and images
• Large images require bandwidth when pulled
• “Trusted” images – extra check which base images can be used

19. Reading
19
https://blog.codecentric.de/2015
/08/case-study-microservices-
bei-leanix/
https://github.com/leanix

20. Backup
20

21. Komfortable Anmeldung an allen Services
via Unternehmensverzeichnis
21
1
A IDM-as-a-ServiceBInterner IDM1
Vorteile SSO (SAML)
• SAML Identity Provider
mittlerweile gut verbreitet
in Unternehmen
• Ein standardisierter Weg:
sowohl intern als auch
extern alles via SAML
Herausforderungen
• Komplexität Shibboleth
und SAML-Spezifikation
• Löst nicht maschinen-
basiertes Login („ECP-
Workflow“)
ACTIVE DIRECTORY
FEDERATION SERVICES (ADFS)
C Kunden IDM
svc.leanix.net/idp
1) IDM = Identity Management

22. Sichere Kommunikation mit APIs –
von Browser und zwischen Services
22
2
Vorteile oAuth2 & JWT
• Sicherheitsgewinn durch
delegierte
Authentifizierung
• Weniger Abhängigkeiten:
Permissions im Payload
• Gleicher Mechanismus
auch zwischen Services
• Signierte Tokens lassen sich
dezentral verifizieren
Herausforderungen
• Verknüpfung mit SAML
nicht standardisiert
oAuth2
Resource Server
export images …
Token (JWT):
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ
hbmRyZS5jaH …
Expires_in: 3400
Backend
Microservices
Private Key
Public Key
Dezentrale Token
Verifizierung
JWT: Json Web Tokens

23. Json Web Tokens (JWT) ist ein Standard
für das Format von Tokens
23Debugger: https://jwt.io IETF Standard: https://tools.ietf.org/html/rfc7519
2

24. 24
2 JWT bringt Vorteile insb. bei Skalierung
im Vergleich zum “puren” oAuth2
oAuth2
Resource Server
export images …
Token: 31886e3b-dd8f-4b13-
9434-…
Expires_in: 3400
Verify Token, Get Payload (Permissions)
Backend
Microservices
oAuth2
Resource
Server
export images …
Token (JWT):
eyJhbGciOiJSUzI1NiJ9.eyJzdWI
iOiJhbmRyZS5jaH …
Expires_in: 3400
Backend
Microservices
Private Key
Public Key
A) oAuth2 “pur”: Tokens müssen gegen
Resource Server verifiziert werden
B) oAuth2 mit “JWT”: Tokens können
dezentral verifiziert werden mit Public Key

25. Einfache Nutzung der API durch
interaktive Doku und generierte SDKs
25
3
Vorteile Swagger
• Interaktive REST-API Doku:
Operationen direkt im
Browser ausführbar
• Immer aktuell, da
generiert aus Quellcode
• Automatische Erzeugung
von SDK’s (z.B. Java, PHP,
C#)
à Mehr unter:
blog.leanix.net

26. Konsistente Paketierung und
plattformunabhängige Auslieferung
26
Server
Host OS
Hypervisor
Guest OS
Libs
App A
Guest OS
Libs
App B
Virtualisation Vorteile Docker
• Schnelleres
Deployment
• Weniger Ressourcen-
Verbrauch
• Container passen sehr
gut zur Struktur von
Microservices
• Cloud & On-Premise
Herausforderungen
• Maturität von Tools
& Ökosystem
• Linux Kernel benötigt
(Workarounds z.B. für
Windows & Mac)
VM VM
Server
Host OS
Docker Engine
eam mysql
Libs
Docker
Container Container
solr
Container
Libs
4

27. Kontinuierliches Deployment und
Minimierung von Maintenance-Zeiten
27
5
Load-Balancer (default = blue)
eam
1.18
eam
1.19
mtm
1.0
mtm
1.1
Export
0.8
export
0.9
DB, Index, Queue DB, Elastic
Test
Vorteile Green-Blue
• „Unterbrechungsfreies“
Deployment
• Test neuer Versionen in
Produktionsumgebung
• Schrittweiser Rollout
• Schnelles Rollback zu
alter Version
Herausforderungen
• Migration von Daten-
Containern (DB)
• Session-Handling
(Re-Login notwendig)

28. Ansible Example: Provision servers
28
# Provisions the frontend servers
---
- hosts: frontend
sudo: true
roles:
- {role: 'init'}
- {role: 'docker'}
- {role: 'updates'}
provision_server.yml
$ ansible_playbook provision_server.yml –I hosts/prod -v
hosts/prod
[frontend]
srv-de-web-1.leanix.net
srv-de-web-2.leanix.net
srv-us-web-1.leanix.net
srv-us-web-2.leanix.net
[backend]
srv-de-app-1.leanix.net
srv-de-app-2.leanix.net
srv-us-app-1.leanix.net
srv-us-app-2.leanix.net

29. Ansible Example: Configure system
29
[…]
- name: Install System Packages
apt: pkg={{ item }} state=latest
with_items: ["curl", "wget", "python-software-properties", "software-properties-
common", "daemon", "supervisor"]
- name: German kb
command: loadkeys de
changed_when: false
- name: Set hostname on boot to short name from inventory list
template: src=hostname.j2 dest=/etc/hostname owner=root group=root mode=0644
register: hostname_file
[…]
roles/init/tasks/main.yml

30. Ansible Example: Deploy service
30
[…]
- name: Start leanix synclog Docker container
shell: docker run -d
--name {{ item.1.name }}
-p {{ ansible_eth1.ipv4.address }}:{{ item.1.synclog_port }}:{{SERVICE_PORT }}
-e SERVICE=synclog
-e PROXY_SERVICE={{ PROXY_SERVICE }}
-e SWAGGER_BASEPATH={{ SWAGGER_BASEPATH }}
leanix/leanix-synclog
with_indexed_items: SYNCLOG_SERVICES
when: synclog_running.results[{{ item.0 }}].rc != 0
[…]
roles/init/tasks/main.yml

31. Monitoring
31ELK = Elastic Logstash Kibana
Availability
Performance
Logfiles
Service Description
• Every micro service has a health-check URL
• Availability Check & Response Time
• Server Metrics: CPU, Memory, etc.
• Docker Metrics per Container: CPU, Mem, …
• Browser Metrics: Page Load, JS Errors
• Central storage for log files
• Similar for ELK-Stack, but as a Service
Alerting
• Single point for all alerts
• Informs operations managers on duty
Dashboard
• Dashboard which shows main KPIs
• Running on Screens in LeanIX Office

32. Geckoboard Dashboard
32Source: Geckoboard