OpenShift als Motor des kontinuierlichen Test- und Deployment Zyklus Referent: Jürgen Hoffmann, Red Hat

Transkript

1 OpenShift als Motor des kontinuierlichen Test- und Deployment Zyklus Referent: Jürgen Hoffmann, Red Hat München, 13. Oktober 2015

2 Agenda Traditionelle Entwicklung Änderungen im Aspekt von Containern OpenShift als Secret Sauce und Treiber des kontinuierlichen Testens Seite 2

3 Standardzyklus push code... Dev Dev QA Test app QA Prod Operate app Ops Seite 3

4 Generelle Verbesserung Produktion besser simulieren? Schritte zwischen den Stages automatisieren? Wie kann ich den Prozeß standardisieren? Mehr Zeit für Innovationen Weniger Zeit für Infrastrukturthemen Seite 4

5 Continuous Integration Seite 5

6 Platform as a Service Fokus ist Anwendung Standardisierung und Wiederverwendbarkeit Automatisierung und Effizienz PaaS verspricht: Beschleunigte Entwicklung Beschleunigte Verfahren Entw. -> Prod Unterstützende Verfahren für DevOps Seite 6

7 Seite 7

8 Bedingte Anforderungen Die Art der Anwendung ist entscheidend Web Applikationen vs. traditionelle Multi- Tier Anwendung Schnelle Integrationsfähigkeit Hohe Automatisierung APIs meist proprietär Eingeschränkte Freiheit in der Technologiewahl Platform Lock-In Seite 8

9 Automatisierte Staging Umgebungen Automatisierung bietet eine Laufzeitumgebung für eine Vielfalt von üblichen Applikationstypen in jeder Umgebung Schneller Projektstart bei üblichen Typen Bessere aber limitierte Wahlfreiheit von Technologien Fokus der Automatisierung liegt zumeist auf Front-End Services Teile sind zwar automatisiert, aber nicht paketiert Seite 9

10 Ochestrierte Provisionierung Automatisierte Provisionierung von virtuellen Maschinen und Lifecycle Management Größtmögliche Kontrolle In der Regel eher schlechte Utilisierung der Resourcen Skalierung ist meist schwierig und Komplex Hoher Betriebsoverhead Meist schlechte Erweiterbarkeit Seite 10

11 Was wäre wenn? Abhängigkeiten paketiert werden könnten Deployments frei orchestriert werden könnten Eine nahtlose Integration in jegliche Entwicklungswerkzeuge möglich wäre Seite 11

12 CONTAINERS MIT DOCKER Encapsulation Seite 12

13 (Übrigens) Container Sind Keine mini-vms Sie teilen sich den OS kernel Prozesse laufen auf dem Host OS Separiert durch Kernel Namespaces mount (file system mounts) ipc (inter-process communication) pid (processes) uts (hostname) Starten im Sekundenbereich Seite 13

14 STANDARDISIERUNG Standards werden über Container veröffentlicht Dockerfile My Tomcat Web App Container Neue abgeleitete Standards werden per docker build erstellt FROM rhel7-tomcat:v MAINTAINER Buddy ADD /var/tomcat/webapps/root.war EXPOSE 8080 CMD [ tomcat.sh ] Seite 14

15 Docker und mehrere Hosts Wie betreibe ich Container in großem Maßstab? Skalierung von Container Deployments Routing zu Containern Skalierung von Persistent Storage für Container Hochverfügbare Plattform Hochverfügbare Anwendungen Seite 15

16 GOOGLE KUBERNETES Services bieten stabilen Endpoint für skalierte Apps Anwendungsskalierung Definieren Sie die gewünschte Anzahl von Replicas und kubernetes übernimmt die Orchestrierung im Cluster Kubernetes Infrastrukturskalierung Fügen Sie einfach neue Knoten zum Cluster hinzu um die Kapazität zu erweitern Labels für Kontrolle des Schedulers Seite 16 Einfache Verwaltung von Persistent Storage

17 A SIMPLE SDLC - WITH CONTAINERS Dev push Existing CI... compile & test Kubernetes cluster docker build QA Nodes? run pod Consistent run-time environment?? Dev Nodes test apps QA Platform Ops maintain cluster Prod Nodes Seite Automate cluster routing and scaling 17 maintain apps? Ops How to route to apps?

18 Red Hat s Mission Beteiligung an Docker & Kubernetes Project Atomic Sicheres Container OS Docker & Kubernetes OpenShift Origin Automatisierung des Container Lifecycle Managements Integrierter Routing Layer (HAproxy) Webconsole und User-/Team Management Multimandanten Seite 18

19 A SIMPLE SDLC - WITH OPENSHIFT Dev push... OpenShift extended Kubernetes cluster build config QA Nodes Consistent run-time environment image streams private repo deploy config deploy config Dev Nodes test apps QA maintain cluster Prod Nodes Automated external routing Automated cluster routing and scaling maintain Platform Ops HA external entry points Seite 19 Ops

20 Redhat Registry Corporate Registry Docker Images werden aus mehreren Layern erstellt Seite 20

21 Redhat Registry Corporate Registry Docker Images werden aus mehreren Layern erstellt Wenn sie Funktionen hinzu fügen, fügen Sie einen weiteren Layer zum Basis Image Seite 21

22 Redhat Registry Corporate Registry Docker Images werden aus mehreren Layern erstellt Wenn sie Funktionen hinzu fügen, fügen Sie einen weiteren Layer zum Basis Image Anpassen der Unternehmensstandards Disable connectors Add internal certs and.pem files Seite 22

23 Redhat Registry Corporate Registry Docker Images werden aus mehreren Layern erstellt Wenn sie Funktionen hinzu fügen, fügen Sie einen weiteren Layer zum Basis Image Anpassen der Unternehmensstandards Disable connectors Add internal certs and.pem files Seite 23

24 Redhat Registry Corporate Registry MyApp:latest Docker Images werden aus mehreren Layern erstellt Wenn sie Funktionen hinzu fügen, fügen Sie einen weiteren Layer zum Basis Image Anpassen der Unternehmensstandards Disable connectors Add internal certs and.pem files Ihre Anwendung ist einfach ein weiterer Layer Copy.war to webapps Directory Seite 24

25 STANDARDISIERUNG Standards werden über Container veröffentlicht Dockerfile My Tomcat Web App Container Neue abgeleitete Standards werden per docker build erstellt FROM rhel7-tomcat:v MAINTAINER Buddy ADD /var/tomcat/webapps/root.war EXPOSE 8080 CMD [ tomcat.sh ] Seite 25

26 Redhat Registry Corporate Registry Red Hat released ein neues Basis Image MyApp:latest Seite 26

27 Redhat Registry Corporate Registry Base images change Security fix! MyApp:latest Seite 27

28 Redhat Registry Corporate Registry Base images change Security fix! Images in registry not up-to-date MyApp:latest Our app is still based on older images Seite 28

29 Redhat Registry Corporate Registry Base images change Security fix! Images in registry not up-to-date MyApp:latest Our app is still based on older images Images sind Immutable Also... Müssen alle bedingten Images neu gebaut werden? Seite 29

30 Redhat Registry Corporate Registry MyApp:latest MyApp:latest newapp:latest MyApp2:latest newapp:latest Was passiert bei mehreren Anwendungen Bei einem neuen Image müssen Alle abhängigen Layer neu gebaut werden Komplexität In Docker + Kubernetes existiert kein Mechanismus um diese Komplexität zu verwalten Seite 30

31 S2I und Image Streams Seite 31

32 3 Wege zum fertigen Docker Image Openshift bietet 3 Möglichkeiten um Image Builds auszuführen Docker Build Source to Image (S2I oder STI) Custom Builder Image Seite 32

33 POSD - Plain Old Simple Docker Einfach auf ein Dockerfile im SCM verweisen, OpenShift baut das Docker Image samt aller Abhängigkeiten oc new-app Seite 33

34 S2I Source to Image Einfach auf das Source Code Repository verweisen OpenShift untersucht das Repository und bestimmt die Runtime (Java, Python, Ruby, etc.) Wählt Basis Image entsprechend aus Nimmt ein Deployment des Artefakts vor und erstellt einen neuen Layer oc new-app (this simply works) Seite 34

35 Custom Builder Image Custom Builder Image ergänzen falls Docker und S2I nicht ausreichen Die gesamte Logik kann frei definiert werden Integration in CMDB Integration in beliebige Test Frameworks Integration in beliebige Governance Tools Freie Integration in Jenkins Seite 35

36 Image Streams Jedes Image repräsentiert einen Stream Builds und Deployments können auf Änderungen im Stream registrieren ( listen ) Wenn sich ein Basis Image ändert, werden auch alle abhängigen Images neu erstellt Daraus folgt, Tomcat Image wird geändert: Security fix Corporate Build ist gegen das Tomcat Image (ImageStream) registriert Corporate Build wird angestoßen. Resultat ist ein neuer Corporate Build Dieser ist ebenfalls ein Image Stream und alle abhängigen Images werden neu gebaut Seite 36

37 Redhat Registry Corporate Registry MyApp:latest Seite 37

38 Redhat Registry Corporate Registry buildconfig MyApp:latest Seite 38

39 Redhat Registry Corporate Registry trigger buildconfig stream:tomcat MyApp:latest Seite 39

40 Redhat Registry Corporate Registry trigger buildconfig stream:tomcat MyApp:latest corporate:1.0 Seite 40

41 Redhat Registry Corporate Registry MyApp:latest trigger stream:tomcat buildconfig corporate:1.0 buildconfig Seite 41

42 Redhat Registry Corporate Registry trigger buildconfig trigger buildconfig stream:tomcat stream:corporate MyApp:latest corporate:1.0 Seite 42

43 Redhat Registry Corporate Registry trigger buildconfig trigger buildconfig stream:tomcat stream:corporate MyApp:latest corporate:1.0 MyApp:1.0 Seite 43

44 Redhat Registry Corporate Registry Corporate Image wurde neu erstellt Applikations-Image wurde ebenfalls neu erstellt Alle Images wurden in der Corporate Registry zur Verfügung gestellt Alle Fixes von Red Hat und Corporate sind enthalten Alles steht zum trigger Deployment bereits buildconfig unabhängig von trigger den Etwicklungs- Release Zyklen stream:tomcat stream:corporate MyApp:latest corporate:1.0 buildconfig MyApp:latest previous Seite 44 latest

45 A SIMPLE SDLC - WITH OPENSHIFT Dev push... OpenShift extended Kubernetes cluster build config QA Nodes Consistent run-time environment image streams private repo deploy config deploy config Dev Nodes test apps QA maintain cluster Prod Nodes Automated external routing Automated cluster routing and scaling maintain Platform Ops HA external entry points Seite 45 Ops

46 Seite 46

47 Deployment Types Rolling Deployments Recreate Deployments Blue Green Deployments A/B Deployments Custom Deployment Seite 47

48 ConSol Software GmbH Franziskanerstraße 38 D München Tel: Fax: Seite 48