From 9bff60f1e1df18ee12fb2b290f09e2a8b580bc11 Mon Sep 17 00:00:00 2001 From: Joerg Behrmann Date: Thu, 12 Jan 2023 20:31:46 +0100 Subject: [PATCH 2/2] RFC how to run the server --- rfcs/001-setup.md | 226 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 226 insertions(+) create mode 100644 rfcs/001-setup.md diff --git a/rfcs/001-setup.md b/rfcs/001-setup.md new file mode 100644 index 0000000..1da6eec --- /dev/null +++ b/rfcs/001-setup.md @@ -0,0 +1,226 @@ +--- +title: Blaupause für die Struktur es ZaPF-Servers +author: Jörg Behrmann +date: 2023-01-10 +status: Draft +--- + +# Blaupause für die Struktur es ZaPF-Servers + +Dieser RFC soll die Struktur des ZaPF-Servers beschreiben, das bedeutet wie +Dienste, Infrastrukturdienste und Dienste für ZaPFika, auf dem Server +organisiert werden. + +## Historischer Abriss + +In grauer Vorzeit waren alle Dienste der ZaPF verteilt und wurden von der +Universität gehostet, die sich zu einem Zeitpunkt bereitgefunden hatte. Dies +hatte den Nachteil, dass es keine Kontrolle darüber gab was man hatte. Der +Zustand war nicht haltbar. Man wollte es selbst richtig machen. + +Die ZaPF schuf daraufhin das Gremium des TOPFes und schaffte einen eigenen +virtuellen Server an, dessen installierte Software hauptsächlich händisch +gepflegt wurde. Das händische Gefrickel war nicht maintain- und der +Gesamtzustand nicht haltbar. Man wollte es richtig machen. + +Auf einem zweiten Server wurde mit der Konfigurationsverwaltung Ansible und +Containern aus vollständigen Betriebssystemimages als eigenständigen Hosts +("Mikro-VMs") ein Sytem aufgebaut. Die Idee hinter dieser Struktur war einzelne +Dienste voneinander zu isolieren. Die Ansible-Rollen wurden für +Wiederverwendbarkeit abstrahiert. Das Setup mit vielen eigenständigen Hosts und +abstrahierten Ansbible-Rollen stellte sich in der Übergabe an neue DECKEL als zu +komplex und unflexibel heraus, da Dokumentation fehlte, so dass Dinge "mal eben" +händisch gemacht wurden. Damit kam man sich ins Gehege mit Dingen, die von +Ansible gemanaged wurden und die Ansible-Rollen bitrotteten - in ihnen +eingebaute Annahmen funktionierten nicht mehr. + +Aufgrund steigender Beliebtheit wurden neuere Projekte als gestellte +Docker-Container ausgerollt und der Plan vorgebracht zum Zwecke der +Einheitlichkeit **alle** Softwarekomponenten "zu dockern". + +## Ziele + +1. Einzelne Dienste und der gesamte Server sollen restartbar sein. +2. Einzelne Dienste und der gesamte Server sollen reproduzibel installierbar. +3. Einzelne Dienste und der gesamte Server sollen automatische + Sicherheitsupdates erhalten +4. Händisches Gefrickel soll vermieden werden. + +## Annahmen + +Das Scheitern der bisherigen Strukturen lässt sich zurückführen auf fehlende +Dokumentation und zu komplexen Strukturen, die theoretisch vorteilhaft sind, +aber praktisch eine zu steile Lernkurve haben. + +Potentielle DECKEL sind Studierende mit geringen Linuxkenntnissen. Sie können +sich im Terminal bewegen und per SSH auf Rechner zugreifen, Dateien editieren +und haben git schonmal benutzt. Eine weitere Ausbildung über dieses Niveau ist +notwendig. + +Die von Linuxdistributionen geleistete Integrationsarbeit sollte so weit wie +möglich genutzt werden, so dass diese Arbeit durch den TOPF nicht gedoppelt +werden muss. + +## Technologien + +Der Vorschlag ist die folgenden Technologie zu benutzen. + +### Linuxdistribution als langweilige, maximal statische Infrastruktur + +Linuxdistrbutionen, wie das von uns verwendete Debian, leisten den Dienst +Software in eine konsistent installierbare Form zu bringen und diese aktuell zu +halten. Im Fall von Debian werden die Versionen für die Zeit eines Releases, +überlicherweise etwa zwei Jahre, stabil gehalten und nur Sicherheitslücken +geschlossen. Dies erlaubt Updates automatisch einzuspielen. + +Distributionen paketieren nicht alle Software, aber Infrastrukturkomponenten, +wie Mailserver, Datenbanken und Webserver sind verfügbar und können auf diese +Art und Weise einfach installiert und in Stand gehalten werden. + +Auch ist anzunehmen, dass falls Menschen einmal etwas unter Linux installiert +haben, sie das über die Paketverwaltung ihrer Distribution getan haben und es +den geringsten mentalen Overhead hat. + +Aus diesem Grund bietet es sich an, so viele Komponenten wie möglich direkt aus +den Distributionsquellen zu beziehen, da dort die Arbeit der Integration schon +geleistet wurde und nur noch die, auch bei anderen Lösungen notwendige, +Konfiguration bleibt. + +### Pakete oder OCI-Container für Userdienste + +Für nicht von der Distribution paketierte Software bieten sich OCI-Container +oder in Einzelfällen, wenn die Pakete eigenständig sind und nicht in das System +eingreifen, auch Fremdpaketquellen von namhaften Anbietern (mögliche Beispiele: +GitLab, Synapse). + +### Ansible Playbooks in einem Monorepo für Infrastruktur + +Konfigurationsmanagementsysteme erlauben die reproduzible und idempotente +Konfiguration von Systemen. Sie sind der händischen Applikation von +Konfiguration oder ad hoc-Skripten vorzuziehen, da sie weniger fehleranfällig +sind. + +Ansible ist das vermutlich am weitesten verbreitete System und wurde vom TOPF +schon eingesetzt - mit gemischtem Erfolg. Eine Hauptursache dürfte in dem +komplexen Mikro-VM-Setup liegen, aber auch in der starken Modularisierung der +Ansible-Rollen mit vielen Git-Submodulen. + +## Vorgehen + +Es wird vorgeschlagen wie folgt vorzugehen: + +1. Es gibt ein Ansible-Tutorial für die Menschen durchgeführt, die eines haben + wollen. +2. Die bestehenden Ansible-Rollen und Playbooks werden in ein Monorepo + umgezogen, d.h. es wird ein Repo geschaffen, das den kompletten Zustand des + Servers abbilden soll. +3. Die Ansible-Rollen und Playbooks für nicht länger benutzte Dienste werden + entfernt. +4. Die aktuelle Produktionskonfiguration wird verglichen mit dem letzten in den + Ansible-Rollen dokumentierten Zustand. +5. Ansible-Rollen werden demodularisiert und so weit möglich auf unser + spezifisches Setup spezialisiert. Dies geschieht per Pull Requests gegen das + oben genannte Repo unter Review aller Interessierten. +6. Playbooks oder Rollen für fehlende Komponenten werden hinzugefügt. +7. Ein RFC-Prozess für zukünftige Änderungen wird etabliert. + +### Offene Fragen + +1. Unser Basissystem ist einer der ältesten Teile und einzelne + Infrastrukturdienste laufen schon in neueren Versionen in Mikro-VMs + ("Nspawn-Containern"). Ein Rollback auf eine ältere Version ist nicht ratsam. + + Eine mögliche Antwort wäre die Rollen gegen ein frisches Zweitsystem, + z.B. eine VM auf dem Server, getestet wird und dann nach einer Datensicherung + zu einem Stichtag das Gastgebersystem neu zu installieren. + +## Alternativen + +Alle diese Alternativen sind nicht ausschließlich und können kombiniert werden. + +### "Handgefrickel" + +Alles kann händisch gemacht werden. Dies hat den Nachteil, dass nicht +nachvollziehbar ist, was gemacht wurde, und ist repetitiv und fehleranfällig. + +### "Alles dockern" + +Jede Softwarekomponente kann einzeln in einen Container verpackt werden. Dies +hat den Vorteil maximaler Kapselung und erlaubt es beliebige Versionen +vollkommen getrennt voneinander zu betreiben. + +Der Nachteil ist wachsender Zoo an unabhängigen Containern, deren Inhalte und +Patchlevel gemanaged werden müssen, jeder Container muss für Sicherheitsupdates +einzeln neugebaut werden und verschiedene Softwareversionen vergrößern die Bugs +die auftreten können multiplikativ. + +Das Bauen von Containern doppelt die Paketierung von Software durch +Distributionen und verschiebt die Arbeit Softwarekomponenten zu integrieren zu +uns. + +Es bleibt offen wie die Container auf den Server gebracht werden. +1. Die Container können händisch kopiert und gestartet ewrden. Hat die selben + Probleme die generell unter "Handgefrickel" genannt sind +2. Die Container können durch ein Konfigurationsmanagementsystem, z.B. Ansible, + kopiert und gestartet werden. In diesem Fall wird das + Konfigurationsmanagementsystem nicht eingespart und muss trotzdem in + zumindest ähnlichen Rudimenten erlernt werden. + +### Dokumentation + +Dokumentation kann verschiede Aufgaben erfüllen, die wichtigsten davon: +1. Was wurde gemacht? +2. Warum wurde es gemacht? + +Alles kann minutiös dokumentiert werden, so dass es reproduzibel ist. Dies +garantiert nicht, dass das ist was in der Realität gemacht wurde oder dass bei +sich ändernden Umständen die Dokumentation an sich wechselnde Realitäten +angepasst wird. Weiterhin ist eine hinreichend genau Spezifikation von dem was +gemacht wurde ununterscheidbar von einer Beschreibung in einem +Konfigurationsmanagement. + +## Glossar + +### Chroot + +Ein *Change Root* ist ein Teilbaum des Verzeichnisbaumes dessen Wurzel als neues +Wurzelverzeichnis (`/`) benutzt wird. Wurde vorallem historisch als +Sandboxingmethode benutzt um Zugriff auf Dateien in anderen Teilbäumen des +Verzeichnisbaumes zu verhindern. + +### VM + +Eine *Virtuelle Machine* ist ein virtueller Computer, dessen Hardware +vollständig emuliert wird und eigenständig auf dieser läuft und keine Ressourcen +mit seinem Gastgeber teilt - über die hinaus, die dieser seinem Gast zur +Verfügung stellt. + +### Namespaces + +Namespaces sind Kontexte in denen Programme laufen können in denen Konzepte wie +Zeit und Raum anders definiert sind, d.h. ihnen eine andere Realität als die +globale vorgetäuscht wird, z.B. kein einem laufenden Programm durch einen Mount +Mamespace ein anderer Verzeichnisbaum als der globale gegeben werden, auf den +dieser das laufende Programm dann nich mehr zugreifen kann, oder durch einen +Time Namespace eine andere Uhrzeit. + +Namespaces werden primär dazu benutzt um laufende Programme voneinander zu +isolieren und sind im Servicemanager verfügbar und werden von zahlreichen von +Distributionen paketierten Programmen schon zur Härtung gegen Sicherheitslücken +benutzt. + +### Container + +Container sind ein überladener Begriff, der verschiedene Dinge meinen kann, von +vollstándigen Betriebssystemimages als Mikro-VM zu abgesreckten Bundles, die +eine einzige Binary enthalten. Heute haben Container hauptsächlich zwei +Bedeutungen hat: + +1. Ein "Chroot auf steroiden" oder "Drei Namespaces in einem Trenchcoat", eine + Kombinationen aus Namespaces um laufende Programme voneinander zu isolieren. +2. Ein Mechanismus um Software zu verteilen, so dass die Programme darin + beliebige andere Versionen nutzen können als die des gastgebenden Systems. + +Der aktuell verbreitetste Standard für Container sind OCI-Container, meist +"Docker"-Container genannt, nach der ursprünglich meistgenutzen Implementation - +so wie alle Nussnougatcreme Nutelle ist. -- 2.39.0