Infrastruktur ein kritisches Thema, ohne sie läuft nichts. Bei MS interessant, da es sich um verteilte Systeme handelt

130 Leute, drei Standorte, Accso

Infrastruktur isf für MS, wie für Menschen Luft zum Atmen Skalieren wichtig, Infrastruktur nach Bedarf einsetzen,

je nach Maßstab geht das nur noch automatisiert -> moderne Technologien erforderlich

Infra an zwei stellen wesentlich, einmal Entwicklung, einmal Betrieb Entwicklung Einfluss von Infrastruktur berücksichtigen, mehr Infrastrukturaspekte als bei Monolithen

im Bereich Hardware -Ausgehend vom Service (selbst gestaltet), brauch Rechenleistung um Dienst zu erfüllen, in Form von CPU, Speicher -Es wird BS benötigt -Netzwerkverbindungen um Dienst anbieten zu können, Internetanschluss mit entsprechender Bandbreite -typischerweise Speicherplatz (Storage) Energie und Kühlung, redundant, Kühlleistung

Erste Fragestellung, wo machen wir eine Testumgebung typischerweise am besten im RZ

im Bereich Software Ausstattung an Systemsoftware nicht immer frei in der Gestaltung Software muss konfiguriert werden Sicherheitsthemen, Benutzerkonten, Berechtigungen Networking, Firewall, o. ä.

Monitoring & Alerting Mechanismen, Informationen wenn etwas ausgefallen ist. Automatismen, aber auch manuelle Arbeit erforderlich

Provisioning (ebene darüber) Bereitstellen von Gerätschaften im Netzwerk muss durch jmd. geleistet werden Change Mngmnt - Was ist einzurichten, was soll geändert werden (Serviceleistungen)

Backup & Restore

(Patch) Management (Serviceleistung)

Support (Serviceleistung) (24x7, Schichtbetrieb)

Geschichte der Infrastruktur einfache Gerätschaften - bare metal, früher üblich, wurden gekauft, gewisse Software auf gewisse Maschine Konsequenzen wenn neues System kommt, neues System erforderlich, Prozess evtl. langwierig

heute Infrastruktur auf Knopfdruck

Besser mit verfügbarkeit von VMs, RZ konnten große Rechenkapazität auf Vorrat bereitstellen und für verschiedene Systeme VMs bereitstellen - dauer wenige Wochen bis Umgebung verfügbar ist peformancenachteil, aber in kauf genommen, da schneller Nachteil hoher Pflegeaufwand für VMs Noch nicht da wo wir heute sind: schnell Kapazitäten je nach Bedarf hinzufügen oder entfernen

nächste Stufe Raus aus Kundeneigenen RZ IaaS, PaaS, SaaS: aus der Cloud in unterschiedlichem niveau Leistungen beziehen Dauer bis Umgebung eingerichtet ist, trotzdem noch im Bereich von 1-2 Wochen

virtual private/hybrid cloud Kapazität auf Knopfdruck, Software sofort, vollautomatisch, zahlen nur für tatsächlichen Verbrauch (abgerechnet nach Zeit) Verschiedene Ausprägungen: private cloud, aws, google eigene Services wie eigene RZ rausschneiden, separete Netze

stufe höher: Container nicht mehr virtuelle maschinen mit großvolumigen images(komplettes system inkl. bs) funktionieren im Grunde wie eine Anwendung, lassen sich genauso starten wie Applikation, bieten aber abgeschlossene Umgebung einer VM

insbesondere bei MS sehr wichtig da die Umgebung auf der die Software läuft von den Entwicklern mitgestaltet werden soll

Schritt weiter Betrieb von Systemen aus vielen Container, keine individuelle Verwaltung von einzelnen Containern Das System soll die Container bekommen und dafür sorgen, dass der anwendungsverbund läuft

Schritt hin zum: Orchestrated clusters on premise vs. on demand, Stufe iaas, usw. fällt in beide Bereiche

Infrastruktur Beispiel:

2 Instanzen, Verfügbarkeit auch bei Ausfall einer Instanz Instanzen können auch an getrennten Orten platziert sein, je nach Verfügbarkeitsanforderungen

Daten sind das Kapital der heutigen Wirtschaft, daher hohe Sicherheitsanforderungen, innen in der Firma angesiedelt Logik auf den Daten Ebene weiter vorne, vllt. getrennt durch Firewall, die sich schnell ändernden Applikationen Zugriffskontrollmöglichkeiten auf unterschiedlichen Schichten Webserver noch weiter draußen

Wie wird Infra bei der Entwicklung von MS genutzt

Blick in das innere von VMs eine Hardware für mehrere VMs, Hypervisor gaukelt Hardware virtuell für mehrere Maschinen vor jede VM hat komplettes eigenes BS und Anwendungen darin

gegenüber Container Hardware mit einmal BS, dann Docker (beispiel) Containerumgebung, dann viele kleine Anwendungen als Container BS nur einmal erforderlich, daher können viel mehr Containerisierte Anwendungen auf eine physische Maschine

daher auch schnellerer Start, es muss nicht immer ein BS gestartet werden

Verfügbarkeit von technischen Mitteln seit Jahren gegeben (in Linux) Namespaces: Aufteilung von Sicht auf das System (Dateisystem, Netzwerkumgebung)

Layered FS: Jede Anwendung sieht etwas anderes, sogar verschiedene Distris können vorgegaukelt werden

Control Groups: Begrenzung von Hardwareressourcen

Nutzung:

Postgres -> Docker Hub: Containerbeispiele, Docker nicht nur Laufzeitumgebung, es gibt fast beliebige vorgefertigte Images

Docker File, um anzugeben auf welcher Basis ein Dockercontainer gestaltet werden soll Image für Ausgangsbasis mit Parametern steuerbar, welche Anwendungen definieren wie die Anwendung gestartet werden kann Es kann ein Image gebaut werden, wo die Anwendung paketiert ist sehr schneller und einfacher Prozess

Standardimages aus Registry (Hub) mit Dockerfile anwendungsspezifisch beliebig oft, parallel, starten und stoppen -> container pro container ein prozess, ein Dienst/Prozess(-baum) pro Image, einschränkungen gegenüber VMs Container liegen lokal auf der Maschine wo sie betrieben werden

Laufzeitumgebung Docker ist Linuxdaemon

Alternativen: Docker Rkt (CoreOS) [Rocket] LXD (LXC) Windows Containers

Enwicklung, schnell Services, Software benutzen

Entwicklungsinfrastruktur kann schnell bereitgestellt werden

In Produktion (anderes Thema) hängt davon ab, was und wo man betreibt Vorher Frage: wo läuft die Software, welche Mechanismen sind zulässig. Aber: Grundsätzlich kann es in Produktion sinnvoll eingesetzt werden Möglich: Mischung aus Containerisierten Anwendungen und VMs Container sehr eingeschränkt aber hocheffizient VMs sehr frei aber nicht effizient

Container (beschleuniger Betrieb) -> Agilität (schnell reagieren) -> DevOps (zusammenarbeit entwicklung und Betrieb) -> Cloud (alles aus dem inet) -> MS -> Docker (Produkt, mach Container einfach zugänglich) -> Container

Unterschiede zw. Entwicklung und Betrieb run develop Hardware on premise, cloud laptop test-environment software Cloud Paas VMs auf Laptops Service Private Ops, Cloud Saas Self Service Infrastructure Team Docker Engine ? local Docker, Docker Toolbox Docker Base Images / Runtime Environments Private/secured Docker Registry Docker Hub Packaged Services Docker Images Docker Images (prod ready) Sepcific Networking, Monitoring, Security ? Docker Compose, Dockerized Services VMs

Betrieb: Interessenkonflikt: Betriebsmanschaft: stabilität, änderungen problem Entwickler: änderungen schnell umsetzen

DevOps: Kultureller Wandel, Technologiefreiheit ist Arbeit für den Betrieb, Lizenzen, Anforderungen also Verantwortung

Continoous Integration: traditonell: Software wird als lauffähiges Produkt abgeliefert, dass getestet ist. zusätzlich noch: möglichst genau so betreiben wie im echten Betrieb, Änderungen nach den Erfahrungen aus dem Betrieb kritischer bei MS, weil diese großflächig mit Infra verbunden sind.

Kontinuierliches wird mit Pipeline dargestellt:

1. Schritt Quellcode aus dem System automatisch holen (jenkins) bauen zu lauffähiger Software, Rückmeldung bei Fehlern

2. Tests auf ausführbarer Software (Acceptance Test), sicherung der Einhaltung von Anforderungen Rückmeldung bei Fehlern

3. Software steht bereit für Abnehmer, tests, manuelle Bestätigung (häufig) (Approval)

4. Release

Pipeline kann in Continous Integration Umgebung codiert werden (Jenkins File)

Vollautomatischer Prozess durch Continuess Integration Server Server kann Dockerimages zum bauen nutzen

Services werden als Docker Images paketiert und können direkt in Docker Registry übertragen werden

Images auf Entwicklermaschine, Testumgebung und Prod optimalerweise die selben Datenbankzugangsdaten nicht in Image codieren, sondern aus Umgebungsvariablen

Automatisiert Instanzen hochfahren und runterfahren je nach Last

Neue Version, alte ist noch in Betrieb: Mechanismus nimm einen Teil der alten Instanzen raus, und ersetzte sie nach und nach durch neue

Automatisierung: Container Orchestrierung Datei yaml festlegen aller services mit Dockercompose automatisch starten und stoppen, aber eher für eine Maschine Swarmmode erlaubt die Nutzung auf mehreren Maschinen, aber nicht optimal (docker swarm)

Kubernetes unabhängig von konkreten Technologien hohe automation on-premise /private data center option, funktioniert im Grunde überall gleich einfache administration

Es ist nicht klar ob mir Dockercontainern im Produktivbetrieb gearbeitet werden kann, kubernetes auf dem Weg zum Industriestandard

kubernetes: Ressource Mngmnt - Container werden so eingestellt das es passt (Rechenleistung usw.) Scheduling - Verteilung auf zur Verfügung gestellte Rechenleistung, wenn Bedarf Instanzen bereitzustellen sorgt Scheduling dafür dass diese vorhanden sind, ersetzt Instanzen bei Ausfall, Rolling Updates Load Balancing - verteilt Anfragen auf Dienste

Kubernets löst das Problem sich auf einen Cloudanbieter festlegen zu müssen. Kann unabhängig von konkreter Umgebung eingesetzt werden

Kommunikation im System Services wissen voneinander nicht mehr wo sie laufen (10 Instanzen auf 20 Maschinen) Service ruft nur aus: mit wem möchte ich Kommunizieren Mechanismus sorgt dafür das der Aufruf an der entsprechenden Stelle ankommt Wenn bei Aufruf etwas schiefgeht (Instanz die Aufruf bearbeitet fällt aus), unter Umständen kann die Infrastruktur dafür sorgen, dass der Aufruf wiederholt wird Thema: Service Discovery beschriebt das Problem Service Mash: aktueller Stand der Lösung, es geht gar nicht mehr um das deploymnt der Dienste sonder diese können mit Minimalaufwand in der benötigten Qualität kommunizieren

Istio - realisiert die Kommunikation Istio leistet auch die Verwaltung der Zertifikate es stehen verschiedene Protokolle zur Kommunikation zur Verfügung das System führt Buch wo welche Services laufen und unter welcher Adresse diese zu finden sind. Leitet dann die Aufrufe weiter.

Pod wird typischerweise für einen Dienst benutzt, Services die unabhängig voneinander sind werden nicht in einen Pod zusammengefasst.

Container mehrere Instanzen bei Datenspeicherzugriff komplexer, vorschlag Cold Standby

Services einer Domäne in unterschiedliche Pods, einzelne Pods für jeden Dienst