Créé le 01/11/2021
Dernière mise à jour le 01/11/2021
Bilan des 7 derniers mois depuis le dernier article à ce sujet.
Je vais mettre en avant certains changements, il serait inutile de tous les lister ici, la plupart sont mineurs ou sont des corrections par rapport à de l’utilisation concrète du skeleton sur des projets.
Pour voir toutes les différences :
Reverse Proxy Traefik
Un support MacOS a été ajouté avec en prime l’ajout de commandes Make pour lancer Traefik selon l’OS et aussi la possibilité de le lancer en redémarrage automatique sans aucun fichier à modifier.
Pour le support MacOS sur le skeleton, il y a actuellement une MR, fonctionnelle pour un projet mais a priori ne fonctionnant pas si l’on veut plusieurs projets démarrés en parallèles.
PHP Psalm
Dans le précédent article, j’avais indiqué avoir laissé cet outil de côté car je n’avais pas trouvé de configuration adéquate.
J’ai insisté et ai fini par trouver les commandes à lancer au préalable et surtout comment configurer l’outil pour activer le mode « tainted » pour l’analyse de sécurité.
Ce qui m’a permis de découvrir un problème de sécurité sur File Extractor et Search API Attachments. Suite à cela, j’ai donc rendu privé l’affichage des résultats des Pipelines CI afin d’éviter d’afficher publiquement si une issue de sécurité était trouvée.
Si d’autres issues de sécurité sont trouvées, elles seront signalées à l’équipe de sécurité Drupal.
Dommage qu’il ne soit pas possible de masquer les résultats de CI sur certaines tâches ou branches.
Cypress
De même que pour PHP Psalm, mes premiers essais de Cypress n’étaient pas très positifs. J’ai réessayé de l’ajouter à ma stack et y suis parvenu pour un usage local.
En effet, je souhaite pouvoir utiliser les images Docker Cypress et ne pas avoir à maintenir les miennes, cela fonctionne en local. J’ai donc fait des commandes Make différentes pour lancer un conteneur Cypress contenant déjà plusieurs navigateurs.
Pour un usage dans Gitlab CI, suite à la consultation de nombreux tutoriels et articles à ce sujet, je n’ai pour réussi ce point car dans tous ces exemples, il est constamment question de tester une application en JS et donc le conteneur NodeJS qui fait fonctionner l’application a "simplement" à avoir Cypress et les tests sont exécutés sur ce même conteneur. Cypress ne peut pas être ajouté en tant que service et être piloté depuis le conteneur PHP, comme Chromedriver avec les tests PHPUnit (en tout cas, pas à ma connaissance actuelle).
Cela nécessiterait d’ajouter Cypress directement dans mon image PHP de CI, ce que je souhaite éviter car, Cypress a de nombreux pré-requis et qu’il faut installer les navigateurs souhaités pour les tests dans une version spécifique, ce qui ferrait accroître la taille de mes images pour un outil que je n’utilise pas encore suffisamment pour justifier cette mise en place.
Je reviendrai sur l’usage de Cypress dans un prochain article.
Scripts (beaucoup de scripts...)
Les scripts ont été retravaillés presque entièrement afin de permettre d’avoir :
- une gestion multisites (utile rien que pour la branche d’exemple d’environnement avec Entity Share),
- le packaging pour un environnement cible pour une branche ou un tag Git donnés,
- le déploiement sur un environnement cible avec séparation des étapes pour permettre de mettre à jour un site après l’autre et ainsi diminuer le temps de mise en mode maintenance de chaque site et différer des montées de version si besoin. Les différentes étapes séparées :
- déploiements des sources
- lien symboliques d’activation d’une release
- mise à jour
- le déploiement sur un environnement avec Docker utilisé pour faire fonctionner le projet,
- un ajout de scripts et commande Make pour avoir un minimum d’administration des sites distants :
- création de sauvegarde (possibilité de sauvegarder les fichiers publics et privés),
- suppression de sauvegarde,
- restauration d’une sauvegarde,
- je n’ai pas fait de script de purge des releases car pour l’instant par nécessaire et qu’il peut y avoir des besoins différents, car il faut vérifier qu’il n’y ait plus de site qui utilise la release à supprimer par exemple.
- la gestion des secrets, pour éviter de versionner des mots de passe par exemple :
- Gitlab CI est surtout intégré avec la solution Vault et pas grand chose d’autre. Je me suis donc renseigné sur Bitwarden CLI et malheureusement même avec des clés API il faut obligatoirement mettre à disposition un mot de passe maître, ce qui n’est pas top. J’ai donc opté pour un double système, pour des scripts exécutés localement, il est possible de gérer des mots de passe stockés dans un Bitwarden. Et pour un usage dans Gitlab CI, il faut renseigner des variables d’environnements dans Gitlab CI et il y aura un remplacement à la volée.
- la généralisation de l’utilisation des fichiers .env, même pour l’environnement Gitlab CI,
- l’utilisation de variables d’environnement pour les alias Drush, afin de continuer d’avoir un maximum de configuration gérée via les fichiers .env.
À noter également que désormais il y a une utilisation possible des hook_deploy.
J’étais auparavant retissant à leur usage, avec ma casquette de mainteneur de modules contrib, car ces hook sont non utilisables dans ce contexte et car non déclenchés si une mise à jour est effectuée via l’interface de Drupal. Mais bon les mises à jour sont toujours effectuées via Drush. Et finalement cela me faisait utiliser les hook_post_update à la place des hook_deploy, ce dont les premiers ne sont pas faits pour.
Documentation
Les changements sont documentés dans le dossier docs, peut être que la documentation est à réorganiser, je verrai à l’usage.
Pour le paramétrage PHPStorm, j’ai fait une version française sur le site.
Conclusion
Après 7 mois de lourdes modifications/améliorations, j’oublie certainement de mettre en avant certains changements.
Je me sers désormais de toutes ces nouveautés pour déployer mon site via Gitlab CI !
Après ce point étape, les prochaines étapes sont :
- de suivre des changements d’outils dans le noyau Drupal :
- continuer à ajouter des outils :
- rendre la partie Docker plus composable pour pouvoir gérer via les fichier .env les services présents ou non comme un Solr ou un Elasticsearch par exemple :
Après cela, je pense marquer à nouveau la progression avant de me lancer dans une réécriture des scripts pour éviter la duplication de code entre :
- les scripts pour l’administration de l’environnement local de ceux pour les environnements distants,
- les commandes Makefile et le fichier .gitlab-ci.yml.
Le shell c’est très puissant, mais ça a plein d’effet de bord et je commence à en faire une overdose. Les variables d’environnement c’est cool, mais pas tellement possible de gérer des listes et de la configuration imbriquée avec.
Remerciements
Merci à :
- Guillaume Aveline pour le support MacOS et retours d’utilisation.
- Inès Wallon pour les contributions et retours d’utilisation.
- Bastien Rigon pour les retours d’utilisation.
- Smile de m’avoir permis de passer du temps sur ce sujet.
Si j’ai oublié des contributeurs, n’hésitez pas à me le signaler.
Ajouter un commentaire