L'implémentation classique : Odoo/docker

Odoo/docker est l’image officielle distribuée par Odoo SA.  Le conteneur vient avec sa version du code et est mis à jour, disons-le, sporadiquement.  L’utilisation de cette image amène à une pipeline très classique de docker. L’image mère contient le “code” nécessaire pour rouler la solution et les images filles embarqueront des spécificités de l'intégrateur, puis celles du client, par exemple.

Cette approche demande des ressources bien au fait de la mise en place d’un pipeline Docker car il est prévisible que beaucoup d’images vont être construites. C’est l’utilisation de référence « by the book » de la technologie.  C’est la même approche que lorsqu'on utilise les images de Nginx, de Python et autres images officielles.  Sa grande faiblesse, c'est qu'elle pousse à avoir une version unique du code Odoo pour l’ensemble des clients. Par conséquent, cela exige la mise en place de tests validant le maintien de toutes les fonctionnalités de chaque client afin de diminuer l’apparition de dysfonctionnements. Notre image, Numigi/odoo-public est basée sur cette approche. 

Le couteau suisse : Technativa / doodba

Doodba est une image docker développée par Tecnativa et dont Jayro est le mainteneur principal.  Elle renferme une série d’outils pour aider au développement — déploiement, mise à jour du code sur les dépôts git, des services tournent sur chaque environnement (dev, test ou prod) et  plus encore.  En ce qui concerne Odoo, c'est une coquille vide puisque vous devez y injecter la version du code que vous souhaitez utiliser.

Je retiens que Doodba semble parfait pour une petite structure qui n’a pas les ressources et/ou les besoins suffisants pour développer une solution sur mesure.  Ce conteneur Docker venant avec de nombreux outils sera cependant moins pertinent et peut être plus contraignant pour une grosse structure disposant déjà de ses propres outils.

L'approche intermédiaire :

Camptocamp / docker-odoo-project

CamptoCamp a voulu garder ainsi une grande souplesse sur la version du code qui est implémentée chez le client, tout en bénéficiant d'une image de base simple qui uniformise les outils des développeurs.  C’est aussi l’approche qu’Akretion, un autre partenaire historique d'Odoo, a privilégiée.

Conclusion

Il faut admettre qu’aucune de ces approches ne se démarque radicalement des autres. Elles ont toutes leurs avantages et leurs faiblesses.  Mais le dialogue était présent et il reste intéressant de découvrir ce que font chacun des partenaires.  Quelle que soit l'approche privilégiée, il est clair que la technologie Docker fait maintenant partie de l'environnement des projets Odoo et qu'elle est là pour rester, du moins jusqu'à ce qu'une autre technologie la surpasse.