# Brainstorm ## Overview - verschiedene Lösungsansätze verfolgen - unterschiedliche Anwendung (kleine Scripts vs. große Projekte) - unterschiedliche Nutzer:innen-Erfahrung - "TensorBoard" ## SSH > kleine Scripts sowie große Projekte - CLI: byobu - GUI: Xpra - Datasets über NFS - [-] schlechte Serverauslastung ### Bare Metal - [+] Keinen automatischen Server-Stopp (JupyterHub stoppt nach 3 || 4 Tagen) - [-] Firewall-Routing erforderlich - [-] Linux-Account erforderlich (mit SSH-Schlüssel) - [-] Nutzer:in muss Conda-Umgebung erstellen ### JupyterHub - Code-Tunnel (Github- oder Microsoft-Account) - "ngrok" - Eintrag in JupyterHub-Config zur Nutzung der GPUs - [+] Conda-Umgebung bereits vorhanden - [-] vmtl. neue Tunnelerstellung bei jedem Starts des User-Servers auf JupyterHub - `$ code tunnel` ## Makefile > kleine Scripts; kurzfristige Ausführung; Debugging - Konfiguration über Makefile-Variablen - Targets - `make push` kopiert Code von Client auf Server (`scp` || `rsync`) - `make exec` führt Code auf Server aus (`ssh`) - `make status` fragt Fortschritt auf Server ab (`ssh`) - `make pull` kopiert Output von Server auf Client (`scp` || `rsync`) ## JupyterHub – Browser - JupyterHub im Browser - Terminal von JupyterLab zur Ausführung - [+] "bessere" Serverauslastung (Ressourcenmanagement) - [+] keine byobu-Abhängigkeit - [-] ungewünschte Nutzung von JupyterHub (im Browser) ## GitLab > große Projekte; langwierige Berechnungen 1. [Code](https://gitlab.cvh-server.de/mmelchert/akis-cloud-computing): `git push` 2. [Pipelines](https://gitlab.cvh-server.de/mmelchert/akis-cloud-computing/-/pipelines): `.gitlab-ci.yml` 3. [Runners](https://gitlab.cvh-server.de/mmelchert/akis-cloud-computing/-/settings/ci_cd#js-runners-settings): RTX 4090 4. [Pipelines](https://gitlab.cvh-server.de/mmelchert/akis-cloud-computing/-/pipelines) [](https://gitlab.cvh-server.de/mmelchert/akis-cloud-computing/-/commits/main) 5. [Artifacts](https://gitlab.cvh-server.de/mmelchert/akis-cloud-computing/-/artifacts): Output - [+] "optimale" Serverauslastung - [+] "bekannter" / standardisierter Workflow - [+] GUI vorhanden - [+] integrierte Versionsverwaltung - [+] automatisierte Ausführung des Codes - Runners-Konfiguration nötig (max. Laufzeit) - [+] Fortschrittskontrolle - E-Mail-Benachrichtigung - fehlerhafter Pipeline (default) - erfolgreicher Pipeline (Repo Notification Settings) - [Matrix-Bot](https://gitlab.cvh-server.de/mmelchert/akis-cloud-computing/-/settings/integrations/matrix/edit) - [+] Ablage der letzten Output-Versionen (Artifacts) - statischer Link zum Output des letzten Jobs - jede Code-Änderung ein Commit & Push - [+] grundsätzlich sinnvoll - [-] eher ungeeignet fürs Debugging - [-] Speicheraufwand (GitLab auf Hetzner-Server) - Umzug möglich <!-- todo: Jobs vs. [MLOps](https://docs.gitlab.com/user/project/ml/) -->