Hoe GitLab en Pantheon te verbinden en de workflows van Drupal en WordPress te optimaliseren

Onze gast, de maker van ontwikkeltools bij Pantheon, legt uit hoe je WordPress-deploys kunt automatiseren met GitLab CI/CD.

In Pantheon Ik houd me bezig met ontwikkelaarsrelaties, dus ben altijd op zoek naar nieuwe manieren om WordPress- en Drupal-ontwikkelaars te helpen bij hun automatiseringsproblemen in werkprocessen. Daarom experimenteer ik graag met nieuwe tools en combineer ik deze voor efficiënter werken.

Ik zie vaak dat ontwikkelaars worstelen met één staging server.

Het is geen pretje om te wachten op je beurt om de staging server te gebruiken of om klanten een URL te sturen met het label: 'Hier kijken, en hier voorlopig niet.'

Multidev-omgevingen — een van de coole tools van Pantheon — lossen dit probleem op, want ze laten je op aanvraag omgevingen voor Git-takken creëren. Elke multidev-omgeving heeft zijn eigen URL en database, zodat ontwikkelaars rustig kunnen werken, de kwaliteit kunnen controleren en goedkeuring kunnen krijgen zonder elkaar voor de voeten te lopen.

Maar Pantheon heeft geen tools voor versiebeheer of continue integratie en deployment (CI/CD). Het is echter een flexibele platform die kan integreren met allerlei tools.

Ik heb ook opgemerkt dat teams voor ontwikkeling andere tools gebruiken dan voor bouwen en deployen.

Bijvoorbeeld, ze hebben verschillende tools voor versiebeheer en CI/CD. Je moet schakelen tussen tools om code te bewerken en problemen te diagnosticeren.

Op GitLab er is een volledige set ontwikkeltools: voor versiebeheer, tickets, merge requests, een toonaangevende CI/CD-pijplijn, containerregistratie en dat soort zaken. Ik ben nog geen applicaties tegengekomen waarin zo veel tools voor het beheer van het ontwikkelingsproces zijn geïntegreerd.

Ik ben dol op automatisering, dus ik heb onderzocht hoe ik Pantheon kan verbinden met GitLab, zodat commits naar de hoofdbranch op GitLab worden gedeployed naar de hoofdontwikkelomgeving in Pantheon. Bovendien kunnen merge requests op GitLab code aanmaken en deployen naar multidev-omgevingen in Pantheon.

In deze gids leg ik uit hoe je de verbinding tussen GitLab en Pantheon kunt instellen en het werkproces van WordPress en Drupal kunt optimaliseren.

Je kunt natuurlijk de GitLab-repository spiegelen, maar we gaan alles handmatig doen om te graven in GitLab CI en in de toekomst dit hulpmiddel niet alleen voor deployment te gebruiken.

Inleiding

Voor deze post is het belangrijk te begrijpen dat Pantheon elke website opsplitst in drie elementen: code, database en bestanden.

De code omvat CMS-bestanden, zoals de kernel, plugins en thema's van WordPress. Deze bestanden worden beheerd in de Git-repository, die op Pantheon is gehost, wat betekent dat we code van GitLab naar Pantheon kunnen deployen met Git.
Bestanden in Pantheon zijn mediabestanden, dat zijn afbeeldingen voor de website. Gewoonlijk worden ze door gebruikers geüpload, en Git negeert ze.

Maak een gratis account aan, leer meer over het werkproces van Pantheon of meld je aan voor een demo op pantheon.io.

Veronderstellingen

Mijn project op Pantheon en GitLab heet pantheon-gitlab-blog-demo. De projectnaam moet uniek zijn. Hier zullen we werken met een WordPress-site. We zouden ook Drupal kunnen gebruiken, maar dan moeten er enkele aanpassingen worden gedaan.

Ik zal de Git commandoregelgebruiken, terwijl jij kunt werken in de grafische interface, als je dat wilt.

We creëren een project

Om te beginnen creëren we een GitLab-project (hier komen we als nog op terug).

Nu we creëren een WordPress-website op Pantheon. Daarna installeren we WordPress voor het dashboard van de site.

Als je de drang voelt om iets te wijzigen, zoals plugins verwijderen of toevoegen, heb een beetje geduld. De site is nog niet verbonden met GitLab, en we willen dat alle codewijzigingen via GitLab verlopen.

Zodra we WordPress hebben geïnstalleerd, gaan we terug naar het Pantheon-dashboard en wijzigen we de ontwikkelingsmodus naar Git.

De eerste commit naar GitLab

Nu moeten we de initiële WordPress-code van de Pantheon-website naar GitLab overbrengen. Hiervoor klonen we de code uit de Git-repository van de Pantheon-site lokaal, en sturen deze daarna naar de GitLab-repository.

Om het eenvoudiger en veiliger te maken, voegen we een SSH-sleutel toe aan Pantheon en zullen we niet telkens een wachtwoord hoeven in te voeren als we de Pantheon Git-repository klonen. Tevens voegen we de SSH-sleutel toe aan GitLab.

Om dit te doen, klonen we de Pantheon-website lokaal door de opdracht uit het veld Clone with Git op het dashboard van de site te kopiëren.

Als je hulp nodig hebt, lees dan de documentatie over het starten met Git voor Pantheon.

Laten we nu git remote originwijzigen, zodat het naar GitLab verwijst in plaats van naar Pantheon. Dit kan met de git remote-opdracht.

We gaan naar het GitLab-project en kopiëren de URL van de repository uit het dropdownmenu Clone op de projectdetailspagina. We kiezen voor de optie Clone with SSH, aangezien we de SSH-sleutel al hebben ingesteld.

Standaard git remote voor de lokale kopie van de code-repository — oorsprong. Dit kan gewijzigd worden met git remote set-url origin [URL van de GitLab-repository], waar we in plaats van de haakjes de werkelijke URL invoeren.

Ten slotte uitvoeren we git push origin master --force, om de WordPress-code van de Pantheon-website naar GitLab te sturen.

De parameter –force is maar één keer nodig. Daarna in de commando's git push zal het niet op GitLab zijn.

We stellen de referenties en variabelen in

Vergeet je nog hoe we lokaal de SSH-sleutel hebben toegevoegd om toegang te krijgen tot Pantheon en GitLab? De SSH-token kan worden gebruikt voor autorisatie in GitLab en Pantheon.

GitLab heeft uitstekende documentatie. Laten we kijken naar de sectie over SSH-sleutels bij het gebruik van de Docker-executor in het document over het gebruik van SSH-sleutels met GitLab CI/CD..

Nu gaan we de eerste twee stappen uitvoeren: we creëren een nieuw paar SSH-sleutels lokaal met ssh-keygen en voegen de privésleutel toe als variabele in het project..

Vervolgens stellen we in SSH_PRIVATE_KEY hoe GitLab CI/CD omgevingsvariabele in de projectinstellingen. in de projectinstellingen.
In de derde en vierde stap maken we een bestand aan .gitlab-ci.yml met de volgende inhoud:

before_script:
  # Zie 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"

Laten we het bestand niet committen .gitlab-ci.yml, later moet er nog iets aan worden toegevoegd.

Nu voeren we de vijfde stap uit en voegen we de openbare sleutel toe die we in de eerste stap hebben gemaakt, aan de services waarvoor je toegang nodig hebt in de bouwomgeving..

In ons geval willen we vanuit GitLab toegang krijgen tot Pantheon. Volg de instructies in het Pantheon-document over het toevoegen van een SSH-sleutel aan Pantheon en voer deze stap uit.

Vergeet niet: de privésleutel gaat in GitLab, de openbare sleutel in Pantheon.

Laten we nog een paar omgevingsvariabelen instellen. De eerste heet PANTHEON_SITE. De waarde is de naam van de Pantheon-site op jouw machine.

De naam op de machine staat aan het einde van de opdracht Clone with Git. Je hebt de site al lokaal gekloond, dus dit is de naam van de map van de lokale repository.

Laten we de omgevingsvariabele PANTHEON_GIT_URLinstellen. Dit is de Git-repository-URL voor de Pantheon-site die we al hebben gebruikt.

We voeren alleen de SSH-repository-URL in, zonder git clone en de naam van de site op de machine aan het einde.

Poeh. Dat hebben we gedaan, nu kunnen we ons bestand afmaken .gitlab-ci.yml.

Laten we een deploy-taak aanmaken.

Wat we in het begin met GitLab CI zullen doen, lijkt erg op wat we eerder met Git-repositories hebben gedaan. Maar deze keer voegen we de Pantheon-repository als een tweede remote Git-bron toe, en dan sturen we de code van GitLab naar Pantheon.

Om dit te doen, stellen we in een stage deploy en taak deploy:dev, omdat we naar de ontwikkelomgeving op Pantheon zullen deployen. Het resultaatbestand .gitlab-ci.yml zal er als volgt uitzien:

stages:
- deploy

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

Variabelen SSH_PRIVATE_KEY, PANTHEON_SITE en PANTHEON_GIT_URL zou zouden vertrouwd moeten voelen - we hebben deze omgevingsvariabelen eerder ingesteld. Met deze variabelen kunnen we waarden in het bestand gebruiken .gitlab-ci.yml meermalen, en we hoeven ze alleen maar op één plek bij te werken.

Laten we uiteindelijk het bestand toevoegen, committen en verzenden .gitlab-ci.yml naar GitLab.

We controleren de implementatie

Als we alles goed hebben gedaan, zal de taak deploy:dev met succes worden uitgevoerd in GitLab CI/CD en de commit verzenden .gitlab-ci.yml naar Pantheon. Laten we kijken.

We sturen de branches van merge-requests naar Pantheon

Hier zullen we mijn favoriete functie van Pantheon gebruiken - multidev, waar we op verzoek extra Pantheon-omgevingen voor Git-branches kunnen creëren.

Toegang tot multidev is beperkt, dus dit gedeelte kan overgeslagen worden. Maar als je toegang hebt, kun je de prestaties aanzienlijk verbeteren door automatische multidev-omgevingen op Pantheon in te stellen vanuit GitLab merge-requests.

Laten we eerst een nieuwe Git-branch lokaal maken met behulp van git checkout -b multidev-support. Nu moeten we weer iets veranderen in .gitlab-ci.yml.

Ik vind het leuk om het nummer van de merge-request in de naam van de Pantheon-omgeving op te nemen. Bijvoorbeeld, de eerste merge-request - mr-1, de tweede - mr-2 enz.

De merge-request verandert, dus we moeten dynamisch de namen van de Pantheon-branches bepalen. In GitLab is het heel eenvoudig - we moeten gebruik maken van vooraf gedefinieerde omgevingsvariabelen.

We kunnen $CI_MERGE_REQUEST_IID, gebruiken om het nummer van de merge-request aan te geven. Laten we dit alles toepassen samen met de globale omgevingsvariabelen die we eerder hebben ingesteld, en voegen we een nieuwe taak deploy:multidev aan het einde van het bestand toe .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 de source branch van de merge request
    - git checkout $CI_COMMIT_REF_NAME
    # Voeg de Pantheon git repository als een extra remote toe
    - git remote add pantheon $PANTHEON_GIT_URL
    # Push de source branch van de merge request naar Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  only:
    - merge_requests

Het zal lijken op onze taak deploy:dev, alleen de branch wordt naar Pantheon gestuurd, niet naar master.

We hebben het bijgewerkte bestand toegevoegd en gecommit .gitlab-ci.yml, en nu zullen we de nieuwe branch naar GitLab sturen met git push -u origin multidev-support.

Nu zullen we een nieuwe merge-request maken vanuit de branch multidev-ondersteuning, door te drukken op Maak een mergeverzoek aan.

Nadat we het mergeverzoek hebben aangemaakt, kijken we hoe de CI/CD-taak wordt uitgevoerd deploy:multidev.

Kijk — er is een nieuwe tak naar Pantheon gestuurd. Maar als we naar het multidev-gedeelte van het dashboard op Pantheon gaan, zien we de nieuwe omgeving daar niet

Laten we het gedeelte Git Branches bekijken.

Uiteindelijk heeft onze tak mr-1 Pantheon bereikt. Laten we een omgeving creëren vanuit de tak mr-1.

We hebben de multidev-omgeving gemaakt, en nu gaan we terug naar GitLab en kijken in het gedeelte Operaties > Omgevingen. We zien records voor , maar volgt geen wijzigingen), gebruikmakend van een andere configuratie. en mr-1.

Dit is omdat we een record hebben toegevoegd omgeving met de naam naam en url aan de CI/CD-taken. Als we op het symbool van de openstaande omgeving klikken, worden we doorgestuurd naar de multidev-URL op Pantheon.

Automatiseer de creatie van multidev

In principe kunnen we hier stoppen en gewoon niet vergeten om een multidev-omgeving aan te maken voor elk mergeverzoek, maar dit proces kan worden geautomatiseerd.

Pantheon heeft een command-line tool Terminus, waarmee we automatisch met het platform kunnen werken. Met Terminus kunnen we multidev-omgevingen aanmaken vanuit de commandoregel — perfect voor GitLab CI.

We hebben een nieuw mergeverzoek nodig om dit te testen. Laten we een nieuwe tak maken met behulp van git checkout -b auto-multidev-creation.

Om Terminus in GitLab CI/CD-taken te gebruiken, hebben we een machine-token nodig voor authenticatie met Terminus en een containerafbeelding met Terminus.

We maken een Pantheon machine-token, bewaren het op een veilige plek en voegen het toe als een globale omgevingsvariabele in GitLab met de naam PANTHEON_MACHINE_TOKEN.

Als je vergeten bent hoe je omgevingsvariabelen in GitLab toevoegt, ga dan terug naar de plek waar we PANTHEON_SITE.

We maken een Dockerfile met Terminus

Als je geen Docker gebruikt of niet van bestanden houdt Dockerfile, neem dan mijn afbeelding registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest en sla dit gedeelte over.

GitLab heeft een containerregister, waar we de Dockerfile voor ons project kunnen opbouwen en hosten. Laten we een Dockerfile met Terminus maken om met Pantheon te werken.

Terminus is een command-line tool geschreven in PHP, dus laten we beginnen met een PHP-afbeelding. Ik installeer Terminus via Composer, dus ik neem de officiële Docker Composer-afbeelding. We maken Dockerfile in de map van de lokale repository met de volgende inhoud:

# 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"

Volg de instructies voor het bouwen en pushen van afbeeldingen in de sectie Build and push images in van de documentatie van het containerregister, om de afbeelding te bouwen vanuit Dockerfile en deze naar GitLab te verzenden.

Open het gedeelte Register in het GitLab-project. Als alles volgens plan is verlopen, zal onze afbeelding daar zijn. Noteer de link naar de afbeeldingtags — we hebben deze nodig voor het bestand .gitlab-ci.yml.

Sectie script in de taak deploy:multidev begint uit te breiden, laten we het dus naar een apart bestand verplaatsen. We maken een nieuw bestand aan 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

Het script bevindt zich in een privémap en geeft geen webtoegang op Pantheon. We hebben een script voor onze multidev-logica. Laten we nu het gedeelte bijwerken deploy:multidev bestand .gitlab-ci.yml, zodat het er als volgt uitziet:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Voer het multidev-deployscript uit
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

We moeten ervoor zorgen dat onze taken worden uitgevoerd in de gemaakte aangepaste afbeelding, dus laten we een definitie toevoegen afbeelding met de registry URL in .gitlab-ci.yml. Uiteindelijk hebben we zo'n bestand gekregen .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Zie 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:
    # Voer het multidev-deployscript uit
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

We voegen toe, committen en verzenden private/multidev-deploy.sh en .gitlab-ci.yml. Laten we nu teruggaan naar GitLab en wachten tot de CI/CD-taak is uitgevoerd. Geduld: multidev kan enkele minuten in beslag nemen.

Vervolgens gaan we de lijst met multidevs op Pantheon bekijken. O, wonder! De multidev-omgeving mr-2 is al hier.

Conclusie

Mijn team werkt veel leuker sinds we merge requests zijn begonnen te openen en omgevingen automatisch te creëren.

Met de krachtige tools van GitLab en Pantheon kun je GitLab automatisch aan Pantheon koppelen.

Omdat we GitLab CI/CD gebruiken, zal onze workflow groeimogelijkheden hebben. Hier zijn een paar ideeën om aan de slag te gaan:

• Voeg een build-stap toe.
• Voeg geautomatiseerde tests toe.
• Voeg een taak toe om te zorgen voor naleving van de code-standaarden.
• Voeg dynamisch beveiligingstest voor toepassingen.

Laat ons weten wat je denkt van GitLab, Pantheon en automatisering.

P.S. Wist je dat Terminus, de commandoregeltool van Pantheon, kan worden uitgebreid via plugins?

We hebben goed gewerkt aan versie 2 van onze plugin voor de build-tools van Terminus met ondersteuning voor GitLab. Als je niet wilt rommelen met de configuratie voor elk project, probeer dan deze plugin en help ons de beta v2 te testen. Voor het team van Terminus build:project:create je hebt alleen een Pantheon-token en een GitLab-token nodig. Hiermee wordt een van de projectvoorbeelden met Composer en automatische tests uitgerold, wordt er een nieuw project in GitLab aangemaakt, een nieuwe Pantheon-website gecreëerd en worden ze verbonden met behulp van omgevingsvariabelen en SSH-sleutels.

Over de auteur

Andrew Taylor maakt ontwikkelaars-tools in Pantheon.

Bron: habr.com