da

Praxisbericht.tex

@@ -155,11 +155,11 @@ Das Software-Engineering Department befindet sich im ersten Stock auf der Südse
 
 \section{Aufgabenbereich}
 
-Mein Arbeitsplatz befindet sich im Herz der PA INF GUI. Während der Name auf alleiniges Ausarbeiten von grafischen Nutzeroberflächen (Graphical User Interface, kurz GUI) vermuten lässt, ist diese Abteilung auch für die Integration der verschiedenen Backends von selektron zuständig. Dies wird mithilfe des in der Abteilung entwickelten Kernmodul der selektron-Suite, selektron core, bewältigt. selektron core besteht dabei aus den Komponenten Administration, API Gateway, Authentification, Authorisation und Discovery. Jedes der Backends besteht ebenfalls aus mehreren Komponenten. Diese werden jeweils für Kundensysteme vom Basis-Entwicklungsstand einzeln angepasst und zugeschnitten, damit es perfekt auf deren Anforderungen ausgelegt ist. Oft haben Kunden jedoch gleiche oder ähnliche Bedürfnisse, welche im aktuellen System bei jedem Kunden extra und damit mehrfach Implementiert werden. Diese Implementationen betreiben oft die gleiche Aufgabe, sind jedoch anders Entwickelt. Durch diese resultierenden Redundanzen steigt der Wartungsaufwand. Ebenfalls steigt der Aufwand, die zugeschnittenen Systeme bei dem Kunden zu konfigurieren und einzusetzen, da jeder Kunde eine einzigartige IT-Infrastruktur hat, wodurch das Deployment händisch mit einer Ansammlung von über die Jahre entwickelten und gewachsenen Skripten und viel Filigranarbeit durchzuführen ist. Dieses Händische Softwaredeployment ist nicht nur aufwändig, sondern senkt dazu die Wartbarkeit, da über die Jahre immer wieder Updates, Migrationen und sonstige kurzfristige Änderungen auftreten, welche nur zum Teil dokumentiert, und damit schwer Nachvollziehbar sowie absolut nicht Auditierbar sind. Folgend ist die Einarbeitung von Servicemitarbeitern aufwändig, da alles über das Terminal mit Skripten und Befehlen verwaltet werden muss, und nicht alle Fälle von diesen existierenden Skripten übernommen werden können. Diese Servicefälle müssen im Schlimmstfall bis zum nächsten Arbeitstag warten, was für den Kunden verlorene Zeit und damit verlorenes Geld bedeutet. Würde im aktuellen System eine Ausfallsicherheit existieren, könnte diese zumindest den Service bei einigen trivialen Fällen entlasten, jedoch ist aktuell keine vorhanden.
+Mein Arbeitsplatz befindet sich im Herz der PA INF GUI. Während der Name auf alleiniges Ausarbeiten von grafischen Nutzeroberflächen (Graphical User Interface, kurz GUI) vermuten lässt, ist diese Abteilung auch für die Integration der verschiedenen Backends von selektron zuständig. Dies wird mithilfe des in der Abteilung entwickelten Kernmodul der selektron-Suite, selektron core, bewältigt. selektron core besteht dabei aus den Komponenten Administration, API Gateway, Authentification, Authorisation und Discovery. Jedes der Backends besteht ebenfalls aus mehreren Komponenten. Diese werden jeweils für Kundensysteme vom Basis-Entwicklungsstand einzeln angepasst und zugeschnitten, damit es perfekt auf deren Anforderungen ausgelegt ist. Oft haben Kunden jedoch gleiche oder ähnliche Bedürfnisse, welche im aktuellen System bei jedem Kunden extra und damit mehrfach Implementiert werden. Diese Implementationen betreiben oft die gleiche Aufgabe, sind jedoch anders Entwickelt. Durch diese resultierenden Redundanzen steigt der Wartungsaufwand. Ebenfalls steigt der Aufwand, die zugeschnittenen Systeme bei dem Kunden zu konfigurieren und einzusetzen, weil jeder Kunde eine einzigartige IT-Infrastruktur hat, wodurch das Deployment händisch mit einer Ansammlung von über die Jahre entwickelten und gewachsenen Skripten und viel Filigranarbeit durchzuführen ist. Dieses Händische Softwaredeployment ist nicht nur aufwändig, sondern senkt dazu die Wartbarkeit, da über die Jahre immer wieder Updates, Migrationen und sonstige kurzfristige Änderungen auftreten, welche nur zum Teil dokumentiert, und damit schwer Nachvollziehbar sowie absolut nicht Auditierbar sind. Folgend ist die Einarbeitung von Servicemitarbeitern aufwändig, da alles über das Terminal mit Skripten und Befehlen verwaltet werden muss, und nicht alle Fälle von diesen existierenden Skripten übernommen werden können. Diese Servicefälle müssen im Schlimmstfall bis zum nächsten Arbeitstag warten, was für den Kunden verlorene Zeit und damit verlorenes Geld bedeutet. Würde im aktuellen System eine Ausfallsicherheit existieren, könnte diese zumindest den Service bei einigen trivialen Fällen entlasten, jedoch ist aktuell keine vorhanden.
 
-Jedes der Module der selektron-Suite wurde innerhalb der letzten Jahre in Container-Images gebündelt und daraufhin das Deployment mit Containerverwaltungstools wie Docker oder Podman durchgeführt, um das Deployment weitestgehend zu vereinfachen und Kundeninfrastrukturunabhängiger zu gestalten. Trotzdessen bleiben viele der gennanten Probleme bestehen, da sie über die simple Containerisierung von Software hinaus gehen.
+Jedes der Module der selektron-Suite wurde innerhalb der letzten Jahre in Container-Images gebündelt und daraufhin das Deployment mit Containerverwaltungstools wie Docker oder Podman durchgeführt, um das Deployment weitestgehend zu vereinfachen und Kundeninfrastrukturunabhängiger zu gestalten. Trotzdessen gehen viele der gennanten Probleme über die simple Containerisierung von Software hinaus, und bleiben somit bestehen.
 
-Mein Aufgabenbereich, das Evaluieren von Kubernetes als Containerorchestrierung für den Software-Stack der psb, ist keine klassische Aufgabe im Bezug auf die Nutzeroberfläche, ist in der Firmenstruktur, da es als Integration gilt, dieser Abteilung untergliedert. Kubernetes führt im Kern, ähnlich wie Docker und Podman, Container aus, geht jedoch weit über das Ausführen und triviale Verwalten von diesen hinaus und wird daher aus als Orchestration bezeichnet. Da die Firma aktuell noch keine Forschung über Kubernetes, außer dem Fakt, dass es existiert und die aktuelle Problemlage Lösen könnte, betrieben hat, sollte dies meine Aufgabe werden. Das Ziel ist es, herauszufinden, welche Features Kubernetes und dessen Ökosystem bietet, zu analysieren wie diese funktionieren als auch zu überprüfen, ob diese konkret für das Projekt Sinn ergeben. Mithilfe der Erkenntnisse soll Basiswissen über die Containerorchestration sowie ein möglichst automatisch deploybares Walking Skeleton auf Grundlage des selektron-Basisprojektes entstehen. Darüber hinaus soll geprüft werden, inwieweit Kubernetes eine Integration von Windows-basierten Systemen ermöglicht und welche technischen Einschränkungen dabei bestehen. Die gewonnenen Erkenntnisse dienen als Entscheidungsgrundlage für eine mögliche Migraton der bestehenden Systemarchitektur hin zu einer Kubernetes-basierten Lösung.
+Mein Aufgabenbereich, das Evaluieren von Kubernetes als Containerorchestrierung für den Software-Stack der psb, ist keine klassische Aufgabe im Bezug auf die Nutzeroberfläche, ist in der Firmenstruktur, da es als Integration gilt, dieser Abteilung untergliedert. Kubernetes führt im Kern, ähnlich wie Docker und Podman, Container aus, geht jedoch weit über das Ausführen und triviale Verwalten von diesen hinaus und wird daher aus als Orchestration bezeichnet. In Anbetracht, dass die Firma aktuell noch keine Forschung über Kubernetes, außer dem Fakt, dass es existiert und die aktuelle Problemlage Lösen könnte, betrieben hat, sollte dies meine Aufgabe werden. Das Ziel ist es, herauszufinden, welche Features Kubernetes und dessen Ökosystem bietet, zu analysieren wie diese funktionieren als auch zu überprüfen, ob diese konkret für das Projekt Sinn ergeben. Mithilfe der Erkenntnisse soll Basiswissen über die Containerorchestration sowie ein möglichst automatisch deploybares Walking Skeleton auf Grundlage des selektron-Basisprojektes entstehen. Darüber hinaus soll geprüft werden, inwieweit Kubernetes eine Integration von Windows-basierten Systemen ermöglicht und welche technischen Einschränkungen dabei bestehen. Die gewonnenen Erkenntnisse dienen als Entscheidungsgrundlage für eine mögliche Migraton der bestehenden Systemarchitektur hin zu einer Kubernetes-basierten Lösung.
 
 \section{Methodik}
 
@@ -179,7 +179,7 @@ Für das Evaluieren wurde entschlossen, eine möglichst Originalgetreue Distribu
 Nach der Wahl der Distribution folgte das Einarbeiten in Kubernetes. Dabei wurde mit den kompletten Grundlagen begonnen: wie bediene ich das Kommandozeilentool \texttt{kubectl}, was ist ein Pod, wie ist er definiert, wie binden Services sich an Pods, et cetera. Gleichzeitig wurde meiner ersten Aufgabe nachgegegangen, das Monitoring-Tool Graylog, welches selektron benutzt, um alle Logs der verschiedenen Services zusammenzuführen, auf Kubernetes zu portieren, um praktische Erfahrung zu sammeln. Währenddessen wurde ein Nachschlagewerk geschrieben und gepflegt, um diese Daten zusammengefasst an einer Stelle zu haben.
 
 \subsection{Helm}
-Schnell wurde klar, das Kubernetes Komponenten manuell schreiben und verwalten möglich ist, jedoch Limitationen aufweist. Ein Kernnachteil ist, dass \texttt{kubectl apply} nur Komponenten hinzufügen, aber nicht löschen kann, und man somit nichtmehr definierte Komponenten selbst verwalten muss. Darauf folgt das benutzen von Helm als Paketmanager, welches Charts definiert. Charts sind Sammlungen an Komponentendefinitionsvorlagen, die mit einer Values-Datei zu vollwertigen Kubernetes-Komponentendefinitionen werden, um als konfigurierten Release auf das Cluster gespielt zu werden. Dies hat den Vorteil, dass Helm-Charts mit einem Befehl installiert, geupgraded und deinstalliert werden können und eine Versionierung zwischen den Releases existiert die Rollbacks ermöglicht. Glücklicherweise pflegen die Entwickler von Graylog ebenfalls solch einen Chart, wodurch ich von meiner spartanischen Erstimplementation auf eine allumfassend bessere Version wechseln konnte. Bei der Installation hatte ich gleichzeitig das erste mal Kontakt mit Operatoren, konkret dem vom Graylog-Helm-Chart genutzten MongoDB-Operator. Operatoren sind Kubernetes-Erweiterungen bestehend aus Custom-Resource-Definitions (kurz CRDs) und mindestens einem Pod, welcher Instanzen der definierten CRDs (Custom Resources, CRs) überwacht, und daraufhin das Cluster entsprechend bedient. Der MongoDB Operator überwacht z.B. das Cluster nach MongoDB-Komponenten, in welchen eine Datenbank definiert wird, und erstellt daraufhin dynamisch die Datenbank nach den Anforderungen. Falls die Komponente editiert oder gelöscht wird, wird die dadurch erstellte Datenbank dementsprechend editiert oder gelöscht. Somit Verwaltet der Operator den Lebenszyklus der angefragten Resource, und der anfragende Service muss sich nicht um die genaue Implementation, sondern nur den Finalzustand kümmern. Dieser Ansatz wird \glqq{}Infrastructure as Code\grqq{} genannt, da Infrastruktur (in diesem Fall Datenbanken) mithilfe von Code statt manueller Prozesse bereitgestellt wird, und somit Konsistenz, Auditierbarkeit, Transparenz und Skalierbarkeit gewährt.
+Schnell wurde klar, das Kubernetes Komponenten manuell schreiben und verwalten möglich ist, jedoch Limitationen aufweist. Ein Kernnachteil ist, dass \texttt{kubectl apply} nur Komponenten hinzufügen, aber nicht löschen kann, und man somit nichtmehr definierte Komponenten selbst verwalten muss. Darauf folgt das benutzen von Helm als Paketmanager, welches Charts definiert. Charts sind Sammlungen an Komponentendefinitionsvorlagen, die mit einer Values-Datei zu vollwertigen Kubernetes-Komponentendefinitionen werden, um als konfigurierten Release auf das Cluster gespielt zu werden. Dies hat den Vorteil, dass Helm-Charts mit einem Befehl installiert, geupgraded und deinstalliert werden können und eine Versionierung zwischen den Releases existiert die Rollbacks ermöglicht. Glücklicherweise pflegen die Entwickler von Graylog ebenfalls solch einen Chart, wodurch ich von meiner spartanischen Erstimplementation auf eine allumfassend bessere Version wechseln konnte. Bei der Installation hatte ich gleichzeitig das erste mal Kontakt mit Operatoren, konkret dem vom Graylog-Helm-Chart genutzten MongoDB-Operator. Operatoren sind Kubernetes-Erweiterungen bestehend aus Custom-Resource-Definitions (kurz CRDs) und mindestens einem Pod, welcher Instanzen der definierten CRDs (Custom Resources, CRs) überwacht, und daraufhin das Cluster entsprechend bedient. Der MongoDB Operator überwacht z.B. das Cluster nach MongoDB-Komponenten, in welchen eine Datenbank definiert wird, und erstellt daraufhin dynamisch die Datenbank nach den Anforderungen. Falls die Komponente editiert oder gelöscht wird, wird die dadurch erstellte Datenbank dementsprechend editiert oder gelöscht. Somit Verwaltet der Operator den Lebenszyklus der angefragten Resource, und der anfragende Service muss sich nicht um die genaue Implementation, sondern nur den Finalzustand kümmern. Dieser Ansatz wird \glqq{}Infrastructure as Code\grqq{} genannt, in Anbetracht dessen, dass Infrastruktur (in diesem Fall Datenbanken) mithilfe von Code statt manueller Prozesse bereitgestellt wird, und somit Konsistenz, Auditierbarkeit, Transparenz und Skalierbarkeit gewährt.
 
 \subsection{GatewayAPI}
 Nachdem Graylog auf dem Cluster lief, war es jedoch noch nicht von extern erreichbar. Dafür ist Ingress zuständig. Ingress ist ein Spec, verwaltet von dem Kubernetes-Team\cite{k8sIngress}, welcher Layer 7 HTTP/S Routing erlaubt. Dieser Spec wird von IngressControllern implementiert, z.B. nginx oder Traefik. Da selektron jedoch nicht nur Layer 7, sondern auch Layer 4 Routing benötigt, um mit der SPS im Lager zu kommunizieren, wurde auf Ingress' Nachfolger, GatewayAPI gesetzt\cite{k8sGatewayAPI}. GatewayAPI ist genau wie Ingress ein Spec, welcher von extern programmierten GatewayControllern, z.B. Istio oder Traefik, implementiert wird. Er lernt aus den Defiziten von Ingress und trennt Routen, Gateways und GatewayClasses voneinander. Ebenfalls erlaubt er nicht nur HTTP/S, sondern auch gRPC, TCP und UDP-Verbindungen.