🥇Jak spojit GitLab a Pantheon a optimalizovat pracovní toky pro Drupal a WordPress

Náš host, tvůrce nástrojů pro vývojáře z Pantheon, hovoří o tom, jak automatizovat nasazování WordPressu pomocí GitLab CI/CD.

V Pantheon Pracuji ve vztazích s vývojáři, takže vždy hledám nové způsoby, jak pomoci vývojářům WordPress a Drupal řešit problémy s automatizací v pracovních postupech. Proto rád experimentuji s novými nástroji a kombinuji je pro efektivní práci.

Často vídám, jak se vývojáři trápí s jedním mezilehlým serverem.

Není to žádná radost - čekat na svou řadu, abych mohl použít mezilehlý server, nebo posílat klientům URL s označením: „Tady se podívejte, a sem zatím nechoďte“.

Prostředí multidev — jeden z skvělých nástrojů Pantheon — řeší tento problém, protože s nimi lze na vyžádání vytvářet prostředí pro větve Git. Každé prostředí multidev má svůj vlastní URL a databázi, takže vývojáři mohou v klidu pracovat, testovat kvalitu a získávat schválení, aniž by se navzájem překáželi.

Ale na Pantheon nejsou žádné nástroje pro sledování verzí nebo kontinuální integraci a nasazení (CI/CD). Přesto je to flexibilní platforma, se kterou lze integrovat jakékoli nástroje.

Také jsem si všiml, že týmy používají pro vývoj jiné nástroje než pro sestavení a nasazení.

Například mají různé nástroje pro sledování verzí a CI/CD. Musí se přepínat mezi nástroji, aby mohli upravovat kód a diagnostikovat problémy.

Na GitLab existuje úplná sada nástrojů pro vývoj: pro sledování verzí, tikety, merge requesty, nejlepší v třídě CI/CD pipeline, registry kontejnerů a podobně. Zatím jsem nenašel aplikace, které by měly tolik nástrojů pro řízení pracovního postupu vývoje.

Miluji automatizaci, takže jsem se naučil, jak propojit Pantheon s GitLabem, aby se commity do hlavní větve na GitLab nasazovaly v hlavním vývojovém prostředí v Pantheon. A také merge requesty na GitLab mohou vytvářet a nasazovat kód do prostředí multidev v Pantheon.

V tomto průvodci vám ukážu, jak nastavit připojení mezi GitLabem a Pantheonem a optimalizovat pracovní postup WordPress a Drupal.

Samozřejmě, můžeme zrcadlit repozitář GitLab, ale všechno budeme dělat ručně, abychom si s tím pohráli GitLab CI a do budoucna používat tento nástroj nejen pro nasazení.

Úvod

Pro tento příspěvek je třeba pochopit, že Pantheon rozděluje každou stránku na tři prvky: kód, databázi a soubory.

Kód zahrnuje soubory CMS, například jádro, pluginy a šablony WordPress. Tyto soubory se spravují v Git repozitáři, umístěném na Pantheonu, což znamená, že můžeme nasazovat kód z GitLabu na Pantheon pomocí Gitu.
Soubory na Pantheonu jsou mediální soubory, tedy obrázky pro web. Obvykle je nahrávají uživatelé a Git je ignoruje.

Vytvořte si bezplatný účet, zjistěte více o pracovním postupu Pantheon nebo zaregistrujte se na demo na pantheon.io.

Předpoklady

Můj projekt na Pantheon a GitLab se jmenuje pantheon-gitlab-blog-demo. Název projektu musí být jedinečný. Budeme pracovat se stránkou WordPress. Můžete vzít i Drupal, ale bude třeba udělat některé změny.

Budu používat příkazový řádek Git, ale vy můžete pracovat v grafickém rozhraní, pokud chcete.

Vytváříme projekt

Nejprve vytvoříme projekt GitLab (k tomu se ještě vrátíme).

Nyní vytvoříme stránku WordPress na Pantheonu. Poté nainstalujeme WordPress pro řídicí panel stránky.

Pokud máte potřebu něco změnit, například odstranit a přidat pluginy, zadržte to. Stránka ještě není připojena k GitLabu a chceme, aby všechny změny kódu procházely přes GitLab.

Jakmile nainstalujeme WordPress, vrátíme se na řídicí panel stránky Pantheon a změníme režim vývoje na Git.

Počáteční commit na GitLab

Teď je třeba přesunout počáteční kód WordPress ze stránky Pantheon na GitLab. K tomu lokálně klonujeme kód z Git repozitáře stránky Pantheon a poté ho odešleme do repozitáře GitLab.

Aby to bylo jednodušší a bezpečnější, přidáme SSH klíč do Pantheon a nebudeme muset pokaždé zadávat heslo, když klonujeme repozitář Pantheon Git. Zároveň již přidáme SSH klíč na GitLab.

K tomu klonujeme stránku Pantheon lokálně a zkopírujeme příkaz z pole Klonovat pomocí Gitu na řídicím panelu stránky.

Pokud potřebujete pomoc, přečtěte si dokumentaci k práci s Gitem pro Pantheon.

Teď změníme git remote origin, abychom ukazovali na GitLab místo Pantheon. Tohoto lze dosáhnout příkazem git remote.

Přejdeme do projektu GitLab a zkopírujeme URL repozitáře z rozbalovacího seznamu Klonovat na stránce podrobností projektu. Vybereme možnost Klonovat pomocí SSH, protože jsme už nastavili SSH klíč.

Ve výchozím nastavení git remote pro lokální kopii kódového repozitáře - origin. To lze změnit pomocí git remote set-url origin [URL repozitáře GitLab], kde místo závorek zadáme skutečné URL.

Nakonec spustíme git push origin master --force, abychom poslali kód WordPress ze stránky Pantheon na GitLab.

Parametr –force je potřeba použít jen jednou. Poté v příkazech git push na GitLab nebude.

Nastavujeme přihlašovací údaje a proměnné

Pamatujete, jak jsme lokálně přidali SSH klíč, abychom se autorizovali v Pantheon a GitLab? SSH token lze použít k autorizaci v GitLab a Pantheon.

GitLab má skvělou dokumentaci. Pojďme se podívat na část o SSH klíčích při použití Docker executor v dokumentu o používání SSH klíčů s GitLab CI/CD.

Teď provedeme první dva kroky: vytvoříme novou dvojici SSH klíčů lokálně s ssh-keygen a přidáme soukromý klíč jako proměnnou v projektu.

Pak nastavíme SSH_PRIVATE_KEY jak proměnnou prostředí GitLab CI/CD v nastavení projektu.
Ve třetím a čtvrtém kroku vytvoříme soubor .gitlab-ci.yml s tímto obsahem:

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

Zatím nebudeme soubor commitovat .gitlab-ci.yml, později k němu budeme muset ještě něco přidat.

Teď provedeme pátý krok a přidáme veřejný klíč, který jsme vytvořili v prvním kroku, k službám, ke kterým potřebujete přístup v buildu.

V našem případě chceme mít přístup z GitLab k Pantheon. Řídíme se pokyny v dokumentu Pantheon k přidání SSH klíče do Pantheon a provedeme tento krok.

Pamatujte: soukromý SSH klíč je v GitLab, veřejný je v Pantheon.

Nastavíme ještě několik proměnných prostředí. První se jmenuje PANTHEON_SITE. Její hodnota je název webu Pantheon na vašem stroji.

Název na stroji je uveden na konci příkazu Clone with Git. Web jste už lokálně clonovali, takže to bude název adresáře lokálního repozitáře.

Dále nastavíme proměnnou prostředí PANTHEON_GIT_URL. To je URL repozitáře Git pro web Pantheon, který jsme již použili.

Zadáváme pouze URL SSH repozitáře, bez git clone a jména webu na stroji na konci.

Uf. To je hotové, teď můžeme dokončit náš soubor .gitlab-ci.yml.

Vytvoříme úlohu pro nasazení

To, co budeme na začátku dělat s GitLab CI, je velmi podobné tomu, co jsme dělali s repozitáři Git dříve. Ale tentokrát přidáme repozitář Pantheon jako druhý vzdálený zdroj Git a poté odešleme kód z GitLab do Pantheon.

K tomu nastavíme fázi deploy a úlohu deploy:dev, protože budeme nasazovat do vývojového prostředí na Pantheon. Výsledný soubor .gitlab-ci.yml bude vypadat takto:

stages:
- deploy

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

Proměnné SSH_PRIVATE_KEY, PANTHEON_SITE a PANTHEON_GIT_URL by měly vypadat povědomě – tyto proměnné jsme nastavili dříve. S těmito proměnnými budeme moci použít hodnoty v souboru .gitlab-ci.yml mnohokrát, a aktualizovat je budeme muset pouze na jednom místě.

Nakonec přidáme, commitneme a odešleme soubor .gitlab-ci.yml na GitLab.

Kontrolujeme nasazení

Pokud jsme vše udělali správně, úkol deploy:dev se úspěšně provede v GitLab CI/CD a odešle commit .gitlab-ci.yml na Pantheon. Podívejme se.

Odesíláme větve merge requestů na Pantheon

Tady využijeme moji oblíbenou funkci Pantheon – multidev, kde můžeme na požádání vytvářet další prostředí Pantheon pro větve Git.

Přístup k multidev je omezen, takže tuto část lze přeskočit. Ale pokud máte přístup, můžete výrazně zlepšit výkon nastavením automatického vytváření multidev prostředí na Pantheon z merge requestů GitLab.

Nejprve vytvoříme novou větev Git lokálně pomocí git checkout -b multidev-support. Nyní znovu provedeme nějaké změny v .gitlab-ci.yml.

Rád uvádím číslo merge requestu v názvu prostředí Pantheon. Například první merge request – mr-1, druhý – mr-2 a tak dále.

Merge request se mění, takže potřebujeme dynamicky definovat názvy větví Pantheon. Na GitLab je to jednoduché – stačí použít předem definované proměnné prostředí.

Můžeme vzít $CI_MERGE_REQUEST_IID, abychom uvedli číslo merge requestu. Pojďme to všechno spojit s globálními proměnnými prostředí, které jsme uvedli dříve, a přidat nový úkol deploy:multidev na konec souboru .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 vypadat jako náš úkol deploy:dev, pouze větev je odeslána na Pantheon, a ne na master.

Přidali jsme a commitli aktualizovaný soubor .gitlab-ci.yml, a nyní odešleme novou větev do GitLab s git push -u origin multidev-support.

Nyní vytvoříme nový merge request z větve multidev-support, stiskněte Vytvořit merge request.

Po vytvoření merge requestu se podívejme, jak se úkol CI/CD provádí deploy:multidev.

Podívejte se — na Pantheon byla odeslána nová větev. Ale pokud přejdeme do sekce multidev na řídícím panelu webu na Pantheon, novou prostředí tam neuvidíme

Podívejme se do sekce Git Branches.

Nakonec naše větev mr-1 dorazila na Pantheon. Vytvoříme prostředí z větve mr-1.

Vytvořili jsme prostředí multidev, teď se vraťme do GitLab a podívejme se do sekce Operations > Environments. Uvidíme záznamy pro dev a mr-1.

To je proto, že jsme přidali zápis environment s názvem name a url do úloh CI/CD. Pokud klikneme na ikonu otevřeného prostředí, přejdeme na URL prostředí multidev na Pantheon.

Automatizujeme vytváření multidev

V zásadě, na tom bychom mohli skončit a prostě nezapomínat vytvářet prostředí multidev pro každý merge request, ale tento proces můžeme automatizovat.

Na Pantheon je nástroj příkazového řádku Terminus, kde můžeme s platformou pracovat automaticky. V Terminus můžeme vytvářet prostředí multidev z příkazového řádku — ideální pro GitLab CI.

Potřebujeme nový merge request, abychom to otestovali. Vytvoříme novou větev pomocí git checkout -b auto-multidev-creation.

Abychom používali Terminus v úlohách GitLab CI/CD, potřebujeme strojový token pro autentizaci v Terminus a obraz kontejneru s Terminus.

Vytváříme strojový token Pantheon, uchováváme ho na bezpečném místě a přidáváme jako globální proměnnou prostředí do GitLab s názvem PANTHEON_MACHINE_TOKEN.

Pokud jste zapomněli, jak přidávat proměnné prostředí do GitLab, vraťte se tam, kde jsme definovali PANTHEON_SITE.

Vytváříme Dockerfile s Terminus

Pokud nepoužíváte Docker nebo nemáte rádi soubory Dockerfile, vezměte můj obraz registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest a přeskočte tuto část.

V GitLab je registry kontejnerů, kde můžeme sestavit a umístit Dockerfile pro náš projekt. Vytvořme soubor Dockerfile s Terminus, abychom mohli pracovat s Pantheon.

Terminus je příkazový řádkový nástroj pro PHP, takže začneme s obrazem PHP. Instalaci Terminus provádím přes Composer, takže jako základ vezmu oficiální obraz Docker Composer. Vytvoříme Dockerfile v adresáři lokálního repozitáře s takovým obsahem:

# 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 podle pokynů pro sestavení a odesílání obrazů v sekci Build and push images v dokumentace registry kontejnerů, abychom sestavili obraz z Dockerfile a odeslali ho do GitLab.

Otevřeme sekci Registry v projektu GitLab. Pokud vše probíhá podle plánu, tam bude náš obraz. Zapamatujte si odkaz na tag obrazu — potřebujeme ho pro soubor .gitlab-ci.yml.

Sekce script v úkolu deploy:multidev začíná se rozrůstat, takže jej přeneste do samostatného souboru. Vytvoříme nový soubor 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 se nachází v soukromém adresáři a neumožňuje webový přístup na Pantheon. Máme skript pro naši logiku multidev. Nyní aktualizujeme sekci deploy:multidev soubory .gitlab-ci.yml, aby to vypadalo 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:
    # Spustit skript pro deploy multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Musíme se ujistit, že naše úkoly se vykonávají ve vytvořeném vlastním obraze, takže přidáme definici obrázek s URL repositáře do .gitlab-ci.yml. Výsledkem je tento soubor .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Viz 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:
    # Spustit skript pro deploy multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Přidáváme, commituje a odesíláme private/multidev-deploy.sh a .gitlab-ci.yml. Teď se vraťte do GitLabu a počkejte, až úkol CI/CD proběhne. Chvíli to trvá: multidev se může vytvářet několik minut.

Pak se jdeme podívat na seznam multidev na Pantheon. Ó zázraku! Prostředí multidev mr-2 už je tu.

Závěr

Moje týmová práce se stala mnohem zábavnější, když jsme začali otevírat merge requesty a automaticky vytvářet prostředí.

S mocnými nástroji GitLab a Pantheon můžete GitLab automaticky připojit k Pantheon.

Jelikož používáme GitLab CI/CD, náš pracovní proces bude mít prostor pro růst. Tady je několik nápadů, jak začít:

Přidejte krok pro sestavení.
Přidejte automatizované testování.
Přidejte úkol pro zajištění dodržování kódovacích standardů.
Přidejte dynamické testování bezpečnosti aplikací.

Napište, co si myslíte o GitLab, Pantheon a automatizaci.

P.S. Věděli jste, že Terminus, nástroj příkazového řádku Pantheon, lze rozšiřovat pomocí pluginů?

V Pantheon jsme tvrdě pracovali na verzi 2 našeho pluginu pro nástroje sestavení Terminus se supportem GitLab. Pokud se nechcete zabývat konfigurací pro každý projekt, vyzkoušejte tento plugin a pomozte nám otestovat beta verzi v2. Pro tým Terminus build:project:create potřebujete pouze token Pantheon a token GitLab. Ten rozbalí jeden z příkladů projektu s Composerem a automatizovaným testováním, vytvoří nový projekt v GitLabu, nový web na Pantheon a spojí je pomocí proměnných prostředí a SSH klíčů.