Unser Installationsbundle für den Kommentierungsserver auf Kubernetes besteht aus mehreren Dateien: Im Folgenden gehen wir davon aus, dass Ihnen bekannt ist, wie Dockerfiles und .yml Konfigurationsdateien in Kubernetes zu verwenden sind. Dockerfile* In den drei Dockerfiles befinden sich die Anweisungen, wie die drei für die Kommentierung benötigten Container erstellt werden. Die so erstellten Container müssen dann in Ihre docker-registry gepusht werden, um sie in Kubernetes zu nutzen. Ordner comments-keycloak-theme, commenting.jar, nginx.conf, keycloak-docker-entrypoint.sh Diese Dateien werden von den Dockerfiles verwendet, um die einzelnen Container zu erstellen. Eine Modifikation ist hier in der Regel nicht notwendig. *-kubernetes-*.yml In den fünf YAML-Dateien befinden sich die Konfigurationen für Kubernetes, um unseren Service starten zu können. Diese dienen als Orientierung und es können je nach Ihrer Kubernetes-Konfiguration Anpassungen nötig sein. In der 0-kubernetes-ns.yml ist der Namespace definiert, in dem die graphomate comments Entitäten in Kubernetes erstellt werden. Die 1-kubernetes-role.yml definiert die Rollen die notwendig sind, damit die graphomate services die Konfigurationen lesen dürfen. Die Datei 2-kubernetes-config.yml definiert unterschiedliche Konfigurationsparameter für
den unseren Service. Dazu gehören die Verbindungsdaten für die Datenbanken in denen die Kommentare und die Benutzer gespeichert werden. Diese können auch in der selben Datenbank gespeichert werden. Dafür sind in PostgreSQL zwei Schemata notwendig. Bisher konnten wir auch erfolgreich MSSQL auf Azure ohne Schemata testen. Die Konfiguration dafür ist in etwas komplexer als die für PostgreSQL und kann bei Bedarf durch uns erklärt werden. Auch die Definition für den Mailserver werden hier getätigt. Dieser wird verwendet um einem Benutzer der in einem Kommentar erwähnt wurde darüber per Mail zu benachrichtigen. In der 3-kubernetes-secrets.yml werden Zugangsdaten für die Datenbanken, den Mailserver und den initialen Administrator gepflegt. Diese sind wie für Kubernetes üblich Base64 encodiert. In 4-kubernetes-deployment.yml werden die drei für unseren Service benötigten Container Konfiguriert. Diese sind in unserem Bespiel alle in einem Pod vereint und verwenden temporäre in-memory Volumes. Es steht ihnen natürlich frei, andere, bespielsweise persistente, Volumes zu verwenden und die Container für besseres Load-Balancing in unterschiedlichen Pods zu verteilen. Dafür ist allerdings im Fall von dem keycloak-Container eine relative komplexe Konfiguration und eine Anpassung der nginx.conf für den Nginx-Container notwendig, auf die wir in diesem Rahmen nicht eingehen wollen.
Die drei Docker-Container müssen mit den von uns ausgelieferten Dockerfiles erstellt und in Ihre von kubernetes verwendete Docker-Registry gepusht werden. Nachdem die Konfigurationsparameter und Secrets angepasst wurden, sollten diese in Kubernetes angewendet werden. Außer der erstellung Erstellung einer Datenbank und der Schematas übernimmt unser Service die restliche Konfiguration der Datenbank selbst, sobald der Service das erste Mal gestartet wird. Vor den Port 80 des Nginx-Containers sollten Sie bspw. einen Ingress-Controller setzen, der die SSL Terminierung übernimmt und den Port nach außen mit SSL gesichert exponiert. Weitere Port Ports auf unseren Service sind nicht notwending, da der Nginx-Container hier als Reverse-Proxy fungiert. Nach dem ersten Start muss aus der Keycloak-UI unter <Server URL>/auth für den “frontend”-Client das Client-Secret ausgelesen werden. Dieses soll dann in die Kubernetes-Secrets unter “KEYCLOAK_CLIENT_SECRET” eingefügt werden. Ein anschließender Neustart der Container ist notwendig. Wenn Sie den Service erfolgreich installiert haben, können Sie drei Dinge tun, um dessen Funktionsfähigkeit zu überprüfen. : An der Root-URL auf den Service, sollten ein JSON mit Informationen zu dem Service und der installierten Version erscheinen. <Server URL>/auth sollte die Bedienoberfläche von Keycloak öffnen, in der Sie sich mit den Daten des initialen Admin-Benutzers einloggen können, wenn Sie auf “Administration Console” klicken. Hier können Sie auch andere Ident-Provider an unseren Service anbinden. Bswp. sind hier Active Directory per SAML und externe OAuth Provider zu nennen. Für weitere Informationen hierzu konsultieren Sie bitte die Dokumentation von Keycloak. Als letztes überprüfen Sie bitte, ob unter <Server URL>/commenting/administration/ unsere Bedienoberfläche für das Backend erscheint. Hier können Sie, mit einem gültigen Benutzer (bspw. wieder der Admin), bestehende Kommentare einsehen, diese bearbeiten und auch neue erstellen. Gleichzeitig haben Sie die Möglichkeit neue Benutzer zu erstellen und
diesen eine von drei Rollen zuzuweisen. Die Rolle “Viewer” kann Kommentare nur anzeigen, “Editor” kann diese erstellen + bearbeiten und “Admin” kann zusätzlich noch User erstellen und ändern |