Dans cet article, nous vous expliquons notre approche de déploiement hybride pour une application Symfony conteneurisée avec Docker. Ce système permet un déploiement à la fois sur des serveurs connectés à Internet et en mode local (on-premise) pour les zones de travail sans connectivité réseau.
Nous avons récemment entrepris la refonte complète de l’application ArSol pour l’équipe archéologique de l’université de Tours. Le logiciel original, une application desktop, était obsolète. Nous l’avons entièrement modernisé en développant une application web sur mesure… avec une interface utilisateur considérablement rajeunie de plusieurs décennies propulsée avec Symfony 7.4, PHP 8.4 et FrankenPHP.
Une des particularités du projet, c’est que l’application peut être utilisée sur des lieux de fouilles archéologiques ne disposant pas de réseau. Pour plusieurs raisons, l’idée d’une PWA a été écartée assez rapidement. Nous avons plutôt opté pour un mode de déploiement On-Premise : chaque site de fouille pourra ainsi faire tourner l’infrastructure complète (serveur web, bases de données et application Symfony) sur une machine locale. Les contraintes métiers nous ont permis de développer, sans trop de complexité, un système de verrouillage partiel de l’application (pour éviter tout conflit) et une synchronisation des données entre le SaaS (c’est-à-dire la production, le serveur central) et les instances On-Premise.
Je vais vous montrer aujourd’hui comment nous avons mis en place ce déploiement On-Premise (que j’abrégerai OP dans la suite de cet article). D’abord, nous verrons comment se présente la stack Docker, puis comment nous avons automatisé la création des images et le déploiement.
Pour ce projet, nous avons choisi de déployer l’application via des images Docker, aussi bien pour la production que pour les instances OP. Ainsi, ce sont les mêmes images Docker qui seront utilisées dans le mode SaaS et dans le mode OP. L’activation des différentes options et feature flags repose exclusivement sur des variables d’environnement.
Sur tous nos projets, nous utilisons docker-starter et ArSol n’y a pas fait exception. Ce squelette fournit une stack Docker complète, avec tout ce qu’il faut dedans pour que chaque intervenant du projet puisse le faire tourner en local facilement.
Docker-starter s’est amélioré au fil des années pour offrir une excellente DX à tous nos développeurs, qu’ils soient développeurs PHP ou intégrateurs, qu’ils soient à l’aise avec le fonctionnement de Docker ou pas du tout.
Pour cela, toute la stack est pilotée par des tasks Castor 🦫 :
castor start : construit les images si nécessaire, les démarre, installe les dépendances Composer/Yarn/npm, build les assets front, etc. Bref, cette seule commande suffit pour rendre le projet complètement fonctionnel en local, que ce soit au premier lancement ou aux lancements suivants ;castor migrate : joue les migrations Doctrine ;castor stop : stoppe toute la stack ;