J’aimerais vous parler du déploiement des applications Laravel pour les environnements de développement et de production. La façon par défaut d’installer une application Laravel pour le développement utilise désormais la technologie Docker, c’est pourquoi je souhaite mentionner une ou deux choses sur Docker, Laravel Sail, Spin, et les utilisations de chaque technologie.
Conteneurs Docker vs machines virtuelles
Dans les machines virtuelles (VM) plus anciennes et plus traditionnelles, la configuration ressemblerait à celle d’un serveur physique, avec un système d’exploitation complet et tous les logiciels nécessaires installés dessus.
Les conteneurs Docker sont généralement plus légers. Chaque conteneur Docker utilise le noyau du système d’exploitation de l’hôte au lieu d’avoir son propre système complet. De plus, chaque conteneur est généralement décomposé en un élément le plus petit possible.
Malgré le fait que les conteneurs Docker utilisent le noyau de la machine hôte, ils n’ont aucune connaissance de cette dernière et fonctionnent donc de manière isolée. Cela peut être un énorme avantage pour la sécurité.
Qu’est-ce que Docker Compose ?
Sachant que les conteneurs Docker sont généralement décomposés en petits morceaux, il s’ensuit qu’avec des applications plus grandes ou compliquées, nous pourrions en avoir besoin de plusieurs. Dans ces cas-là, il faudra pouvoir les orchestrer ensemble harmonieusement ; c’est là que Docker Compose entre en jeu. Docker Compose offre une structure de fichier de configuration astucieuse que le technicien peut utiliser pour définir toutes les parties et la façon dont elles fonctionneront ensemble.
Par exemple, je pourrais définir un fichier de configuration Docker Compose qui spécifierait qu’un serveur de base de données et un serveur Web sont tous deux nécessaires, et que le serveur Web dépend de la disponibilité du serveur de base de données.
Une fois la configuration pour Docker Compose définie, la mise en place de votre environnement se fait généralement en une seule commande. Le démontage est tout aussi simple.
Avantages
Nous utilisons la technologie Docker pour normaliser notre environnement de développement depuis un certain temps déjà ; cela a fait une énorme différence à plusieurs égards.
Les environnements locaux propres à chacun de nos développeurs sont désormais exactement les mêmes, ce qui élimine le problème du « Ça marche sur ma machine ». Cela est vrai même pour les développeurs qui utilisent les principaux systèmes d’exploitation (Windows/Mac/Linux). Les déploiements de machines de développeurs sont désormais rapides et efficaces, car elles sont toutes standardisées, et déployées de manière standardisée, généralement avec une seule commande.
Un autre point fort du travail avec les conteneurs Docker est que tous les logiciels nécessaires à un projet sont généralement contenus dans les conteneurs, ce qui permet de passer très facilement d’un projet à l’autre sans se soucier de configurations logicielles conflictuelles. De plus, Docker Compose s’auto-documente d’une certaine manière ; en conservant sa configuration au sein de nos référentiels de code, il est assez simple de déterminer avec quelle version de PHP un système a été conçu (à titre d’exemple).
Laravel + Docker = Sail
Ici, chez Direct Impact Solutions, nous avons utilisé PHP Laravel pour un nombre important de systèmes. Les créateurs de Laravel ont même adopté l’utilisation de Docker comme méthode d’installation par défaut en utilisant leur propre système Docker Compose, Laravel Sail. Laravel Sail est personnalisable et facile à utiliser, c’est pourquoi nous l’avons utilisé dans le cadre de certains de nos projets. J’aime la facilité avec laquelle il est possible d’ajouter de nouveaux conteneurs de services dans un projet. Par exemple, si en cours de développement l’application a maintenant besoin d’envoyer des courriels, il est possible d’ajouter un nouveau conteneur pour mailpit à l’aide de commandes intégrées.
Liste de souhaits pour Laravel Sail
Une chose regrettable à propos de Laravel Sail, cependant, est le fait qu’il n’utilise pas un serveur web traditionnel, mais plutôt une commande artisan (artisan serve) qui agit comme une enveloppe autour du serveur web intégré de PHP. C’est regrettable, car le serveur web intégré de PHP n’exécute qu’un seul processus à la fois (single-thread). En tant que tel, il n’est pas conçu pour gérer des requêtes multiples et ne devrait pas être utilisé pour les environnements de production.
Étant donné que Laravel Sail est construit à l’aide de la technologie Docker Compose, il devrait (en théorie) être possible de le faire fonctionner à l’aide d’un serveur web traditionnel, de sorte que nous n’aurions pas les limitations qui nous empêchent d’utiliser cette technologie en production. Malheureusement, je soupçonne que ce n’est pas près d’arriver. Cela a peut-être quelque chose à voir avec le fait que les développeurs de Laravel et de Laravel Sail ont également un produit de déploiement et de gestion de la production connu sous le nom de Laravel Forge.
Et maintenant ?
En raison de notre appréciation de la normalisation, de la simplicité et de Docker/Sail, nous étudions d’autres technologies dans l’espoir de trouver quelque chose qui offre la continuité que nous souhaitons entre les environnements de développement et de production.
Spin
ServerSideUP a récemment publié un outil de développement open-source, Spin, qui est très similaire à Laravel Sail. Spin vise à faire exactement ce que nous voulions à l’origine de Laravel Sail, et même plus ! Non seulement il nous permet de réutiliser le même environnement de développement au sein de la production, mais il en fait plus.
Utilisation de Spin
Pour commencer à utiliser Laravel Sail, le technicien exécutait souvent sail up -d à partir de la ligne de commande.
De même, lorsqu’on utilise Spin au lieu de Sail, on peut exécuter spin up -d pour créer un environnement. Des commandes similaires sont également fournies pour exécuter des commandes à l’intérieur des conteneurs Docker (il est courant d’exécuter des commandes PHP artisan depuis le conteneur PHP et des commandes npm run depuis le conteneur node ).
Vérifications des mises à jour de Spin
Spin vérifie les mises à jour avec la commande spin up. C’est rafraîchissant à voir, et ce n’est pas quelque chose que j’ai vu dans Laravel Sail.
Différences dans les environnements de Spin
En théorie, l’utilisation de Spin pour les déploiements de dev et de production devrait toujours produire des environnements identiques pour les utilisateurs finaux. Cependant, des fichiers Docker-compose.yml distincts sont fournis pour les deux, de sorte que pour les cas où certaines choses doivent changer entre les environnements (exemple mailpit en dev, serveur de messagerie approprié en production), Spin le supporte. Des fichiers Docker-compose.yml sont fournis pour dev, production et même pour l’intégration continue (CI).
Configuration de Spin
Un projet qui a intégré Spin sera livré avec d’autres fichiers de configuration au-delà des simples fichiers de configuration de Docker Compose. Ces fichiers de configuration supplémentaires permettent au technicien de définir des détails sur les connexions SSH et les comptes utilisateurs qui seront chargés de déployer la solution. Lorsqu’elle est déployée dans un environnement de production, la technologie Docker Swarm est utilisée. Il existe même un fichier .spin-inventory.ini au format Ansible inventory où il est possible de définir les serveurs à utiliser.
Chiffrement de Spin
Étant donné que Spin utilise un certain nombre de fichiers de configuration qui pourraient potentiellement contenir des informations sensibles, il est important de noter que Spin encourage fortement le cryptage de ces fichiers. Une fois cryptés, il est possible de stocker en toute confiance ces fichiers dans votre référentiel de code. Spin est équipé de son propre coffre-fort qui contient des commandes pour le cryptage, le décryptage, l’édition, etc.
Déploiements sans temps d’arrêt
Spin aide les techniciens en leur fournissant des modèles d’action GitHub et de la documentation à l’appui. Les nouveaux projets Laravel peuvent être démarrés avec Spin. Alternativement, Spin peut être ajouté à un projet Laravel existant.
Quelle que soit l’approche adoptée, des actions GitHub modélisées sont accessibles. L’action de facto consiste à déployer en production chaque fois qu’une nouvelle version est ajoutée à GitHub. La mise en place de cette action nécessite quelques autres éléments, mais Spin vous guide tout au long de ce processus.
Conclusion
Spin est similaire à Laravel Sail, utilise des technologies éprouvées comme Docker et Ansible, répondant aux critères de sécurité et de flexibilité, et élimine même le problème d’avoir des environnements de production et de développement différents (ce qui est la raison pour laquelle la plupart d’entre nous ont commencé à utiliser Docker en premier lieu). Spin contribue également aux déploiements sans temps d’arrêt, ce qui en fait un outil très prometteur dans nos coffre à outils.