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

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

В Пантеон Аз съм в отношения с разработчици, така че винаги търся нови начини да помогна на разработчиците на WordPress и Drupal да решат проблеми с автоматизацията в работните процеси. За да направя това, обичам да експериментирам с нови инструменти и да ги комбинирам един с друг, за да работят ефективно.

Често виждам как разработчиците се борят с един единствен сървър за етапи.

Толкова забавно – изчакване на вашия ред за използване на междинен сървър или изпращане на клиенти на URL адрес с надпис: „Вижте тук, но още не гледайте тук“.

мултиразработващи среди - един от страхотните инструменти на Pantheon - решава този проблем, защото с тях можете да създавате среди за Git клонове при поискване. Всяка мултидев среда има свой собствен URL адрес и база данни, така че разработчиците да могат да работят, да проверяват качеството и да получават одобрение, без да си стъпват по петите.

Но Pantheon няма инструменти за контрол на версиите или непрекъсната интеграция и внедряване (CI/CD). Но това е гъвкава платформа, с която можете да интегрирате всякакви инструменти.

Забелязах също, че екипите използват някои инструменти за разработка, а други за изграждане и внедряване.

Например, те имат различни инструменти за контрол на версиите и CI/CD. Трябва да си играете и да превключвате между инструменти за редактиране на код и диагностициране на проблеми.

На GitLab има пълен набор от инструменти за разработка: контрол на версиите, билети, заявки за сливане, най-добрият в класа CI / CD тръбопровод, регистър на контейнери и други подобни. Все още не съм срещал приложение, което има толкова много за управление на работния процес на разработка.

Обичам автоматизацията, така че научих как да свържа Pantheon с GitLab, така че ангажиментите към главния клон на GitLab да бъдат разгърнати в основната среда за разработка в Pantheon. Заявките за сливане на GitLab също могат да създават и разгръщат код в мултиразработващи среди в 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и можете да работите в GUI, ако искаш.

Създайте проект

Като начало създаваме Проект GitLab (ще се върнем към това по-късно).

Сега създаване на WordPress сайт на Pantheon. След това инсталирайте WordPress за таблото за управление на сайта.

Ако ви сърбят ръцете да промените нещо, например да премахнете и добавите плъгини, бъдете търпеливи. Сайтът все още не е свързан с GitLab и искаме всички промени в кода да минават през GitLab.

След като WordPress е инсталиран, върнете се към таблото за управление на Pantheon и променете режима на разработка на Git.

Първоначално ангажиране на GitLab

Сега трябва да прехвърлите първоначалния код на WordPress от сайта на Pantheon в GitLab. За да направим това, клонираме локално кода от Git хранилището на сайта на Pantheon и след това го изпращаме в GitLab хранилището.

За да бъде по-лесно и по-безопасно, добавете SSH ключ към Pantheon и няма да въвеждаме паролата всеки път, когато клонираме Git хранилището на Pantheon. В същото време вече добавете 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, тогава ще трябва да добавите нещо друго към него.

Сега направете петата стъпка и добавете публичния ключ, който сте създали в първата стъпка, към услугите, до които имате нужда от достъп в средата за изграждане.

В нашия случай искаме да имаме достъп до Pantheon от GitLab. Следвайте инструкциите в документа на 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 − multidevкъдето можете да създадете допълнителни среди на Pantheon за клонове на Git при поискване.

Достъпът до 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, само клонът отива към Пантеона, а не към master.

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

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

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

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

Нека да разгледаме секцията Git Branches.

В резултат на това нашият клон mr-1 стигна до Пантеона. Създайте среда от клон mr-1.

Създадохме мултидев среда, сега нека се върнем към GitLab и да разгледаме секцията Операции > Среди. Ще видим записи за dev и mr-1.

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

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

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

Pantheon има инструмент за команден ред Крайна спиркакъдето можете да работите с платформата автоматично. Terminus ви позволява да създавате мултиразработващи среди от командния ред - идеално за GitLab CI.

Имаме нужда от нова заявка за сливане, за да тестваме това. Създайте нов клон с git checkout -b auto-multidev-creation.

За да използвате Terminus в GitLab CI/CD задачи, имате нужда от машинен токен за удостоверяване с Terminus и изображение на контейнер на Terminus.

Създаване на машинен токен Pantheon, запазете го на сигурно място и го добавете като глобална променлива на средата в GitLab с името PANTHEON_MACHINE_TOKEN.

Ако сте забравили как да добавите променливи на средата на GitLab, върнете се там, където сме дефинирали PANTHEON_SITE.

Създайте Docker файл с 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"

Следвайте инструкциите за изграждане и изпращане на изображения от раздела Изградете и прокарайте изображения в документация на регистъра на контейнеритеза сглобяване на изображение от 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 може да отнеме няколко минути.

След това отиваме да разгледаме списъка с множество програми в Pantheon. О, чудо! мултидев среда mr-2 вече тук.

Заключение

Екипът ми се забавляваше много повече, когато започнахме автоматично да отваряме заявки за сливане и да създаваме среди.

С мощните инструменти на GitLab и Pantheon можете автоматично да свържете GitLab към Pantheon.

Тъй като използваме GitLab CI/CD, нашият работен процес ще има място за растеж. Ето няколко идеи, за да започнете:

• Добавете стъпка на изграждане.
• Добавете автоматизирано тестване.
• Добавете задача, за да гарантирате спазването на стандартите за код.
• Добави динамично тестване на сигурността на приложението.

Напишете какво мислите за GitLab, Pantheon и автоматизацията.

PS Знаете ли, че Terminus, инструментът на командния ред на Pantheon, може да се разшири чрез добавки?

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

За автора

Андрю Тейлър създава инструменти за разработчици в Пантеон.

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