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

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

Uues Pantheon Ma tegelen arendajate suhetega, seetõttu otsin alati uusi viise, kuidas aidata WordPressi ja Drupaliga töötavatel arendajatel lahendada automatiseerimisega seotud probleeme oma töövoogudes. Seetõttu armastan ma katsetada uusi tööriistu ja neid omavahel kombineerida tõhusaks tööks.

Ma näen sageli, kuidas arendajad vaevlevad ühe vahe-serveriga.

See pole just meeldiv - oodata oma korda, et kasutada vahe-serverit, või saata klientidele URL, millel on märge: "Siit vaata, siia aga mitte".

Multidevi keskkonnad — üks Pantheoni ägedamaid tööriistu — lahendab selle probleemi, kuna nende abil saab vajaduse korral luua keskkondi Git'i harude jaoks. Igal multidevi keskkonnal on oma URL ja andmebaas, mistõttu arendajad saavad rahulikult töötada, kvaliteeti kontrollida ja heakskiitu saada, üksteise kannul astumata.

Kuid Pantheonil pole versioonikontrolli ega pideva integreerimise ja juurutamise (CI/CD) tööriistu. Siiski on see paindlik platvorm, millega saab integreerida igasuguseid tööriistu.

Lisaks olen märganud, et meeskonnad kasutavad arendamiseks ühte tööriistade komplekti ning koostamise ja juurutamise jaoks teist.

Näiteks on neil versioonikontrolli ja CI/CD jaoks erinevad tööriistad. Peab tegema tülikat tööd ja vahetama tööriistu, et redigeerida koodi ja diagnoosida probleeme.

Pealehe GitLab on terve tööriistakomplekt arenduseks: versioonikontroll, piletid, mergenõuded, parim klassi CI/CD torujuhe, konteinerite register ja kõik selline. Ma pole veel kohanud rakendusi, kus oleks nii palju töövoo juhtimise tööriistu.

Armastan automatiseerimist, seetõttu õppisin, kuidas ühendada Pantheon GitLabiga, et GitLabis peaharu kommid juurutatakse Pantheoni peamises arenduskeskkonnas. Samuti saavad GitLabi mergenõuded luua ja juurutada koodi Pantheoni multidevi keskkondades.

Selles juhendis räägin, kuidas seadistada ühendust GitLabi ja Pantheoni vahel ning optimeerida WordPressi ja Drupaliga seotud töövoogu.

Ma tean, et saab GitLabi arhiivi peegeldada, kuid me teeme kõik käsitsi, et uurida GitLab CI-d 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, nagu WordPressi tuum, pistikprogrammid ja teemad. Neid faile haldatakse Git reposis., mis on Pantheon'is hostitud, mis tähendab, et me saame koodi GitLabist Pantheoni Git'i kaudu juurdepääsuks.
Failide all Pantheon'is mõistetakse meediafaile, nagu veebisaidi pildid. Tavaliselt laadivad need üles kasutajad, ja Git need ignoreerib.

Looge tasuta konto, et saada rohkem teavet Pantheoni töövoo kohta. või Registreeru demokeskusele aadressil pantheon.io.

Eeldused

Minu projekt Pantheon'is ja GitLab's kannab nime pantheon-gitlab-blog-demo.Projektinimi peab olema ainulaadne. Siin töötame WordPressi saidiga. Saame kasutada ka Drupalit, kuid see nõuab mõningaid muudatusi.

Ma kasutan Git käsklust, aga saate töötada ka graafilises liideses,kui soovite.

Loo projekt

Esialgu loome GitLab projekti (sellest me räägime hiljem).

Nüüd loome WordPressi saidi Pantheon'is.Seejärel installime WordPressi saidi armatuurlauda.

Kui on soov midagi muuta, näiteks pistikprogramme eemaldada või lisada, siis pidage vastu. Saidil ei ole veel ühendust GitLab'iga ja me tahame, et kõik koodi muudatused toimuksid läbi GitLab'i.

Kui oleme WordPressi installinud, naaseme Pantheoni saidi armatuurlauda ja muudame arendustüübi Git-iks.

Esialgne Commit GitLab'is

Nüüd tuleb viia esialgne WordPressi kood Pantheoni saidilt GitLabi. Selleks kloonime koodi Pantheoni saidi Git repost kohalikult ja saadame seejärel GitLab'i reposse.

Seda lihtsamaks ja turvalisemaks muutmiseks lisame SSH-võtme Pantheon'i ja me ei pea iga kord parooli sisestama, kui kloonime Pantheoni Git repot. Kõrval oleme samuti lisanud SSH-võtme GitLabi..

Selleks kloonime Pantheoni saidi kohalikult, kopeerides käsu saidi armatuurlaudade Klooni kaudu Git.

Kui vajate abi, lugege dokumentatsiooni Pantheoni Gitiga alustamiseks..

Nüüd muudame git remote origin, et suunata GitLab'i Pantheoni asemel. Seda saab teha käsklusega git remote..

Liigume GitLab'i projekti ja kopeerime reposi URL-i rippmenüüst Klooni lehe projekti detailide lehe juures. Valime Kloonimiseks SSH variant, kuna oleme juba SSH-võtme seadistanud.

Vaikimisi git remote kohaliku koodi repo koopia jaoks - origin.Seda saab muuta käsuga git remote set-url origin [GitLab'i repo URL],kus sulgude asemele sisestame tegeliku URL-i.

Lõpuks käivitage git push origin master --force., etten WordPressi kood Pantheoni saidilt GitLabi.

Parameetrit –force on vaja ainult üks kord. Seejärel käskudes git push GitLabis seda ei ole.

Seadistame mandaadid ja muutujad

Kas mäletate, kuidas me kohapeal lisasime SSH-võtme, et autoriseeruda Pantheonis ja GitLabis? SSH-tokenit saab kasutada GitLabis ja Pantheonis autoriseerimiseks.

GitLabis on suurepärane dokumentatsioon. Vaata SSH-võtmete osa, kui kasutate Docker'i executorit SSH-võtmete kasutamise dokumendis GitLab CI/CD jaoks.

Praegu teeme kaks esimest sammu: loome uue SSH-võtme paari kohapeal ssh-keygen'i abil ja lisame privaatvõtme nagu muutuja projekti.

Siis määrame SSH_PRIVATE_KEY kuidas mujutu GitLab CI/CD keskkonnas projekti seadetes.
Kolmandas ja neljandas sammus 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 hetkel seda faili komiteeri .gitlab-ci.yml, hiljem tuleb sinna veel midagi lisada.

Nüüd teeme viienda sammu ja lisame avatud võtme, mille lõime esimeses sammus, teenustele, millele peate pääsema ehituskeskkonnas.

Meie puhul soovime GitLabist pääseda Pantheoni. Järgime Pantheoni dokumentatsioonis juhiseid SSH-võtme lisamiseks Pantheoni ja teeme selle sammu.

Pidage meeles: privaatne SSH on GitLabis, avatud Pantheonis.

Seadistame veel paar keskkonnamuutujat. Esimene kannab nime PANTHEON_SITE. Selle väärtus on Pantheoni saidi nimi teie masinas.

Nimi on masinas märgitud käsu „Clone with Git“ lõpus. Olete juba klooninud saidi kohapeal, nii et see on teie lokaalse repotüübi katalooge.

Seejärel seadistame keskkonnamuutujat PANTHEON_GIT_URL. See on Pantheoni saidi Git repotübi URL, mida oleme juba kasutanud.

Sisestame ainult repotübi SSH-URL-i, ilma git clone ja saidi nime masinas lõpus.

Uhh. Oleme selle lõpetanud, nüüd saame oma faili lõpetada .gitlab-ci.yml.

Loome rakenduse ülesande

See, mida me alguses GitLab CI-ga teeme, on väga sarnane sellele, mida me varem Git-repo tüüpidega tegime. Kuid seekord lisame Pantheoni repotüübi kui teise kaugse tagasiteenuse, ja siis saadame koodi GitLabist Pantheoni.

Selleks seadistame faasi deploy ja ülesanne deploy:dev, kuna me saame Pantheonis arenduskeskkonda. Järgnevalt näeb fail välja selline: .gitlab-ci.yml näeb välja nii:

etapid:
- juurutamine

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

juurutamine:dev:
  etapp: juurutamine
  keskkond:
    nimi: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  skript:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  ainult:
    - master

Muutujad SSH_PRIVATE_KEY, PANTHEON_SITE ja PANTHEON_GIT_URL peavad olema tuttavad - oleme need keskkonnaparameetrid varem seadistanud. Nende parameetrite abil saame kasutada väärtusi failis .gitlab-ci.yml korduvalt, ja neid tuleb uuendada ainult ühes kohas.

Lõpuks lisame, pühendame ja saadame faili .gitlab-ci.yml GitLabi.

Kontrollime juurutamist

Kui me kõik õigesti tegime, siis tööülesanne deploy:dev täidetakse edukalt GitLab CI/CD-s ja saadab commit'i .gitlab-ci.yml Pantheoni. Vaadake, kuidas see välja näeb.

Saadame muru-päringute harud Pantheoni

Siin kasutame oma lemmikfunktsiooni Pantheon'is - multidev, kus saab päringu alusel luua täiendavaid Pantheoni keskkondi Git'i harude jaoks.

Ligipääs multidev'ile on piiratud, seega võib seda jaotist vahele jätta. Kuid kui teil on ligipääs, saab oluliselt parandada efektiivsust, seadistades automaatse multidev keskkondade loomise Pantheonis GitLabi muru-päringutest.

Esiteks loome uue Git'i haru kohapeal, kasutades git checkout -b multidev-support. Nüüd muudame veel midagi .gitlab-ci.yml.

Mulle meeldib märkida muru-päringu numbrit Pantheoni keskkonna nimel. Näiteks esimene muru-päring - mr-1, teine - mr-2 jne.

Muru-päring muutub, seega peame dünaamiliselt määrama Pantheoni harude nimed. GitLab'is on see lihtne - peame kasutama eeldefineeritud keskkonnaparameetreid.

Saame kasutada $CI_MERGE_REQUEST_IID, et märkida muru-päringu number. Rakendame nüüd kõik see koos varem määratud globaalsete keskkonnaparameetritega ja lisame faili lõppu uue ülesande deploy:multidev .gitlab-ci.yml.

deploy:multidev:
  etapp: juurutamine
  keskkond:
    nimi: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  skript:
    # Kontrolli muru-päringu algset haru
    - git checkout $CI_COMMIT_REF_NAME
    # Lisa Pantheoni git'i hoidla lisaks
    - git remote add pantheon $PANTHEON_GIT_URL
    # Saada muru-päringu algne haru Pantheoni
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  ainult:
    - muru-päringud

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

Oleme lisanud ja pühendanud uuendatud faili .gitlab-ci.yml, ja nüüd saadame uue haru GitLab'i koos git push -u origin multidev-support.

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

Pärast mergenõude loomist vaatame, kuidas CI/CD ülesanne täidetakse deploy:multidev.

Vaadake - uue haru on saadetud Pantheoni. Kuid kui liigume Pantheoni saidi juhtpaneelil multidevi jaossa, ei näe me seal uut keskkonda

Vaadakem Git Branches jaost.

Kokkuvõttes sai meie haru mr-1 Pantheoni. Loome keskkonna harust mr-1.

Loomasime multidev keskkonna ja nüüd naeme tagasi GitLabi ja vaatame jaotust Operations > Environments. Näeme kirjeid dev ja mr-1.

See on tingitud sellest, et lisasime kirje keskkond nimega nimi ja url CI/CD ülesannetes. Kui vajutad avatud keskkonna ikoonile, suundume multidev keskkonna URL-ile Pantheonil.

Automatiseerime multidevi loomise

Põhimõtteliselt võiks sellega lõpetada ja lihtsalt mitte unustada luua multidevi keskkonda iga mergenõude jaoks, kuid seda protsessi on võimalik automatiseerida.

Pantheonil on käsurea tööriist Terminus, kus saab platvormiga automaatselt töötada. Terminuses saab luua multidevi keskkondi käsurealt - ideaalne GitLab CI-d.

Meil on vajalik uus mergenõue, et seda testida. Loome uue haru abil git checkout -b auto-multidev-creation.

Terminus kasutamiseks GitLabi CI/CD ülesannetes on vajalik masinatoken, et autentida Terminuses ja konteineripilt koos Terminusega.

Loome Pantheoni masinatokeni, salvestame selle turvalisse kohta ja lisame GitLabis globaalse keskkonnamuutujana nimega PANTHEON_MACHINE_TOKEN.

Kui unustasite, kuidas lisada GitLabi keskkonnamuutujaid, naaske sinna, kus me määratlesime PANTHEON_SITE.

Loome Dockerfile 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 konteinerite register, kus saab ehitada ja paigutada Dockerfile meie projektile. Loome Dockerfile'i Terminusega, et töötada Pantheoniga.

Terminus on PHP käsurea tööriist, seega alustame PHP pildiga. Paigaldan Terminuse Composeri kaudu, seega kasutan ametlikku Docker Compose'i pilti. Loome Dockerfile kohalikus hoidlas 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ärgige konteinerite registri dokumentatsiooni sektsiooni, et ehitada ja saata pilte Ehita ja saada pilte ja , et ehitada piltja saata see GitLabi. Dockerfile Avame jaotuse

Register GitLabi projektis. Kui kõik läks plaanipäraselt, on seal meie pilt. Kirjutage alla pildi sildi link - see on vajalik meie failile ülesandes .gitlab-ci.yml.

Jaotis script ülesandes deploy:multidev hakkab laienema, 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 privaatkaustas ja ei anna veebipöördumist Pantheoni. Meil on skript meie multidevi loogika jaoks. Uuendame nüüd jao deploy:multidev failist .gitlab-ci.yml, et see näeks välja 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 multidevi juurutusskript
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Peame veenduma, et meie ülesanded täidetakse loodud kohandatud pildis, seega lisame määratlemise image registri URL-iga .gitlab-ci.yml. Lõppkokkuvõttes saime sellise faili .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 multidevi juurutusskript
    - "/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 lõpetatakse. Oodake; multidevi võib luua paar minutit.

Siis vaatame Pantheonis multidevi nimekirja. O ime! Multidevi keskkond mr-2 on juba siin.

Kokkuvõte

Minu meeskond töötas palju rõõmsamalt, kui hakkasime avama ühendusettepanekuid ja looma keskkondi automaatselt.

Mugavate GitLabi ja Pantheoni tööriistade abil saab GitLabi automaatselt Pantheoniga ühendada.

Kuna me kasutame GitLab CI/CD, on meie tööprotsessil palju kasvuruumi. Siin on paar ideed, et alustada:

• Lisage koostamisetapp.
• Lisage automatiseeritud testimine.
• Lisage ülesanne, et tagada koodistandardeid.
• Lisage rakenduste dünaamiline turvatestimine.

Kirjutage, mida te arvate GitLabist, Pantheonist ja automatiseerimisest.

P.S. Kas teadsite, et Terminus, Pantheoni käsurealiides, võib laiendada pluginatega?

Me Pantheonil oleme kõvasti vaeva näinud Terminuse 2. versiooniga koostamise tööriistade plugina jaoks GitLabi toe toetab. Kui te ei soovi iga projekti seadistamisega vaeva näha, proovige seda pluginat ja aidake meil beetatestida v2. Terminus meeskonnale build:project:create on vajalik ainult Pantheoni ja GitLabi token. See rajab ühe näidisprojekti koos Composer'i ja automaatse testimisega, loob uue projekti GitLabis, uue saidi Pantheon'is ja ühendab need keskkonnamuutujate ja SSH-võtmete kaudu.

Autori kohta

Andrew Taylor loob arendustööriistu Pantheon.

Allikas: habr.com