2022-06-24 Dt. SysOps Meeting-Notizen

öffentliches gitlab: https://gitlab.lrz.de/bib-public/folio-helm

In einem K8s-Namespace einmal die komplette Installation machen.

Elasticsearch über bitnami-Helmcharts, Kafka über bitnami-Helmcharts deployed.

Stroage Class mit Longhorn. Die Helmcharts werden woanders nicht out-of-the box funktionieren. Basieren aber auf den Helm-Charts von Steffen Köhler (Leipzig). 

Hosting von versch. Bibliotheken, wahrscheinlich im selben Cluster.

Okapi wird im lokalen gitlab gebaut. Globale Variablen verwenden, damit man nicht an verschiedenen Stellen editieren muss. Start von Okapi mit einem java-Befehl. Es wird ein Service erstellt und es gibt 3 verschiedene Pods, die geclustert sind. Mit einem Befehl installiert.

Absicherung des Supertenants, danach Installation der restlichen Module. mod-users, mod-permissions, mod-authtoken erstellt. Dann jobs gestartet, um diese Module bei Okapi anzumelden. Dafür Skripte geschrieben "init.sh". Von Steffen Köhler übernommen und erweitert für abgesicherten Supertenant. 

Davor noch ein Skript ausgeführt, welches den Superuser absichert. Dafür das Templating von Helm verwendet, um auch die Variablen zu nutzen. Variablen in secure-supertenant.yml.  secure-supertant-Skript i.W. von 2019, aber kompakter. 

Konfigurationen der einzelnen Module zusammen in einem einzigen Value-File, 2022-r1-auth.yaml. Hier werden auch die Images angegeben. Das ist eigentlich das einzige, was man verwalten muss, es sei denn, man braucht zusätzlich Features. Das wird für jedes Modul ausgeführt.  2 pods für authtoken benötigen ein gemeinsames Secret; das ist hier schon eingebaut.

2022-r1-auth.yaml installiert die Module, die man zur Authentifizierung benötigt. Danach Absicherung des Supertenants. Dann Deployment aller anderen Module.

Datei 2022-r1-all.yaml pfegt man, und behält sie auch. Dadurch hat man auch den Überblick, welche Module für welchen Tenant installiert sind. Überarbeitet, hatte bei Jason Root ca. 7000 Zeilen.

Arbeitet an Version für einen Upgrade-Prozess. FOLIO-Upgrade ist etwas spezieller.

Skript 2022-r1-all.yaml installiert ca. 50 Module. Danach muss noch der Tenant installiert werden.

Auflösung der Abhängigkeiten: Nutzung der Möglichkeiten von Kubernetes, dass es es noch einmal versucht, wenn es fehlgeschlagen  ist. Daher muss man nicht auf Reihenfolge achten, in der die Module deployed werden.  (Einige) Container direkt von folio-org geholt.

Letzter Schritt : Tenant (Mandanten) installieren. Woher soll das Image für Stripes kommen ? Das muss man selber bauen, OKAPI-URL und tenant: einbauen. Dafür wird eine CI-Pipeline benutzt. Für einen weiteren Tenant sollte nur die Datei tenants/values-demo.yml angepasst werden. Außerdem muss man per Tenant mitgeben, welche Module aktiviert werden sollen.

1 Pod, der das Frontend enthält und einen Job, der das Frontend registriert. Letzeres ist ein "relativ kompliziertes" Skript. register-tenant.sh. Erweitert, dass es mit abgesichertem Supertenant funktioniert. 

Das Skript ist direkt in den Files von dem Helm-Charts. D.h. das Skript wird eingelesen und anschließend ausgeführt. Daher kann man direkt an diesem Skript arbeiten. pod benutzt Alpine Linux, installiert curl und bash.  Legt versch. Permission an. Generiert relativ viele Secrets (z.B. für Supertenant, admin).  Damit sollte man jetzt über einen Ingress auf Stripes zugreifen können.... kann man auch.

Aktuelle Arbeiten an LDP-Deployment.

Stripes Modul in K8s-Cluster mit Calico  gebaut. Das dauert 13 Minuten. 

Zur Clusterung des Stripes gibt es eigentlich keinen Grund, der Browser lädt sich die javascript-Dateien ja nur einmal herunter.

Deployment der Datenbank über Kubegres. Müssen sie sich noch genauer anschauen.  Kubegres erstellt einen Operator. Der erstellt dann ein Cluster aus einem Main und zwei Replicas (1,2,3). Nimmt offiziellen Postgres-Container, wird nicht über ein Helm-Chart deployed. Rendering von Konfigurationsdateien. Es ist sehr simpel, wird aber momentan nicht wirklich supported. Erstellt okapi und folio user mit entsprechender Datenbank. Die Parameter kommen auch aus den global values. Eine verbindende Ressource vom Typ "Kubegres". Nicht einheitlich, von daher problematisch. Gucken nach Alternativen. Gibt dt. README (in gitlab folio-helm), explizit zu Kubegres. Bei Crunchy ein anderes Problem gehabt. Falsches Passwort-Hash gespeichert. Crunchy macht es für sie ungünstig, wird aber öfter benutzt. Nutzer werden in Kubegres in dem Skript angelegt. Besser wäre es , das "agnostisch" zu machen.

Voraussetzungen im Cluster: Wird direkt über HTTPS erreicht. K8s-Cluster über kubespray installiert. Man sieht K8s-Dashboard. Hausintern wurde ein anderes Tool für die K8s-Verwaltung ausgesucht, Kubermatic, welches ein Konkurrenzprodukt zu Rancher ist. Deswegen wurde kein Rancher-Cluster gewählt. Wenn man Rancher Support kaufen will, wird es unheimlich teuer.

User-Zugang könnte man etwas staffeln, um den Zugang sicherer zu machen.

Storage Classes: (nfs-Subdir ?), Longhorn, ... Jetzt im Moment wird hauptsächlich Longhorn eingesetzt, weil es komfortabel ist. Minio-Server noch nicht vollständig installiert. Zusätzliches Elastic-Cloud so installiert, dass sie den Kubernetes-Cluster monitort. Da laufen alle Log-Meldungen herein. 

Netzwerkschicht: MetalLB als Software Load-Balancer, dazu ein nginx-Ingress-Kontroller. Damit kann man die Dinge von außen zugänglich machen. Von außen läuft der Zugriff über eine einzige IP-Adresse, aber unterschiedliche Namen. Cert-Manager so konfiguriert, dass er Zertifikate aus LetsEncrypt holt, wenn ein neuer Ingres kommt. 

Neben abgesicherten Supertenant noch einen Tenant installiert. Man könnte innerhalb von wenigern Minuten einen zweiten Tenant installieren. Unterscheidung der Tenants über (k8s-)Namespace z.B. "folio-kiwi-h1". Am längsten dauert es, ein neues Stripes-Modul zu bauen. 

Im gitlab platform-complete geklont. Dann gibt es einen CI-Job, der in dem K8s-Cluster einen Stripes-Container baut und in die Registry (gitlab) wieder herein legt. Das Helm-Chart nimm dann den Container wieder dort heraus und installiert ihn.

FOLIO gitlab-runner. gitlab Server schickt an den K8s-Server einen Job "bau mal ein neues Image". Dann wird das dort gebaut und wieder zurück geschickt. Das läuft über Tags.

Alles, was mit Helm-Charts zu tun hat, ist in dem gitlab-Repo. Bitte melden, wenn irgendetwas fehlt. Bitte Verbesserungsvorschläge an Florian. 

Okapi-Hazelcast hat relativ viele Probleme gemacht. Jedes neue Okapi-Release bekommt über das Templating ein neues Cluster. Benötigt Hazelcast-Rollen. Evtl. geht es auch mit normalen Rollen. 

3 Master Nodes, 8 Worker Nodes.

control-Plane kubernetes-Master läuft auch auf den normalen Nodes; wäre aber besser das auf VMs auszulagern. Momentan kann man 110 pods auf dem Server starten. Für 200GB RAM Nodes ist das "zu langweilig". → Ressource-Limits erhöhen. Design des K8s-Clusters anpassen. Läuft bisher aus vom RZ ausgemusterten Rechnern.

Ausfallsicherheit mit Kubernetes kann man gut hinbekommen.

Alles etwas modularer gemacht als bei Jason Root.

Florian K. am 29.07. wieder da. 

Explizit Feedback willkommen !!!

Im August will Florian K. dieselbe Demo auf englisch in den Internationalen SysOps halten !

Florian am nächsten Freitag (01.07.) noch da. Dann Gelegenheit für eine weitere Diskussion hier in dieser Runde um 13 Uhr.