Ausführung der Worker in Container und cgroups #163
Description
cgroups
Da cgroups verschachtelt werden können, können wir für alle Worker eine gemeinsame Haupt-cgroup erstellen. cpu.max und memory.max richten sich nach der Server-Konfiguration worker.max_workers (sollten wir umbenennen zu max_cpus) und worker.max_memory.
Für jeden Worker (außer den ThreadWorker) wird eine neue cgroup erstellt. CPU/Memory richten sich nach den Standardwerten, den vom Paket angeforderten Ressourcen oder den überschriebenen Werten (siehe #161).
Informationen zu cgroups:
- https://man7.org/linux/man-pages/man7/cgroups.7.html
- https://docs.kernel.org/admin-guide/cgroup-v2.html
Container-Worker
Als neue Worker-Art wird die Ausführung im Container hinzugefügt, was im Server auch der Standard werden soll. Unterstützt werden sollen Docker als auch Podman. Beide kennen das Argument --cgroup-parent. Standardmäßig sollen die Worker keinen Netzwerkzugriff erhalten.
Die Pakete sollen in ihrem Manifest definieren, in welcher Umgebung sie ausgeführt werden sollen, d.h. welche Python-Version sie erwarten. Perspektivisch könnte darüber auch eine Ausführung unter PyPy angefordert werden oder einer komplett anderen (Nicht-Python) Umgebung. In dem Feld sollte daher nicht nur >=3.13 sondern python>=3.13 stehen.
Zur Ausführung können wir sicherlich die Standard-Python-Images vom Docker Hub benutzen. Die Images werden regelmäßig gepullt und die Worker neugestartet, wenn eine neue Version bereitsteht.
Worker darf weitere Container starten lassen
Beispielsweise zur Ausführung von Programmierabgaben soll der Hauptprozess im Worker auch noch weitere Container (durch den Server) starten lassen können, die in der gemeinsamen Worker cgroup ausgeführt werden. --oom-score-adj sollte höher gesetzt werden als der Score des Worker-Hauptprozesses (der wiederum höher sein sollte als der des QuestionPy-Servers). Die Möglichkeit zum Starten weiterer Container (und welcher Images) muss als Permission über das Manifest angefordert werden. Die stdin/stdout/stderr werden direkt dem Hauptprozess zugänglich gemacht, damit die Kommunikation nicht weiter über den QuestionPy-Server erfolgen muss. Bei der Container-Erstellung muss das Paket angeben, wie viel Speicher dem Container maximal zur Verfügung stehen soll.
Hier ist es schwieriger zu sagen, welche Images zur Verfügung stehen sollen. Die Standard-Images aus dem Docker Hub werden für viele Anwendungsfälle nicht ausreichend sein. Hier wäre ein Mechanismus gut, dass man als Admin Dockerfiles hinterlegen kann. Die Images werden dann (bei Bedarf) automatisch gebaut. Hinterlegt werden können muss auch eine Logik, die darüber entscheidet, ob ein Image neugebaut werden muss (weil eine neuere Version des Basis-Images oder einer anderen Abhängigkeit vorliegt).
Ressourcennutzung im Container Manager
Da der Container Manager möglicherweise nicht exklusiv genutzt wird, müssten die Container mit einem Präfix erzeugt werden. Beim Server-Start werden eventuell noch laufende Container mit diesem Präfix gekillt.
Für die produktive Ausführung des QuestionPy-Servers sinnvoll wäre es, wenn wir regelmäßig ungenutzte Images/Layers prunen lassen. Dies kann über die Konfiguration aktiviert werden.