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.
Il s'appuit sur la distrution EOLE pour déployer ses différents composants.
Envole rencontre depuis des années des problèmatiques :
- 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
- Les différentes applications Envole ont leur propre contrainte de version php.
- 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
- 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
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
## Architecture
### EoleBase
La présente étude part du principe qu'Envole ne serait plus installé sur une instance Scribe mais sur une installation EoleBase d'Eole
**Avantages**
- Décharger le serveur Scribe et lui laisser ses fonctions principales. C'est à dire
- Contrôleur de Domaine
- SSO
- Annuaire
- Imap (et SMTP ?)
- 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
**Inconvéhients**
- L'adminstrateur devra configurer le lien SSO et Annaire qui eux restent sur le scribe.
- Il devra donc fixer certains secrets sur le Scribe (notamment le compte reader/writer annuaire sur le scibe)
- Connaitre et renseigner les hosts/ports des service SSO et Annuaire
- Avoir un second nom de domaine pour l'accès aux applications Envole
### Paquet Debian
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
- le dictionnaire eole de configuration
- les templates de configuration
- le dossier de définitions de l'ensemble des conteneurs possible pour Envole
- un script qui viendrait monter ou non les conteneurs souhaités par l'administateur
### POC
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.
### PODMAN vs DOCKER sur Eole
**PODMAN**
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
- Ubuntu 22.04 ne dispose pas de paquet pour podman-compose
- Pour installer podman-compose, il est nécessaire de l'installer via pip
- 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
- Il est nécessaire d'installer la dernière version 4.4 de Podman PPA pour faire fonctionner l'ensemble
- 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
- 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.
**DOCKER**
Eole n'a pas intégré nativement docker. Mais il est tout à fait possible de l'installer par ses propres moyens sauf que
- Tout comme Podman Ubuntu ne propose pas de paquet suffisament à jour de docker-ce et docker-compose
- Il est nécessaire de les installer via la mise en place d'un PPA
- Par la suite docker se comporte bien mieux que podman. Il est plus souple d'usage, moins verbeux
- 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.
**CONCLUSION**
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
- afin de disposer des dernières versions possibles de l'un ou de l'autre
- que l'un ou l'autre ne détruit pas le réseau associé au composer de conteneur
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.
## POC
### Sources
Les sources du POC sont disponible ici
https://forge.cadoles.com/Envole/envole
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
### Repository
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.
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.
### Installation du POC
1- Instancier un eolebase 2.9
2- Installer eole-web
```
apt-get install eole-web
Genconfig
Services > Activer l'interface web de l'EAD = non
Services > Activer le serveur de bases de données MySQL = non
Services > Activer l’interface d’administration du module (EAD3) = non
Applications Web > Nom de domaine des applications web = mondomaine.fr
save & quit
Reconfigure
```
3- Installer docker & docker-compose
```
apt install git make apt-transport-https ca-certificates curl gnupg-agent software-properties-common
