🥇 Hvordan koble GitLab og Pantheon og optimalisere Drupal og WordPress arbeidsflyter

Vår skaper av gjesteutviklerverktøy hos Pantheon snakker om hvordan man automatiserer WordPress-implementeringer ved å bruke GitLab CI/CD.

В Pantheon Jeg jobber i utviklerrelasjoner, så jeg er alltid på utkikk etter nye måter å hjelpe WordPress- og Drupal-utviklere med å løse automatiseringsproblemer i arbeidsflytene deres. For å gjøre dette liker jeg å eksperimentere med nye verktøy og kombinere dem med hverandre for å fungere effektivt.

Jeg ser ofte utviklere som sliter med en enkelt staging-server.

Det er en glede å vente på din tur til å bruke en mellomserver eller sende klienter en URL med meldingen: "Se her, men ikke se her ennå."

Multidev-miljøer - et av de kule Pantheon-verktøyene - løser dette problemet, for med dem kan du lage miljøer for Git-grener etter behov. Hvert multidev-miljø har sin egen URL og database, slik at utviklere kan jobbe stille, sjekke kvalitet og få godkjenning uten å tråkke hverandre på tærne.

Men Pantheon har ikke verktøy for versjonskontroll eller kontinuerlig integrasjon og distribusjon (CI/CD). Men det er en fleksibel plattform som du kan integrere alle verktøy med.

Jeg la også merke til at team bruker visse verktøy for utvikling, og forskjellige for montering og distribusjon.

For eksempel har de ulike verktøy for versjonskontroll og CI/CD. Du må fikle rundt og bytte mellom verktøy for å redigere kode og diagnostisere problemer.

På GitLab det er et komplett sett med utviklingsverktøy: for versjonskontroll, billetter, sammenslåingsforespørsler, en klassens beste CI/CD-pipeline, et containerregister og alt sånt. Jeg har ennå ikke kommet over en applikasjon som tilbyr så mye for å administrere utviklingsarbeidsflyten din.

Jeg elsker automatisering, så jeg lærte hvordan jeg kobler Pantheon til GitLab slik at forpliktelser til hovedgrenen på GitLab blir distribuert til hovedutviklingsmiljøet i Pantheon. Og sammenslåingsforespørsler på GitLab kan opprette og distribuere kode til multidev-miljøer i Pantheon.

I denne opplæringen vil jeg lede deg gjennom hvordan du setter opp en forbindelse mellom GitLab og Pantheon og optimaliserer WordPress- og Drupal-arbeidsflyten din.

Selvfølgelig er det mulig, speil GitLab-depotet, men vi vil gjøre alt med hendene våre for å fordype oss GitLab CI og i fremtiden bruke dette verktøyet ikke bare for distribusjon.

Innledning

For dette innlegget må du forstå at Pantheon deler hvert nettsted ned i tre elementer: kode, database og filer.

Koden inkluderer CMS-filer som WordPress-kjerne, plugins og temaer. Disse filene administreres i Git-lagre, hostet av Pantheon, noe som betyr at vi kan distribuere kode fra GitLab til Pantheon med Git.
Filer i Pantheon er mediefiler, det vil si bilder for nettstedet. Vanligvis blir de lastet opp av brukere og Git ignorerer dem.

Opprett en gratis konto, finn ut mer om Pantheon arbeidsflyt eller registrere deg for en demo på pantheon.io.

Antagelser

Prosjektet mitt om Pantheon og GitLab heter pantheon-gitlab-blog-demo. Prosjektnavnet må være unikt. Her skal vi jobbe med en WordPress-side. Du kan ta Drupal, men du må endre noen ting.

jeg vil bruke Git kommandolinjeog du kan jobbe i grafisk grensesnitt, hvis du vil.

Lag et prosjekt

Først, la oss lage GitLab-prosjekt (vi kommer tilbake til dette senere).

Nå lage et WordPress-nettsted på Pantheon. Deretter installerer vi WordPress for sidens dashbord.

Hvis hendene dine klør etter å endre noe, for eksempel fjerne eller legge til plugins, vær tålmodig. Siden er ennå ikke koblet til GitLab, og vi ønsker at alle kodeendringer skal gå gjennom GitLab.

Når vi har installert WordPress, gå tilbake til Pantheon-nettstedets dashbord og endre utviklingsmodus til Git.

Innledende commit på GitLab

Nå må du overføre den første WordPress-koden fra Pantheon-siden til GitLab. For å gjøre dette, kloner vi koden fra Git-depotet til Pantheon-siden lokalt, og sender den deretter til GitLab-depotet.

For å gjøre det enklere og tryggere, legg til en SSH-nøkkel til Pantheon og vi trenger ikke å skrive inn et passord hver gang vi kloner et Pantheon Git-lager. Samtidig allerede legg til en SSH-nøkkel til GitLab.

For å gjøre dette, klone Pantheon-nettstedet lokalt ved å kopiere kommandoen fra Clone with Git-feltet på nettsidens dashbord.

Hvis du trenger hjelp, les dokumentasjonen komme i gang med Git for Pantheon.

La oss nå endre git remote originå peke på GitLab i stedet for Pantheon. Det kan gjøres командой git remote.

La oss gå til GitLab-prosjektet og kopiere depot-URLen fra Clone-rullegardinmenyen på siden med prosjektdetaljer. La oss velge alternativet Klone med SSH, fordi vi allerede har konfigurert SSH-nøkkelen.

Som standard git remote for en lokal kopi av kodelageret - origin. Dette kan endres c git remote set-url origin [URL репозитория GitLab], hvor vi i stedet for parentes skriver inn den faktiske URL-en.

Til slutt lanserer vi git push origin master --forceå presse WordPress-kode fra Pantheon til GitLab.

Alternativet –force er bare nødvendig én gang. Så i lag git push det vil ikke være på GitLab.

Sette opp legitimasjon og variabler

Husker du hvordan vi la til en SSH-nøkkel lokalt for å logge på Pantheon og GitLab? SSH-tokenet kan brukes til å autorisere GitLab og Pantheon.

GitLab har utmerket dokumentasjon. La oss se avsnitt om SSH-nøkler når du bruker Docker-utføreren i dokumentet om bruk av SSH-nøkler med GitLab CI/CD.

Vi vil nå fullføre de to første trinnene: La oss lage et nytt SSH-nøkkelpar lokalt med ssh-keygen og legge til den private nøkkelen som en variabel i prosjektet.

Da spør vi SSH_PRIVATE_KEY som GitLab CI/CD miljøvariabel i prosjektinnstillingene.
I det tredje og fjerde trinnet vil vi lage en fil .gitlab-ci.yml med innhold som dette:

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"

La oss ikke forplikte filen ennå .gitlab-ci.yml, så må du legge til noe annet til den.

Nå utfører vi det femte trinnet og legg til den offentlige nøkkelen du opprettet i det første trinnet til tjenestene du trenger tilgang til i byggemiljøet.

I vårt tilfelle ønsker vi tilgang til Pantheon fra GitLab. Vi følger instruksjonene i Pantheon-dokumentet på legge til en SSH-nøkkel til Pantheon og utfør dette trinnet.

Husk: privat SSH er i GitLab, åpen SSH er i Pantheon.

La oss sette opp noen flere miljøvariabler. Den første heter PANTHEON_SITE. Verdien er navnet på Pantheon-nettstedet på maskinen din.

Navnet på maskinen er oppført på slutten av kommandoen Clone with Git. Du har allerede klonet området lokalt, så dette vil være navnet på den lokale depotkatalogen.

La oss deretter sette opp miljøvariabelen PANTHEON_GIT_URL. Dette er nettadressen til Git-depotet for Pantheon-nettstedet som vi allerede har brukt.

Skriv inn bare URL-adressen til SSH-depotet, uten git clone og navnet på nettstedet på maskinen på slutten.

Puh. Det er gjort, nå kan vi fullføre filen vår .gitlab-ci.yml.

Opprett en distribusjonsoppgave

Det vi i utgangspunktet skal gjøre med GitLab CI er veldig likt det vi har gjort med Git-repositories tidligere. Men denne gangen, la oss legge til Pantheon-depotet som en andre ekstern Git-kilde, og deretter skyve koden fra GitLab til Pantheon.

For å gjøre dette, la oss konfigurere stadium deploy и oppgave deploy:dev, fordi vi vil distribuere til utviklingsmiljøet på Pantheon. Den resulterende filen .gitlab-ci.yml Det vil se slik ut:

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

Variabler SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL bør se kjent ut – vi satte opp disse miljøvariablene tidligere. Med disse variablene vil vi kunne bruke verdiene i filen .gitlab-ci.yml mange ganger, og de trenger bare å oppdateres på ett sted.

Til slutt legger du til, forplikter og sender filen .gitlab-ci.yml på GitLab.

Kontrollerer utplasseringen

Hvis vi gjorde alt riktig, oppgaven deploy:dev vil kjøre vellykket i GitLab CI/CD og sende inn en commit .gitlab-ci.yml ved Pantheon. La oss ta en titt.

Sender tråder for sammenslåingsforespørsel til Pantheon

Her skal vi bruke min favoritt Pantheon-funksjon − multidev, hvor du kan lage flere Pantheon-miljøer for Git-grener på forespørsel.

Tilgang til multidev er begrenset, så denne delen kan hoppes over. Men hvis du har tilgang, kan du seriøst øke produktiviteten ved å sette opp automatisk oppretting av multidev-miljøer på Pantheon fra GitLab-sammenslåingsforespørsler.

La oss først lage en ny Git-gren lokalt ved å bruke git checkout -b multidev-support. La oss nå endre noe igjen .gitlab-ci.yml.

Jeg liker å inkludere sammenslåingsforespørselsnummeret i Pantheon-miljønavnet. For eksempel er den første sammenslåingsforespørselen mr-1, sekund - mr-2 etc.

Sammenslåingsforespørselen endres, så vi må dynamisk bestemme Pantheon-grennavnene. Det er enkelt på GitLab - du trenger bare å bruke forhåndsdefinerte miljøvariabler.

Vi kan ta $CI_MERGE_REQUEST_IIDfor å spesifisere sammenslåingsforespørselsnummeret. La oss bruke alt dette sammen med de globale miljøvariablene vi spesifiserte tidligere og legge til en ny deploy:multidev-oppgave på slutten av filen .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

Det vil ligne på vår oppgave deploy:dev, bare grenen sendes til Pantheon, ikke til master.

Vi har lagt til og forpliktet den oppdaterte filen .gitlab-ci.yml, og la oss nå skyve en ny gren til GitLab med git push -u origin multidev-support.

La oss nå lage en ny sammenslåingsforespørsel fra grenen multidev-supportved å trykke Opprett sammenslåingsforespørsel.

Etter å ha opprettet en sammenslåingsforespørsel, ser vi på hvordan CI/CD-oppgaven utføres deploy:multidev.

Se, en ny tråd er sendt til Pantheon. Men hvis vi går til multidev-delen på Pantheon-nettstedets dashbord, vil vi ikke se det nye miljøet der

La oss se på Git Branches-delen.

Som et resultat, vår tråd mr-1 kom til Pantheon. La oss skape et miljø fra en gren mr-1.

Vi har laget et multidev-miljø, la oss nå gå tilbake til GitLab og se på delen Drift > Miljøer. Vi vil se oppføringer for dev и mr-1.

Dette er fordi vi har lagt til en oppføring environment Med navn name и url inn i CI/CD-oppgaver. Hvis vi klikker på det åpne miljøikonet, vil vi bli ført til URL-en til multidev-miljøet på Pantheon.

Automatiser opprettelsen av multidev

I prinsippet kan du stoppe her og bare huske å lage et multidev-miljø for hver sammenslåingsforespørsel, men denne prosessen kan automatiseres.

Pantheon har et kommandolinjeverktøy Terminus, hvor du kan jobbe med plattformen automatisk. Terminus lar deg lage multidev-miljøer fra kommandolinjen - ideelt for GitLab CI.

Vi trenger en ny sammenslåingsforespørsel for å teste dette. La oss lage en ny gren ved å bruke git checkout -b auto-multidev-creation.

For å bruke Terminus i GitLab CI/CD-oppgaver trenger du et maskintoken for autentisering med Terminus og et containerbilde med Terminus.

Opprette et Pantheon Machine Token, lagre den på et trygt sted og legg den til som en global miljøvariabel i GitLab med navnet PANTHEON_MACHINE_TOKEN.

Hvis du har glemt hvordan du legger til GitLab-miljøvariabler, gå tilbake til der vi definerte PANTHEON_SITE.

Opprette en dockerfil med Terminus

Hvis du ikke bruker Docker eller ikke liker filer Dockerfile, ta bildet mitt registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest og hoppe over denne delen.

GitLab har et containerregister, hvor vi kan bygge og plassere Dockerfilen for prosjektet vårt. La oss lage en Dockerfile med Terminus for å jobbe med Pantheon.

Terminus er et PHP-kommandolinjeverktøy, så la oss starte med PHP-bildet. Jeg installerer Terminus gjennom Composer, så jeg bruker offisielle Docker Composer-bilde. Vi skaper Dockerfile i den lokale depotkatalogen med følgende innhold:

# 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ølg instruksjonene for å sette sammen og sende bilder fra seksjonen Bygg og push bilder в dokumentasjon for containerregisteretå samle et bilde fra Dockerfile og skyv den til GitLab.

Åpner seksjonen registret i GitLab-prosjektet. Hvis alt gikk etter planen, vil vårt image være der. Skriv ned en lenke til bildekoden - vi trenger den til filen .gitlab-ci.yml.

Seksjon script i problemet deploy:multidev begynner å vokse, så la oss flytte den til en egen fil. Opprett 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 er i en privat katalog og tillater ikke nettilgang til Pantheon. Vi har et skript for multidev-logikken vår. La oss nå oppdatere delen deploy:multidev fil .gitlab-ci.ymlslik at det blir slik:

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

Vi må sørge for at oppgavene våre utføres i det opprettede tilpassede bildet, så la oss legge til en definisjon image fra register-URL til .gitlab-ci.yml. Som et resultat endte vi opp med en fil som denne .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

Legg til, forplikt og send private/multidev-deploy.sh и .gitlab-ci.yml. Nå går vi tilbake til GitLab og venter på at CI/CD-oppgaven skal fullføres. Vær tålmodig: multidev kan ta flere minutter å lage.

Så går vi og ser på multidev-listen på Pantheon. Å mirakel! Multidev miljø mr-2 allerede her.

Konklusjon

Teamet mitt hadde mye mer moro da vi begynte å åpne sammenslåingsforespørsler og opprette miljøer automatisk.

Med de kraftige verktøyene til GitLab og Pantheon kan du koble GitLab til Pantheon automatisk.

Siden vi bruker GitLab CI/CD, vil arbeidsflyten vår ha plass til å vokse. Her er et par ideer for å komme i gang:

Legg til et byggetrinn.
Legg til automatisert testing.
Legg til en oppgave for å sikre at kodestandarder oppfylles.
Legge til dynamisk applikasjonssikkerhetstesting.

Fortell oss hva du synes om GitLab, Pantheon og automatisering.

PS Visste du at Terminus, Pantheons kommandolinjeverktøy, kan utvides via plugins?

Vi i Pantheon har gjort en god jobb med versjon 2 av vår plugin for Terminus byggeverktøy med GitLab-støtte. Hvis du ikke vil bry deg med innstillinger for hvert prosjekt, prøv denne plugin-en og hjelp oss med å teste v2-betaen. For Terminus-teamet build:project:create Du trenger bare et Pantheon-token og et GitLab-token. Hun vil distribuere et av eksempelprosjektene med Composer og automatisert testing, lage et nytt prosjekt i GitLab, en ny Pantheon-side, og koble dem sammen ved hjelp av miljøvariabler og SSH-nøkler.

Om forfatteren

Andrew Taylor lager verktøy for utviklere i Pantheon.

Kilde: www.habr.com

Hvordan koble GitLab og Pantheon og optimalisere Drupal og WordPress arbeidsflyter