🥇Jak połączyć GitLab i Pantheon oraz zoptymalizować przepływy pracy Drupal i WordPress

Nasz gość, twórca narzędzi dla deweloperów z Pantheon, opowiada, jak automatyzować wdrożenia WordPress za pomocą GitLab CI/CD.

W Pantheon Zajmuję się relacjami z deweloperami, więc zawsze szukam nowych sposobów, aby pomóc programistom WordPress i Drupal rozwiązywać problemy z automatyzacją w procesach roboczych. Uwielbiam eksperymentować z nowymi narzędziami i łączyć je ze sobą dla efektywnej pracy.

Często widzę, jak deweloperzy borykają się z jednym serwerem pośredniczącym.

To niezbyt przyjemne — czekać na swoją kolej, aby skorzystać z serwera pośredniczącego lub wysyłać klientom URL z adnotacją: „Tutaj patrzcie, a tu na razie nie patrzcie”.

Środowiska multidev — to jedno z fajnych narzędzi Pantheon — rozwiązują ten problem, ponieważ umożliwiają tworzenie środowisk dla gałęzi Git na żądanie. Każde środowisko multidev ma własny URL i bazę danych, dzięki czemu deweloperzy mogą spokojnie pracować, kontrolować jakość i uzyskiwać zatwierdzenie, nie depcząc sobie po piętach.

Jednak w Pantheon nie ma narzędzi do kontroli wersji ani ciągłej integracji i wdrożenia (CI/CD). Ale to elastyczna platforma, która pozwala integrować dowolne narzędzia.

Dodatkowo zauważyłem, że zespoły używają różnych narzędzi do rozwoju, a innych do budowy i wdrożenia.

Na przykład mają różne narzędzia do kontroli wersji i CI/CD. Muszą się męczyć i przełączać między narzędziami, aby edytować kod i diagnozować problemy.

Na GitLab Mam pełny zestaw narzędzi do rozwoju: do kontroli wersji, biletów, zapytań o złączenia, najlepszy w swojej klasie pipeline CI/CD, rejestr kontenerów i tym podobne. Jeszcze nie spotkałem aplikacji, która miałaby tak wiele do zarządzania procesem roboczym w rozwoju.

Uwielbiam automatyzację, dlatego dowiedziałem się, jak połączyć Pantheon z GitLab, aby commity do głównej gałęzi na GitLab były wdrażane w głównym środowisku roboczym w Pantheon. Ponadto zapytania o złączenie na GitLab mogą tworzyć i wdrażać kod w środowiskach multidev w Pantheon.

W tym przewodniku opiszę, jak skonfigurować połączenie między GitLab a Pantheon i zoptymalizować proces roboczy WordPress i Drupal.

Można oczywiście odzwierciedlić repozytorium GitLab, ale wszystko zrobimy ręcznie, aby pokopać w GitLab CI i w przyszłości używać tego narzędzia nie tylko do wdrożeń.

Wprowadzenie

Aby zrozumieć tę wiadomość, musisz wiedzieć, że Pantheon dzieli każdą stronę na trzy elementy: kod, bazę danych i pliki.

Kod obejmuje pliki CMS, takie jak rdzeń, wtyczki i motywy WordPressa. Te pliki są zarządzane w repozytorium Git, umieszczonym na Pantheon, co oznacza, że możemy wdrażać kod z GitLab do Pantheon za pomocą Gita.
W Pantheon pliki to multimedia, czyli obrazy dla strony. Zazwyczaj są one ładowane przez użytkowników, a Git je ignoruje.

Utwórz darmowe konto, dowiedz się więcej o procesie roboczym Pantheon lub zapisz się na demo na pantheon.io.

Założenia

Mój projekt na Pantheon i GitLab nazywa się pantheon-gitlab-blog-demo. Nazwa projektu musi być unikalna. Tutaj będziemy pracować z witryną WordPress. Można też wziąć Drupal, ale trzeba będzie dokonać pewnych zmian.

Będę używać wiersza poleceń Git, a wy możecie pracować w interfejsie graficznym, jeśli chcecie.

Tworzymy projekt

Na początek tworzymy projekt GitLab (do tego jeszcze wrócimy).

pokazuje to, czego się spodziewano: tworzymy stronę WordPress na Pantheon. Następnie instalujemy WordPress dla pulpitu nawigacyjnego strony.

Jeśli masz ochotę coś zmienić, na przykład usunąć lub dodać wtyczki, powstrzymaj się. Witryna nie jest jeszcze połączona z GitLab, a chcemy, by wszystkie zmiany kodu przechodziły przez GitLab.

Gdy zainstalujemy WordPress, wracamy do pulpitu nawigacyjnego Pantheon i zmieniamy tryb rozwoju na Git.

Początkowy commit na GitLab

Teraz musimy przesłać początkowy kod WordPress z witryny Pantheon do GitLab. W tym celu klonujemy kod z repozytorium Git witryny Pantheon lokalnie, a następnie wysyłamy go do repozytorium GitLab.

Aby było prościej i bezpieczniej, dodamy klucz SSH do Pantheon i nie będziemy musieli za każdym razem wpisywać hasła, gdy klonujemy repozytorium Pantheon Git. Przy okazji już dodamy klucz SSH do GitLab.

W tym celu klonujemy witrynę Pantheon lokalnie, kopiując polecenie z pola Klonuj z Gitem na pulpicie witryny.

Jeśli potrzebujesz pomocy, zapoznaj się z dokumentacją na temat rozpoczęcia pracy z Gitem dla Pantheon.

Teraz zmienimy git remote origin, aby wskazywało na GitLab zamiast Pantheon. Można to zrobić poleceniem git remote.

Przechodzimy do projektu GitLab i kopiujemy URL repozytorium z rozwijanego menu Klonuj na stronie szczegółów projektu. Wybieramy opcję Klonuj za pomocą SSH, ponieważ już skonfigurowaliśmy klucz SSH.

Domyślnie git remote dla lokalnej kopii repozytorium kodu – origin. Można to zmienić za pomocą git remote set-url origin [URL repozytorium GitLab], gdzie zamiast nawiasów wpisujemy faktyczny URL.

Na koniec uruchamiamy git push origin master --force, aby przesłać kod WordPress z witryny Pantheon do GitLab.

Parametr –force potrzebny jest tylko raz. Potem w komendach git push na GitLab go nie będzie.

Konfigurujemy dane logowania i zmienne

Pamiętasz, jak lokalnie dodaliśmy klucz SSH, aby autoryzować się w Pantheon i GitLab? Token SSH można używać do autoryzacji w GitLab i Pantheon.

GitLab ma świetną dokumentację. Zobaczmy sekcję o kluczach SSH przy używaniu executorów Docker w dokumencie o używaniu kluczy SSH z GitLab CI/CD.

Teraz wykonamy pierwsze dwa kroki: stwórzmy nową parę kluczy SSH lokalnie za pomocą ssh-keygen i dodajmy klucz prywatny jako zmienną w projekcie.

Potem ustawimy SSH_PRIVATE_KEY jak zmienną środowiskową GitLab CI/CD w ustawieniach projektu.
Na trzecim i czwartym kroku stworzymy plik .gitlab-ci.yml z taką zawartością:

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"

Na razie nie będziemy commitować pliku .gitlab-ci.yml, potem trzeba będzie dodać jeszcze kilka rzeczy.

Teraz wykonujemy piąty krok i dodajemy klucz publiczny, który stworzyliśmy w pierwszym kroku, do usług, do których potrzebujesz dostępu w środowisku budowy.

W naszym przypadku chcemy uzyskać dostęp do Pantheon z GitLab. Postępuj zgodnie z instrukcją w dokumencie Pantheon o dodawaniu klucza SSH w Pantheon i wykonujemy ten krok.

Pamiętaj: klucz prywatny SSH – w GitLab, klucz publiczny – w Pantheon.

Skonfigurujemy jeszcze kilka zmiennych środowiskowych. Pierwsza nazywa się PANTHEON_SITE. Jej wartość to nazwa witryny Pantheon na twoim komputerze.

Nazwa na komputerze wskazana jest na końcu komendy Clone with Git. Już sklonowałeś witrynę lokalnie, więc to będzie nazwa katalogu lokalnego repozytorium.

Następnie skonfigurujemy zmienną środowiskową PANTHEON_GIT_URL. To jest adres URL repozytorium Git dla witryny Pantheon, który już wykorzystaliśmy.

Wprowadzamy tylko adres URL repozytorium SSH, bez git clone i nazwy witryny na komputerze na końcu.

Uff. To zrobione, teraz możemy zakończyć nasz plik .gitlab-ci.yml.

Tworzymy zadanie wdrożenia

To, co na początku będziemy robić z GitLab CI, jest bardzo podobne do tego, co robiliśmy z repozytoriami Git wcześniej. Ale tym razem dodamy repozytorium Pantheon jako drugie zdalne źródło Git, a potem wyślemy kod z GitLab do Pantheon.

W tym celu skonfigurujemy etap deploy i zadanie deploy:dev, ponieważ będziemy wdrażać w środowisku deweloperskim na Pantheon. W rezultacie plik .gitlab-ci.yml będzie wyglądać tak:

etapy:
- wdrożenie

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

deply:dev:
  etap: wdrożenie
  środowisko:
    nazwa: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  skrypt:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  tylko:
    - master

Zmienne SSH_PRIVATE_KEY, PANTHEON_SITE i PANTHEON_GIT_URL powinny wyglądać znajomo — wcześniej skonfigurowaliśmy te zmienne środowiskowe. Dzięki tym zmiennym możemy wykorzystywać wartości w pliku .gitlab-ci.yml wielokrotnie, a ich aktualizację będziemy musieli przeprowadzać tylko w jednym miejscu.

Na koniec dodamy, zatwierdzimy i prześlemy plik .gitlab-ci.yml na GitLab.

Sprawdzamy wdrożenie

Jeśli wszystko zrobiliśmy poprawnie, zadanie deploy:dev zostanie pomyślnie wykonane w GitLab CI/CD i wyśle commit .gitlab-ci.yml do Pantheon. Zobaczmy.

Przesyłamy gałęzie merge requestów do Pantheon

Tutaj wykorzystamy moją ulubioną funkcję Pantheon — multidev, gdzie można na żądanie tworzyć dodatkowe środowiska Pantheon dla gałęzi Git.

Dostęp do multidev jest ograniczony, więc tę sekcję można pominąć. Ale jeśli masz dostęp, możesz znacznie zwiększyć wydajność, konfigurując automatyczne tworzenie środowisk multidev w Pantheon z merge requestów GitLab.

Najpierw utworzymy nową gałąź Git lokalnie przy użyciu git checkout -b multidev-support. Teraz wprowadzimy jeszcze kilka zmian w .gitlab-ci.yml.

Lubię umieszczać numer merge requestu w nazwie środowiska Pantheon. Na przykład, pierwszy merge request — mr-1, drugi — mr-2 i tak dalej.

Merge request się zmienia, więc musimy dynamicznie określać nazwy gałęzi Pantheon. Na GitLab to proste — wystarczy użyć wstępnie zdefiniowanych zmiennych środowiskowych.

Możemy wziąć $CI_MERGE_REQUEST_IID, aby wskazać numer merge requestu. Zastosujmy to wszystko razem z globalnymi zmiennymi środowiskowymi, które zdefiniowaliśmy wcześniej i dodajmy nowe zadanie deploy:multidev na końcu pliku .gitlab-ci.yml.

deploy:multidev:
  etap: wdrożenie
  środowisko:
    nazwa: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  skrypt:
    # Wyciągnij źródłową gałąź merge requestu
    - git checkout $CI_COMMIT_REF_NAME
    # Dodaj repozytorium git Pantheon jako dodatkowy zdalny
    - git remote add pantheon $PANTHEON_GIT_URL
    # Wypchnij źródłową gałąź merge requestu do Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  tylko:
    - merge_requests

Będzie to wyglądać jak nasze zadanie deploy:dev, tylko gałąź jest wysyłana do Pantheon, a nie do master.

Dodaliśmy i zatwierdziliśmy zaktualizowany plik .gitlab-ci.yml, a teraz wyślemy nową gałąź do GitLab z git push -u origin multidev-support.

Teraz stwórzmy nowe zapytanie o scalanie z gałęzi multidev-support, klikając Utwórz zapytanie o scalanie.

Po utworzeniu zapytania o scalanie sprawdźmy, jak działa zadanie CI/CD deploy:multidev.

Zobacz — nowa gałąź została przesłana do Pantheon. Jednak gdy przejdziemy do sekcji multidev na pulpicie nawigacyjnym Pantheon, nie zobaczymy tam nowego środowiska

Sprawdźmy sekcję Git Branches.

W rezultacie nasza gałąź mr-1 została wysłana do Pantheon. Stwórzmy środowisko z gałęzi mr-1.

Utworzyliśmy środowisko multidev, a teraz wróćmy do GitLab i zajrzyjmy do sekcji Operations > Environments. Zobaczymy wpisy dla dev i mr-1.

To dlatego, że dodaliśmy wpis environment z nazwą name i url w zadaniach CI/CD. Jeśli klikniemy ikonę otwartego środowiska, przejdziemy do adresu URL środowiska multidev na Pantheon.

Automatyzujemy tworzenie multidev

W zasadzie można by się tutaj zatrzymać i po prostu nie zapominać o tworzeniu środowiska multidev dla każdego zapytania o scalanie, ale ten proces można zautomatyzować.

W Pantheon jest narzędzie wiersza poleceń Terminus, w którym można pracować z platformą automatycznie. W Terminus można tworzyć środowiska multidev z wiersza poleceń — idealne dla GitLab CI.

Potrzebujemy nowego zapytania o scalanie, aby to przetestować. Stwórzmy nową gałąź za pomocą git checkout -b auto-multidev-creation.

Aby używać Terminus w zadaniach GitLab CI/CD, potrzebny jest token maszyny do uwierzytelnienia w Terminus oraz obraz kontenera z Terminus.

Tworzymy token maszyny Pantheon, przechowujemy go w bezpiecznym miejscu i dodajemy jako globalną zmienną środowiskową w GitLab z nazwą PANTHEON_MACHINE_TOKEN.

Jeśli zapomniałeś, jak dodawać zmienne środowiskowe w GitLab, wróć tam, gdzie określiliśmy PANTHEON_SITE.

Tworzymy Dockerfile z Terminus

Jeśli nie używasz Dockera lub nie lubisz plików Dockerfile, weź mój obraz registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest i pomiń tę sekcję.

W GitLab jest rejestr kontenerów, w którym można zbudować i umieścić Dockerfile dla naszego projektu. Stwórzmy plik Dockerfile z Terminus, aby pracować z Pantheon.

Terminus to narzędzie wiersza poleceń napisane w PHP, więc zaczniemy od obrazu PHP. Instaluję Terminus przez Composer, dlatego wezmę za podstawę oficjalny obraz Dockera Composer. Tworzymy Dockerfile w katalogu lokalnego repozytorium o takiej zawartości:

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

Postępuj zgodnie z instrukcjami dotyczącymi budowy i przesyłania obrazów z sekcji Build and push images do dokumentacji rejestru kontenerów, aby zbudować obraz z Dockerfile i przesłać go do GitLab.

Otwieramy sekcję Registry w projekcie GitLab. Jeśli wszystko poszło zgodnie z planem, tam będzie nasz obraz. Zapisz link do tagu obrazu — będzie nam potrzebny do pliku .gitlab-ci.yml.

Sekcja script w zadaniu deploy:multidev zaczyna się rozwijać, więc przenieśmy go do osobnego pliku. Tworzymy nowy plik 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

Skrypt znajduje się w prywatnym katalogu i nie daje dostępu do sieci na Pantheon. Mamy skrypt dla naszej logiki multidev. Teraz zaktualizujmy sekcję deploy:multidev pliku .gitlab-ci.yml, aby wyglądało to tak:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Uruchamiamy skrypt wdrażania multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Musimy upewnić się, że nasze zadania są wykonywane w utworzonym niestandardowym obrazie, więc dodamy definicję image z URL rejestru w .gitlab-ci.yml. Ostatecznie mamy taki plik .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Zobacz 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:
    # Uruchamiamy skrypt wdrażania multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Dodajemy, zatwierdzamy i wysyłamy private/multidev-deploy.sh i .gitlab-ci.yml. Teraz wracamy do GitLab i czekamy, aż zadanie CI/CD się zakończy. Niech to potrwa: multidev może być tworzony przez kilka minut.

Potem idziemy zobaczyć listę multidev na Pantheon. O, cud! Środowisko multidev mr-2 już tutaj jest.

Podsumowanie

Mojemu zespołowi znacznie lepiej pracuje się, odkąd zaczęliśmy otwierać merge requesty i automatycznie tworzyć środowiska.

Dzięki potężnym narzędziom GitLab i Pantheon można automatycznie połączyć GitLab z Pantheon.

Ponieważ używamy GitLab CI/CD, nasz proces roboczy ma wiele możliwości rozwoju. Oto kilka pomysłów, jak zacząć:

Dodaj krok budowy.
Dodaj automatyczne testowanie.
Dodaj zadanie, aby zapewnić zgodność ze standardami kodu.
Dodaj dynamiczne testowanie zabezpieczeń aplikacji.

Napisz, co myślisz o GitLab, Pantheon i automatyzacji.

P.S. Wiedziałeś, że Terminus, narzędzie linii poleceń Pantheon, można rozszerzać przez wtyczki?

Pracowaliśmy w Pantheon nad wersją 2 naszego pluginu do narzędzi budowlanych Terminus z obsługą GitLab. Jeśli nie chcesz bawić się w konfigurację dla każdego projektu, spróbuj tej wtyczki i pomóż nam przetestować betę v2. Dla zespołu Terminus build:project:create potrzebny jest tylko token Pantheon i token GitLab. Rozpocznie to jeden z przykładowych projektów z Composer i automatycznym testowaniem, utworzy nowy projekt w GitLab, nową stronę Pantheon i połączy je za pomocą zmiennych środowiskowych i kluczy SSH.