@wusel ich Schedule ja jobs und deren dependencies. Also ich nutze slurm ... Dann starte ich via docker compose Jobs. Und jeden fucking Tag bröselt da irgendwas weg. Geht random mäßig nicht. Nochmal Schedulen. Zack geht.
@flohoff Klingt nach dem Grund, warum Menschen systemd, zuvor monit und andere Tools, erfunden haben ...
@wusel naja. Es sind ja keine services die laufen.
Jobs holen Daten vom S3 ... Verarbeiten die und schieben die Ergebnisse wieder auf den S3. Meistens jedenfalls. Manchmal werden noch Datenbanken betanked oder geupdated.
Wenn was failed Kriege ich mail und das wird im icinga rot ... Passive checks für alle Jobs.
Es ist ganz klassisch EVA nur halt mit.vielen intermediate steps und zwischenprodukten die mehrfach verwendet werden. Und für jeden step andere tools.
@wusel Und es gibt jobs die laufen alle 30 Minuten. Und es gibt jobs die monatlich laufen.
@flohoff Äh, Mißverständnis. "How do people …?" "K8s" — jedenfalls höre ich das immer wieder, wenn »viel« mit Docker gemacht wird. Bin auch über »docker compose« noch nicht raus ...
@wusel Ich wollte halt perspektivisch jobs über mehr als eine Maschine verteilen. Slurm kann das - nur ich brauche immer alle tools, teilweise binariers, teilweise temporäre postgres/postgis datenbanken.
Also baue ich mit das alles in docker container. Und jeder job hat nen git repo.
Slurm scheduled das auf einem node, der cloned sich die job geschreibung und docker compose wird mit dem docker-compose.yml file gestartet (Mit ein bisschen environment dabei wie secrets die gemapped werden etc)
Ich denke ich habe so statistisch 500-1000 Jobs am Tag - einige davon stumpf wiederkehrend, einige nur einmal. Einige laufen nur 5-10 Minuten. Andere laufen 12 Stunden. Einige job dependency bäume haben 2-5 Jobs - Andere haben 80 Jobs mit zig abhängigkeiten.
Und ich habe jeden tag gefailte jobs die beim restarten einfach gehen. Und die probleme sind nicht sauber startende docker container - nicht erreichbar, hängen geblieben etc etc etc. D.h. die fangen oft nichtmal an mein zeugs auszuführen. D.h. container image ist da, docker sagt "Alles top" - nur es läuft nicht. Und wenn ich jobs mit mehr als einem container habe startet der eine und der andere hängt.
Nervt gigantisch.
@wusel So - alle jobs jeweils mit --verbose starten - heute morgen wieder 2 gefailte:
compose.parallel.parallel_execute_iter: Failed: ServiceName(project='job167667', service='process', number=1)
ERROR: for job167667_process_1 UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)
compose.parallel.parallel_execute_iter: Failed: <Service: process>
ERROR: for process UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)
Natürlich nicht ohne ein
If you encounter this issue regularly because of slow network conditions, consider setting COMP
OSE_HTTP_TIMEOUT to a higher value (current value: 60).
Es ist localhost - die kiste hat langeweile - Also ist containerd eingeschlafen oder so ein zeugs
@wusel docker compose. Also ziemlich bare Metal.