Kuidas ühendada GitLab ja Pantheon ning optimeerida Drupal ja WordPress töövooge

Meie külaline, Pantheoni arendustööriistade looja, räägib, kuidas automatiseerida WordPressi juurutamist GitLabi CI/CD abil.

V Pantheon Ma tegelen arendajate suhetega, seega otsin alati uusi viise, kuidas aidata WordPressi ja Drupal'i arendajatel automatiseerimistööprotsessides probleeme lahendada. Selleks armastan ma eksperimenteerida uute tööriistadega ja kombineerida neid üksteisega efektiivseks tööks.

Ma näen sageli, kuidas arendajad vaevlevad ühe vaheserveriga.

See ei ole just meeldiv — oodata oma järjekorda vaheserveri kasutamiseks või saata klientidele URL, millel on märge: 'Siit vaata, ja siit mitte'.

Multidev keskkonnad — üks Pantheoni ägedamaid tööriistu — lahendab selle probleemi, kuna nende abil saab nõudmisel luua keskkondi Git'i harude jaoks. Igal multidev keskkonnal on oma URL ja andmebaas, seega saavad arendajad rahulikult töötada, kvaliteeti kontrollida ja heakskiitu saada, üksteisele jalgu astumata.

Kuid Pantheonil puuduvad versioonikontrolli või pideva integreerimise ja juurutamise (CI/CD) tööriistad. Siiski on see paindlik platvorm, millega saab integreerida mis tahes tööriistu.

Olen ka märganud, et arendusteam kasutab arendamiseks ühte tööriistade komplekti, kuid koostamiseks ja juurutamiseks teist.

Näiteks on neil erinevad tööriistad versioonikontrolliks ja CI/CD-ks. Tuleb koos töötada ja vahetada tööriistu, et koodi redigeerida ja probleeme isoleerida.

VDS-l on võimalik installida: GitLab Seal on täielik tööriistade komplekt arenduseks: versioonikontroll, piletihaldus, merge-päringud, parim oma klassis CI/CD pipeline, konteinerite register ja kõik selline. Ma pole veel kohanud rakendusi, millel oleks nii palju arendustöövoo haldamiseks.

Ma armastan automatiseerimist, seega uurisin, kuidas ühendada Pantheon GitLabiga, et commid põhiharusse GitLabis oleksid juurutatud Pantheoni põhikeskkonnas. Samuti saavad GitLabis merge-päringud luua ja juurutada koodi Pantheoni multidev keskkondadesse.

Selles juhendis räägin, kuidas seadistada ühendus GitLabi ja Pantheoni vahel ning optimeerida WordPressi ja Drupal'i töövoogu.

Muidugi, saab GitLabi hoidlat peegeldada,, kuid teeme kõik käsitsi, et uurida, kuidas GitLab CI ja tulevikus kasutada seda tööriista mitte ainult juurutamiseks.

Sissejuhatus

Selle postituse jaoks on oluline mõista, et Pantheon jagab iga saidi kolmeks elemendiks: kood, andmebaas ja failid.

Kood hõlmab CMS-faile, näiteks WordPressi tuuma, pluginaid ja teemasid. Need failid hallatakse Git repoteooriumis, mis asub Pantheonis, võimaldades meil deponeerida koodi GitLabist Pantheoni Git'i.
Failid Pantheonil viitavad meediafailidele, st saidi piltidele. Tavaliselt laadivad neid üles kasutajad, ja Git ignoreerib neid.

Loo tasuta konto, saa rohkem teada Pantheoni töövoost või registreeru demole aadressil pantheon.io.

Eeldused

Minu projekt Pantheonil ja GitLabis kannab nime pantheon-gitlab-blog-demo. Projekti nimi peab olema ainulaadne. Siin töötame WordPressi saidiga. Võib kasutada ka Drupalit, kuid mõningaid muudatusi on vaja teha.

Kasutan Git käsurealiidest, aga saate töötada graafilises kasutajaliideses, kui soovite.

Loome projekti

Esiteks loome GitLabi projekti (selle juurde tuleme hiljem).

Nüüd loome WordPressi saidi Pantheonil. Siis installime WordPressi saidi armatuurlauale.

Kui tunnete, et midagi tuleks muuta, näiteks pluginad eemaldada ja uusi lisada, siis kannatage. Veebisait ei ole veel ühendatud GitLabi, kuid soovime, et kõik koodimuudatused läheksid läbi GitLabi.

Kui oleme WordPressi installinud, naasma Pantheoni saidi juhtpaneelile ja muudame arenduse režiimi Git-iks.

Esimene commit GitLabis

Nüüd tuleb algne WordPressi kood Pantheoni saidilt GitLabi edastada. Selle jaoks kloonime koodi Pantheoni saidi Git repolt kohalikku masinasse ja seejärel saadame GitLabi.

Kergemaks ja turvalisemaks muutmiseks, lisame SSH-võtme Pantheoni ja ei pea iga kord parooli sisestama, kui kloonime Pantheoni Git repolt. Samuti lisame SSH-võtme GitLabi.

Selleks kloonime Pantheoni saidi kohalikult, kopeerides käsu saidi juhtpaneeli Clone with Git väljalt.

Kui vajate abi, lugege dokumentatsiooni Gitiga töö alustamiseks Pantheoniga.

Nüüd muudame git remote origin, et suunata GitLabi asemel Pantheoni. Seda saab teha git remote käsuga.

Liigume GitLabi projekti ja kopeerime reposi URL-i projekti detailide lehe Clone avanevast loendist. Valime Clone with SSH variandi, kuna oleme juba SSH-võtme seadistanud.

Vaikimisi git remote kohaliku koodirepositooriumi jaoks — origin. Seda saab muuta c git remote set-url origin [GitLabi hoidla URL], kus sulgude asemel sisestame tegeliku URLi.

Lõ finally, käivitame git push origin master --force, et saata WordPressi kood Pantheoni veebisaidilt GitLabi.

Parameeter –force on vajalik ainult üks kord. Seejärel ei ole seda käsus git push GitLabis.

Seame üles mandaadid ja muutujad

Kas mäletate, kuidas me kohalikult lisasime SSH-võtme, et autentida end Pantheonil ja GitLabis? SSH-tokenit saab kasutada GitLabis ja Pantheonil autentimiseks.

GitLabis on suurepärane dokumentatsioon. Vaadakem ripatsi SSH-võtmetest Docker-executorit kasutamise dokumendis GitLab CI/CD SSH võtmete kasutamise kohta.

Käesoleval hetkel täidame esimesed kaks sammu: loome uue SSH-võtme paari kohalikult ssh-keygen'iga ja lisame privaatvõtme projekti muutujaks.

Seejärel seadistame SSH_PRIVATE_KEY kuidas GitLab CI/CD keskkonnamuutujaks projekti seadetes.
Kolmandal ja neljandal sammul loome faili .gitlab-ci.yml sellise sisuga:

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

Ärme pakuge faili veel commit'ida .gitlab-ci.yml, see sellele tuleb veel midagi lisada.

Nüüd liigume viienda sammu juurde ja lisame avaliku võtme, mille lõime esimeses sammus, teenustele, millele vajame ligipääsu koostamiskeskkonnas..

Meie juhul soovime saada GitLabist ligipääsu Pantheoni. Järgime dokumentis Pantheon olevaid juhiseid SSH-võtme lisamiseks Pantheoni ja teeme selle sammu.

Pea meeles: privaatne SSH on GitLabis, avalik Pantheonis.

Seame veel mõned keskkonnamuutujad. Esimene kannab nime PANTHEON_SITE. Selle väärtus on Pantheoni saidi nimi teie arvutis.

Nimi arvutis on näidatud Gitiga kloonimise käsu lõpus. Olete juba saidi lokaalselt klooninud, nii et see on kohalikku repositooriumi katalooge nimi.

Seejärel seadistame keskkonnamuutuja PANTHEON_GIT_URL. See on Pantheoni saiti Git-repositooriumi URL, mida oleme juba kasutanud.

Sisestame ainult repositooriumi SSH URL-i, ilma git clone ja saidi nime arvutis lõpus.

Huh. Meie pool on tehtud, nüüd saame lõpetada meie faili. .gitlab-ci.yml.

Loome deploy-ülesande.

See, mida me esialgsel ajal GitLab CI-ga teeme, on väga sarnane sellele, mida me tegime varem Git-repositooridega. Kuid seekord lisame Pantheoni repositooriumi teiseks kaugseks Git-allikaks ja seejärel saadame koodi GitLabist Pantheoni.

Selleks seadistame etapp deploy ja ülesanne deploy:dev, kuna me deployime arenduskeskkonda Pantheonis. Tulemuseks on fail .gitlab-ci.yml näeb välja järgmiselt:

stages:
- deploy

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

Muutujad SSH_PRIVATE_KEY, PANTHEON_SITE ja PANTHEON_GIT_URL peavad olema tuttavad — me oleme need keskkonnaväärused varem seadistanud. Nende muutujatega saame kasutada väärtusi failis .gitlab-ci.yml korduvalt, ja neid tuleb uuendada vaid ühes kohas.

Lõpuks lisame, salvestame ja saadame faili .gitlab-ci.yml GitLabi.

Kontrollime deploy'd

Kui oleme kõik õigesti teinud, siis ülesanne deploy:dev täidetakse edukalt GitLab CI/CD-s ja saadab commit'i .gitlab-ci.yml Pantheoni. Vaatame üle.

Saadame mergenõuete harud Pantheoni

Siin kasutame oma lemmikfunktsiooni Pantheonis — multidev, kus saab nõudmisel luua täiendavaid Pantheoni keskkondi Git'i harude jaoks.

Juhtimine multidev'i on piiratud, nii et seda osa ei pea täitma. Kuid kui teil on juurdepääs, saab tõhusust tõsiselt suurendada, seadistades Pantheoni multidevi keskkondade automaatse loomise GitLabi mergikutsest.

Esiteks loome kohalikult uue Git haru kasutades git checkout -b multidev-support. Nüüd muudame taas midagi .gitlab-ci.yml.

Mulle meeldib märkida Pantheoni keskkonna nime sisse mergikutse number. Näiteks esimene mergikuts mr-1, teine mr-2 jne.

Mergikutse muutub, seega peame dünaamiliselt määrama Pantheoni harude nimed. GitLabis on see lihtne – tuleb kasutada etteantud keskkonnavariante.

Saame võtta $CI_MERGE_REQUEST_IID, et märkida mergikutse number. Rakendame seda nüüd koos varem määratud globaalsete keskkonnavariante ning lisame faili lõppu uue ülesande deploy:multidev .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:
    # Kontrolli mergikutse lähteharu
    - git checkout $CI_COMMIT_REF_NAME
    # Lisa Pantheoni git-repositoorium täiendava kaug-koduna
    - git remote add pantheon $PANTHEON_GIT_URL
    # Suru mergikutse lähteharu Pantheoni
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  only:
    - merge_requests

See sarnaneb meie ülesandele deploy:dev, ainult haru saadetakse Pantheoni, mitte master.

Lisame ja kinnitame uuendatud faili .gitlab-ci.yml, ja nüüd saadame uue haru GitLabi git push -u origin multidev-support.

Nüüd loome uue mergenõude harust multidev-support, vajutades Loo mergenõue.

Mergenõude loomise järel vaatame, kuidas CI/CD ülesanne täitub deploy:multidev.

Näete — Pantheoni on saadetud uus haru. Kuid kui läheme Pantheoni saidi armatuurlaual jaotisse multidev, ei näe me seal uut keskkonda

Vaadakem jaotist Git Branches.

Seega, meie haru mr-1 on jõudnud Pantheoni. Loome harust keskkonna mr-1.

Loomise käigus lõime me multidevi keskkonna, nüüd pöördume tagasi GitLabi ja vaata jaotist Operations > Keskkonnad. Näeme kirjeid dev ja mr-1.

See on sellepärast, et lisasime kirje environment nimega name ja url CI/CD ülesannetes. Kui vajutada avatud keskkonna ikoonile, läheme multidevi keskkonna URL-ile Pantheonil.

Automatiseerime multidevi loomise

Põhimõtteliselt võib sellega piirduda ja lihtsalt mitte unustada iga mergenõude jaoks multidevi keskkonda luua, kuid seda protsessi saab automatiseerida.

Pantheonil on käsurea tööriist Terminus, mille kaudu saab automaatselt töötada platvormiga. Terminuses saab luua multidevi keskkondi käsurealt — ideaalselt. GitLab CI.

Me vajame uut ühendamise päringut, et seda testida. Loome uue haru koos git checkout -b auto-multidev-creation.

GitLab CI/CD ülesannetes Terminuse kasutamiseks on vajalik masinatoken autentimiseks Terminuses ja konteineripilt Terminusega.

Loome Pantheoni masinatokeni, salvestame selle turvalisse kohta ja lisame kui globaalset keskkonnavarianti GitLabis nimega PANTHEON_MACHINE_TOKEN.

Kui olete unustanud, kuidas keskkonnavarbe lisada GitLabis, minge tagasi sinna, kus me määratlesime PANTHEON_SITE.

Loome Dockerfile'i Terminusega

Kui te ei kasuta Dockerit või ei armasta faile Dockerfile, võtke minu pilt registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest ja jätke see osa vahele.

GitLabis on konteineriregister, kus saab ehitada ja majutada Dockerfile'i meie projekti jaoks. Loome Dockerfile'i Terminusega, et töötada Pantheoniga.

Terminus on PHP käsurea tööriist, nii et alustame PHP pildist. Installin Terminuse läbi Composer'i, seega võtan aluseks ametliku Docker Composer'i pildi. Loome Dockerfile kohalikus repository's sellise sisuga:

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

Järgime konteineriregistri dokumentatsiooni jaehitamise ja saatmise juhiseid Build and push images ühes sektsioonist, et luua pilt, et luua pilt Dockerfile ja ja GitLabi.

Avame jaotis Registry GitLabis. Kui kõik läks plaanipäraselt, siis seal on meie pilt. Salvestage link kujundi sildile — see on meile vajalik failis .gitlab-ci.yml.

Jaotis script ülesandes deploy:multidev hakkab kasvama, seega viige see eraldi faili. Loome uue faili 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

Skript asub privaatsetes kataloogides ja ei anna veebipõhist juurdepääsu Pantheonis. Meil on skript meie multidev loogika jaoks. Vaatame nüüd, et uuendame jaotist deploy:multidev faile .gitlab-ci.yml, et see välja näeks nii:

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äivita multidev juurutusskript
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Peame veenduma, et meie ülesandeid täidetakse loodud kohandatud kujundis, seega lisame määratlemise pilt registri URL-iga .gitlab-ci.yml. Tulemuseks on meil selline fail .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Vaata 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äivita multidev deploy skript
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Lisame, kinnitame ja saadame private/multidev-deploy.sh ja .gitlab-ci.yml. Nüüd naaseme GitLabi ja ootame, kuni CI/CD ülesanne täidetakse. Palun natuke kannatust: multidev võib loodud saada mitu minutit.

Siis vaatame Pantheoni multidev nimekirja. O imet! Multidev keskkond mr-2 on juba siin.

Kokkuvõte

Minu meeskond töötab palju toredamalt, kui hakkasime avama mergenõudeid ja looma keskkondi automaatselt.

Tugevate GitLabi ja Pantheoni tööriistadega saab GitLabi automaatselt Pantheoni siduda.

Kuna kasutame GitLab CI/CD-d, on meie tööprotsessil palju kasvu. Siin on paar ideed, millega alustada:

• Lisa ehitusetapp.
• Lisage automatiseeritud testimine.
• Lisage ülesanne, et tagada koodistandardite järgimine.
• Lisage rakenduste turvatestimise dünaamiline testimine.

Kirjutage, mida arvate GitLabist, Pantheonist ja automatiseerimisest.

P.S. Kas te teadsite, et Terminus, Pantheoni käsurea tööriist, on laiendatav pluginate kaudu?

Me Pantheonis oleme teinud head tööd meie v2 versiooniga Terminusi ehitustööriistade pluginast GitLabi toega. Kui te ei soovi iga projekti seadistamisega vaeva näha, proovige seda pluginat ja aidake meil beta v2 testida. Terminuse meeskonnale build:project:create vajatakse ainult Pantheoni tokenit ja GitLabi tokenit. See käivitab ühe näidisprojekti koos Composeriga ja automatiseeritud testimisega, loob uue projekti GitLabis, uue Pantheoni saidi ning ühendab need keskkonnamuutujate ja SSH-võtmete kaudu.

Autorist

Andrew Taylor loob arendajatele tööriistu Pantheon.

Allikas: habr.com