Як поєднати 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"

Поки не будемо комітувати файл .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