Utiliser Laravel avec les pipelines GitLab
jigadmin

Comme mentionné dans un article précédent, Laravel is a popular PHP development platform that is well known for its clean design and the active user community. Gitlab is one of the most popular source code repository and collaborative software development platforms.   This article outlines how to use Gitlab’s pipelines with Laravel projects.

Vous devrez d’abord déclarer les principales étapes du processus des pipelines telles que : Build, Test et Deploy.

Construire (préparation et configuration)

The instructions below assume that you have docker installed and understand how it works with Gitlab.  If you are unsure, take a look at our blog on configuration du menu fixe.

Les étapes de préparation et de configuration sont :

Configurer une image de conteneur Docker

GitLab CI/CD (https://docs.gitlab.com/ee/ci/) permet d'utiliser Docker (https://www.docker.com/) pour gérer le processus de test et de déploiement d'une application. Vous devrez donc récupérer une image Docker de base pour l'utiliser ou en créer une.Il existe de nombreuses images Docker disponibles pour les applications PHP/Laravel.Par exemple, l'image officielle PHP Docker (https://hub.docker.com/_/php).

Une fois qu'un conteneur est créé et qu'un Dockerfile est placé dans le répertoire racine de votre application, vous devrez configurer le registre de conteneurs GitLab, créer une image et la placer là pour une utilisation ultérieure.

Pour configurer Container Registry sur le référentiel de votre projet GitLab, accédez à l'onglet Registre ou si vous ne le trouvez pas, vous devrez peut-être l'activer pour votre projet dans Paramètres > Paramètres de votre projet.Général >Visibilité, fonctionnalités du projet, autorisations.

 

Vous devrez d’abord vous connecter au registre GitLab en utilisant votre nom d’utilisateur et votre mot de passe GitLab.Étant donné que Docker est installé sur notre machine, vous devrez exécuter les commandes suivantes :

connexion docker registre.gitlab.com

Ensuite, vous pouvez créer et transférer votre image vers GitLab :

docker build -t registre.gitlab.com/<USERNAME>/<IMAGE_NAME>.

docker push registre.gitlab.com/<USERNAME>/<IMAGE_NAME>

Now you can use this image in order to build and test your application with GitLab CI/CD which requires a file called .gitlab-ci.yml created in the  repository’s root starting with the following commands to use the image previously registered:

image: registry.gitlab.com/<USERNAME>/<IMAGE_NAME>:latest

Ajoutez des services supplémentaires à votre pipeline GitLab.

L'approche consistant à ajouter plusieurs services à votre pipeline GitLab dépend des besoins spécifiques de votre projet, ainsi que du mot-clé services et de Docker Compose (https://docs.docker.com/compose/) ont leurs propres avantages.

Le mot-clé services est une approche plus simple qui vous permet d'ajouter facilement un nombre limité de services à votre pipeline GitLab.Cela convient lorsque vous n'avez besoin que de quelques services simples, comme une base de données ou un serveur de cache, et que vous n'avez pas besoin de les gérer de manière plus complexe.Le mot-clé services est également une fonctionnalité intégrée de GitLab et ne nécessite pas l'installation d'outils supplémentaires ni l'écriture de fichiers de configuration supplémentaires.

D'un autre côté, docker-compose offre plus de flexibilité et de fonctionnalités dans la gestion de plusieurs services.Il vous permet de définir des configurations de service complexes, telles que plusieurs versions d'un service, des réseaux, des volumes et des dépendances.De plus, vous pouvez facilement gérer vos services à l'aide des commandes docker-compose, ce qui peut simplifier la configuration de votre pipeline.

Dans l’ensemble, si vous disposez d’une architecture d’application plus complexe et devez gérer plusieurs services, utiliser docker-compose serait une meilleure approche.Cependant, si vous n’avez besoin d’utiliser que quelques services simples et que vous souhaitez une solution simple et rapide, le mot-clé services est une option appropriée.Il est important de choisir l’approche qui correspond le mieux aux besoins de votre projet.

Voici un exemple de la façon d'ajouter un service MySQL à un pipeline GitLab CI/CD pour une application Laravel à l'aide du mot-clé services :

services:

  - mysql : dernier

variables :

  MYSQL_DATABASE : ma_app_db

  MYSQL_ROOT_PASSWORD : exemple

  DB_HOST : mysql

  DB_USERNAME : racine

  DB_PASSWORD : exemple

Dans cet exemple, nous utilisons le mot-clé services pour spécifier l'image MySQL Docker qui sera démarrée à côté de l'image principale.

Ensuite, nous définissons certaines variables d'environnement utilisées pour configurer notre application Laravel pour se connecter au service MySQL.Nous définissons la variable MYSQL_DATABASE sur le nom de la base de données que nous souhaitons créer et MYSQL_ROOT_PASSWORD sur le mot de passe que nous souhaitons définir pour l'utilisateur root.Nous définissons également les variables DB_HOST, DB_USERNAME et DB_PASSWORD pour configurer la connexion à la base de données de Laravel.

Installez les dépendances de l'application (packages requis par Laravel Framework) :

Pour installer les dépendances requises par le framework Laravel dans le pipeline GitLab, vous pouvez utiliser le gestionnaire de packages composer.Voici un exemple :

scénario:

- apt-get update &&apt-get install -y git décompresser

- curl -sS https://getcomposer.org/installer |php -- --install-dir=/usr/local/bin --filename=composer

- compositeur install --prefer-dist --no-ansi --no-interaction --no-progress

Dans cet exemple, nous installons d’abord certaines dépendances nécessaires à l’exécution de Composer.Nous téléchargeons et installons ensuite le compositeur lui-même.Enfin, nous exécutons composer install pour installer les dépendances requises par Laravel, en utilisant quelques indicateurs supplémentaires pour améliorer les performances de l'installation.

Configurez l'environnement d'application Laravel et générez une clé d'environnement :

Pour transmettre les informations d'identification de la base de données au fichier .env d'une application Laravel dans un pipeline GitLab, vous pouvez utiliser les variables CI/CD de GitLab mentionnées ci-dessus pour stocker les informations sensibles, puis les utiliser dans le script du pipeline pour mettre à jour le fichier .env avec les informations d'identification correctes.

Voici un exemple de la façon dont vous pourriez procéder :

Dans les paramètres de votre projet GitLab, accédez à « CI/CD » ;et « Variables ».Ici, vous pouvez ajouter des variables pour vos informations d'identification de base de données, telles que DB_HOST, DB_DATABASE, DB_USERNAME et DB_PASSWORD.

Dans votre fichier .gitlab-ci.yml, ajoutez une tâche pour mettre à jour le fichier .env avec les informations d'identification de la base de données.Voici un exemple :

construire:

étape : construire

scénario:

    - cp .env.exemple .env

    - Clé artisanale php : générer

    - sed -i "s/DB_HOST=.*/DB_HOST=${DB_HOST}/" .env

    - sed -i "s/DB_DATABASE=.*/DB_DATABASE=${DB_DATABASE}/" .env

    - sed -i "s/DB_USERNAME=.*/DB_USERNAME=${DB_USERNAME}/" .env

- sed -i "s/DB_PASSWORD=.*/DB_PASSWORD=${DB_PASSWORD}/" .env

Dans cet exemple, nous définissons nos informations d'identification de base de données en tant que variables CI/CD.Dans la tâche de build, nous copions le fichier .env.example pour créer un nouveau fichier .env, générons une nouvelle clé d'application, puis utilisons sed pour mettre à jour les informations d'identification de la base de données dans le fichier .env.

Notez que les commandes sed de l'exemple remplacent toute la ligne commençant par DB_HOST=, DB_DATABASE=, DB_USERNAME= ou DB_PASSWORD= par la valeur correspondante des variables CI/CD.Si votre fichier .env a un format différent, vous devrez peut-être ajuster les commandes sed en conséquence.

Configurez la base de données et exécutez les migrations :

Dans un pipeline GitLab, il est recommandé de créer la base de données et d'exécuter des migrations avant d'exécuter les tests et de déployer l'application.Cela garantit que le schéma de base de données est à jour avec la base de code et que les tests sont exécutés sur le dernier schéma de base de données.

Les étapes impliquées dans la création de la base de données et l'exécution des migrations peuvent varier en fonction des exigences spécifiques de votre application et des outils que vous utilisez.Cependant, cela implique généralement d'exécuter les commandes suivantes dans votre pipeline :

  1. Créez la base de données (si elle n'existe pas déjà) :

mysql -u<DB_USERNAME>-p<DB_PASSWORD>-e "CRÉER UNE BASE DE DONNÉES <DB_NAME>"

Remarque : Remplacez <DB_USERNAME>, <DB_PASSWORD> et <DB_NAME>avec les valeurs appropriées pour votre base de données.

2) Exécutez les migrations :

php artisan migrer --force

Vous pouvez ajouter ces commandes à la section before_script de votre pipeline, afin qu'elles soient exécutées avant toute autre commande du pipeline.

Configurer le cache et les artefacts GitLab (https://docs.gitlab.com/ee/ci/caching/#cache-vs-artifacts).

GitLab fournit un mécanisme de mise en cache qui peut être utilisé pour accélérer votre pipeline en mettant en cache les fichiers et les dépendances entre les exécutions du pipeline.Vous pouvez également utiliser des artefacts pour transmettre des données entre les tâches du pipeline.Par exemple:

cache :

chemins :

    - fournisseur

Dans cet exemple, nous ajoutons le répertoire du fournisseur à la section chemins de la configuration du cache.Cela mettra en cache le répertoire des fournisseurs entre les exécutions du pipeline.

Dans le travail de build, nous exécutons les mêmes étapes de build qu'avant, mais nous n'installons pas de dépendances à l'aide de composer car nous pouvons utiliser le répertoire du fournisseur mis en cache.

En mettant en cache le répertoire des fournisseurs, vous pouvez accélérer considérablement votre pipeline et éviter d'avoir à réinstaller les dépendances à chaque exécution de pipeline.

Un pipeline GitLab exécute plusieurs tâches, étape par étape, à l'aide de code automatisé.Un pipeline d'intégration continue implique de créer quelque chose à partir de zéro et de le tester dans un environnement de développement.

Test (syntaxe et contrôles de sécurité)

One of the advantages of using a pipeline is the ability to run a series of tests before code is deployed to the main codeline.  Examples include tests for things like unit code functionality, syntax and security.

Il existe de nombreux vérificateurs de syntaxe, parmi ceux que nous apprécions :

Vous pouvez l'installer à l'aide de Composer et il contient un fichier de configuration .php_cs que vous pouvez valider dans votre référentiel.Exécutez php-cs-fixer fix pour vérifier et résoudre tous les problèmes dans votre référentiel.

Laravel Framework utilise StyleCI pour vérifier automatiquement les problèmes de style de code sur les nouveaux commits et demandes d'extraction.Il peut vous avertir lorsqu'il détecte des problèmes, envoyer automatiquement des correctifs via des demandes d'extraction et valider automatiquement les correctifs.Cependant, il n'est gratuit que pour les projets open source.

PHP Code sniffer (phpcs) est un vérificateur de style livré avec divers styles PHP populaires tels que PEAR, PSR2, etc. Il peut vérifier l'indentation, les commentaires manquants, les conventions de dénomination, etc. et inclut également phpcbf, un programme qui peut résoudre automatiquement certains problèmes.

Détecteur de désordre PHP (phpmd) vérifie les odeurs de code : code gênant, trop compliqué ou inutilisé et est livré avec plusieurs règles intégrées qui peuvent être activées ou désactivées.

Pour illustrer un exemple de configuration d'un vérificateur de syntaxe dans le pipeline, utiliserons-nous PHP-CS-Fixer :

php-cs- :

étape : test

dépendances :

- compositeur

scénario:

    - ./vendor/bin/php-cs-fixer fix --config=.php_cs.php --verbose --diff --dry-run

There are also many examples of security checkers available.  Some of the ones we like are:

Il s'agit d'un outil de ligne de commande basé sur Go qui vérifie si votre application PHP dépend de packages PHP présentant des vulnérabilités de sécurité connues.Publié par Fabien Potencier (fabpot) fondateur du projet Symfony.Il utilise la base de données des avis de sécurité en coulisses (https://github.com/FriendsOfPHP/security-advisories).Ce répertoire est mis à jour quotidiennement avec les derniers CVE et constitue un excellent point de départ pour commencer à vérifier.

Cet analyseur est un wrapper autour de phpcs-security-audit, un ensemble de règles PHP CodeSniffer qui détecte les vulnérabilités et les faiblesses liées à la sécurité dans le code PHP.

To illustrate an example of how to setup a security checker in the pipeline we will use Fabpot’s local-php-security-checker.  This can be integrated into your container and run within your CI environment using the following steps:

# Sorties https://github.com/fabpot/local-php-security-checker/releases

URL ARG="https://github.com/fabpot/local-php-security-checker/releases/download/v2.0.6/local-php-security-checker_2.0.6_linux_amd64"

EXÉCUTER apk ajouter --no-cache wget

EXÉCUTER wget -O local-php-security-checker $URL

EXÉCUTER chmod +x ./local-php-security-checker

EXÉCUTER mv ./local-php-security-checker /usr/local/bin/

scénario:

    - local-php-security-checker

Test (Tests unitaires)

Unit Testing is the process of checking small pieces of code to speed your testing strategies.  These unit tests are automated to reduce time for overall testing and improve the reliability of the system.  As code is added to new systems it’s possible to break previously created tasks.  Adding these unit tests to the build process allows programmers to catch errors before they make it into the main codeline.

Des exemples de frameworks de tests unitaires sont :

PHPStan est un outil d'analyse statique PHP qui se concentre sur la recherche d'erreurs dans votre code sans réellement l'exécuter.Il détecte des classes entières de bogues avant même que vous écriviez des tests pour le code.

PHPUnit est un framework de tests unitaires pour le langage de programmation PHP.Laravel utilise PHPUnit pour les tests par défaut.

Nous utiliserons à la fois Larastan (un wrapper PHPStan pour Laravel – https://github.com/nunomaduro/larastan) pour effectuer une analyse statique sur les projets et PHPUnit pour exécuter les tests unitaires :

unité php :

étape : test

scénario:

- phpunit --coverage-text –colors=jamais

- vendeur/bin/phpstan

Déployer (Déploiement)

Le déploiement a lieu lorsque le code est transmis à la codéine principale et envoyé à un serveur intermédiaire ou de production.Pour des raisons de commodité, nous ne travaillerons pour l’instant qu’avec la tâche de préparation, car elle sera très similaire à la tâche de production.

Tout d’abord, nous devrons initialiser une connexion SSH en procédant comme suit :

  • Créez une nouvelle paire de clés SSH localement sur notre machine.
  • Donnez la clé publique à notre serveur.
  • Donnez la clé privée à GitLab en utilisant des variables secrètes.
  • Utilisez cette clé privée dans nos pipelines.

Une fois cela fait, nous pouvons déployer l’application sur l’hôte intermédiaire.

Il existe quelques outils de déploiement disponibles pour gérer le processus :

Laravel Envoy est un outil permettant d'exécuter les tâches courantes que vous exécutez sur vos serveurs distants.Grâce à la syntaxe de style Blade, vous pouvez facilement configurer des tâches de déploiement, des commandes Artisan, etc.

Deployer est un package PHP qui fournit un provisionnement automatique du serveur, des déploiements sans temps d'arrêt, un retour à une version précédente et des recettes prêtes à l'emploi pour les principaux frameworks et certaines applications PHP.

Nous utiliserons Deployer :

Tout d’abord, nous devons installer Deployer :

composer nécessite un déployeur/déployeur : ^ 7.0

Ensuite, nous initialiserons Deployer et choisirons la recette du projet Laravel qui générera automatiquement un fichier de configuration déployer.yaml ou déployer.php :

initialisation du dépôt

Vous pouvez maintenant parcourir le fichier de déploiement et modifier tous les paramètres nécessaires à la configuration de votre application.

Nous avons déjà installé Deployer, installé les certificats SSL sur le serveur intermédiaire et créé le script de déploiement. Il est donc temps de tout rassembler et d'effectuer le premier déploiement sur le serveur intermédiaire :

Déploiement Dép.

Vous devriez voir une nouvelle structure de dossiers dans votre hôte, où se trouve le dossier des versions.Deployer synchronise votre code avec votre serveur, exécute vos tâches, puis crée un lien symbolique qui relie la version actuelle à la version activée.

En cas de problème, vous pouvez toujours revenir à la version précédemment déployée :

restauration du dépôt