Hur man kopplar GitLab och Pantheon och optimerar arbetsflöden för Drupal och WordPress

Vår gäst, skaparen av utvecklarverktyg från Pantheon, berättar hur man automatiserar WordPress-deploys med hjälp av GitLab CI/CD.

I Pantheon Jag arbetar med utvecklarrelationer, så jag letar alltid efter nya sätt att hjälpa WordPress- och Drupalutvecklare att lösa automationsproblem i sina arbetsflöden. För detta gillar jag att experimentera med nya verktyg och kombinera dem för effektivt arbete.

Jag ser ofta hur utvecklare brottas med en enda mellanserver.

Det är inte så roligt att vänta på sin tur att använda mellanservern eller att skicka URL:er till kunder med noteringen: 'Här kan du titta, men här kan du vänta.'

Multidev-miljöer — ett av de coola verktygen från Pantheon — löser detta problem, eftersom man på begäran kan skapa miljöer för Git-grenar. Varje multidev-miljö har sin egen URL och databas, så utvecklarna kan arbeta ostört, kontrollera kvaliteten och få godkännande utan att trampa varandra på tårna.

Men Pantheon har inga verktyg för versionskontroll eller kontinuerlig integration och distribution (CI/CD). Däremot är det en flexibel plattform som kan integrera alla verktyg.

Jag har också märkt att teamen använder olika verktyg för utveckling och för byggande och distribution.

Till exempel har de olika verktyg för versionskontroll och CI/CD. Man får kämpa och växla mellan verktygen för att redigera kod och diagnostisera problem.

På GitLab Det finns en heltäckande uppsättning utvecklingsverktyg: för versionskontroll, ärenden, merge-förfrågningar, en bästa i klassen CI/CD-pipeline, containerregister och allt sådant. Jag har ännu inte stött på applikationer som har så mycket för att hantera utvecklingsarbetets flöde.

Jag älskar automatisering, så jag har studerat hur man kopplar Pantheon till GitLab, så att commits i huvudgrenen på GitLab deployas till huvudutvecklingsmiljön i Pantheon. Och dessutom kan merge-förfrågningar på GitLab skapa och deploya kod till multidev-miljöer i Pantheon.

I den här guiden kommer jag att berätta hur man ställer in en anslutning mellan GitLab och Pantheon och optimerar arbetsflödet för WordPress och Drupal.

Man kan, självklart, spegelvända GitLab-repositoriet, men vi kommer att göra allt manuellt för att grotta in i GitLab CI och i framtiden använda detta verktyg inte bara för deployment.

Introduktion

För detta inlägg behöver vi förstå att Pantheon delar varje webbplats i tre element: kod, databas och filer.

Koden inkluderar CMS-filer, såsom kärnan, plugins och teman för WordPress. Dessa filer hanteras i Git-repositoriet, som är placerat på Pantheon, vilket innebär att vi kan distribuera kod från GitLab till Pantheon med Git.
Filer i Pantheon avser mediafiler, det vill säga bilder för webbplatsen. Vanligtvis laddas de upp av användare, och Git ignorerar dem.

Skapa ett gratis konto, läs mer om arbetsflödet i Pantheon eller boka en demo på pantheon.io.

Antaganden

Mitt projekt på Pantheon och GitLab heter pantheon-gitlab-blogg-demo. Projektets namn måste vara unikt. Här kommer vi att arbeta med en WordPress-webbplats. Vi kan även använda Drupal, men då måste vissa ändringar göras.

Jag kommer att använda Git-kommandoraden, men du kan arbeta i det grafiska gränssnittet, om du vill.

Skapar projekt

Börja med att skapa ett GitLab-projekt (detta kommer vi att återkomma till).

Nu skapa en WordPress-webbplats på Pantheon. Sedan installerar vi WordPress för webbplatsens instrumentpanel.

Om du känner för att göra några ändringar, som att ta bort eller lägga till plugins, vänta lite. Webbplatsen är ännu inte kopplad till GitLab, och vi vill att alla kodändringar ska gå genom GitLab.

När vi har installerat WordPress, går vi tillbaka till Pantheons instrumentpanel och ändrar utvecklingsläget till Git.

Första commit på GitLab

Nu måste vi överföra grundkoden för WordPress från Pantheon-webbplatsen till GitLab. För detta klonar vi koden från Pantheon-webbplatsens Git-repo lokalt och skickar sedan till GitLab-repositoriet.

För att göra det enklare och säkrare, lägger vi till en SSH-nyckel i Pantheon och slipper ange lösenordet varje gång vi klonar Pantheon Git-repositoriet. Samtidigt lägger vi också till SSH-nyckeln på GitLab.

För detta klonar vi Pantheon-webbplatsen lokalt genom att kopiera kommandot från fältet Clone with Git på webbplatsens instrumentpanel.

Om du behöver hjälp, läs dokumentationen om att komma igång med Git för Pantheon.

Nu ändrar vi git remote origin, för att peka på GitLab istället för Pantheon. Detta kan göras med kommandot git remote.

Vi går till GitLab-projektet och kopierar URL-adressen till repositoriet från rullgardinsmenyn Clone på projektets detaljsida. Vi väljer alternativet Clone with SSH, eftersom vi redan har konfigurerat SSH-nyckeln.

Som standard git remote för den lokala kopian av kodens repositorium — origin. Detta kan ändras med git remote set-url origin [URL till GitLab-repositoriet], där vi skriver in den faktiska URL:en istället för inom klamrar.

Till sist kör vi git push origin master --force, för att skicka WordPress-koden från Pantheon-webbplatsen till GitLab.

Parametern –force behövs bara en gång. Sedan i kommandona git push kommer det inte att finnas på GitLab.

Ställer in autentiseringsuppgifter och variabler

Kommer ni ihåg hur vi lokalt lade till en SSH-nyckel för att autentisera oss hos Pantheon och GitLab? SSH-token kan användas för autentisering mot GitLab och Pantheon.

GitLab har utmärkt dokumentation. Låt oss titta på avsnittet om SSH-nycklar när man använder Docker-executorn i dokumentationen om att använda SSH-nycklar med GitLab CI/CD.

Nu ska vi genomföra de första två stegen: skapa ett nytt par SSH-nycklar lokalt med ssh-keygen och lägga till den privata nyckeln som en variabel i projektet.

Sedan ställer vi in SSH_PRIVATE_KEY som GitLab CI/CD-miljövariabeln i projektinställningarna.
I det tredje och fjärde steget skapar vi filen .gitlab-ci.yml med följande innehåll:

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

Vi ska inte commit:a filen just nu .gitlab-ci.yml, senare måste vi lägga till något mer till den.

Nu genomför vi det femte steget och lägger till den offentliga nyckeln som vi skapade i det första steget till de tjänster som du behöver åtkomst till i byggmiljön.

I vårt fall vill vi få åtkomst till Pantheon från GitLab. Följ instruktionerna i Pantheon-dokumentationen om att lägga till SSH-nyckeln i Pantheon och genomför detta steg.

Kom ihåg: den privata SSH-nyckeln är i GitLab, den offentliga är i Pantheon.

Låt oss konfigurera några fler miljövariabler. Den första kallas PANTHEON_SITE. Dess värde är namnet på Pantheon-webbplatsen på din maskin.

Namnet på maskinen anges i slutet av kommandot Klona med Git. Du har redan klonat webbplatsen lokalt, så detta blir namnet på den lokala repository-katalogen.

Sedan ställer vi in miljövariabeln PANTHEON_GIT_URL. Detta är URL:en till Git-repot för Pantheon-webbplatsen som vi redan har använt.

Vi anger endast SSH-repo-URL:en, utan git clone och namnet på webbplatsen på maskinen i slutet.

Puh. Det är klart, nu kan vi avsluta vår fil .gitlab-ci.yml.

Skapar en deploy-uppgift

Det vi först kommer att göra med GitLab CI liknar mycket det vi gjorde med Git-repot tidigare. Men den här gången lägger vi till Pantheon-repot som en andra fjärrkälla för Git och skickar sedan koden från GitLab till Pantheon.

För detta konfigurerar vi steget deploy och uppgiften deploy:dev, eftersom vi ska deploya till utvecklingsmiljön på Pantheon. Resultatet blir att filen .gitlab-ci.yml ser ut så här:

steg:
- distribuera

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

distribuera:dev:
  steg: distribuera
  miljö:
    namn: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  script:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  endast:
    - master

Variabler SSH_PRIVATE_KEY, PANTHEON_SITE och PANTHEON_GIT_URL bör se bekanta ut — vi har konfigurerat dessa miljövariabler tidigare. Med dessa variabler kan vi använda värden i filen .gitlab-ci.yml många gånger, och uppdatera dem behöver vi bara göra på ett ställe.

Slutligen lägger vi till, commitar och skickar filen .gitlab-ci.yml till GitLab.

Kontrollerar distributionen

Om vi har gjort allt rätt, kommer uppgiften deploy:dev att genomföras framgångsrikt i GitLab CI/CD och skicka commit .gitlab-ci.yml till Pantheon. Låt oss kolla.

Skickar brancherna för merge-begäran till Pantheon

Här kommer vi att använda min favoritfunktion på Pantheon — multidev, där man kan skapa ytterligare miljöer på Pantheon för Git-brancher på begäran.

Tillgången till multidev är begränsad, så detta avsnitt behöver kanske inte utföras. Men om du har tillgång kan du allvarligt öka produktiviteten genom att konfigurera automatisk skapande av multidev-miljöer på Pantheon från merge-begärningar i GitLab.

Först gör vi en ny Git-branch lokalt med hjälp av git checkout -b multidev-support. Nu ändrar vi återigen något i .gitlab-ci.yml.

Jag gillar att ange numret på merge-begäran i namnet på Pantheon-miljön. Till exempel, den första merge-begäran — mr-1, den andra — mr-2 och så vidare.

Merge-begäran förändras, så vi behöver dynamiskt bestämma namnen på Pantheon-brancherna. På GitLab är det enkelt — det gäller att använda fördefinierade miljövariabler.

Vi kan ta $CI_MERGE_REQUEST_IID, för att ange numret på merge-begäran. Låt oss använda allt detta tillsammans med de globala miljövariabler som vi angav tidigare och lägga till en ny uppgift deploy:multidev i slutet av filen .gitlab-ci.yml.

deploy:multidev:
  steg: distribuera
  miljö:
    namn: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Checka ut källbranch för merge-begäran
    - git checkout $CI_COMMIT_REF_NAME
    # Lägg till Pantheon git-repositoriet som en extra remote
    - git remote add pantheon $PANTHEON_GIT_URL
    # Skicka källbranch för merge-begäran till Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  endast:
    - merge_requests

Det kommer att likna vår uppgift deploy:dev, förutom att branchen skickas till Pantheon, inte till master.

Vi har lagt till och committat den uppdaterade filen .gitlab-ci.yml, och nu ska vi skicka den nya branchen till GitLab med git push -u origin multidev-support.

Låt oss nu skapa en ny merge-förfrågan från grenen multidev-support, genom att trycka på Skapa merge-förfrågan.

När vi har skapat merge-förfrågan, låt oss se hur CI/CD-uppgiften utförs deploy:multidev.

Titta - en ny gren har skickats till Pantheon. Men om vi går till avsnittet multidev på Pantheons instrumentbräda, ser vi inte den nya miljön där

Låt oss titta på avsnittet Git Branches.

Till slut har vår gren mr-1 nått Pantheon. Låt oss skapa en miljö av grenen mr-1.

Vi har skapat en multidev-miljö, nu går vi tillbaka till GitLab och kollar in avsnittet Operations > Environments. Vi kommer att se poster för dev och mr-1.

Det beror på att vi har lagt till en post miljö med namnet name och url i CI/CD-uppgifterna. Om vi klickar på ikonen för den öppna miljön, kommer vi att gå till URL:en för multidev-miljön på Pantheon.

Vi automatiserar skapandet av multidev

I princip kan vi stanna här och bara komma ihåg att skapa en multidev-miljö för varje merge-förfrågan, men den här processen kan automatiseras.

Pantheon har ett kommandoradsverktyg Terminus, där vi kan arbeta automatiskt med plattformen. I Terminus kan vi skapa multidev-miljöer från kommandoraden - perfekt för GitLab CI.

Vi behöver en ny merge-förfrågan för att testa detta. Låt oss skapa en ny gren med hjälp av git checkout -b auto-multidev-creation.

För att använda Terminus i GitLab CI/CD-uppgifter behöver vi en maskintoken för autentisering i Terminus och en containerbild med Terminus.

Skapa en maskintoken för Pantheon, spara den på en säker plats och lägg till den som en global miljövariabel i GitLab med namnet PANTHEON_MACHINE_TOKEN.

Om du har glömt hur man lägger till miljövariabler i GitLab, gå tillbaka till där vi definierade PANTHEON_SITE.

Skapa en Dockerfile med Terminus

Om du inte använder Docker eller inte gillar filer Dockerfile, ta min bild registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest och hoppa över detta avsnitt.

I GitLab finns det ett containerregister, där vi kan bygga och publicera Dockerfile för vårt projekt. Låt oss skapa en Dockerfile med Terminus för att arbeta med Pantheon.

Terminus är ett kommandoradsverktyg skrivet i PHP, så låt oss börja med en PHP-bild. Jag installerar Terminus via Composer, så jag tar utgångspunkt i den officiella Docker Composer-bilden. Skapa Dockerfile i katalogen för det lokala repositoriet med detta innehåll:

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

Följ instruktionerna för att bygga och skicka bilder från avsnittet Bygg och skicka bilder på i dokumentationen för containerregistret, för att bygga en bild från Dockerfile och skicka den till GitLab.

Öppna avsnittet Registry i GitLab-projektet. Om allt har gått enligt planerna, kommer vår bild att finnas där. Skriv ner länken till bildens tagg - den behöver vi för filen .gitlab-ci.yml.

Avsnitt script i uppgiften deploy:multidev börjar växa, så låt oss flytta den till en separat fil. Skapa en ny fil 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

Skriptet ligger i en privat katalog och ger ingen webbåtkomst på Pantheon. Vi har ett skript för vår multidev-logik. Låt oss nu uppdatera avsnittet deploy:multidev filen .gitlab-ci.yml, så att det ser ut så här:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Kör multidev deploy-skriptet
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Vi måste säkerställa att våra uppgifter körs i den skapade anpassade bilden, så vi lägger till definitionen bild med register-URL:en i .gitlab-ci.yml. Resultatet är att vi får en sådan fil .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Se 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:
    # Kör multidev deploy-skriptet
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Lägg till, commit och skicka private/multidev-deploy.sh och .gitlab-ci.yml. Nu går vi tillbaka till GitLab och väntar på att CI/CD-uppgiften ska köras. Ha tålamod: multidev kan skapas under några minuter.

Sen går vi och kollar listan över multidev på Pantheon. Åh, mirakel! Multidev-miljön mr-2 är redan här.

Slutsats

Mitt team började ha mycket roligare när vi började öppna merge-förfrågningar och automatiskt skapa miljöer.

Med de kraftfulla verktygen GitLab och Pantheon kan du automatiskt koppla GitLab till Pantheon.

Eftersom vi använder GitLab CI/CD har vår arbetsprocess mycket tillväxtpotential. Här är några idéer för att komma igång:

• Lägg till ett byggsteg.
• Lägg till automatiserade tester.
• Lägg till en uppgift för att säkerställa att kodstandarder följs.
• Lägg till dynamisk applikation säkerhetstestning.

Skriv vad du tycker om GitLab, Pantheon och automatisering.

P.S. Visste du att Terminus, Pantheons kommandoradsverktyg, kan utökas via plugins?

Vi på Pantheon har jobbat hårt med version 2 av vår pluggin för byggverktyg Terminus med stöd för GitLab. Om du inte vill krångla med installationen för varje projekt, prova det här pluginet och hjälp oss att testa beta v2. För teamet Terminus build:project:create behövs endast en Pantheon-token och en GitLab-token. Den kommer att distribuera ett av exempelprojekten med Composer och automatisk testning, skapa ett nytt projekt i GitLab, en ny Pantheon-sajt och koppla dem med hjälp av miljövariabler och SSH-nycklar.

Om författaren

Andrew Taylor skapar verktyg för utvecklare i Pantheon.

Källa: habr.com