Transformer Symfony monolithique en multi-applications : un guide étape par étape

Cet article de blog est basé sur la présentation de Florent Huck, Developer Advocate chez Upsun, lors de la SymfonyCon 2023. Nous avons utilisé des outils d'IA pour la transcription et pour améliorer la structure et la clarté du contenu.

Le passage d'une application monolithique unique à une architecture multi-applications ne doit pas nécessairement être intimidant. Lors d'une récente conférence de développeurs, Florent, de l'équipe Developer Relations d'Upsun, a présenté un guide pratique étape par étape sur la manière de refactoriser un monolithe en plusieurs applications à l'aide d'Upsun.

Pourquoi passer d'une seule application à plusieurs ?

Selon les données d'Upsun, 90 % des applications Symfony hébergées sur leur plateforme sont des monolithes, et seulement 10 % utilisent deux applications ou plus. Cette statistique révèle une opportunité significative pour les développeurs de moderniser leur architecture et de découpler leurs applications pour une meilleure évolutivité et maintenabilité.

Le projet présenté en exemple est le site de l'atelier « Bigfoot ». Il a démarré sous la forme d'une application Symfony 6.2 sur PHP 8.3 avec PostgreSQL 15 et sans interface d'administration. Pour l'atelier, l'équipe avait besoin du même site dans d'autres langues et d'un moyen simple de gérer le contenu. Cela a motivé le passage d'une application unique à une configuration multi-applications :

• Conserver Symfony comme application principale et ajouter API Platform pour exposer les données.
• Ajouter un administrateur à l'aide des composants API Platform Admin.
• Ajouter un front-end « white label » Gatsby qui lit à partir de l'API.
• Ajouter un serveur Mercure pour les mises à jour en temps réel.

Ce que Upsun gère pour vous

Upsun se situe entre votre code et le principal fournisseur de cloud que vous choisissez. Vous n'avez pas à gérer les serveurs. Vous envoyez votre code, définissez une configuration YAML simple, et Upsun se charge de l'hébergement. Un nouveau projet bénéficie d'une architecture prête à l'emploi : CDN, sauvegardes automatiques, caches, recherche et base de données. Même l'application de démonstration inclut PostgreSQL sans nécessiter d'étapes supplémentaires. Les certificats sont gérés pour vous avec des renouvellements automatiques, vous n'avez donc pas à vous soucier de la gestion des certificats TLS.

Si vous souhaitez découvrir rapidement le fonctionnement d'Upsun, commencez ici, sur le site web d'Upsun.

Quatre commandes pour démarrer

Le processus de déploiement est simple. Avec seulement quatre commandes utilisant l'interface CLI Symfony, vous pouvez mettre votre application en service :

1. Créer un projet de démonstration avec l'option Upsun
2. Initialisez un projet Symfony existant (qui génère automatiquement les fichiers de configuration nécessaires)
3. Suivez le processus Git standard (ajouter, valider)
4. Créer et pousser votre projet

À partir de là, chaque branche Git dispose de son propre environnement live avec une URL stable et un certificat valide. Vous testez dans un environnement qui se comporte comme un environnement de production. Grâce au travail de Fabien Potencier qui a intégré les outils CLI Upsun dans le CLI Symfony, tout peut être géré via une seule interface.

Étude de cas : le site web Bigfoot

Pour illustrer le processus de refactorisation, Florent a utilisé un exemple concret : le site web Bigfoot, initialement créé pour les ateliers Blackfire. Ce site de type blog consacré aux observations de Bigfoot a été construit comme un monolithe à l'aide de :

• Symfony 6.2 (mis à jour pour fonctionner avec PHP 8.3)
• PostgreSQL 15
• De nombreux fixtures
• Aucune interface d'administration

L'objectif était de transformer cette application unique en plusieurs applications interconnectées :

• Une application Symfony servant le site principal Bigfoot
• Un composant d'administration API Platform pour la gestion du contenu
• Un frontend Gatsby comme solution en marque blanche
• Un serveur Mercure pour la communication en temps réel

Processus de refactorisation étape par étape

1. Créer un nouvel environnement

Ne poussez jamais directement en production. Commencez par créer une nouvelle branche à l'aide de la CLI Symfony, qui crée automatiquement une branche Git locale et un environnement correspondant avec les mêmes données que votre branche précédente.

Upsun génère automatiquement des certificats SSL et gère leur renouvellement, éliminant ainsi le point faible auquel de nombreux développeurs sont confrontés lorsqu'ils gèrent manuellement les certificats.

2. Adapter la structure des dossiers

La transformation nécessite de réorganiser votre structure de dossiers. Au lieu d'avoir une seule application avec un dossier de configuration .upsun, vous créez :

• Un dossier d'.upsun racine contenant la principale
• Des dossiers séparés pour chaque application contenant leur code source respectif
• Chaque application dispose de sa propre configuration personnalisée

3. Ajouter API Platform à Symfony

Installez le bundle API Platform core dans l'application Symfony. Il expose une API REST à partir de vos entités Doctrine. Lorsqu'une entité change, les points de terminaison REST reflètent ce changement. C'est ainsi que le front-end Gatsby et l'administrateur liront et écriront le contenu.

4. Gérer la configuration 

Upsun utilise un seul fichier de configuration YAML. Ce fichier contient trois sections principales :

Configuration des routes : chaque application dispose de son propre bloc de routage. Vous définissez des modèles d'URL, par exemple en utilisant le domaine par défaut pour l'application principale, /admin pour l'interface d'administration,  /site pour le front-end Gatsby et des sous-domaines pour des services tels que Mercure.

Configuration des services : l'ajout de services est très simple. Sous services , définissez les bases de données dont chaque application a besoin :

• type: postgresql avec version: 15 pour la base de données.

 Par exemple, pour ajouter Redis, il suffit de spécifier :

redis:

  type: redis

  version: 7

Vous pouvez ajouter ici de petits indicateurs de configuration (tels que la politique de mémoire maximale). Upsun transforme ce simple bloc en un service géré adapté au cloud que vous avez choisi. Vous n'avez pas à écrire de scripts de configuration spécifiques au fournisseur.

Configuration de l'application : pour chaque application, vous définissez :

• Runtime : spécifiez les versions majeures et mineures (par exemple, PHP 8.3). Chaque déploiement utilise la dernière version de maintenance pour cette ligne.
• Racine source : le dossier où se trouve le code de l'application.
• Relations : liez l'application à des services (par exemple, l'application Symfony à PostgreSQL).
• Montages : chemins accessibles en écriture tels que var/ pour le cache et les journaux.
• Web : emplacement de la racine Web et du contrôleur frontal (par exemple, public/index.php).
• Étapes de compilation et de déploiement : utilisez symfony build et symfony deploy de Symfony Configurator pour vider le cache, exécuter les migrations et exécuter toutes les commandes personnalisées dont vous avez besoin. Ajoutez des tâches cron et des workers si nécessaire.

Poussez, testez et promouvez

Lorsque vos modifications de configuration et de code sont prêtes :

• Poussez votre branche : symfony push déploie votre environnement de branche.
• Upsun affiche un petit graphique des applications et des services, vous permettant de confirmer les relations.
• Les routes sont générées à partir de vos règles de routage, telles que :
  • Site par défaut à la racine.
  • Admin à l'adresse /admin.
  • Site Gatsby à un chemin tel que /site.
  • Mercure sur un sous-domaine.

Testez chaque route. Lorsque vous êtes satisfait, exécutez symfony merge. Upsun favorise le passage de la construction à la production.

Allocation des ressources : ce qui change avec Upsun

Upsun introduit une commande CLI resource:set qui permet l'allocation des ressources par conteneur. Vous pouvez spécifier exactement la quantité de CPU et de RAM attribuée à chaque conteneur, ce qui rend la plateforme plus flexible et plus rentable.

Ce contrôle granulaire vous permet de :

• Réduire les ressources pour les environnements de développement
• Tester différentes configurations de ressources sur des environnements dédiés
• Ne payer que pour ce que vous provisionnez dans tous les environnements

Intégration continue

Upsun prend en charge l'intégration avec GitHub, GitLab et Bitbucket. Lorsque vous créez une nouvelle branche et que vous la poussez vers votre référentiel, Upsun déploie automatiquement votre code source dans un environnement dédié, permettant ainsi une intégration continue adéquate.

Cependant, les développeurs doivent être attentifs à l'utilisation des ressources, car chaque environnement contribue à la facture mensuelle. Contrairement aux environnements de test de taille fixe, le modèle flexible d'Upsun signifie que vos branches de fonctionnalités peuvent avoir un impact sur les coûts si elles ne sont pas gérées de manière adéquate.

Meilleures pratiques

Déployez souvent, déployez en toute confiance

La devise d'Upsun est « Déployez le vendredi » (et même « Déployez le Black Friday »). La philosophie est simple : si vous pouvez tester vos fonctionnalités dans un environnement similaire à celui de production, vous pouvez pousser en toute confiance tout le code source nécessaire vers votre branche Git.

Cette approche élimine le cauchemar courant des développeurs : « Je ne comprends pas pourquoi la mise en scène a échoué ; cela fonctionne localement. » Avec une parité d'environnement appropriée, les fichiers manquants entraîneront des échecs dans votre environnement de développement avant d'atteindre la production.

Adaptation du processus Git

L'architecture multi-applications nécessite de légères modifications de votre processus Git, mais le processus de base reste familier. La clé est de déployer fréquemment et de tester minutieusement dans les branches d'environnement avant de fusionner avec la production.

Pièges courants et solutions

Au cours du développement du site multi-applications Bigfoot, plusieurs défis sont apparus :

1. Problèmes de routage : lorsque vous utilisez des éléments URI pour reconnaître les applications, vous devez signaler le premier élément URI dans le nom de la route et la configuration du chemin d'accès.
2. Variables d'environnement : le développement local utilise généralement localhost:8000, mais la production utilise des URL dynamiques. La solution du fichier .environment offre la flexibilité requise pour divers scénarios de déploiement.
3. Gestion des ressources : sans une planification minutieuse, les environnements de développement peuvent consommer autant de ressources que la production, ce qui a un impact significatif sur les coûts.

L'avenir de l'architecture multi-applications

Cette approche de la refactorisation ouvre de nombreuses possibilités pour le développement web moderne. En découplant votre monolithe en applications spécialisées, vous bénéficiez des avantages suivants :

• Une meilleure séparation des préoccupations
• De meilleures options d'évolutivité
• Diversité technologique (combinaison de Symfony, Gatsby et d'autres frameworks)
• Amélioration du processus de l'équipe de développement

Le projet Bigfoot a démontré avec succès comment un monolithe Symfony traditionnel peut évoluer vers une architecture moderne multi-applications tout en conservant toutes ses fonctionnalités et en ajoutant de nouvelles capacités, telles que la communication en temps réel et des interfaces d'administration avancées.

Où cela vous mène-t-il ?

Vous n'avez pas besoin de vous lancer dans le labyrinthe des microservices. Vous pouvez diviser un monolithe en plusieurs applications lorsque cela est judicieux, par exemple API, administration, front-end et temps réel. Le YAML unique, les services gérés, le HTTPS automatique et les environnements de branche d'Upsun rendent cette transition sûre et reproductible. Lorsque vous êtes prêt, fusionnez et passez en production.