Die Bezeichnung “achim” ist eine Abkürzung für Advanced Cloud Hyperscaling Infrastructure Manager. Dabei handelt es sich um ein kleines Programmierprojekt, das ich diesen Sommer aus der Not heraus ins Leben gerufen habe. Dieses Werkzeug dürfte wohl nur einige wenige der sich auf diesem Forum tummelnden Benutzer interessieren. Es soll auch weniger um die Technik gehen als darum, wie man ein praktisches Problem mit etwas Automatisierung pragmatisch und kostengünstig lösen kann.
Natürlich kommt auch hier wieder Debian 12 “Bookworm” zum Einsatz. Immerhin habe ich diesen Spätsommer dank achim ca. 120 angehende Informatiker das erste mal mit Debian in Kontakt gebracht.
Der Quellcode steht auf GitHub unter patrickbucher/achim zur Verfügung und untersteht der MIT-Lizenz.
Problem
Ich unterrichte an einer Berufsschule ein Modul zum Thema “Cloud”. Da es sich hierbei böse gesagt um einen Marketingbegriff und nett gesagt um ein Bereitstellungsmodell für Rechen- und Speicherkapazität handelt, ist es recht anspruchsvoll das Modul mit sinnvollen Inhalten zu füllen. Nach einer Einführung in verschiedene Arten von Datenspeichern (DuckDB, Redis, S3/Minio) gibt es darum zwei Möglichkeiten: Ein Monitoring-Werkzeug in Go weiterzuentwickeln und dessen Konfiguration in Redis auszulagern einerseits; und das Aufsetzen von Nextcloud inkl. Migration des Datenspeichers auf S3/Minio. Alle Aktivitäten haben gemeinsam, dass sie auf einer Linux-VM stattfinden sollen.
Cloud-Ressourcen werden mir von der Schule keine zur Verfügung gestellt. Das Problem liegt auch nicht bei der Schule, sondern bei den Cloud-Anbietern: Die Schule benötigt volle Kostenkontrolle und -Transparenz, die Cloud-Anbieter hingegen lassen lieber die Rechnung mit den bezogenen Ressourcen zusammen hochskalieren.
Zum Glück gibt es neben den drei grossen Cloud-Anbietern (AWS, Azure und Google Cloud) auch noch einige kleine Anbieter, wie z.B. die Firma Exoscale im schweizerischen Lausanne. (Disclaimer: Ich habe mit dieser Firma ausserhalb meiner Kundenbeziehung nichts zu tun. Ich verwende den Anbieter einfach exemplarisch, war aber immer sehr zufrieden damit.) Dieser Anbieter verfügt über ein Pre-Paid-Modell, womit man Budget aufladen und dann aufbrauchen kann. Ist das Budget weg, kann man auch keine Ressourcen mehr beziehen. (Was in diesem Fall genau passieren würde, habe ich noch nicht ausprobiert.)
Weiter verfügt Exoscale über eine API, was man von einem professionellen Cloud-Anbieter heutzutage auch erwarten darf. Ressourcen wie virtuelle Maschinen können damit automatisch erstellt, hoch- und heruntergefahren und schliesslich wieder freigegeben werden.
Kosten
Die volle Kostenkontrolle ist zwar ein gutes Argument für einen Anbieter. Die Kosten sollen aber nicht nur kontrollierbar, sondern auch möglichst tief ausfallen. Auch hier schafft Exoscale Transparenz mit dem Preismodell und einem Kostenrechner.
Stellen wir also ein paar Berechnungen an. Die Rahmenbedingungen lauten:
- 120 Kursteilnehmer mit je einer Linux-VM
- Übungsbetrieb während zehn aufeinanderfolgenden Wochen von jeweils einer Doppellektion (90 Minuten)
- Eigenständige Übungen während der ersten sechs Wochen
- Zusammenhängende Übung während der letzten vier Wochen
Angenommen, die VMs sollen einmal aufgesetzt, gestartet und dann während zehn Wochen laufen gelassen werden, ergäben sich dadurch folgende Kosten:
Code: Alles auswählen
120 * 10 * 7 * 24 * (0.00729 + 10 * 0.00014) = 1751.90
Wenn man die VMs in den ersten sechs Wochen jeweils für die Übung erstellt und nachher direkt wieder abräumt, käme diese erste Phase wesentlich günstiger:
Code: Alles auswählen
120 * 6 * 1.5 * (0.00729 + 10 * 0.00014) = 9.39
- Compute: 120 * 4 * 1.5 * 0.00729 = 5.25
- Storage: 120 * 4 * 7 * 24 * 10 * 0.00014 = 112.90
- Total zweite Phase: 5.25 + 112.90 = 118.15
Fazit: Für den reinen Übungsbetrieb ist die Cloud sehr kostengünstig. Bezieht man die Ressourcen jedoch permanent, wird es schnell teuer.
Automatisierung
Der Kostenrahmen und die Art des Ressourcenbezugs wäre nun festgelegt. Nun stellt sich die Frage, wie die einzelnen Kursteilnehmer zu ihrer VM kommen. Hierzu habe ich mir eine kleine Datenstruktur zurechtgelegt: die sogenannte group-Datei. Jede Datei steht für eine Gruppe, die etwa eine Schulklasse repräsentieren kann. Ressourcen der gleichen Gruppe können so gemeinsam bereitgestellt, angesteuert und wieder freigegeben werden. So eine group-Datei, die im YAML-Format vorliegen soll, kann etwa folgendermassen aussehen:
Code: Alles auswählen
name: students
users:
- email: alice_bobson@frickelbude.ch
name: alice_bobson
ssh-key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJhx+5Z/Ao+9w3EujyXcKcE8Wzw0uyApawro5dlMXQwa alice_bobson@frickelbude.ch"
permanent: true
- email: bob_allison@frickelbude.ch
name: bob_allison
ssh-key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJhx+5Z/Ao+9w3EujyXcKcE8Wzw0uyApawro5dlMXQwa bob_allison@frickelbude.ch"
permanent: false
- email: mallory_malfeasance@frickelbude.ch
name: mallory_malfeasance
ssh-key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJhx+5Z/Ao+9w3EujyXcKcE8Wzw0uyApawro5dlMXQwa mallory_malfeasance@frickelbude.ch"
Es folgt eine Auflistung der Benutzer, in diesem Fall drei an der Zahl. Zu jedem Benutzer werden folgende Informationen abgelegt:
- email: Die E-Mail-Adresse der Person, die ich so aus der Schulverwaltungssoftware exportieren kann.
- name: Der Benutzername der Person, die ich von der E-Mail-Adresse ableite (der Teil links vom @-Zeichen).
- ssh-key: Der SSH-Public-Key, der mir von allen Benutzern eigens dafür zugestellt wird. (Das ist der aufwändigste Teil der initialen Administration, da kaum automatisierbar).
- permanent: Diese Einstellung legt fest, ob die jeweilige VM des Benutzers nach dem Übungsbetrieb erhalten bleiben (permantent: true) oder danach zerstört werden soll.
Das Verwalten der VMs (und einige Zusatzaufgaben, die etwa beim Zusammenspiel mit Ansible hilfreich sind) habe ich mit einem Python-Kommandozeilenwerkzeug namens achim gelöst. Das Projekt verwendet einige gängige Python-Libraries (click für das Kommandozeileninterface, requests für die HTTP-Anfragen, PyYAML zum Lesen und Schreiben von YAML-Dateien sowie die Exoscale-spezifische Bibliothek requests-exoscale-auth für die Authentifizierung). Von einer jungfräulichen Debian-VM ausgehend wird achim folgendermassen aufgesetzt:
Zuerst müssen für das Klonen und die Inbetriebnahme einige Pakete installiert werden:
Code: Alles auswählen
sudo apt install -y git python3.11-venv
Code: Alles auswählen
git clone https://github.com/patrickbucher/achim.git
cd achim
python -m venv env
. env/bin/activate
pip install .
Code: Alles auswählen
cp sample.env .env
Code: Alles auswählen
EXOSCALE_API_KEY=EXO****
EXOSCALE_API_SECRET=****
EXOSCALE_ZONE=ch-gva-2
Arbeitsablauf
Achim ist nun eingerichtet und betriebsbereit. Ein typischer Arbeitsablauf damit sieht nun folgendermassen aus:
- Die VM-Instanzen für eine ganze Gruppe werden mithilfe von achim create-group und anhand der group-Datei erstellt.
- Die automatisch zugewiesenen IP-Adressen werden mittels achim inventory in ein Ansible-Inventory exportiert. Dabei wird pro Benutzer und Gruppe ein Abschnitt erstellt, der dann mithilfe von ansible-playbook -l TARGET PLAYBOOK bzw. direkt über die hosts-Angabe im Playbook angesteuert werden kann.
- Mithilfe von achim user-playbook wird aus der group-Datei ein Ansible-Playbook erstellt, das für jeden Benutzer den SSH-Schlüssel deployed. (Hierzu wird der Benutzername im Playbook über die hosts-Einstellung angegeben, damit der richtige SSH-Schlüssel auf dem jeweiligen Host landet.)
- Nun können je nach Bedarf (d.h. je nach Übung) andere Ansible-Playbooks gezielt auf Gruppen/Besitzer auf den passenden Hosts ausgeführt werden.
- Mit achim overview wird eine HTML-Datei erzeugt, die zu jedem Benutzer die IP-Adresse und den SSH-Befehl zum Einloggen anzeigt. Diese HTML-Datei kann ich dann beispielsweise im Schulzimmer projizieren, damit alle Kursteilnehmer ihre Koordinaten mitbekommen.
- Am Ende der Doppellektion kann ich die VMs mit achim stop-group herunterfahren bzw. mit achim destroy-group komplett entfernen. (Bei letzterem gibt es ein Flag, das die als permanent markierten VMs auch gleich mitlöscht, was standardmässig nicht pasiert.)
- Die permanenten VMs kann ich in der nächsten Woche wieder mit achim start-group hochfahren.
Fazit
Mithilfe einer schlanken Python-Kommandozeilenanwendung und Ansible konnten nun fast ein Semester lang effizient und kostengünstig Cloud-Ressourcen für 120 Kursteilnehmer zur Verfügung gestellt werden. Ein Cloud-Anbieter, der mit einem Pre-Paid-Modell volle Kostenkontrolle anbietet und transparent abrechnet, war hierzu auch sehr hilfreich: gerade wenn man seine Organisation von einem unbekannten Anbieter (anstelle von Microsoft Azure) überzeugen will.
Die Lösung müsste für andere Kurse noch erweitert werden, sodass man mehrere virtuelle Maschinen pro Kursteilnehmer verwalten könnte. Ein selbständiges Hoch- und Herunterfahren der VMs durch die Kursteilnehmer wäre nur über eine zusätzliche Portallösung möglich, was aber je nach Bedarf den Aufwand wert sein dürfte.
Für den reinen Übungsbetrieb sind aber Cloud-VMs wesentlich komfortabler als lokal installierte und verwaltete VMs.
Dank Debian GNU/Linux 12 “Bookworm”, womit sich auf einer VM mit einer CPU, 512 MB Ram und 10 GB SSD-Speicherplatz Nextcloud zumindest testhalber komfortabel betreiben lässt, konnten die Kosten tief gehalten werden.