Commentaire sur la fiche : Déploiement du logiciel BDF avec Docker

Si la réponse à cette question ne vous parait pas claire ou si elle vous semble obsolète, n’hésitez pas à nous en faire part.

Et nous sommes preneurs également de toute correction de faute d’orthographe ou de grammaire...

Rappel du texte de la fiche :

Docker est un logiciel qui permet d’empaqueter des applications sous forme de « conteneur », ce qui permet de les installer facilement. Dans le cas du logiciel BDF de gestion de fichothèque, Docker va notamment permettre de ne pas se préoccuper de l’installation de Tomcat.

Le dépôt Git du logiciel BDF propose un répertoire /docker/bdf/ qui contient un fichier Dockerfile avec toutes les instructions pour construire une image Docker avec le logiciel BDF et Tomcat.

Pour construire cette image, il suffit de lancer le script build-bdf.sh. Une fois l’image construite, le script run-bdf.sh permet de lancer l’application en activant le conteneur. BDF peut alors être consulté à l’adresse http://localhost:8181/bdf/multi-admin, la page qui s’ouvre étant celle de l’initialisation des codes d’accès aux fichothèques.

Détails sur la construction de l’image

Dockerfile utilise les fichiers du répertoire /docker/bdf/conf/ comme fichier de configuration de l’application BDF (on retrouve les fichiers context.xml et bdf-conf.xml dont on retrouvera la description la fiche Le format XML du fichier de configuration <bdf-conf>).

/docker/bdf/conf-central/ contient une configuration alternative avec une sphère centrale nommée admin. Cette configuration alternative peut être utilisée avec le paramètre central lors de l’appel des scripts.

Utilisation de la configuration alternative

./build-bdf.sh central
./run-bdf.sh central

Point important : Docker va utiliser la toute dernière version de Tomcat telle que présente dans DockerHub et qui s’appuie sur une version récente de Java. Il va également télécharger la dernière version de BDF proposé sur le serveur de production de la FPH (. Ce n’est donc pas la configuration la plus testée.

À propos des points de montage

Pour éviter que la suppression d’un conteneur supprime les données qu’il a pu modifier, une des solutions est de faire des points de montage qui permettent au conteneur de lire voir d’écrire des données situées hors du conteneur lui-même. C’est la solution retenue par le script run-bdf.sh qui définit par trois points de montage :

le premier pointe dans le conteneur vers le chemin défini par <etc-dir> dans le fichier de configuration bdf-conf.xml ; ce répertoire contient les divers fichiers de configuration auxquels BDF accède en lecture seule (en particulier bdf-smtp.ini qui contient les paramètres pour l’envoi de courriels) . Par défaut, l’origine de ce point de montage sur l’hôte est docker/bdf/data/etc/ ;
le deuxième pointe dans le conteneur vers le chemin défini par <var-dir> dans le fichier de configuration bdf-conf.xml ; c’est dans ce répertoire que BDF écrira toutes les données saisies. Par défaut, l’origine de ce point de montage sur l’hôte est docker/bdf/data/var/ ;
le troisième pointe dans le conteneur vers le chemin défini par <dir key="lib.extensions"> dans le fichier de configuration bdf-conf.xml ; ce répertoire est destiné à accueillir les extensions de BDF. Par défaut, l’origine de ce point de montage sur l’hôte est docker/bdf/data/extensions/.

On pourra évidemment adapter le script run-bdf.sh pour que l’origine des points de montage sur le système hôte soit différent, notamment si on va au delà du test et qu’on saisit de « vraies » données.