Hogyan kapcsoljuk össze a GitLab-ot és a Pantheon-t, és optimalizáljuk a Drupal és WordPress munkafolyamatokat.

Vendégünk, a Pantheon fejlesztői eszközök készítője elmondja, hogyan lehet automatizálni a WordPress-deployokat a GitLab CI/CD segítségével.

A Pantheon Fejlesztői kapcsolatokkal foglalkozom, ezért mindig keresem az új módszereket, hogy segítsek a WordPress és Drupal fejlesztőknek az automatizálással kapcsolatos problémák megoldásában. Ehhez szeretek új eszközöket kipróbálni és kombinálni őket a hatékonyabb munkához.

Gyakran látom, hogy a fejlesztők szenvednek egy köztes szerverrel.

Ez nem éppen kellemes élmény - várni a sorunkra, hogy használhassuk a köztes szervert, vagy ügyfeleknek URL-t küldeni a megjegyzéssel: 'Itt nézzétek, de itt még ne nézzétek'.

A multidev környezetek — a Pantheon egyik menő eszköze — megoldja ezt a problémát, hiszen ezeket kérésre lehet létrehozni a Git ágazatok szerint. Minden multidev környezetnek saját URL-je és adatbázisa van, így a fejlesztők nyugodtan dolgozhatnak, ellenőrizhetik a minőséget és kaphatnak jóváhagyást, anélkül, hogy egymás lábára lépnének.

De a Pantheonban nincsenek verziókezelő vagy folyamatos integrációs és deploy (CI/CD) eszközök. Viszont ez egy rugalmas platform, amelyre bármilyen eszközt integrálni lehet.

Ezen kívül észrevettem, hogy a csapatok különböző eszközöket használnak a fejlesztéshez, és másokat az építéshez és a telepítéshez.

Például különböző eszközöket használnak a verziókezeléshez és a CI/CD-hez. Így sok időt kell eltölteni az eszközök közötti váltogatással, hogy kódot szerkesszenek és problémákat diagnosztizáljanak.

Ezen GitLab Van egy teljes eszközkészlet a fejlesztéshez: verziókezeléshez, ticketekhez, merge requestekhez, a legjobbnak számító CI/CD pipeline, konténerregiszter és hasonlók. Még nem találkoztam olyan alkalmazásokkal, ahol ennyiféle eszköz lenne a fejlesztési munkafolyamat kezelésére.

Imádom az automatizálást, ezért tanulmányoztam, hogyan lehet a Pantheont összekapcsolni a GitLabbal, hogy a GitLabe-be történő fő ági commitok a Pantheon fő fejlesztési környezetébe települjenek. A GitLab merge requestek pedig kódot hozhatnak létre és telepíthetnek a Pantheon multidev környezeteibe.

Ebben az útmutatóban elmondom, hogyan lehet beállítani a kapcsolatot a GitLab és a Pantheon között, és hogyan lehet optimalizálni a WordPress és Drupal munkafolyamatot.

Természetesen lehet, tükrözni a GitLab tárolót, de mindent kézzel fogunk csinálni, hogy megmutassuk, hogyan működik, GitLab CI és a jövőben ezt az eszközt nemcsak deployra használni.

Bevezetés

Ehhez a bejegyzéshez fontos megérteni, hogy a Pantheon minden weboldalt három elemre bont: kód, adatbázis és fájlok.

A kódba a CMS fájlok tartoznak, például a WordPress mag, bővítmények és témák. Ezek a fájlok a Git tárolóban, amely a Pantheonban található, így a GitLabból a Pantheonba tudunk kódot telepíteni a Git segítségével.
A Pantheonban fájlok alatt a médiafájlokat értjük, tehát a weboldalhoz tartozó képeket. Ezeket általában a felhasználók töltik fel, és a Git figyelmen kívül hagyja őket.

Hozzon létre ingyenes fiókot, tudjon meg többet a Pantheon munkafolyamatáról vagy jelentkezzen be egy bemutatóra a pantheon.io-n.

Feltételezések

A projekt nevem a Pantheonban és a GitLabban pantheon-gitlab-blog-demo. A projekt neve egyedinek kell lennie. Itt egy WordPress weboldallal fogunk dolgozni. Drupal is használható, de akkor néhány dolgot módosítani kell.

Én a Git parancssorát, de Ön használhatja a grafikus felhasználói felületet, ha szeretné.

Projekt létrehozása

Először hozzunk létre GitLab projektet (erről még visszatérünk).

Most hozzunk létre egy WordPress weboldalt a Pantheonban. Ezután telepítjük a WordPress-t a weboldal irányítópultjára.

Ha akarja módosítani például a bővítményeket, várjon egy kicsit. Az oldal még nincs csatlakoztatva a GitLabhoz, és azt akarjuk, hogy minden kódmódosítás a GitLabon keresztül történjen.

Miután telepítettük a WordPress-t, visszatérünk a Pantheon weboldal irányítópultjára, és a fejlesztési módot Git-re állítjuk.

Első elkötelezés a GitLabban

Most át kell vinni az első WordPress kódot a Pantheon weboldalról a GitLabba. Ehhez helyben klónozzuk a Pantheon weboldal Git tárolóját, majd küldjük a GitLab tárolóba.

A jobb és biztonságosabb megoldás érdekében adjunk hozzá SSH-kulcsot a Pantheonhoz és ne kelljen minden alkalommal jelszót beírni, amikor a Pantheon Git tárolót klónozzuk. Egyúttal már adjunk hozzá SSH-kulcsot a GitLabhoz.

Ehhez helyben klónozzuk a Pantheon weboldalt, a weboldal irányítópultján található Klónozás Git-tel opcióból másolva a parancsot.

Ha segítségre van szüksége, olvassa el a dokumentációt a Pantheon Git használatának megkezdéséről.

Most módosítsuk a git remote origin, hogy a GitLab-ra mutasson a Pantheon helyett. Ezt megtehetjük a git remote paranccsal..

Lépjünk a GitLab projekthez, és másoljuk ki a tároló URL-jét a projekt részletei oldalán a Klónozás legördülő listából. Válasszuk a Klónozás SSH-val lehetőséget, hiszen már beállítottuk az SSH-kulcsot.

már tartalmaz egy előre létrehozott önaláírt TLS/SSL tanúsítványt. Ennyi nekem elegendő, mivel zárva tartom a külső hozzáférést. Azoknak, akik más típusú tanúsítványokat szeretnének használni, van git remote a kód tárolójának helyi másolatához — origin. Ezt meg lehet változtatni a git remote set-url origin [GitLab tároló URL] paranccsal,ahol a zárójelek helyére a tényleges URL-t írjuk.

Végül futtassuk a git push origin master --force, hogy a WordPress kódot a Pantheon weboldalról a GitLabra küldjük.

A -force paraméter csak egyszer szükséges. A parancsokban azután git push nem lesz benne GitLabon.

Beállítjuk a hitelesítési adatokat és a változókat

Emlékszel, hogyan adtunk hozzá helyben SSH-kulcsot, hogy belépjünk a Pantheonba és a GitLabba? Az SSH-token használható a GitLab és a Pantheon hitelesítésére.

A GitLabnak nagyszerű dokumentációja van. Nézzük meg az SSH-kulcsokról szóló részt, amikor Docker-executorral használunk SSH-kulcsokat a GitLab CI/CD dokumentumban..

Most végrehajtjuk az első két lépést: helyben létrehozunk egy új SSH-kulcspárt az ssh-keygen-nel, és hozzáadjuk a zártkulcsot mint változót a projekthez..

Aztán beállítjuk SSH_PRIVATE_KEY hogyan GitLab CI/CD környezeti változót a projekt beállításaiban.
A harmadik és negyedik lépésben létrehozunk egy fájlt .gitlab-ci.yml a következő tartalommal:

before_script:
  # Lásd a https://docs.gitlab.com/ee/ci/ssh_keys/README.html weboldalt
  - 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"

Most ne kezdjük el a fájl commitálását .gitlab-ci.yml, aztán még hozzá kell adni valamit.

Most hajtsuk végre az ötödik lépést és adjuk hozzá az első lépésben létrehozott nyilvános kulcsot azokhoz a szolgáltatásokhoz, amelyekhez hozzáférésre van szükségünk a build környezetben..

A mi esetünkben a GitLabon keresztül szeretnénk hozzáférni a Pantheonhoz. Kövessük a Pantheon dokumentum utasításait a SSH-kulcs Pantheonba történő hozzáadásáról és hajtsuk végre ezt a lépést.

Ne felejtsük el: a zártkulcs a GitLabban, a nyilvános a Pantheonban.

Beállítunk még néhány környezeti változót. Az első PANTHEON_SITE néven fut. Az értéke a Pantheon webhely neve a gépeden.

A gépen található név a Clone with Git parancs végén van megadva. Már klónoztad a webhelyet helyben, így ez a helyi tároló mappa neve lesz.

Ezután beállítjuk a környezeti változót PANTHEON_GIT_URL. Ez a Pantheon webhely Git tárolójának URL-je, amelyet már használtunk.

Csak a tároló SSH URL-jét adjuk meg anélkül, hogy git clone és a webhely nevét a gépen a végén.

Húha. Megcsináltuk, most befejezhetjük a fájlunkat .gitlab-ci.yml.

Létrehozunk egy telepítési feladatot

Amit a GitLab CI-val először csinálunk, nagyon hasonló ahhoz, amit korábban a Git tárolókkal csináltunk. De ezúttal hozzáadjuk a Pantheon tárolót mint második távoli Git forrást, majd a kódot a GitLabból a Pantheonba küldjük.

Ehhez beállítjuk a szakaszt after_deploy és feladatot deploy:dev, mivel a Pantheon fejlesztési környezetébe fogunk telepíteni. Ennek eredményeképpen a fájl .gitlab-ci.yml így fog kinézni:

szakaszok:
- telepítés

előscript:
  # Lásd: 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"
	elepítés:dev:
  szakasz: telepítés
  környezet:
    név: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  script:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  csak:
    - master

Változók SSH_PRIVATE_KEY, PANTHEON_SITE és PANTHEON_GIT_URL ismerősnek kell lennie – ezeket a környezeti változókat már korábban beállítottuk. Ezekkel a változókkal használni tudjuk az értékeket a fájlban .gitlab-ci.yml többször, és csak egy helyen kell őket frissíteni.

Végül hozzáadjuk, elkövetjük és elküldjük a fájlt .gitlab-ci.yml a GitLab-ra.

Ellenőrizzük a telepítést

Ha mindent helyesen csináltunk, a feladat deploy:dev sikeresen végrehajtódik a GitLab CI/CD-ben és elküldi a commit-ot .gitlab-ci.yml a Pantheonba. Nézzük meg.

Küldjük el a merge kérések ágainkat a Pantheonba

Itt a kedvenc Pantheon funkciómat fogjuk használni – multidev, ahol igény esetén további Pantheon környezeteket hozhatunk létre a Git ágakhoz.

A multidev hozzáférés korlátozott, így ezt a részt kihagyhatjuk. De ha hozzáférése van, jelentősen növelheti a teljesítményt azáltal, hogy automatikusan létrehozza a multidev környezeteket a Pantheonban a GitLab merge kérésekből.

Először helyben létrehozunk egy új Git ágat a következővel git checkout -b multidev-support. Most ismét módosítunk egy kicsit a .gitlab-ci.yml.

Nekem tetszik, ha a merge kérés számát a Pantheon környezet nevében szerepeltetem. Például, az első merge kérés – mr-1, a második – mr-2 stb.

A merge kérés változik, így dinamikusan kell meghatároznunk a Pantheon ágak neveit. A GitLab-on ez egyszerű – használni kell a előre meghatározott környezeti változókat.

A következőt vehetjük: $CI_MERGE_REQUEST_IID, hogy megadjuk a merge kérés számát. Most egyesítsük ezeket a globális környezeti változókkal, amelyeket korábban megadtunk, és adjuk hozzá az új deploy:multidev feladatot a fájl végéndeploy:multidev: szakasz: telepítés környezet: név: multidev/mr-$CI_MERGE_REQUEST_IID url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/ script: # Ellenőrizzük a merge kérés forráshoz tartozó ágat - git checkout $CI_COMMIT_REF_NAME # A Pantheon git tárolót további távoli tárolóként add hozzá - git remote add pantheon $PANTHEON_GIT_URL # Push a merge kérés forráshoz tartozó ágat a Pantheonba - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force csak: - merge_requests .gitlab-ci.yml.

Hasonlítani fog a feladatunkra

, csak az ág a Pantheonba kerül, nem pedig deploy:devHozzáadtuk és elköteleztük a frissített fájlt master.

, most viszont elküldjük az új ágat a GitLab-ba a következővel .gitlab-ci.ymlgit push -u origin multidev-support Most létrehozunk egy új merge kérést az ágból.

Most létrehozunk egy új összevonási kérést az ágból multidev-támogatás, rákattintva Hozzon létre merge kérdést.

Merge kérés létrehozása után nézzük meg, hogyan teljesül a CI/CD feladat deploy:multidev.

Nézzük meg — új ágat küldtünk a Pantheonra. De ha átmegyünk a Pantheon weboldalának multidev szekciójába, nem látjuk az új környezetet.

Nézzük meg a Git Branches szekciót.

Végül az ágaink mr-1 eljutottak a Pantheonra. Hozzunk létre egy környezetet az ágból. mr-1.

Létrehoztuk a multidev környezetet, most térjünk vissza a GitLabba és nézzünk be a szekcióba Operations > Environments. Látni fogjuk a bejegyzéseket a dev és mr-1.

Ez azért van, mert hozzáadtunk egy bejegyzést környezet a névvel name és url a CI/CD feladatokhoz. Ha rákattintunk a nyitott környezet ikonra, átmegyünk a multidev környezet URL-jére a Pantheonon.

Automatizáljuk a multidev létrehozását

Alapvetően itt meg lehet állni, és egyszerűen figyelni kell, hogy a merge kéréshez mindig hozzunk létre egy multidev környezetet, de ezt a folyamatot automatizálhatjuk.

A Pantheonban van egy parancssori eszköz Terminus, ahol automatizáltan dolgozhatunk a platformmal. A Terminus segítségével parancssorból hozhatunk létre multidev környezeteket — tökéletes GitLab CI.

Szükségünk van egy új merge kérésre, hogy ezt letesztelhessük. Hozzunk létre egy új ágat a következővel: git checkout -b auto-multidev-creation.

A Terminus GitLab CI/CD feladatokban való használatához géptoken szükséges a Terminus autentikálásához és a Terminus konténerképhez.

Hozzunk létre egy géptokot a Pantheonhoz, tároljuk biztonságos helyen, és adjuk hozzá globális környezeti változóként a GitLabban a következő névvel: PANTHEON_MACHINE_TOKEN.

Ha elfelejtettük, hogyan kell környezeti változókat hozzáadni a GitLabhoz, térjünk vissza ahhoz, ahol definiáltuk PANTHEON_SITE.

Hozzunk létre egy Dockerfile-t a Terminushoz

Ha nem használ Docker-t, vagy nem szereted a fájlokat Dockerfile, vedd át az én képet registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest , és hagyd ki ezt a részt.

A GitLabban van egy konténerregiszter, ahol összerakhatjuk és elhelyezhetjük a Dockerfile-t a projektünkhöz. Készítsünk egy Dockerfile-t a Terminushoz, hogy dolgozhassunk a Pantheonnal.

A Terminus egy PHP alapú parancssori eszköz, ezért kezdjük a PHP képpel. A Terminus-t a Composer segítségével telepítem, ezért én az hivatalos Docker Composer képet veszem alapul. Létrehozunk egy Dockerfile a helyi adattárunk mappájában ezzel a tartalommal:

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

Kövessük az építési és push utasításokat a konténerregiszter dokumentációjának Build and push images be. részéből, hogy képet készíthessünk aés elküldhessük a GitLabba. Dockerfile Nyissuk meg a

Registry szekciót a GitLab projektben. Ha minden rendben ment, ott lesz a képünk. Írjuk le a kép címkéjének linkjét — ez szükséges a fájlhoz a feladatban. .gitlab-ci.yml.

Rész script a feladatban. deploy:multidev lassan el kezd terjedni, szóval tegyük át egy külön fájlba. Hozzunk létre egy új fájlt 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

A skript egy privát könyvtárban található és nem ad hozzáférést a weben a Pantheonhoz. Van egy skriptünk a multidev logikánkhoz. Most frissítsük a szakaszt deploy:multidev fájlt .gitlab-ci.yml, hogy így nézzen ki:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Futtasd a multidev telepítő skriptet
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Meg kell győződni arról, hogy a feladataink a létrehozott testreszabott képen futnak, így adjuk hozzá a definíciót kép a regisztrációs URL-lel a .gitlab-ci.yml. Végül egy ilyen fájlunk lett .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Lásd: 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:
    # Futtasd a multidev telepítő skriptet
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Hozzáadjuk, elkötelezzük és feltöltjük private/multidev-deploy.sh és .gitlab-ci.yml. Most térjünk vissza a GitLabhoz, és várjuk meg, amíg a CI/CD feladat végrehajtódik. Légy türelmes: a multidev létrehozása néhány percet igénybe vehet.

Aztán nézzük meg a multidev listáját a Pantheonon. Ó csoda! A multidev környezet mr-2 már itt van.

Zárás

A csapatom sokkal szórakoztatóbbá vált, amikor elkezdtük automatikusan létrehozni a merge requesteket és a környezeteket.

A GitLab és Pantheon erőteljes eszközeivel automatikusan csatlakoztathatjuk a GitLabot a Pantheonhoz.

Mivel a GitLab CI/CD-t használjuk, a munkafolyamatunk sokat fejlődhet. Íme néhány ötlet a kezdéshez:

• Adj hozzá egy build lépést.
• Adj hozzá automatizált tesztelést.
• Adj hozzá egy feladatot, hogy biztosítsd a kód standardjainak betartását.
• Adj hozzá dinamikus alkalmazásbiztonsági tesztelést.

Írd meg, mit gondolsz a GitLabról, Pantheonról és az automatizálásról.

P.S. Tudtad, hogy a Terminus, a Pantheon parancssori eszköze, kibővíthető pluginekkel??

Mi a Pantheonon szépen dolgoztunk a Terminus build eszközökhöz készült 2-es verzión. pluginjén. GitLab támogatással. Ha nem szeretne minden projekthez külön beállításokkal bíbelődni, próbálja ki ezt a bővítményt, és segítse nekünk tesztelni a v2 béta verziót. A Terminus csapatának. build:project:create csak Pantheon tokenre és GitLab tokenre van szükség. Ez telepít egy példaprojektet Composerrel és automatikus teszteléssel, létrehoz egy új GitLab projektet, egy új Pantheon webhelyet, és összekapcsolja őket környezeti változókkal és SSH kulcsokkal.

A szerzőről

Andrew Taylor eszközöket készít fejlesztők számára a Pantheon.

Forrás: habr.com