CometVisu Docker: Testcontainer

[Chris M.]

Der offizielle CometVisu Container mit dem jeweilst aktuellem Entwicklungsstand gibt es nun unter cometvisu/cometvisu:testing (und in der Form cometvisu/cometvisu:testing-20181028 die letzten Stände vom jeweiligen Tag).
Sobald ein neuer Pull-Request gemergt wird, wird im Anschluss automatisch dieser Container gebaut.

Wichtige Änderung im Vergleich zum Container aus dem ersten Post in diesem Thread: der Config-Ordner (und folglich das Volume) muss nach /var/www/html/resource/config eingebunden werden.

Auch wenn das nun schon ziemlich stabil sein sollte: vor der breiten Ankündigung würde ich das noch bisschen testen wollen.

=> Wer weiß was er nun machen muss: gerne ausprobieren!
=> War jetzt nicht weiß. was das alles bedeutet: bitte noch ein paar Tage warten, dann wird's die richtige Anleitung geben.

Und natürlich noch der allgemeine Hinweis: Testing ist die Entwicklungsversion. Das ist kein Release! Nicht produktiv nutzen!

[Robert_Mini]

Und ich dachte ich hab heute mal einen freien Abend .
Bin gespannt,
Robert

[Matthias]

Hi Chris,

danke für die Umsetzung, ich habe es wirklich schnell installiert bekommen.

Ich habe beim Import meiner alten Config aber das Problem, dass ich diese nicht korrekt angezeigt bekommen. Die Config ist im Design Metall gehalten, wird aber in pure angezeigt. Auch wenn ich die die Beispielkonfig "metal" abspeicher und nachher wieder neu hochlade, wird sie in pure angezeigt...

Irgendeine Idee

Gruß

Matthias

[Robert_Mini]

Hallo Chris!

Läuft soweit bei mir! - leicht zu erkennen durch das aufgeräumte Metals Design - wie Peuter im KNX-UF gepostet hat.
2 Dinge habe ich noch nicht ganz geschafft:
1) Den CV-Entwicklungs-Docker parallel zum Release - braucht der dann einen eigenen Reverse Proxy und einen eigenen Port anstelle 18080?
2) Die Mediendateien: Wohin lädt der Manager diese? nach config/media?
Was braucht es dann für einen Pfad in der config?

Code: Alles auswählen

<image src="media/OG.svg" widthfit="true"> oder
<image src="config/media/OG.svg" widthfit="true"> oder ???

Will nicht so recht klappen, hab den Manager aber bis jetzt nicht verwendet (und ssh gibt's im Container ja noch nicht vermute ich mal?).
Hochgeladen habe ich die Datei mit dem Manager.

Danke
Robert

[Robert_Mini]

Ich habe beim Import meiner alten Config aber das Problem, dass ich diese nicht korrekt angezeigt bekommen. Die Config ist im Design Metall gehalten, wird aber in pure angezeigt. Auch wenn ich die die Beispielkonfig "metal" abspeicher und nachher wieder neu hochlade, wird sie in pure angezeigt...
Irgendeine Idee

Am einfachsten in der URL ein &design=metal anhängen.
Achtung: das #id_ muss dahinter stehen.

Beispiel:

Code: Alles auswählen

https://timberwolf117.local/proxy/cvtest/?config=Test&design=metal#id_

Ansonsten steht bei mir im config file ebenfalls metal:

Code: Alles auswählen

<pages xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" design="metal" lib_version="8" xsi:noNamespaceSchemaLocation="./visu_config.xsd">

Bei mir klappt so, in der URL gebe ich kein design an.

lg
Robert

[Chris M.]

Ich habe beim Import meiner alten Config aber das Problem, dass ich diese nicht korrekt angezeigt bekommen. Die Config ist im Design Metall gehalten, wird aber in pure angezeigt. Auch wenn ich die die Beispielkonfig "metal" abspeicher und nachher wieder neu hochlade, wird sie in pure angezeigt...

Hm, seltsam.

Hast Du evtl. unter der gleichen URL vorher den 0.10.2 Contianer und evtl. den Browser-Cache nicht geleert?

Ansonsten: sagt der Check (z.B. aus dem Manager heraus aufgerufen), dass die Config valide ist?
Falls ja: gibt es irgendwelche Fehlermeldungen auf der Browser Konsole (Strg+Shift+I)?

Hinzugefügt nach 11 Minuten 41 Sekunden:

1) Den CV-Entwicklungs-Docker parallel zum Release - braucht der dann einen eigenen Reverse Proxy und einen eigenen Port anstelle 18080?

Kommt darauf an was Du machen willst.
Direkt und ohne HTTPS zugreifen => kein Proxy notwendig (Zugriff über http://timberwolf:12345/)
HTTPS verwenden => Proxy ist notwendig

Jedes mal muss der Port (18080, 12345, ...) für jeden Container anders sein, egal ob mit Proxy oder nicht. Und natürlich der Pfad zu den CGIs muss dazu passen.

2) Die Mediendateien: Wohin lädt der Manager diese? nach config/media?
Was braucht es dann für einen Pfad in der config?

Code: Alles auswählen

<image src="media/OG.svg" widthfit="true"> oder
<image src="config/media/OG.svg" widthfit="true"> oder ???

Müsste ich nochmal checken
Für 0.11 (also die aktuelle Entwickungsversion) rate ich mal: resource/config/media/

(und ssh gibt's im Container ja noch nicht vermute ich mal?).

Nein, ssh ist noch nicht drinnen. In die normalen kommt das auch nicht rein da es auf produktiven Containern nichts zu suchen hat. Aber ich schaue noch, ob evtl. automatisiert basierend auf den Containern solche mit ssh gebaut werden können.

[Robert_Mini]

...
Jedes mal muss der Port (18080, 12345, ...) für jeden Container anders sein, egal ob mit Proxy oder nicht. Und natürlich der Pfad zu den CGIs muss dazu passen.

Danke für die Erläuterung zu den Containern.
Da muss ich noch den besten Weg finden, wie man Container kopiert/dupliziert ohne den alten zu löschen und dann entsprechend modifiziert => neuer Port.

Für 0.11 (also die aktuelle Entwicklungsversion) rate ich mal: resource/config/media/

Gut geraten - hat genau so geklappt .

Nein, ssh ist noch nicht drinnen. In die normalen kommt das auch nicht rein da es auf produktiven Containern nichts zu suchen hat. Aber ich schaue noch, ob evtl. automatisiert basierend auf den Containern solche mit ssh gebaut werden können.

Das wäre super!

Danke
Robert

[starwarsfan]

Hallo miteinander

Jedes mal muss der Port (18080, 12345, ...) für jeden Container anders sein, egal ob mit Proxy oder nicht. Und natürlich der Pfad zu den CGIs muss dazu passen.

Ich habe das auf dem TW resp. mit Portainer nicht explizit ausprobiert aber dass die Ports bei jedem Container explizit anders sein müssen, ist nicht korrekt. Die können durchaus gleich sein, nur kann dann jeweils nur ein Container gestartet werden. Damit ist es überhaupt kein Problem, einen hinsichtlich Container-Setup identischen Container anzulegen. Dieser kann dann eben nur dann gestartet werden, wenn der "andere" Container vorher gestoppt wurde. Damit lässt sich hervorragend experimentieren, wenn es kein Problem ist, den "anderen" Container zu stoppen.

Just my two cents...

[Robert_Mini]

Danke Yves!
Hier gilt es noch best practice zu finden.
Zb bin ich gespannt ob die Visu Clients Star/stop des Containers vertragen oder dann ein reload erforderlich wird.
Dafür gibt‘s in der CV bereits ein Reload on GA, aber mal sehen.

Robert

[jockel]

@Robert_Mini

Versteh ich das richtig, dass dein Vorgehen nicht mit Portainer umsetzbar ist, sondern man Docker in einer Linux-Umgebung braucht?

Ich hab das jetzt auch mal mit dem Portainer auf dem Timberwolf ausprobiert und im ursprünglichen Thread eine kleine Anleitung ergänzt:
viewtopic.php?p=2567#p2567