Attention on parle ici à priori de fichiers statiques de la webapp, ils sont donc tels quels dans l’image Docker (je veux dire ils ne sont pas dynamiquement générés au démarrage ou autre). Donc si ce n’est pas le bon fichier que vous avez à l’arrivée c’est inexplicable à part s’il y a confusion sur l’image réellement utilisée (peut être une histoire de cache Docker pour votre build d’image custom ?) et/ou sur des histoires tordues de volumes Docker (implicitement liés à la manière dont fonctionne l’infra sur laquelle vous déployez ou dans le genre) et/ou à cause de proxies intermédiaires (ou de cache navigateur) qui garderaient abusivement des anciennes versions de ces fichiers, etc.
Pour vous en persuader faites le test sur un environnement Docker “de base” => un simple docker run ou un docker-compose et regardez le fichier tel qu’il est dans le container. Une infra complexe qui interdit d’ “ouvrir le capot” rend impossible toute investigation de notre part.
Une chose est certaine, nous ne reproduisons pas le pb sur un environnement simple (à base de docker-compose) tel que décrit dans un post précédent.
Pour info, et bien que cela n’ait pas forcément beaucoup de sens dans un contexte Docker, nous avons ajouté (en 5.1 alpha uniquement pour le moment) un mécanisme de vérification de la non altération des répertoires “clés” de la webapp Simplicité.
S’il n’y a pas de pb vous aurez désormais une trace au démarrage du genre:
22-Dec-2020 17:43:14.401 INFO [main] com.simplicite.util.AppLog.globalLog SIMPLICITE: Checksum verification: success
Sinon vous aurez des warnings et/ou des erreurs qui indiquent une probable altération des répertoires en question. Et au final vous aurez un message du genre:
22-Dec-2020 17:43:14.401 INFO [main] com.simplicite.util.AppLog.globalLog SIMPLICITE: Checksum verification: failed
Aucun de ces messages n’empêchera le démarrage de l’instance car il peut être légitime d’ajouter des JARs et/ou des JS/CSS comme vous le faites par exemple avec les plugins Fullcalendar (mais vous aurez donc un warning sur le répertoire scripts).
Ce mécanisme sera généralisé à toutes les versions/branches 4.0 et 5 prochainement et on le rendra peut être plus “fin” pour pouvoir situer plus précisément les altérations potentielles.
Oui la question est de savoir si le fichier sur le serveur AWS est le bon. Le ZIP que vous nous avez envoyé contient bien un fichier ui-bundle.js erroné par rapport à votre version (vue de votre navigateur).
Si le serveur contient bien le bon fichier source, alors c’est bien un problème de cache entre tomcat et votre navigateur. Simplicité vide correctement ses caches au clear-cache et en front vous verrez que toutes les URL des ressources statiques sont timestampées par version pour éviter ce problème de cache navigateur (ou proxy) lors des changements de version socle.
Sinon c’est un problème de recopie de nos versions GIT ou Docker sur vos instances AWS qu’il faudra analyser plus finement à chaque étage.
(le problème de “delete” au démarrage n’est pas reproduit non plus et présuppose d’être sûr que les class/jar déployés sont également corrects sinon on risque de chercher à résoudre des symptomes et non des causes).
Il faudra des répertoires fortement verrouillés (scripts/ui, les classes éditeur, libs…), les “ajouts” doivent se faire dans des zones réservées (comme les libs additionnelles partagées qui sont dans /jar et surtout pas dans /libs).
Et il me semble préférable de sortir un FATAL + arrêt du service si les répertoires protégés/systèmes sont non conformes.
Car il y a un risque majeur de perte de données si l’upgrade revient en arrière ou que sais-je d’imprévisible si des fichiers ont été corrompus par l’infra/paas ou une fausse manip.
On peut ensuite imaginer un redémarrage type rescue / sans echec en embarquant un zip des-dits répertoires + XML systèmes + suppression des addons (jar incompatible typiquement) qui seraient forcés avant redémarrage.
J’ai prévu le cas on peut dire si tel ou tel répertoire checké génère un warning ou une erreur (et pourquoi pas considérer une erreur comme un fatal qui arrête le démarrage)
Mais en fait dans scripts, par exemple, c’est pas forcément facile de faire le tri entre ce qui est vraiment essentiel (genre les scripts Simplicité mais aussi jQuery ou Bootstrap) et ce qui est plus ou moins “facultatif” car lié à des usages “non essentiels” (ex; Fullcalendar, jszip, …).
Et si on prend l’exemple des plugins Fullcalendar on peut pas non plus les mettre n’importe où.
Bref c’est pas aussi simple qu’il n’y parait…
Mais, surtout, je reste absolument persuadé que dans le cas des images Docker il n’y a aucune raison qu’il y ait des altérations autres que celles explicitement faites en buildant une image custom (sauf dans des cas hypothétiques de montages tordus avec des volumes là où il faut pas, ou dans le genre).
Notre image docker est stockée sur notre artifactory interne avant d’être poussé sur ECR. Sachant que cette image est bien déployée sur notre environnement de formation depuis ECR/ECS et sur mon environnement local depuis artifactory, ça voudrait dire qu’y a un problème dans AWS au moment du déploiement de l’image dans cet environnement particulier.
Le contrôle par checksum dont j’ai parlé plus haut est livré en 5.1 (alpha) nous en finalisons les tests aujourd’hui puis ce sera backporté en 5.0 (beta) et à priori livré ce soir si tout va bien.
Cela permettra de détecter d’éventuelles “incohérences” des fichiers clés dans le container qu’elle qu’en soit la raison.
Réciproquement si le contrôle par checksum est ok cela signifiera que le pb se situe ailleurs (ex: proxies, etc.).
Je vous tient au courant sur ce point.
PS: Comme discuté précédemment si vous pouvez nous fournir simplement un dump de votre base PostgreSQL ça nous permettrait de voir si on reproduit votre pb sur un environnement basique qui nous permet d’investiguer.
La vérification de checksum au démarrage a été livrée sur la 5.0 (beta), les images Docker sont à jour sur DockerHub.
En l’état:
Le contrôle est fatal (= annule le démarrage de la webapp) si les classes Java Simplicite (WEB-INF/classes) ou si les composants principaux de la UI (scripts/ui) sont impactés.
Le contrôle remonte une erreur si les libs Java (WEB-INF/lib) sont impactées
Le contrôle remonte un warning dans les autres cas
Typiquement votre ajout des plugins Fullcalendar vous mettra dans le cas d’un warning sur le répertoire scripts uniquement, du genre:
23-Dec-2020 14:09:47.521 WARNING [main] com.simplicite.util.AppLog.globalLog SIMPLICITE: Checksum verification failed on [scripts] directory ([57cadcac87b86f8544c503d47b5d65f6] vs [478f89d366aceae0cf6b84402d6ad796]), some core system files have been altered or files have been removed or added. This may have unpredictable effects!
23-Dec-2020 14:09:47.522 INFO [main] com.simplicite.util.AppLog.globalLog SIMPLICITE: Checksum verification: failed
NB: Ces règles sont susceptibles d’évoluer à l’avenir.
