Comment connecter GitLab et Pantheon et optimiser les workflows Drupal et WordPress

Notre invité, créateur d'outils pour développeurs chez Pantheon, explique comment automatiser les déploiements WordPress à l'aide de GitLab CI/CD.

Dans Pantheon Je me consacre aux relations avec les développeurs, donc je cherche toujours de nouvelles façons d'aider les développeurs WordPress et Drupal à résoudre les problèmes d'automatisation dans leurs flux de travail. Pour cela, j'aime expérimenter avec de nouveaux outils et les combiner pour un travail efficace.

Je vois souvent des développeurs éprouver des difficultés avec un serveur intermédiaire.

Ce n'est pas agréable d'attendre son tour pour utiliser le serveur intermédiaire ou d'envoyer des URL aux clients avec la mention : « Regardez ici, mais pas là pour l'instant ».

Les environnements multidev — l'un des super outils de Pantheon — résolvent ce problème, car ils permettent de créer des environnements pour des branches Git à la demande. Chaque environnement multidev a sa propre URL et sa base de données, ce qui permet aux développeurs de travailler calmement, de vérifier la qualité et d'obtenir des approbations sans se gêner.

Mais Pantheon n'a pas d'outils pour le contrôle des versions ou l'intégration et le déploiement continus (CI/CD). Cependant, c'est une plateforme flexible qui peut intégrer n'importe quels outils.

J'ai également remarqué que pour le développement, les équipes utilisent différents outils, tandis que pour la construction et le déploiement, d'autres.

Par exemple, ils ont des outils différents pour le contrôle des versions et pour le CI/CD. Il faut jongler et passer d'un outil à l'autre pour modifier le code et diagnostiquer les problèmes.

Sur GitLab il existe un ensemble complet d'outils pour le développement : pour le contrôle des versions, les tickets, les demandes de fusion, un pipeline CI/CD de premier ordre, un registre de conteneurs et tout ce genre de choses. Je n'ai pas encore trouvé d'applications qui offrent autant d'options pour gérer un flux de travail de développement.

J'adore l'automatisation, donc j'ai étudié comment connecter Pantheon à GitLab, afin que les commits sur la branche principale de GitLab soient déployés dans l'environnement principal sur Pantheon. De plus, les demandes de fusion sur GitLab peuvent créer et déployer du code dans les environnements multidev sur Pantheon.

Dans ce guide, je vais expliquer comment établir la connexion entre GitLab et Pantheon et optimiser le flux de travail WordPress et Drupal.

On peut, bien sûr, miroiter le dépôt GitLab, mais nous allons tout faire manuellement pour examiner le GitLab CI et à l'avenir utiliser cet outil non seulement pour le déploiement.

Introduction

Pour ce post, il faut comprendre que Pantheon divise chaque site en trois éléments : le code, la base de données et les fichiers.

Le code comprend les fichiers CMS, tels que le noyau, les plugins et les thèmes WordPress. Ces fichiers sont gérés dans un dépôt Git, hébergé par Pantheon, ce qui signifie que nous pouvons déployer le code de GitLab vers Pantheon avec Git.
Les fichiers dans Pantheon sont des fichiers multimédias, c'est-à-dire des images pour le site. Ils sont généralement téléchargés par les utilisateurs, et Git les ignore.

Créez un compte gratuit, découvrez-en plus sur le flux de travail de Pantheon ou inscrivez-vous pour une démo sur pantheon.io.

Hypothèses

Mon projet sur Pantheon et GitLab s'appelle pantheon-gitlab-blog-demo. Le nom du projet doit être unique. Ici, nous allons travailler avec un site WordPress. On pourrait aussi utiliser Drupal, mais il faudrait modifier certaines choses.

Je vais utiliser la ligne de commande Git, et vous pouvez travailler dans une interface graphique, si vous le souhaitez.

Créons un projet

Pour commencer, créons un projet GitLab (nous y reviendrons).

Maintenant Créons un site WordPress sur Pantheon. Ensuite, installons WordPress pour le tableau de bord du site.

Si vous avez envie de modifier quelque chose, par exemple supprimer ou ajouter des plugins, attendez. Le site n'est pas encore connecté à GitLab, et nous voulons que tous les changements de code passent par GitLab.

Une fois WordPress installé, retournons sur le tableau de bord du site Pantheon et changeons le mode de développement en Git.

Le premier commit sur GitLab

Maintenant, il faut transférer le code initial de WordPress du site Pantheon vers GitLab. Pour cela, clonons le code depuis le dépôt Git du site Pantheon localement, puis envoyons-le vers le dépôt GitLab.

Pour que ce soit plus simple et sécurisé, ajoutons une clé SSH dans Pantheon et n'ayons pas à saisir le mot de passe chaque fois que nous clonons le dépôt Git de Pantheon. Par la même occasion, ajoutons déjà la clé SSH sur GitLab..

Pour cela, clonons le site Pantheon localement en copiant la commande depuis le champ Cloner avec Git sur le tableau de bord du site.

Si vous avez besoin d'aide, consultez la documentation pour commencer à travailler avec Git pour Pantheon..

Maintenant, modifions git remote origin, pour indiquer GitLab au lieu de Pantheon. Cela peut se faire avec la commande git remote..

Passons au projet GitLab et copions l'URL du dépôt depuis la liste déroulante Cloner sur la page des détails du projet. Choisissons l'option Cloner avec SSH, puisque nous avons déjà configuré la clé SSH.

Par défaut git remote pour la copie locale du dépôt de code est origin.Cela peut être changé avec git remote set-url origin [URL du dépôt GitLab],où vous entrez l'URL réelle à la place des crochets.

Enfin, exécutons git push origin master --force, pour envoyer le code WordPress depuis le site Pantheon vers GitLab.

Le paramètre –force n'est nécessaire qu'une seule fois. Ensuite, dans les commandes git push il ne sera pas dans GitLab.

Configurons les informations d'identification et les variables

Vous vous souvenez comment nous avons ajouté localement une clé SSH pour nous authentifier auprès de Pantheon et GitLab ? Un jeton SSH peut être utilisé pour l'authentification de GitLab et Pantheon.

GitLab dispose d'une excellente documentation. Regroupons-nous sur la section sur les clés SSH lors de l'utilisation de l'exécuteur Docker dans le document sur l'utilisation des clés SSH avec GitLab CI/CD.

Nous allons maintenant effectuer les deux premières étapes : créer une nouvelle paire de clés SSH localement avec ssh-keygen et ajouter la clé privée comme variable dans le projet.

Ensuite, nous définirons SSH_PRIVATE_KEY comment la variable d'environnement GitLab CI/CD dans les paramètres du projet.
Lors des troisième et quatrième étapes, nous créerons un fichier .gitlab-ci.yml avec ce contenu :

before_script:
  # Voir https://docs.gitlab.com/ee/ci/ssh_keys/README.html
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
  - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "Gitlab CI"

Ne commençons pas encore à valider le fichier .gitlab-ci.yml, il faudra encore y ajouter quelque chose.

Nous réalisons maintenant la cinquième étape et ajoutons la clé publique créée à l'étape précédente aux services auxquels vous souhaitez accéder dans l'environnement de construction.

Dans notre cas, nous souhaitons accéder à Pantheon depuis GitLab. Suivons les instructions du document Pantheon sur l'ajout de la clé SSH dans Pantheon et effectuons cette étape.

Rappelons-nous : la clé SSH privée est dans GitLab, la clé publique est dans Pantheon.

Configurons quelques variables d'environnement supplémentaires. La première s'appelle PANTHEON_SITE. Sa valeur est le nom du site Pantheon sur votre machine.

Le nom sur la machine est indiqué à la fin de la commande Cloner avec Git. Vous avez déjà cloné le site localement, donc ce sera le nom du répertoire du dépôt local.

Ensuite, configurons la variable d'environnement PANTHEON_GIT_URL. C'est l'URL du dépôt Git pour le site Pantheon, que nous avons déjà utilisée.

Nous entrons uniquement l'URL SSH du dépôt, sans git clone et le nom du site sur la machine à la fin.

Ouf. C'est fait, maintenant nous pouvons terminer notre fichier .gitlab-ci.yml.

Créons une tâche de déploiement

Ce que nous allons faire au départ avec GitLab CI ressemble beaucoup à ce que nous avons fait auparavant avec les dépôts Git. Mais cette fois, nous ajouterons le dépôt Pantheon comme deuxième source distante Git, puis nous enverrons le code de GitLab vers Pantheon.

Pour cela, nous configurerons l'étape deploy et la tâche deploy:dev, puisque nous allons déployer dans l'environnement de développement sur Pantheon. En conséquence, le fichier .gitlab-ci.yml ressemblant à ceci :

étapes:
- déployer

avant_script:
  # Voir https://docs.gitlab.com/ee/ci/ssh_keys/README.html
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
  - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "Gitlab CI"

déployer:dev:
  étape: déployer
  environnement:
    nom: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  script:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  seulement:
    - master

Variables SSH_PRIVATE_KEY, PANTHEON_SITE et PANTHEON_GIT_URL devraient sembler familiers — nous avons configuré ces variables d'environnement précédemment. Avec ces variables, nous pourrons utiliser les valeurs dans le fichier .gitlab-ci.yml plusieurs fois, et les mettre à jour ne sera nécessaire qu'à un seul endroit.

Enfin, ajoutons, validons et envoyons le fichier .gitlab-ci.yml sur GitLab.

Vérifions le déploiement

Si nous avons tout bien fait, la tâche deploy:dev s'exécutera avec succès dans GitLab CI/CD et enverra le commit .gitlab-ci.yml vers Pantheon. Voyons cela.

Nous envoyons les branches des merge requests vers Pantheon

Ici, nous allons utiliser ma fonctionnalité préférée de Pantheon — multidev, où il est possible de créer des environnements Pantheon supplémentaires pour les branches Git à la demande.

L'accès à multidev est limité, donc cette section peut ne pas être réalisée. Mais si vous y avez accès, vous pouvez considérablement améliorer les performances en configurant la création automatique d'environnements multidev sur Pantheon à partir des merge requests GitLab.

D'abord, créons une nouvelle branche Git localement avec git checkout -b multidev-support. Maintenant, modifions à nouveau quelque chose dans .gitlab-ci.yml.

J'aime inclure le numéro de la merge request dans le nom de l'environnement Pantheon. Par exemple, la première merge request — mr-1, la deuxième — mr-2 et cetera.

La merge request change, donc nous devons déterminer dynamiquement les noms des branches Pantheon. Dans GitLab, c'est facile — nous pouvons utiliser des variables d'environnement prédéfinies..

Nous pouvons prendre $CI_MERGE_REQUEST_IID, pour spécifier le numéro de la merge request. Regroupons tout cela avec les variables d'environnement globales que nous avons mentionnées précédemment, et ajoutons une nouvelle tâche deploy:multidev à la fin du fichier. .gitlab-ci.yml.

déployer:multidev:
  étape: déployer
  environnement:
    nom: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Récupérer la branche source de la merge request
    - git checkout $CI_COMMIT_REF_NAME
    # Ajouter le dépôt git Pantheon comme un remote supplémentaire
    - git remote add pantheon $PANTHEON_GIT_URL
    # Pousser la branche source de la merge request vers Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  seulement:
    - merge_requests

Cela ressemblera à notre tâche deploy:dev, sauf que la branche est envoyée vers Pantheon, et non vers master.

Nous avons ajouté et validé le fichier mis à jour .gitlab-ci.yml, et maintenant, envoyons la nouvelle branche vers GitLab avec git push -u origin multidev-support.

Maintenant, créons une nouvelle demande de fusion depuis la branche multidev-support, en appuyant sur Créer une demande de fusion.

Après avoir créé la demande de fusion, voyons comment la tâche CI/CD s'exécute deploy:multidev.

Regardez — une nouvelle branche a été envoyée à Pantheon. Mais si nous allons dans la section multidev sur le tableau de bord du site Pantheon, nous ne verrons pas là le nouvel environnement

Jetons un œil à la section Git Branches.

Finalement, notre branche mr-1 a atteint Pantheon. Créons un environnement à partir de la branche mr-1.

Nous avons créé l'environnement multidev, maintenant retournons dans GitLab et jetons un œil à la section Operations > Environments. Nous verrons des enregistrements pour dev et mr-1.

C'est parce que nous avons ajouté un enregistrement environment avec le nom nom et url dans les tâches CI/CD. Si nous cliquons sur l'icône d'environnement ouvert, nous passerons à l'URL de l'environnement multidev sur Pantheon.

Automatisons la création de multidev

En fait, nous pourrions nous arrêter ici et simplement ne pas oublier de créer un environnement multidev pour chaque demande de fusion, mais ce processus peut être automatisé.

Pantheon dispose d'un outil en ligne de commande Terminus, où nous pouvons travailler avec la plateforme de manière automatique. Dans Terminus, nous pouvons créer des environnements multidev directement depuis la ligne de commande — idéal pour GitLab CI.

Nous avons besoin d'une nouvelle demande de fusion pour tester cela. Créons une nouvelle branche avec git checkout -b auto-multidev-creation.

Pour utiliser Terminus dans les tâches GitLab CI/CD, un jeton de machine est nécessaire pour s'authentifier auprès de Terminus et une image de conteneur avec Terminus.

Créons un jeton de machine Pantheon, gardez-le en lieu sûr et ajoutez-le comme variable d'environnement globale dans GitLab avec le nom PANTHEON_MACHINE_TOKEN.

Si vous avez oublié comment ajouter des variables d'environnement dans GitLab, revenez à l'endroit où nous avons défini PANTHEON_SITE.

Créons un Dockerfile avec Terminus

Si vous n'utilisez pas Docker ou que vous n'aimez pas trop les fichiers Dockerfile, prenez mon image registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest et passez cette section.

GitLab dispose d'un registre de conteneurs, où vous pouvez assembler et héberger un Dockerfile pour notre projet. Créons un fichier Dockerfile avec Terminus pour travailler avec Pantheon.

Terminus est un outil en ligne de commande basé sur PHP, donc commençons par une image PHP. J'installe Terminus via Composer, donc je vais prendre l'image officielle Docker Composer. Nous créons Dockerfile dans le répertoire local du dépôt avec ce contenu :

# Use the official Composer image as a parent image
FROM composer:1.8

# Update/upgrade apk
RUN apk update
RUN apk upgrade

# Make the Terminus directory
RUN mkdir -p /usr/local/share/terminus

# Install Terminus 2.x with Composer
RUN /usr/bin/env COMPOSER_BIN_DIR=/usr/local/bin composer -n --working-dir=/usr/local/share/terminus require pantheon-systems/terminus:"^2"

Suivez les instructions pour construire et pousser les images à partir de la section Build and push images dans de la documentation du registre de conteneurs, pour construire l'image à partir de Dockerfile et l'envoyer dans GitLab.

Ouvrons la section Registry dans le projet GitLab. Si tout s'est bien passé, notre image y sera. Notez le lien vers le tag de l'image — il est nécessaire pour le fichier .gitlab-ci.yml.

Section script dans la tâche deploy:multidev commence à se développer, alors déplaçons-le dans un fichier distinct. Créons un nouveau fichier private/multidev-deploy.sh:

#!/bin/bash

# Store the mr- environment name
export PANTHEON_ENV=mr-$CI_MERGE_REQUEST_IID

# Authenticate with Terminus
terminus auth:login --machine-token=$PANTHEON_MACHINE_TOKEN

# Checkout the merge request source branch
git checkout $CI_COMMIT_REF_NAME

# Add the Pantheon Git repository as an additional remote
git remote add pantheon $PANTHEON_GIT_URL

# Push the merge request source branch to Pantheon
git push pantheon $CI_COMMIT_REF_NAME:$PANTHEON_ENV --force

# Create a function for determining if a multidev exists
TERMINUS_DOES_MULTIDEV_EXIST()
{
    # Stash a list of Pantheon multidev environments
    PANTHEON_MULTIDEV_LIST="$(terminus multidev:list ${PANTHEON_SITE} --format=list --field=id)"

    while read -r multiDev; do
        if [[ "${multiDev}" == "$1" ]]
        then
            return 0;
        fi
    done <<< "$PANTHEON_MULTIDEV_LIST"

    return 1;
}

# If the mutltidev doesn't exist
if ! TERMINUS_DOES_MULTIDEV_EXIST $PANTHEON_ENV
then
    # Create it with Terminus
    echo "No multidev for $PANTHEON_ENV found, creating one..."
    terminus multidev:create $PANTHEON_SITE.dev $PANTHEON_ENV
else
    echo "The multidev $PANTHEON_ENV already exists, skipping creating it..."
fi

Le script se trouve dans un répertoire privé et n'offre pas d'accès web sur Pantheon. Nous avons un script pour notre logique multidev. Mettons maintenant à jour la section deploy:multidev fichiers .gitlab-ci.yml, pour que cela ressemble à ceci :

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Exécutez le script de déploiement multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Nous devons nous assurer que nos tâches s'exécutent dans l'image personnalisée créée, alors ajoutons la définition image avec l'URL du registre dans .gitlab-ci.yml. Au final, nous avons obtenu ce fichier .gitlab-ci.yml:

image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest

stages:
- deploy

before_script:
  # Voir https://docs.gitlab.com/ee/ci/ssh_keys/README.html
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add > /dev/null
  - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "Gitlab CI"

deploy:dev:
  stage: deploy
  environment:
    name: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  script:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  only:
    - master

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Exécutez le script de déploiement multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Ajoutons, engageons et envoyons private/multidev-deploy.sh et .gitlab-ci.yml. Maintenant, retournons sur GitLab et attendons que la tâche CI/CD soit exécutée. Patientez : le multidev peut se créer pendant plusieurs minutes.

Ensuite, allons consulter la liste des multidev sur Pantheon. Oh miracle ! L'environnement multidev mr-2 est déjà là.

Conclusion

Mon équipe a trouvé beaucoup plus de plaisir lorsque nous avons commencé à ouvrir des demandes de fusion et à créer des environnements de manière automatique.

Avec les puissants outils de GitLab et Pantheon, vous pouvez connecter GitLab à Pantheon automatiquement.

Puisque nous utilisons GitLab CI/CD, notre flux de travail a encore beaucoup de potentiel pour se développer. Voici quelques idées pour commencer :

• Ajoutez une étape de construction.
• Ajoutez des tests automatisés.
• Ajoutez une tâche pour garantir le respect des normes de code.
• Ajoutez un test de sécurité des applications dynamique.

Dites-nous ce que vous pensez de GitLab, Pantheon et de l'automatisation.

P.S. Saviez-vous que Terminus, l'outil en ligne de commande de Pantheon, peut être étendu par des plugins?

Nous avons travaillé dur chez Pantheon sur la version 2 de notre plugin pour les outils de construction Terminus avec le support de GitLab. Si vous ne souhaitez pas vous occuper de la configuration pour chaque projet, essayez ce plugin et aidez-nous à tester la bêta v2. Pour l'équipe Terminus build:project:create il suffit d'un jeton Pantheon et d'un jeton GitLab. Cela déploiera l'un des exemples de projet avec Composer et des tests automatisés, créera un nouveau projet dans GitLab, un nouveau site Pantheon et les liera via des variables d'environnement et des clés SSH.

À propos de l'auteur

Andrew Taylor crée des outils pour les développeurs chez Pantheon.

Source : habr.com