Continuous deployment in LeanIX @ Bonn Agile

3.653 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.653
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
24
Aktionen
Geteilt
0
Downloads
12
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Continuous deployment in LeanIX @ Bonn Agile

  1. 1. Green-Blue Deployment mit Docker, Ansible & Jenkins André Christ, Bonn Agile Meetup
  2. 2. Agenda 2 Warum Continuous Deployment? Was macht unsere Dev-Ops Architektur aus? Wie geht es in der Praxis?
  3. 3. Start-up Mentality: Build Minimal Viable Products (“MVP”) 3
  4. 4. Vom MVP zum reifen Produkt 4Quelle: In Anlehnung an: @benorama
  5. 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. 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. 7. Agenda 7 Warum Continuous Deployment? Was macht unsere Dev-Ops Architektur aus? Wie geht es in der Praxis?
  8. 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. 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. 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. 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. 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. 13. Agenda 13 Warum Continuous Deployment? Was macht unsere Dev-Ops Architektur aus? Wie geht es in der Praxis?
  14. 14. Beispiel: LeanIX Website 14 leanix-website leanix-website postfix redis nginx etcdconfd Load-Balancer Container Ressources Key-Value Store User Request
  15. 15. Laufende Container 15 $ docker ps
  16. 16. 16 LIVE DEMO
  17. 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. 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. 19. Reading 19 https://blog.codecentric.de/2015 /08/case-study-microservices- bei-leanix/ https://github.com/leanix
  20. 20. Backup 20
  21. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 32. Geckoboard Dashboard 32Source: Geckoboard

×