Ako prepojiť GitLab s Pantheon a optimalizovať pracovné procesy Drupal a WordPress

Náš hosť, tvorca nástrojov pre vývojárov z Pantheon, vysvetľuje, ako automatizovať nasadenia WordPress pomocou GitLab CI/CD.

V Pantheon Pracujem v oblasti vzťahov s vývojármi, preto vždy hľadám nové spôsoby, ako pomôcť vývojárom WordPress a Drupal riešiť problémy s automatizáciou v pracovných procesoch. Preto rád experimentujem s novými nástrojmi a kombinuje ich navzájom na efektívnu prácu.

Často vidím, ako sa vývojári trápi s jedným medzi-serverom.

Nie je to príjemné čakať na svoju radu, aby sa mohol použiť medzi-server, alebo posielať klientom URL s označením: „Tu pozri, a tu zatiaľ nie.“

Odborné prostredia multidev — jeden z skvelých nástrojov Pantheon — riešia tento problém, pretože s nimi je možné na požiadanie vytvárať prostredia pre vetvy Git. Každé prostredie multidev má svoj URL a databázu, takže vývojári môžu pokojne pracovať, kontrolovať kvalitu a získať schválenie, aniž by si navzájom stúpali na prsty.

Ale Pantheon nemá nástroje pre správu verzií alebo kontinuálnu integráciu a nasadenie (CI/CD). Napriek tomu je to flexibilná platforma, s ktorou je možné integrovať akékoľvek nástroje.

Ešte som si všimol, že tímy používajú rôzne nástroje na vývoj a iné na kompiláciu a nasadenie.

Napríklad majú rôzne nástroje na správu verzií a CI/CD. Musia sa trápiť a prepínať medzi nástrojmi, aby upravili kód a diagnostikovali problémy.

Na GitLab Je tu kompletný súbor nástrojov pre vývoj: na správu verzií, tikety, m merge-requesty, najlepší vo svojej triede CI/CD pipeline, registrov kontajnerov a podobne. Zatiaľ som nenarazil na aplikácie, ktoré by mali toľko nástrojov na správu pracovného procesu vývoja.

Milujem automatizáciu, a preto som sa naučil, ako pripojiť Pantheon k GitLab, aby sa commity do hlavnej vetvy v GitLab nasadili do hlavného vývojového prostredia v Pantheon. A merge-requesty na GitLab môžu vytvárať a nasadzovať kód do prostredí multidev v Pantheon.

V tomto sprievodcovi vám ukážem, ako nastaviť pripojenie medzi GitLab a Pantheon a optimalizovať pracovný proces WordPress a Drupal.

Samozrejme, môžem zrkadliť repozitár GitLab, ale všetko budeme robiť ručne, aby sme sa dostali do GitLab CI a do budúcnosti využívali tento nástroj nielen na nasadenie.

Úvod

Pre tento príspevok je potrebné pochopiť, že Pantheon rozdeľuje každú stránku na tri prvky: kód, databázu a súbory.

Kód obsahuje súbory CMS, ako je jadro, pluginy a témy WordPress. Tieto súbory sú spravované v Git repozitári, ktorý je umiestnený na Pantheone, takže môžeme nasadiť kód z GitLab na Pantheon pomocou Git.
Súbory na Pantheone sú mediálne súbory, teda obrázky pre stránku. Zvyčajne ich nahrávajú používateľia a Git ich ignoruje.

Vytvorte si bezplatný účet, dozviete sa viac o pracovnom procese Pantheon alebo na objednanie demoverzie na pantheon.io.

Predpoklady

Môj projekt na Pantheone a GitLab sa volá pantheon-gitlab-blog-demo. Názov projektu by mal byť jedinečný. Tu budeme pracovať so stránkou WordPress. Môžete použiť aj Drupal, ale bude potrebné niečo upraviť.

Budem používať príkazový riadok Git, môžete pracovať v grafickom rozhraní, ak chcete.

Vytvárame projekt

Najprv vytvoríme projekt GitLab (k tomu sa ešte vrátime).

Teraz vytvoríme stránku WordPress na Pantheone. Potom nainštalujeme WordPress pre ovládací panel stránky.

Ak máte chuť niečo zmeniť, napríklad odstrániť alebo pridať pluginy, vydržte. Stránka ešte nie je pripojená k GitLab a chceme, aby všetky zmeny kódu prebiehali cez GitLab.

Keď nainštalujeme WordPress, vrátime sa na ovládací panel stránky Pantheon a zmeníme vývojový režim na Git.

Počiatočný commit na GitLab

Teraz musíme preniesť počiatočný kód WordPress zo stránky Pantheon na GitLab. Na to klonujeme kód z Git repozitára stránky Pantheon lokálne a potom ho odosielame do repozitára GitLab.

Aby to bolo jednoduchšie a bezpečnejšie, pridáme SSH kľúč do Pantheon a nebudeme musieť zakaždým zadávať heslo, keď klonujeme repozitár Pantheon Git. Po ceste už pridáme SSH kľúč na GitLab.

Na to klonujeme stránku Pantheon lokálne, skopírovaním príkazu z poľa Klonovať s Git na ovládacom paneli stránky.

Ak potrebujete pomoc, prečítajte si dokumentáciu o začiatku práce s Git pre Pantheon.

Teraz zmeníme git remote origin, aby sme ukázali na GitLab namiesto Pantheon. Môžeme to urobiť príkazom git remote.

Prejdeme do projektu GitLab a skopírujeme URL adresu repozitára z rozbaľovacieho zoznamu Klonovať na stránke podrobností projektu. Vyberieme možnosť Klonovať s SSH, pretože sme už nastavili SSH kľúč.

Predvolene git remote pre lokálnu kópiu repozitára kódu — origin. To môžeme zmeniť pomocou git remote set-url origin [URL repozitára GitLab], kde namiesto zátvoriek zadáme faktickú URL.

Nakoniec spustíme git push origin master --force, aby sme odoslali kód WordPress zo stránky Pantheon na GitLab.

Parametre –force je potrebný iba raz. Potom v príkazoch git push na GitLab nebude.

Nastavujeme poverenia a premenné

Pamätáte si, ako sme lokálne pridali SSH kľúč, aby sme sa autorizovali v Pantheone a GitLab? SSH token môžeme použiť na autorizáciu v GitLab a Pantheone.

Na GitLab je skvelá dokumentácia. Pozrime sa na sekciu o SSH kľúčoch pri používaní Docker executor v dokumente o používaní SSH kľúčov s GitLab CI/CD.

Teraz vykonáme prvé dva kroky: vytvoríme novú dvojicu SSH kľúčov lokálne s ssh-keygen a pridáme súkromný kľúč ako premennú v projekte.

Potom nastavíme SSH_PRIVATE_KEY ako premennú prostredia GitLab CI/CD v parametroch projektu.
V treťom a štvrtom kroku vytvoríme súbor .gitlab-ci.yml s takým obsahom:

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"

Zatiaľ nebudeme commitovať súbor .gitlab-ci.yml, neskôr k nemu bude potrebné ešte niečo pridať.

Teraz vykonávame piaty krok a pridávame verejný kľúč, ktorý sme vytvorili v prvom kroku, k službám, ku ktorým potrebujete prístup v prostredí buildovania.

V našom prípade chceme z GitLab získať prístup k Pantheone. Postupujte podľa pokynov v dokumente Pantheon o pridávaní SSH kľúča do Pantheonu a vykonávame tento krok.

Pamätáme si: súkromný SSH – v GitLab, verejný – v Pantheone.

Nastavíme ešte niekoľko premenných prostredia. Prvá sa volá PANTHEON_SITE. Jej hodnota je názov stránky Pantheon vo vašej mašine.

Názov na mašine je uvedený na konci príkazu Clone with Git. Už ste stránku lokálne sklonovali, takže to bude názov adresára lokálneho repozitára.

Ďalej nastavíme premennú prostredia PANTHEON_GIT_URL. Toto je URL repozitára Git pre stránku Pantheon, ktorý sme už použili.

Zadávame iba URL SSH repozitára, bez git clone a názvu stránky na mašine na konci.

Uf. To sme zvládli, teraz môžeme dokončiť náš súbor .gitlab-ci.yml.

Vytvoríme úlohu nasadenia

To, čo na začiatku budeme robiť s GitLab CI, je veľmi podobné tomu, čo sme robili s Git repozitármi predtým. Ale tentoraz pridáme repozitár Pantheon ako druhý vzdialený zdroj Git, a potom pošleme kód z GitLab do Pantheon.

Na to nastavíme fázu deploy a úlohu deploy:dev, veď nasadzujeme do vývojového prostredia v Pantheone. Výsledkom bude, že súbor .gitlab-ci.yml bude vyzerať takto:

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

Premenné SSH_PRIVATE_KEY, PANTHEON_SITE a PANTHEON_GIT_URL by mali by už byť známe — tieto premenné sme nastavili skôr. S týmito premennými budeme môcť používať hodnoty v súbore .gitlab-ci.yml mnohých, a bude ich potrebné aktualizovať iba na jednom mieste.

Nakoniec pridáme, zcommitujeme a pošleme súbor .gitlab-ci.yml na GitLab.

Kontrolujeme nasadenie

Ak sme všetko spravili správne, úloha deploy:dev úspešne prebehne v GitLab CI/CD a pošle commit .gitlab-ci.yml na Pantheon. Pozrime sa.

Posielame vetvy merge requestov na Pantheon

Tu použijeme moju obľúbenú funkciu Pantheon — multidev, kde môžeme na požiadanie vytvárať ďalšie prostredia Pantheon pre vetvy Git.

Prístup k multidev je obmedzený, takže túto časť nie je potrebné vykonávať. Ale ak máte prístup, môžete výrazne zvýšiť produktivitu nastavením automatického vytvárania prostredí multidev na Pantheon z merge requestov GitLab.

Najprv vytvoríme novú vetvu Git lokálne pomocou git checkout -b multidev-support. Teraz opäť urobíme niekoľko zmien v .gitlab-ci.yml.

Rád uvádzam číslo merge requestu v názve prostredia Pantheon. Napríklad, prvý merge request — mr-1, druhý — mr-2 a pod.

Merge request sa mení, takže musíme dynamicky určiť názvy vetiev Pantheon. Na GitLab je to jednoduché — musíme použiť preddefinované premenné prostredia.

Môžeme vziať $CI_MERGE_REQUEST_IID, aby sme uviedli číslo merge requestu. Poďme to všetko aplikovať spolu s globálnymi premennými prostredia, ktoré sme uviedli skôr, a pridajme novú úlohu deploy:multidev na konci súboru .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

Bude to vyzerať ako naša úloha deploy:dev, iba vetva sa posiela na Pantheon, a nie do master.

Pridali sme a zcommitovali aktualizovaný súbor .gitlab-ci.yml, a teraz pošleme novú vetvu do GitLab s git push -u origin multidev-support.

Teraz vytvoríme nový merge request z vetvy podpora multidev, kliknutím Vytvoriť merge request.

Po vytvorení mergového požiadavku si pozrieme, ako prebieha úloha CI/CD deploy:multidev.

Pozrite sa — na Pantheon bola odoslaná nová vetva. Ak však prejdeme do sekcie multidev na panela nástroja na Pantheon, novú prostredie tam neuvidíme

Pozrime sa na sekciu Git Branches.

Naša vetva mr-1 sa dostala na Pantheon. Vytvoríme prostredie z vetvy mr-1.

Vytvorili sme prostredie multidev, teraz sa vrátime do GitLab a pozrieme sa do sekcie Operations > Environments. Uvidíme záznamy pre dev a mr-1.

To je preto, že sme pridali záznam environment s názvom name a url do úloh CI/CD. Ak klikneme na ikonu otvorenej prostredia, prejdeme na URL prostredia multidev na Pantheon.

Automatizujeme vytváranie multidev

V zásade sa na tomto mieste môžeme zastaviť a jednoducho nezabudnúť vytvárať prostredie multidev pre každý mergový požiadavok, no tento proces môžeme automatizovať.

Na Pantheon je nástroj príkazového riadku Terminus, kde môžete pracovať s platformou automaticky. V Terminus môžete vytvárať prostredia multidev z príkazového riadku — ideálne pre GitLab CI.

Potrebujeme nový merge request, aby sme to otestovali. Vytvoríme novú vetvu pomocou git checkout -b auto-multidev-creation.

Aby ste mohli použiť Terminus v úlohách GitLab CI/CD, potrebujete token stroja na autentifikáciu v Terminus a obraz kontajnera s Terminus.

Vytvárame token stroja Pantheon, uchovávame ho na bezpečnom mieste a pridávame ako globálnu premennú prostredia do GitLab s názvom PANTHEON_MACHINE_TOKEN.

Ak ste zabudli, ako pridávať premenné prostredia GitLab, vráťte sa k tomu, kde sme definovali PANTHEON_SITE.

Vytvárame Dockerfile s Terminus

Ak nepoužívate Docker alebo nemáte radi súbory Dockerfile, vezmite môj obraz registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest a preskočte túto časť.

V GitLab je registrovaný kontajner, kde môžeme zostaviť a umiestniť Dockerfile pre náš projekt. Vytvorme súbor Dockerfile s Terminus na prácu s Pantheon.

Terminus je nástroj príkazového riadku na PHP, takže začneme s obrazom PHP. Terminus inštalujem cez Composer, takže ako základ vezmem oficiálny obraz Docker Composer. Vytvoríme Dockerfile v lokálnom repozitári s takýmto obsahom:

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

Postupujte podľa pokynov na zostavenie a odoslanie obrazov v sekcii Build and push images v dokumentácie registrov kontajnerov, aby ste zostavili obraz z Dockerfile a poslali ho do GitLab.

Otvoríme sekciu Registry v projekte GitLab. Ak všetko ide podľa plánu, tam bude náš obraz. Poznačte si odkaz na tag obrazu — ten potrebujeme pre súbor .gitlab-ci.yml.

Sekcia script v úlohe deploy:multidev začína sa rozrastať, takže ho prenesme do samostatného súboru. Vytvárame nový súbor 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 sa nachádza v súkromnom adresári a neumožňuje webový prístup na Pantheon. Máme skript pre našu logiku multidev. Poďme teraz aktualizovať sekciu deploy:multidev súboru .gitlab-ci.yml, aby to vyzeralo takto:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Spustiť skript na nasadenie multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Musíme sa uistiť, že naše úlohy sa vykonávajú v vytvorenom prispôsobenom obraze, takže pridáme definíciu obrázok s URL adresou registra do .gitlab-ci.yml. Nakoniec máme takýto súbor .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Pozri 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:
    # Spustiť skript na nasadenie multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Pridávame, commitujeme a odosielame private/multidev-deploy.sh a .gitlab-ci.yml. Teraz sa vraciame do GitLab a čakáme, kým sa úloha CI/CD vykoná. Prosím, vydržte: multidev môže byť vytváraný niekoľko minút.

Následne ideme skontrolovať zoznam multidev na Pantheon. Ó zázrak! Prostredie multidev mr-2 už je tu.

Záver

Môj tím sa cítil oveľa šťastnejšie, keď sme začali otvárať mergenotifikácie a automaticky vytvárať prostredia.

S mocnými nástrojmi GitLab a Pantheon môžeme automaticky pripojiť GitLab k Pantheon.

Keďže používame GitLab CI/CD, náš pracovný proces má veľký potenciál. Tu je pár nápadov, ako začať:

• Pridajte krok na zostavenie.
• Pridajte automatizované testovanie.
• Pridajte úlohu na zabezpečenie dodržiavania štandardov kódu.
• Pridajte dynamické testovanie zabezpečenia aplikácií.

Napíšte, čo si myslíte o GitLab, Pantheon a automatizácii.

P.S. Vedeli ste, že Terminus, nástroj príkazového riadka Pantheon, je možné rozšíriť prostredníctvom pluginov?

Pracovali sme na Pantheon verzii 2 nášho pluginu pre nástroje zostavenia Terminus s podporou GitLab. Ak sa vám nechce zaoberať sa nastavením pre každý projekt, vyskúšajte tento plugin a pomôžte nám otestovať beta verziu v2. Pre tím Terminus build:project:create potrebujete iba token Pantheon a token GitLab. Rozšíri jeden z príkladov projektu s Composer a automatickým testovaním, vytvorí nový projekt v GitLab, nový web Pantheon a prepojí ich pomocou environmentálnych premenných a SSH kľúčov.

O autorovi

Andrew Taylor vytvára nástroje pre vývojárov v Pantheon.

Zdroj: habr.com