🏷️ dfde  🏷️ programming  🏷️ education  🏷️ linux  🏷️ tech  🏷️ unix 
📆 15.12.2024

achim

Advanced Cloud Hyperscaling Infrastructure Manager

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. Es hier 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:

Die Micro-Instanz (512 MB RAM, 1 CPU-Core) kostet pro Stunde CHF 0.00729. Für den Storage (10 GB) muss man pro Gigabyte und Stunde weitere CHF 0.00014 rechnen. Das klingt nach wenig, aber diese Zahl wird mehrmals mit den anderen Faktoren multipliziert.

Angenommen, die VMs sollen einmal aufgesetzt, gestartet und dann während zehn Wochen laufen gelassen werden, ergäben sich dadurch folgende Kosten:

120 * 10 * 7 * 24 * (0.00729 + 10 * 0.00014) = 1751.90

CHF 1751.90 ist zu teuer, dass man das eben mal für einen einzelnen Kurs auslegen könnte. Eine günstigere Lösung muss her.

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:

120 * 6 * 1.5 * (0.00729 + 10 * 0.00014) = 9.39

In der zweiten Phase von vier Wochen sollen die VMs jedoch bestehen bleiben, damit man in der Folgewoche wieder dort weitermachen kann, wo man zuletzt aufgehört hat. Den Storage zahlt man jedoch die ganze Zeit:

Damit kosten die beiden Phasen 9.39 + 118.15 = 127.54. Mit einer Sicherheitsmarge für zusätzliche Übungslektionen und für hektische Tage, an denen der Lehrer vergisst die VMs rechtzeitig herunterzufahren, sollte ein Budget von CHF 200.- damit ausreichend ‒ und auch akzeptabel sein.

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:

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"

Die Gruppe hat einen Namen (name), dieser lautet hier “students”. Der Name muss über verschiedene group-Dateien hinweg eindeutig sein.

Es folgt eine Auflistung der Benutzer, in diesem Fall drei an der Zahl. Zu jedem Benutzer werden folgende Informationen abgelegt:

achim

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:

sudo apt install -y git python3.11-venv

Anschliessend kann achim über den Quellcode (via Git) installiet werden:

git clone https://github.com/patrickbucher/achim.git
cd achim
python -m venv env
. env/bin/activate
pip install .

Weiter muss man sich auf dem Portal einen Key erstellen, der dann in einer Datei namens .env lokal abgelegt werden soll. Eine Vorlage ist unter sample.env vorhanden und kann kopiert werden:

cp sample.env .env

Die Angaben sind anhand des erstellten Schlüssels zu übernehmen:

EXOSCALE_API_KEY=EXO****
EXOSCALE_API_SECRET=****
EXOSCALE_ZONE=ch-gva-2

Die Zone ch-gva-2 bezeichnet Genf. In Deutschland beispielsweise dürfte de-fra-1 (Frankfurt am Main) oder de-muc-1 (München) die bessere Lösung sein, zumal die Lichtgeschwindigkeit selbst in der Cloud nicht skaliert. Wichtig ist es, sich von Beginn an für eine Zone zu entscheiden, da die Ressourcen anschliessend in dieser festgelegten Zone liegen, und die zugrundeliegende API die Ressourcen über das Zonenpräfix ansteuert. (Wechselt man die Zone nachträglich, können die bestehenden Ressourcen in der anderen Zone damit nicht angesprochen werden.)

Arbeitsablauf

Achim ist nun eingerichtet und betriebsbereit. Ein typischer Arbeitsablauf damit sieht nun folgendermassen aus:

  1. Die VM-Instanzen für eine ganze Gruppe werden mithilfe von achim create-group und anhand der group-Datei erstellt.
  2. 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.
  3. 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.)
  4. 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.
  5. 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.
  6. 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.)
  7. Die permanenten VMs kann ich in der nächsten Woche wieder mit achim start-group hochfahren.

Die Verwendung von achim ist in der README-Datei im Abschnitt Usage erklärt. Zusätzlich habe ich ein Demonstrationsvideo für achim im Zusammenspiel mit Ansible erstellt, das die ganzen Werkzeuge in Aktion zeigt.

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.