Einladung: Workshop Portalbetrieb

Design & Entwicklung Portal & Datenverarbeitung
#1

Ob es ein richtiger „Workshop“ wird oder nur ein bisschen zeigen und quatschen, das weiß ich noch nicht. Aber wir sollten uns auf jeden Fall mal zusammensetzen und über den Betrieb der Portalsoftware sprechen, denn da haben einige hier Fragen, und es ändert sich jetzt auch relativ viel.

Inhaltlich möchte ich sprechen über:

  • Allgemeine Architektur (v0.3)
  • Änderungen v0.2 → v0.3
  • Migrationen
  • Setup mit/ohne Docker
  • Einrichtung Keycloak
  • Reverse Proxy (Optionen, Setup, Gründe)
  • Backups
  • Informationsweitergabe Devs → Betreiber:innen, Versionierung
  • Docker Hub?
  • Persönliche Daten → eher als Infopunkt, keine Diskussion zu Datenschutzerklärungen, die den Abend füllt :wink:

Für weitere Themenvorschläge gern kommentieren.

Bitte stimmt hier für einen Termin ab, den gewählten Termin werde ich hier dann demnächst bekanntgeben:

https://nuudel.digitalcourage.de/2OJEi3idTf7k9cBV

/cc @boldt @zeitungsleser @gluap @norbertschulz

LG Paul

2 „Gefällt mir“
#2

Wunderbar, das Nuudel hat ergeben:

Mittwoch, 1. Dezember, 19:30 Uhr

Wie üblich treffen wir uns im meet.openbikesensor.org, der Code geistert irgendwo im Slack rum :wink:

/cc @ventusfahrer @joachim.braun @thomaso @norbertschulz @gluap

1 „Gefällt mir“
#3

Dch habe den Nuudel erst jetzt gehen. Schade, denn am 01.12. kann ich nicht.

#4

Für alle hier ein kleiner Teaser: Ich habe heute den Abend verbracht, mal meine Ideen und Gedanken und das was ich gebaut habe aufzuschreiben und eine Dokumentation zur Architektur und zu den Open Source Lizenzen der Tools und Daten, die das Portal verwendet, zu schreiben. Außerdem gibt es noch die README im Repo für Allgemeines und für das Development Setup, und die Deployment Kurzanleitung.

Lest euch das gern schon einmal durch.

PS: Nachdem ich heute also lange über Lizenzen nachgedacht habe, ist mir aufgefallen, dass das neue Portal (Python 3 & React) noch gar nicht lizensiert war. Das habe ich dann mal nachgeholt :rocket: (LGPL-3.0, wie üblich). Ich habe das ja allein entwickelt, also musste ich niemensch fragen. FOSS :heart:

1 „Gefällt mir“
#5

Für alle die es interessiert: Ich habe germany-latest.osm.pbf als Straßenabschnitte in portal.openbikesensor.org importiert – die PostgreSQL ist jetzt ca. 3.6GiB groß, so groß wie die Input-Datei ungefähr, zwar weniger Daten drin, dafür geographisch indiziert. Das ganze hat ca. 1 Stunde gedauert, durch einen SSH-Tunnel. Die Ziel-VM ist ziemlich langsam, das wäre auf einer stärkeren Maschine wesentlich schneller gegangen.

Ihr braucht etwa das Doppelte an freier Platte für den Import, da temporäre Daten verwendet werden die danach gelöscht werden. Also startet mit etwa 6-10GB frei wenn ihr ganz DE importieren wollt. Entsprechend weniger wenn es nur einzelne Regionen sind :wink:

2 „Gefällt mir“
#6

Und noch etwas: Es empfiehlt sich, die Trackdateien direkt komprimiert zu backupen:

# du -hs data/api-data/tracks/ backup/2021-12-02/tracks.tar.gz
476M    data/api-data/tracks/
86M     backup/2021-12-02/tracks.tar.gz

Die CSVs geben viel compression ratio her :wink: Solange also #58 nicht implementiert ist, solltet ihr das von Hand so machen, um Platz zu sparen.

1 „Gefällt mir“
#7

7 Beiträge wurden in ein neues Thema verschoben: Karte zeigt keine Straßenzüge

#8

@opatut

Follow-up: Ich hab jetzt einen lokalen Klon des Darmstädter Portals erfolgreich migriert. Dabei ist mir aufgefallen, dass ich eigentlich gern eine .env datei für die Credentials verwenden würde, anstatt sie in verschiedenen Configs abzulegen (vor allem: Posgress user/Password) da die (je nach setup) von allen Containern gebraucht wird.

Ich hab das jetzt lokal mit .env gemacht und würde das auch upstream einpflegen wenn da interesse besteht.

In der config.py kann man das ja auch einfach lesen:

import os
# Connection to the database
POSTGRES_URL = f"postgresql+asyncpg://{os.getenv('POSTGRES_USER')}:{os.getenv('POSTGRES_PASSWORD')}@postgres/obs"

Außerdem:
Nach der migration musste ich noch mal die tracks auf „queued“ setzen - Kann aber sein, dass das entweder war, weil ich noch vom alten „dev/production“ branch kam oder im ersten durchlauf die config nicht wusste wo /data liegt.

1 „Gefällt mir“
#9

Jo mach das gern. Ich mag an .env nicht, dass docker-compose das automatisch liest, aber alle anderen Tools natürlich nicht. Das müsste wenn dann zuende gedacht werden, und überall irgendwie automatisch funktionieren, finde ich. Du kannst da gern einen Vorschlag machen.

#10

Was meinst du denn mit „alle anderen Tools“? Im Baremetal-deployment? Denn der keycloak und der Postgres container beherrschen die Env variablen ja bereits out-of-the-box. Docker (ohne compose) hat „–env-file“ um das File zu lesen

#11

Alle anderen. Also meine shell lädt .env nicht automatisch wenn sie irgendeinen Prozess in einem Verzeichnis startet. Man muss das --env-file halt selbst bauen.

#12

Für mich ist es schon eine Verbesserung wenn die (compose-) Container das env lesen und es z. B. nur noch eine Quelle für das postgres Passwort gibt. In der shell kann man die Variablen ja auch bequem reinladen. Mein Workflow ist aber auch so, dass ich eher in den Containern arbeite. Wenn das ein freak Workflow ist, den außer mir keiner nutzt brauchen wir es auch nicht einbauen.

Ich wollte das aber auch nicht statt des bisherigen workflows mit configdateien anbieten sondern zusätzlich.

Ein Vorteil wäre, dass wir damit architektonisch näher an einem releasbaren docker image wären, das der user mit den gängigen env Mechanismen konfiguriert.

#13

In der Bash könnte man .env z.B. mittels set -o allexport; source .env; set +o allexport einlesen.