<p>Envole est une solution qui propose un ensemble d'applicatifs web fédérés autour d'un annaire afin de gérer l'identité ainsi qu'un SSO afin de gérer l'authentification.</p>
<p>Il s'appuit sur la distrution EOLE pour déployer ses différents composants.</p>
<p>Envole rencontre depuis des années des problèmatiques :</p>
<ul>
<li>Elle doit se baser sur une version précise d'EOLE 2.5 ou 2.6 ou 2.7 ou 2.8 ou 2.9 qui ont chacune leur contrainte de version php</li>
<li>Les différentes applications Envole ont leur propre contrainte de version php.</li>
<li>Ce qui oblige de limiter les possibilités de montée de version de l'application dans une version x d'eole car cette dernière ne fournit pas la version minimum de php requise</li>
<li>Ou qui empéche le passage d'une application de fonctionner dans une version x d'eole car cette dernière propose une version trop résente de php pour l'application</li>
</ul>
<p>Ce document va chercher à évaluer la possibilité de conteneriser les applications Envole, afin qu'elles puissent fonctionner le moins possible en contrainte avec la version d'Eole</p>
<h2id="architecture">Architecture</h2>
<h3id="eolebase">EoleBase</h3>
<p>La présente étude part du principe qu'Envole ne serait plus installé sur une instance Scribe mais sur une installation EoleBase d'Eole</p>
<p><strong>Avantages</strong></p>
<ul>
<li>Décharger le serveur Scribe et lui laisser ses fonctions principales. C'est à dire
<ul>
<li>Contrôleur de Domaine</li>
<li>SSO</li>
<li>Annuaire</li>
<li>Imap (et SMTP ?)</li>
</ul>
</li>
<li>Faire évoluer plus facilement le serveur Envole vers des versions plus récente d'Eole avec moins de contrainte tout en assurant une mise à jour de sécurité plus régulière</li>
</ul>
<p><strong>Inconvéhients</strong></p>
<ul>
<li>L'adminstrateur devra configurer le lien SSO et Annaire qui eux restent sur le scribe.</li>
<li>Il devra donc fixer certains secrets sur le Scribe (notamment le compte reader/writer annuaire sur le scibe)</li>
<li>Connaitre et renseigner les hosts/ports des service SSO et Annuaire</li>
<li>Avoir un second nom de domaine pour l'accès aux applications Envole</li>
</ul>
<h3id="paquet-debian">Paquet Debian</h3>
<p>Contrairement à la précédente logique Envole, il n'y aurait qu'un seul paquet Debian pour Envole. Il n'installerait pas les sources des applications, mais uniquement</p>
<ul>
<li>le dictionnaire eole de configuration</li>
<li>les templates de configuration</li>
<li>le dossier de définitions de l'ensemble des conteneurs possible pour Envole</li>
<li>un script qui viendrait monter ou non les conteneurs souhaités par l'administateur</li>
</ul>
<h3id="poc">POC</h3>
<p>Afin de s'assurer de la faisabilité d'un tel changement, un POC a été initié, dans le cadre des éléments précédents cités. La première question fut de savoir quelle technologie de conteneurisation serait à utiliser PODMAN ou DOCKER, et dans leur logique de composer PODMAN-COMPOSE ou DOCKER-COMPOSER.</p>
<h3id="podman-vs-docker-sur-eole">PODMAN vs DOCKER sur Eole</h3>
<p><strong>PODMAN</strong></p>
<p>Eole a intégré à partir de la 2.9 dans sa distribution podman. Ce qui de prime abord devrait-être la technologie à utiliser, sauf que</p>
<ul>
<li>Ubuntu 22.04 ne dispose pas de paquet pour podman-compose</li>
<li>Pour installer podman-compose, il est nécessaire de l'installer via pip</li>
<li>De plus la version de podman disponible sur Ubuntu 22.04 est une version 3.4 qui n'est pas compatible avec la version de podman-compose</li>
<li>Il est nécessaire d'installer la dernière version 4.4 de Podman PPA pour faire fonctionner l'ensemble</li>
<li>Par la suite il est possible de créer un composer d'image docker comme on pourrait le faire avec docker-compose. Podman est juste plus stricte dans sa synthaxe et certaines commandes ne sont pas tout à fait indentique</li>
<li>Mais il apparait qu'un reconfigure rendra totalement inopérant le réseau des conteneurs. Pour le rendre de nouveau opérant, il est nécessaire de le détruire pour le reconstruire.</li>
</ul>
<p><strong>DOCKER</strong></p>
<p>Eole n'a pas intégré nativement docker. Mais il est tout à fait possible de l'installer par ses propres moyens sauf que</p>
<ul>
<li>Tout comme Podman Ubuntu ne propose pas de paquet suffisament à jour de docker-ce et docker-compose</li>
<li>Il est nécessaire de les installer via la mise en place d'un PPA</li>
<li>Par la suite docker se comporte bien mieux que podman. Il est plus souple d'usage, moins verbeux</li>
<li>Mais tout comme podman, un reconfigure vient rendre totalement inopérant le reseau des conteneurs. Il est nécessaire de réinitialiser docker-ce pour rétablir le reseau.</li>
</ul>
<p><strong>CONCLUSION</strong></p>
<p>Quoi qu'il arrive, une intégration compléte que cela soit avec Podman ou avec Docker, demandera un travail d'intégration d'Eole</p>
<ul>
<li>afin de disposer des dernières versions possibles de l'un ou de l'autre</li>
<li>que l'un ou l'autre ne détruit pas le réseau associé au composer de conteneur</li>
</ul>
<p>Ma préférence va malgrés tout sur Docker, il est plus souple moins verbeux et me semble plus fiable à long terme. Il serait possible de maitenir les deux solutions en parrallèle avec un effort supplémentaire d'intégration et de maintenance.</p>
<h2id="poc">POC</h2>
<h3id="sources">Sources</h3>
<p>Les sources du POC sont disponible ici<br>
https://forge.cadoles.com/Envole/envole</p>
<p>Elles sont pour l'instant hébergé à Cadoles pour des raisons de simplicité de mise en oeuvre, mais à terme elles seront bien stockées chez Eole</p>
<h3id="repository">Repository</h3>
<p>Certaines images sont hébergées elles aussi sur un repository public de Cadoles. Là aussi pour des raisons de simplicité de mise en oevre, mais à terme Eole devra fournir un repository propre aux images Envole.</p>
<p>Les images en questions sont celles des applications maintenues par Envole, en l'occurence pour l'instant uniquement Ninegate. Mais à terme pourra aussi y figurer des images d'applications tiers sur lesquelles nous aurions besion d'altérer légèrement le comportement.</p>
<h3id="installation-du-poc">Installation du POC</h3>
