ElabNET Technik Forum

Hallo @Chris M.

ich habe heute bei mir auf dem Timberwolf noch mal den 0.11-dev container frisch aufgesetzt und mich dabei leicht irritieren lassen! Ich weiß nicht ob dies ein Fehler ist oder oder so gehört, wenn ja würde ich die Doku noch verbessern

Direkt nach dem container deploy habe ich folgendes eingegeben Damit wurde aber nur "Loading..." angezeigt und nichts ging weiter? Ich habe mir dann den Wolf gesucht, aber nichts zustande gebracht...
Heute abend dann doch ein Geistesblitz Vola, es war nur nicht die richtige Config geladen

PS: Wenn dies normal ist, würde ich die Doku da noch verfeinern.

Gruß

Matthias

Danke Matthias, bei mir das gleiche Phänomen. Meine ersten Versuche mit der CV auf dem TWS, allerdings die 'stable' 0.10.2.
Dein Tip hat mir weiteres Suchen erspart! Mit einer gespeicherten default-config läuft es jetzt.

Matthias hat geschrieben: ↑Mo Jan 14, 2019 11:29 pm Direkt nach dem container deploy habe ich folgendes eingegeben

Code: Alles auswählen

https://timberwolf153.local/proxy/visuDev/

Damit wurde aber nur "Loading..." angezeigt und nichts ging weiter? Ich habe mir dann den Wolf gesucht, aber nichts zustande gebracht...
[...]
PS: Wenn dies normal ist, würde ich die Doku da noch verfeinern.

Das sollte so nicht sein. Meist wird das durch ein Reload der Seite durch den Browser behoben.

Ursache ist noch irgend eine Inkompatibilität zwischen Proxy und Container.

Ich hatte auch masive Probleme.
Erst habe ich die 0.10.2 installiert. Alles bestens. Dann die 0.11 - config nicht gefunden...... also zurück auf die 0.10.2 .....immer noch keine config vorhanden.....
Auch ein löschen des Proxys im TW hat nichts gebracht. Ich konnte sogar nach löschen des Containers und des Volumes noch brauchbare Meldungen nach Aufruf der NICHTmehr vorhandenen Visu bekommen. Fand ich echt komisch.
Erst eine komplette Neuinstallation mit anderen Proxys wie z.B. /proxy/come-visu/ für die 0.11 und /proxy/cromevisu/ für die "latest" brachten nachvollziehbarer Ergebnisse.
Obwohl /proxy/visu/ gelöscht führt jede Installation der Container mit genau dienem Proxy zu Fehlern.
Gruß
Bernd

Hallo zusammen, der Effekt kommt mir bekannt vor.
Chris verwies mich dann auf einen speziellen URL-Parameter: Habt ihr das damit mal probiert?

Gruß
Jens

strippe186 hat geschrieben: ↑Di Jan 15, 2019 11:19 pmAuch ein löschen des Proxys im TW hat nichts gebracht. Ich konnte sogar nach löschen des Containers und des Volumes noch brauchbare Meldungen nach Aufruf der NICHTmehr vorhandenen Visu bekommen. Fand ich echt komisch.

Laienhaft - ich kenne den Aufbau der CV nicht - würde ich vermuten, dass es sich um Cache-Probleme mit dem Browser handelt.

Letztens hatte ich im Wiregate Shop einen Kunden, der meinte, ihm würde sein Preis aber günstiger angezeigt als wenn er auf den Bestellen-Button drückt und dann den Preis im Warenkorb sieht. Lag auch am Cache. Der Kunde hatte den Preis von einem früheren BEsuch im Cache und aus welchem Grund auch immer, diesen gesehen (er hatte sogar einen Screenshot).

Darum: Bei Problemen immer den Cache im Browser löschen. Besonders bei Wechsel zwischen verschiedenen Versionen

lg

Stefan Werner

Hallo Chris

Chris M. hat geschrieben: ↑Mo Jan 14, 2019 7:18 pm Der Hauptknackpunkt wird das Erstellen des cometvisu/cometvisuabstractbase Containers sein, da dieser von DockerHub automatisch gebaut wird - und ich befürchte, dass die das mit ARM nicht können.
Theoretisch sollte sich dieser aber 1:1 auch unter ARM bauen lassen und dann als ARM Version hochladen. Dockerfile ist ja öffentlich sichtbar.

Eigentlich sollte das kein Problem sein. Ich baue schon seit längerem ARM-Images auf x86, das geht wunderbar.

Hab' mal einen Blick auf das Dockerfile geworfen und so auf die Schnelle würde sagen, dass die folgenden Anpassungen notwendig sind, um ein ARM-Image zu bauen:

• Installieren von qemu-user auf dem Host

• From-Tags ändern von php:7.2-apache in arm32v7/php:7.2-apache

• Das Binary qemu-arm-static muss im Builder vorhanden sein, also jeweils nach den From-Tags hinzufügen von

  COPY qemu-arm-static /usr/bin

Damit baust Du basierend auf dem ARM-PHP-Image auf einem x86 Host. Hier hat's noch ein wenig mehr Doku dazu.

Super, werde ich am Wochenende mal versuchen!

Das funktioniert
Hab gestern den Abend damit verbracht die Base in einer Ubuntu x64 Umgebung für ARM zu bauen (fast exakt so wie Yves es beschrieben hat) - das hat geklappt. Heute das selbe auf Windoof probiert - geht auch (also baut). Dann hab ich mir mal die Cometvisu Entwicklungsumgebung aufgesetzt und gebaut. Dann eben das Dockerfile mit meinem Container gefüttert - baut auch durch
Ich hab jetzt hier einen ARM Container liegen. Den muss ich nun nur noch auf einem PI testen (hab nix anderes da) - aber den muss ich auch erst noch aufsetzen. Das gehe ich morgen oder die Tage an (oder will jemand den Container Export haben zum testen?). Nun gibts ein Bier (warum gibts hier keinen Beer Smiley?? )

Hans Martin

Wow Hans-Martin, ich bin sehr beeindruckt! Danke sehr.

Wir bauen bei uns die ARM-Software auch mit quemu, kontrolliert mit Mr. Jenkins, der dann auch gleich die installierbaren Pakete draus macht.

Unsere Entwickler checken den Code ins hauseigene GIT ein und automatischn läuft im Hintergrund das Deployment auf beiden Prozessorplattformen bis zum Paket durch. Das war mal ein großes Stück Arbeit, aber hält die Durchlaufzeiten so knapp wie möglich. Wir schaffen mehrere Versionen am Tag, wenn wir beim Zusammenbacken verschiedener Sprints sind.

lg

Stefan