Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CLOUDINFRA Unterlagen

CLOUDINFRA Unterlagen

WPS – Workplace Solutions

September 17, 2020
Tweet

More Decks by WPS – Workplace Solutions

Other Decks in Technology

Transcript

  1. 24.11.2020 //// Seite 3 WPS - Workplace Solutions GmbH Die

    WPS GmbH und Ihre Expertise Rund um Architekturanalyse ▪ Architektur-Review und Qualitätsgutachten ▪ Architektur- und Refactoring-Beratung ▪ Architekturstile - Einführung und Entwicklung Rund um IT-Landschaften ▪ Analyse der Ist/Soll-Geschäftsprozesse mit Fachanwendern ▪ Darstellung von komplexen IT- Landschaften ▪ Qualitäts- und Testmanagement Software- Architektur Anforderungs- ermittlung Leitstand und Interaktion Individual- software Business-Software, die Spaß macht!
  2. 24.11.2020 //// Seite 4 WPS - Workplace Solutions GmbH DIE

    TRAINER [email protected] @clemologe Clemens Heppner [email protected] @jbumueller Johannes Bumüller Richard Voß [email protected] @richard_voss [email protected] Christopher Berg [email protected] Malte Jörgens [email protected] @flauflauf Florian von Stosch Adrian Metzner [email protected]
  3. 24.11.2020 //// Seite 9 WPS - Workplace Solutions GmbH INHALT

    1. Einleitung 2. Grundlagen moderner Infrastrukturen 3. Gängige Architekturkonzepte 4. Cloud Native Journey 5. Hilfreiche Muster (Pattern) 6. Development, CI/CD und Betrieb 7. Automatisierung 8. Anhang ▪ Fallstudie Hotel
  4. 24.11.2020 //// Seite 2 WPS – Workplace Solutions International Software

    Architecture Qualification Board e.V. Vereinsziele: ▪ Erstellung und Pflege einheitlicher Lehr- und Ausbildungspläne für Softwarearchitekten (Certified Professional for Software Architecture) ▪ Definition von Zertifizierungsprüfungen auf Basis der CPSA-Lehrpläne ▪ Sicherstellung der fachlich-inhaltlichen Qualität von Lehre, Aus- und Weiterbildung für Softwarearchitektur iSAQB?
  5. 24.11.2020 //// Seite 3 WPS – Workplace Solutions iSAQB-Zertifizierungsstufen Foundation

    Level Aufgaben, Methoden und Techniken für die Entwicklung von Softwarearchitekturen. Alle Aspekte, die für Softwarearchitektur wesentlich sind. Technologische, organisatorische und soziale Faktoren. Advanced Level Vertiefung des Foundation Levels. Der Lehrplan besteht aus einzelnen Modulen, die bestimmte Schwerpunkte haben. Expert Level In Planung
  6. 24.11.2020 //// Seite 4 WPS – Workplace Solutions Kompetenzbereiche Advanced

    Level ▪ Methodische Kompetenz: Systematisches Vorgehen bei Architekturaufgaben, unabhängig von Technologien. ▪ Technische Kompetenz: Kenntnis und Anwendung von Technologien zur Lösung von Entwurfsaufgaben. ▪ Kommunikative Kompetenz: Fähigkeiten zur produktiven Zusammenarbeit mit unterschiedlichen Stakeholdern, Kommunikation, Präsentation, Argumentation, Moderation. →Alle drei Kompetenzbereiche müssen abgedeckt sein (mindestens 10 Credit Points pro Kompetenzbereich) →Insgesamt sind 70 Credit Points erforderlich →10 Credit Points entsprechen in der Regel einem Schulungstag →Eine Schulung zu einem Lehrplanmodul bringt maximal 30 Credit Points, auch wenn sie länger als 3 Tage ist →Es ist möglich sich bestimmte andere Zertifikate anerkennen zu lassen
  7. 24.11.2020 //// Seite 5 WPS – Workplace Solutions Püfung iSAQB

    Advanced Level Prüfung und Zertifizierung Wenn Sie als CPSA-A geprüft werden möchten, müssen Sie sich bei einer der anerkannten Zertifizierungsstellen anmelden. Die Zertifizierungsstelle schickt Ihnen in Absprache eine Prüfungsaufgabe zu, die Sie in etwa 40 Arbeitsstunden lösen und deren Lösung Sie dokumentieren müssen. Sie schicken die Lösung an die Zertifizierungsstelle ein. Die Zertifizierungsstelle bestellt zwei unabhängige Prüfer und übergibt ihnen Ihre Lösung, so dass sie begutachtet werden kann. Die Prüfer telefonieren anschließend noch mit Ihnen als Teilnehmer. Sie müssen Ihre Lösung in diesem Gespräch erklären und verteidigen. Wenn die Prüfer bestätigen, dass Sie alle Voraussetzungen für den CPSA-A erfüllen, dass Ihre Lösung gut ist und dass Sie die Lösung gut dokumentiert, erklärt und verteidigt haben, stellt Ihnen die Zertifizierungsstelle das CPSA-A Zertifikat aus.
  8. 24.11.2020 //// Seite 6 WPS – Workplace Solutions MODUL AGILA

    (10 komm. CP, 20 method. CP) Softwaresysteme und -architekturen nach agilen Prinzipien entwerfen und weiterentwickeln ▪ Agile Prinzipien und Ideen auf Architekturarbeit übertragen ▪ Architekturpraktiken sinnvoll in agiles Vorgehen verankern ▪ Arbeiten in selbstorganisierte Teams und gemeinsam wahrgenommene Verantwortung erfordern neue Fähigkeiten, sowohl technischer als auch methodischer und kommunikativer Art. Diese werden theoretisch und praktisch behandelt. Schulungsangebot: https://www.wps.de/schulung/isaqb-agila
  9. 24.11.2020 //// Seite 7 WPS – Workplace Solutions MODUL IMPROVE

    (20 method. CP, 10 techn. CP) Softwarearchitekturen anhand ökonomischer und technischer Ziele systematisch verbessern ▪ Grundlagen von Evolution und Verbesserung von Softwarearchitekturen ▪ Ist-Situation analysieren ▪ Probleme und Lösungsansätze schätzen und bewerten ▪ Verbesserung langfristig planen ▪ Typische Ansätze und Beispiele für Verbesserung Schulungsangebot: https://www.wps.de/schulung/isaqb-improve/
  10. 24.11.2020 //// Seite 8 WPS – Workplace Solutions MODUL Domain-Driven

    Design (10 komm. CP, 20 method. CP) Passgenaue Softwarearchitekturen durch Kommunikation mit den Fachexperten und einheitliche Konstruktionsbausteine entwickeln ▪ Eine gemeinsame Sprache erleichtert die Zusammenarbeit ▪ Software nach fachlichen Gesichtspunkten strukturieren ▪ Kommunikation ist der Schlüssel – miteinander und zwischen Teams ▪ Bausteine von DDD geben team- übergreifende Anleitungen für die Konstruktion Schulungsangebot: https://www.wps.de/schulung/isaqb-ddd/
  11. 24.11.2020 //// Seite 9 WPS – Workplace Solutions MODUL FLEX

    (10 method. CP, 20 techn. CP) Flexible Architekturkonzepte und Methoden, um Software schnell und mit hoher Qualität in die Produktion zu bringen: ▪ Microservices entwerfen ▪ DevOps und Continuous Delivery umsetzen ▪ Containerisierung ▪ Resiliente Systeme betreiben Schulungsangebot: ▪ https://www.wps.de/schulung/isaqb-flex/
  12. 24.11.2020 //// Seite 10 WPS – Workplace Solutions MODUL CLOUDINFRA

    (10 method. CP, 20 techn. CP) Architekturkonzepte und Methoden, um Software in der Cloud sicher und flexibel zu betreiben und das Skalierungspotential auszuschöpfen: ▪ Microservices verstehen ▪ Cloudangebote und deren Anwendung ▪ Containerisierung und Container-Manager einsetzen ▪ Resiliente Systeme betreiben Schulungsangebot: ▪ https://www.wps.de/schulung/isaqb-cloudinfra/
  13. 24.11.2020 //// Seite 11 WPS – Workplace Solutions Weitere Module

    Credit Points ADOK Architektur-Dokumentation: Wie dokumentiert und kommuniziert man Softwarearchitekturen? 20 method. ARCEVAL Architektur-Bewertung: Wie findet man heraus, ob eine Architektur die Erwartungen erfüllt? 20 method. EAM Enterprise Architecture Management: Wie kann man eine große Landschaft von IT-Systemen konsistent halten? 30 method. EMBEDDED Embedded Systems: Wie entwirft man eingebettete Systeme, die direkten Einfluss auf ihre Umgebung nehmen? 10 method. 20 tech. SOA-T Serviceorientierte Architekturen: Wie entwirft man eine SOA? 10 method. 20 tech. SOFT Softskills für Software-Architekten: Wie führt man Gespräche zur Architekturfindung und präsentiert Architektur verständlich? 30 komm. WEB Web-Architekturen: Wie gestaltet man leistungsfähige und sichere webbasierte Systeme? 30 techn.
  14. 24.11.2020 //// Seite 12 WPS – Workplace Solutions Aufbau Grundlagen

    moderner Infrastrukturen Gängige Architekturkonzepte Cloud Native Journey Hilfreiche Muster Development, CI/CD und Betrieb Automatisierung Case Study Case Study Case Study Case Study Live Demo Terraform + AWS Case Study Live Demo AWS Live Demo + Hands-On Docker Case Study
  15. 24.11.2020 //// Seite 15 WPS – Workplace Solutions Verteilung nach

    Lehrplan Grundlagen moderner Infrastrukturen 2:00 Gängige Architekturkonze pte 2:00 Cloud Native Journey 4:00 Hilfreiche Muster 4:00 Development, CI/CD und Betrieb 4:00 Automatisierung 2:00 Case Study 2:00 ZEIT
  16. 24.11.2020 //// Seite 29 WPS – Workplace Solutions Zeitplan Remote-Schulung

    - Tag 1 Zeit Inhalt 09:00-10:00 Einführung und Überblick Grundlagen moderner Infrastrukturen Grundlagen Cloud Computing 10:00-10:15 Pause 10:15-11:15 Grundlagen moderner Infrastrukturen Grundlagen Cloud Computing 11:15-11:30 Pause 11:30-12:30 Grundlagen moderner Infrastrukturen Cloud computing & Container Manager Gängige Architekturkonzepte Microservices konkret 12:30-13:15 Mittagspause
  17. 24.11.2020 //// Seite 30 WPS – Workplace Solutions Zeitplan Remote-Schulung

    - Tag 1 Zeit Inhalt 13:15-14:15 Gängige Architekturkonzepte Microservices & Integrationsstile 14:15-14:30 Pause 14:30-15:30 Gängige Architekturkonzepte Microservices & Integrationsstile 15:30-15:45 Pause 15:45-17:00 Cloud Native Journey Grundlegendes zu Cloud Native
  18. 24.11.2020 //// Seite 31 WPS – Workplace Solutions Zeitplan Remote-Schulung

    - Tag 2 Zeit Inhalt 09:00-10:00 Cloud Native Journey Grundlagen Container & Container-Manager 10:00-10:15 Pause 10:15-11:15 Cloud Native Journey Container-Manager 11:15-11:30 Pause 11:30-12:30 Cloud Native Journey Container-Manager 12:30-13:15 Mittagspause
  19. 24.11.2020 //// Seite 32 WPS – Workplace Solutions Zeitplan Remote-Schulung

    - Tag 2 Zeit Inhalt 13:15-14:15 Hilfreiche Patterns Resilience-Muster 14:15-14:30 Pause 14:30-15:30 Hilfreiche Patterns Container Patterns 15:30-15:45 Pause 15:45-17:00 Hilfreiche Patterns Container Patterns
  20. 24.11.2020 //// Seite 33 WPS – Workplace Solutions Zeitplan Remote-Schulung

    - Tag 3 Zeit Inhalt 09:00-10:00 Development, CI/CD und Betrieb Grundlagen Deployment & Deployment-Strategien 10:00-10:15 Pause 10:15-11:15 Development, CI/CD und Betrieb Grundlagen Deployment & Deployment-Strategien 11:15-11:30 Pause 11:30-12:30 Development, CI/CD und Betrieb Monitoring, Logging und Alerting 12:30-13:15 Mittagspause
  21. 24.11.2020 //// Seite 34 WPS – Workplace Solutions Zeitplan Remote-Schulung

    - Tag 3 Zeit Inhalt 13:15-14:15 Development, CI/CD und Betrieb Monitoring, Logging und Alerting Automatisierung Infastrukturautomatisierung, insbes. Terraform 14:15-14:30 Pause 14:30-15:30 Automatisierung Container-Management-Plattformen 15:30-15:45 Kaffeepause 15:45-17:00 Automatisierung Container-Management-Plattformen
  22. 24.11.2020 //// Seite 38 WPS – Workplace Solutions Was ihr

    erwarten könnt ▪ Wissen aus der Literatur ▪ Erfahrungen aus der Praxis ▪ Meinungen ▪ Tipps und Tricks ▪ Abwechslung von ▪ Vorträgen ▪ Demos ▪ Übungen ▪ Ein Zertifikat
  23. 24.11.2020 //// Seite 39 WPS – Workplace Solutions Was wir

    von euch erhoffen ▪ Lust auf Neues ▪ Diskussion ▪ War Stories ▪ Fragen
  24. 24.11.2020 //// Seite 3 WPS – Workplace Solutions Warum überhaupt

    Cloud? Moderne Applikationen sollen hochverfügbar sein • Verteilung von Last auf eine skalierbare Anzahl von Instanzen eines Services • Verteilung von einem Rechenzentrum als Single-Point-of-Failure (Stromausfall, Störung) auf mehrere, ohne dass dies für Klienten spürbar ist • Potentiell physisch näher am Endkunden (durch geografisch verteilte Serverlokalität) Verlagerung von Kompetenzen und Verantwortung an den Cloud-Anbieter • Bereitstellung von Infrastruktur • Ausfallsicherheit • Verfügbarkeit • Datensicherheit • IT-Sicherheit Einfache Automatisierung durch Infrastructure as Code
  25. 24.11.2020 //// Seite 4 WPS – Workplace Solutions Cloud-Charakteristika (NIST)

    ▪ Selbstbedienung nach Bedarf ▪ Erreichbar per Internet ▪ Ressourcen-Pool für mehrere Kunden ▪ Hohe Elastizität ▪ Service wird gemessen / überwacht
  26. 24.11.2020 //// Seite 5 WPS – Workplace Solutions Cloud -

    Public vs. Private ▪ Anforderungen an beide ▪ Vollständige Virtualisierung und Containerisierung ▪ Dynamisches Hinzunehmen und Entfernen von Rechenleistung ▪ Anforderungen an die Public Cloud ▪ Vollständiges Outsourcing der Hardware ▪ Fremde Rechen- und Speicherleistungen werden auf Bedarf eingekauft ▪ Anforderungen an die Private Cloud ▪ Betrieb eigener Hardware
  27. 24.11.2020 //// Seite 6 WPS – Workplace Solutions Cloud Vor-

    und Nachteile ▪ Gemeinsamkeiten ▪ Infrastruktur auf Abfrage ▪ Skalierbarkeit ▪ Vorteile Public Cloud ▪ Abgabe von Aufwand und Verantwortung => Reduktion der Fertigungstiefe ▪ Große Menge höherwertiger Dienste ▪ Einfache Automatisierbarkeit ▪ Hoher Reifegrad ▪ Größere Skalierbarkeit als bei Private Cloud ▪ Nachteile Public Cloud ▪ Erfordert aufwändigeren Umgang mit sensiblen Daten, weil der Cloud-Anbieter Zugriff darauf hat ▪ (meist) im Internet => höhere Sicherheitsanforderungen
  28. 24.11.2020 //// Seite 7 WPS – Workplace Solutions Cloud Service-Typen

    ▪ Software as a Service (SaaS) ▪ E-Mail, virtueller Desktop, Spiele, … ▪ Kunde hat eine Software zur Verfügung, die in einer Cloud läuft ▪ Function as a Service (Serverless) ▪ AWS Lambda, Google Cloud Function ▪ Man definiert nur Funktionscode, komplette Infrastruktur wird abstrahiert ▪ Platform as a Service (PaaS) ▪ Webserver, Datenbanken, Entwicklungsumgebungen, … ▪ Kunde kann Software auf der Cloud-Infrastruktur installieren ▪ Hoher Standardisierungs-Grad! ▪ Infrastructure as a Service (IaaS) ▪ Virtuelle Maschinen, Storage, Load Balancer, … ▪ Kunde kann Betriebssysteme, Datenspeicher und Netzwerke verwalten ▪ Zugrundeliegende Infrastruktur bleibt in der Verantwortung des Anbieters
  29. 24.11.2020 //// Seite 8 WPS – Workplace Solutions Managed Services

    oder Rechenressourcen? ▪ Abwägungsfrage: ▪ Managed Datenbank vom Cloudanbieter ▪ Oder eine reine VM/VMs auf denen die Datenbank selbst betrieben wird ▪ Häufig abzuwägen: ▪ Schneller Start vs. steile Lernkurve ▪ Für die Masse gute Leistung vs. auf individuellen Bedarf zugeschnittene Leistung ▪ Standardisierung vs. Flexibilität Standardisierung Flexibilität hoch niedrig niedrig hoch IaaS PaaS SaaS FaaS
  30. 24.11.2020 //// Seite 10 WPS – Workplace Solutions Einordnung IaaS

    Application Data Runtime Middleware OS Virtualization Servers Storage Network PaaS Application Data Runtime Middleware OS Virtualization Servers Storage Network Serverless (FaaS) Application Data Runtime Middleware OS Virtualization Servers Storage Network SaaS Application Data Runtime Middleware OS Virtualization Servers Storage Network
  31. 24.11.2020 //// Seite 13 WPS – Workplace Solutions Kosten ▪

    Man zahlt für: Rechenleistung, Speicher, Netzwerkverkehr ▪ Kosten skalieren mit den Ressourcen und teilweise mit dem Verbrauch ▪ Gestoppte Instanzen kosten nichts ▪ Preise können höher als bei traditionellen Hostern sein, genau prüfen! ▪ Aber! Man zahlt auch für Instanzen die laufen, aber nichts tun.
  32. 24.11.2020 //// Seite 14 WPS – Workplace Solutions Ressourcen-Management ▪

    Hochfahren: ▪ Manuell nach Erfahrung ▪ Automatisch nach Auslastung ▪ Automatisch nach SLAs (eine Maschine pro X Besucher) ▪ Herunterfahren ▪ Bei geringer Last ▪ Erst nach Abkühl-Phase ▪ Klienten dürfen sich die Instanz nicht lange merken
  33. 24.11.2020 //// Seite 15 WPS – Workplace Solutions Muss es

    denn Cloud sein? ▪ Ja wenn, ▪ Ressourcen kurzfristig abgerufen werden sollen ▪ Ressourcen auch mal abgeschaltet werden sollen ▪ Ein hoher Grad an Automatisierung gewünscht ist ▪ Man nicht den Keller voller aktuellem Blech hat ▪ Die Governance/Compliance es zulässt ▪ Nein wenn, ▪ Es von Compliance-Gesichtspunkten nicht möglich ist ▪ Man ein eigenes Rechenzentrum mit entsprechendem Personal besitzt => dann eventuell Aufbau einer Private-Cloud mit Openshift ▪ Es keine besonderen Skalierungsanforderungen gibt ▪ Der Ressourcenbedarf relativ stabil ist
  34. 24.11.2020 //// Seite 16 WPS – Workplace Solutions Leitbild: Pet

    vs Cattle „Server sind wie Haustiere“ Sie bekommen einen Namen, sind einmalig, werden liebevoll aufgezogen und versorgt. Wenn sie krank sind, werden sie gesund gepflegt. „Server sind wie Vieh“ Vieh bekommt Nummern und ist kaum unterscheidbar. Wenn es krank wird, holt man sich neues. Scale Out Scale Up CC-By-Nd “Sick dog large”, Yoel Ben-Avraham
  35. 24.11.2020 //// Seite 17 WPS – Workplace Solutions Pet-Server werden

    auch Snowflakes genannt ▪ Zwei Pet-Server werden aufgesetzt (gleiches Betriebssystem gleiches Patch-Level) ▪ Über die Zeit werden die Server sich auseinanderentwickeln ▪ Auf dem einen wird ein Patch eingespielt auf dem anderen nicht ▪ Administratoren greifen manuell auf die Server zu und tun Dinge auf dem einen, aber nicht auf dem anderen Server ▪ So entwickeln die Server sich immer weiter auseinander, man spricht auch von Configuration Drift Susi Hektor Zeit Security Patch kommt Server ist offline Server wieder online Ein Admin tweakt das OS von Susi Irgendwie ist der Server langsam
  36. 24.11.2020 //// Seite 19 WPS – Workplace Solutions Was ist

    Serverless? ▪ Wie so oft: Es gibt keine einheitliche Definition ▪ „Run code, not Server“ ▪ Entwickler sollen sich nur noch um die Entwicklung fachlicher Bausteine kümmern, nicht um technische Infrastruktur ▪ FaaS = Function as a service ▪ Kosten/Funktionsaufruf => Kosten skalieren ▪ Eventgesteuert ▪ Es gib keine laufenden Serverprozesse. Stattdessen gibt es einen Funktionsaufruf sobald ein Trigger-Event ausgelöst wurde, zum Beispiel ein HTTP-Aufruf
  37. 24.11.2020 //// Seite 23 WPS – Workplace Solutions ▪ AWS

    Lambda ▪ Google Cloud Functions ▪ Azure Functions ▪ IBM Cloud Functions ▪ Oracle Cloud Fn ▪ Webtask.io ▪ Hook.io €€€ Serverless Angebote
  38. 24.11.2020 //// Seite 24 WPS – Workplace Solutions Wann welche

    Art von Cloud-Anbieter nutzen? Bare Metal für Legacy-Anwendungen, die nicht virtualisiert funktionieren Notlösung beim Umgang mit sensiblen Daten, wenn noch keine Cloud-gemäßen Sicherheitsmaßnahmen (z.B. Encryption at Rest und TLS) umgesetzt sind ggf. bei gesetzlichen Vorgaben IaaS wenn minimale Bindung an Cloud-Anbieter gewünscht wenn noch wenig Cloud-Erfahrung vorhanden, denn die meisten Konzepte sind bekannt (SSH, IPs, Betriebssysteme, etc.) Betrieb von Open-Source-Software ohne verfügbare gemanagte Lösungen PaaS wenn man Aufwände im Betrieb im Vergleich zu IaaS einsparen möchte, z.B. das Erstellen regelmäßige DB-Backups für einen hohen Reifegrad durch Outsourcing der komplexen Aufgaben an den Cloud-Anbieter für Datenbanken für Container-Manager Serverless wenn Skalierung und Kosteneffizienz wichtig sind wenn die Code-Menge überschaubar ist für langfristige / komplexe Operationen ("Batch-Jobs"), z.B. Machine-Learning-Inferenz für schnelles Prototyping ohne Aufsetzen von jeglicher Infrastruktur SaaS wenn die Funktionalität nicht spezifisch für die eigene Organisation ist (kein eigener Code) Beispiele: CRM, Mail, SCM
  39. 24.11.2020 //// Seite 26 WPS – Workplace Solutions AWS-Services und

    minimales Setup mit EC2 Bildquelle: https://cloudit4you.wordpress.com/2015/06/30/aws-cloud-architecture-overview/
  40. 24.11.2020 //// Seite 27 WPS – Workplace Solutions Beispiele für

    AWS Services ▪ IaaS ▪ EC2: VMs ▪ VPC: Netzwerke ▪ Route53: DNS ▪ PaaS ▪ S3: Dateispeicher ▪ IAM: Identity Access Management (User, Rollen, etc.) ▪ RDS, DynamoDB: Gemanagte Datenbanken ▪ CloudWatch, CloudTrail: Monitoring ▪ ECR, EKS, ECS, Fargate: Docker PaaS ▪ FaaS ▪ Lambda
  41. 24.11.2020 //// Seite 29 WPS – Workplace Solutions Shared Security

    Responsibility Model https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf
  42. 24.11.2020 //// Seite 30 WPS – Workplace Solutions ... für

    „Container Services“ (RDS, EMR, Beanstalk) https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf
  43. 24.11.2020 //// Seite 31 WPS – Workplace Solutions ...und „Abstracted

    Services“ (S3, DynamoDB, SQS) https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf
  44. 24.11.2020 //// Seite 32 WPS – Workplace Solutions Globale Infrastruktur

    (AWS) (März 2020) ▪ 22 Regionen (+5) ▪ 69 Availability Zones ▪ Unsere Region: eu-central-1
  45. 24.11.2020 //// Seite 33 WPS – Workplace Solutions AWS EC2

    EC2 = Elastic Compute Cloud Gehört zu IaaS, weil man „rohe“ VMs mietet ▪ Instanz = VM ▪ EBS (Elastic Block Storage) Volume = Festplattenspeicher ▪ Security Group = Firewall-Einstellung ▪ Key-Pair = SSH Schlüsselpaar ▪ Elastic-IPs
  46. 24.11.2020 //// Seite 35 WPS – Workplace Solutions AWS EC2

    ▪ Ist mit einer klassischen virtuellen Maschine vergleichbar ▪ Erhält eine IP-Adresse ▪ Wird mit einem Betriebssystem bestückt ▪ Grundlage ist meist ein Betriebssystemimage, das sogenannte AMI (Amazon Machine Image) ▪ Es gibt viele die von AWS bereits bereitgestellt werden ▪ Man kann aber auch eigene bauen etwa mit Packer oder LinuxKit EC2-Instanz
  47. 24.11.2020 //// Seite 36 WPS – Workplace Solutions ▪ Mehrere

    Maschinen, die untereinander kommunizieren sollen ▪ Aber nicht alle Konnektivität zum Internet haben sollen/dürfen ▪ Dabei hilft ein Service wie Virtual Private Cloud ▪ Instanzen lassen sich über Subnets zusammenfassen und von anderen Subnets abschotten Eine AWS-Instanz kommt selten allein EC2-Instanz EC2-Instanz EC2-Instanz App 2 App 1 DB VPC
  48. 24.11.2020 //// Seite 37 WPS – Workplace Solutions ▪ Ein

    Subnet trennt Instanzen logisch voneinander ab ▪ Instanzen verschiedener Subnets können also nicht aufeinander zugreifen ▪ Mit einem Internet Gateway können Subnets öffentlich erreichbar gemacht werden ▪ Durch Private Gateways lassen sich auch Verbindungen mit dem eigenen Netzwerk herstellen ▪ Oder man ermöglicht Zugang zu Subnets per VPN AWS VPC Subnets EC2-Instanz EC2-Instanz EC2-Instanz Websh op Backoff ice OLAP VPC EC2-Instanz EC2-Instanz Public Api Payme nt
  49. 24.11.2020 //// Seite 38 WPS – Workplace Solutions ▪ Innerhalb

    einer Verfügbarkeitszone kann es mehrere Subnets geben ▪ Ein Subnet kann sich nie über mehrere Verfügbarkeitszonen erstrecken AWS-VPC at Scale – Verfügbarkeitszonen EC2-Instanz EC2-Instanz EC2-Instanz App 2 App 1 DB VPC EC2-Instanz EC2-Instanz EC2-Instanz App 2 App 1 DB Frankfurt Berlin
  50. 24.11.2020 //// Seite 39 WPS – Workplace Solutions Live Demo

    AWS (manuell ohne Terraform) Keypair, Security Group, Instanz und DNS-Eintrag anlegen
  51. 24.11.2020 //// Seite 41 WPS – Workplace Solutions Die AWS

    (Web)-Console ▪ Nicht für Deployments geeignet, da keine Nachvollziehbarkeit gewährleistet wird ▪ Eher um das Serviceangebot zu erkunden und um initial zu verstehen wie ein Service funktioniert ▪ Effizient wird die Verwendung der Cloud erst wenn man Ressourcen automatisiert erzeugt ▪ Als Monitoring-Werkzeug bis man dies endlich professionalisiert hat
  52. 24.11.2020 //// Seite 42 WPS – Workplace Solutions AWS CLI

    und SDK ▪ Per Kommandozeile Zugriff auf AWS ▪ Im Grunde die AWS Web-Console auf der Kommandozeile ▪ Möglichkeit zur Automatisierung im Rahmen von Scripts ▪ Für die meisten Programmiersprachen werden SDKs bereitgestellt ▪ Ermöglicht die Erzeugung von Ressourcen aus der eigenen Anwendung ▪ Aber für die meisten Automatisierungsszenarien läuft es auf selbstgestrickte Lösungen raus
  53. 24.11.2020 //// Seite 43 WPS – Workplace Solutions Von Code

    zum Image mit fertigem Betriebssystem ▪ Vorbereitung eines Betriebssystems wie man es braucht ▪ Nach dem Erzeugen der EC2-Instanz sind keine weiteren Installationen nötig.
  54. 24.11.2020 //// Seite 44 WPS – Workplace Solutions Infrastrukturautomatisierung mit

    CloudFormation und Terraform ▪ Ein geeignetes System zur Infrastrukturautomatisierung ▪ CloudFormation: Eine Lösung von und für AWS ▪ Terraform: Ein Werkzeug für viele / alle Cloud-Anbieter ▪ Man beschreibt in einer Datei, welche Ressourcen erzeugt werden sollen ▪ Diese Datei gehört wie anderer Quellcode unter Versionskontrolle ▪ Ausführung der Dateien sorgt via API dafür, dass die entsprechenden Cloudressourcen erzeugt oder eben zerstört werden. ▪ Wegen der Unabhängigkeit sehen wir uns im Weiteren Terraform an.
  55. 24.11.2020 //// Seite 47 WPS – Workplace Solutions Umgebungen Entwicklungs-

    umgebung Integrations- umgebung Stagingumgebung eingeschränkter Betrieb vollständiger Betrieb
  56. 24.11.2020 //// Seite 48 WPS – Workplace Solutions Aber in

    der Integrationsumgebung ist der Fehler nicht aufgetreten!
  57. 24.11.2020 //// Seite 51 WPS – Workplace Solutions Moderne Anwendungen

    Quelle: https://de.slideshare.net/dotCloud/why-docker
  58. 24.11.2020 //// Seite 52 WPS – Workplace Solutions Software kommt

    in vielen Formen ▪ Verschiedene Programmiersprachen ▪ Inkompatible Abhängigkeiten ▪ z.B. python 2.7 vs python 3.x ▪ Dependency Hell ▪ Unterschiede in ▪ Betriebssystem ▪ Rechnerkonfiguration (z.B. PATH, JAVA_HOME, ...) ▪ Java-Version ▪ Application-Server-Version ▪ Application-Server-Konfiguration ▪ Verschiedene Paketierungswege ▪ Z.B. für Java Anwendungen: ▪ Aus Eclipse starten ▪ Als jar-Datei verpacken ▪ Als war in tomcat deployen ▪ Als Service-Dienst in Windows registrieren ➢ Interferenzen zwischen Anwendungen ➢ Unterschiedliches Verhalten je nach System ➢ unvorhergesehene Bugs
  59. 24.11.2020 //// Seite 55 WPS – Workplace Solutions Die Lösung:

    Container Quelle: https://de.slideshare.net/dotCloud/why-docker
  60. 24.11.2020 //// Seite 56 WPS – Workplace Solutions Containerisierung: Tools

    ▪ Linux-Container: ▪ Docker ▪ rkt (Rocket) ▪ LXD ▪ Windows-Container: ▪ DrawBridge ▪ Offener Standard appc LXD
  61. 24.11.2020 //// Seite 57 WPS – Workplace Solutions Wobei helfen

    Container? ▪Anwendung inkl. Software-Abhängigkeiten paketieren ▪Anwendung verteilen ▪Anwendung überall reproduzierbar starten ▪Externe Systemabhängigkeiten (z.B. DB) isolieren ▪In verschiedenen Umgebungen testen ▪Angriffsvektoren für Sicherheit minimieren
  62. 24.11.2020 //// Seite 58 WPS – Workplace Solutions Container helfen

    extrem, die Dev/Prod Parität zu maximieren.
  63. 24.11.2020 //// Seite 60 WPS – Workplace Solutions Container at

    Scale ▪ Container liefern ein Artefakt aus und bieten gute Möglichkeiten, sie mit umgebungsspezifischer Konfiguration zu starten ▪ Die Dev/Prod-Parität pro Container ist extrem hoch ▪ Häufig besteht ein System aus einer Vielzahl von Artefakten ▪ Alle Artefakte sollen im Verbund und konsistent konfiguriert gestartet und skaliert werden ▪ Darauf liefern Container für sich keine Antwort ▪ Ebenso nicht wie Container hostübergreifend kommunizieren können
  64. 24.11.2020 //// Seite 61 WPS – Workplace Solutions Abstraktionsschicht für

    den Containerbetrieb ▪ Realisieren die Verteilung von Containern auf mehrere Hosts ▪ Ermöglichen die hostübergreifende Kommunikation über Overlay-Netzwerke ▪ Wickeln die Umverteilung von Containern ab, wenn ein Host wegbricht
  65. 24.11.2020 //// Seite 63 WPS – Workplace Solutions IT-Organisation mit

    Container-Managern ▪ IT-Betrieb ▪ Kümmert sich um den Aufbau der Container- Management Umgebung ▪ Verantwortet das Sizing des Clusters ▪ Monitoring und Backups auf Clusterebene ▪ Anwendungsspezifische Deployment-Eigenheiten sind nicht mehr direkt Themen des IT-Betriebs ▪ Entwickler ▪ Müssen nicht in die Tiefen der Linux-Administration absteigen ▪ Beschreiben Deployments mit ihnen bekannten Mitteln ▪ Kümmern sich um anwendungsspezifisches Monitoring und Backup ▪ Automatisierungsaufgaben sind nicht umfänglich und fehleranfällig gescriptet, sondern werden bereits durch den Containermanager bereitgestellt Container Manager Host Host Host Storage Backend Monitoring Infrastruktur Host Host Host IT-Betrieb Entwickler Betreibt den Cluster Managen Builds und Code Managen Deployments
  66. 24.11.2020 //// Seite 64 WPS – Workplace Solutions Managed Services

    Was ist teurer, eine teuer gemietete Datenbank oder eine günstigere VM zu mieten und die Installation und Wartung selbst zu übernehmen?
  67. 24.11.2020 //// Seite 65 WPS – Workplace Solutions Konventionell -

    Die Infrastruktur selbst betreiben ▪ Microservice Teams oder Ops-Team installieren auf Bare-Metal oder VMs selbst die Infrastruktur (z.B. das DBMS) ▪ Das Team kümmert sich um die Wartung und Updates ▪ Wäre die Zeit nicht besser in die Arbeit am Kernsystem investiert?
  68. 24.11.2020 //// Seite 66 WPS – Workplace Solutions Managed Service

    vom Cloud-Anbieter ▪ Schnell aufgebaut ▪ Entwickler/Ops können sich voll auf die eigentliche Anwendung konzentrieren. ▪ Einige Betriebsaspekte werden automatisch durchgeführt ▪ Backups ▪ Updates ▪ Security-Checks ▪ Weniger Möglichkeiten in Konfiguration einzugreifen ▪ Der Service kommt von der Stange und ist so konfiguriert, dass es für die meisten passt
  69. 24.11.2020 //// Seite 67 WPS – Workplace Solutions Managed Services

    oder Rechenressourcen? Managed Service (SaaS, PaaS) Standardisierung Anpassbarkei t ▪ Abwägungsfrage: ▪ Managed Datenbank vom Cloudanbieter ▪ Oder eine reine VM/VMs auf denen die Datenbank selbst betrieben wird ▪ Häufig abzuwägen: ▪ Schneller Start vs. steile Lernkurve ▪ Für die Masse gute Leistung vs. auf individuellen Bedarf zugeschnittene Leistung ▪ Standardisierung vs. Anpassbarkeit
  70. 24.11.2020 //// Seite 70 WPS – Workplace Solutions Übung zu

    Kapitel 2 – Grundlagen moderner Infrastrukturen ▪ Lesen Sie die Fallstudie inklusive Szenarien ▪ Beantworten Sie folgende Fragen mit Hinblick auf die verschiedenen Bounded Contexts: ▪ Welche Risiken sehen Sie in der Nutzung einer Public und/oder Private Cloud? ▪ Welche Chancen sehen Sie in der Nutzung einer Public und/oder Private Cloud? ▪ Hinweis: Am besten klappt es, wenn Sie Ihre Gedanken frühzeitig in Miro festhalten
  71. 24.11.2020 //// Seite 4 WPS – Workplace Solutions CONWAYS LAW

    ▪ Melvin Conway: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." "If you have four groups working on a compiler, you'll get a 4-pass compiler“ Eric Raymond
  72. “Organizations which design systems are constrained to produce designs which

    are copies of the communication structures of these organizations.” Melvin Conway
  73. Melvin Conway (1967) “Organizations which design systems are constrained to

    produce designs which are copies of the communication structures of these organizations.”
  74. 24.11.2020 //// Seite 13 WPS – Workplace Solutions MICROSERVICES AND

    SCALABILITY https://martinfowler.com/articles/microservices.html
  75. 24.11.2020 //// Seite 14 WPS – Workplace Solutions MICROSERVICES –

    WAS IST DAS? ▪ Ein Architekturstil und eine technische Idee, die mit der Modularisierung von Domänen gut zusammenpasst ▪ Unabhängig voneinander deployt ▪ Eigener Prozess (oder sogar eine eigene VM) ▪ Läuft häufig in einem eigenen Container Micro- service A Micro- service B Micro- service C
  76. 24.11.2020 //// Seite 15 WPS – Workplace Solutions MICROSERVICES –

    WAS IST DAS? ▪ Ein Architekturstil und eine technische Idee, die mit der Modularisierung von Domänen gut zusammenpasst ▪ Unabhängig voneinander deployt ▪ Eigener Prozess (oder sogar eine eigene VM) ▪ Läuft häufig in einem eigenen Container ▪ Hält seine Daten in einer eigenen Datenbank oder einem Schema Micro- service A Micro- service B Micro- service C
  77. 24.11.2020 //// Seite 16 WPS – Workplace Solutions MICROSERVICES –

    WAS IST DAS? ▪ Ein Architekturstil und eine technische Idee, die mit der Modularisierung von Domänen gut zusammenpasst ▪ Unabhängig voneinander deployt ▪ Eigener Prozess (oder sogar eine eigene VM) ▪ Läuft häufig in einem eigenen Container ▪ Hält seine Daten in einer eigenen Datenbank oder einem Schema ▪ Kann in unterschiedlichen Technologien und Stylen implementiert sein → keine Wiederverwendung Micro- service A Micro- service B Micro- service C
  78. 24.11.2020 //// Seite 17 WPS – Workplace Solutions MICROSERVICES –

    TECHNOLOGIEFREIHEIT Micro- service A Micro- service B Micro- service C Microservices reden nur über Netzprotokolle miteinander  Nur Laufzeitabhängigkeit  Freiheit in der Wahl der Technologie ▪ Entscheidungen können schneller getroffen werden ▪ Technologie kann auf jeweiligen Service zugeschnitten werden ▪ Z.B. Graph-DB für Service, der viel mit Relationen hantiert ▪ Keine unnötige Komplexität durch unpassende Sprache / Frameworks / Datenbanken
  79. 24.11.2020 //// Seite 18 WPS – Workplace Solutions MICROSERVICES –

    WAS IST DAS? ▪ Ein Architekturstil und eine technische Idee, die mit der Modularisierung von Domänen gut zusammenpasst ▪ Unabhängig voneinander deployt ▪ Eigener Prozess (oder sogar eine eigene VM) ▪ Läuft häufig in einem eigenen Container ▪ Hält seine Daten in einer eigenen Datenbank oder einem Schema ▪ Kann in unterschiedlichen Technologien und Stylen implementiert sein → keine Wiederverwendung ▪ Hat manchmal eine GUI, manchmal nicht Micro- service A GUI Micro- service B Micro- service C
  80. 24.11.2020 //// Seite 19 WPS – Workplace Solutions MICROSERVICES –

    WAS IST DAS? ▪ Ein Architekturstil und eine technische Idee, die mit der Modularisierung von Domänen gut zusammenpasst ▪ Unabhängig voneinander deployt ▪ Eigener Prozess (oder sogar eine eigene VM) ▪ Läuft häufig in einem eigenen Container ▪ Hält seine Daten in einer eigenen Datenbank oder einem Schema ▪ Kann in unterschiedlichen Technologien und Stylen implementiert sein → keine Wiederverwendung ▪ Hat manchmal eine GUI, manchmal nicht ▪ Kommuniziert über Netz mit anderen Services durch verschiedene Technologien (synchron/asynchron) Micro- service A Micro- service B Micro- service C
  81. 24.11.2020 //// Seite 20 WPS – Workplace Solutions Independent System

    Architecture Eine Sammlung von Best Practices, die aus den Erfahrungen von Microservice und Self-Contained Systems resultieren
  82. 24.11.2020 //// Seite 21 WPS – Workplace Solutions ▪ Einige

    Punkte werden als Must-Have durch ein “muss” im Satz verdeutlicht. Hier gibt es kaum Spielraum die Best Practices nicht umzusetzen ▪ Andere Punkte sind lediglich mit einem “sollte“ versehen und bieten hier aus ISA-Sicht eher Raum sie nicht so umzusetzen ▪ Tiefergehende Beschreibung auf https://isa- principles.org ▪ Alle Aspekte werden im Laufe der Schulung näher betrachtet Die Independent System Architecture (ISA)
  83. 24.11.2020 //// Seite 22 WPS – Workplace Solutions Wesentliche Punkte

    einer Independent System Architecture (ISA) 1. Das System muss in verschiedene Module zerlegt werden, die Schnittstellen bereitstellen 2. Das System muss zwei klar getrennte Ebenen von Architekturentscheidungen haben a. Macroarchitektur b. Microarchitektur 3. Die Unabhängigkeit zwischen Modulen muss maximiert werden. Dies erreicht man durch getrennte Prozesse, Container und virtuelle Maschinen 4. Die Integration und Kommunikation muss für das System begrenzt und vereinheitlicht werden 5. Metadaten, z.B. zur Authentifizierung müssen modulübergreifend vereinheitlicht werden 6. Jedes Modul muss seine eigene Continuous Delivery Pipeline haben 7. Der Betrieb (Konfiguration, Deployment, Logging, ...) sollte modulübergreifend vereinheitlicht werden 8. Standards für Betrieb, Integration oder Kommunikation sollten lediglich auf Schnittstellenebene vorgeschrieben sein 9. Module müssen resilient sein https://isa-principles.org
  84. 24.11.2020 //// Seite 24 WPS – Workplace Solutions ▪ Begriff

    ursprünglich aus Datenbankwelt ▪ Shared Something: ▪ Prozesse teilen sich Ressourcen (RAM, Disk) ▪ Synchronisation muss stattfinden ▪ Single-Point-of-Failure ▪ Shared Nothing: ▪ Prozesse sind unabhängig ▪ Skalierung beliebig möglich ▪ MongoDB lässt sich durch Sharding horizontal skalieren ▪ Shared Everything ▪ Festplatte und RAM geteilt ▪ Oracle RAC, AWS Aurora Shared Something / Shared Nothing Prozess A Shared Disk Prozess B Prozess A Shared Nothing Prozess B Früher vor allem auf der Hardware-Ebene, heute wir der Begriff aber neu interpretiert!
  85. 24.11.2020 //// Seite 25 WPS – Workplace Solutions Shared Something

    / Shared Nothing II RAM RAM RAM RAM RAM CPU CPU CPU CPU CPU CPU SAN Disk Disk BUS LAN LAN Shared RAM Shared Disk Shared Nothing
  86. 24.11.2020 //// Seite 26 WPS – Workplace Solutions ▪ Services

    sollen ▪ Unabhängig voneinander deploybar sein ▪ Ihren Dienst fortführen, wenn andere Services Probleme verursachen ▪ Shared Nothing durch Containerisolation Shared Something / Shared Nothing III Prozess A Shared Disk Prozess B Prozess A Shared Nothing Prozess B
  87. 24.11.2020 //// Seite 27 WPS – Workplace Solutions ▪ Shared

    Nothing nicht nur im Betrieb, sondern auch in der Entwicklung ▪ Jedes Team hat eigene Entwicklungs- Infrastruktur (Build-Server, Repository, …) ▪ Änderungen an Build-Server oder -Konfiguration betrifft nur einzelnes Team ▪ Kein teamübergreifender Quellcode Shared Infrastructure
  88. 24.11.2020 //// Seite 29 WPS – Workplace Solutions MICROSERVICES Kino-

    management Kartenverkauf Marketing Kino-Anwendung Kino- management Kartenverkauf Marketing Legende WAR- File Java Package
  89. 24.11.2020 //// Seite 30 WPS – Workplace Solutions Mikro- und

    Makro-Architekturentscheidungen ▪ Typische Makro-Architektur ▪ Kommunikationsprotokoll zwischen Microservices ▪ Authentifizierung ▪ Ggf. durch einen zentralen Identity Provider ▪ Look & Feel ▪ Falls Microservices eine eigene UI besitzen ▪ Technologie für Integrationstests ▪ Typisch Mikro-Architektur ▪ Autorisierung ▪ Konkrete Unit-Tests ▪ Continuous Delivery Pipeline
  90. 24.11.2020 //// Seite 31 WPS – Workplace Solutions Mikro- und

    Makro-Architekturentscheidungen ▪ Entscheidungen können auf Mikro- oder Makroebene entschieden werden ▪ Makroebene ▪ Einsatz der Gesamtlösung wird eingeschränkt ▪ Unternehmensweite Standards ▪ Mikroebene ▪ Optimale Lösung für den einzelnen Bounded Context ▪ Sorgt für Unabhängigkeit der Teams ▪ Beispiele ▪ Die Programmiersprache ▪ Die Datenbank ▪ Look & Feel ▪ Dokumentation
  91. 24.11.2020 //// Seite 32 WPS – Workplace Solutions Getrennte Betriebsmannschaft

    You build it You run it Firmenkultur Betrieb: Mikro- und Makro-Architektur Betrieb • Konfiguration • Monitoring • Log-Analyse • Deployment-Technologie Mikroarchitektur Makroarchitektur
  92. 24.11.2020 //// Seite 33 WPS – Workplace Solutions Entscheidungen auf

    Makroarchitekturebene haben Auswirkungen auf die Integration
  93. 24.11.2020 //// Seite 34 WPS – Workplace Solutions Ebenen der

    technischen Integration von vertikalen Subsystemen Micro- service A Micro- service B Micro- service C UI Backend Daten
  94. 24.11.2020 //// Seite 35 WPS – Workplace Solutions Schnittstelle eines

    Microservices ▪ REST ▪ Anbindung der UI an das Backend ▪ Synchron → Rest Ressourcen passend fürs UI gestalten mit Value Objects → Keine Entities oder Aggregate als Ressource ▪ Messaging ▪ Service zu Service ▪ Asynchron → Commands, Events, Request, Response mit Value Objects Service A UI A Service B POST GET PUT DELETE POST, GET, PUT, DELETE
  95. 24.11.2020 //// Seite 36 WPS – Workplace Solutions Datenintegration (Shared

    Database) ▪ Mehrere Services arbeiten auf dem gleichen Datenbankschema ▪ Keine Datenredundanz ▪ Schema kann nur gemeinsam weiterentwickelt werden ▪ Das widerspricht dem Konzept „Microservice“ ▪ Nicht zu verwechseln mit Shared Kernel (Context Mapping) Subsystem A Subsystem B
  96. 24.11.2020 //// Seite 37 WPS – Workplace Solutions Datenintegration (Datenreplikation)

    ▪ Jeder Microservice hat seine eigene Datenbank oder sein eigenes Datenbankschema ▪ Redundanz der Daten ▪ Datenmigration kann durch „Extract, Transform, Load “- Prozesse (ETL) realisiert sein Micro- service A Micro- service B ETL
  97. 24.11.2020 //// Seite 38 WPS – Workplace Solutions Backendintegration File

    Transfer Vorteile ▪ Einfach ohne weitere Software zu realisieren ▪ Auf allen Plattformen und in allen Programmiersprachen verfügbar ▪ Asynchron, sodass die Applikationen getrennt weiter arbeiten können ▪ Lose Kopplung zwischen den Applikationen ▪ Kaum Eingriffe in die Applikation, um den Export zu realisieren ▪ Interna der Apps bleiben verborgen Nachteile ▪ Inkonsistenz zwischen Applikationen wegen großer Zeitintervalle zwischen den Updates der Daten ▪ Viele Absprachen zwischen den Entwicklern notwendig über: ▪ Verzeichnisse und Dateinamen ▪ Zeitpunkt der Fertigstellung und des Löschens eines Exports ▪ Semantik der Daten wird in den Applikationen jeweils lokal festgelegt Voraussetzung ▪ Gemeinsames Dateisystem ▪ Einigung über das Format (Textbasiert, XML, CSV, etc.) ▪ Exporter bzw. Importer verstehen das gleiche Format Micro- service A Micro- service B
  98. 24.11.2020 //// Seite 39 WPS – Workplace Solutions Backendintegration RPC

    (Remote Procedure Call) Vorteile ▪ Funktionalität wird wiederverwendet ▪ Daten sind lokal gekapselt, sodass jede Applikation beliebige eigene Formate wählen kann und die Integrität ihrer eigenen Daten wahrt ▪ Potentiell weniger Codeverdopplung, weil Funktionen wiederverwendet werden Nachteile ▪ Enge Kopplung und geringere Stabilität bei Ausfall einer Applikation ▪ Performanz und Ausfallsicherheit von entfernten Aufrufen ▪ Änderungen an einer Applikation betreffen potentiell alle entfernten Aufrufer ▪ Sich gegenseitig aufrufende Applikationen bilden ein kaum zu entwirrendes Knäuel Voraussetzung ▪ Veröffentlichung von nutzbaren Funktionen für andere Applikationen ▪ Einigung über eine gemeinsame Technologie (z. B. CORBA, COM, .NET, RMI, SOAP mit HTTP) ▪ Berücksichtigung von Ausfällen des Netzwerks bzw. der aufgerufenen Applikation Micro- service A Micro- service B Micro- service A Micro- service B
  99. 24.11.2020 //// Seite 40 WPS – Workplace Solutions GRPC ▪

    gRPC = gRPC Remote Procedure Call ▪ Entwickelt von Google ▪ Open Source ▪ Basiert auf ▪ HTTP/2 (Transport) ▪ Protobuf (Schnittstellenbeschreibung)
  100. 24.11.2020 //// Seite 41 WPS – Workplace Solutions Backendintegration REST

    (Representational State Transfer) Im Vergleich zu RPC ▪ Ähnlich wie RPC (ebenfalls synchrone Kommunikation) ▪ Anstatt von Funktionsaufrufen wird auf Ressourcen gearbeitet ▪ Prinzipien ▪ Zustandslosigkeit ▪ Nachricht enthält alle Informationen, Server speichert keine Zustände zwischen zwei Nachrichten ▪ Caching ▪ HTTP Caching soll verwendet werden ▪ Einheitliche Schnittstelle ▪ Adressierbarkeit von Ressourcen ▪ http://webshop/api/bestellungen ▪ Repräsentationen zur Veränderung von Ressourcen ▪ HTML/JSON/XML ▪ Selbstbeschreibende Nachrichten ▪ Durch HTTP-Verben, GET, POST, DELETE, PUT Micro- service A Micro- service B
  101. 24.11.2020 //// Seite 42 WPS – Workplace Solutions HTTP Methoden

    HTTP-Methode Seiteneffekt-frei Idempotent GET Ja Ja PUT Nein Ja DELETE Nein Ja POST Nein Nein PATCH Nein Nein
  102. 24.11.2020 //// Seite 43 WPS – Workplace Solutions HATEOAS ▪

    Hypermedia As The Engine Of Application State (HATEOAS) ▪ Beispiel: ▪ http://api.domain.com/management/departments/10 { "departmentId": 10, "departmentName": "Administration", "locationId": 1700, "managerId": 200, "links": [ { "href": "10/employees", "rel": "employees", "type" : "GET" } ] }
  103. 24.11.2020 //// Seite 44 WPS – Workplace Solutions Wie finden

    sich Services eigentlich? Hey, ! Wo bist du und wie kann ich dich erreichen?
  104. 24.11.2020 //// Seite 45 WPS – Workplace Solutions Service Discovery

    klassisch ▪ Konfigurationsdatei ▪ Wird gelegentlich aktualisiert ▪ Probleme bei Microservices ▪ Netzwerk-Adressen nicht statisch ▪ Microservices werden dynamisch gestartet oder gestoppt ▪ Wie wird Load Balancing durchgeführt? Service Client Service Instanz A Service Instanz B Service Instanz C Client oder ein API Gateway Dynamische IP Adressen Skalierung REST API REST API REST API 10.10.2.12:8893 10.10.34.24:8034 10.10.1.99:8238 ?
  105. 24.11.2020 //// Seite 46 WPS – Workplace Solutions Service Discovery

    (Client Side Load Balancing) ▪ Client ist verantwortlich für die Bestimmung von verfügbaren Services und deren Location ▪ Client ist ebenfalls verantwortlich für das Load Balancing ▪ Ablauf ▪ Services melden sich bei der Service Registry an ▪ Client fragt Service Registry nach Services ab ▪ Client verwendet Load-Balancing Algorithmus und spricht Service an Service Instanz A Service Instanz B Service Instanz C REST API REST API REST API 10.10.2.12:8893 10.10.34.24:8034 10.10.1.99:8238 Service Register Client Ein HTTP Client der das Register kennt Register Client Register Client Register Client
  106. 24.11.2020 //// Seite 47 WPS – Workplace Solutions Service Discovery

    (Server Side Load Balancing) ▪ Services melden sich ebenfalls bei der Service Registry an ▪ Ein Load Balancer übernimmt die Aufgabe der Service Auswahl Service Instanz A Service Instanz B Service Instanz C REST API REST API REST API 10.10.2.12:8893 10.10.34.24:8034 10.10.1.99:8238 Service Register Client Register Client Register Client Register Client Load Balancer
  107. 24.11.2020 //// Seite 48 WPS – Workplace Solutions Backendintegration Messaging

    Vorteile ▪ Lose Kopplung, ähnlich wie File Transfer ▪ Hohe Ausfallsicherheit des Gesamtsystems, weil Nachrichten aufgehoben werden ▪ Weniger Performance-Probleme wegen Message- Queues ▪ Asynchrone Kommunikation macht Zeitverzögerung übers Netz für Entwickler sichtbar ▪ Über Nachrichten können Daten verschickt und Funktionsaufrufe abgesetzt werden Nachteile ▪ Asynchrone Kommunikation muss beherrscht werden ▪ Semantische Dissonanz zwischen Applikationen wird nicht behoben Voraussetzung ▪ Applikationen sind an einen Message Bus angeschlossen ▪ Entsprechende Technologie wird verwendet (JMS, IBM WebSphereMQ, Microsoft MSMQ, asynchrone WebServices). Micro- service A Micro- service B
  108. 24.11.2020 //// Seite 50 WPS – Workplace Solutions Message-oriented Middleware

    (MOM) Grundkonzepte: • Send and Forget • Store and Forward Loose Coupling and Reliability Channels are separate from applications → Removes location dependencies Channels are asynchronous and reliable → Removes temporal dependencies Data is exchanged in self-contained messages → Removes data format dependencies
  109. 24.11.2020 //// Seite 51 WPS – Workplace Solutions Synchrone vs.

    Asynchrone Kommunikation Auswirkungen asynchroner Kommunikation • Prozesse arbeiten parallel → Schnellere Verarbeitung, aber schwieriges Debugging • Ergebnisse durch Callback → Empfang und Verarbeitung in neuem Kontext und bei Ausführung anderer Arbeiten • Unbestimmte Ausführungsreihenfolge → Unabhängige Prozesse mit Synchronisationslogik
  110. 24.11.2020 //// Seite 52 WPS – Workplace Solutions Delivering in

    MOM – Die Queue ▪ Messages werden in einer Queue auf dem Server persistiert ▪ Eine Message kann nur einmal von einem Consumer gelesen werden ▪ Mehrere Producer / Consumer können dieselbe Queue benutzen ▪ Das Verarbeiten kann skaliert werden A B P queue Q message producers message consumers
  111. 24.11.2020 //// Seite 53 WPS – Workplace Solutions Delivering in

    MOM – Das Topic ▪ Messages werden in einem Topic auf dem Server persistiert ▪ Mehrere unterschiedliche Consumer erhalten die gleichen Nachrichten ▪ Mehrere Producer / Consumer können das gleiche Topic benutzen ▪ Das Verarbeiten kann nicht skaliert werden (außer…) A B P topic Q message producers message consumers
  112. 24.11.2020 //// Seite 54 WPS – Workplace Solutions Delivering in

    MOM – Kombination aus Queue und Topic ▪ Messages werden in einem Topic auf dem Server persistiert. Jedes Topic ist partitioniert. ▪ Mehrere unterschiedliche Consumer Groups erhalten die gleichen Nachrichten. In einer Consumer Group können sich mehrere Consumer befinden. ▪ Mehrere Producer / Consumer können das gleiche Topic benutzen ▪ Das Verarbeiten kann über Partitionierung skaliert werden A1 B1 P topic Q message producers message consumers A2 B2 A B
  113. 24.11.2020 //// Seite 55 WPS – Workplace Solutions Herausforderung durch

    MOM ▪ Komplexes Programmiermodell ▪ Event-getriebenes Programmiermodell ▪ Logik wird auf Eventhandler verteilt ▪ Debugging über Prozessgrenzen ▪ Nachrichtenreihenfolge ▪ Nachrichten haben Zustellgarantie, aber evtl. keine Garantie der Reihenfolge ▪ Abhängige Nachrichten müssen resequentialisiert werden ▪ Synchrone Anwendungsszenarien ▪ Anwender gehen von einer synchronen Bearbeitung ihrer Anfrage aus ▪ Anwendung muss entsprechend reagieren ▪ Plattform Support ▪ Proprietäre MOMs oder Plattformen schränken die Möglichkeiten ein ▪ Herstellerabhängigkeit ▪ Trotz Standards wie JMS sind die Implementierungen oft plattformabhängig ▪ Die Integration von integrierten Lösungen ist eine weitere Herausforderung!
  114. 24.11.2020 //// Seite 56 WPS – Workplace Solutions Message Technologien

    ▪ Message Systeme ▪ RabbitMQ ▪ ActiveMQ ▪ Kafka ▪ Protokolle ▪ AMQP (Advanced Message Queuing Protocol) ▪ MQTT (Message Queue Telemetry Transport), Internet of Things ▪ STOMP (Streaming Text Oriented Messaging Protocol) ▪ APIs ▪ JMS
  115. 24.11.2020 //// Seite 58 WPS – Workplace Solutions Frontend UI-Integration

    (Frontend Monolith) ▪ Es gibt einen Frontend Monolithen ▪ Native Apps ▪ Desktop Anwendung ▪ Single-Page-Applikation ▪ Ggf. ein Team für die Frontendentwicklung ▪ Optional mit API-Gateway ▪ Einheitliches Look & Feel Micro- service A Micro- service B
  116. 24.11.2020 //// Seite 59 WPS – Workplace Solutions UI-Integration (Modularisiertes

    Frontend) ▪ Integration über ▪ Links ▪ Transklusion (auch: Content Projection) ▪ Übernahme von einem elektronischen Dokument oder Teilen davon in ein oder mehrere andere Dokumente durch einen Hypertext-Verweis ▪ Vorteile ▪ Lose Kopplung ▪ Login und UI in einem Microservice (Ein Team) ▪ Freie Wahl der Frontend-Technologie ▪ Herausforderung ▪ Einheitliches Look & Feel ▪ UI-Änderungen ggf. querschnittlich (Z.B. bei Redesign) Micro- service A Micro- service B
  117. 24.11.2020 //// Seite 60 WPS – Workplace Solutions Micro frontends

    https://martinfowler.com/articles/micro-frontends.html
  118. 24.11.2020 //// Seite 61 WPS – Workplace Solutions Integrationsansätze für

    Micro-Frontends ▪ Serverseitige Template-Komposition ▪ Je nach URL-Suffix andere HTML-Datei in index.html inkludieren, oder ▪ Je nach URL-Suffix Teil-HTML von anderem Server abfragen ▪ Buildtime Integration ▪ Im Frontend die „Micro-Frontends“ als versionierte npm-dependencies einbinden ▪ Nachteil: Kopplung auf Release/Deployment-Ebene ▪ Laufzeit-Integration mit iframes ▪ Je nach Route direkt im index.html jeweiligen iframe von unterschiedlichen Ressourcen und unterschiedlichen Servern holen ▪ Laufzeit-Integration mit JavaScript ▪ index.html inkludiert JavaScript-Dateien von allen Micro-Frontends. Je nach Route wird der Entrypoint eines Micro-Frontends aufgerufen, der dann das Rendern übernimmt ▪ Flexibel ▪ Laufzeit-Integration mit WebComponents ▪ Je nach Route WebComponent von jeweiligem Micro-Frontend in den DOM laden ▪ Weniger flexibel, stärker am Web-Standard
  119. 24.11.2020 //// Seite 62 WPS – Workplace Solutions Self Contained

    System (SCS) ▪ Für Microservices gibt es keine einheitliche Definition ▪ Ein SCS ist eine Ausprägung von Microservices ▪ SCS geben einen Orientierungspunkt, wie eine Microservice-Architektur konkret aussehen kann ▪ SCS sind eine Sammlung von Best Practices ▪ SCS geben Elemente auf der Makro-Architekturebene vor http://scs-architecture.org/
  120. 24.11.2020 //// Seite 63 WPS – Workplace Solutions Self Contained

    System (SCS) ▪ Jedes SCS ist eine autonome Webanwendung ➔ Jedes SCS besitzt eine UI ▪ Es gibt keine gemeinsame UI ▪ Ein SCS kann optional eine API besitzen ▪ Z.B. für die Anbindung von einer mobilen App ▪ Ein SCS gehört einem Team ▪ Ein SCS kann aus mehreren Microservices bestehen ▪ Z.B. für Skalierung ▪ Priorisierung für die Kommunikation unter SCSs ▪ Prio 1: UI-Integration ▪ Prio 2: asynchrone Kommunikation ▪ Prio 3. synchrone Kommunikation Micro- service A Micro- service B 1 2
  121. 24.11.2020 //// Seite 64 WPS – Workplace Solutions Orchestrierung (Workflow-Engine

    + Enterprise Service Bus) ▪ Zentrale Orchestrierung über Workflow-Engine ▪ Workflow-Engine kann Standalone oder als Bestandteil eines ESBs laufen ▪ Muster eher unüblich für Microservice- Architekturen ▪ Leichtgewichtigere Lösungen werden bevorzugt Microservice Kino- management Microservice Ticketverkauf ESB Microservice Marketing Workflow-Engine
  122. 24.11.2020 //// Seite 65 WPS – Workplace Solutions Orchestrierung (Service)

    ▪ Microservices übernehmen die Orchestrierung ▪ Optional kann eine Workflow-Engine im Microservice laufen ▪ Beispiel: Camunda ▪ Harte Abhängigkeit bleibt zwischen den Services Microservice Ticketverkauf Microservice Marketing Microservice Kinomanagement Workflow-Engine
  123. 24.11.2020 //// Seite 66 WPS – Workplace Solutions Orchestrierung (EVENT-DRIVEN

    ARCHITECTURE) ▪ Bounded Contexts kommunizieren über Domain Events ▪ Ähnlichkeit zu Pipes-and-Filters ▪ Messaging ist Pipes ▪ Bounded Contexts sind Filters (besser Processors) ▪ Lose gekoppelt ▪ Vergleich mit Unix-Pipeline Kartenverkauf Wochenplan finalisiert
  124. 24.11.2020 //// Seite 68 WPS – Workplace Solutions Event Sourcing

    ▪ Event Store ▪ Ereignisse beschreiben etwas, was schon geschehen ist ▪ Alle Zustandsänderungen werden durch Ereignisse ausgelöst ▪ Ereignisse werden gespeichert, nicht der Zustand ▪ Append-only ▪ Es gibt kein Löschen ▪ Aber Stornierende Events ▪ History-Funktion ▪ Commands ▪ Clients fehlt möglicherweise Kontext zur Erzeugung von Events ▪ Commands können Events auslösen
  125. 24.11.2020 //// Seite 69 WPS – Workplace Solutions ▪ Kontobewegungen

    ▪ Geld eingenommen (Event) ▪ Geld abgebucht (Event) ▪ Erstelle Überweisung (Command) ▪ Leasing-Vertrag ▪ Vertrag angelegt ▪ Vertrag unterzeichnet ▪ Vertrag genehmigt ▪ (mit Auflagen) ▪ Vertrag abgerechnet ▪ Versionskontrollsystem Event Sourcing – Beispiele https://commons.wikimedia.org/wiki/File:Kontoauszug.svg
  126. 24.11.2020 //// Seite 70 WPS – Workplace Solutions ▪ CQS

    (Command-Query-Separation) ▪ Operationen entweder zustandsändernd (Commands) ▪ Oder sondierend (Queries) ▪ Klassisch für Methoden an Klassen ▪ CQRS (CQ-Responsibility-Segregation) ▪ Trennung der Verantwortlichkeit ▪ Zwei unterschiedliche Objekte/Module für Command und Query ▪ Nicht pro Klasse, sondern in der Architektur Command-Query-Responsibility-Segregation (CQRS) Command Handler Query Handler Daten
  127. 24.11.2020 //// Seite 71 WPS – Workplace Solutions ▪ Nur

    weil wir die gleichen Daten verwenden, müssen wir nicht das gleiche Datenmodell verwenden! Command-Query-Responsibility-Segregation (CQRS) Command Handler Query Handler Datenmodell B Datenmodell A
  128. 24.11.2020 //// Seite 72 WPS – Workplace Solutions ▪ “A

    command handler is a flavor of an application service“ Zweiteilung von Domain- und Application-Layer Domain Model (Write Model) View Model (Read Model) Application Services for business tasks Application Services for report requests
  129. 24.11.2020 //// Seite 73 WPS – Workplace Solutions CQRS und

    Fachmodelle ▪ Queries ▪ Können jetzt mit einem dünnen Lese-Layer gemacht werden ▪ Keine Fachlogik mehr ▪ ➔Reporting ▪ Commands ▪ Behalten richtiges Fachmodell ▪ Können aber schlanker sein, weil sie sich über Datenabfragen keine Gedanken mehr machen müssen ▪ Typischerweise nur noch eine Abfrage getByID()
  130. 24.11.2020 //// Seite 74 WPS – Workplace Solutions ▪ Die

    Commands werden in einer DB gespeichert ▪ Die Queries werden auf einer anderen DB gefahren ▪ Der Command Handler sorgt dafür, dass der Zustand der zweiten DB passend ist ▪ Vorteile: ▪ Unterschiedliche Technologien für CS und DB möglich ▪ Dadurch schnelle Speicherung und schnelles Lesen ▪ Es ist möglich Datenstand für jeden beliebigen Zeitpunkt wieder herzustellen ▪ DB kann aus Command Store wiederhergestellt werden Command Store (auch: Command Sourcing) Command Handler Query Handler Command Store Command Queue Query- Datenbank
  131. 24.11.2020 //// Seite 75 WPS – Workplace Solutions DDD, Event-Sourcing

    & CQRS kombinieren Command Handler Thin Data Layer Event Store Client Read Database Domain Logic Event Repository Aggregate DTO Event Publisher Event Handler SQL Command
  132. 24.11.2020 //// Seite 76 WPS – Workplace Solutions CQRS und

    Bounded Contexts ▪ CQRS ist nicht für alles der richtige Architekturstil ▪ Sondern in einzelnen Bounded Contexts ▪ Auch möglich: ▪ Command Handler in einem BC, ▪ Query Handler in einem anderen
  133. 24.11.2020 //// Seite 77 WPS – Workplace Solutions Übung zu

    Kapitel 3 – Gängige Architekturmuster ▪ Betrachtet auch die Szenarien aus der Fallstudie. ▪ Mit Blick auf die geplante Systemlandschaft: Welcher Architekturstil wird den Anforderungen am besten gerecht? ▪ Wie sollten die Systembestandteile integriert werden? ▪ Betrachten Sie CQRS als Integrationsform. Passt der Stil in die Anwendungslandschaft? ▪ Diskutieren der Lösungsvorschläge in der Gruppe
  134. 24.11.2020 //// Seite 4 WPS – Workplace Solutions Was bedeutet

    Cloud Native? ▪ Es gibt keine standardisierte Definition. Es ist ein Buzzword ▪ Grobe Idee: Anwendungen so designen, dass diese sich sehr gut („natürlich“) und erfolgreich in der Cloud betreiben lassen ▪ Betrifft ▪ Entwurf ▪ Implementierung ▪ Betrieb
  135. 24.11.2020 //// Seite 5 WPS – Workplace Solutions iSAQB /

    CPSA: "Applications adopting the principles of Microservices, packaged and delivered as Containers, orchestrated by Platforms, running on top of Cloud infrastructure" Microservices Containers Platforms Cloud Infrastructure
  136. 24.11.2020 //// Seite 7 WPS – Workplace Solutions Andere... https://medium.com/walmartlabs/cloud-native-application-architecture-

    a84ddf378f82 https://www.redhat.com/en/topics/cloud-native-apps https://www.ibm.com/cloud/cloud-native | https://www.ibm.com/cloud/learn/cloud-native https://www.cncf.io/
  137. 24.11.2020 //// Seite 8 WPS – Workplace Solutions 1. Packaged

    as lightweight containers 2. Developed with best-of-breed languages and frameworks 3. Designed as loosely coupled microservices 4. Centered around APIs for interaction and collaboration 5. Architected with a clean separation of stateless and stateful services 6. Isolated from server and operating system dependencies 7. Deployed on self-service, elastic, cloud infrastructure 8. Managed through agile DevOps processes 9. Automated capabilities 10. Defined, policy-driven resource allocation ▪ https://thenewstack.io/10-key-attributes-of-cloud- native-applications/ 1. Designed As Loosely Coupled Microservices 2. Developed With Best-of-breed Languages And Frameworks 3. Centred Around APIs For Interaction And Collaboration 4. Stateless And Massively Scalable 5. Resiliency At The Core Of the Architecture 6. Packaged As Lightweight Containers And Orchestrated 7. Agile DevOps & Automation Using CI/CD 8. Elastic — Dynamic scale-up/down ▪ https://medium.com/walmartlabs/cloud-native- application-architecture-a84ddf378f82 Eigenschaften von Anwendungen
  138. 24.11.2020 //// Seite 9 WPS – Workplace Solutions Cloud-native software

    is highly distributed, must operate in a costantly changing environment, and is itself constantly changing. Cornelia Davis, Former VP of Technology at Pivotal
  139. 24.11.2020 //// Seite 10 WPS – Workplace Solutions Etwas konkreter:

    12factor.net ▪ I. Codebase: Eine im Versionsmanagementsystem verwaltete Codebase, viele Deployments ▪ II. Abhängigkeiten: Abhängigkeiten explizit deklarieren und isolieren ▪ III. Konfiguration: Die Konfiguration in Umgebungsvariablen ablegen ▪ IV. Unterstützende Dienste: Unterstützende Dienste als angehängte Ressourcen behandeln ▪ V. Build, release, run: Build- und Run-Phase strikt trennen ▪ VI. Prozesse: Die App als einen oder mehrere Prozesse ausführen ▪ VII. Bindung an Ports: Dienste durch das Binden von Ports exportieren ▪ VIII. Nebenläufigkeit: Mit dem Prozess-Modell skalieren ▪ IX. Einweggebrauch: Robuster mit schnellem Start und problemlosen Stopp ▪ X. Dev-Prod-Vergleichbarkeit: Entwicklung, Staging und Produktion so ähnlich wie möglich halten ▪ XI. Logs: Logs als Strom von Ereignissen behandeln ▪ XII. Admin-Prozesse: Admin/Management-Aufgaben als einmalige Vorgänge behandeln
  140. 24.11.2020 //// Seite 11 WPS – Workplace Solutions Eine 12factor-App

    ist nicht un- bedingt eine Cloud Native App!
  141. 24.11.2020 //// Seite 12 WPS – Workplace Solutions Cloud Native

    ... Journey „klassische“ Anwendung „die bessere“ Anwendung Freie Skalierung Hochverfügbarkeit Failover Eigenständigkeit Container Infrastruktur- Abstraktion Modularisierung Microservices API Orientierung Metriken Monitoring Fehler- toleranz Umgebungs- unabhängigkeit Continuous Deployment Cloud Native? Optimale Sprachen & Tools
  142. 24.11.2020 //// Seite 13 WPS – Workplace Solutions Antipattern: Distributed

    Big Ball of Mud Distributed Big Ball Of Mud „Modulith“ Microservices (Bounded Contexte) Monolithic Big Ball Of Mud
  143. 24.11.2020 //// Seite 14 WPS – Workplace Solutions Cloud Native

    Maturity Model (Pivotal) „Cloud Ready“ •Eigenständigkeit (self-contained): alles in einem Paket •Netzwerk (Ein- ausgehend) von außen definierbar •verwendet bereitgestellte "Basisdienste" •Nicht-ständiger Zugriff auf persistenten Speicher Cloud Friendly •Erfüllung der „12 Faktoren“ •Horizontale Skalierbarkeit (durch zustandslose Services) •Hochverfügbarkeit (Failover) durch Platform Cloud Resilient •Hohe Fehlertoleranz schon im Entwurf •Anbieterunabhängige Implementierung •Metriken und Monitoring in Services eingebaut •Proaktive Ausfalltests Cloud Native •Microservices •API-orientierter Entwurf
  144. 24.11.2020 //// Seite 15 WPS – Workplace Solutions Aber eine12factor-App

    bietet gute Voraussetzungen um zur Cloud Native App zu werden.
  145. 24.11.2020 //// Seite 16 WPS – Workplace Solutions Unser Fokus:

    Container & Orchestrierung ▪ Egal, wie man die Reise gestaltet, für Cloud Native unstrittig ist: ▪ Bereitstellung von Software als Container ▪ Integration mit anderen Diensten nur noch über Netzwerk-Ports ▪ Auslagern der Persistenz aus den eigenen Services, Annäherung an “Zustandslosigkeit“ ▪ Die automatische Steuerung der Integration, des Lebenszyklus und der Skalierung von Containern Container Netzwerk Persistenz Orchestrierung
  146. 24.11.2020 //// Seite 17 WPS – Workplace Solutions Naiv: Eine

    Anwendung als Container verpacken /etc/config.ini /var/db/data lib.jar util.dll executable.bin /var/db/data Wozu? Volume Entrypoint
  147. 24.11.2020 //// Seite 18 WPS – Workplace Solutions ▪ Immer

    vollständiges und konsistentes Softwarepaket ▪ Freiheit zur Veränderung für SW-Team ▪ Eindeutige Versionierung des Container-Images ▪ Reproduzierbarkeit des Deployments ▪ Selbes Paket in DEV, TEST, PROD ▪ (Was ist mit der config.ini? Später!) ▪ Unabhängigkeit vom Host-System: ▪ „Build Once, Run Anywhere“, aber anders: ▪ Keine klassische Plattformunabhängigkeit ▪ Aber Unabhängigkeit von der konkreten Umgebung des Hosts Einfaches, konsistentes Lieferartefakt lib.jar util.dll /etc/config.ini executable.bin /etc/config.ini lib.jar util.dll executable.bin
  148. 24.11.2020 //// Seite 19 WPS – Workplace Solutions Reduzierung der

    Konfigurationseigenschaften ▪ Ein Container hat nur noch wenige, definierte Zugangspunkte ▪ Aufrufparameter (Entrypoint) & Umgebungsvariablen ▪ Externe Verzeichnisse/Dateien (Volumes) ▪ Ein- und ausgehende Netzwerk-Verbindungen (Ports): ▪ Angebotene Dienste ▪ Benötigte Dienste ▪ Großes Vereinheitlichungspotenzial: Egal welche Anwendung, sie hat nur noch diese definierenden Eigenschaften für denjenigen, der sie in Betrieb nimmt ▪ (oder sogar noch weniger?)
  149. 24.11.2020 //// Seite 20 WPS – Workplace Solutions Docker Lifecycle

    Container Image Dockerfile BUILD SHIP RUN Registry build run push pull
  150. 24.11.2020 //// Seite 22 WPS – Workplace Solutions Docker CLI

    docker info docker pull docker images docker run docker ps docker stop docker logs ...
  151. 24.11.2020 //// Seite 23 WPS – Workplace Solutions Arten, Container

    zu starten ▪Dauerhaft laufende(r) Server oder Datenbank ▪docker run -d my-server ▪Kurzlebiges Skript (mit Antwort) ▪docker run --rm ubuntu ls ▪Interaktiver Container ▪docker run –it my-server sh
  152. 24.11.2020 //// Seite 27 WPS – Workplace Solutions Nächste Schritte

    1. (VII) Dienste immer als Port anbieten • Vereinheitlichtes Nutzungsmodell • Service-Nutzer entkoppelt vom Service-Host 2. (III) Konfiguration immer über Umgebungsvariablen • Simple Konfiguration • Stage-agnostische Container • keine Überraschungen in Produktion wg. abweichender Konfiguration /etc/config.ini lib.jar util.dll executable.bin /var/db/data 80 Volume Entrypoint Port A=B
  153. 24.11.2020 //// Seite 29 WPS – Workplace Solutions HOST ▪

    Durch Port-Binding kann man nun viele Container auf einem Host betreiben. Z.B. ▪ Diverse Stages (Entwicklung, Test, Produktion) meiner einen Anwendung bzw. eines Dienstes ▪ Mehrere Anwendungen oder Services ▪ Oder gar beliebige, auch fremde Container? ▪ Ist sichergestellt, dass diese sich gegenseitig nicht beeinflussen? Mehrere Container auf einem Host CONTAINER 80 CONTAINER 80 CONTAINER 80 5001 5002 5003
  154. 24.11.2020 //// Seite 30 WPS – Workplace Solutions Dockerfile Beispiel

    FROM python:3.4 RUN groupadd -r uwsgi && useradd -r -g uwsgi uwsgi RUN pip install Flask==0.10.1 uWSGI==2.0.8 requests==2.5.1 redis==2.10.3 WORKDIR /app COPY app /app COPY entrypoint.sh / EXPOSE 9090 9191 USER uwsgi ENTRYPOINT ["/entrypoint.sh"]
  155. 24.11.2020 //// Seite 35 WPS – Workplace Solutions Container-Isolation –

    Die „alte Welt“ der VMs ▪ Herkömmliche (systembasierte) VMs besitzen einen Hypervisor, der die Zugriffe der Gastsysteme auf die Hardware des Hosts kapselt (Netzwerk, Audio, Grafikkarte, Festplatte, etc.) ▪ Die Kapselung kann durch Hardware-Emulation, Hardware- Virtualisierung oder Paravirtualisierung erfolgen. In jedem Fall denken die Gastsysteme, sie kommunizieren mit der „echten“ Hardware ▪ Gast-Systeme = vollständige, eigenständige Betriebssysteme, die sich unterscheiden können vom Host (z.B. ein Linux-Gast- System auf einem Windows-Host – oder umgekehrt), besitzen einen eigenen Netzwerk-Stack und sind Stateful ▪ Primäres Ziel: Server-Partitionierung – „Warum soll mein Rechner schlafen, nur weil in App 1 nichts passiert?“
  156. 24.11.2020 //// Seite 36 WPS – Workplace Solutions Container-Isolation –

    Die „neue“ Welt der Container ▪ Container sind quasi „etwas besser isolierte Prozesse“ direkt auf dem Host ▪ Keine Hardware-Emulation: Container teilen sich Ressourcen (CPU, Memory, Festplattenspeicher, etc.) mit dem Host und miteinander und verwenden auch den gleichen Kernel ▪ Deshalb können auf einem Windows-Host auch nur Windows- Container ausgeführt werden. Um Linux-Container auf einem Windows-Host zu starten müssen die Container innerhalb einer VM laufen. ▪ Primäres Ziel: Skalierbarkeit, Performance, Reproduzierbarkeit des Deployments, Leichtgewichtigkeit
  157. 24.11.2020 //// Seite 37 WPS – Workplace Solutions Container-Isolation –

    „Wie werden die Container denn jetzt voneinander isoliert?“ ▪ „namespaces“ (Isolation) ▪ „limitieren, was von welchen Prozessen gesehen werden kann bzw. darf“ ▪ pid, net, ipc, mount, uts, user ▪ „cgroups“ (Limitierung) ▪ „limitieren Prozesse/Prozessgruppen/Ressourcen wie Memory, CPU, Block, Network“ ▪ z.B. Absicherung vor DOS (Denial of Service) - Attacken Beispiel: pid - namespace
  158. 24.11.2020 //// Seite 38 WPS – Workplace Solutions Container-Isolation –

    Linux Capabilities ▪ Privilegierte Prozesse ▪ Prozesse, die vom Root-User ausgeführt werden, umgehen Kernel Restriktionen ▪ Der Root-User darf quasi „alles“ ▪ Ergo: Anwendungen innerhalb von Containern sollten in der Regel keine Root- Rechte erhalten! (no-brainer) ▪ Linux Capabilities ▪ Ermöglichen es Prozessen (Usern) eine Teilmenge der Root-Rechte bereitzustellen ▪ Jedes dieser Rechte kann einzeln vergeben werden ▪ Ein normaler (unprivilegierter) User benötigt früher oder später weitere Rechte (z.B. um einen Netzwerk Socket aufzumachen) ▪ Lösung 1 (schlecht): Root-Rechte vergeben (gefährlich) ▪ Lösung 2: Capability CAP_NET_BIND_SERVICE vergeben (Tada, Port 80 ist frei)
  159. 24.11.2020 //// Seite 39 WPS – Workplace Solutions Container-Isolation –

    AppArmor ▪ Modul des Linux Security Modules (LSM) ▪ Vergibt die Linux Capabilities ▪ Reguliert und beschränkt Zugriffe auf Netzwerk, Dateien und Verzeichnisse ▪ Zählt zu den Mandatory Acess Control (MAC) Sicherheitssystemen ▪ Für Anwendungen können „Anwendungsprofile“ definiert werden, die die Berechtigungen beschreiben, die eine Anwendung besitzen darf ▪ Bevor die AppArmor-Regeln greifen, werden allerdings zunächst die Benutzer- Zugriffsrechte durch das Discretional Access Control (DAC) von Linux überprüft ▪ „AppArmor kann mit den Docker-Containern verwendet werden, die auf einer Container-optimierten OS-Instanz laufen“. Die Container besitzen dann bereits ein Default-Anwendungsprofil
  160. 24.11.2020 //// Seite 40 WPS – Workplace Solutions Container-optimierte Betriebssysteme

    Betriebssysteme für die Nutzung in Containern Betriebssysteme für Container- Hosts
  161. 24.11.2020 //// Seite 41 WPS – Workplace Solutions Betriebssysteme für

    die Nutzung in Containern ▪ Sehr klein ▪ Nur Package Manager und grundlegende Kommandos vorinstalliert ▪ Beispiel: Alpine (5MB) ▪ Nachteil: Viele offizielle Docker-Images, z.B. Jenkins, laufen stabiler mit größeren Basis-Images wie Debian
  162. 24.11.2020 //// Seite 42 WPS – Workplace Solutions Betriebssysteme für

    Container-Hosts Vor- und Nachteile am Beispiel von Googles Container-Optimized OS: ▪ Vorteile ▪ Spezialisiert auf den Umgang mit Containern ▪ Sehr schlank, da nur die nötigsten Programme installiert wurden, um potentielle Angriffsmöglichkeiten auf ein Minimum zu beschränken (z.B. kein Paketmanager!) ▪ Firewall nach Installation vollständig auf Lockdown eingestellt ▪ Zugriffe ausschließlich per SSH ▪ Verbindungen werden per Whitelisting freigegeben ▪ Lädt automatisch wöchentliche Updates im Hintergrund herunter, die bei einem Container-Neustart direkt installiert werden (reduziert Wartung) ▪ Anwendungen können nur innerhalb eines Containers gestartet werden (Sicherheit)
  163. 24.11.2020 //// Seite 43 WPS – Workplace Solutions Betriebssysteme für

    Container-Hosts ▪ Nachteile ▪ Viele Standardprogramme wie z.B. der Paketmanager fehlen ▪ Keine selbstständige Installation von Softwarepaketen möglich ▪ Hierfür benötigt man Werkzeuge wie die CoreOS Toolbox ▪ Anwendungen müssen in einem Container ausgeführt werden ▪ COS läuft nur mit Googles Cloud Engine
  164. 24.11.2020 //// Seite 44 WPS – Workplace Solutions Betriebssysteme für

    Container-Hosts ▪ Googles COS nimmt einem zwar einiges an Aufwand ab bei der Einrichtung von Containern - andere Alternativen bieten einem allerdings sehr viel mehr Freiheiten: ▪ Beispiele: ▪ Fedora CoreOS (ehemals CoreOS Container Linux und Project Atomic) ▪ RancherOS (Rancher) ▪ DCOS (Mesosphere) ▪ Photon (VmWare)
  165. 24.11.2020 //// Seite 48 WPS – Workplace Solutions Container-Isolation –

    Container vs Virtuelle Maschine (VM) ▪ VMs benötigen Hypervisor ▪ Hohe Isolation (Security) ▪ Performance-Overhead ▪ Container sind quasi „etwas besser isolierte Prozesse“ direkt auf dem Host (Stichworte: cgroups, namespaces, privileged/unprivileged) ▪ Performance ▪ Ressourcennutzung ▪ Nähe zum Host birgt Sicherheitsrisiken (Kompromittierbarkeit)
  166. 24.11.2020 //// Seite 49 WPS – Workplace Solutions Aufruf eines

    anderen Service /etc/config.ini lib.jar util.dll executable.bin /var/db/data A=B ▪ Eigener Service ▪ Fremder Service ws://cool-service.foo.bar.com/endpoint ws://cool-service/endpoint Volume Entrypoint Port Link
  167. 24.11.2020 //// Seite 50 WPS – Workplace Solutions Persistenz auslagern

    /etc/config.ini executable.bin /var/db/data A=B Volume Entrypoint Port Link
  168. 24.11.2020 //// Seite 51 WPS – Workplace Solutions Persistenz –

    Ein Vergleich File Storage Block Storage Object Storage
  169. 24.11.2020 //// Seite 52 WPS – Workplace Solutions Persistenz –

    Ein Vergleich – File Storage ▪ File Storage ▪ Klassisch ▪ Alle unstrukturierten Daten (nicht in DB) auf File Servern / NAS Systemen ▪ Bei großen Datenmengen wird die Skalierung schwierig und resultiert oft in vielen Dateninseln mit hoher Komplexität, Kosten, Aufwand und Risiko und die Performance sinkt erheblich bei größeren Datenmengen
  170. 24.11.2020 //// Seite 53 WPS – Workplace Solutions Persistenz –

    Ein Vergleich – Block Storage ▪ Block Storage ▪ Grundlage für VM-Festplatten ▪ Daten werden in Blöcken fixer Größe gespeichert (daher der Name) ▪ Es gibt keine Metadaten und Dateien sind üblicherweise über etliche Blöcke verteilt ▪ Wird eher für strukturierte Daten (Daten in Datenbanken) verwendet ▪ Vorteilhaft für Transaktionen ▪ Kann über Regionen verteilt werden, allerdings leidet dann die Performance deutlich
  171. 24.11.2020 //// Seite 54 WPS – Workplace Solutions Persistenz –

    Ein Vergleich – Object Storage ▪ Object Storage ▪ Beispiel: AWS S3 ▪ Einfacher zu nutzen als File Storage und Block Storage ▪ Flache Struktur ▪ Jedes Objekt hat ID und optionale Metadaten ▪ Von physischem Speicherort wird abstrahiert ▪ Cloudanbieter übernimmt Verteilung, Ausfallsicherheit usw.
  172. 24.11.2020 //// Seite 55 WPS – Workplace Solutions Persistenz –

    Ein Vergleich – Überblick Typ Geschwindigke it Verteilung Skalierbarkeit Analyse File Storage Gut für kleine Mengen und Dateien Schwierig, meist nur lokal oder in lokalen Netzwerken Millionen von Dateien aber dann ist Schluss Nur vordefinierte Metadaten Block Storage Gut für Datenbanken und transaktionale Daten Hohe Latenzen bei weiter Verteilung Begrenzt durch Adressierungsraum Keine Metadaten Object Storage Besonders gut für große Datenmengen Einfache Verteilung über viele Regionen Kaum Grenzen Sehr gut durch konfigurierbare Metadaten
  173. 24.11.2020 //// Seite 56 WPS – Workplace Solutions Unstrukturierte Daten

    - Datenspeicherung in der Cloud ▪ In der Cloud spielt Skalierbarkeit eine große Rolle ▪ Dafür sind zustandslose Container erforderlich ▪ Wie soll dann persistiert werden? ▪ Werden Daten im Container gespeichert gehen diese verloren wenn der Container stirbt. ▪ Werden Daten auf dem Host gespeichert gehen diese verloren wenn der Host stirbt.
  174. 24.11.2020 //// Seite 57 WPS – Workplace Solutions Strukturierte Daten

    – RDBMS in der Cloud – Vor- und Nachteile ▪ Datenbanken für Cloud Anwendungen: entweder selbst gehostet oder managed ▪ Nachteile managed: ▪ Lokalität der Daten (compliance) ▪ Vorgaben (wie bspw. die unterstützen DBs) ▪ Bedingt konfigurierbar ▪ Vorteile managed: ▪ Support ▪ Vereinfachte Einrichtung, Skalierbarkeit, Verwaltung ▪ Sehr hohe Geschwindigkeit, sowie Verfügbarkeits- und Sicherheitsstandards ▪ Keine Hardwarebestellung, Datenbankeinrichtung ▪ Automatische Updates und Backups ▪ Pay what you use
  175. 24.11.2020 //// Seite 58 WPS – Workplace Solutions Strukturierte Daten

    – RDBMS in der Cloud - Anbieterauswahl ▪ Amazon bietet AWS RDS: ▪ Amazon Aurora, MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server ▪ Migrationsservice (AWS Database Migration Service) ▪ Automatische Skalierung (nur Aurora) ▪ Zahlen was man nutzt (compute + storage) ▪ Unterstützt lesende horizontale Skalierung durch Replikas ▪ Microsoft Azure: ▪ SQL Database (basiert auf Microsoft SQL Server) ▪ Zahlen was man nutzt, aber es gibt unterschiedliche „tiers“ mit unterschiedlicher Performance, Verfügbarkeit, Speichergröße Support, etc. ▪ Untertützt sharding via „Elastic Database Tools“
  176. 24.11.2020 //// Seite 59 WPS – Workplace Solutions Strukturierte Daten

    – NoSQL DBaaS - Anbieterauswahl ▪ Selbstverständlich gibt es auch NoSQL Datenbanken in der Cloud ▪ AWS: ▪ DynamoDB (Dokumentenbasierte DB) ▪ Azure: ▪ DocumentDB (Dokumentenbasierte DB) ▪ TableStorage (Key-value store) ▪ MongoDB Atlas für GCP, Azure und AWS
  177. 24.11.2020 //// Seite 61 WPS – Workplace Solutions Container Management

    – Was ist das und wann brauche ich das? Wie gehe ich mit dem Deployment von riesigen Mengen von Containern um? Wie kann ich bestimmte Container skalieren? Wie kann ich wissen ob alle meine Container gerade stabil laufen? Wie verteile ich meine Container auf meine Hardware? Wie können die Container sich untereinander finden? Wie kann ich die Konfiguration außerhalb der Container lagern? Wie behalte ich einen Überblick über meine Ressourcen?
  178. 24.11.2020 //// Seite 62 WPS – Workplace Solutions Verschiedene Container

    Manager Docker Swarm • Einfach zu benutzen und installieren, wenige Funktionalitäten und geringer Support durch Community Apache Mesos + Marathon • Neben Container Verwaltung auch Ressourcen Verwaltung, persistente Speicher lange in Beta, komplex, weniger Funktionalitäten und geringer Support durch Community Nomad • Wenige Funktionalitäten, Fokus auf Cluster Management, sehr leichtgewichtig, hochskalierbar Kontena, CloudFoundry, AWS ECS, … → Kubernetes
  179. 24.11.2020 //// Seite 63 WPS – Workplace Solutions Container Management

    – Kubernetes – Ein Überblick der Vorteile ▪ Bietet (unter anderem) ▪ Service discovery mit Lastverteilung ▪ Speicherorchestrierung ▪ Automatisierte Rollouts und Rollbacks ▪ Ressourcenverwaltung ▪ Selbst heilend ▪ Secret und Config Management ▪ Pod Placement ▪ Kann als deklarative state machine betrachtet werden ▪ Man definiert einen Wunschzustand via YAML Konfigurationsdateien ▪ Kubernetes versucht diesen Zustand zu erstellen und zu halten
  180. 24.11.2020 //// Seite 65 WPS – Workplace Solutions Container Management

    – Managed Services (Kubernetes) Quelle: https://aws.amazon.com/de/eks/
  181. 24.11.2020 //// Seite 66 WPS – Workplace Solutions Container Manager

    – Kubernetes – Cluster Access ▪ Zugriff für Devs über kubectl ▪ Konfiguration über ▪ .kubeconfig file im kubectl dir ▪ KUBECONFIG environmment variable ▪ Config definiert ▪ Endpunkt ▪ User
  182. 24.11.2020 //// Seite 67 WPS – Workplace Solutions Container Manager

    - Kubernetes - RBAC ▪ RBAC = Role Based Access Control ▪ Konfiguriert durch kubernetes api ▪ Basiert auf Role, ClusterRole und Permissions ▪ Es gibt nur additive Permissions ▪ Kein Deny! ▪ Role <- existiert in einem Namespace ▪ ClusterRole <- pot. Namespace übergreifend ▪ Rollen werden an User durch RoleBindings angebracht ▪ ClusterRoleBinding für Cluster Roles Bildquelle: https://blog.aquasec.com/kubernetes-rbac
  183. 24.11.2020 //// Seite 68 WPS – Workplace Solutions Container Management

    – Kubernetes – Grundlegende Konzepte - Pods ▪ In der Welt von Kubernetes (K8S) werden nicht Container sondern Pods deployt ▪ Ein Pod ist eine Hülle um einen (oder mehrere) Container ▪ Pods ermöglichen Kubernetes Anwendungen zu skalieren ▪ Es sollte nur eine fachliche Anwendung pro Pod laufen ▪ Alle Container im Pod teilen sich ein lokales Netzwerk und Volume ▪ Ein Pod ist ein sogenanntes Kubernetes Object Volume Container Pod
  184. 24.11.2020 //// Seite 69 WPS – Workplace Solutions Container Management

    – Kubernetes – Kubernetes Objects ▪ Werden von Controllern (Erklärung folgt) verwaltet und über Konfigurationsdateien (üblicherweise yaml) definiert ▪ Erforderlich sind ▪ apiVersion ▪ kind ▪ metadata ▪ spec ▪ Es gibt extrem viele Kubernetes Objects, aber oft reichen einige wenige aus apiVersion: v1 kind: Pod metadata: name: test-pod labels: app: test spec: containers: - name: test-container image: busybox command: ['sh', '-c', 'echo Hello Word! && sleep 3600'] test-pod.yaml
  185. 24.11.2020 //// Seite 70 WPS – Workplace Solutions Container Management

    – Kubernetes – Grundlegende Konzepte – Pods ▪ Wie wird ein Pod deployt? ▪ Alle Kubernetes Objects können in Dateien beschrieben und mit einem Kommandozeilentool (kubectl) an K8S übertragen werden ▪ `kubectl.exe apply –f test-pod.yaml` ▪ Aber ▪ Was passiert wenn der Pod stirbt? (cattle) ▪ Wie skaliere ich nun die Anwendung? apiVersion: v1 kind: Pod metadata: name: test-pod labels: app: test spec: containers: - name: test-container image: busybox command: ['sh', '-c', 'echo Hello Word! && sleep 3600'] test-pod.yaml
  186. 24.11.2020 //// Seite 72 WPS – Workplace Solutions Container Management

    – Kubernetes – Grundlegende Konzepte - ReplicaSet ▪ Kubernetes kann eine deklarative Zustandsbeschreibung entgegen nehmen und versuchen diesen kontinuierlich aufrecht zu erhalten ▪ Das Aufrechterhalten geschieht durch sogenannte Controller, welche den aktuellen Zustand beobachten, mit dem Soll-Zustand abgleichen und Änderungen auslösen (Control Loop) ▪ Das ReplicaSet ist ein solcher Controller ReplicaSet
  187. 24.11.2020 //// Seite 73 WPS – Workplace Solutions apiVersion: apps/v1

    kind: ReplicaSet spec: replicas: 3 template: spec: containers: - name: test-container image: busybox command: ['sh', '-c', 'echo Hello Word! && sleep 3600'] Container Management – Kubernetes – Grundlegende Konzepte – ReplicaSet ▪ Dieses ReplicaSet versucht immer 3 Pods gleichzeitig am Laufen zu halten ▪ Wenn einer stirbt wird ein neuer gestartet ▪ Wie das genau funktioniert wird später erklärt ▪ Aber ▪ Was wenn ich eine neue Version von meiner Anwendung deployen möchte? apiVersion: apps/v1 kind: ReplicaSet metadata: name: test-replicaset labels: app: test spec: replicas: 3 selector: matchLabels: app: test template: metadata: labels: app: test spec: containers: - name: test-container image: busybox command: ['sh', '-c', 'echo Hello Word! && sleep 3600'] test-replicaset.yaml
  188. 24.11.2020 //// Seite 75 WPS – Workplace Solutions Container Management

    – Kubernetes – Grundlegende Konzepte - Deployment ▪ Wird in der Regel verwendet statt des ReplicaSet oder Pod ▪ Ermöglicht es unter anderem Deployment Strategien durchzuführen ▪ Ändert sich das Pod template, so wird ein neues ReplicationSet erzeugt welches die neuen Pods startet ▪ Im Beispiel wird gerade v2 deployt. Dazu wird im ReplicaSet von v1 ein Pod entfernt während der erste Pod im ReplicaSet von v2 gestartet wird Deployment v1 v2
  189. 24.11.2020 //// Seite 76 WPS – Workplace Solutions apiVersion: apps/v1

    kind: Deployment spec: replicas: 3 template: spec: containers: - name: test-container image: busybox command: ['sh', '-c', 'echo Hello Word! && sleep 3600'] Container Management – Kubernetes – Grundlegende Konzepte – Deployment ▪ Spezifikation unterscheidet sich nicht großartig vom ReplicaSet ▪ Unterstützt aber update Strategien .spec.strategy.type==Recreate||Rolling Update ▪ Kann zurückgerollt werden apiVersion: apps/v1 kind: Deployment metadata: name: test-deployment labels: app: test spec: replicas: 3 selector: matchLabels: app: test template: metadata: labels: app: test spec: containers: - name: test-container image: busybox command: ['sh', '-c', 'echo Hello Word! && sleep 3600'] test-deployment.yaml
  190. 24.11.2020 //// Seite 78 WPS – Workplace Solutions Container Management

    – Kubernetes – State Machine ▪ Wie funktioniert die Zustandserhaltung / -erreichung in K8S? ▪ K8S beobachtet mittels kubelet jeden Container über healthchecks ▪ Ist ein Container tot, wird ein neuer gestartet ▪ Aber ▪ Wie kann ich überhaupt einen Pod erreichen? ▪ Wo laufen die kubelets? (kommen wir später zu) ▪ Wie weiß ich ob ein Container tot ist? (kommen wir später zu) ReplicaSet kubelet
  191. 24.11.2020 //// Seite 79 WPS – Workplace Solutions Container Management

    – Kubernetes – Grundlegende Konzepte – Service ▪ Ermöglicht das einfache Ansprechen von Pods über den Service Namen oder DNS ▪ Ermöglicht Lastverteilung ▪ Im Beispiel wird ein Service erstellt, der jeden Pod mit dem Label `app=test` auf Port 16325 adressiert und selbst von K8S eine IP zugewiesen bekommt (oft cluster ip genannt) apiVersion: v1 kind: Service metadata: name: test-service spec: selector: app: test ports: - protocol: TCP port: 80 targetPort: 16325 test-service.yaml
  192. 24.11.2020 //// Seite 80 WPS – Workplace Solutions Cluster Management

    – Kubernetes – Load Balancing ▪ Services ▪ Wenn Services genutzt werden, können Anfragen an den Service statt an einen speziellen Pod gestellt werden. ▪ Der Service entscheidet dann welcher der angebundenen Pods mit gleicher Funktionalität die Anfrage erhält. Technisch nutzt der Service dazu den kube-proxy. ▪ Es gibt 2 Modi anhand derer diese Entscheidung gefällt wird. ▪ 1. Zufällige Auswahl ▪ 2. Round Robin ▪ Beides ist keine perfekte Lastverteilung, da die Auslastung der Pods nicht betrachtet wird ▪ Alternativ bieten einige Cloud Anbieter einen speziellen Service vom Typ „LoadBalancer“ an ▪ Bindet einen externen Load Balancer an ▪ Kann clusterweit (default) oder nodeweit (local) konfiguriert werden ▪ Weitere Alternative: Ingress ▪ Je nach Ingress Controller unterschiedliche Möglichkeiten der Lastverteilung
  193. 24.11.2020 //// Seite 81 WPS – Workplace Solutions Service-Type: ClusterIP

    ▪ Nur innerhalb des Clusters erreichbar ▪ Oder über Proxy: kubectl proxy --port=8080 ▪ Use Cases: ▪ Debugging ▪ Cluster-interne Kommunikation Service Pod Pod Pod Proxy
  194. 24.11.2020 //// Seite 83 WPS – Workplace Solutions Service-Type: NodePort

    ▪ Öffnet direkt Port auf Nodes für Zugriff von außen ▪ 1 Port pro Service ▪ Vorteile: ▪ Einfach ▪ Keine zusätzlichen Cloud-Ressourcen nötig ▪ Keine Kosten ▪ Nachteile: ▪ Port muss Aufrufer bekannt sein ▪ Jeder Service braucht unterschiedliche Ports ▪ Kein Loadbalancing -> Skaliert nicht ▪ Aufrufer muss Node-Adressen kennen ▪ Aufrufer muss wissen, auf welchen Nodes welche Service-Pods laufen Service Pod Pod Pod Node Port Node Port Node Port
  195. 24.11.2020 //// Seite 84 WPS – Workplace Solutions ▪ Erzeugt

    „dummen“ Loadbalancer außerhalb des Clusters ▪ Cluster muss Cloud-Anbieter kennen und entsprechende Rechte haben ▪ Vorteile: ▪ Performance ▪ Skalierung ▪ Nachteile: ▪ Kosten (jeder Service erzeugt eigenen Loadbalancer) ▪ Jeder Service hat eigene IP Service-Type: LoadBalancer Service Pod Pod Pod Load Balancer
  196. 24.11.2020 //// Seite 85 WPS – Workplace Solutions ▪ Technisch

    kein Service, sondern eigenes Konzept ▪ Ein Einstiegspunkt für viele Services ▪ Unterscheidung nach Route, Domäne etc. ▪ Meist realisiert durch „smarten“ (L7 HTTP) Loadbalancer vom Cloudanbieter ▪ Vorteile: ▪ Geringe Kosten ▪ Mächtigkeit ▪ SSL etc. einfach umsetzbar ▪ Nachteile: ▪ Hohe Komplexität ▪ Kann Bottleneck werden „Service-Type“: Ingress Service Pod Pod Pod Ingress Service Pod Pod Pod /foo /bar
  197. 24.11.2020 //// Seite 87 WPS – Workplace Solutions Container Management

    – Kubernetes – Grundbegriffe ▪ Node = kleinste Rechenhardware (physischer Rechner / VM / … ) ▪ Bietet Abstraktion auf austauschbare CPU + RAM ▪ Cluster = eine Menge von Nodes ▪ Deployments werden intelligent auf Nodes verteilt ▪ Persistent Volumes = Bereiche für dauerhafte Speicherung ▪ Benötigt da lokale Daten verworfen werden können (node switch) ▪ Nicht gemanaged ▪ Lokale oder Cloud Datenträger werden angebunden, persistent volumes kapseln dies Node CPU: 2000 RAM: 32GB Node CPU: 1200 RAM: 16GB Node CPU: 500 RAM: 4GB Cluster lokales Dateisystem Cloud Speicher
  198. 24.11.2020 //// Seite 88 WPS – Workplace Solutions Container Management

    – Kubernetes – Control vs. Data Plane ▪ Master Nodes (oft Control Plane genannt) ▪ Überwachung und Steuerung des Clusters ▪ Worker Nodes (auch Dataplane) ▪ Führen eigentliche Workloads (Pods) aus ▪ Lokale Netzwerkverwaltung Master Node Scheduler Kube API Server Cloud Controller Manager Kube Controller Manager Cluster Storage Worker Node n Worker Node 1 Kubelet Kube-proxy Kube-proxy Pod 1 Pod n Container Runtime
  199. 24.11.2020 //// Seite 89 WPS – Workplace Solutions Overlay Networks

    – Wie funktioniert die Kommunikation? ▪ Unterschiedliche Pods können auf unterschiedlichen Nodes liegen, wie können diese nun kommunizieren? ▪ Hier helfen Overlay Networks: ▪ Arbeitet auf dem Layer 3 des OSI Modells (IP) durch Hinzufügen eines weiteren äußeren Headers ▪ Herstellung von virtuellen privaten Netzen ▪ Subnetze werden getunnelt für einfache Kommunikation ▪ Vorteile: ▪ Vereinfachtes IP-Adressen Management ▪ Einfach skalierbar ▪ Sicherheit durch private Netzwerke
  200. 24.11.2020 //// Seite 90 WPS – Workplace Solutions Container Management

    – Kubernetes – Master Components 1/2 ▪ Kube API Server ▪ API Schnittstelle zur Master Node (inkl. Authorisierung) ▪ Akzeptiert Kommandos zur Ansicht und Änderung des Cluster Zustands (z.B. gestartete Pods) ▪ Baut Verbindung zu kubelets der Worker Nodes auf ▪ Cluster Storage ▪ Persistiert den Status, die Konfiguration und den aktuellen Ausführungs-Plan des Clusters ▪ Oft mittels etcd realisiert Master Node Scheduler Kube API Server Cloud Controller Manager Kube Controller Manager Cluster Storage
  201. 24.11.2020 //// Seite 91 WPS – Workplace Solutions Container Management

    – Kubernetes – Master Components 2/2 ▪ Kube Scheduler ▪ Evaluiert die Anforderungen von Pods und plant die Verteilung auf Nodes ▪ Behält Überblick über Status der Pods sowie den Rahmenbedingungen (Hardware, Software und Richtlinien) ▪ Kube Controller Manager ▪ Beobachtet den Zustand des Clusters und versucht den gewollten Zustand des Clusters zu regulieren (Stichwort control loop) mittels mehrerer Controller die Kubernetes Objects beobachten ▪ Node Controller, Replication Controller, Endpoints Controller, … ▪ Cloud Controller Manager ▪ Wie Kube Controller Manager nur für Cloud Provider Master Node Kube Scheduler Kube API Server Cloud Controller Manager Kube Controller Manager Cluster Storage
  202. 24.11.2020 //// Seite 92 WPS – Workplace Solutions Container Management

    – Kubernetes – Node Components ▪ Kubelet ▪ Stellt sicher dass die von Kubernetes gestarteten Container im Pod funktionsfähig sind (healthchecks) ▪ Informiert den Kube API Server ▪ Startet Pods mittels Container Runtime (meist Docker) ▪ Kube-proxy ▪ Verwaltet das lokale Node-Netwerk (IP, iptables, IPVS, Netzwerkrichtlinien) ▪ Stellt sicher dass alle Pods im Cluster miteinander kommunizieren können Worker Node 1 Kubelet Kube-proxy Pod 1 Pod n Container Runtime
  203. 24.11.2020 //// Seite 93 WPS – Workplace Solutions Unstrukturierte Daten

    - Cloud Native Storage – Beispiel Kubernetes ▪ Container Dateisystem ▪ Einfach im Dateisystem des Containers speichern ▪ Daten gehen verloren sobald der Container stirbt ▪ Lokales Volume ▪ Dateien ins Volume des Pods speichern ▪ Daten gehen verloren sobald der Pod stirbt ▪ Persistent Volume ▪ Pods geben an was sie für einen Speicher brauchen (Persistent Volume Claim) und bekommen beim Start einen zugewiesen ▪ Daten bleiben erhalten solange das Cluster lebt (also auch wenn eine Node stirbt)
  204. 24.11.2020 //// Seite 94 WPS – Workplace Solutions Persistent Volume

    und Persistent Volume Claim 15GB 50GB 50GB 15GB 5GB 5GB Cluster- Admin Erzeugt Persistent Volumes Dev / DevOps Deployt Pod der persistenten Speicher braucht, daher erstellt er auch ein PVC Pod Persistent Volume Claim (PVC) Ein PersistentVolumeClai m Formuliert anforderungen an den Speicher (z.B. Größe) Der Cluster weist aus den bestehenden Volumes mindestens eines zu welches den Anforderungen des PVC entpricht
  205. 24.11.2020 //// Seite 95 WPS – Workplace Solutions Container Management

    – Kubernetes – Weitere Kubernetes Objects ▪ Ingress = Kontrollierter Eingang für von extern (außerhalb des Clusters) eingehenden Netzwerkverkehr ▪ Zugriff initial gesperrt und muss explizit geöffnet werden ▪ Service = Gruppierung von Pods für einheitlichen Zugriff ▪ Es gibt unterschiedliche Arten (ClusterIP, NodePort, LoadBalancer, ExternalName) ▪ Sinnvoll insbesondere wenn ein Pod repliziert vorhanden ist und Last verteilt werden soll ▪ Namespace = virtuelles Cluster zur Gruppierung und Organisation ▪ Ermöglicht Ressourcen Verteilung ▪ Schränkt naming scope ein ▪ Ermöglicht einfache Zugriffskontrolle ▪ Bewahrt Überblick ▪ Diverse andere
  206. 24.11.2020 //// Seite 96 WPS – Workplace Solutions Container Management

    – Kubernetes - Finite Workloads ▪ Wie unterstützt mich Kubernetes bei der Bearbeitung von endlichen Arbeitspaketen? ▪ CronJobs erlauben es einen Job zu erstellen. Dieser wiederum startet Pods die die endlichen Arbeitspakete abarbeiten und sich dann selbst terminieren. ▪ CronJob ▪ definiert wann der Job gestartet wird (wie auch aus Linux cron jobs bekannt) ▪ definiert ob ein alter Job im Fehler-/Verzugsfall ersetzt wird, erhalten bleibt und der neue nicht startet oder ob ein weiterer parallel gestartet wird ▪ Job ▪ definiert welche Container gestartet werden und wie diese konfiguriert sind ▪ definiert wie mit failures umgegangen wird (Abbruch? Neustart? Wie oft?)
  207. 24.11.2020 //// Seite 97 WPS – Workplace Solutions Container Management

    – Kubernetes – Initialisierung 1 ▪ Jeder Pod hat eine Phase und mehrere Conditions ▪ Die Phase ist der aggregierte Gesamtzustand ▪ Conditions sind feingranular ▪ Haben Status: True, False oder Unknown ▪ Merken sich Details wie lastTransitionTime Pending Running Succeeded (erfolgreich terminiert) Failed Unknown (meistens Kommunikations problem) PodScheduled Ready Initialized Unschedulable Containers Ready
  208. 24.11.2020 //// Seite 98 WPS – Workplace Solutions Container Management

    – Kubernetes – Initialisierung 2 ▪ Container haben auch unterschiedliche States ▪ Grundlage für Zustand des umgebenden Pods Pending Running Terminated $ kubectl describe pod [POD_NAME] ... Containers: my-container: State: Terminated Reason: Completed Exit Code: 0 Started: Wed, 30 Jan 2019 11:45:26 +0530 Finished: Wed, 30 Jan 2019 11:45:26 +0530 ...
  209. 24.11.2020 //// Seite 99 WPS – Workplace Solutions Container Management

    – Kubernetes – Initialisierung 3: Probes ▪ Probes dienen dazu, den Zustand der Container im Pod festzustellen ▪ exec Befehl im Container mit erwartetem Status 0 ▪ TCP-Socket-Check mit erwartetem offenem Port ▪ HTTP GET mit erwartetem Status-Code >= 200 && < 400 ▪ 2 Arten: Liveness Probe und Readiness Probe Liveness Probe • Bei Fehlschlag erst SIGTERM dann SIGKILL Readiness Probe • Bei Erfolg Aufnahme ins Loadbalancing • Bei Fehlschlag Entfernung aus Loadbalancing
  210. 24.11.2020 //// Seite 100 WPS – Workplace Solutions Cluster Management

    – Kubernetes – Placement 1/2 ▪ Der Kube Scheduler verteilt Pods auf Nodes ▪ Betrachtet dafür: ▪ Container Ressourcen Anforderungen (deswegen wichtig zu definieren!) ▪ Verfügbare Ressourcen der Nodes ▪ Konfigurierte Placement / Scheduling Policies ▪ Abhängigkeiten ▪ Placement / Scheduling Policies ▪ Es gibt ein Standard Set ▪ Dieses kann um eigene erweitert werden ▪ Es gibt filternde und sortierende policies
  211. 24.11.2020 //// Seite 101 WPS – Workplace Solutions Cluster Management

    – Kubernetes – Placement 2/2 ▪ Es kann mehrere Scheduler geben und ein Pod kann den gewünschten Scheduler in der Pod Spezifikation angeben ▪ Das Placement durch den Scheduler kann umgangen werden indem ein Pod eine Placement Node in der Spezifikation angibt ▪ Mittels der „Node Affinity“ können weitere Filter- und Sortierregeln für einen Pod spezifiziert werden ▪ Mittels „Pod Affinity“ und „Pod Antiaffinity“ können Pods spezifizieren ob sie möglichst auf gleiche Nodes oder möglichst verteilt platziert werden möchten ▪ Bei fast allen dieser Regeln wird spezifiziert ob sie auf das Scheduling und/oder die Execution beziehen ▪ Es gibt einen weiteren Opt-In Mechanismus für die Pod Platzierung namens „taints and tolerations“ ▪ Nodes definieren ein „taint“ (Makel) ▪ Nur Pods die eine „toleration“ (Toleranz) gegenüber diesen Makel haben werden platziert ▪ Dabei sind die Makel entweder „hard“ (keine Platzierung), „soft“ (Platzierung nur wenn notwendig) oder gar „evict“ (Bereits laufende Pods die keine Toleranz haben werden entfernt)
  212. 24.11.2020 //// Seite 102 WPS – Workplace Solutions ▪ Alles

    Kubernetes Objekte können über Dateien konfiguriert werden. Diese müssen dann nur noch dem Cluster mitgeteilt werden. Dies funktioniert i.d.R. über das Command-Line-Tool kubectl ▪ Es wird erst eine Konfigurationsdatei für jeden Context (verschiedene Stages, namespaces etc) angelegt ▪ Dann können Dateien „applied“ werden oder Zustände abgefragt werden Container Management – Kubernetes – Kubectl kubectl Kubernetes Cluster API deployment .yaml apply -f deployment.yaml
  213. 24.11.2020 //// Seite 103 WPS – Workplace Solutions Container Management

    – Kubernetes – Helm Helm ist ein Package Manager für Kubernetes ▪ Gruppierung / Kapselung mehrerer Kubernetes-Objekte in einem Helm-Chart ▪ Charts können in Repositories abgelegt, versioniert und verteilt werden ▪ Ermöglicht Templating
  214. 24.11.2020 //// Seite 108 WPS – Workplace Solutions Übung zu

    Kapitel 4 – Cloud Native Journey Der Controller von Happiness steht einem Betrieb in der Cloud äußerst skeptisch gegenüber. ▪ Wie gehen Sie damit um? Bauen Sie eine Cloud/No-Cloud-Brücke oder versuchen Sie ihn vom Betrieb in der Cloud zu überzeugen? ▪ Sammeln Sie Argumente und schlüssige Stichpunkte, mit denen Sie dem Controller seine Sorgen nehmen wollen. ▪ Mit Blick auf das Gesamtsystem: Welche Clouddienste würden Sie in Anspruch nehmen? ▪ Skizzieren Sie die Systemlandschaft und halten Sie Ihre Entscheidungen fest.
  215. 24.11.2020 //// Seite 5 WPS – Workplace Solutions Resilience in

    der Biologie Jede Zelle ist identisch aus einem unveränderlichen Bauplan (der DNA) erstellt
  216. 24.11.2020 //// Seite 6 WPS – Workplace Solutions Resilience in

    der Biologie Zellen können vervielfacht werden
  217. 24.11.2020 //// Seite 7 WPS – Workplace Solutions Zerstörung einer

    Zelle ist kein Problem Resilience in der Biologie
  218. 24.11.2020 //// Seite 8 WPS – Workplace Solutions Zerstörung einer

    Zelle ist kein Problem Resilience in der Biologie
  219. 24.11.2020 //// Seite 9 WPS – Workplace Solutions Der Körper

    kann sich selbst heilen Resilience in der Biologie
  220. 24.11.2020 //// Seite 10 WPS – Workplace Solutions Der Körper

    kann sich selbst heilen ... indem schadhafte Zellen erkannt werden Resilience in der Biologie
  221. 24.11.2020 //// Seite 11 WPS – Workplace Solutions Der Körper

    kann sich selbst heilen ... indem schadhafte Zellen erkannt und repariert werden? → Nein Resilience in der Biologie
  222. 24.11.2020 //// Seite 12 WPS – Workplace Solutions Der Körper

    kann sich selbst heilen ... indem schadhafte Zellen erkannt und zerstört werden! Resilience in der Biologie
  223. 24.11.2020 //// Seite 13 WPS – Workplace Solutions Der Körper

    kann sich selbst heilen ... indem schadhafte Zellen erkannt und zerstört werden ... und neue erzeugt werden Resilience in der Biologie
  224. 24.11.2020 //// Seite 14 WPS – Workplace Solutions Resilience Resilience

    ist vor allem die Fähigkeit zur Selbstheilung Man definiert, was der Soll-Zustand des Systems ist ▪Welche Services ▪In welcher Anzahl Das System behebt selbstständig Abweichungen vom Soll
  225. 24.11.2020 //// Seite 16 WPS – Workplace Solutions Vorbedingung: Automatisierung

    Absolute Vorbedingungen für Resilience: - Anwendungs-Blaupausen (z.B. Docker Images) - Infrastrukturautomatisierung - Apps müssen auf Skalierbarkeit ausgelegt sein - Service Discovery
  226. 24.11.2020 //// Seite 17 WPS – Workplace Solutions Um Probleme

    zu beheben, muss man sie zunächst erkennen →Monitoring ... und die richtigen Reaktionen ausführen Vorbedingung: Probleme erkennen und beheben Beides muss auf mehreren Ebenen geschehen
  227. 24.11.2020 //// Seite 19 WPS – Workplace Solutions Übersicht ▪

    Einstiegsprinzipien ▪ Isolation - Probleme, die lokal bestehen sollen sich nicht ausbreiten ▪ Latenzüberwachung – Latenzprobleme erkennen und behandeln ▪ Muster (Auswahl) ▪ Bulkhead (Isolation) ▪ Timeouts (Latenz) ▪ Fail Fast (Latenz) ▪ Circuit Breaker (Isolation) ▪ Fallback (Isolation) ▪ Redundanz (Isolation&Latenz)
  228. 24.11.2020 //// Seite 20 WPS – Workplace Solutions Bulkhead ▪

    Analogie zu den Schottwänden auf Schiffen ▪ Das System darf nicht als Ganzes kaputt gehen ▪ System wird in möglichst unabhängige Einheiten aufgeteilt (Failure Units) ▪ Bulkheads (Schottwand) trennen die Systeme ▪ Keine konkrete Implementierungsanweisung Wie passt das zu Microservices? Schott
  229. 24.11.2020 //// Seite 21 WPS – Workplace Solutions Bulkhead-Ebenen ▪

    Das Bulkhead-Muster sollte man auf mehreren Ebenen anwenden ▪ Prozesse über Container voneinander isolieren ▪ Fachlich und technisch autarke Bounded Contexts / Self-Contained Systems definieren ▪ Infrastruktur in getrennte Netze einteilen ▪ Unterschiedliche Cloud-Accounts für verschiedene Umgebungen nutzen ▪ Dadurch wird jeweils der „Blast Radius“ von Ausfällen, Fehlern und Angriffen reduziert Getrennte Cloud-Anbieter Getrennte Cloud-Accounts Getrennte (virtuelle) Netze, z.B. VPCs Getrennte Cluster Getrennte Namespaces im Cluster Getrennte Self-Contained Systems Getrennte VMs Getrennte Container Getrennte Prozesse
  230. 24.11.2020 //// Seite 22 WPS – Workplace Solutions Timeouts ▪

    Durch Timeouts blockiert synchrone Kommunikation nicht ▪ Timeouts für alle Ressourcen verwenden ▪ HTTP-Aufrufe ▪ DB-Aufrufe ▪ Threads ▪ Vorsichtig mit schnellen Retries ▪ Langsame Retries machen das Gesamtsystem robuster (Beispiel: Mailversand) ▪ Nachrichten müssen idempotent sein
  231. 24.11.2020 //// Seite 23 WPS – Workplace Solutions Fail Fast

    ▪ Beispiel ▪ Stehen in der Warteschlange ▪ Am Schalter Zurückweisung, Erst Formular XY ausfüllen ▪ Langsame Antworten sind schlimmer als keine Antworten ▪ Abgrenzung zu Timeouts (Zwei Seiten der Medaille) ▪ Timeouts ▪ Zur Absicherung des Systems gegen Fehler von Anderen ▪ Für Ausgangsnachrichten ▪ Fail Fast ▪ Zum Benachrichtigen, warum man eine Anfrage nicht bearbeiten kann ▪ Für Eingangsnachrichten Asterix erobert Rom
  232. 24.11.2020 //// Seite 24 WPS – Workplace Solutions Circuit Breaker

    ▪ Wie der Schutzschalter im Sicherungsschrank ▪ Wird auf Ressourcen angewendet ▪ Andere Microservices ▪ Thread Pools ▪ Connection Pools ▪ Ist der Schutzschalter geschlossen, arbeitet das System normal ▪ Ab einer bestimmten Anzahl/Frequenz an Fehlern öffnet sich der Schalter ➔Aufrufe werden sofort fehlerhaft beantwortet (fail fast) ▪ Nach Ruhezeit wird Schalter wieder geöffnet Schutzschalter
  233. 24.11.2020 //// Seite 25 WPS – Workplace Solutions Fallback ▪

    Strategie, wenn ein Fehler erkannt wurde ▪ Fehlerbehandlung sollte möglichst vollständig automatisiert erfolgen ▪ Beispiel: Schreibanfrage eines Benutzers per Webanwendung, langsame Datenbank ▪ Fallback Option 1: Fehler an den Benutzer. Bitte versuchen Sie es später ▪ Fallback Option 2: Command in eine Queue und asynchrone Bearbeitung ▪ Nicht: Sanduhr anzeigen Plan A B
  234. 24.11.2020 //// Seite 26 WPS – Workplace Solutions Redundanz ▪

    Systemteile redundant auslegen ▪ Failure Units ▪ Durch Redundanz werden unterschiedliche Szenarien adressiert ▪ Failover ▪ Latenz gering halten (Schnelle Antworten) ▪ Fehlererkennung, z.B. Flugzeug (Systeme sind dreifach ausgelegt) ▪ Lastverteilung
  235. 24.11.2020 //// Seite 29 WPS – Workplace Solutions Frameworks: Resilience4j

    ▪ Hystrix ist eine deprecated library ▪ Hystrix empfiehlt Resilience4j als Alternative ▪ Open Source ▪ Für Java 8+, da funktional ▪ Leichtgewichtig (nur eine transitive Abhängigkeit: Vavr) ▪ Arbeitet mit dem Decorator pattern -> requests können um modulare Funktionalitäten angereichert werden (retry, circuit breaker, …) ▪ Unterstützt hoch und niedrig frequentierte Systeme dadurch dass Daten nicht wie bei Hystrix in timed buckets geschrieben werden sondern in einen zeitunabhängigen Ringpuffer konfigurierbarer Größe
  236. 24.11.2020 //// Seite 30 WPS – Workplace Solutions Frameworks: Resilience4j

    – Beispiel Quelle: https://resilience4j.readme.io/docs/getting-started
  237. 24.11.2020 //// Seite 31 WPS – Workplace Solutions Weitere Alternativen

    ▪ Bisher wurden Frameworks als Beispiele vorgestellt ▪ Vorteil: ▪ Fein granulare Konfigurationsmöglichkeiten für jeden Service ▪ Nachteil: ▪ Kein „Big Picture“ ▪ Skaliert schlecht ▪ Aufwendig ▪ Möglicher Wildwuchs bei vielen Services ▪ Alternativ können beispielsweise Container Manager oder Service Meshes verwendet werden → folgende Kapitel
  238. 24.11.2020 //// Seite 33 WPS – Workplace Solutions Container Management

    – Kubernetes – ein kurzer Rückblick ▪ Bietet (unter anderem) ▪ Service discovery mit Lastverteilung ▪ Speicherorchestrierung ▪ Automatisierte Rollouts und Rollbacks ▪ Ressourcenverwaltung ▪ Selbst heilend ▪ Secret und Config Management ▪ Pod Placement ▪ Kann als deklarative state machine betrachtet werden ▪ Man definiert einen Wunschzustand via YAML Konfigurationsdateien ▪ Kubernetes versucht diesen Zustand zu erstellen und zu halten
  239. 24.11.2020 //// Seite 34 WPS – Workplace Solutions Container Management

    – Kubernetes – ein kurzer Rückblick ▪ Alle Container teilen sich ▪ Ressourcen ▪ Ein Netzwerk ▪ Ein Volume (Speicher) ▪ Pods ▪ Werden nach Bedarf skaliert ▪ Sollten möglichst wenige Container beinhalten ▪ Läuft auf einem Node, welcher Ressourcen bereitstellt ▪Pod Container 1 Haupt- anwendung Sidecar Container Sidecar Container 2
  240. 24.11.2020 //// Seite 36 WPS – Workplace Solutions Container Patterns

    Container Patterns Microservice Principles DDD Clean Code In Anlehnung an Kubernetes Patterns (Bilgin Ibryam, Roland Huss) S. 2 f
  241. 24.11.2020 //// Seite 37 WPS – Workplace Solutions Container Patterns

    - Überblick ▪ Single-Node Patterns ▪ Single-Container Pattern ▪ Sidecar/Sidekick Pattern ▪ Ambassador Pattern ▪ Adapter Pattern ▪ Init Container Pattern ▪ Multi-Node Patterns ▪ Leader election Pattern ▪ Work queue Pattern ▪ Scatter and gather Pattern ▪ Kubernetes Patterns ▪ Konfiguration ▪ Skalierung ▪ Disruption Strategies ▪ Controller und Operator Pattern
  242. 24.11.2020 //// Seite 38 WPS – Workplace Solutions ▪ Trennung

    zwischen Applikation und der Konfiguration ▪ Via ConfigMap ▪ kann in Umgebungsvariablen gesetzt oder in ein Volume gemounted werden ▪ Via Secret ▪ kann in Umgebungsvariablen gesetzt oder in ein Volume gemounted werden ▪ Werden nicht auf die Platte einer Node geschrieben sondern im Speicher gehalten (tempfs). ▪ Können Ende zu Ende verschlüsselt werden, so dass sie nicht in etcd lesbar sind apiVersion: v1 kind: ConfigMap metadata: name: game-demo data: player_initial_lives: "3" ui_properties_file_name: "user- interface.properties" game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true Kubernetes Patterns – Konfiguration configmap.yaml:
  243. 24.11.2020 //// Seite 39 WPS – Workplace Solutions Kubernetes Patterns

    – Skalierung ▪ Kubernetes unterstützt Autoskalierung ▪ CPU Nutzung als Standard Metrik ▪ Andere Metriken können via Metrik Server (z.B. Prometheus) auch genutzt werden (z.B. Arbeitsspeicher, Anzahl der Anfragen, benutzerdefinierte Metriken) ▪ Die Skalierung von Pods wird von Strategien beeinflusst (siehe nächste Folie) Horizontal Pod Autoscaler (HPA) Vertical Pod Autoscaler (VPA) Cluster Autoscaler
  244. 24.11.2020 //// Seite 40 WPS – Workplace Solutions Kubernetes Patterns

    – Disruption Strategies ▪ Unterschiedliche Anwendungen haben unterschiedliche Anforderungen bzgl. Verfügbarkeit und Shutdown handling ▪ Es können sogenannte PodDisruptionBudgets (PDB) konfiguriert werden an den die prozentuale oder absolute Anzahl minimal verfügbarer oder maximal nicht verfügbarer Pods eines Sets definiert werden kann ▪ Beispiele ▪ 1: Zustandloses Frontend ▪ Ich möchte einfach nur genug Nutzer bedienen können ▪ Z.B. „minAvailable“ von 80% ▪ 2: Zustandsbehaftete skalierte Anwendung (z.B. Kafka oder etcd) ▪ Ich möchte Quorum und Replikationsbedingungen erfüllen ▪ Z.B. „maxUnavailable“ von 1 ▪ …
  245. 24.11.2020 //// Seite 41 WPS – Workplace Solutions Kubernetes Patterns

    – Controller und Operator Pattern ▪ Controller reagieren auf Abweichungen vom Soll-Zustand der Kubernetes-Objekte ▪ Beispiel: ReplicaSet-Controller ▪ Es ist ein ReplicaSet mit „replicas: 3“ spezifiziert ▪ Der ReplicaSet-Controller stellt fest, dass aktuell nur 2 Pods aktiv sind ▪ Der Controller startet einen weiteren Pod ▪ Operator ▪ Operator sind Controller, die benutzerdefinierte Objekte beobachten
  246. 24.11.2020 //// Seite 42 WPS – Workplace Solutions Container Patterns

    - Single-Container Pattern ▪ Oft Ausgangssituation ▪ Einfacher Einstieg ▪ Best Practice, solange der Container nur eine Verantwortlichkeit hat ▪ Anti-Pattern, wenn der Container mehrere hat ▪ Z.B. Webserver + Log Prozessor ▪Pod Container 1 Haupt- anwendung
  247. 24.11.2020 //// Seite 43 WPS – Workplace Solutions Container Patterns

    – Sidecar/Sidekick Pattern - Erklärung ▪ Erweitern den Hauptcontainer um neue Funktionalität ▪ Es wird ein (meist technischer) Container neben dem Applikationscontainer ausgeführt ▪ Sinvoll für die Trennung von fachlichen Aufgaben (Applikationscontainer) und technischen Aufgaben (sidecar) ▪ Sidecar einfach austauschbar ▪ Beispiele: Log Processor Circuit Breaker Traffic Shifting Fault Injection
  248. 24.11.2020 //// Seite 44 WPS – Workplace Solutions Container Patterns

    – Sidecar/Sidekick Pattern - Kommunikation ▪ Kommunikation z.B. über geteiltes Volume oder lokales Netzwerk ▪ Beispiel: ▪ Anwendung schreibt logs einfach aufs Volume, wie lokal ▪ Sidecar liest logs und schickt sie an zentrale Sammelstelle weiter ▪ Die Anwendung weiß nichts von der Komplexität der Weiterleitung / dem zentralen Log Sammler ▪ Anwendung wurde erweitert ohne angepasst zu werden ▪Pod Container 1 Haupt- anwendung Sidecar Container Log Prozessor geteiltes Volume
  249. 24.11.2020 //// Seite 45 WPS – Workplace Solutions Container Patterns

    – Sidecar/Sidekick Pattern - Vorteile ▪ Modularisierung ▪ Höhere Kohäsion, geringere Kopplung ▪ Standardisierung ▪ Rekonfiguration ohne Deployment möglich ▪ Einfache Wiederverwendung
  250. 24.11.2020 //// Seite 46 WPS – Workplace Solutions Container Patterns

    – Adapter Pattern ▪ Standardisierung unterschiedlicher Container Outputs ▪ eine wiederverwendbare Lösung ▪ Erweiterung / Spezifizierung des Sidecar Patterns ▪ Beispiel: ▪ Logs / Metriken aus vielen Anwendungen in ein Standardformat bringen ▪ Konkreter: ▪ Metriken sind in proprietärem Formaten in Datei vorhanden ▪ Prometheus benötigt Webschnittelle die gecrawlt werden kann ▪ Für Serviceübergreifende Dashboards / Analysen wird einheitliches Format benötigt ▪ Adapter Sidecar liest Datei, formatiert in Standardformat und bietet die Metriken über Webserver zum crawlen an
  251. 24.11.2020 //// Seite 47 WPS – Workplace Solutions Container Patterns

    – Ambassador Pattern - Erklärung ▪ Vor- / Nachgeschalteter Proxy ▪ Empfängt allen ein- und ausgehenden Netzwerkverkehr ▪ Kann diesen überwachen und manipulieren ▪ Bietet einfache Schnittstelle für Hauptcontainer ▪ Beispiele: ▪ Cache Zugriff (lokal simpler Memcached, in Produktion ein verteiltes etcd) ▪ Client Side Service Discovery ▪ Connection-Handling / Resilience (Circuit Breaker, Timeout, Retries, …) Ambassador = BotschafterIn, RepräsentantIn, GesandteR
  252. 24.11.2020 //// Seite 48 WPS – Workplace Solutions Container Patterns

    – Ambassador Pattern - Vorteile ▪ Abstraktion von Servermenge, für die Applikation ist nur ein Server sichtbar ▪ Einfaches Interface für den Aufruf anderer Services ▪ Simplifizierung da lokal und in Cloud über das lokale Netzwerk kommuniziert wird ▪ Trennt Konfiguration und Anwendungslogik ▪ Vermindert Komplexität in der Hauptanwendung ▪ Kann wiederverwendet werden ▪ Hauptanwendung ist nicht mehr an bestimmte Bibliotheken gebunden (z.B. Hystrix, resilience4j)
  253. 24.11.2020 //// Seite 49 WPS – Workplace Solutions Container Patterns

    – Init Container Pattern ▪ Wenn eine Initialisierung der Hauptanwendung notwendig ist ▪ Datenbank Schema / Migration ▪ Rechte auf Betriebssystem ▪ Oft sind besondere Rechte oder Werkzeuge zur Initialisierung notwendig, welche im laufenden Betrieb nicht vorhanden sein sollten ▪ Init Container werden vor anderen und sequentiell gestartet. Wenn alle erfolgreich durchgelaufen sind werden die anderen gestartet (diese laufen i.d.R. alle parallel)
  254. 24.11.2020 //// Seite 50 WPS – Workplace Solutions Multi-Node Container

    Patterns – Leader election Pattern ▪ Problem: Replication / Sharing among nodes, nicht idempotente Aufgaben ▪ Leader auswählen ▪ Logik der Leader Election aus Applikation heraushalten ▪ Nicht an eine Programmiersprache gebunden ▪ Beispiel Kubernetes: ▪ Erster Pod versucht einen Endpoint zu erstellen und diesem ein Label zu verpassen mit seiner id in einer leader property, einer lease time und einem Zeitstempel der letzten Aktualisierung. Andere pods prüfen das label regelmäßig und versuchen sich selbst als leader einzutragen wenn die lease abgelaufen ist
  255. 24.11.2020 //// Seite 51 WPS – Workplace Solutions Multi-Node Container

    Patterns – Work Queue design Pattern ▪ Ist ein sogenanntes „Batch Computational Pattern“, was bedeutet, dass es ein kurzläufiges Verarbeiten großer Datenmengen ist und kein dauerhaftes Verarbeiten. Beispiele: ▪ Tägliche Reports erstellen ▪ Aggregationen über Daten erstellen ▪ Video Dateien transkodieren ▪ Vorgehen: ▪ Große Aufgabe in unabhängige „Work Items“ splitten ▪ Evtl Container / Pods spawnen ▪ Arbeit verteilen Work Queue Manager Worker Worker Worker Work items Work item Work item Work item
  256. 24.11.2020 //// Seite 52 WPS – Workplace Solutions Multi-Node Container

    Patterns – Scatter and gather Pattern ▪ Problem: Eine ressourcenintensive Anfrage soll schnell beantwortet werden ▪ Lösung: ▪ Aufteilung der zu erledigenden Aufgabe in Teilaufgaben ▪ Aufteilung der Pods in einen Leader und mehrere Follower ▪ Leader verteilt Teilaufgaben an Follower ▪ Follower melden Teilergebnisse ▪ Leader berechnet und meldet Gesamtergebnis aus Teilergebnissen ▪ Skalierung auf Ebene der Zeit durch Parallelisierung einer Aufgabe im Vergleich zu ▪ Skalierung auf Ebene der Verarbeiteten requests pro Zeit ▪ Durch Skalierung der verfügbaren Nodes / Pods ▪ Skalierung auf Ebene der Datenmenge ▪ Durch sharding der Daten
  257. 24.11.2020 //// Seite 53 WPS – Workplace Solutions Multi-Node Container

    Patterns – Scatter and gather Pattern – Ein Beispiel ▪ Thalia macht eine Suchanfrage über alle Bücher um solche zu filtern, welche ein bestimmtes Wort beinhalten ▪ Mögliche klassische Lösungen wären: ▪ Mehr Ressourcen: bessere CPU / mehr Cores, schnellere Festplatten ▪ Indizierung oder Caching ▪ Scatter and gather (kann natürlich mit klassischem Vorgehen kombiniert werden): ▪ Teilt die zu durchsuchenden Dokumente in Gruppen und überträgt jedem Follower eine Gruppe ▪ Sammelt und vereint die Teilergebnisse ▪ Antwortet dem Anfragenden Leader Follower Follower Follower Alle Dokumente Einige Dokumente Einige Dokumente Einige Dokumente
  258. 24.11.2020 //// Seite 54 WPS – Workplace Solutions Multi-Node Container

    Patterns – Scatter and gather Pattern - Diskussion ▪ Performanzbetrachtung: Wie viele Follower sind am effektivsten? ▪ Jeder Follower reduziert die Verarbeitungsdauer (wenn wir davon ausgehen, dass die Aufgabe so klein schneidbar ist, was im vorherigen Beispiel solange gegeben ist wie #Follower < #Bücher) ▪ Dennoch wird durch jeden Follower ein overhead erzeugt ▪ Netzwerkverkehr, Request parsing, Deployment, … ▪ Weiterhin gibt es das sogenannte „straggler“ (Nachzügler) Problem, denn da der Leader auf alle Follower warten muss entscheidet der langsamste Follower über die Gesamtlaufzeit. ▪ Man stelle sich vor die Latenz beträgt in einem von 100 Requests 2 Sekunden und in allen anderen Fällen nur wenige ms ▪ Bei einem Follower hat man zu 1% eine Gesamtdauer von mindestens 2 Sekunden ▪ Bei 100 Followern hat man zu etwa 63% eine Gesamtdauer von mindestens 2 Sekunden (1- 0,99^100) ▪ Gleiches Problem bei der Verfügbarkeit, denn die Nicht-Verfügbarkeit steigt mit der Anzahl der Follower
  259. 24.11.2020 //// Seite 56 WPS – Workplace Solutions Resilience im

    Service Mesh – Beispiel Istio Traffic control Conditional Rate Limits Traffic Shifting Content based routing Sicherheit TLS Terminierung mTLS Resilience Timeouts Retries Circuit breakers Monitoring Tracing Logging Dashboards
  260. 24.11.2020 //// Seite 57 WPS – Workplace Solutions Resilience im

    Service Mesh – Beispiel Istio – Architektur ▪ Besteht aus ▪ Control Plane ▪ Pilot (verteilt Konfiguration auf Proxies) ▪ Mixer (nimmt Telemetriedaten entgegen) ▪ Citadel (verteilt Zertifikate an Proxies) ▪ Galley (überprüft Konfiguration) ▪ Nicht alle verpflichtend und es gibt weitere Zusatzdienste (ingress, egress, …) ▪ Data Plane ▪ Envoy Proxies als Sidecars (steuern und berichten) Istio Control Plane (Pilot, Mixer, Citadel, …) Pod A Container Container Envoy Anwendung Pod B Container Container Envoy Anwendung
  261. 24.11.2020 //// Seite 58 WPS – Workplace Solutions Resilience im

    Service Mesh – Beispiel Istio – Vor- und Nachteile ▪ Vorteile ▪ Quasi geschenkte Resilience (in K8S sehr einfach zu installieren) ▪ Trennung von Applikationslogik und Resilience ▪ Exzessive Monitoring Möglichkeiten (Grafana ist bereits inklusive) ▪ Einfache Steuerung ▪ Nachteile ▪ Latenz, CPU, Speicher ▪ Komplexität (weiterer Layer) ▪ Ein paar Probleme z.B. bei mTLS Verschlüsselung kann ein kubelet keine healtchecks mehr auf dem Standard Weg ausführen
  262. 24.11.2020 //// Seite 59 WPS – Workplace Solutions Übung zu

    Kapitel 5 – Hilfreiche Muster ▪ Unter Einbeziehung Ihrer bisherigen Ergebnisse, welche Resilienzmuster wären hilfreich um einen adäquaten Betrieb der Systeme zu gewährleisten? ▪ Diskutieren Sie mögliche Ansätze in der Gruppe und begründen Sie ihre Entscheidung
  263. 24.11.2020 //// Seite 2 WPS – Workplace Solutions Systemqualität Qualitätsmetriken

    dienen als Leitplanken für den Deploymentprozess und das Monitoringsetup
  264. 24.11.2020 //// Seite 3 WPS – Workplace Solutions Produktqualität nach

    DIN/ISO 25010 (früher 9126) • Qualität von Softwaresystemen wird immer bezogen auf Eigenschaften oder Merkmale. Die explizite Beachtung der relevanten Qualitätsmerkmale ermöglicht die Langlebigkeit der Anwendung! • Es gibt innere und äußere Qualitätsmerkmale Funktionalität Eignung Verwendbarkeit Genauigkeit Interoperabilität Sicherheit Zuverlässigkeit Reife Fehlertoleranz Ausfallsicherheit Datensicherheit Benutzbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Attraktivität Effizienz Zeitverhalten Ressourcennutzung Sicherheit Integrität Vertraulichkeit Nachweisbarkeit Authentizität Verantwortlichkeit Kompatibilität Austauschbarkeit Interoperabilität Compliance Wartbarkeit Analysierbarkeit Änderbarkeit Erweiterbarkeit Stabilität Testbarkeit Portierbarkeit Anpassbarkeit Installierbarkeit Ersetzbarkeit Konfigurierbarkeit Eigenschaften Merkmale
  265. 24.11.2020 //// Seite 4 WPS – Workplace Solutions Architekten sind

    Diplomaten und Akrobaten Flexibilität → Standardisierung Komplexität → Einfachheit Kosten & Termine → Leistung Neue Technologie → Etablierte Technologie Minimale Schnittstellen → Enge Integration Strikte Kontrolle → Agile Entscheidungen Top-Down- Plannung → Bottom-Up- Realisierung Kosten Q Q Q Q Q Wartbarkeit Performance Einfachheit Flexibilität Time-to-Market Fehlertoleranz Q Q Skalierbarkeit Lösung Q Q Standardisierung
  266. 24.11.2020 //// Seite 5 WPS – Workplace Solutions Qualitätsbaum (utility

    tree) & Szenarien ▪ Ein Qualitätsbaum konkretisiert Qualitätsmerkmale ▪ Allgemeine Merkmale weiter links, spezielle Anforderungen rechts ▪ Wird in kleinen Workshops entwickelt ▪ erst Brainstorming dann Organisation der Qualitätsmerkmale in Baum spezifische Qualität Performance Erweiterbarkeit Verfügbarkeit Latenz Durchsatz Neue Middleware Neue Produktkategorie bei Hardwarefehler bei Bedienfehler Szenario Szenario
  267. 24.11.2020 //// Seite 6 WPS – Workplace Solutions Dokumentation von

    Qualität - Szenarien ▪ Qualitätsmerkmale können durch Szenarien beschrieben und Qualität so definiert werden ▪ Szenarien beschreiben, was beim Eintreffen eines Stimulus auf ein System in bestimmten Situationen geschieht ▪ Die Szenarien beschreiben konkrete Anforderungen bzgl. einzelner Qualitätsmerkmale (z.B. zu Performance oder Verständlichkeit) ▪ 3 Arten von Szenarien: ▪ Anwendungsszenarien beschreiben, wie das System auf einen bestimmten Auslöser reagieren soll ▪ Änderungsszenarien beschreiben eine Modifikation des Systems oder seiner Umgebung ➢Deployments ➢Infrastrukturänderungen ▪ Stress- oder Grenzszenarien beschreiben, wie das System auf Extremsituationen reagiert → Szenarien sind die Grundlage um die Qualität von Architekturen zu bewerten
  268. 24.11.2020 //// Seite 7 WPS – Workplace Solutions Szenarien ▪

    Bestandteile von Szenarien: ▪ Auslöser (Stimulus) ▪ Zusammenarbeit des auslösenden Stakeholders mit dem System ▪ Quelle des Auslösers ▪ Woher stammt der Auslöser (intern, extern, Benutzer, Angreifer) ▪ Umgebung ▪ Zustand des Systems zum Zeitpunkt des Auslösers ▪ Systembestandteil ▪ Welcher Bestandteil ist betroffen ▪ Antwort ▪ Wie reagiert das System ▪ Antwortmetrik ▪ Wie kann die Antwort gemessen/bewertet werden
  269. 24.11.2020 //// Seite 8 WPS – Workplace Solutions Szenarien -

    Beispiele Performanz: „Die Antwort auf eine Angebotsanfrage muss Endbenutzern im Regelbetrieb in weniger als 5 Sekunden angezeigt werden. Im Betrieb unter Hochlast (Lastspitzen) darf eine Antwort bis zu 15 Sekunden dauern, in diesem Fall ist ein entsprechender Hinweis anzuzeigen.“ Robustheit: „Bei Eingabe unzulässiger oder fehlerhafter Daten in die Eingabefelder muss das System entsprechende spezifische Hinweistexte ausgeben und danach im Normalbetrieb weiterarbeiten.“ Funktional: „Bei Benutzer-Eingabe eines Wertes in das Feld ‚Postleitzahl‘ wird automatisch der zugehörige Ort aus der Datenbank gelesen und im Feld ‚Wohnort‘ angezeigt.“
  270. 24.11.2020 //// Seite 10 WPS – Workplace Solutions Arbeitsorganisation „DevOps

    ist die Praxis von Betrieb und Entwicklung, im gesamten Software-Lebenszyklus, vom Design über die Entwicklung hin zur Produktion, zusammenzuarbeiten“ DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. – http://theagileadmin.com/what-is-devops/
  271. 24.11.2020 //// Seite 11 WPS – Workplace Solutions Definition DevOps

    DevOps ist eine Menge an Praktiken, die die Zeit vom Commit einer Änderung bis zur produktiven Inbetriebnahme reduzieren und gleichzeitig eine hohe Qualität sicherstellen. DevOps is a set of practices intended to reduce the time between commiting a change to a system and the change being placed into normal production, while ensuring high quality. DevOps A Software Architect‘s Perspective, Len Bass
  272. 24.11.2020 //// Seite 15 WPS – Workplace Solutions Der grundsätzliche

    Zielkonflikt DevOps viele+stabile Releases QA Ops sind langsam. QA sind nutzlos. Entwickler sind unpünktlich. Nie läuft es rund. Entwickler brauchen immer Extra- würstchen.
  273. 24.11.2020 //// Seite 16 WPS – Workplace Solutions Der grundsätzliche

    Zielkonflikt ▪ Entwicklung einer Kultur der (agilen) Zusammenarbeit ▪ Qualitätssicherung und Effizienz- steigerung durch Automatisierung von Entwicklungs-, QA- und Betriebs- aufgaben DevOps viele+stabile Releases QA Korrektheit Wenige Versionen
  274. 24.11.2020 //// Seite 18 WPS – Workplace Solutions Umgebungen Entwicklungs-

    umgebung Integrations- umgebung Stagingumgebung eingeschränkter Betrieb vollständiger Betrieb • Läuft meist auf Entwickler-Desktop • Log-Level ist sehr hoch • Läuft auf CI-Server • Komponenten werden erzeugt • Umgebung ist so nah an der Betriebs- umgebung wie möglich! • Komponente wird bei einigen Anfragen verwendet und überwacht • Komponente wird auf allen Instanzen in Produktion genommen unveränderte Komponente angepasste Konfiguration Minimale Test- Daten Produktive Daten Neu aufgesetzte, Minimale Test-Daten Realistische Daten
  275. 24.11.2020 //// Seite 20 WPS – Workplace Solutions Konfiguration der

    Umgebungen ▪ Konfiguration sollte immer nachvollziehbar sein ▪ Konfigurationsänderungen sollten reversibel sein ▪ Beides wird gefördert wenn sich die Konfiguration im Repository befindet ▪ Im Idealfall betreiben wir in jeder Umgebung das gleiche Artefakt ▪ Feature Toggles helfen das hinzu und wegnehmen einzelner Funktionen zentral zu steuern ▪ Features die noch nicht produktionsreif sind werden nur in den vorgelagerten Umgebungen aktiviert
  276. 24.11.2020 //// Seite 22 WPS – Workplace Solutions Arten von

    Feature Toggles https://martinfowler.com/articles/feature-toggles.html
  277. 24.11.2020 //// Seite 23 WPS – Workplace Solutions Umgebungen Entwicklungs-

    umgebung Integrations- umgebung Stagingumgebung eingeschränkter Betrieb vollständiger Betrieb Wurden Features Erwartungsgemäß umgesetzt? Test/Review auf Code- ebene Visuell richtig umgesetzt? Abnahme durch Kunde/Anwe nder Test in Real Life Funktionieren bereits bestehende Features noch?
  278. 24.11.2020 //// Seite 24 WPS – Workplace Solutions Wer oder

    Was installiert? ▪ Bis zur Produktivschaltung erfolgen mindestens 2-3 Installationen ▪ Erfolgen sie automatisiert oder manuell? ▪ Wer hat die Verantwortung? ▪ Wer oder was verifiziert den Erfolg einer Installation? ▪ Wer oder was benötigt und erhält Zugriff auf Produktivdaten? ▪ Wie erfolgen Akzeptanztests? ▪ Wer gibt das go für die Produktivschaltung?
  279. 24.11.2020 //// Seite 25 WPS – Workplace Solutions Deployment und

    Betrieb mit Containern Container und Container Manager bilden ein Rahmenwerk um Deployment, Betrieb und Monitoring zu standardisieren
  280. 24.11.2020 //// Seite 26 WPS – Workplace Solutions Von der

    Codebasis eines Microservices zum laufenden Verbund ▪ Wie wird der Code eines Microservice gebaut und lauffähig „installiert“? ▪ Das definiert die Container-Spec (z.B. Dockerfile)! ▪ Auf Basis der Container-Spec wird ein Image gebaut ▪ Das Image sollte im Betrieb weiterhin konfigurierbar bleiben z.B. durch Umgebungsvariablen ▪ Die Deployment-Spec beschreibt die Betriebsumgebung und Konfiguration des Containers. Z.B. Replica und Umgebungsvariablen Container- Spec Container- Spec Container- Spec Deployment-Specs
  281. 24.11.2020 //// Seite 27 WPS – Workplace Solutions Container-Spec mit

    Multi Stage Docker Build FROM golang:1.7.3 AS builder WORKDIR /go/src/github.com/alexellis/href-counter/ RUN go get -d -v golang.org/x/net/html COPY app.go . RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app . FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=builder /go/src/github.com/alexellis/href-counter/app . CMD ["./app"] https://docs.docker.com/develop/develop-images/multistage-build/
  282. 24.11.2020 //// Seite 28 WPS – Workplace Solutions Deployment-Specs teilen

    sich häufig in mehrere Aspekte ▪ Zusammensetzen der Einzelkomponenten ▪ Einbinden externer wie etwa einer Datenbank ▪ Umgebungsspezifische Konfiguration und Secrets bzw. Secret-Management Deployment-Spec Konfiguration der Umgebung ▪ Datenbank
  283. 24.11.2020 //// Seite 30 WPS – Workplace Solutions Application Lifecycle

    Management ▪ Wie machen wir folgende Dinge, wenn wir einen Container-Manager nutzen? ▪ Deployments ▪ Versionierte Container ▪ Versionierte Deployment-Spezifikationen ▪ Deployment-Strategien ▪ Zustandsbehaftete Anwendungen betreiben ▪ Zeitlich begrenzte Jobs ausführen
  284. 24.11.2020 //// Seite 31 WPS – Workplace Solutions Kubernetes Konzepte

    für Lifecycle Management Grundlage für alles: Pod Für typische, stateless Anwendungen: ▪ ReplicationController (ist deprecated) ▪ ReplicaSet ▪ Deployment Für zustandsbehaftete und nicht skalierbare Anwendungen: ▪ StatefulSet Für zeitlich begrenzte Jobs: ▪ Job ▪ CronJob Für Infrastrukturaufgaben: ▪ DaemonSet
  285. 24.11.2020 //// Seite 32 WPS – Workplace Solutions ▪ Definiert

    eine Menge gleichartiger Pods (=Replicas) mit einer gewünschten Anzahl ▪ ReplicaSet sorgt dafür, dass die Anzahl eingehalten wird ▪ Grundlage dafür: Liveness-Probe ▪ Wird meist nicht selbst erzeugt, sondern von höherer Abstraktion Deployment ReplicaSet apiVersion: apps/v1 kind: ReplicaSet metadata: name: frontend labels: app: guestbook tier: frontend spec: # modify replicas according to your case replicas: 3 selector: matchLabels: tier: frontend template: metadata: labels: tier: frontend spec: containers: - name: php-redis image: gcr.io/google_samples/gb-frontend:v3 Quelle: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
  286. 24.11.2020 //// Seite 33 WPS – Workplace Solutions ▪ Abstraktion

    über ReplicaSet, die auch Versionsverwaltung und Deployments übernimmt ▪ Wird sehr ähnlich wie ReplicaSet beschrieben ▪ Deklarative Beschreibung von Pod und Deployment-Strategie ▪ Verwaltet unter der Haube ReplicaSets und deren Historie ▪ Ändert man die spec.containers eines Deployments, so wird die Deploymentstrategie ausgeführt ▪ Dazu später mehr apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 Deployment Quelle: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
  287. 24.11.2020 //// Seite 34 WPS – Workplace Solutions ▪ StatefulSet

    eignet sich für zustandsbehaftete (verteilte) Anwendungen ▪ Beispiele: MySQL, MongoDB, ZooKeeper ▪ Garantiert: ▪ Vorhersagbare Identität & Reihenfolge der Instanzen ▪ At-Most-One: Jede Identität existiert maximal 1x zur Zeit ▪ Eigene Persistenz für jede Identität durch volumeClaimTemplates apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 3 # by default is 1 template: metadata: labels: app: nginx spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: k8s.gcr.io/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "my-storage-class" resources: requests: storage: 1Gi StatefulSet Quelle: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
  288. 24.11.2020 //// Seite 35 WPS – Workplace Solutions Versionierung 1/2

    ▪ Es gibt mehrere Ebenen, auf der wir die Container und Deploymentspezifikationen versionieren können ▪ Source Code können wir über Commits, Branches und Tags versionieren ▪ Deploymentspezifikationen können und sollten als yaml-Dateien im Git eingecheckt werden ▪ Docker Images können innerhalb eines Repositories mit einem Tag versehen werden, z.B. ▪ my-registry/my-image:1.0 ▪ my-registry/my-image:1.1
  289. 24.11.2020 //// Seite 36 WPS – Workplace Solutions Versionierung 2/2

    ▪ Deployments (das Kubernetes Konzept) halten eine “Rollout History“ mit Änderungsgrund vor $ kubectl rollout history deployment.v1.apps/nginx-deployment deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true ▪ Helm-Charts haben auch eine Version, die unabhängig von den darin genutzten Docker-Images ist apiVersion: v1 description: A single-sentence description of this project name: my-helm-chart version: 0.1.0
  290. 24.11.2020 //// Seite 38 WPS – Workplace Solutions Deployment Deployment

    bezeichnet den Vorgang, eine neue Version eines Services in eine Umgebung zu nehmen. Ziele eines Deployments ▪ Fehlerbehebung ▪ Service-Qualität verbessern ▪ neue Features Rechtliche Maßgaben beachten, ggf. menschlicher “Gatekeeper” notwendig. Bei minimalen Auswirkungen auf die Nutzer des Services! Entwicklungs- umgebung Integrations- umgebung Stagingumgebung eingeschränkter Betrieb vollständiger Betrieb
  291. 24.11.2020 //// Seite 39 WPS – Workplace Solutions Die Deployment-Pipeline

    https://martinfowler.com/bliki/DeploymentPipeline.html „One of the challenges of an automated build and test environment is you want your build to be fast, so that you can get fast feedback, but comprehensive tests take a long time to run. A deployment pipeline is a way to deal with this by breaking up your build into stages. Each stage provides increasing confidence, usually at the cost of extra time. Early stages can find most problems yielding faster feedback, while later stages provide slower and more through probing. Deployment pipelines are a central part of Continuous Delivery.“
  292. 24.11.2020 //// Seite 40 WPS – Workplace Solutions Continuous Integration,

    Delivery, Deployment Modultests ok? Integrationstests ok? Abnahme / Performance Tests ok? Betatests in Produktion ok? Entwicklungs- umgebung Integrations- umgebung Stagingumgebung eingeschränkter Betrieb vollständiger Betrieb Continuous Deployment Continuous Delivery Continuous Integration
  293. 24.11.2020 //// Seite 42 WPS – Workplace Solutions Einfachstes Deployment:

    Downtime ▪ Zugehörige und abhängige Systeme werden während des Deployments vom Netz genommen ▪ Ops müssen Nacht- oder Frühschichten schieben ▪ Devs sind zeitlich eingeschränkt ▪ unmöglich bei 24/7 Anforderungen
  294. 24.11.2020 //// Seite 44 WPS – Workplace Solutions ▪ Gesamte

    Produktivumgebung in Staging doppeln ▪ So identisch wie möglich ▪ Produktions- und Staging- Umgebungen wechseln sich ab Blau-/Grün-Deployment
  295. 24.11.2020 //// Seite 45 WPS – Workplace Solutions ▪ Gesamte

    Produktivumgebung in Staging doppeln ▪ So identisch wie möglich ▪ Produktions- und Staging- Umgebungen wechseln sich ab Blau-/Grün-Deployment
  296. 24.11.2020 //// Seite 46 WPS – Workplace Solutions ▪ Gesamte

    Produktivumgebung in Staging doppeln ▪ So identisch wie möglich ▪ Produktions- und Staging- Umgebungen wechseln sich ab Blau-/Grün-Deployment
  297. 24.11.2020 //// Seite 56 WPS – Workplace Solutions ▪ Risiko

    minieren: Neue Version erst bei einem Teil der Nutzer ausrollen ▪ Zufällig ausgewählt ▪ Zuerst interne, dann externe ▪ Nach Nutzerdaten ▪ Freiwillige (Beta-Test) ▪ Ziele ▪ Risikominimierung von Fehlern ▪ Kapazitätsplanung ▪ Nutzerverhalten (A/B-Tests) ▪ Alternativversionen parallel betreiben Eingeschränkter Betrieb Entwicklungs- umgebung Integrations- umgebung Stagingumgebung eingeschränkter Betrieb vollständiger Betrieb
  298. 24.11.2020 //// Seite 57 WPS – Workplace Solutions ▪ Risiko

    minieren: Neue Version erst bei einem Teil der Nutzer ausrollen ▪ Zufällig ausgewählt ▪ Zuerst interne, dann externe ▪ Nach Nutzerdaten ▪ Freiwillige (Beta-Test) ▪ Ziele ▪ Risikominimierung von Fehlern ▪ Kapazitätsplanung ▪ Nutzerverhalten (A/B-Tests) ▪ Alternativversionen parallel betreiben Eingeschränkter Betrieb Entwicklungs- umgebung Integrations- umgebung Stagingumgebung eingeschränkter Betrieb vollständiger Betrieb Fehler gibt es trotzdem! Dauerhaft: ▪ Monitoring und Vergleich mit historischen Daten ▪ Logging, das die Fehlerdiagnose vereinfacht ▪ Problemfälle zum Normalfall machen
  299. 24.11.2020 //// Seite 59 WPS – Workplace Solutions Das macht

    erst mit einer guten Monitoring-Infrastruktur Spaß!
  300. 24.11.2020 //// Seite 60 WPS – Workplace Solutions Vor- und

    Nachteile der Strategien 1. Downtime ▪ Sehr einfach! ▪ Ops müssen Nacht- oder Frühschichten schieben ▪ Devs sind zeitlich eingeschränkt ▪ unmöglich bei 24/7 Anforderungen 2. Blau/Grün-Deployment ▪ Ressourcen-Verbrauch ist höher (oder man nimmt die Staging-Umgebung) ▪ “Big Bang” beim Umschalten ▪ Rollback ist (fast) einfach ▪ (bereits im neuen Release angefallene Daten müssen ggf. nach Rollback gerettet werden) 3. Rollierendes Update ▪ Ressourcen kaum erhöht ▪ Konsistenzprobleme müssen bedacht werden ▪ komplizierter ▪ Rollback in der Mitte ist ein Problem
  301. 24.11.2020 //// Seite 62 WPS – Workplace Solutions ▪ Es

    kommt ein letzter Request der die Erstellung eines Users fordert. ▪ Dieser wird auch erzeugt und erhält die ID 1234. ▪ Unmittelbar danach schaltet der Router um und stellt Version 1.1 live Blau-/Grün-Deployment – Was ist mit den Daten? POST Request: CREATE USER “Hans Meier“
  302. 24.11.2020 //// Seite 63 WPS – Workplace Solutions ▪ Danach

    erfolgt ein GET Request der die User mit dem Namen „Hans Meier“ anfordert. ▪ Wie stellen wir sicher, dass der Hans Meier mit der ID 1234 auch in der Antwort enthalten ist? Blau-/Grün-Deployment – Was ist mit den Daten? GET Request: ALL USERS NAMED “Hans Meier“
  303. 24.11.2020 //// Seite 64 WPS – Workplace Solutions ▪ Viele

    Datenbanksysteme bieten die Möglichkeit Bi- Direktional zu synchronisieren Blau-/Grün-Deployment – Synchronisation der Datenbanken
  304. 24.11.2020 //// Seite 65 WPS – Workplace Solutions ▪ Beide

    Versionen gehen gegen einen Datenbankcluster und die Datenbank erhält mit der neuen Version konservative Änderungen ▪ Die Datenbank bleibt N-1 kompatibel. ▪ Das Konzept muss von Entwicklern verstanden sein und bei den Datenbankrefactorings berücksichtigt werden. Blau-/Grün-Deployment – Gemeinsame Datenbank 1.0 & 1.1
  305. 24.11.2020 //// Seite 66 WPS – Workplace Solutions Inkonsistenzen bei

    parallel betriebenen Versionen Beispiel während der Umstellung: Ich nutze den neuen Kino-Service, um einen neuen Saal anzulegen. Beim alten Kino-Service schlägt der selbe Aufruf fehl, weil das Feature fehlt! Lösungsansätze ▪ Klient weiß, mit welcher Version er spricht ▪ Neue Features erst nutzen, wenn alle Services ersetzt sind ▪ Vorwärts- und rückwärtskompatible Schnittstellen Auch für veränderte DB-Schemata gibt es Lösungsansätze. Alle Lösungen müssen von Software-Entwicklern umgesetzt werden!
  306. 24.11.2020 //// Seite 67 WPS – Workplace Solutions Deploymentstrategien umsetzen

    ▪ Downtime- und Rollierende Deployments sind direkt über Kubernetes-Deployments möglich über ▪ spec.strategy.type: Recreate bzw. ▪ spec.strategy.type: RollingUpdate ▪ Achtung: Das ältere, imperative kubectl rolling-update sollte man nicht mehr verwenden ▪ Blau/Grün-Deployments muss man ohne Service Mesh oder Knative händisch aus den Kubernetes- Bausteinen scripten ▪ Z.B. Durch die manuelle Nutzung von 2 ReplicaSets (1 Blau, 1 Grün) und einem vorgeschalteten Service, den man jeweils umschaltet
  307. 24.11.2020 //// Seite 68 WPS – Workplace Solutions Verantwortlichkeiten und

    Zugriffskontrolle ▪ Um eine hohe Autonomie einzelner Teams zu erreichen, ist es sinnvoll Infrastrukturgrenzen zwischen ihnen zu ziehen (s. Bulkhead-Muster aus Kapitel 5) ▪ Auch aus Sicherheitsgründen ist eine Abschottung sinnvoll ▪ Sorgt für einfaches Rechte-Management, denn innerhalb seiner „Zone“ kann einem Team volle Autorität gewährt werden ▪ Möglichkeiten: ▪ Bei Cloud-Provider 1 Sub-Account pro Team ▪ Eigene(r) Cluster oder Namespace pro Team ▪ Eigener Namespace im Cluster. Mit Ressource-Quotas können den Teams Grenzen gesetzt werden ▪ Trennung von Prod- und anderen Umgebungen auf verschieden Cloud-Accounts bzw. Cluster ▪ Es bleibt ein Trade-Off: Die Autonomie und Sicherheit erkauft man sich durch weniger Standardisierung und deutlich mehr Infrastrukturaufgaben pro Team
  308. 24.11.2020 //// Seite 69 WPS – Workplace Solutions Föderale Cloud-Accounts

    Haupt-Account Account Projekt 1 Account Projekt 2 Account Projekt 3 ▪ Jedes Projekt bekommt eigenen Cloud-Account → Bulkhead ▪ Team kann volle Kontrolle über eigenen Account bekommen ▪ Umsetzbar z.B. mit AWS Organizations ▪ Kosten sind einzeln nachvollziehbar, Rechnungen kommen im Haupt-Account zusammen ▪ Nutzer verwaltet man idealerweise nur einmal im Haupt-Account
  309. 24.11.2020 //// Seite 70 WPS – Workplace Solutions ▪ Diverse

    Möglichkeiten, Komponenten zu gruppieren: ▪ Tags für Cloud-Provider Ressourcen ▪ Kubernetes Labels und Namespaces ▪ Labels für fachliche/funktionale Gruppierung (Umgebung, App, SCS, Frontend/Backend/DB, Version) ▪ Empfohlene Labels nutzen ▪ Namespaces für Verantwortungsbereiche ▪ Helm Charts Best Practices zur Komponentengruppierung Quelle: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/ Key Description Example Type app.kubernetes.io/ name The name of the application mysql string app.kubernetes.io/ instance A unique name identifying the instance of an application wordpress-abcxzy string app.kubernetes.io/ version The current version of the application (e.g., a semantic version, revision hash, etc.) 5.7 .21 string app.kubernetes.io/ component The component within the architecture database string app.kubernetes.io/ part-of The name of a higher level application this one is part of wordpress string app.kubernetes.io/ managed-by The tool being used to manage the operation of an application helm string
  310. 24.11.2020 //// Seite 71 WPS – Workplace Solutions Monitoring Monitoring

    is the process of observing and recording state changes and data flow. Len Bass, Ingo Weber, Liming Zhu
  311. 24.11.2020 //// Seite 73 WPS – Workplace Solutions Allgemeine Ziele

    von Monitoring Fehler erkennen • aktuell & nachträglich Verschlechterung der Performance erkennen • einzelne Systeme & Verbund von Systemen Kapazitäten planen • kurz- & langfristig Reaktion der Nutzer verstehen • verschiedene Oberflächen & Kampagnen Sicherheitsverletzungen erkennen • sofort & nachträglich The purpose of computing is insight, not numbers. Richard Hamming
  312. 24.11.2020 //// Seite 74 WPS – Workplace Solutions Ebenen für

    Monitoring und Reaktionen Anwendung (z.B. Kubernetes Pods / Deployments) Infrastrukturknoten (z.B. Kubernetes Nodes oder EC2 Instanzen) Hardware
  313. 24.11.2020 //// Seite 75 WPS – Workplace Solutions Was muss

    beobachtet werden? ▪ Allgemein ▪ Eingaben (REST-Anfragen, Benutzerinteraktion, …) ▪ Ressourcen (CPU, Speicher, Queues, Thread-Pools, …) ▪ Ergebnisse (Transaktionen, Rechnungs-Auftrag, …) ▪ Es gibt fachliches und technisches Monitoring ▪ Technische Infrastruktur ▪ Betriebssystem ▪ Virtualisierte Hardware ▪ Kommunikation zwischen Anwendungen ▪ Anwendungen ▪ CI-Server, Deployment-Vorgänge, Skripte, … Anwendung (z.B. Kubernetes Pods / Deployments) Infrastrukturknoten (z.B. Kubernetes Nodes oder EC2 Instanzen) Hardware
  314. 24.11.2020 //// Seite 76 WPS – Workplace Solutions Monitoring ▪Health-Checks

    für Endpunkte definieren ▪z.B. durch Kubernetes Readiness- (schon voll da?) und Liveness-Probes (noch lebendig?) Reagieren ▪Scheduler checkt Health- Checks und trifft Entscheidungen ▪Abschießen ▪Skalieren ▪Rollback Ebene: Anwendung Anwendung Infrastrukturknoten Hardware
  315. 24.11.2020 //// Seite 77 WPS – Workplace Solutions Monitoring ▪Erkennen,

    wann ein Infrastrukturknoten unzureichende oder ungebrauchte Ressourcen hat ▪CPU, Memory, Disk I/O ▪Tools (Auswahl): ▪AWS Autoscaling Group + AWS CloudWatch ▪Kubernetes Cluster Autoscaler Addon Reagieren ▪Anzahl der Infrastrukturknoten erhöhen oder verringern Ebene: Infrastrukturknoten Anwendung Infrastrukturknoten Hardware
  316. 24.11.2020 //// Seite 78 WPS – Workplace Solutions Monitoring ▪Cloud-Anbieter

    warnt bei: ▪Rechner-Ausfällen ▪Abnutzung von Festplatten / Datenkorruption ▪Netz-Ausfällen Reagieren ▪Korrumpierte VMs migrieren Ebene: Hardware Anwendung Infrastrukturknoten Hardware
  317. 24.11.2020 //// Seite 79 WPS – Workplace Solutions Wie kann

    beobachtet werden? ▪ Datenbasis wird auch „Operations Database“, abk. OpsDB genannt (Nygard) ▪ Durch Persistenz können Aussagen über die Vergangenheit und Zukunft getroffen werden Big Data Systeme Business Intelligence Einbruchs- Erkennung … System 1 System 2 Anwendung Middleware Betriebssystem Anwendung Middleware Betriebssystem Monitoring System Datenbasis Visualisierung Alarm- auswertung Andere Systeme ohne agent Agent agenten- basiert extern Benutzer Tracking Logdateien Konfigurations- Management Metriken
  318. 24.11.2020 //// Seite 80 WPS – Workplace Solutions Agenten für

    das Monitoring laufen typischerweise als Sidecar oder DaemonSet
  319. 24.11.2020 //// Seite 81 WPS – Workplace Solutions OpsDB ▪

    Business Feature: Geschäftsprozess, Funktion, … ▪ Node: Dienst, Anwendung, Server, Datenbank, … ▪ Observation: Geben Auskunft über den Zustand eines Nodes ▪ Expectation: Erwartungen für Observation, Z.B. Maximale Durchlaufzeit ▪ Observation/Expectation Type: Klassifizieren Observations und Expectations OpsDB, Release IT!, Nygard (Quelle: Wikipedia)
  320. 24.11.2020 //// Seite 82 WPS – Workplace Solutions Historisch und

    Echtzeit ▪ Echtzeit-Monitoring ▪ Wie ist aktuell die Auslastung des Systems? ▪ Werden Schwellwerte überschritten? ▪ Grundlage für Alerting ▪ Historisches Monitoring ▪ Speicherung relevanter Kennzahlen ▪ System- und Anwendungslogdaten ▪ Erweiterte Möglichkeiten durch Datenanalyse ▪ Anomalieerkennung ▪ Langsam entstehende Ressourcenengpässe ▪ Nachbereitung von Ausfällen
  321. 24.11.2020 //// Seite 83 WPS – Workplace Solutions Korrelation von

    Daten ▪ Einzelsysteme werden überwacht, aber Gesamtprozess muss erkennbar bleiben ▪ Welche Log-Daten gehören zusammen? ▪ Komplexe Prozesse über mehrere Systeme verfolgen ▪ Sortieren nach Zeitstempel ist schwierig ▪ Uhrzeitabweichungen ▪ Latenzen ➢Ähnliche Zeitmessung durch NTP-Server (keine Garantie) ➢Totale Ordnung der Logs durch Vektorzeitstempel (aufwändig) ▪ Kontext ist wichtig! ▪ Welche VM? Welche Instanz? Welche Komponente?
  322. 24.11.2020 //// Seite 84 WPS – Workplace Solutions ▪ Kritisches

    Echtzeitmonitoring sollte vor allem durch Alarme geschehen, die automatisch bei der Verletzung definierter Metrik-Thresholds gesendet werden ▪ Typische Ziele: Mail-Verteiler, Slack-Channel Alerting Grafana-Alarm ab 85% Speicherauslastung einer Instanz
  323. 24.11.2020 //// Seite 85 WPS – Workplace Solutions Meta-Monitoring ▪

    Monitoring für das Monitoring System ▪ Drei Tage kommt kein Alert ▪ Ist alles gut? ▪ Oder ist das Monitoring System ausgefallen? ▪ Wir benötigen einen Mechanismus der Ausfälle und Leistungsengpässe am Monitoring-System aufdeckt Wer monitort eigentlich das Monitoringsystem?
  324. 24.11.2020 //// Seite 87 WPS – Workplace Solutions Wofür eigentlich

    Logging? ▪ Verhalten der Anwendung nachvollziehen ▪ Analyse… ▪ im Fehlerfall (wichtig: Exceptions zusammenhängend loggen) ▪ bei seltsamer Entwicklung der Metriken ▪ Eignen sich weniger gut um Metriken zu persistieren
  325. 24.11.2020 //// Seite 93 WPS – Workplace Solutions ElasticSearch ▪

    NoSQL DB ▪ CRUD über HTTP-Schnittstelle ▪ GET, PUT, POST, DELETE ▪ JSON-basierte Query Language Relationale DB ElasticSearch Database Index Table Type Row Document Column Field Schema Mapping SQL Query DSL GET /bank/_search { "query":{ "match" : { "city":„Hamburg" } } }
  326. 24.11.2020 //// Seite 94 WPS – Workplace Solutions Kibana ▪

    Webanwendung ▪ Grafische Oberfläche für ElasticSearch ▪ Werkzeuge um Visualisierungen und Dashboard zu definieren
  327. 24.11.2020 //// Seite 96 WPS – Workplace Solutions Logging und

    Datenschutz ▪ Aufgepasst beim Logging personenbezogener Daten! => DSGVO ▪ Falls personenbezogene Daten geloggt werden müssen, ist der Anwender zu informieren ▪ IP-Adressen können auch personenbezogene Daten sein!
  328. 24.11.2020 //// Seite 98 WPS – Workplace Solutions Tracing ▪

    Spezielle Art des Loggings ▪ Enthält Informationen zur Ablaufverfolgung ▪ Meldung beim Einsprung in eine Funktion ▪ Meldung beim Verlassen ▪ Ggf. mit Argumenten Stacktrace bei Exceptions
  329. 24.11.2020 //// Seite 99 WPS – Workplace Solutions Tracing und

    Microservice Microservice A Microservice B Microservice C ➔ Verteiltes Tracing
  330. 24.11.2020 //// Seite 102 WPS – Workplace Solutions ▪ Standardformat

    für Distributed Tracing ▪ Nutzt Nomenklatur und Ideen von Dapper ▪ Services nutzen API, um Traces zu erzeugen, strukturieren und mit Informationen zu versehen ▪ Laufzeit: Ein Tracer implementiert diese API und übermittelt Daten an Sammler ▪ Beispiele für Tracer: Zipkin, Jaeger, LightStep, Instana, … OpenTracing
  331. 24.11.2020 //// Seite 105 WPS – Workplace Solutions ▪ Neuere

    Alternative zu Zipkin ▪ Entstanden bei Uber auf Basis von Zipkin ▪ OpenTracing kompatibel ▪ OpenSource seit 2017 ▪ Standard Sidecar bei Istio und OpenShift Jaeger
  332. 24.11.2020 //// Seite 106 WPS – Workplace Solutions Jaeger Architektur

    https://www.jaegertracing.io/docs/1.16/architecture/
  333. 24.11.2020 //// Seite 108 WPS – Workplace Solutions Beispiel: Spring

    Sleuth mit Zipkin und LogStash Bildquelle: https://medium.com/swlh/distributed-tracing-in-micoservices-using-spring-zipkin-sleuth-and-elk-stack-5665c5fbecf
  334. 24.11.2020 //// Seite 109 WPS – Workplace Solutions Metriken „Metrik,

    ist eine Funktion, die eine Eigenschaft in einen Zahlenwert, auch Maßzahl genannt, abbildet“
  335. 24.11.2020 //// Seite 110 WPS – Workplace Solutions Arten von

    Metriken ▪ System ▪ Wie ist die CPU-Auslastung? ▪ Wie voll ist die Festplatte? ▪ Anwendung ▪ Wie viele Threads sind im Thread Pool? ▪ Wie ist die mittlere Antwortzeit eines Requests? ▪ Fachliche ▪ Wie viele Bücher wurden verkauft? ▪ Wie viele Benutzer sind angemeldet? ▪ Fachliches Monitoring ist historisch Aufgabe von BI und Controlling ▪ Warum betrachten wir es hier?
  336. 24.11.2020 //// Seite 111 WPS – Workplace Solutions Metriken aus

    Logs ▪ Logging = Protokollierung ▪ Metriken aufgrund von Log-Dateien aufsetzen ▪ Z.B.: Anzahl der 400er-Fehler im Apache-Log ▪ Aufgrund von Logs im eigenen System, Z.B.: Bestellung ausgeführt ▪ Problematisch! Kopplung zwischen Metrik und Log-Ausgabe
  337. 24.11.2020 //// Seite 112 WPS – Workplace Solutions Metrik Pipeline

    Anwendung Instrumentieren Erfassen Sammeln Samplen Persistieren Visualisieren ? ? ?
  338. 24.11.2020 //// Seite 113 WPS – Workplace Solutions Beispiel Metrik

    Pipeline Anwendung Instrumentieren Erfassen Sammeln Samplen Persistieren Visualisieren ? ? ?
  339. 24.11.2020 //// Seite 115 WPS – Workplace Solutions Logging vs

    Metriken Logging/Tracing Metriken Fehlersuche Monitoring Fehleranalyse Fehlererkennung Debugging Alerting Auditing Profiling
  340. 24.11.2020 //// Seite 117 WPS – Workplace Solutions Predictable Demands

    ▪ Benötigte Pod-Ressourcen sollte man unbedingt angeben. Sie sind Grundlage für: ▪ Berechnung der Clustergröße ▪ Platzierung der Pods ▪ Skalierung ▪ Arten benötigter Ressourcen: ▪ CPU ▪ RAM ▪ GPU ▪ Laufzeitabhängigkeiten ▪ PersistentVolumes über persistentVolumeClaim ▪ ConfigMaps ▪ Secrets
  341. 24.11.2020 //// Seite 118 WPS – Workplace Solutions ▪ requests

    definieren minimal benötigte Ressourcen ▪ Ist Grundlage für Scheduling der Pods auf Nodes ▪ limits definieren maximale Ressourcen ▪ Angabe beeinflusst, ob ein Pod als erstes oder letztes bei Problemen beendet wird 1. Pods ohne Ressourcen-Angabe (Best-Effort) 2. Pods mit requests != limits (Burstable) 3. Pods mit requests = limits (Guaranteed) Ressourcen-Profile apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: wp image: wordpress resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" Quelle: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container
  342. 24.11.2020 //// Seite 120 WPS – Workplace Solutions Nobody is

    perfect ▪ Was sind perfekte Systeme? ▪ Software ohne Fehler ▪ Hardware, die nie versagt ▪ Menschen, die immer die richtigen Entscheidungen treffen → Perfekte Systeme gibt es nicht → Es wird immer Fehler geben
  343. 24.11.2020 //// Seite 121 WPS – Workplace Solutions Stabilitätsansätze ▪

    A (Verfügbarkeit) soll maximiert werden ▪ Traditionell: MTTF maximieren, + ➔ A => 1 ▪ Redundante Hardware, Cluster, Vermeidung von Fehlern auf Softwareebene ▪ Geht davon aus, dass die Anwendung isoliert läuft ▪ Resilience Ansatz: MTTR minimieren, + ➔ A => 1 ▪ Fehler sind in verteilten Systemen der Normalfall, nicht die Ausnahme, und es ist nicht möglich, sie vorherzusagen. → Do not try to avoid failures. Embrace them.
  344. 24.11.2020 //// Seite 122 WPS – Workplace Solutions ▪ 1

    Maschine ▪ 99,9% verfügbar ▪ MTTF 1 Jahr ▪ MTTR 8 Stunden ▪ MTTF 15 Tage ▪ MTTR 8 Stunden Ausfallwahrscheinlichkeit ▪ MTTR 8 Stunden (HW repariert) ▪ MTTR 10 Minuten (VMs ziehen um) ▪ 24 Maschinen ▪ 99,9% verfügbar …
  345. 24.11.2020 //// Seite 123 WPS – Workplace Solutions Betroffene Applikationen

    ▪ Gleichzeitig fallen mehrere VMs / Service-Instanzen aus ▪ Die betroffenen Maschinen sind nicht “logisch” begrenzt, weil VMs flexibel auf den Hypervisorn verschoben werden 1 Hypervisor fällt aus, was passiert? Hypervisors Virtuelle Maschinen
  346. 24.11.2020 //// Seite 124 WPS – Workplace Solutions Netzwerk-Partition Konsistenz

    + Verfügbarkeit + Partitionstoleranz ist unmöglich! (CAP Theorem) Beispiele: ▪ DNS – Verfügbar und Partitionstolerant ▪ SQL-DBs – Konsistent und Verfügbar ▪ Banking-Anwendungen – Konsistent und Partitionstolerant switch switch
  347. 24.11.2020 //// Seite 125 WPS – Workplace Solutions Risiken und

    Nebenwirkungen ▪ höhere Latenzen kommen leichter und öfter vor ▪ VMs können sich gegenseitig beeinflussen (z.B. Zeit klauen) ▪ Ausfälle einzelner VMs kommen öfter vor, weil es viele sind ▪ Hardware-Fehler treffen viele VMs gleichzeitig ▪ Daten-Konsistenz muss bedacht werden ▪ Cluster-Dateisysteme müssen bedacht werden ▪ Viel mehr VMs zu managen
  348. 24.11.2020 //// Seite 126 WPS – Workplace Solutions Übung zu

    Kapitel 6 – Development, CI/CD und Betrieb ▪ Wie funktioniert das Deployment? Bei welchem Bounded Context reicht Downtime, wo gibt es komplexere Strategien? ▪ Skizzieren Sie, welche Pipeline(s) für das System existieren ▪ Welche Umgebungen existieren für die Systeme? ▪ Anhand welcher Kriterien wird eine Version in die nächste Umgebung überführt? ▪ Angenommen Sie sollen ein Monitoringsystem aufsetzen. Welche fachlichen Aspekte sollten betrachtet werden?
  349. 24.11.2020 //// Seite 2 WPS – Workplace Solutions Don‘t Repeat

    Yourself (DRY) ▪ Repetitive Konfigurationsarbeit soll nicht manuell gemacht werden, weil ▪ Konfigurationen nur schwer nachzuvollziehen und zu überwachen sind ▪ es die Änderbarkeit erschwert, da an vielen Rechnern Änderungen nachgezogen werden müssen. ▪ es zu Inkonsistenzen führen kann. ▪ so Rollbacks nur schwer möglich sind ▪ Auch „Single Point of Truth“ und „Single Point of Maintenance“
  350. 24.11.2020 //// Seite 3 WPS – Workplace Solutions Merkmale guter

    Bereitstellung Automatisierte Bereitstellung Nachvollziehbarkeit Befehle sollen wiederholbar sein Befehle sollen protokolliert sein Befehle sollen Standardisiert sein Regression Qualitätssicherung, automatisierte Tests Monitoring Rollback, Roll Forward Regelmäßigkeit If it hurts, do it more often Infrastructure as Code: verwalte alle Skripte im selben Repository! Diese Skripte müssen genauso Qualitätsgesichert werden wie Code. Bei manueller Arbeit sind diese Merkmale schwer zu erreichen. Bereitstellungszeit reduzieren Koordinierungs-Aufwand reduzieren Zeit für andere Aufgaben frei machen
  351. 24.11.2020 //// Seite 4 WPS – Workplace Solutions Infrastructure as

    Code Infrastrukturautomatisierung mit Terraform & Co
  352. 24.11.2020 //// Seite 5 WPS – Workplace Solutions Infrastructure as

    Code Im Grunde wie Softwareentwicklung Code Versions- kontrolle Code Review Integration Deployment Text Editor Git o.ä. Review Tools Syntax Validierung Cloud Provider
  353. 24.11.2020 //// Seite 6 WPS – Workplace Solutions Infrastructure as

    Code ▪ Die Infrastruktur im Code beschreiben ▪ Den Infrastruktur-Code im Repository einchecken ▪ Code muss getestet werden, z.B. mit Serverspec
  354. 24.11.2020 //// Seite 7 WPS – Workplace Solutions Tools für

    Infrastrukturautomatisierung und Bereitstellung ▪ Push vs. Pull ▪ Fokus auf Infrastruktur, Provisionierung oder beides
  355. 24.11.2020 //// Seite 9 WPS – Workplace Solutions Bereitstellung: Push

    vs. Pull Push • Zentrale Konfiguration • Einfacheres Modell Pull • Jede Instanz ist selbst verantwortlich für Updates • Flexibler skalierbar auf mehrere Admins Provisio- nierung Provisio- nierung
  356. 24.11.2020 //// Seite 10 WPS – Workplace Solutions Chef ▪

    Pull-basiert ▪ Nodes brauchen Chef Client Agent ▪ Ruby Cookbooks und Recipes als Grundelemente Workstation Chef Server Node Node Node
  357. 24.11.2020 //// Seite 11 WPS – Workplace Solutions Beispiel Ansible:

    Konzepte Inventory • Definiert Hosts und Gruppen von Hosts Playbook • Weist Gruppen Provisionierungen zu • Direkt, oder • Durch Role Role • Beschreibung mehrerer Tasks, die nacheinander ausgeführt werden sollen
  358. 24.11.2020 //// Seite 12 WPS – Workplace Solutions Ansible Beispiel

    - name: Install Mysql package yum: name={{ item }} state=installed with_items: - mysql-server - MySQL-python - libselinux-python - libsemanage-python - name: Configure SELinux to start mysql on any port seboolean: name=mysql_connect_any state=true persistent=yes when: sestatus.rc != 0 - name: Create Mysql configuration file template: src=my.cnf.j2 dest=/etc/my.cnf notify: - restart mysql - name: Start Mysql Service service: name=mysqld state=started enabled=yes
  359. 24.11.2020 //// Seite 13 WPS – Workplace Solutions Beispiel Ansible:

    Inventory [controllers] control01.baremetal control02.baremetal [nodes] node01.baremetal node02.baremetal [baremetals:children] controllers nodes ▪ Das Inventory definiert Hosts und Gruppen von Hosts ▪ control01.baremetal ist ein Host ▪ controllers und nodes sind Gruppen ▪ baremetals enthält alle Hosts, die in controllers und nodes enthalten sind
  360. 24.11.2020 //// Seite 14 WPS – Workplace Solutions Beispiel Ansible:

    Playbook und Roles --- hosts: baremetals roles: - base Playbook Role „base“ --- # Base Setup - name: Install CenterDevice Root CA Certificates sudo: true copy: src=usr/local/share/ca-certificates/{{ item }} dest=/usr/local/share/ca-certificates/{{ item }} with_items: - centerdevice-intermediate-ca.crt - centerdevice-root-ca.crt - name: Update root certificate database sudo: true command: update-ca-certificates Quelle: Cloud Fibal 2, Kapitel „Ansible“
  361. 24.11.2020 //// Seite 15 WPS – Workplace Solutions Beispiel Ansible:

    Ausführung der Bereitstellung ansible-demo-scripts$ ansible-playbook -u local-admin --ask-sudo-pass -i inventories/hosts.baremetal site.yml sudo password: ****** PLAY [baremetals] ************************************************************* GATHERING FACTS *************************************************************** ok: [control02.baremetal] ok: [node02.baremetal] ok: [control01.baremetal] ok: [node01.baremetal] TASK: [base | Install CenterDevice Root CA Certificates] ********************** changed: [control01.baremetal] => (item=centerdevice-intermediate-ca.crt) changed: [control02.baremetal] => (item=centerdevice-intermediate-ca.crt) changed: [node01.baremetal] => (item=centerdevice-intermediate-ca.crt) changed: [node02.baremetal] => (item=centerdevice-intermediate-ca.crt) changed: [node02.baremetal] => (item=centerdevice-root-ca.crt) changed: [control01.baremetal] => (item=centerdevice-root-ca.crt) changed: [node01.baremetal] => (item=centerdevice-root-ca.crt) changed: [control02.baremetal] => (item=centerdevice-root-ca.crt) TASK: [base | Update root certificate database] ******************************* changed: [control02.baremetal] changed: [node01.baremetal] changed: [control01.baremetal] changed: [node02.baremetal] Quelle: Cloud Fibal 2, Kapitel „Ansible“
  362. 24.11.2020 //// Seite 16 WPS – Workplace Solutions Beispiel Ansible:

    Erneute Ausführung ansible-demo-scripts$ ansible-playbook -u local-admin --ask-sudo-pass -i inventories/hosts.baremetal site.yml sudo password: ****** PLAY [baremetals] ************************************************************* GATHERING FACTS *************************************************************** ok: [control02.baremetal] ok: [node02.baremetal] ok: [control01.baremetal] ok: [node01.baremetal] TASK: [base | Install CenterDevice Root CA Certificates] ********************** ok: [control01.baremetal] => (item=centerdevice-intermediate-ca.crt) ok: [control02.baremetal] => (item=centerdevice-intermediate-ca.crt) ok: [node01.baremetal] => (item=centerdevice-intermediate-ca.crt) ok: [node02.baremetal] => (item=centerdevice-intermediate-ca.crt) ok: [node02.baremetal] => (item=centerdevice-root-ca.crt) ok: [control01.baremetal] => (item=centerdevice-root-ca.crt) ok: [node01.baremetal] => (item=centerdevice-root-ca.crt) ok: [control02.baremetal] => (item=centerdevice-root-ca.crt) TASK: [base | Update root certificate database] ******************************* changed: [control02.baremetal] changed: [node01.baremetal] changed: [control01.baremetal] changed: [node02.baremetal] Quelle: Cloud Fibal 2, Kapitel „Ansible“ Idempotenz • Mehrfache Ausführung führt zu gleichem Zustand
  363. 24.11.2020 //// Seite 18 WPS – Workplace Solutions Terraform ▪

    Cloud-Infrastruktur mit Code beschreiben ▪ Deklarative Syntax ▪ Man beschreibt, welche Ressourcen es geben SOLL
  364. 24.11.2020 //// Seite 19 WPS – Workplace Solutions terraform apply

    ▪ berechnet Diff. zwischen SOLL und IST ▪ Erstellt Plan und zeigt den an ▪ Fragt nach Bestätigung IST SOLL
  365. 24.11.2020 //// Seite 20 WPS – Workplace Solutions terraform apply

    ▪ berechnet Diff. zwischen SOLL und IST ▪ Erstellt Plan und zeigt den an ▪ Fragt nach Bestätigung IST SOLL + + + ~ - ~
  366. 24.11.2020 //// Seite 21 WPS – Workplace Solutions Terraform: Abhängige

    Ressourcen ▪ Terraform erkennt Abhängigkeiten zwischen Ressourcen großteils automatisch durch Referenzen ▪ Ressourcen werden entsprechend in der richtigen Reihenfolge erzeugt oder abgeräumt my_security_group my_instance Abhängigkeit
  367. 24.11.2020 //// Seite 22 WPS – Workplace Solutions Terraform: State

    ▪ Tatsächlicher Zustand wird in „State“ gemerkt ▪ Nur bekannte Ressourcen werden von Terraform beachtet ▪ Sollte im Git oder besser in einem Backend gespeichert werden Code x State Welt y x y z a b
  368. 24.11.2020 //// Seite 24 WPS – Workplace Solutions Terraform Limitationen

    & Fallstricke ▪ Teilweise erkennt Terraform nicht alle Konsequenzen automatisch ▪ Beispiel: aws_instance mit aws_route53_record auf die Public-IP ▪ instance_type von t2.medium auf t2.large ändern ▪ terraform apply sagt: Update-in-Place, keine weiteren Auswirkungen ▪ Tatsächlich: ▪ Neustart erforderlich ▪ Public-IP und Public-DNS ändern sich ▪ Erst zweiter Aufruf von terraform apply erkennt geänderte Public-IP und ändert den aws_route53_record ▪ Im Zweifel: terraform apply doppelt ausführen
  369. 24.11.2020 //// Seite 25 WPS – Workplace Solutions Terraform: Weitere

    Themen Module Variablen Outputs Backends Import Provisioner Interpolation Syntax
  370. 24.11.2020 //// Seite 26 WPS – Workplace Solutions Terraform Zusammenfassung

    ▪ Terraform: Cloud-Infrastruktur mit Code beschreiben ▪ Deklarative Syntax. Man beschreibt, welche Ressourcen es geben SOLL ▪ „terraform apply“ ▪ berechnet Diff. zwischen SOLL und IST ▪ Erstellt Plan und zeigt den an ▪ Fragt nach Bestätigung ▪ Code ins Git ▪ Versionierung / Auditing out of the box ▪ Team hat alles unter Kontrolle ▪ Konfigurationsdrift direkt erkennbar ▪ Module, Kapselung und Abstraktion möglich
  371. 24.11.2020 //// Seite 28 WPS – Workplace Solutions Beispiele für

    Konfigurationen ▪ Packer Dateien ▪ Vorbereitung eines Host Images (reduziert Provisionierungsaufwand nach Allokation) ▪ Erhöht allerdings Verwaltungsaufwand weil man ein weiteres Artefakt verwalten muss ▪ Terraformdateien ▪ Zur Allokation von Infrastrukturessourcen in der Cloud ▪ Segmentierung des Netzerks ▪ Definition von Zugriffsrechten ▪ Ansible Playbook ▪ Provisionierung des Hosts nachdem die Ressource Allokiert wurde ▪ Verschiedene Konfigurationen der Kernanwendung
  372. 24.11.2020 //// Seite 29 WPS – Workplace Solutions Infrastruktur-Code Git

    ▪ Verwaltung sämtlicher Konfiguration in git ▪ Somit ist jede Infrastrukturanpassung in einem commit manifestiert und dokumentiert ▪ Fehlerhafte Konfigurationsanpassungen lassen sich einfach rückgängig machen app-repo - src - app - config - prod - stage - test - infrastructure - playbooks - terraform - .dockerignore - .gitignore - Dockerfile - readme.md - ... infrastructure-repo - playbooks - terraform - environments - prod - stage - test - modules - common-host - create-dns-entry - security-groups - .gitignore - readme.md app-repo + src - .dockerignore - .gitignore - Dockerfile - readme.md
  373. 24.11.2020 //// Seite 30 WPS – Workplace Solutions ▪ Idee

    von weaveworks 2017 publiziert https://www.weave.works/technologies/gitops/ ▪ Sämtliche Infrastrukturanpassungen werden durch einen git commit getriggert ▪ Zwei Repositories ▪ Das Code-Repository an dem die Build Pipeline hängt die lauffähige Artefakte produziert und diese bereitstellt ▪ Das ConfigRepository bildet die Grundlage zur Durchführung von Deployments oder Infrastrukturanpassungen ▪ Denkbar sind auch eigene Repositories je Umgebung. GitOps
  374. 24.11.2020 //// Seite 32 WPS – Workplace Solutions ▪ Kubernetes

    vereinfacht Deployment und Betrieb ▪ Es standardisiert die Verfahren zum Deployment von Anwendungen. ▪ Es standardisiert den Betrieb von Anwendungen ▪ Vanilla Kubernetes bringt aber auch Aufwand ▪ Steile Lernkurve für Betrieb und Entwickler ▪ Aufwändiges Aufsetzen neuer Cluster ▪ Betrieb des/der Cluster bringt weiteren Aufwand ▪ Kubernetes “Installer“ und “Management Plattformen“ versuchen die Nachteile zu mildern Container Management Plattform ( Rancher / OpenShift) Kubernetes Automatisierte Deployments Konzepte zum Betrieb verteilter Systeme Terraform Automatisierte Erzeugung von Cloud- Ressourcen Kubernetes Fluch oder Segen?
  375. 24.11.2020 //// Seite 33 WPS – Workplace Solutions Abstraktionen für

    Kubernetes Kubernetes „Installer“ • kops: CLI-Tool zum Aufsetzen von Kubernetes bei AWS (experimentell auch bei GCP) • Erstellt Infrastruktur und darauf Kubernetes-Cluster • kubeadmin: CLI-Tool zum Aufsetzen von Kubernetes auf bestehender Linux-Infrastruktur Kubernetes als Managed Service auch Kubernetes as a Service (KaaS) • EKS bei AWS • GKE bei Google Cloud • AKS bei Azure Container Management Platformen zur „Fernsteuerung“ von Kubernetes • Rancher: UI zur Verwaltung von Kubernetes-Clustern • Gardener: ähnlich wie Rancher Kubernetes Distributionen, die versuchen das Setup und Management zu vereinfachen • OpenShift: Eine Kubernetes-Distribution,die einige Kubernetes Implementationsdetails versteckt
  376. 24.11.2020 //// Seite 34 WPS – Workplace Solutions Unterschiede zwischen

    Container-Managern Die Container-Manager-Lösungen unterscheiden sich in verschiedenen Merkmalen: On Premise vs. On Cloud Selbst gemanagt vs. Händler-gemanagt Public oder Private • Teilt man sich den Container-Manager mit anderen Mandanten? • Gegenseitige Performance-Beeinflussung • Sicherheit Um welche Art von Container-Manager handelt es sich? • Pures („vanilla“) Kubernetes • Kubernetes mit Drumherum • Anderes (z.B. AWS ECS)
  377. 24.11.2020 //// Seite 35 WPS – Workplace Solutions Kops –

    Clustermanagement über CLI Ein „Installer“ für Kubernetes Cluster
  378. 24.11.2020 //// Seite 36 WPS – Workplace Solutions kops Überblick

    ▪ Open Source Tool ▪ Ermöglicht Cluster selber zu managen ▪ Viel manueller Aufwand ▪ Zwei Modi: ▪ Kops verwaltet direkt den Cluster über eigene Konfigurationsdateien ▪ Kops generiert Terraform-Code zur Verwaltung des Clusters ▪ Nur AWS voll supported
  379. 24.11.2020 //// Seite 37 WPS – Workplace Solutions kops Voraussetzungen

    ▪ kops benötigt als minimale Vorraussetzungen: ▪ AWS User oder Rolle mit weitreichendem Zugriff ▪ Vollzugriff auf EC2, Route53, S3, IAM, VPC ▪ S3 Bucket als State Store ▪ Route53-gemanagte DNS-Zone, die auflösbar ist ▪ Alternative: Verzicht auf DNS mit .k8s.local-Domain ▪ nur für Testzwecke geeignet ▪ kops unterstützt nicht bei der Einrichtung dieser Ressourcen
  380. 24.11.2020 //// Seite 38 WPS – Workplace Solutions Erzeugen der

    Cluster-Konfiguration ▪ Befehl: kops create cluster State Store (S3) kops erzeugt Cluster-Konfig- Dateien in
  381. 24.11.2020 //// Seite 39 WPS – Workplace Solutions Erzeugen der

    Cluster-Konfiguration export NAME=kops.example.com export KOPS_STATE_STORE=s3://kops.example.com kops create cluster \ --zones eu-central-1a \ --node-count=2 \ --node-size=t2.micro \ --master-size=t2.micro \ $NAME
  382. 24.11.2020 //// Seite 40 WPS – Workplace Solutions kops create

    cluster ▪ Erzeugt Cluster-Konfiguration in State Store (z.B. S3) ▪ Viele Parametrisierungsmöglichkeiten ▪ Clustergröße ▪ Clustername ▪ Domain ▪ Öffentlich / Privat ▪ Nodes (Anzahl, Typ) ▪ Masters (Anzahl, Typ) ▪ …
  383. 24.11.2020 //// Seite 41 WPS – Workplace Solutions Bearbeiten der

    Cluster-Konfiguration ▪ Befehl: kops edit cluster State Store (S3) kops bearbeitet (mit Texteditor) Cluster-Konfig- Dateien in
  384. 24.11.2020 //// Seite 42 WPS – Workplace Solutions Erzeugen /

    Ändern des Clusters ▪ Befehl: kops update cluster --yes State Store (S3) kops 1. liest Cluster-Konfig- Dateien in 2. Erzeugt / ändert Cluster-Ressourcen in Cloud-Umgebung 3. konfiguriert kubectl ~/.kube/config
  385. 24.11.2020 //// Seite 43 WPS – Workplace Solutions kops Auswirkungen

    ▪ Erzeugte Cluster-Konfiguration besteht aus ca. 100 Ressourcen-Definitionen VPC Subnetze Routing- Tabellen Autoscaling- Gruppen Geheimnisse Security Groups Volumes Rollen SSH- Schlüsselpaare
  386. 24.11.2020 //// Seite 44 WPS – Workplace Solutions kops Auswirkungen

    in der Cloud Auszug aus AWS CloudTrail-Events für minimalen Cluster: 11:35:19 CreateDhcpOptions 11:35:19 CreateVpc 11:35:19 CreateVolume 11:35:19 ImportKeyPair 11:35:19 CreateVolume 11:35:19 CreateTags 11:35:19 ModifyVpcAttribute 11:35:20 CreateInstanceProfile 11:35:20 CreateInternetGateway 11:35:20 CreateRole 11:35:20 CreateRole 11:35:20 ModifyVpcAttribute 11:35:20 CreateInstanceProfile 11:35:20 CreateSecurityGroup 11:35:20 CreateTags 11:35:21 CreateTags 11:35:21 AddRoleToInstanceProfile 11:35:21 AddRoleToInstanceProfile 11:35:21 CreateTags 11:35:21 CreateTags 11:35:21 CreateSubnet 11:35:21 PutRolePolicy 11:35:21 AttachInternetGateway 11:35:21 CreateSecurityGroup 11:35:21 CreateRouteTable 11:35:21 CreateTags 11:35:21 CreateTags 11:35:21 AssociateDhcpOptions 11:35:21 PutRolePolicy 11:35:22 AuthorizeSecurityGroupIngress 11:35:22 AuthorizeSecurityGroupIngress 11:35:22 AuthorizeSecurityGroupIngress 11:35:22 AuthorizeSecurityGroupIngress 11:35:22 AssociateRouteTable 11:35:22 CreateRoute 11:35:22 AuthorizeSecurityGroupIngress 11:35:22 AuthorizeSecurityGroupIngress 11:35:22 AuthorizeSecurityGroupIngress 11:35:22 AuthorizeSecurityGroupIngress 11:35:22 AuthorizeSecurityGroupIngress 11:35:22 AuthorizeSecurityGroupIngress 11:35:33 CreateLaunchConfiguration 11:35:33 CreateLaunchConfiguration 11:35:34 EnableMetricsCollection 11:35:34 CreateServiceLinkedRole 11:35:34 CreateServiceLinkedRole 11:35:34 CreateAutoScalingGroup 11:35:34 EnableMetricsCollection 11:35:34 CreateAutoScalingGroup 11:35:34 CreateServiceLinkedRole 11:36:41 RunInstances 11:36:42 RunInstances 11:39:05 AttachVolume 11:39:07 AttachVolume 11:40:08 AttachVolume 11:41:42 CreateRoute 11:41:42 ModifyInstanceAttribute 11:42:22 ModifyInstanceAttribute 11:42:22 CreateRoute 11:43:02 ModifyInstanceAttribute 11:43:02 CreateRoute
  387. 24.11.2020 //// Seite 45 WPS – Workplace Solutions kops Auswirkungen

    im Cluster kops$ kubectl get all --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE kube-system pod/dns-controller-5cdfc679cc-x888w 1/1 Running 0 87m kube-system pod/etcd-manager-events-ip-172-20-62-59.eu-central-1.compute.internal 1/1 Running 0 87m kube-system pod/etcd-manager-main-ip-172-20-62-59.eu-central-1.compute.internal 1/1 Running 0 86m kube-system pod/kube-apiserver-ip-172-20-62-59.eu-central-1.compute.internal 1/1 Running 3 87m kube-system pod/kube-controller-manager-ip-172-20-62-59.eu-central-1.compute.internal 1/1 Running 0 87m kube-system pod/kube-dns-66d58c65d5-ccvh6 3/3 Running 0 86m kube-system pod/kube-dns-66d58c65d5-vcb55 3/3 Running 0 87m kube-system pod/kube-dns-autoscaler-6567f59ccb-vp6jd 1/1 Running 0 87m kube-system pod/kube-proxy-ip-172-20-32-214.eu-central-1.compute.internal 1/1 Running 0 85m kube-system pod/kube-proxy-ip-172-20-48-113.eu-central-1.compute.internal 1/1 Running 0 86m kube-system pod/kube-proxy-ip-172-20-62-59.eu-central-1.compute.internal 1/1 Running 0 86m kube-system pod/kube-scheduler-ip-172-20-62-59.eu-central-1.compute.internal 1/1 Running 0 87m NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default service/kubernetes ClusterIP 100.64.0.1 <none> 443/TCP 88m kube-system service/kube-dns ClusterIP 100.64.0.10 <none> 53/UDP,53/TCP 87m NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE kube-system deployment.apps/dns-controller 1/1 1 1 87m kube-system deployment.apps/kube-dns 2/2 2 2 87m kube-system deployment.apps/kube-dns-autoscaler 1/1 1 1 87m NAMESPACE NAME DESIRED CURRENT READY AGE kube-system replicaset.apps/dns-controller-5cdfc679cc 1 1 1 87m kube-system replicaset.apps/kube-dns-66d58c65d5 2 2 2 87m kube-system replicaset.apps/kube-dns-autoscaler-6567f59ccb 1 1 1 87m
  388. 24.11.2020 //// Seite 46 WPS – Workplace Solutions kops Pro

    & Contra ▪ Volle eigene Kontrolle über den Cluster ▪ Geringe Kopplung an Cloud-Provider ▪ Erfordert sehr hohen Grad an Cloud-Expertise ▪ Viel Trial & Error mit Rechten, Domänen, etc. ▪ Aufräumen von Cluster-Resten und Clusterkonfigurationen in State Store ist müßig Empfehlung: ▪ Nur in leerem Cloud-Account ausprobieren ▪ Mit AWS CloudTrail o.ä. nachvollziehen, was alles passiert ▪ Nachschauen, dass nach Cluster-Löschung wirklich alle Ressourcen abgeräumt wurden
  389. 24.11.2020 //// Seite 47 WPS – Workplace Solutions Rancher Eine

    Multi Cluster und Multi-Cloud Container Management-Plattform
  390. 24.11.2020 //// Seite 48 WPS – Workplace Solutions Rancher 1.x

    ▪ Kam Anfang 2016 ▪ Ein Manager für Container Manager ▪ Und ein Container Manager ▪ Hatte einen eigenen Container-Manager namens Cattle ▪ Konnte bekannte weitere Manager aufsetzen, beobachten und steuern ▪ Insbesondere: Docker Swarm, Mesos und Kubernetes ▪ Manager für Cloudienste ▪ Schnittstellen zu gängigen IaaS-Anbietern und Fähigkeit dort Ressourcen zu managen ▪ Spannt virtuelles Netzwerk zwischen Ressourcen von verschiedenen Cloudanbietern ▪ Um seinen Cluster etwa über mehrere Cloudanbieter zu verteilen
  391. 24.11.2020 //// Seite 50 WPS – Workplace Solutions Rancher 2.x

    ▪ Kam Mitte 2018 ▪ Noch immer ein Manager für Container Manager ▪ Arbeitet nur noch mit Kubernetes und den Managed Kubernetes Angeboten der großen Cloudanbieter ▪ Kann also Kubernetes, GKE und EKS aufsetzen, beobachten und steuern ▪ Das ist geblieben: Manager für Cloudienste ▪ Schnittstellen zu gängigen IaaS-Anbietern und Fähigkeit dort Ressourcen zu managen ▪ Spannt virtuelles Netzwerk zwischen Ressourcen von verschiedenen Cloudanbietern ▪ Die Kernidee ▪ Rancher macht das Erzeugen und Management von einem Cluster derart einfach, dass Teams sich nach Bedarf leichtgewichtig eigene Cluster erzeugen können ▪ Rancher stellt die Management und Monitoringinfrastruktur bereit, die dann Teamübergreifend vereinheitlicht wird.
  392. 24.11.2020 //// Seite 51 WPS – Workplace Solutions Rancher -

    Überblick ▪ Besteht aus 3 wichtigen Komponenten ▪ Rancher Kubernetes Engine (RKE) ▪ Installation von Kubernetes auf Bare Metal oder virtuellen Maschinen ▪ Anzahl der Nodes anpassen, Cluster upgrades, Cluster health monitoring ▪ Unified Cluster Management ▪ zentrale Authentifizierung und Zugriffskontrolle ▪ Application Workload Management ▪ UI für die Verwaltung von K8S Objects (Pods, deplyoments, …) ▪ Helm support (mit wizard für’s templating) ▪ CI/CD integration (Jenkins, Drone, Gitlab, …) ▪ Prometheus alert manager Application Workload Management Unified Cluster Management RKE EKS GKE AKS
  393. 24.11.2020 //// Seite 52 WPS – Workplace Solutions Rancher –

    Eine Management Plattform für Kubernetes • Management mehrerer Kubernetes Cluster • Management von Ressourcen bei Cloudprovidern • Clusterübergreifendes Access Management Google Kubernetes Engine Google Cloud Platform Selbst gemanagter Kubernetes Cluster Auf Bare oder VMs Web-UI CLI
  394. 24.11.2020 //// Seite 57 WPS – Workplace Solutions OpenShift ▪

    Von Red Hat ▪ Ursprünglich (2011, vor Docker und Kubernetes) mit eigener Container-Technologie “Gears“ ▪ Mittlerweile bilden Docker und Kubernetes den Kern ▪ Im Unterschied zu Rancher hat OpenShift Kubernetes direkt im Bauch. ▪ Es ist sozusagen eine Kubernetes-Distribution ▪ Und sattelt noch eine Reihe Features drauf ▪ Container Registry ▪ Service Mesh-Artige Funktionalität ▪ Monitoring
  395. 24.11.2020 //// Seite 58 WPS – Workplace Solutions OpenShift Architektur

    Kubernetes Automatisierte Operationen (OpenShift) Service Mesh Application Services Developer Services Build Pipeline, CI/CD Tooling Cluster Services Monitoring, Logging, Container-Registry Unterstützung für den IT-Betrieb Unterstützung für die Entwickler
  396. 24.11.2020 //// Seite 59 WPS – Workplace Solutions OpenShift Varianten

    OpenShift Online • Voll gemanagt • In Public Cloud • Geteilt mit anderen Mandanten OpenShift Dedicated • Voll gemanagt • In Virtual Private Cloud (d.h. abgetrennter Bereich in Public Cloud) OpenShift Container Platform • Nicht gemanagt • On Premise
  397. 24.11.2020 //// Seite 60 WPS – Workplace Solutions OpenShift Konzepte

    OpenShift ergänzt die Kubernetes-Konzepte wie Pod, ConfigMaps und Deployment um eigene Project DeploymentConfig BuildConfig Build ImageStream Route
  398. 24.11.2020 //// Seite 61 WPS – Workplace Solutions Project ▪

    Ähnlich zu Kubernetes Namespace ▪ Hat zusätzlich: ▪ Striktere Validierung ▪ Über Templates erzeugbar ▪ Ressource Limits (mittlerweile auch bei Namespaces)
  399. 24.11.2020 //// Seite 62 WPS – Workplace Solutions DeploymentConfig ▪

    Gab es in OpenShift bevor es Deployments in Kubernetes gab ▪ Ein paar zusätzliche Features zu Deployments: ▪ Verdrahtet mit ImageStreams ▪ Explizite Angabe von Triggern ▪ ImageChange: Image hat neue Version ▪ ConfigChange: Die Konfiguration wurde geändert ▪ Deployment-Strategien neben RollingUpdate ▪ Blue-Green ▪ A/B ▪ Lifecycle Hooks, die vor oder nach einem Deployment ausgeführt werden
  400. 24.11.2020 //// Seite 63 WPS – Workplace Solutions Build ▪

    Erweitert Kubernetes um CI/CD-Kapazitäten ▪ Ein Build ist ein innerhalb von OpenShift ablaufender Build-Prozess, der Container-Images als Grundlage für einen Pod baut ▪ Wird durch BuildConfig (eine yaml-Datei) konfiguriert
  401. 24.11.2020 //// Seite 64 WPS – Workplace Solutions ▪ Ziel

    ist ein ImageStream ▪ Nutzt eine von zwei Strategien: ▪ Source-to-Image: Injiziert Anwendungscode in ein bestehendes Image. ▪ Sicherer, aber weniger flexibel als ein Dockerfile ▪ Pipeline: Angabe einer Jenkins-Pipeline ▪ Verschiedene Inputs möglich ▪ Inhalte aus bestehenden Images extrahieren ▪ Source-Code aus Git ▪ Lokale Dateien ▪ Kubernetes Secrets und ConfigMaps kind: "BuildConfig" apiVersion: "v1" metadata: name: "ruby-sample-build" spec: runPolicy: "Serial" triggers: - type: "GitHub" github: secret: "secret101" source: git: uri: "https://github.com/openshift/ruby-hello-world" strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "ruby-20-centos7:latest" output: to: kind: "ImageStreamTag" name: "origin-ruby-sample:latest" postCommit: script: "bundle exec rake test" BuildConfig
  402. 24.11.2020 //// Seite 65 WPS – Workplace Solutions ImageStream ▪

    Triggert Build wenn ein dem, Deployment zugrundeliegendes (Basis)-Image sich ändert etwa wegen eines Updates
  403. 24.11.2020 //// Seite 66 WPS – Workplace Solutions Route ▪

    Ähnlich zu Kubernetes Ingress, mit leicht anderen Features ▪ Macht einen Service öffentlich unter einem Hostnamen verfügbar Feature Ingress bei OpenShift Route bei OpenShift Standard Kubernetes-Object X Externer Zugriff auf Services X X Sticky Sessions X X Load-balancing Strategies (z.B. round robin) X X Rate-limit und Throttling X X IP-Whitelisting X X TLS-Edge-Termination X X Erneute TLS-Verschlüsselung X TLS Passthrough X Split Traffic X Generierte Hostnames nach Muster X Wildcard-Domains X Route / Ingress Service Pods macht extern verfügbar macht intern verfügbar und verteilt Last
  404. 24.11.2020 //// Seite 68 WPS – Workplace Solutions oc (CLI)

    ▪ oc ist ein CLI-Tool ▪ Hat die selben Befehle wie kubectl ▪ Ergänzt um reine OpenShift-Kommandos, z.B. für BuildConfigs oc login --token=<TOKEN> --server=https://api.us-east-1.online-starter.openshift.com:6443 oc new-project nodejs-echo oc new-app https://github.com/sclorg/nodejs-ex -l name=myapp
  405. 24.11.2020 //// Seite 76 WPS – Workplace Solutions Übung zu

    Kapitel 7 – Automatisierung Mit Blick auf die Fallstudie, sowie ihre bisherigen Designentscheidungen: ▪ Würden Sie eine der Containermanagement- Plattformen in Erwägung ziehen? Begründen Sie! ▪ Welche weiteren Tools zur Automatisierung würden Sie zu welchem Zweck einsetzen?