Comment connecter GitLab et Pantheon et optimiser les flux de travail Drupal et WordPress

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

В Panthéon Je travaille dans les relations avec les développeurs, je suis donc toujours à la recherche de nouvelles façons d'aider les développeurs WordPress et Drupal à résoudre les problèmes d'automatisation de leurs flux de travail. Pour ce faire, j'aime expérimenter de nouveaux outils et les combiner entre eux pour travailler efficacement.

Je vois souvent des développeurs aux prises avec un seul serveur intermédiaire.

C'est un tel plaisir d'attendre son tour pour utiliser un serveur intermédiaire ou envoyer aux clients une URL avec la note : « Regardez ici, mais ne regardez pas encore ici ».

Environnements multi-développements - l'un des outils sympas de Pantheon - résout ce problème, car avec eux, vous pouvez créer des environnements pour les branches Git à la demande. Chaque environnement multidev possède sa propre URL et sa propre base de données, afin que les développeurs puissent travailler tranquillement, vérifier la qualité et obtenir l'approbation sans se marcher sur les pieds.

Mais Pantheon ne dispose pas d'outils de contrôle de version ou d'intégration et de déploiement continus (CI/CD). Mais c'est une plateforme flexible avec laquelle vous pouvez intégrer n'importe quel outil.

J'ai également remarqué que les équipes utilisent certains outils pour le développement et différents pour l'assemblage et le déploiement.

Par exemple, ils disposent de différents outils pour le contrôle de version et le CI/CD. Vous devez bricoler et basculer entre les outils pour modifier le code et diagnostiquer les problèmes.

Sur gitlab ce il existe un ensemble complet d'outils de développement : pour le contrôle de version, les tickets, les demandes de fusion, le meilleur pipeline CI/CD de sa catégorie, un registre de conteneurs, et tout le reste. Je n'ai pas encore rencontré d'application offrant autant de fonctionnalités pour gérer votre flux de travail de développement.

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

Dans ce tutoriel, je vais vous expliquer comment établir une connexion entre GitLab et Pantheon et optimiser votre flux de travail WordPress et Drupal.

Bien sur, c'est possible, mettre en miroir le dépôt GitLab, mais nous ferons tout de nos mains pour approfondir CI GitLab et à l'avenir, utilisez cet outil non seulement pour le déploiement.

introduction

Pour cet article, vous devez comprendre que Pantheon décompose chaque site en trois éléments : le code, la base de données et les fichiers.

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

Créer un compte gratuit, en savoir plus sur Flux de travail du Panthéon ou inscrivez-vous pour une démo sur panthéon.io.

Hypothèses

Mon projet sur Pantheon et GitLab s'appelle pantheon-gitlab-blog-demo. Le nom du projet doit être unique. Ici, nous travaillerons avec un site WordPress. Vous pouvez prendre Drupal, mais vous devrez modifier certaines choses.

j'utiliserai Ligne de commande Gitet tu peux travailler dans interface graphique, si tu veux.

Créer un projet

Tout d'abord, créons Projet GitLab (nous y reviendrons plus tard).

Maintenant créer un site WordPress sur Panthéon. Ensuite, nous installons WordPress pour le tableau de bord du site.

Si vos mains ont envie de changer quelque chose, par exemple supprimer ou ajouter des plugins, soyez patient. Le site n'est pas encore connecté à GitLab et nous souhaitons que toutes les modifications de code passent par GitLab.

Une fois WordPress installé, revenez au tableau de bord du site Web Pantheon et changez le mode de développement en Git.

Validation initiale sur GitLab

Vous devez maintenant transférer le code WordPress initial du site Pantheon vers GitLab. Pour ce faire, nous clonons localement le code du référentiel Git du site Pantheon, puis l'envoyons au référentiel GitLab.

Pour rendre les choses plus faciles et plus sûres, ajouter une clé SSH à Panthéon et nous n'aurons pas besoin de saisir un mot de passe à chaque fois que nous clonerons un référentiel Pantheon Git. En même temps déjà ajouter une clé SSH à GitLab.

Pour ce faire, clonez le site Pantheon localement en copiant la commande du champ Cloner avec Git sur le tableau de bord du site.

Si vous avez besoin d'aide, lisez la documentation débuter avec Git pour Pantheon.

Maintenant changeons git remote originpour pointer vers GitLab au lieu de Panthéon. Ça peut être fait командой git remote.

Allons au projet GitLab et copions l'URL du référentiel à partir de la liste déroulante Clone sur la page de détails du projet. Choisissons l'option Cloner avec SSH, car nous avons déjà configuré la clé SSH.

Par défaut git remote pour une copie locale du référentiel de code - origin. Cela peut être modifié c git remote set-url origin [URL репозитория GitLab], où au lieu de crochets, nous saisissons l'URL réelle.

Enfin, nous lançons git push origin master --forcepour pousser le code WordPress de Pantheon vers GitLab.

L’option –force n’est nécessaire qu’une seule fois. Puis en équipes git push ce ne sera pas sur GitLab.

Configuration des informations d'identification et des variables

Rappelez-vous comment nous avons ajouté une clé SSH localement pour vous connecter à Pantheon et GitLab ? Le token SSH peut être utilisé pour autoriser GitLab et Pantheon.

GitLab possède une excellente documentation. Voyons 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 terminer les deux premières étapes : Créons une nouvelle paire de clés SSH localement avec ssh-keygen et ajoutons la clé privée en tant que variable au projet.

Ensuite, nous demanderons SSH_PRIVATE_KEY comme Variable d'environnement GitLab CI/CD dans les paramètres du projet.
Dans les troisième et quatrième étapes, nous créerons un fichier .gitlab-ci.yml avec un contenu comme celui-ci :

before_script:
  # See 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 validons pas encore le fichier .gitlab-ci.yml, alors vous devrez y ajouter autre chose.

Maintenant, nous effectuons la cinquième étape et ajoutez la clé publique que vous avez créée lors de la première étape aux services auxquels vous devez accéder dans l'environnement de construction.

Dans notre cas, nous souhaitons accéder à Panthéon depuis GitLab. Nous suivons les instructions du document Panthéon sur ajouter une clé SSH à Pantheon et effectuez cette étape.

N'oubliez pas : le SSH privé est dans GitLab, le SSH ouvert est dans Panthéon.

Configurons quelques variables d'environnement supplémentaires. Le premier s'appelle PANTHEON_SITE. Sa valeur est le nom du site Panthéon sur votre machine.

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

Ensuite, configurons la variable d'environnement PANTHEON_GIT_URL. Il s'agit de l'URL du référentiel Git du site Panthéon que nous avons déjà utilisé.

Saisissez uniquement l'URL du référentiel SSH, sans git clone et le nom du site sur la machine à la fin.

Phew. C'est fait, maintenant nous pouvons terminer notre dossier .gitlab-ci.yml.

Créer une tâche de déploiement

Ce que nous ferons initialement avec GitLab CI est très similaire à ce que nous avons fait avec les référentiels Git dans le passé. Mais cette fois, ajoutons le référentiel Pantheon comme deuxième source Git distante, puis transférons le code de GitLab vers Pantheon.

Pour ce faire, configurons étape deploy и tâche deploy:dev, car nous allons déployer dans l'environnement de développement sur Pantheon. Le fichier résultant .gitlab-ci.yml ressemblera à ceci:

stages:
- deploy

before_script:
  # See 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

Variables SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL devrait sembler familier - nous avons configuré ces variables d'environnement plus tôt. Avec ces variables nous pourrons utiliser les valeurs du fichier .gitlab-ci.yml plusieurs fois, et ils n’auront besoin d’être mis à jour qu’à un seul endroit.

Enfin, ajoutez, validez et envoyez le fichier .gitlab-ci.yml sur GitLab.

Vérification du déploiement

Si nous avons tout fait correctement, la tâche deploy:dev s'exécutera avec succès dans GitLab CI/CD et soumettra un commit .gitlab-ci.yml au Panthéon. Jetons un coup d'oeil.

Envoi de fils de discussion de demande de fusion à Pantheon

Ici, nous utiliserons ma fonctionnalité Panthéon préférée - multidév., où vous pouvez créer des environnements Pantheon supplémentaires pour les branches Git à la demande.

L'accès au multidev est limité, cette section peut donc être ignorée. Mais si vous y avez accès, vous pouvez sérieusement augmenter la productivité en configurant la création automatique d'environnements multidev sur Pantheon à partir des demandes de fusion GitLab.

Créons d’abord une nouvelle branche Git localement en utilisant git checkout -b multidev-support. Maintenant, changeons encore quelque chose dans .gitlab-ci.yml.

J'aime inclure le numéro de demande de fusion dans le nom de l'environnement Pantheon. Par exemple, la première demande de fusion est mr-1, deuxième - mr-2 etc.

La demande de fusion change, nous devons donc déterminer dynamiquement les noms des branches Panthéon. C'est simple sur GitLab - il vous suffit d'utiliser variables d'environnement prédéfinies.

Nous pouvons prendre $CI_MERGE_REQUEST_IIDpour spécifier le numéro de demande de fusion. Appliquons tout cela avec les variables d'environnement globales que nous avons spécifiées précédemment et ajoutons une nouvelle tâche déployer: multidev à la fin du fichier. .gitlab-ci.yml.

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # 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:mr-$CI_MERGE_REQUEST_IID --force
  only:
    - merge_requests

Ce sera similaire à notre tâche deploy:dev, seule la branche est envoyée au Panthéon, pas à master.

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

Créons maintenant une nouvelle demande de fusion à partir de la branche multidev-supporten appuyant Créer une demande de fusion.

Après avoir créé une demande de fusion, nous regardons comment la tâche CI/CD est exécutée deploy:multidev.

Écoutez, un nouveau fil de discussion a été envoyé au Panthéon. Mais si on va dans la section multidev du tableau de bord du site Pantheon, on n'y verra pas le nouvel environnement

Regardons la section Branches Git.

En conséquence, notre fil mr-1 Je suis arrivé au Panthéon. Créons un environnement à partir d'une branche mr-1.

Nous avons créé un environnement multidev, revenons maintenant à GitLab et regardons la section Opérations > Environnements. Nous verrons les entrées pour dev и mr-1.

C'est parce que nous avons ajouté une entrée environment Avec nom name и url dans les tâches CI/CD. Si nous cliquons sur l'icône de l'environnement ouvert, nous serons redirigés vers l'URL de l'environnement multidev sur Pantheon.

Automatisez la création de multidev

En principe, vous pouvez vous arrêter ici et penser simplement à 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ù vous pouvez travailler automatiquement avec la plateforme. Terminus vous permet de créer des environnements multidev à partir de la ligne de commande - idéal pour CI GitLab.

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

Pour utiliser Terminus dans les tâches GitLab CI/CD, vous avez besoin d'un jeton de machine pour l'authentification avec Terminus et d'une image de conteneur avec Terminus.

Créer un jeton de machine Panthéon, enregistrez-le dans un endroit sûr et ajoutez-le en tant que variable d'environnement globale dans GitLab avec le nom PANTHEON_MACHINE_TOKEN.

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

Création d'un fichier Docker avec Terminus

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

GitLab dispose d'un registre de conteneurs, où nous pouvons créer et placer le Dockerfile pour notre projet. Créons un Dockerfile avec Terminus pour travailler avec Pantheon.

Terminus est un outil de ligne de commande PHP, commençons donc par l'image PHP. J'installe Terminus via Composer, je vais donc utiliser Image officielle de Docker Composer. Nous créons Dockerfile dans le répertoire du référentiel local avec le contenu suivant :

# 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 d'assemblage et d'envoi des images de la section Créer et diffuser des images в documentation du registre de conteneurspour collecter une image de Dockerfile et transférez-le vers GitLab.

Ouverture de la rubrique Registre dans le projet GitLab. Si tout se passe comme prévu, notre image sera là. Écrivez un lien vers la balise d'image - nous en avons besoin pour le fichier .gitlab-ci.yml.

Section script dans le problème deploy:multidev commence à croître, alors déplaçons-le dans un fichier séparé. Créer 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 est dans un répertoire privé et ne permet pas l'accès Web au Panthéon. Nous avons un script pour notre logique multidev. Mettons maintenant à jour la section deploy:multidev dossier .gitlab-ci.ymlpour que cela donne 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:
    # Run the multidev deploy script
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Nous devons nous assurer que nos tâches sont effectuées dans l'image personnalisée créée, ajoutons donc une définition image de l'URL du registre à .gitlab-ci.yml. En conséquence, nous nous sommes retrouvés avec un fichier comme celui-ci .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # See 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:
    # Run the multidev deploy script
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Ajouter, valider et envoyer private/multidev-deploy.sh и .gitlab-ci.yml. Nous retournons maintenant à GitLab et attendons la fin de la tâche CI/CD. Soyez patient : la création d'un multidev peut prendre plusieurs minutes.

Ensuite, nous allons regarder la liste multidev sur Pantheon. Ô miracle ! Environnement multi-développement mr-2 Déjà là.

Conclusion

Mon équipe s'est beaucoup plus amusée lorsque nous avons commencé à ouvrir des demandes de fusion et à créer automatiquement des environnements.

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

Puisque nous utilisons GitLab CI/CD, notre flux de travail pourra se développer. Voici quelques idées pour vous aider à démarrer :

• Ajoutez une étape de construction.
• Ajoutez des tests automatisés.
• Ajoutez une tâche pour garantir que les normes du code sont respectées.
• Ajouter tests de sécurité des applications dynamiques.

Faites-moi savoir ce que vous pensez de GitLab, Pantheon et de l'automatisation.

PS Saviez-vous que Terminus, l'outil de ligne de commande de Pantheon, peut être étendu via des plugins?

Chez Pantheon, nous avons fait du bon travail sur la version 2 de notre plugin pour les outils de construction Terminus avec le support de GitLab. Si vous ne voulez pas vous soucier des paramètres de chaque projet, essayez ce plugin et aidez-nous à tester la version bêta v2. Pour l'équipe Terminus build:project:create Vous n'avez besoin que d'un jeton Panthéon et d'un jeton GitLab. Elle déploiera l'un des exemples de projets avec Composer et des tests automatisés, créera un nouveau projet dans GitLab, un nouveau site Pantheon, et les connectera à l'aide de variables d'environnement et de clés SSH.

À propos de l'auteur

Andrew Taylor crée des outils pour les développeurs Panthéon.

Source: habr.com