Jak połączyć GitLab i Pantheon oraz zoptymalizować przepływy pracy w Drupalu i WordPressie

Nasz gość, twórca narzędzi programistycznych w Pantheon, opowiada o tym, jak zautomatyzować wdrożenia WordPress przy użyciu GitLab CI/CD.

В Panteon Pracuję w relacjach z programistami, więc zawsze szukam nowych sposobów, aby pomóc programistom WordPress i Drupal w rozwiązywaniu problemów z automatyzacją w ich przepływach pracy. W tym celu lubię eksperymentować z nowymi narzędziami i łączyć je ze sobą, aby działały efektywnie.

Często widzę, jak programiści mają problemy z jednym serwerem przejściowym.

To wielka przyjemność czekać na swoją kolej, aby skorzystać z serwera pośredniczącego lub wysłać klientom adres URL z dopiskiem: „Spójrz tutaj, ale jeszcze tu nie zaglądaj”.

Środowiska wieloprogramowe - jedno z fajnych narzędzi Pantheona - rozwiązuje ten problem, ponieważ za ich pomocą można na żądanie tworzyć środowiska dla oddziałów Git. Każde środowisko wieloprogramowe ma swój własny adres URL i bazę danych, dzięki czemu programiści mogą pracować cicho, sprawdzać jakość i uzyskiwać zgodę, nie wchodząc sobie nawzajem na palce.

Ale Pantheon nie ma narzędzi do kontroli wersji ani ciągłej integracji i wdrażania (CI/CD). Jest to jednak elastyczna platforma, z którą można zintegrować dowolne narzędzia.

Zauważyłem również, że zespoły używają pewnych narzędzi do programowania, a innych do montażu i wdrażania.

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

Na GitLab istnieje pełny zestaw narzędzi programistycznych: do kontroli wersji, zgłoszeń, żądań scalania, najlepszego w swojej klasie potoku CI/CD, rejestru kontenerów i tym podobnych. Nie spotkałem jeszcze aplikacji, która oferuje tak wiele możliwości zarządzania przepływem prac programistycznych.

Uwielbiam automatyzację, więc dowiedziałem się, jak połączyć Pantheon z GitLabem, aby zatwierdzenia z głównej gałęzi GitLaba zostały wdrożone w głównym środowisku programistycznym w Pantheonie. Żądania scalania w GitLab umożliwiają tworzenie i wdrażanie kodu w środowiskach wielu deweloperów w Pantheonie.

W tym samouczku przeprowadzę Cię przez proces konfiguracji połączenia pomiędzy GitLabem i Pantheonem oraz optymalizacji przepływu pracy w WordPressie i Drupalu.

Oczywiście jest to możliwe, lustrzane repozytorium GitLab, ale zrobimy wszystko, aby zagłębić się w nasze ręce GitLab CI i w przyszłości korzystaj z tego narzędzia nie tylko przy wdrażaniu.

Wprowadzenie

Na potrzeby tego postu musisz zrozumieć, że Pantheon dzieli każdą witrynę na trzy elementy: kod, bazę danych i pliki.

Kod zawiera pliki CMS, takie jak rdzeń WordPress, wtyczki i motywy. Pliki te są zarządzane w Repozytoria Git, hostowany przez Pantheon, co oznacza, że ​​możemy wdrażać kod z GitLab do Pantheona za pomocą Git.
Pliki w Pantheonie to pliki multimedialne, czyli obrazy witryny. Zazwyczaj są one przesyłane przez użytkowników, a Git je ignoruje.

Utwórz darmowe konto, Dowiedz się więcej o Przepływ pracy w Panteonie lub zapisz się na demo na pantheon.io.

Założenia

Mój projekt na Pantheonie i GitLabie nazywa się pantheon-gitlab-blog-demo. Nazwa projektu musi być unikalna. Tutaj będziemy pracować z witryną WordPress. Możesz wziąć Drupala, ale będziesz musiał zmienić pewne rzeczy.

Użyję Linia poleceń Gitai możesz pracować interfejs graficzny, Jeśli chcesz.

Utwórz projekt

Najpierw stwórzmy Projekt GitLaba (powrócimy do tego później).

Instrukcja utworzenie witryny WordPress na Panteonie. Następnie instalujemy WordPress dla panelu kontrolnego witryny.

Jeśli swędzą Cię ręce, żeby coś zmienić, na przykład usunąć lub dodać wtyczki, uzbrój się w cierpliwość. Witryna nie jest jeszcze połączona z GitLabem i chcemy, aby wszystkie zmiany w kodzie przechodziły przez GitLab.

Po zainstalowaniu WordPressa wróć do pulpitu nawigacyjnego witryny Pantheon i zmień tryb programowania na Git.

Początkowe zatwierdzenie w GitLab

Teraz musisz przenieść początkowy kod WordPressa ze strony Pantheon do GitLab. W tym celu klonujemy lokalnie kod z repozytorium Git strony Pantheon, a następnie wysyłamy go do repozytorium GitLab.

Aby było łatwiej i bezpieczniej, dodaj klucz SSH do Pantheona i nie będziemy musieli wpisywać hasła za każdym razem, gdy klonujemy repozytorium Pantheon Git. Już w tym samym czasie dodaj klucz SSH do GitLab.

Aby to zrobić, sklonuj witrynę Pantheon lokalnie, kopiując polecenie z pola Klonuj za pomocą Git na panelu kontrolnym witryny.

Jeśli potrzebujesz pomocy, przeczytaj dokumentację rozpoczęcie pracy z Git dla Pantheona.

Teraz zmieńmy git remote originaby wskazać GitLab zamiast Pantheon. To może być zrobione командой git remote.

Przejdźmy do projektu GitLab i skopiujmy adres URL repozytorium z listy rozwijanej Klonuj na stronie szczegółów projektu. Wybierzmy opcję Clone with SSH, gdyż mamy już skonfigurowany klucz SSH.

Domyślnie git remote dla lokalnej kopii repozytorium kodu - origin. Można to zmienić, c git remote set-url origin [URL репозитория GitLab], gdzie zamiast nawiasów podajemy rzeczywisty adres URL.

Wreszcie uruchamiamy git push origin master --forceaby wypchnąć kod WordPress z Pantheona do GitLab.

Opcja –force jest potrzebna tylko raz. Następnie w zespołach git push nie będzie go na GitLabie.

Konfigurowanie poświadczeń i zmiennych

Pamiętasz, jak dodaliśmy lokalnie klucz SSH do logowania się do Pantheona i GitLaba? Token SSH może służyć do autoryzacji GitLaba i Pantheona.

GitLab ma doskonałą dokumentację. Zobaczmy sekcja dotycząca kluczy SSH podczas korzystania z executora Docker w dokumencie dotyczącym używania kluczy SSH z GitLab CI/CD.

Wykonamy teraz dwa pierwsze kroki: Utwórzmy lokalnie nową parę kluczy SSH za pomocą ssh-keygen i dodajmy klucz prywatny jako zmienną do projektu.

Wtedy zapytamy SSH_PRIVATE_KEY jak Zmienna środowiskowa GitLab CI/CD w ustawieniach projektu.
W trzecim i czwartym kroku utworzymy 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"

Nie zatwierdzajmy jeszcze pliku .gitlab-ci.yml, to będziesz musiał dodać do tego coś jeszcze.

Teraz wykonujemy piąty krok i dodaj klucz publiczny utworzony w pierwszym kroku do usług, do których potrzebujesz dostępu w środowisku kompilacji.

W naszym przypadku chcemy uzyskać dostęp do Pantheona z GitLaba. Postępujemy zgodnie z instrukcjami zawartymi w dokumencie Panteon dot dodanie klucza SSH do Pantheona i wykonaj ten krok.

Pamiętaj: prywatny SSH znajduje się w GitLabie, otwarty SSH jest w Panteonie.

Skonfigurujmy jeszcze kilka zmiennych środowiskowych. Pierwsza nazywa się PANTHEON_SITE. Jego wartością jest nazwa witryny Pantheon na Twoim komputerze.

Nazwa komputera jest podana na końcu polecenia Klonuj za pomocą Git. Stronę sklonowałeś już lokalnie, więc będzie to nazwa katalogu lokalnego repozytorium.

Następnie skonfigurujmy zmienną środowiskową PANTHEON_GIT_URL. To jest adres URL repozytorium Git dla witryny Pantheon, z której już korzystaliśmy.

Wpisz tylko adres URL repozytorium SSH, bez git clone i nazwę witryny na komputerze na końcu.

Uff. Gotowe, teraz możemy dokończyć nasz plik .gitlab-ci.yml.

Utwórz zadanie wdrożenia

To, co początkowo będziemy robić z GitLab CI, jest bardzo podobne do tego, co robiliśmy w przeszłości z repozytoriami Git. Ale tym razem dodamy repozytorium Pantheon jako drugie zdalne źródło Git, a następnie wypchniemy kod z GitLab do Pantheon.

Aby to zrobić, skonfigurujmy etap deploy и zadanie deploy:dev, ponieważ będziemy wdrażać go w środowisku programistycznym na platformie Pantheon. Wynikowy plik .gitlab-ci.yml będzie wyglądać następująco:

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

Zmienne SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL powinien wyglądać znajomo — te zmienne środowiskowe ustawiliśmy wcześniej. Dzięki tym zmiennym będziemy mogli wykorzystać wartości w pliku .gitlab-ci.yml wiele razy i będą musiały być aktualizowane tylko w jednym miejscu.

Na koniec dodaj, zatwierdź i wyślij plik .gitlab-ci.yml na GitLabie.

Sprawdzanie wdrożenia

Jeśli wszystko zrobiliśmy poprawnie, zadanie deploy:dev zostanie pomyślnie uruchomiony w GitLab CI/CD i prześle zatwierdzenie .gitlab-ci.yml w Panteonie. Przyjrzyjmy się.

Wysyłanie wątków z prośbą o połączenie do Pantheona

Tutaj użyjemy mojej ulubionej funkcji Pantheona − multidev, gdzie na żądanie możesz utworzyć dodatkowe środowiska Pantheon dla oddziałów Git.

Dostęp do multidev jest ograniczony, więc tę sekcję można pominąć. Jeśli jednak masz dostęp, możesz znacznie zwiększyć produktywność, konfigurując automatyczne tworzenie środowisk wielorozwojowych w Pantheonie na podstawie żądań połączenia GitLab.

Najpierw utwórzmy lokalnie nową gałąź Git, używając git checkout -b multidev-support. Teraz zmieńmy coś ponownie w .gitlab-ci.yml.

Lubię dołączać numer żądania scalania do nazwy środowiska Pantheon. Na przykład pierwsze żądanie scalania to mr-1, drugi - mr-2 itp.

Żądanie scalania ulega zmianie, dlatego musimy dynamicznie określać nazwy gałęzi Panteonu. W GitLabie jest to łatwe - wystarczy użyć predefiniowane zmienne środowiskowe.

Możemy wziąć $CI_MERGE_REQUEST_IIDaby określić numer żądania połączenia. Zastosujmy to wszystko wraz z określonymi wcześniej globalnymi zmiennymi środowiskowymi i dodajmy nowe zadanie Deploy:multidev na końcu pliku .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

Będzie to podobne do naszego zadania deploy:dev, tylko oddział jest wysyłany do Panteonu, a nie do master.

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

Utwórzmy teraz nowe żądanie scalania z gałęzi multidev-supportnaciskając Utwórz żądanie połączenia.

Po utworzeniu żądania scalania przyglądamy się, jak wykonywane jest zadanie CI/CD deploy:multidev.

Słuchaj, nowy wątek został wysłany do Pantheona. Jeśli jednak przejdziemy do sekcji multidev na pulpicie nawigacyjnym witryny Pantheon, nie zobaczymy tam nowego środowiska

Przyjrzyjmy się sekcji Oddziały Git.

W rezultacie nasz wątek mr-1 dotarłem do Panteonu. Stwórzmy środowisko z gałęzi mr-1.

Stworzyliśmy środowisko multidev, teraz wróćmy do GitLaba i przyjrzyjmy się sekcji Operacje > Środowiska. Zobaczymy wpisy dla dev и mr-1.

Dzieje się tak, ponieważ dodaliśmy wpis environment Z imieniem name и url w zadaniach CI/CD. Jeśli klikniemy ikonę otwartego środowiska, zostaniemy przeniesieni do adresu URL środowiska multidev na Pantheonie.

Zautomatyzuj tworzenie multidev

Zasadniczo możesz na tym poprzestać i pamiętać o utworzeniu środowiska wieloprogramowego dla każdego żądania połączenia, ale proces ten można zautomatyzować.

Pantheon ma narzędzie wiersza poleceń Stacja końcowa, gdzie możesz pracować z platformą automatycznie. Terminus pozwala na tworzenie środowisk multidev z linii poleceń - idealne dla GitLab CI.

Aby to przetestować, potrzebujemy nowego żądania połączenia. Utwórzmy nowy oddział za pomocą git checkout -b auto-multidev-creation.

Aby używać Terminusa w zadaniach CI/CD GitLab, potrzebujesz tokena maszynowego do uwierzytelniania w Terminusie i obrazu kontenera w Terminusie.

Tworzenie tokena maszyny Panteon, zapisz go w bezpiecznym miejscu i dodaj jako globalną zmienną środowiskową w GitLabie z nazwą PANTHEON_MACHINE_TOKEN.

Jeśli zapomniałeś, jak dodać zmienne środowiskowe GitLab, wróć do miejsca, w którym zdefiniowaliśmy PANTHEON_SITE.

Tworzenie pliku Dockerfile za pomocą Terminusa

Jeśli nie używasz Dockera lub nie lubisz plików Dockerfile, zrób moje zdjęcie registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest i pomiń tę sekcję.

GitLab ma rejestr kontenerów, gdzie możemy zbudować i umieścić plik Dockerfile dla naszego projektu. Utwórzmy plik Dockerfile z Terminusem do pracy z Pantheonem.

Terminus jest narzędziem wiersza poleceń PHP, więc zacznijmy od obrazu PHP. Instaluję Terminusa przez Composer, więc użyję oficjalny obraz Docker Composer. Tworzymy Dockerfile w katalogu lokalnego repozytorium o następującej 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 składania i wysyłania obrazów z sekcji Twórz i przesyłaj obrazy в dokumentacja rejestru kontenerówz którego chcesz zebrać obraz Dockerfile i wypchnij go do GitLab.

Otwarcie sekcji rejestr w projekcie GitLab. Jeśli wszystko poszło zgodnie z planem, nasz wizerunek tam będzie. Zapisz link do tagu obrazu - będzie nam potrzebny do pliku .gitlab-ci.yml.

Rubryka script w problemie deploy:multidev zaczyna rosnąć, więc przenieśmy go do osobnego pliku. Utwórz 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 katalogu prywatnym i nie pozwala na dostęp sieciowy do Panteonu. Mamy skrypt dla naszej logiki multidev. Zaktualizujmy teraz sekcję deploy:multidev plik .gitlab-ci.ymlżeby wyszło 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:
    # Run the multidev deploy script
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Musimy mieć pewność, że nasze zadania są wykonywane w utworzonym niestandardowym obrazie, dlatego dodajmy definicję image z adresu URL rejestru do .gitlab-ci.yml. W rezultacie otrzymaliśmy taki plik .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

Dodaj, zatwierdź i wyślij private/multidev-deploy.sh и .gitlab-ci.yml. Teraz wracamy do GitLaba i czekamy na zakończenie zadania CI/CD. Bądź cierpliwy: utworzenie multidev może zająć kilka minut.

Następnie przeglądamy listę multidev na Pantheonie. O cud! Środowisko multidev mr-2 już tutaj.

wniosek

Mój zespół miał dużo więcej zabawy, gdy zaczęliśmy automatycznie otwierać żądania scalania i tworzyć środowiska.

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

Ponieważ korzystamy z GitLab CI/CD, nasz przepływ pracy będzie mógł się rozwijać. Oto kilka pomysłów na dobry początek:

• Dodaj krok kompilacji.
• Dodaj testy automatyczne.
• Dodaj zadanie, aby upewnić się, że standardy kodu są spełnione.
• Dodaj dynamiczne testowanie bezpieczeństwa aplikacji.

Daj nam znać, co myślisz o GitLabie, Pantheonie i automatyzacji.

PS Czy wiesz, że Terminus, narzędzie wiersza poleceń Pantheona, można rozszerzyć za pomocą wtyczek?

W Pantheonie wykonaliśmy dobrą robotę nad wersją 2 naszego oprogramowania wtyczka do narzędzi do budowania Terminusa ze wsparciem GitLaba. Jeśli nie chcesz zawracać sobie głowy ustawieniami dla każdego projektu, wypróbuj tę wtyczkę i pomóż nam przetestować wersję beta v2. Dla zespołu Terminusa build:project:create Potrzebujesz tylko tokena Pantheon i tokena GitLab. Wdroży jeden z przykładowych projektów za pomocą Composera i testów automatycznych, utworzy nowy projekt w GitLab, nowej witrynie Pantheon i połączy je za pomocą zmiennych środowiskowych i kluczy SSH.

O autorze

Andrew Taylor tworzy narzędzia dla programistów w Panteon.

Źródło: www.habr.com