Si të lidhni GitLab me Pantheon dhe të optimizoni punët e përditshme të Drupal dhe WordPress

E ftuar, krijuesi i mjeteve për zhvillues nga Pantheon, tregon se si të automatizosh deplojet e WordPress me ndihmën e GitLab CI/CD.

Në Pantheon Unë merrem me marrëdhënie me zhvilluesit, prandaj gjithmonë kërkoj mënyra të reja për t'i ndihmuar ata në WordPress dhe Drupal për të zgjidhur problemet me automatizimin në proceset e punës. Për këtë, më pëlqen të eksperimentoj me mjete të reja dhe të kombinoj ato për punë efikase.

shpesh e shoh se zhvilluesit vuajnë me një server ndërmjetës.

Nuk është ndonjë kënaqësi e madhe - të presësh radhën tënde për të përdorur serverin ndërmjetës ose të dërgosh klientëve një URL me shënimin: "Këtu shiko, e këtu mos shiko për tani".

Mjediset multidev — një nga mjetet e shkëlqyera të Pantheon — zgjidhin këtë problem, pasi me to mund të krijosh mjedise sipas degëve Git me kërkesë. Çdo mjedis multidev ka URL dhe bazën e të dhënave të tij, kështu që zhvilluesit punojnë pa shqetësim, kontrollojnë cilësinë dhe marrin miratimin, pa i penguar njëri-tjetrin.

Por në Pantheon nuk ka mjete për kontrolle versioni ose integrim dhe deplojim të vazhdueshëm (CI/CD). Megjithatë, kjo është një platformë fleksibile, me të cilën mund të integrohen çdo lloj mjeti.

Po ashtu, kam vënë re se për zhvillim ekipet përdorin mjete të ndryshme, ndërsa për ndërtim dhe deploy - të tjera.

Për shembull, ata kanë mjete të ndryshme për kontrollin e versioneve dhe CI/CD. Duhet të merret me dhe të kalojë midis mjeteve për të redaktuar kodin dhe diagnostikuar problemet.

Në GitLab ka një grup të plotë mjetesh për zhvillim: për kontrollin e versioneve, bileta, kërkesat për bashkim, një pipeline CI/CD më të mirin në klasë, një regjistër konteinerash dhe të gjitha këto. Nuk kam hasur deri tani në aplikacione që ofrojnë kaq shumë për menaxhimin e procesit të punës në zhvillim.

E adhuroj automatizimin, prandaj kam studiuar se si të lidh Pantheon me GitLab, për të bërë që komitetet në degën kryesore në GitLab të deplohen në ambientin kryesor të zhvillimit në Pantheon. Gjithashtu, kërkesat për bashkim në GitLab mund të krijojnë dhe të deplojnë kodin në mjediset multidev në Pantheon.

Në këtë udhëzues, do të tregoj se si të konfigurosh lidhjen midis GitLab dhe Pantheon dhe të optimizosh procesin e punës për WordPress dhe Drupal.

Sigurisht, mund të pasqyrosh repositorin GitLab, por ne do të bëjmë gjithçka me duar, për të hulumtuar në GitLab CI dhe në të ardhmen të përdorim këtë mjet jo vetëm për deploy.

Hyrje

Për këtë post, duhet të kuptoni se Pantheon e ndan çdo faqe në tre elementë: kodi, baza e të dhënave dhe skedarët.

Kodi përfshin skedarët e CMS, si bërthama, shtojcat dhe temat e WordPress. Këta skedarë menaxhohen në repozitoret Git, të vendosura në Pantheon, domethënë mund të depozitojmë kodin nga GitLab në Pantheon me Git.
Skedarët në Pantheon quhen skedarë medie, domethënë imazhe për faqen. Zakonisht ngarkohen nga përdoruesit dhe Git i injoron ato.

Krijoni një llogari falas, mësoni më shumë rreth procesit të punës Pantheon ose regjistrohuni për një demo në pantheon.io.

Supozime

Projekti im në Pantheon dhe GitLab quhet pantheon-gitlab-blog-demo. Emri i projektit duhet të jetë unik. Këtu do të punojmë me një faqe WordPress. Mund të përdorim gjithashtu Drupal, por do të nevojiten disa ndryshime.

Do të përdor linjë komandash Git, por ju mund të punoni në ndërfaqen grafike, nëse dëshironi.

Krijojmë projektin

Së pari krijojmë projektin GitLab (për këtë do të kthehemi më vonë).

tregon atë që pritej: krijojmë një faqe WordPress në Pantheon. Pastaj instalohet WordPress për panelin e faqes.

Nëse keni dëshirë të ndryshoni diçka, si të hiqni dhe shtoni shtojca, duroni. Faqja ende nuk është e lidhur me GitLab, dhe ne dëshirojmë që të gjitha ndryshimet e kodit të kalojnë përmes GitLab.

Kur të instalojmë WordPress, kthehemi në panelin e faqes Pantheon dhe ndryshojmë modalitetin e zhvillimit në Git.

Komiteti fillestar në GitLab

Tani duhet të japim fillimin e kodit WordPress nga faqja Pantheon në GitLab. Për këtë e klonojmë kodin nga repoziotori Git i faqes Pantheon lokal, dhe pastaj e dërgojmë në repoziotori GitLab.

Për ta bërë më të lehtë dhe më të sigurt, shtojmë çelësin SSH në Pantheon dhe nuk do të hyjmë çdo herë fjalëkalimin kur klonojmë repoziotorin Pantheon Git. Njëkohësisht, tashmë shtojmë çelësin SSH në GitLab.

Për këtë e klonojmë faqen Pantheon lokal, duke kopjuar komandën nga fusha Clone with Git në panelin e faqes.

Nëse keni nevojë për ndihmë, lexoni dokumentacionin për fillimin e punës me Git për Pantheon.

Tani do të ndryshojmë git remote origin, për të treguar për GitLab në vend të Pantheon. Kjo mund të bëhet me komandën git remote.

Për të kaluar në projektin GitLab dhe kopjuar URL-në e repoziotorit nga lista zbritëse Clone në faqen e detajeve të projektit. Zgjidhni opsionin Clone with SSH, pasi e kemi konfiguruar tashmë çelësin SSH.

Më në default git remote për kopjen lokale të repoziotorit të kodit - origin. Kjo mund të ndryshohet nga git remote set-url origin [URL repoziotori GitLab], ku në vend të kllapave vendosim URL-në reale.

Në fund, ekzekutojmë git push origin master --force, për të dërguar kodin WordPress nga faqja Pantheon në GitLab.

Parametri –force përdoret vetëm një herë. Më pas në komandat git push në GitLab nuk do të jetë.

Konfigurojmë kredencialet dhe variablat

Mos haroni si kemi shtuar lokalisht çelësin SSH për t'u autorizuar në Pantheon dhe GitLab? Tokeni SSH mund të përdoret për autorizim në GitLab dhe Pantheon.

GitLab ka dokumentacion të shkëlqyer. Le të shohim seksionin mbi çelësat SSH kur përdorni ekzekutorin Docker në dokumentin mbi përdorimin e çelësave SSH me GitLab CI/CD.

Tani do të kryejmë dy hapat e parë: do të krijojmë një çift të ri çelësash SSH lokalisht me ssh-keygen dhe do të shtojmë çelësin e mbyllur si një variabël në projekt.

Më pas do të caktosh SSH_PRIVATE_KEY si variablën e ambientit GitLab CI/CD në parametrat e projektit.
Në hapin e tretë dhe të katërt do të krijojmë skedarin .gitlab-ci.yml me këtë përmbajtje:

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

Për momentin nuk do ta komitojmë skedarin .gitlab-ci.yml, pasi më pas do t'i shtojmë disa gjëra më shumë.

Tani kryejmë hapin e pestë dhe shtojmë çelësin e hapur që krijuam në hapin e parë në shërbimet që ju nevojiten për qasje në ambientin e ndërtimit.

Në rastin tonë ne duam të kemi qasje nga GitLab në Pantheon. Ndiqni udhëzimet në dokumentin e Pantheon për shtimin e çelësit SSH në Pantheon dhe realizoni këtë hap.

Mos haroni: çelësi privat SSH është në GitLab, çelësi i hapur është në Pantheon.

Do të konfigurojmë disa variabla të tjerë të ambientit. I pari quhet PANTHEON_SITE. Vlera e saj është emri i sitit Pantheon që keni në makinë.

Emri në makinë është i shënuar në fund të komandës Clone with Git. Ju tashmë e keni klonuar sitin lokalisht, kështu që kjo do të jetë emri i katalogut të depove lokale.

Më pas do të konfigurojmë variablën e ambientit PANTHEON_GIT_URL. Ky është URL-ja e depozitës Git për sitin Pantheon, që kemi përdorur tashmë.

Futni vetëm URL-në SSH të depozitës, pa git clone dhe emrin e sitit në makinë në fund.

Ah. E bëjmë këtë, tani mund ta përfundojmë skedarin tonë .gitlab-ci.yml.

Krijojmë një detyrë deploy

Ajo që do të bëjmë fillimisht me GitLab CI është shumë e ngjashme me atë që kemi bërë me depozitë Git më parë. Por këtë herë do ta shtojmë depozitën Pantheon si një burim të dytë të largët Git, dhe më pas do ta dërgojmë kodin nga GitLab në Pantheon.

Për këtë do të konfigurojmë fazën deploy dhe detyrën deploy:dev, pasi do ta shpërndajmë në ambientin e zhvillimit në Pantheon. Si rezultat, skedari .gitlab-ci.yml do të duket kështu:

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

Variablat SSH_PRIVATE_KEY, PANTHEON_SITE dhe PANTHEON_GIT_URL duhet të duken familjare - ne i ndaluam këto variabla ambienti më parë. Me këto variabla, do të mund të përdorim vlerat në skedarin .gitlab-ci.yml marrë parasysh, dhe t’i përditësojmë vetëm në një vend.

Më në fund, do të shtojmë, do ta angazhojmë dhe do ta dërgojmë skedarin .gitlab-ci.yml në GitLab.

Po kontrollojmë deploy-in

Nëse e kemi bërë gjithçka siç duhet, detyra deploy:dev do të kryhet me sukses në GitLab CI/CD dhe do të dërgojë angazhimin .gitlab-ci.yml në Pantheon. Le ta shohim.

Dërgojmë degët e kërkesave për bashkim në Pantheon

Këtu do të përdorim funksionin tim të preferuar në Pantheon - multidev, ku mund të krijojmë ambient të tjerë Pantheon për degët Git në kërkesë.

Aksesi në multidev është i kufizuar, kështu që ky seksion mund të mos ekzekutohet. Por nëse keni qasje, mund të rrisni ndjeshëm performancën, duke konfiguruar krijimin automatik të ambienteve multidev në Pantheon nga kërkesat për bashkim në GitLab.

Së pari, do të bëjmë një degë të re Git në mënyrë lokale duke përdorur git checkout -b multidev-support. Tani përsëri do të bëjmë disa ndryshime në .gitlab-ci.yml.

Më pëlqen të përcaktoj numrin e kërkesës për bashkim në emrin e ambientit Pantheon. Për shembull, kërkesa e parë për bashkim është mr-1, kërkesa e dytë është mr-2 etj.

Kërkesa për bashkim ndryshon, kështu që na nevojitet të përcaktojmë dinamikisht emrat e degëve Pantheon. Në GitLab, kjo është e thjeshtë - duhet të përdorim variablat ambienti të paracaktuar.

Mund të marrim $CI_MERGE_REQUEST_IID, për të përcaktuar numrin e kërkesës për bashkim. Le ta aplikojmë të gjithë këtë së bashku me variablat globalë të ambientit që i përcaktuam më parë dhe të shtojmë një detyrë të re deploy:multidev në fund të skedarit .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:
    # Merrni degën burimore të kërkesës për bashkim
    - git checkout $CI_COMMIT_REF_NAME
    # Shtoni repositorin git të Pantheon si një remote shtesë
    - git remote add pantheon $PANTHEON_GIT_URL
    # Dërgoni degën burimore të kërkesës për bashkim në Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  only:
    - merge_requests

Do të duket si detyra jonë deploy:dev, vetëm se dega dërgohet në Pantheon, jo në master.

Kemi shtuar dhe angazhuar skedarin e përditësuar .gitlab-ci.yml, dhe tani do ta dërgojmë degën e re në GitLab me git push -u origin multidev-support.

Tani do të krijojmë një kërkesë të re për bashkim nga dega mbështetje multidev, duke klikuar Krijoni kërkesën e bashkimit.

Pasi krijoni kërkesën e bashkimit, shikoni se si po kryhet detyra CI/CD deploy:multidev.

Shikoni - një degë e re është dërguar në Pantheon. Por nëse kalojmë tek seksioni multidev në panelin e kontrollit të faqeve në Pantheon, nuk do ta shohim atë mjedis të ri

Le të shohim seksionin Git Branches.

Në fund, dega jonë mr-1 arriti në Pantheon. Le të krijojmë një mjedis nga dega mr-1.

Ne krijuam mjedisin multidev, tani le të kthehemi në GitLab dhe të shikojmë në seksionin Operacionet > Mjediset. Do të shohim regjistrimet për dev dhe mr-1.

Kjo është për shkak se ne shtuam regjistrimin mjedis me emrin emri dhe url në detyrat CI/CD. Nëse klikohet ikona e mjedisit të hapur, ne do të kalojmë në URL-në e mjedisit multidev në Pantheon.

Automatizojmë krijimin e multidev

Në të vërtetë, këtu mund të ndalojmë dhe thjesht të mos harrojmë të krijojmë mjedisin multidev për çdo kërkesë bashkimi, por ky proces mund të automatizohet.

Në Pantheon ka një mjet komandash Terminus, ku mund të punoni automatikisht me platformën. Në Terminus mund të krijoni mjedise multidev nga komandat - ideal për GitLab CI.

Na nevojitet një kërkesë e re bashkimi për ta testuar këtë. Le të krijojmë një degë të re duke përdorur git checkout -b auto-multidev-creation.

Për të përdorur Terminus në detyrat GitLab CI/CD, nevojitet një token makinerie për autentifikimin në Terminus dhe një imazh kontejneri me Terminus.

Krijojmë tokenin e makinerisë Pantheon, e ruajmë atë në një vend të sigurt dhe e shtojmë si një variabël globale mjedisi në GitLab me emrin PANTHEON_MACHINE_TOKEN.

Nëse e keni harruar se si të shtoni variablat e mjedisit në GitLab, kthehuni atje ku e përcaktuam PANTHEON_SITE.

Krijojmë Dockerfile me Terminus

Nëse nuk po përdorni Docker ose nuk e pëlqeni dosjen Dockerfile, merrni imazhin tim registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest dhe kaloni këtë seksion.

Në GitLab ka një regjistër kontejnerësh, ku mund të ndërtosh dhe publikosh Dockerfile për projektin tonë. Le të krijojmë një skedë Dockerfile me Terminus për të punuar me Pantheon.

Terminus është një mjet komandash në PHP, kështu që le të fillojmë me imazhin PHP. Unë e instaloj Terminus përmes Composer, kështu që do të marr si bazë imazhin zyrtar Docker Composer. Krijojmë Dockerfile në katalogun e depozitës lokale me përmbajtjen e tillë:

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

Pasojmë udhëzimet për ndërtimin dhe dërgimin e imazheve nga seksioni Build and push images në i dokumentacionit të regjistrit të kontejnerëve, për të ndërtuar imazhin nga Dockerfile dhe për ta dërguar atë në GitLab.

Hapim seksionin Regjistri në projektin GitLab. Nëse gjithçka shkoi sipas planit, aty do të jetë imazhi ynë. Shkruani lidhjen për etiketën e imazhit - na nevojitet për skedarin .gitlab-ci.yml.

Seksioni script në detyrë deploy:multidev po fillon të rritet, kështu që le ta transferojmë atë në një skedar të veçantë. Të krijojmë një skedar të ri 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

Scripti ndodhet në katalogun privat dhe nuk lejon qasje në web në Pantheon. Ne kemi një script për logjikën tonë multidev. Le të azhurnojmë tani seksionin deploy:multidev skedare .gitlab-ci.yml, në mënyrë që të duket kështu:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Ekzekutoni scriptin e kthimit multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Duhet të sigurohemi që detyrat tona të ekzekutohen në imazhin e krijuar personal, kështu që le të shtojmë një definicion image me URL-në e regjistrit në .gitlab-ci.yml. Si rezultat, kemi një skedar të tillë .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Shihni 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:
    # Ekzekutoni scriptin e kthimit multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Shtojmë, komitim dhe dërgojmë private/multidev-deploy.sh dhe .gitlab-ci.yml. Tani kthehemi në GitLab dhe presim që të përfundojë detyra CI/CD. Rini prapa: multidev mund të krijohet për disa minuta.

Pastaj shkojmë të shohim listën e multidev në Pantheon. O çudi! Ambienti multidev mr-2 është këtu.

Përfundim

Ekipi im ka punuar shumë më mirë kur filluam të hapim kërkesat për bashkim dhe të krijojmë ambiente automatikisht.

Me mjete të fuqishme si GitLab dhe Pantheon mund të lidhim GitLab me Pantheon automatikisht.

Duke qenë se po përdorim GitLab CI/CD, procesi ynë do të ketë shumë hapësirë për t'u rritur. Këtu janë disa ide për të filluar:

• Shtoni një hap të ndërtimit.
• Shtoni testime automatike.
• Shtoni një detyrë për të siguruar përputhshmërinë me standardet e kodit.
• Shtoni testimin dinamik të sigurisë së aplikacioneve.

Shkruani se çfarë mendoni për GitLab, Pantheon dhe automatizimin.

P.S. A dini se Terminus, mjeti i komandës për Pantheon, mund të zgjerohet përmes plugins?

Ne në Pantheon kemi punuar me përkushtim mbi versionin 2 të plugin-it tonë për mjetet e ndërtimit Terminus me mbështetje për GitLab. Nëse nuk dëshironi të merrni me konfigurimin për çdo projekt, provoni këtë plugin dhe na ndihmoni të testojmë betën v2. Për ekipin Terminus build:project:create kërkohet vetëm një token Pantheon dhe një token GitLab. Ai do të dislokojë një nga shembujt e projektit me Composer dhe testimin automatike, do të krijojë një projekt të ri në GitLab, një faqe të re në Pantheon dhe do t'i lidhë ata me variablat e ambientit dhe çelësat SSH.

Rreth autorit

Andrew Taylor krijon mjete për zhvilluesit në Pantheon.

Burimi: habr.com