Kaip prijungti „GitLab“ ir „Pantheon“ bei optimizuoti „Drupal“ ir „WordPress“ darbo eigas

Mūsų svečių kūrėjų įrankių kūrėjas Pantheon pasakoja apie tai, kaip automatizuoti WordPress diegimą naudojant GitLab CI / CD.

В Panteonas Dirbu kūrėjų ryšių srityje, todėl nuolat ieškau naujų būdų, kaip padėti „WordPress“ ir „Drupal“ kūrėjams išspręsti darbo eigos automatizavimo problemas. Norėdami tai padaryti, mėgstu eksperimentuoti su naujomis priemonėmis ir derinti jas tarpusavyje, kad veiktų efektyviai.

Dažnai matau, kaip kūrėjai kovoja su vienu sustojimo serveriu.

Malonu laukti savo eilės naudotis tarpiniu serveriu arba išsiųsti klientams URL su užrašu: „Žiūrėkite čia, bet dar nežiūrėkite čia“.

Multidev aplinkos - vienas iš šaunių Pantheon įrankių - išsprendžia šią problemą, nes su jais galite sukurti aplinką Git filialams pagal poreikį. Kiekviena „multidev“ aplinka turi savo URL ir duomenų bazę, todėl kūrėjai gali tyliai dirbti, tikrinti kokybę ir gauti patvirtinimą nesikišdami ant kojų.

Tačiau „Pantheon“ neturi versijų valdymo ar nuolatinio integravimo ir diegimo (CI / CD) įrankių. Tačiau tai lanksti platforma, su kuria galite integruoti bet kokius įrankius.

Taip pat pastebėjau, kad komandos kūrimui naudoja tam tikrus įrankius, o surinkimui ir diegimui – skirtingus.

Pavyzdžiui, jie turi skirtingus versijų valdymo ir CI/CD įrankius. Norėdami redaguoti kodą ir diagnozuoti problemas, turite suktis ir perjungti įrankius.

Apie GitLab yra visas kūrimo įrankių rinkinys: versijų valdymui, bilietams, sujungimo užklausoms, geriausias klasėje CI/CD konvejeris, konteinerių registras ir viskas. Dar nesu susidūręs su programa, kuri pasiūlytų tiek daug jūsų kūrimo darbo eigai valdyti.

Mėgstu automatizavimą, todėl sužinojau, kaip prijungti „Pantheon“ prie „GitLab“, kad įsipareigojimai pagrindinei „GitLab“ šakai būtų perkeliami į pagrindinę „Pantheon“ kūrimo aplinką. Ir sujungimo užklausos „GitLab“ gali sukurti ir įdiegti kodą „Pantheon“ daugiafunkcinėse aplinkose.

Šioje pamokoje paaiškinsiu, kaip nustatyti ryšį tarp „GitLab“ ir „Pantheon“ ir optimizuoti „WordPress“ bei „Drupal“ darbo eigą.

Žinoma, įmanoma, veidrodinė GitLab saugykla, bet mes darysime viską savo rankomis, kad pasigilintume „GitLab CI“ ir ateityje naudokite šį įrankį ne tik diegimui.

įvedimas

Šiam įrašui turite suprasti, kad „Pantheon“ kiekvieną svetainę suskaido į tris elementus: kodą, duomenų bazę ir failus.

Kodas apima TVS failus, tokius kaip „WordPress“ branduolys, papildiniai ir temos. Šie failai yra tvarkomi Git saugyklos, priglobtas Pantheon, o tai reiškia, kad galime įdiegti kodą iš GitLab į Pantheon su Git.
Failai Panteone yra medijos failai, tai yra svetainės vaizdai. Paprastai juos įkelia vartotojai, o „Git“ jų nepaiso.

Sukurti nemokamą paskyrą, sužinokite daugiau apie Panteono darbo eiga arba užsiregistruoti demo adresu pantheon.io.

Prielaidos

Mano projektas Pantheon ir GitLab vadinasi pantheon-gitlab-blog-demo. Projekto pavadinimas turi būti unikalus. Čia dirbsime su „WordPress“ svetaine. Galite naudoti Drupal, bet turėsite pakeisti kai kuriuos dalykus.

naudosiu Git komandų eilutęir tu gali dirbti grafinę sąsają, jeigu nori.

Sukurti projektą

Pirma, sukurkime GitLab projektas (prie to grįšime vėliau).

dabar sukurti „WordPress“ svetainę „Pantheon“.. Tada įdiegiame „WordPress“ svetainės prietaisų skydelyje.

Jei rankos niežti ką nors pakeisti, pavyzdžiui, pašalinti ar pridėti priedų, būkite kantrūs. Svetainė dar neprijungta prie „GitLab“ ir norime, kad visi kodo pakeitimai būtų atlikti per „GitLab“.

Įdiegę „WordPress“, grįžkite į „Pantheon“ svetainės informacijos suvestinę ir pakeiskite kūrimo režimą į „Git“.

Pradinis įsipareigojimas „GitLab“.

Dabar turite perkelti pradinį „WordPress“ kodą iš „Pantheon“ svetainės į „GitLab“. Norėdami tai padaryti, mes klonuojame kodą iš „Pantheon“ svetainės „Git“ saugyklos vietoje ir išsiunčiame jį į „GitLab“ saugyklą.

Kad būtų lengviau ir saugiau, pridėkite SSH raktą į Panteoną ir mums nereikės įvesti slaptažodžio kiekvieną kartą, kai klonuojame Pantheon Git saugyklą. Jau tuo pačiu metu pridėkite SSH raktą į „GitLab“..

Norėdami tai padaryti, klonuokite „Pantheon“ svetainę vietoje, nukopijuodami komandą iš svetainės prietaisų skydelio lauko „Klonavimas naudojant Git“.

Jei reikia pagalbos, perskaitykite dokumentaciją pradedant naudoti „Git for Pantheon“..

Dabar pasikeiskime git remote originnurodyti į GitLab, o ne į Panteoną. Tai galima padaryti командой git remote.

Eikime į „GitLab“ projektą ir nukopijuokite saugyklos URL iš išskleidžiamojo meniu „Klonas“ projekto išsamios informacijos puslapyje. Pasirinkime parinktį Clone with SSH, nes SSH raktą jau sukonfigūravome.

Pagal nutylėjimą git remote vietinei kodų saugyklos kopijai - origin. Tai galima pakeisti c git remote set-url origin [URL репозитория GitLab], kur vietoj skliaustų įrašome tikrąjį URL.

Galiausiai paleidžiame git push origin master --forceNorėdami perkelti „WordPress“ kodą iš „Pantheon“ į „GitLab“.

Parinktis –force reikalinga tik vieną kartą. Tada komandose git push tai nebus „GitLab“.

Kredencialų ir kintamųjų nustatymas

Prisiminkite, kaip mes pridėjome SSH raktą vietoje, kad galėtumėte prisijungti prie Pantheon ir GitLab? SSH prieigos raktas gali būti naudojamas autorizuojant „GitLab“ ir „Pantheon“.

„GitLab“ turi puikią dokumentaciją. Pažiūrėkime skyrių apie SSH raktus, kai naudojate Docker vykdytoją dokumente apie SSH raktų naudojimą su GitLab CI / CD.

Dabar atliksime pirmuosius du veiksmus: Sukurkime naują SSH raktų porą vietoje su ssh-keygen ir pridėkite privatų raktą kaip kintamąjį prie projekto.

Tada paklausim SSH_PRIVATE_KEY kaip GitLab CI/CD aplinkos kintamasis projekto nustatymuose.
Trečiame ir ketvirtame žingsniuose sukursime failą .gitlab-ci.yml su tokiu turiniu:

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"

Dar neįpareigokime failo .gitlab-ci.yml, tada turėsite pridėti ką nors kita.

Dabar atliekame penktą žingsnį ir pridėkite viešąjį raktą, kurį sukūrėte atlikdami pirmąjį veiksmą, prie paslaugų, prie kurių jums reikia prieigos kūrimo aplinkoje.

Mūsų atveju norime pasiekti „Pantheon“ iš „GitLab“. Vykdome Panteono dokumente pateiktas instrukcijas SSH rakto pridėjimas prie Panteono ir atlikite šį veiksmą.

Atminkite: privatus SSH yra „GitLab“, atviras SSH yra Panteone.

Nustatykime dar kelis aplinkos kintamuosius. Pirmasis vadinamas PANTHEON_SITE. Jo reikšmė yra jūsų įrenginyje esančios Panteono svetainės pavadinimas.

Įrenginio pavadinimas pateikiamas komandos Clone with Git pabaigoje. Jūs jau klonavote svetainę vietoje, todėl tai bus vietinės saugyklos katalogo pavadinimas.

Tada nustatykime aplinkos kintamąjį PANTHEON_GIT_URL. Tai yra „Pantheon“ svetainės „Git“ saugyklos URL, kurį jau naudojome.

Įveskite tik SSH saugyklos URL, be git clone ir svetainės pavadinimą mašinos pabaigoje.

pfu. Tai padaryta, dabar galime baigti failą .gitlab-ci.yml.

Sukurkite diegimo užduotį

Tai, ką iš pradžių darysime su „GitLab CI“, labai panašu į tai, ką anksčiau darėme su „Git“ saugyklomis. Tačiau šį kartą pridėkime „Pantheon“ saugyklą kaip antrą nuotolinį „Git“ šaltinį, o tada perkelkime kodą iš „GitLab“ į „Pantheon“.

Norėdami tai padaryti, sukonfigūruokite etapas deploy и užduotis deploy:dev, nes diegsime į Panteono kūrimo aplinką. Gautas failas .gitlab-ci.yml atrodys taip:

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

Kintamieji SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL turėtų atrodyti pažįstamai – šiuos aplinkos kintamuosius nustatėme anksčiau. Su šiais kintamaisiais galėsime naudoti failo reikšmes .gitlab-ci.yml daug kartų, o juos atnaujinti reikės tik vienoje vietoje.

Galiausiai pridėkite, įsipareigokite ir išsiųskite failą .gitlab-ci.yml „GitLab“.

Dislokacijos tikrinimas

Jei viską padarėme teisingai, užduotis deploy:dev sėkmingai veiks GitLab CI / CD ir pateiks įsipareigojimą .gitlab-ci.yml Panteone. Pažiūrėkime.

Siunčiamos sujungimo užklausos gijos į Panteoną

Čia naudosime mano mėgstamą Panteono funkciją − multidev, kur pagal poreikį galite sukurti papildomų Pantheon aplinkų Git filialams.

Prieiga prie multidev yra ribota, todėl šį skyrių galima praleisti. Bet jei turite prieigą, galite rimtai padidinti produktyvumą nustatydami automatinį daugiafunkcinių aplinkų kūrimą „Pantheon“ iš „GitLab“ sujungimo užklausų.

Pirmiausia sukurkime naują „Git“ filialą vietoje, naudodami git checkout -b multidev-support. Dabar vėl ką nors pakeisime .gitlab-ci.yml.

Man patinka įtraukti sujungimo užklausos numerį į Pantheon aplinkos pavadinimą. Pavyzdžiui, pirmoji sujungimo užklausa yra mr-1, antras - mr-2 ir tt

Sujungimo užklausa keičiasi, todėl turime dinamiškai nustatyti Panteono šakų pavadinimus. „GitLab“ tai paprasta – tereikia naudoti iš anksto nustatyti aplinkos kintamieji.

Galime paimti $CI_MERGE_REQUEST_IIDnorėdami nurodyti sujungimo užklausos numerį. Taikykime visa tai kartu su anksčiau nurodytais pasauliniais aplinkos kintamaisiais ir failo pabaigoje pridėkime naują deploy:multidev užduotį .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

Tai bus panaši į mūsų užduotį deploy:dev, tik filialas siunčiamas į Panteoną, o ne į master.

Pridėjome ir patvirtinome atnaujintą failą .gitlab-ci.yml, o dabar perkelkime naują „GitLab“ šaką su git push -u origin multidev-support.

Dabar sukurkime naują sujungimo užklausą iš filialo multidev-supportpaspausdami Sukurti sujungimo užklausą.

Sukūrę sujungimo užklausą, žiūrime, kaip vykdoma CI/CD užduotis deploy:multidev.

Žiūrėkite, Panteonui buvo išsiųsta nauja tema. Bet jei eisime į „Multidev“ skyrių „Pantheon“ svetainės prietaisų skydelyje, naujos aplinkos ten nematysime.

Pažvelkime į skyrių „Git Branches“.

Dėl to mūsų siūlas mr-1 pateko į Panteoną. Kurkime aplinką iš šakos mr-1.

Sukūrėme multidev aplinką, dabar grįžkime į GitLab ir pažiūrėkime į skyrių Operacijos > Aplinkos. Matysime įrašus už dev и mr-1.

Taip yra todėl, kad pridėjome įrašą environment Su vardu name и url į CI/CD užduotis. Jei spustelėsime atviros aplinkos piktogramą, pateksime į Pantheon daugiafunkcinės aplinkos URL.

Automatizuoti multidev kūrimą

Iš esmės galite čia sustoti ir tiesiog nepamirškite sukurti multidev aplinkos kiekvienai sujungimo užklausai, tačiau šis procesas gali būti automatizuotas.

Pantheon turi komandinės eilutės įrankį Galinė stotis, kur galite dirbti su platforma automatiškai. „Terminus“ leidžia kurti multidev aplinkas iš komandinės eilutės – idealiai tinka „GitLab CI“.

Mums reikia naujos sujungimo užklausos, kad galėtume tai išbandyti. Sukurkime naują filialą naudodami git checkout -b auto-multidev-creation.

Norint naudoti „Terminus“ atliekant „GitLab“ CI / CD užduotis, reikalingas mašinos prieigos raktas, skirtas autentifikuoti naudojant „Terminus“, ir konteinerio vaizdas su „Terminus“.

Panteono mašinos žetono kūrimas, išsaugokite jį saugioje vietoje ir pridėkite kaip pasaulinį aplinkos kintamąjį „GitLab“ su pavadinimu PANTHEON_MACHINE_TOKEN.

Jei pamiršote, kaip pridėti „GitLab“ aplinkos kintamuosius, grįžkite ten, kur apibrėžėme PANTHEON_SITE.

„Dockerfile“ sukūrimas naudojant „Terminus“.

Jei nenaudojate „Docker“ arba jums nepatinka failai Dockerfile, paimk mano atvaizdą registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest ir praleiskite šį skyrių.

„GitLab“ turi konteinerių registrą, kur galime sukurti ir patalpinti mūsų projekto Dockerfile. Sukurkime „Dockerfile“ su „Terminus“, kad dirbtume su „Pantheon“.

Terminus yra PHP komandinės eilutės įrankis, todėl pradėkime nuo PHP vaizdo. Diegiu „Terminus“ per „Composer“, todėl naudosiu oficialus „Docker Composer“ vaizdas. Mes kuriame Dockerfile vietinės saugyklos kataloge su tokiu turiniu:

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

Vykdykite vaizdų surinkimo ir siuntimo instrukcijas iš skyriaus Kurkite ir stumkite vaizdus в konteinerio registro dokumentusrinkti vaizdą iš Dockerfile ir nustumkite jį į „GitLab“.

Atidarykite skyrių registras projekte „GitLab“. Jei viskas vyko pagal planą, mūsų įvaizdis bus ten. Užsirašykite nuorodą į vaizdo žymą – jos mums reikia failui .gitlab-ci.yml.

Skyrius script problemoje deploy:multidev pradeda augti, todėl perkelkime jį į atskirą failą. Sukurkite naują failą 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

Scenarijus yra privačiame kataloge ir neleidžia interneto prieigos prie Panteono. Turime savo multidev logikos scenarijų. Dabar atnaujinkime skyrių deploy:multidev failą .gitlab-ci.ymlkad viskas pasirodytų taip:

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

Turime įsitikinti, kad mūsų užduotys atliekamos sukurtame tinkintame paveikslėlyje, todėl pridėkime apibrėžimą image iš registro URL į .gitlab-ci.yml. Dėl to mes gavome tokį failą .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

Pridėti, įsipareigoti ir siųsti private/multidev-deploy.sh и .gitlab-ci.yml. Dabar grįžtame į „GitLab“ ir laukiame, kol bus baigta CI / CD užduotis. Būkite kantrūs: „Multidev“ kūrimas gali užtrukti kelias minutes.

Tada pažiūrėkime į „Multidev“ sąrašą Panteone. O stebuklas! Multidev aplinka mr-2 jau čia.

išvada

Mano komandai buvo daug smagiau, kai pradėjome automatiškai atidaryti sujungimo užklausas ir kurti aplinkas.

Naudodami galingus „GitLab“ ir „Pantheon“ įrankius galite automatiškai prijungti „GitLab“ prie „Pantheon“.

Kadangi naudojame GitLab CI / CD, mūsų darbo eiga turės kur augti. Štai keletas idėjų, kurios padės jums pradėti:

• Pridėkite kūrimo žingsnį.
• Pridėkite automatinį testavimą.
• Pridėkite užduotį, kad įsitikintumėte, jog laikomasi kodo standartų.
• Papildyti dinaminės programos saugumo testavimas.

Praneškite mums, ką manote apie „GitLab“, „Pantheon“ ir automatizavimą.

PS Ar žinojote, kad Terminus, Panteono komandų eilutės įrankis, galima išplėsti naudojant papildinius?

Mes, Pantheon, atlikome gerą darbą kurdami 2 versiją Terminus kūrimo įrankių papildinys su GitLab palaikymu. Jei nenorite rūpintis kiekvieno projekto nustatymais, išbandykite šį papildinį ir padėkite mums išbandyti v2 beta versiją. „Terminus“ komandai build:project:create Jums reikia tik Pantheon žetono ir GitLab žetono. Ji įdiegs vieną iš pavyzdinių projektų su „Composer“ ir automatiniu testavimu, sukurs naują projektą „GitLab“, naujoje „Pantheon“ svetainėje, ir sujungs juos naudodama aplinkos kintamuosius ir SSH raktus.

Apie Autorius:

Andrew Taylor kuria įrankius kūrėjams Panteonas.

Šaltinis: www.habr.com