Ankündigung

Einklappen
Keine Ankündigung bisher.

Probleme mit Docker Container und Zugriff auf Bus (IP)

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Probleme mit Docker Container und Zugriff auf Bus (IP)

    Hallo Zusammen,

    Ich wollte heute mal eine neue Version der Cometvisu installieren.
    Bisher läuft das auf einem uralten Wiregate, das wiederrum ist mit einer IP-Schnittstelle mit dem KNX verbunden.
    Das Wire-Gate soll für den Cometvisu-Docker auch als Schnittstelle dienen, mach ich mit der ETS bisher auch schon so, das funktioniert auch wunderbar soweit.

    Das ist mein docker-compose.yaml (die Formatierung geht leider verloren beim rein kopieren hier :/)
    Code:
    version: '3.4'
    services:
    cometvisu:
    image: "cometvisu/cometvisu:latest"
    restart: always
    ports:
    - 80:80
    volumes:
    - ./resource/config:/var/www/html/resource/config
    environment:
    KNX_INTERFACE: "ipt:172.26.193.148"
    CGI_URL_PATH: "/cgi-bin/"
    KNX_PA: "1.1.138"
    KNXD_PARAMETERS: "-u --daemon=/var/log/knxd.log -c --error=9"
    172.26.193.148 Ist die IP vom Wiregate.
    Damit startet das Wiregate den eibd
    /usr/bin/eibd -e 1.1.254 -S -D -i -T -d -u --pid-file=/var/run/eibd.pid -c ipt:172.26.193.160
    Wie gesagt nutze ich das Wiregate mit der ETS als Schnittstelle, seit Jahren, das funktioniert auch.

    Den Teil habe ich beim rum probieren irgendwann eingefügt.
    Hab nur die KNX-PA und "--error=9" hinzugefügt, der rest sind ja die standard parameter.
    Code:
    KNX_PA: "1.1.138"
    KNXD_PARAMETERS: "-u --daemon=/var/log/knxd.log -c --error=9"
    Der Container läuft auch, Webserver liefert auch die Visu aus, nur das schreiben/lesen auf den Bus geht leider nicht.

    Wenn ich in der Cometvisu etwas betätige geht ein call an:
    http://server01.local/cgi-bin/w?s=SE...=1641135691959

    Soweit so gut, das cgi-script gibt auch "{'success':1}" zurück, aber auf dem Bus passiert leider nichts.

    Also dachte ich, ich schau in dem Docker Container mal in das Log "/var/log/knxd.log", bzw eibd.log mit den default settings.
    Allerdings ist das log komplett leer.
    Für mich sieht es so aus als ob keine Kommunikation zwischen dem knxd in dem Cometvisu Container und dem Wiregate nicht stattfindet, oder nicht möglich ist.
    Hatte auch probiert den Port mit anzugeben, keine Änderung:
    Code:
    KNX_INTERFACE: "ipt:172.26.193.148:3671"

    Hat jemand eine Idee wie man das debuggen könnte?
    Oder wenigstens wie man den knxd dazu bekommt etwas zu loggen?
    Ich hab auch error=1 als loglevel probiert, aber das gleiches ergebnis (natürlich).


    EDIT:
    Hab gerade noch probiert was passiert wenn man einfach mal eine falsche IP für das IP-Interface angibt.
    Beim starten beschwert sich der knxd nicht, und auch im log steht nach wie vor nichts.

    Das steht in den logs:
    Code:
    starting knxd
    AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.20.0.2. Set the 'ServerName' directive globally to suppress this message
    AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.20.0.2. Set the 'ServerName' directive globally to suppress this message
    [Sun Jan 02 15:08:55.438405 2022] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.38 (Debian) PHP/7.2.22 configured -- resuming normal operations
    [Sun Jan 02 15:08:55.438772 2022] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
    1
    Also leider nichts sinnvolles.
    Danach kommen dann nur noch die logs vom apache mit den eingehenden Requests.




    Zuletzt geändert von daviid; 02.01.2022, 16:12.

    #2
    Um zu verstehen was hier (nicht) passiert, eine kurze Darstellung des Setup:
    • Das WireGate hat einen eibd/knxd, der Zugriff auf den KNX hat und dies per Tunnel auch im Intranet bereitstellt.
    • Der Docker-Container der CometVisu enthält einen knxd, der nach außen über den Tunnel des WireGate eibd/knxd auf den KNX zugreifen möchte, und dies Container-Intern über einen Socket bereit stellt
    • Die CometVisu im Container (genauer: das Backend der CometVisu) nutzt diesen Socket
    Oder kurz: KNX <-> WireGate eibd/knxd <-> Container knxd <-> CometVisu Backend <-> CometVisu Client <-> Web-Browser

    Wenn Du nun ein "w" absetzen kannst und ein "success" zurück bekommst, so lässt sich vermuten, dass die Kette vom Browser bis zum Container-knxd funktioniert.
    Wenn nun aber nichts am KNX auftaucht, so vermute ich, dass der Container knxd nicht mit dem WireGate knxd verbunden ist.

    Ein typischer Test der Verbindung des Container-knxd mit dem KNX wäre ein interaktives Terminal/Shell/Console vom Container zu öffnen und dort das Kommando
    Code:
    vbusmonitor1time local:/tmp/eib
    auszuführen.

    Wenn die Verbindung da ist, dann sollten nun nach und nach alle Pakete sichtbar werden, die auch am KNX kommen.
    Kommt hier nichts, dann ist wirklich die Verbindung "WireGate eibd/knxd <-> Container knxd" zu prüfen und fixen.

    Ich bin hier kein eibd/knxd Experte, bei mir hat es aber schon öfters geholfen von "ipt" auf "iptn" zu wechseln.

    Noch zur Frage des Loggens vom knxd: das kann der schon. Versuche mal mit einem zusätzlichen "-t 65535" in den Parametern.
    TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

    Kommentar


      #3
      Hi Chris,

      Danke schon mal für die Antwort.
      Das Setup wie du es beschreibst ist richtig.

      Wenn ich den vbusmonitor starte sehe ich nichts was auf dem Bus passiert.
      Nur wenn ich in der Cometvisu etwas klicke tauchen die Telegramme dann auch dort auch, aber gehen halt nicht raus.
      (irgendetwas versucht auch auf verschiedene GAs zu lesen, was ist das nochmal?
      Bin aus dem Thema leider schon ewig raus, hab jetzt über mehrere Jahre keine Anpassungen gemacht und war daher auch nicht mehr Aktiv ...).

      So sieht es denn aus wenn ich aus der Visu einen Aktor an/aus schalten möchte:
      Code:
      23:25:39.894 LPDU: BC 00 00 51 00 F1 00 80 63 :L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
      23:25:40.335 LPDU: BC 00 00 51 00 F1 00 81 62 :L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
      23:25:40.666 LPDU: BC 00 00 51 00 F1 00 80 63 :L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
      23:25:41.088 LPDU: BC 00 00 51 00 F1 00 81 62 :L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
      23:25:41.842 LPDU: BC 00 00 51 00 F1 00 80 63 :L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
      23:25:42.096 LPDU: BC 00 00 51 00 F1 00 81 62 :L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
      Statt "ipt" hab ich natürlich auch schon "iptn" probiert, leider ohne erfolg bis her.

      Anpingen kann ich das Wiregate aus dem Container übrigens, funktioniert wunderbar (nachdem man erstmal iputils-ping installieren muss )
      Also prinzipiell geht das schon.
      Jetzt müsste man halt Wissen wie das KNX ipt Protokoll funktioniert, mal schauen ob ich dazu etwas finde.
      Aber ich kann doch nicht der Erste sein der das ganze in dem Docker-Container laufen lässt und der als Verbindung zum KNX das knx ip-tunnel protocol nutzt, oder? : D


      Noch zur Frage des Loggens vom knxd: das kann der schon. Versuche mal mit einem zusätzlichen "-t 65535" in den Parametern.
      Gut zu wissen, damit wird jetzt tatsächlich etwas geloggt, ich konnte aber leider auch da nichts finden woran es liegen könte.

      Ich hab mal etwas aus dem knxd log raus kopiert, kann aber auch nix erkennen:
      Code:
      Layer 8(F0D07070,61D23650) LastUpdates start: 5 pos: 5
      Layer 8(F0D06FF0,61D23651) New Connection
      Layer 8(F0DED080,61D23651) ClientConnection Init
      Layer 8(F0DED080,61D23651) RecvMessage(005): 00 22 51 00 FF
      Layer 7(F0DDA220,61D23651) OpenGroup
      Layer 4(F0D9FAE0,61D23651) OpenGroup 10/1/0 WO
      Layer 8(F0DED080,61D23651) SendMessage(002): 00 22
      Layer 8(F0DED080,61D23651) RecvMessage(004): 00 25 00 81
      Layer 7(F0DDA220,61D23651) Send(002): 00 81
      Layer 4(F0D9FAE0,61D23651) Send Group T_DATA_XXX_REQ A_GroupValue_Write (small) 01
      Layer 3(F0D06EF0,61D23651) Send L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
      Layer 2(F0D04E30,61D23651) Send L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
      Layer 2(F0D04E30,61D23651) Recv L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
      Layer 3(F0D06EF0,61D23651) Recv L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
      Layer 8(F0D07070,61D23651) LastUpdates start: 5 pos: 6
      Layer 8(F0DB0E20,61D23651) SendMessage(006): 00 76 00 06 51 00
      Layer 8(F0D07070,61D23651) LastUpdates start: 5 pos: 6
      Layer 8(F0DC2E80,61D23651) SendMessage(006): 00 76 00 06 51 00
      Layer 8(F0DB0E20,61D23651) RecvMessage(004): 00 75 51 00
      Layer 4(F0D07070,61D23651) GroupCacheRead 10/1/0 0 0
      Layer 4(F0D07070,61D23651) GroupCache found: 0.0.0
      Layer 8(F0DB0E20,61D23651) SendMessage(008): 00 75 00 00 51 00 00 81
      Layer 8(F0DC2E80,61D23651) RecvMessage(004): 00 75 51 00
      Layer 4(F0D07070,61D23651) GroupCacheRead 10/1/0 0 0
      Layer 4(F0D07070,61D23651) GroupCache found: 0.0.0
      Layer 8(F0DC2E80,61D23651) SendMessage(008): 00 75 00 00 51 00 00 81
      Layer 8(F0DB0E20,61D23651) ClientConnection closed
      Layer 8(F0DC2E80,61D23651) ClientConnection closed
      Layer 7(F0DDA220,61D23651) CloseGroup
      Layer 4(F0D9FAE0,61D23651) CloseGroup
      Layer 3(F0D06EF0,61D23651) deregisterGroupCallBack F0D9FAE0 = 0
      Layer 8(F0DED080,61D23651) ClientConnection closed
      Layer 8(F0D06FF0,61D23651) New Connection
      Layer 8(F0DED080,61D23651) ClientConnection Init
      Layer 8(F0DED080,61D23651) RecvMessage(005): 00 76 00 06 2C
      Layer 8(F0D07070,61D23651) LastUpdates start: 6 pos: 6
      Layer 8(F0D06FF0,61D23651) New Connection
      Layer 8(F0DC2E80,61D23651) ClientConnection Init
      Layer 8(F0DC2E80,61D23651) RecvMessage(005): 00 76 00 06 2C
      Layer 8(F0D07070,61D23651) LastUpdates start: 6 pos: 6
      Layer 8(F0D06FF0,61D23652) New Connection
      Layer 8(F0DB0E20,61D23652) ClientConnection Init
      Layer 8(F0DB0E20,61D23652) RecvMessage(005): 00 22 51 00 FF
      Layer 7(F0DDA220,61D23652) OpenGroup
      Layer 4(F0DECEA0,61D23652) OpenGroup 10/1/0 WO
      Layer 8(F0DB0E20,61D23652) SendMessage(002): 00 22
      Layer 8(F0DB0E20,61D23652) RecvMessage(004): 00 25 00 80
      Layer 7(F0DDA220,61D23652) Send(002): 00 80
      Layer 4(F0DECEA0,61D23652) Send Group T_DATA_XXX_REQ A_GroupValue_Write (small) 00
      Layer 3(F0D06EF0,61D23652) Send L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
      Layer 2(F0D04E30,61D23652) Send L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
      Layer 2(F0D04E30,61D23652) Recv L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
      Layer 3(F0D06EF0,61D23652) Recv L_Data low from 0.0.0 to 10/1/0 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
      Layer 8(F0D07070,61D23652) LastUpdates start: 6 pos: 7
      Layer 8(F0DED080,61D23652) SendMessage(006): 00 76 00 07 51 00
      Layer 8(F0D07070,61D23652) LastUpdates start: 6 pos: 7
      Layer 8(F0DC2E80,61D23652) SendMessage(006): 00 76 00 07 51 00
      Layer 8(F0DED080,61D23652) RecvMessage(004): 00 75 51 00
      Layer 4(F0D07070,61D23652) GroupCacheRead 10/1/0 0 0
      Layer 4(F0D07070,61D23652) GroupCache found: 0.0.0
      Layer 8(F0DED080,61D23652) SendMessage(008): 00 75 00 00 51 00 00 80
      Layer 8(F0DC2E80,61D23652) RecvMessage(004): 00 75 51 00
      Layer 4(F0D07070,61D23652) GroupCacheRead 10/1/0 0 0
      Layer 4(F0D07070,61D23652) GroupCache found: 0.0.0
      Layer 8(F0DC2E80,61D23652) SendMessage(008): 00 75 00 00 51 00 00 80
      Layer 8(F0DED080,61D23652) ClientConnection closed
      Layer 8(F0DC2E80,61D23652) ClientConnection closed
      Layer 7(F0DDA220,61D23652) CloseGroup
      Layer 4(F0DECEA0,61D23652) CloseGroup
      Layer 3(F0D06EF0,61D23652) deregisterGroupCallBack F0DECEA0 = 0
      Layer 8(F0DB0E20,61D23652) ClientConnection closed
      Layer 8(F0D06FF0,61D23652) New Connection
      Layer 8(F0DB0E20,61D23652) ClientConnection Init
      Layer 8(F0DB0E20,61D23652) RecvMessage(005): 00 76 00 07 2C
      10/1/0 ist dabei die GA auf die ich schreiben möchte aus der Visu aus.
      Zuletzt geändert von daviid; 03.01.2022, 00:44.

      Kommentar


        #4
        Update:

        Also irgendwie hab ich es jetzt hin bekommen.
        Hab nochmal mit den knxd settings rum gemacht, und bisschen probiert mit ipt, iptn, IP angeben mit Port, oder ohne Port, und irgendwie ging es dann auf einmal.
        Das Problem ist nur, ich hab nix geändert eigentlich ...

        Das ist das aktuelle docker-compos:
        Code:
        version: '3.4'
        services:
          cometvisu:
            image: "cometvisu/cometvisu:latest"
            restart: always
            ports:
            - 80:80
            volumes:
            - ./resource/config:/var/www/html/resource/config
            environment:
              KNX_INTERFACE: "ipt:172.26.193.148"
              CGI_URL_PATH: "/cgi-bin/"
              KNX_PA: "1.1.238"
              KNXD_PARAMETERS: "-u --daemon=/var/log/knxd.log -t 65535 -c --error=3"
        Jetzt ist die GA auf 1.1.238, vorher waren es 138
        Daran liegt es aber auch nicht, habs auch wieder auf 138 zurück geändert und es ging.

        Wenn ich den container starte und mit
        Code:
        vbusmonitor1time local:/tmp/eib
        zuschaue sehe ich dass es erst etwas dauert bis etwas passiert, dann geht es auf einmal los dass ganz viel GAs gelesen werden, und irgendwann wenn das mal fertig ist, funktioniert die Cometvisu auch.
        Ich frag mich nur warum das gestern Abend und heute Mittag nicht auch schon so war ...

        Ich hab gerade auch alles mögliche probiert um das reproduzieren zu können, allerdings leider mit nicht so viel erfolg :/

        Kommentar


          #5
          Allerdings habe ich gerade noch ein Problem entdeckt.
          Ich habe mal meine alte config in das volume von dem container kopiert, soweit so gut, hab dann im XML "lib_version" von "1" auf "8" gesetzt.
          Damit hat auch der Cometvisu-Editor das File gefressen.
          Dann hat sich auch noch der Editor über die Dateirechte beschwert, dann hab ich mal mit "chmod 777 config/*" alles auf 777 gesetzt.
          Dann läd immerhin der Editor die Config.
          Aber wenn ich nach einer Änderung speichern will erscheint ein Popup mit der Meldung:

          Code:
          configuration could not be saved, server responded with 'backup-file is not writeable, please chmod/chown directory '''
          Am Ende sind ja leere Anführungszeichen, ich nehme an da drin sollte irgend etwas stehen, nämlich in welchem directory die Berechtigungen nicht passen.
          Welches könnte das sein?

          Kommentar


            #6
            Zitat von daviid Beitrag anzeigen
            Aber ich kann doch nicht der Erste sein der das ganze in dem Docker-Container laufen lässt und der als Verbindung zum KNX das knx ip-tunnel protocol nutzt, oder? : D
            Nein, Tunnel ist sogar der normale Weg den die aller meisten CometVisu-Container nutzen werden um auf den Bus zuzugreifen.
            Zitat von daviid Beitrag anzeigen
            Gut zu wissen, damit wird jetzt tatsächlich etwas geloggt, ich konnte aber leider auch da nichts finden woran es liegen könte.
            Aus dem Logging werde ich auch oft nicht schlau. Aber ich höre auch immer auf mich mit dem eibd/knxd zu beschäftigen sobald es läuft.

            Zitat von daviid Beitrag anzeigen
            Update:

            Also irgendwie hab ich es jetzt hin bekommen.
            Hab nochmal mit den knxd settings rum gemacht, und bisschen probiert mit ipt, iptn, IP angeben mit Port, oder ohne Port, und irgendwie ging es dann auf einmal.
            Das Problem ist nur, ich hab nix geändert eigentlich ...
            OK, vorhin hatten wir nicht gecheckt, ob der knxd Prozess überhaupt noch läuft. Wobei ich da jetzt nicht auswendig sagen kann, welche Auswirkungen es gibt, wenn der nicht mehr läuft (z.B. ob dann ein "w" überhaupt "success" melden kann).
            Also nicht, dass es nur an einem Neustart des Containers gelegen hat.
            Zitat von daviid Beitrag anzeigen
            Wenn ich den container starte und mit
            Code:
            vbusmonitor1time local:/tmp/eib
            zuschaue sehe ich dass es erst etwas dauert bis etwas passiert, dann geht es auf einmal los dass ganz viel GAs gelesen werden, und irgendwann wenn das mal fertig ist, funktioniert die Cometvisu auch.
            Der vbusmonitor1time sollte eigentlich kontinuierlich Daten liefern (so diese halt am KNX Bus sind). D.h. wenn der noch länger läuft, dann sollten schon noch neue Zeilen dazu kommen.

            Das es direkt beim Start noch Verzögerungen etc. pp. gibt mag sein. Da müssen ja verschiedene Sachen erst mal starten. Aber das ist auch ein Zustand der sehr selten passiert, da der Server - im Gegensatz zum Browser für die Anzeige - ja durchläuft.
            Für die Anzeige der Visu im Browser wird es sogar noch deutlicher sein, da nach einem Neustart der Cache im knxd noch nicht befüllt ist. D.h. ein direkter Aufruf der Visu im Browser wird erst mal alle GAs von allen Busteilnehmern per Read-Request abfragen. Da kann es dann schon bisschen Verzögerung geben.
            Aber das ist in der Praxis ja nicht relevant, das merkt man nur beim Testen.
            Zitat von daviid Beitrag anzeigen
            Allerdings habe ich gerade noch ein Problem entdeckt.
            Ich habe mal meine alte config in das volume von dem container kopiert, soweit so gut, hab dann im XML "lib_version" von "1" auf "8" gesetzt.
            Zwischen Version 1 und 8 gab's einige deutliche Änderungen. Ich hoffe, Du hast das Konvertierungs-Skript verwendet und nicht nur per Hand die Zahl angepasst - sonnst müsstest Du auch alle anderen Konvertierungen per Hand durchführen...
            Zitat von daviid Beitrag anzeigen
            Damit hat auch der Cometvisu-Editor das File gefressen.
            Dann hat sich auch noch der Editor über die Dateirechte beschwert, dann hab ich mal mit "chmod 777 config/*" alles auf 777 gesetzt.
            Dann läd immerhin der Editor die Config.
            Aber wenn ich nach einer Änderung speichern will erscheint ein Popup mit der Meldung:

            Code:
            configuration could not be saved, server responded with 'backup-file is not writeable, please chmod/chown directory '''
            Am Ende sind ja leere Anführungszeichen, ich nehme an da drin sollte irgend etwas stehen, nämlich in welchem directory die Berechtigungen nicht passen.
            Welches könnte das sein?
            Im Config-Verzeichnis (hattest Du nur die Dateien kopiert, oder das neue Config-Verzeichnis mit dem alten überschrieben?) liegen inzwischen die Ordner "backup" und "media". Die müssen da sein und auch für den Web-Server-Prozess schreibbar sein.
            TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

            Kommentar


              #7
              Danke Chris für die ausführliche Antwort!

              Ich hab dann vorgestern Nacht nochmal da dran rum gemacht, alles mögliche probiert, und irgendwie ging es dann einfach, obwohl ich nichts am docker-compose geändert hab.
              So ganz verstanden hab ich es leider nicht.
              Hab dann auch nochmal versucht das irgendwie zu reproduzieren, aber leider ohne Erfolg.
              Es dauert halt einen Moment bis das caching von den ganzen GAs durch ist, aber danach läuft es.

              Aber ich kann hier mal mein docker-compose posten, falls das jemand interessiert:
              Code:
              version: '3.4'
              services:
              cometvisu:
              image: "cometvisu/cometvisu:latest"
              restart: always
              networks:
              - "traefik_net"
              ports:
              - 4000:80
              volumes:
              - ./resource/config:/var/www/html/resource/config
              environment:
              KNX_INTERFACE: "ipt:172.26.193.148"
              CGI_URL_PATH: "/cgi-bin/"
              KNX_PA: "1.1.238"
              KNXD_PARAMETERS: "-u --daemon=/var/log/knxd.log -t 65535 -c --error=3"
              labels:
              - "traefik.enable=true"
              - "traefik.http.routers.cometvisu.rule=Host(`visu.localdomain.local`)"
              - "traefik.http.routers.cometvisu.entrypoints=we b"
              - "traefik.http.services.cometvisu.loadbalancer.serv er.port=80"
              
              
              
              networks:
              traefik_net:
              external: true
              Für die die es intressiert, traefik ist ein reverse proxy. Damit sorge ich dafür dass ich die visu über die Domain 'visu.localdomain.local' erreichen kann, anstatt über die IP/Domain des Servers und en entsprechenden Port (auf dem Server laufen noch andere Sachen, deshalb, kann bzw. möchte ich nicht direkt Port 80 nutzen).
              (Damit das mit der Domain funktioniert muss man natürlich im lokalen DNS-Server auch diese Domain hinterlegen, in meinem Fall ist das ein Ubiquiti EdgeRouter Lite).

              LG und nochmal vielen Dank für die Hilfe
              David

              Kommentar

              Lädt...
              X