Как да свържете GitLab с Pantheon и да оптимизирате работните потоци на Drupal и WordPress

Нашият гост, създател на инструменти за разработчици от Pantheon, разказва как да автоматизирате деплойването на WordPress с помощта на GitLab CI/CD.

В Pantheon Занимавам се с връзки с разработчици, затова винаги търся нови начини да помогна на разработчиците на 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:
  # Вижте 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, който вече сме използвали.

Въвеждаме само SSH URL адреса на репозитория, без git clone и името на сайта на машината в края.

Уф. Това го направихме, сега можем да завършим файла си .gitlab-ci.yml.

Създава се задача за деплой

Това, което ще правим в началото с GitLab CI, много прилича на това, което правихме по-рано с Git репозиториите. Но този път ще добавим репозиторий Pantheon като втори отдалечен Git източник и след това ще изпратим кода от GitLab в Pantheon.

За целта ще настроим етап deploy и задача deploy:dev, тъй като ще деплоим в средата за разработка в Pantheon. В резултат файлът .gitlab-ci.yml ще изглежда така:

етапи:
- разгръщане

преди_скрипт:
  # Вижте 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"

разгръщане:dev:
  стадий: разгръщане
  среда:
    име: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  скрипт:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  само:
    - 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, за да посочим номера на мърдж реквеста. Нека да приложим всичко това заедно с глобалните променливи на средата, които споменахме по-рано, и добавим нова задача разгръщане:multidev в края на файла .gitlab-ci.yml.

разгръщане:multidev:
  стадий: разгръщане
  среда:
    име: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  скрипт:
    # Проверка на източния клон на мърдж реквеста
    - git checkout $CI_COMMIT_REF_NAME
    # Добавяне на Git репозитория на Pantheon като допълнителен remote
    - git remote add pantheon $PANTHEON_GIT_URL
    # Изпращане на източния клон на мърдж реквеста в Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  само:
    - merge_requests

Ще изглежда като нашата задача deploy:dev, само че клонът се изпраща в Pantheon, а не в master.

Добавили сме и комитнали актуализирания файл .gitlab-ci.yml, а сега ще изпратим новия клон в GitLab с git push -u origin multidev-support.

Сега ще създадем нов мерж р запрос от клон multidev-support, натискайки Създаване на мерж р запрос.

След като създадем мерж р запроса, ще видим как протича задачата CI/CD deploy:multidev.

Вижте, в Pantheon е изпратен нов клон. Но ако отидем в раздела multidev на таблото за управление на сайта в Pantheon, там няма да видим нова среда

Нека погледнем раздела Git Branches.

В резултат нашият клон mr-1 стигна до Pantheon. Нека създадем среда от клона mr-1.

Създадохме среда multidev, а сега да се върнем в GitLab и да погледнем в раздела Operations > Environments. Ще видим записите за dev и mr-1.

Това е, защото добавихме запис среда с името name и url в задачите CI/CD. Ако натиснете иконата на отворената среда, ще отидем на URL на средата multidev в Pantheon.

Автоматизираме създаването на multidev

По принцип, тук можем да спрем и просто да не забравяме да създаваме среда multidev за всяко мерж р запитване, но този процес може да бъде автоматизиран.

В Pantheon има инструмент за команден ред Terminus, където можем да работим с платформата автоматично. В 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.

Отваряме раздела Registry в проекта GitLab. Ако всичко е минало по плана, там ще е нашият образ. Запишете линка на таг образа - той ни е необходим за файла. .gitlab-ci.yml.

Раздел скрипт в задачата 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:
    # Извършете скрипта за разгръщане на multidev
    - "/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:
  # Вижте 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:
    # Извършете скрипта за разгръщане на multidev
    - "/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 и автоматизацията.

P.S. Знаехте ли, че Terminus, инструментът за команден ред на Pantheon, може да се разширява чрез плъгини?

Ние в Pantheon работихме усърдно над версия 2 на нашия плъгин за инструментите за изграждане на Terminus с поддръжка на GitLab. Ако не искате да се занимавате с настройките за всеки проект, опитайте този плъгин и ни помогнете да тестваме бета версията v2. За екипа на Terminus build:project:create нужен е само токен на Pantheon и токен на GitLab. Той ще разгръща един от примерите за проект с Composer и автоматизирано тестване, ще създаде нов проект в GitLab, нов сайт на Pantheon и ще ги свърже чрез променливи на средата и SSH ключове.

За автора

Андрю Тейлър (Andrew Taylor) създава инструменти за разработчици в Pantheon.

Източник: habr.com