Ich versuche gerade das aktuelle Portal aus dem main-Branch zum Laufen zu bekommen (aka ich Teste die Doku 
). Ich hänge nun an dem Schritt Prepare database fest:
$ docker-compose run --rm api tools/reset_database.py
ERROR: No such service: api
Dieser Fehler ist soweit korrekt, da die zuvor aus dem Deployment-Verzeichnis kopierte docker-compose.yml kein Service mit dem Namen api beinhaltet.
Wie kann/soll man das Kommando im Production-Szenario genau aufrufen?
API heißt es in development, weil es nur die API ist. Das Frontend ist getrennt.
Im production setup ist der Service portal, weil er auch das Frontend enthält. Ist sogar ein anderes docker Image. Darum hatte ich das jedenfalls getrennt, aber irgendwie scheint das ziemlich viel Verwirrung zu stiften…
Das sollte es klären.
Mit dem Stand der Doku läuft man in den nächsten Crash. Man muss die config.py früher erstellen und konfigurieren, als es die Deployment-Doku beschreibt.
Traceback (most recent call last):
File „/opt/obs/api/tools/reset_database.py“, line 6, in
from obs.api.app import app
File „/opt/obs/api/obs/api/app.py“, line 28, in
app.update_config("./config.py")
File „/usr/local/lib/python3.9/site-packages/sanic/app.py“, line 1413, in update_config
self.config.update_config(config)
File „/usr/local/lib/python3.9/site-packages/sanic/config.py“, line 249, in update_config
config = load_module_from_file_location(location=config)
File „/usr/local/lib/python3.9/site-packages/sanic/utils.py“, line 110, in load_module_from_file_location
_mod_spec.loader.exec_module(module) # type: ignore
File „“, line 846, in exec_module
File „“, line 982, in get_code
File „“, line 1039, in get_data
IsADirectoryError: [Errno 21] Is a directory: ‚./config.py‘
Ich sortiere die Doku nachher etwas
Goin' Fast @ http://127.0.0.1:3000Entsprechend (4) habe ich nun alle Ports auf 3000 gesetzt (das habe ich auch schon in meinem PR schon berücksichtigt).
Dennoch scheint mein Container keinen Sanic-Prozess auf Port 3000 zu haben, sodass er leider noch immer nicht funktioniert. Das volle Portal-Log:
portal_1 | INFO: Goin' Fast @ http://127.0.0.1:3000
portal_1 | [2021-12-20 22:27:23 +0000] [1] [INFO] Goin' Fast @ http://127.0.0.1:3000
portal_1 | [2021-12-20 22:27:23 +0000] [1] [INFO] Starting worker [1]
portal_1 | INFO: Starting worker [1]
[FIXED]: Ich hatte HOST = "127.0.0.1" statt HOST = "0.0.0.0". Das findet sich auch in meinem PR.
Ja, das stiftet Verwirrung.
Wie wäre es, die Doku in Dev und Prod zu teilen und in zwei Wegen zu fahren. Ich bastel jetzt seit drei Tagen drauf rum und es wird nichts.
Mal ist es die Unterscheidung von api und portal, mal ist der ROOT Pfad, der mal /opt/obs, mal /opt/openbikesensor in den Configfiles hat.
In der jetzigen Form ist das Setup für mich nicht nachvollziehbar. Ihr müsst als Entwickler mal um den Schreibtisch herumgehen und die Brille der IT Operation aufsetzen, um die Probleme zu sehen. Wie gesagt, ich würde da gerne helfen, aber mit der aktuellen Basis und ohne vernünftige Architekturskizze ist das unmöglich.
Port 3000 ist in vielen Installationen durch ntop-ng geblockt. Habt ihr euch bei den Ports an den RFC und der Liste der Well Known Services orientiert?
Wo ist denn das Problem mit /opt/obs vs /opt/openbikesensor aufgetreten? Das eine (export $ROOT=/opt/openbikesensor) ist in der Doku der Beispielpfad in dem die Dateien auf dem Host liegen, das andere ist der Pfad in den configdateien im Container gemounted werden. (/opt/obs gibt es also nur in den Containern, nicht im Host). Als ich durchs deployment gestiefelt bin war das in der Doku noch konsistent, evtl. hat sich seitdem was geändert?
Beim einen ist der Port schon belegt, und die nächste hat keine Schreibrechte in /opt aber in /home/obs und dann sind die Pfade wieder anders. Wir können nicht jede Installation und jedes System antizipieren und beschreiben. Darum schlagen wir ja auch Docker vor, damit es in den Container wenigstens mehr oder weniger das gleiche System gibt.
Wenn du nicht weißt, was Docker tut, und wie du dein Host-System in den Container mappst, dann solltest du es vielleicht lernen, bevor du es benutzt.
Wie wäre es, die Doku in Dev und Prod zu teilen und in zwei Wegen zu fahren.
Das sollte eigentlich so sein: Dev vs Prod. Ich finde im Übrigen die Transferleistung machbar, wenn in der Prod-Anleitung „Siehe Normales Readme“ steht, dann eben evtl. deine eigenen Ports, Pfade, Service-Namen, … da einzusetzen.
Hier ist übrigens eine Architekturskizze, die beschreibt aber grob die Anwendung, nicht das Deployment. Das Deployment benötigt mMn keine Skizze, es sind eine Datenbank und ein Python-Prozess nötig.
Wie du das im Endeffekt machst, ist dir überlassen. Jede:r Operator macht das nämlich unterschiedlich. Bei einem „vorgeschriebenen“ Vorgehen meckern sonst alle, dass ihr Setup nicht beschrieben ist – also lasse ich das einfach ganz. Die Beispielkonfigurationen sind eben nur das, Beispiele. Du musst sie schon anpassen auf deine Anforderungen. Da bin ich einfach mal „um den Schreibtisch gegangen“ und habe mir gedacht, die IT Ops werden schon wissen, wie sie sich einen Port aussuchen, das muss ich ihnen ja nicht vorschreiben. Ich nehme 3000, aber du kannst ihn dir umkonfigurieren, es ist ja zum Glück in der Bespielkonfiguration die entsprechende Option drin.
Port 3000 ist in vielen Installationen durch ntop-ng geblockt. Habt ihr euch bei den Ports an den RFC und der Liste der Well Known Services orientiert?
Das ist genau der Fall von „alle meckern, dass ihr Setup nicht beschrieben ist“. Dieses ntop-ng finde ich nicht, kenne ich nicht, hat meine Distro nicht. Port 3000 verwenden ungefähr hundert oder so Dienste. Es ist der generische default port für jede Ruby on Rails / NodeJS Webanwendung. Im Endeffekt ist es auch egal, suche dir bitte deinen Port selbst aus, dann ist der auch nicht durch irgendwas belegt.
Danke für die Zurechtweisung, reflektier aber bitte einmal die Art deiner Kommunikation. Du sprichst mit einem Menschen mit über 30 Jahren Erfahrung im IT Betrieb.
Die Architekturskizze ist eher das Flussdiagramm für Entwickler. Im IT Betrieb beschreibt man darin, welche Maschinen über welche Ports miteinander kommunizieren. Damit wären wir wieder an dem Punkt über die Festlegung von Begriffen und deren einheitlicher Benutzung zu reden.
Auch als Entwickler sollte man darauf achten, den Anderen ernst zu nehmen. Was hier kommt, ist eher Kindergarten und Aktives in den falschen Hals bekommen. Was ich hier echt vermisse, ist eine Fehlerkultur, die auch andere Sichtweisen akzeptiert und versucht, die eigen Wahrnehmung nachzujustieren. Wenn du möchtest, dass andere DEIN PROJEKT unterstützen, tätest du gut daran, deren Unterstützungsangebot auch als genau das wahrzunehmen.
Aus meiner Sicht muss man zuhören und Fragen stellen, wenn man ein Projekt verstehen und unterstützen will. Da das aber bei dir leider eher als „Störe meine Kreise nicht“ ankommt, werde ich einfach nichts mehr fragen.
Alles Gute
