Suite à l’installation de simplicité 5 via docker-compose en local sur mon poste, je cherche à déployer différents modules applicatifs dont les sources sont disponibles dans différents repo git.
Steps to reproduce
This request concerns an up-to-date Simplicité instance
and these are the steps to reproduce it:
J’ai :
1/ git pull les différents repo sur mon poste
2/ j’ai ensuite essayé de les prendre en compte via l’import XML du fichier xml (pas le pom.xml, le fichier de description simplicite) à la racine des modules
L’import du module de base à fini en erreur (bien que les logs ne montrent rien d’anormal)
Il y a de nombreuses manières de packager/déployer un ou plusieurs modules.
Au niveau packaging, pour simplifier, il y a 2 formats de package pour un module:
Soit un fichier unique XML ou JSON contenant tout le paramétrage et le code et les ressources inlinés (en texte brut ou en base64) à l’intérieur, c’est un format parfois pratique car mono-fichier mais c’est pas très exploitable humainement et ça aboutit parfois à de très gros volumes car base64 est verbeux.
Soit une arborescence de fichiers avec un fichier XML ou JSON à la racine contenant le paramétrage et référençant des chemins relatifs vers les fichiers du code et des ressources. Ceux-ci étant éclatés dans une arborescence humainement exploitable (i.e. structuré en projet Maven) => c’est ce format qui est utilisé dans les exports ZIP/tar.gz et dans les repos Git
Pour importer un module dans le second format il ne suffit pas d’importer le XML/JSON à la racine car il va lui manquer le reste. Il faut donc importer un ZIP contenant l’ensemble de l’arborescence (i.e. la même chose qu’un export ZIP) ou passer par les mécanismes Git qui gèrent l’intégralité de l’arborescence du repo (l’idéal quand on parle de repo Git sur GitHub c’est de fonctionner - comme c’est le cas sur l’instance de dev - avec des URL et une clé SSH associé à ton compte GitHub, sinon c’est aussi possible d’utiliser une URL HTTPS et un user token GitHub)
Pour ce qui est de l’import d’une application complète = d’une “grappe” de modules, le bon outil pour automatiser dans un contexte Docker est l’ “importspec”. cf. Simplicité® documentation/90-operation/docker-tutorial
Ca permet de livrer un container qui embarque ou référence les modules à importer au démarrage. Pour que ça marche il faut une gestion rigoureuse des numéros de version car c’est là dessus que ce base l’algo de l’importspec pour savoir s’il a besoin ou pas d’importer les modules
Typiquement dans le cas qui nous intéresse le descripteur de l’importspec ressemblera à ça:
modules:
- name: TdfInfra
version: "<la version du module>"
git:
uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra.git"
- name: TdfInfraAnomalies <===== ZZZ à voir pour celui là ZZZ
version: "<la version du module>"
git:
uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra-anomalies.git"
- name: TdfInfraFrontend
version: "<la version du module>"
git:
uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra-frontend.git"
- name: TdfInfraHELIOS
version: "<la version du module>"
git:
uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra-helios.git"
- name: TdfInfraREFACCES
version: "<la version du module>"
git:
uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra-refacces.git"
Dans le cas présent il va y avoir un besoin de customisation de l’image Docker standard car il va falloir ajouter les datasources supplémentaires qui pointent vers les bases externes : HELIOS, REFACCES et autres (?)
Pour ça il faudra un Dockerfile du genre:
FROM registry.simplicite.io/platform:5-latest
COPY datasources.xml /tmp/
RUN sed -i '/extraresources/r /tmp/datasources.xml' /usr/local/tomcat/webapps/ROOT/META-INF/context.xml && \
rm -f /tmp/datasources.xml
NB: Par défaut on embarque un driver Oracle à jour (actuellement 21.7.0.0) dans nos images Docker (dans /usr/local/tomcat/lib), si ça ne convient pas pour les bases en question (je ne vois pas de raison à priori, mais on ne sait jamais) il faudra aussi mettre en place le remplacement de ce driver par celui qui va bien dans la customisation de l’image ci-dessus.
J’ai donc ajouté ce bloc module dans mes variables d’env pour le service simplicite du docker-compose, j’ai ajouté les volumes me permettant de faire du git clone dans le conteneur (clef privée, know_host, etc…)
Au lancement j’ai curieusement des erreurs de git checkout master sur les 5 modules
Caused by: org.eclipse.jgit.api.errors.RefNotFoundException: Ref master cannot be resolved
at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:223)
at com.simplicite.util.tools.GitTool.checkout(GitTool.java:883)
… 46 more
2022-11-29 20:36:04,174|SIMPLICITE|ERROR|Error during module TdfInfra import
2022-11-29 20:36:04,247|SIMPLICITE|ERROR|Error during module TdfInfraAnomalies import
2022-11-29 20:36:04,324|SIMPLICITE|ERROR|Error during module TdfInfraFrontend import
2022-11-29 20:36:04,380|SIMPLICITE|ERROR|Error during module TdfInfraHELIOS import
2022-11-29 20:36:04,437|SIMPLICITE|ERROR|Error during module TdfInfraREFACCES import
J’imagine que l’outil git utilisé dans la JVM ne voit pas la conf ssh du conteneur hôte.
Y a t-il une manière de configurer les modules dans le docker-compose pour faire référence à la conf ssh du conteneur hôte de la JVM ?
Autre question, je vois bien l’usage de cette configuration pour une plateforme d’intégration/recette
Par contre sur un environnement de dèv, comment les modifications faites par les développeurs sont elles repoussées dans les différentes modules git ? c’est prise en charge par l’IHM d’admin simplicité ?
Sur l’autre question il faut voir avec les devs comment ils se sont organisés pour travailler sur les différents modules, sachant que pour le moment j’ai gardé la main sur TdfInfraHELIOS et TdfInfraREFACCES
Désolé mais j’ai toujours mon problème de git
J’ai fait le montage comme précisé dans la doc
volumes:
- .ssh:/usr/local/tomcat/.ssh:ro
et ajouté la var d’env
SSH_KNOWN_HOSTS: "github.com"
Lorsque lance le conteneur le répertoire .ssh est bien présent à la fois dans tomcat et dans /root
Si je fais un git clone ça marche bien
Par contre dans les logs de l’appli
Caused by: org.eclipse.jgit.api.errors.RefNotFoundException: Ref master cannot be resolved
at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:223)
at com.simplicite.util.tools.GitTool.checkout(GitTool.java:883)
… 46 more
“Si je fais un git clone ça marche bien” => tu veux dire un git clone manuel en ligne de commande dans le container ? sinon quelle est la manip que tu fais ?
Alternativement il est aussi possible d’utiliser une URI GitHub en https:// et une authent/ident via un personal access token GitHub plutôt que via clé SSH, il faut changer les settings en :
Sinon il faut peut être forcer la suppression du répertoire clone dans le répertoire git dans le container (ex: s’il reste des choses de manips précédentes)
Ce qui est bizarre c’est que si ça clone en ligne de commande dans le container ça devrait aussi marcher au niveau de la lib jGit dans Simplicité sauf si le format de la clé SSH n’est pas gérée par jGit ou autre subtilité qui m’échappe.
Perso, avec GitHub j’utilise des clés au format Ed25519 (générées via ssh-keygen -t ed25519) plutôt que RSA.
C’est un pb de known host que jGit (ou la lib SSH sous jacente = jSch) vérifie (mais que le CLI git ne doit sans doute pas vérifier).
Si on monte le répertoire .ssh en readonly (:ro) la mécanique liée à la variable d’environnement SSH_KNOWN_HOSTS ne peut pas marcher car elle ne peut pas écrire le fichier known_hosts dans le répertoire .ssh.
Donc 2 solutions:
avoir déjà github.com dans le fichier known_hosts dans le répertoire .ssh hôte qui pourra alors effectivement être monté en read only (un simple ssh github.com sur l’hôte permet de l’ajouter)
monter le répertoire .ssh avec les droits d’écriture et la variable d’environnement SSH_KNOWN_HOSTS positionée (à github.com)
J’ai testé 1) ça marche, 2) j’ai pas testé mais ça devrait le faire aussi (mais j’aime moins l’idée d’un montage pas en read only)
Oui à la réflexion je suis aussi un peu perplexe car je crois me rappeler qu’on avait fait en sorte de recopier le .ssh depuis son point de montage justement pour rendre la création/modification du known_hosts possible. Comme j’ai aussi fait des manips dans le container j’ai peut être faussé le test.
Je vais regarder ça de plus près, en tout cas c’est forcément cette histoire de check du known hosts qui diffère entre jGit et le CLI git : Il y a peut être un truc à la noix lié au mécanisme (qui a été ajouté récemment) qui permet d’exécuter Tomcat soit en root (mode par défaut historique) soit avec un user “normal” (simplicite)
Nous sommes en train de revoir la manière dont on gère les clés SSH dans nos images Docker. Il y a une combinatoire de cas d’usage assez important qu’on ne doit pas faire régresser, donc ça ne sera pas poussé tout de suite.
Dans le cas qui nous intéresse il faudra faire un truc du genre:
J’ai testé avec ce type de config en mode “manuel” (= création du module via la UI + clone/pull Git + import) et ça fonctionne avec les URI en mode SSH (la clé SSH en question est connue au niveau de mon compte GitHub).
Je testerai le cas du mode “automatisé” via l’importspec un peu plus tard mais ça repose sur les mêmes mécanismes sous jacents.
Il y a de toute façon encore quelques petites coquilles de paramétrage dans les modules de nature à faire planter l’import, je corrige quand j’en vois passer, à date il n’y en a plus mais mais le dev continue donc ça peut revenir.
Sinon je suis aussi en train de préparer ce qu’il faut pour builder l’image avec les datasources additionnels vers les bases externes. Je compéterai ce post quand ce sera au point.
J’ai refait une installation locale avec la dernière image et pullé les repo distants par création des modules manuellement et saisie d’un setting type
TdfInfra
{
“type”: “git”,
“origin”: { “uri”: “git@github.com:simplicitesoftware-projects/module-tdfinfra.git” }
}
Une fois tous les modules chargés (a priori correctement, les logs semblent ok) je ne vois pas de menu vision360, y a t-il quelque chose d’autre à faire ?
