Як злучыць GitLab і Pantheon і аптымізаваць працоўныя працэсы Drupal і WordPress

Наш госць, стваральнік інструментаў для распрацоўшчыкаў з Pantheon, расказвае, як аўтаматызаваць дэплоі WordPress з дапамогай GitLab CI/CD.

В пантэон я займаюся сувязямі з распрацоўшчыкамі, таму заўсёды шукаю новыя спосабы дапамагчы распрацоўшчыкам WordPress і Drupal вырашаць праблемы з аўтаматызацыяй у працоўных працэсах. Для гэтага я люблю эксперыментаваць з новымі інструментамі і спалучаць іх сябар з сябрам для эфектыўнай працы.

Я часта бачу, як распрацоўшчыкі пакутуюць з адным прамежкавым серверам.

Так сабе задавальненне - чакаць сваёй чаргі выкарыстоўваць прамежкавы сервер або адпраўляць кліентам URL з паметкай: "Вось тут глядзець, а тут пакуль не глядзець".

Асяроддзя multidev - адзін з крутых інструментаў Pantheon - вырашаюць гэтую праблему, бо з імі можна па запыце ствараць асяроддзя пад галінкі Git. У кожнага асяроддзя multidev свой URL і база дадзеных, таму распрацоўнікі спакойна працуюць, правяраюць якасць і атрымліваюць ухвалу, не наступаючы адзін аднаму на пяткі.

Але ў Pantheon няма прылад для кантролю версій ці бесперапыннай інтэграцыі і дэплою (CI/CD). Затое гэта гнуткая платформа, з якой можна інтэграваць любыя прылады.

Яшчэ я заўважыў, што для распрацоўкі каманды выкарыстоўваюць адны інструменты, а для зборкі і дэплою - іншыя.

Напрыклад, у іх розныя прылады для кантролю версій і CI/CD. Даводзіцца важдацца і перамыкацца паміж прыладамі, каб рэдагаваць код і дыягнаставаць праблемы.

На GitLab ёсць паўнавартасны набор прылад для распрацоўкі: для кантролю версій, тикетов, мерж-рэквестаў, лепшы ў класе пайплайн CI/CD, рэестр кантэйнераў і ўсё ў такім духу. Мне пакуль не траплялася прыкладанняў, у якіх было б столькі ўсяго для кіравання працоўным працэсам распрацоўкі.

Я люблю аўтаматызацыю, таму я вывучыў, як падключыць Pantheon да GitLab, каб коміты ў галоўную галінку на GitLab дэпляваліся ў галоўным асяроддзі распрацоўкі ў Pantheon. А яшчэ мерж-рэквесты на GitLab могуць ствараць і дэплоіць код у асяроддзі multidev у Pantheon.

У гэтым кіраўніцтве я раскажу, як наладзіць злучэнне паміж GitLab і Pantheon і аптымізаваць працоўны працэс WordPress і Drupal.

Можна, вядома, адлюстраваць рэпазітар GitLab, Але мы ўсё будзем рабіць ручкамі, каб пакапацца ў GitLab CI і ў будучыні выкарыстоўваць гэты інструмент не толькі для дэплою.

Увядзенне

Для гэтай пасады трэба разумець, што Pantheon разбівае кожны сайт на тры элементы: код, база дадзеных і файлы.

У код уваходзяць файлы CMS, напрыклад ядро, убудовы і тэмы WordPress. Гэтыя файлы кіруюцца ў рэпазітары Git, размешчаным Pantheon, гэта значыць, мы можам дэплоіць код з GitLab ў Pantheon з Git.
Файламі ў Pantheon называюцца медыяфайлы, гэта значыць карцінкі для сайта. Звычайна яны загружаюцца карыстальнікамі, і Git іх ігнаруе.

Стварыце бясплатны акаўнт, даведайцеся больш пра працоўным працэсе Pantheon або запішыцеся на дэма на pantheon.io.

Здагадкі

Мой праект на Pantheon і GitLab называецца pantheon-gitlab-blog-demo. Імя праекта павінна быць унікальным. Тут мы будзем працаваць з сайтам WordPress. Можна ўзяць і Drupal, але трэба будзе сёе-тое змяніць.

Я буду выкарыстоўваць камандны радок Git, а вы можаце працаваць у графічным інтэрфейсе, калі хочаце.

Ствараем праект

Для пачатку ствараем праект GitLab (да гэтага мы яшчэ вернемся).

Цяпер ствараем сайт WordPress на Pantheon. Потым усталёўваны WordPress для дашборда сайта.

Калі рукі свярбяць нешта змяніць, напрыклад, убудовы выдаляць і падаўляць, пацярпіце. Сайт яшчэ не падлучаны да GitLab, а мы жадаем, каб усе змены кода праходзілі праз GitLab.

Калі ўсталюем WordPress, вяртаемся на дашборд сайта Pantheon і змяняем рэжым распрацоўкі на Git.

Пачатковы коміт на GitLab

Цяпер трэба перакінуць пачатковы код WordPress з сайта Pantheon на GitLab. Для гэтага клануем код з рэпазітара Git сайта Pantheon лакальна, а потым адпраўляем у рэпазітар GitLab.

Каб было прасцей і бяспечней, дадамо SSH-ключ у Pantheon і не будзем кожны раз уводзіць пароль, калі клануем рэпазітар Pantheon Git. Заадно ўжо дадамо SSH-ключ на GitLab.

Для гэтага клануем сайт Pantheon лакальна, скапіяваўшы каманду з поля Clone with Git на дашбордзе сайта.

Калі патрэбна дапамога, чытайце дакументацыю па пачатку працы з Git для Pantheon.

Цяпер зменім git remote origin, Каб паказаць на GitLab замест Pantheon. Гэта можна зрабіць командой git remote.

Пяройдзем у праект GitLab і скапіюем URL рэпазітара з выпадальнага спісу Clone на старонцы дэталяў праекта. Выберам варыянт Clone with SSH, бо мы ўжо наладзілі SSH-ключ.

Па змаўчанні git remote для лакальнай копіі рэпазітара кода origin. Гэта можна памяняць з git remote set-url origin [URL репозитория GitLab], дзе замест дужак уводзім фактычны URL.

Нарэшце, запускаем git push origin master --force, Каб адправіць код WordPress з сайта Pantheon на GitLab.

Параметр -force патрэбен толькі адзін раз. Потым у камандах git push на GitLab яго не будзе.

Наладжваем уліковыя дадзеныя і зменныя

Памятайце, як мы лакальна дадалі SSH-ключ, каб аўтарызавацца ў Pantheon і GitLab? SSH-токен можна выкарыстоўваць для аўтарызацыі GitLab і Pantheon.

У GitLab ёсць выдатная дакументацыя. Давайце паглядзім раздзел аб SSH-ключах пры выкарыстанні Docker-экзэк'ютара ў дакуменце аб выкарыстанні SSH-ключоў з GitLab CI/CD.

Цяпер мы выканаем першыя два крокі: створым новую пару SSH-ключоў лакальна з ssh-keygen і дадамо зачынены ключ як зменную ў праект.

Потым зададзім SSH_PRIVATE_KEY як зменную асяроддзі GitLab CI/CD у параметрах праекту.
На трэцім і чацвёртым кроках створым файл .gitlab-ci.yml з такім змесцівам:

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"

Пакуль не будзем камiціць файл .gitlab-ci.yml, Потым да яго трэба будзе яшчэ сёе-тое дадаць.

Цяпер выконваем пяты крок і дадаем адкрыты ключ, які стварылі ў першым кроку, да сэрвісаў, да якіх вам патрэбен доступ у асяроддзі зборкі..

У нашым выпадку мы жадаем з GitLab атрымліваць доступ да Pantheon. Прытрымліваемся інструкцыям у дакуменце Pantheon па даданні SSH-ключа ў Pantheon і выконваем гэты крок.

Памятаем: закрыты SSH у GitLab, адкрыты у Pantheon.

Наладзім яшчэ некалькі зменных асяроддзі. Першая называецца PANTHEON_SITE. Яе значэнне - імя сайта Pantheon у вас на машыне.

Імя на машыне пазначана ў канцы каманды Clone with Git. Вы ўжо кланавалі сайт лакальна, так што гэта будзе імя каталога лакальнага рэпазітара.

Далей наладзім зменнае асяроддзе PANTHEON_GIT_URL. Гэта URL рэпазітара Git для сайта Pantheon, які мы ўжо выкарыстоўвалі.

Уводзім толькі URL SSH рэпазітара, без git clone і імя сайта на машыне ў канцы.

Фух. Гэта зрабілі, зараз можам скончыць наш файл .gitlab-ci.yml.

Ствараем задачу дэплою

Тое, што мы спачатку будзем рабіць з GitLab CI, вельмі падобна на тое, што мы рабілі з рэпазітарамі Git раней. Але на гэты раз дадамо рэпазітар Pantheon як другая выдаленая крыніца Git, а потым адправім код з GitLab у Pantheon.

Для гэтага настроім этап deploy и задача deploy:dev, бо мы будзем дэплоіць у сераду распрацоўкі на Pantheon. У выніку файл .gitlab-ci.yml будзе выглядаць так:

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

зменныя SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL павінны выглядаць знаёма - мы наладзілі гэтыя зменныя асяроддзі раней. З гэтымі зменнымі мы зможам выкарыстоўваць значэнні ў файле .gitlab-ci.yml шмат разоў, а абнаўляць іх трэба будзе толькі ў адным месцы.

Нарэшце, дадамо, закамміцім і адправім файл .gitlab-ci.yml на GitLab.

Правяраем дэплой

Калі мы ўсё зрабілі правільна, заданне deploy:dev паспяхова выканаецца ў GitLab CI/CD і адправіць коміт .gitlab-ci.yml у Pantheon. Давайце паглядзім.

Адпраўляем галінкі мерж-рэквестаў у Pantheon

Тут мы будзем выкарыстоўваць маю любімую функцыю Pantheon. multidev, дзе можна па запыце ствараць дадатковыя асяроддзі Pantheon для галінак Git.

Доступ да multidev абмежаваны, так што гэты раздзел можна не выконваць. Але калі ў вас ёсць доступ, можна сур'ёзна павялічыць прадукцыйнасць, наладзіўшы аўтаматычнае стварэнне асяроддзяў multidev на Pantheon з мерж-рэквестаў GitLab.

Спачатку зробім новую галінку Git лакальна з дапамогай git checkout -b multidev-support. Цяпер зноў сёе-тое зменім у .gitlab-ci.yml.

Мне падабаецца ўказваць нумар мерж-рэквеста ў імені асяроддзя Pantheon. Напрыклад, першы мерж-рэквест mr-1, другі - mr-2 і г.д.

Мерж-рэквест мяняецца, так што нам трэба дынамічна вызначаць імёны галінак Pantheon. На GitLab гэта проста - трэба выкарыстоўваць наканаваныя зменныя асяроддзі.

Мы можам узяць $CI_MERGE_REQUEST_IID, Каб пазначыць нумар мерж-рэквеста. Давайце ўжываем усё гэта разам з глабальнымі зменнымі асяроддзі, якія паказалі раней, і дадамо новую задачу deploy:multidev у канцы файла .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

Будзе падобна на нашу задачу deploy:dev, толькі галінка адпраўляецца ў Pantheon, а не ў master.

Мы дадалі і закаміліцілі абноўлены файл .gitlab-ci.yml, а зараз адправім новую галінку ў GitLab з git push -u origin multidev-support.

Цяпер створым новы мерж-рэквест з галінкі. multidev-support, націснуўшы Create merge request.

Стварыўшы мерж-рэквест, глядзім, як выконваецца задача CI/CD deploy:multidev.

Глядзіце - у Pantheon адпраўлена новая галінка. Але калі пяройдзем у падзел multidev на дашбордзе сайта на Pantheon, не ўбачым тамака новае асяроддзе

Паглядзім падзел Git Branches.

У выніку наша галінка mr-1 дабралася да Pantheon. Створым асяроддзе з галінкі mr-1.

Мы стварылі асяроддзе multidev, а зараз вернемся ў GitLab і зазірнем у падзел Operations > Environments. Мы ўбачым запісы для dev и mr-1.

Гэта таму, што мы дадалі запіс environment з імем name и url у задачы CI/CD. Калі націснуць значок адкрытага асяроддзя, мы пяройдзем па URL асяроддзя multidev на Pantheon.

Аўтаматызуем стварэнне multidev

У прынцыпе, на гэтым можна спыніцца і проста не забываць ствараць асяроддзе multidev пад кожны мерж-рэквест, але гэты працэс можна аўтаматызаваць.

У Pantheon ёсць прылада каманднага радка Вакзал, дзе можна працаваць з платформай аўтаматычна. У Terminus можна ствараць асяроддзі multidev з каманднага радка — ідэальна для GitLab CI.

Нам патрэбен новы мерж-рэквест, каб гэта пацясціць. Створым новую галінку з дапамогай git checkout -b auto-multidev-creation.

Каб выкарыстоўваць Terminus у задачах GitLab CI/CD, патрэбен токен машыны для аўтэнтыфікацыі ў Terminus і выява кантэйнера з Terminus.

Ствараем токен машыны Pantheon, захоўваем яго ў бяспечным месцы і дадаем як глабальную зменную асяроддзі ў GitLab з імем PANTHEON_MACHINE_TOKEN.

Калі забыліся, як дадаваць зменныя асяроддзі GitLab, вярніцеся туды, дзе мы вызначалі PANTHEON_SITE.

Ствараем Dockerfile з Terminus

Калі вы не карыстаецеся Docker або недалюбліваеце файлы Dockerfile, вазьміце мой вобраз registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest і прапусціце гэты раздзел.

У GitLab ёсць рэестр кантэйнераў, дзе можна сабраць і размясціць Dockerfile для нашага праекту. Давайце створым файл Dockerfile з Terminus, каб працаваць з Pantheon.

Terminus - гэта прылада каманднага радка на PHP, так што пачнем з выявы PHP. Я ўсталёўваю Terminus праз Composer, таму за аснову вазьму афіцыйны вобраз Docker Composer. Ствараем Dockerfile у каталогу лакальнага рэпазітара з такім змесцівам:

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

Прытрымліваемся інструкцый па зборцы і адпраўцы выяў з часткі Build and push images в дакументацыі рэестра кантэйнераў, каб сабраць вобраз з Dockerfile і адправіць яго ў GitLab.

Адкрываем падзел рэестр у праекце GitLab. Калі ўсё пайшло па плане, там будзе наша выява. Запішыце спасылку на тэг выявы — яна патрэбна нам для файла .gitlab-ci.yml.

Раздзел script у задачы deploy:multidev пачынае разрастацца, так што давайце перанясем яго ў асобны файл. Ствараем новы файл 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

Скрыпт ляжыць у прыватным каталогу і не дае вэб-доступ на Pantheon. Мы маем скрыпт для нашай логікі multidev. Давайце зараз абновім падзел deploy:multidev файл .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:
    # Run the multidev deploy script
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Трэба пераканацца, што нашы задачы выконваюцца ў створанай кастамнай выяве, так што дадамо азначэнне image з URL рэестра ў .gitlab-ci.yml. У выніку ў нас атрымаўся такі файл .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

Дадаем, комитим і адпраўляем private/multidev-deploy.sh и .gitlab-ci.yml. Цяпер вяртаемся ў GitLab і чакаем, пакуль выканаецца задача CI/CD. Патрываеце: multidev можа стварацца некалькі хвілін.

Потым ідзем глядзець сьпіс multidev на Pantheon. Аб цуд! Серада multidev mr-2 ужо тут.

Заключэнне

Мая каманда зарабіла значна весялей, калі мы сталі адкрываць мерж-рэквесты і ствараць асяроддзя аўтаматычна.

З магутнымі прыладамі GitLab і Pantheon можна падлучыць GitLab да Pantheon аўтаматычна.

Раз мы выкарыстоўваем GitLab CI/CD, нашаму працоўнаму працэсу будзе куды расці. Вось пара ідэй, каб прыступіць да працы:

• Дадайце крок зборкі.
• Дадайце аўтаматызаванае тэсціраванне.
• Дадайце задачу, каб гарантаваць захаванне стандартаў кода.
• дадайце дынамічнае тэсціраванне бяспекі прыкладанняў.

Напішыце, што вы думаеце аб GitLab, Pantheon і аўтаматызацыі.

PS А вы ведалі, што Terminus, прылада каманднага радка Pantheon, можна пашыраць праз убудовы?

Мы ў Pantheon нядрэнна папрацавалі над версіяй 2 нашага плагіна для інструментаў зборкі Terminus з падтрымкай GitLab. Калі вы не жадаеце важдацца з наладай для кожнага праекта, паспрабуйце гэты плягін і дапамажыце нам пацясціць бэту v2. Для каманды Terminus build:project:create патрэбен толькі токен Pantheon і токен GitLab. Яна разгорне адзін з прыкладаў праекта з Composer і аўтаматычным тэсціраваннем, створыць новы праект у GitLab, новы сайт Pantheon, і злучыць іх з дапамогай зменных асяроддзя і SSH-ключоў.

Пра аўтара

Эндру Тэйлар (Andrew Taylor) стварае прылады для распрацоўшчыкаў у пантэон.

Крыніца: habr.com