Cum să conectați GitLab la Pantheon și să optimizați fluxurile de lucru pentru Drupal și WordPress

Invităm pe creatorul de instrumente pentru dezvoltatori de la Pantheon să ne spună cum putem automatiza desfășurările WordPress folosind GitLab CI/CD.

În Pantheon Mă ocup de relații cu dezvoltatorii, așa că mereu caut noi modalități de a ajuta dezvoltatorii WordPress și Drupal să abordeze problemele de automatizare în fluxurile de lucru. Îmi place să experimentez cu instrumente noi și să le combin pentru a crea un mediu de lucru eficient.

Adesea observ cum developerii se zbate cu un singur server intermediar.

Nu este deloc plăcut să aștepți la rând pentru a folosi serverul intermediar sau să trimiți clienților un URL cu mențiunea: „Uitați-vă aici, dar nu aici încă”.

Mediile multidev — unul dintre instrumentele grozave de la Pantheon — rezolvă această problemă, deoarece este posibil să creezi medii pentru ramuri Git la cerere. Fiecare mediu multidev are propriul URL și bază de date, așa că dezvoltatorii pot lucra liniștiți, verifica calitatea și obține aprobarea fără să își calcă pe picioare.

Dar la Pantheon nu există instrumente pentru controlul versiunilor sau integrare continuă/dezvoltare (CI/CD). În schimb, este o platformă flexibilă cu care poți integra orice instrumente.

De asemenea, am observat că echipele folosesc instrumente diferite pentru dezvoltare și altele pentru construcție și desfășurare.

De exemplu, au instrumente diferite pentru controlul versiunilor și CI/CD. Trebuie să te chinui să treci de la un instrument la altul pentru a edita codul și a diagnostica problemele.

Pe GitLab există un set complet de instrumente pentru dezvoltare: pentru controlul versiunilor, biletele, cererile de fuziune, o linie de producție CI/CD de top și un registru de containere și alte lucruri de acest gen. Nu am întâlnit, până acum, aplicații care să aibă atât de multe instrumente pentru gestionarea fluxului de lucru în dezvoltare.

Ador automatizarea, așa că am studiat cum să conectez Pantheon la GitLab, astfel încât angajamentele în ramura principală de pe GitLab să fie desfășurate în mediul principal de dezvoltare de la Pantheon. De asemenea, cererile de fuziune pe GitLab pot crea și desfășura cod în mediile multidev de la Pantheon.

În acest ghid, vă voi arăta cum să configurați conexiunea între GitLab și Pantheon și să optimizați fluxul de lucru pentru WordPress și Drupal.

Sigur că poți să reflectezi repo-ul GitLab, dar noi vom face totul manual pentru a explora GitLab CI și pentru a utiliza acest instrument nu doar pentru desfășurări în viitor.

Introducere

Pentru acest post, trebuie să înțelegem că Pantheon împarte fiecare site în trei elemente: cod, bază de date și fișiere.

Codul include fișiere CMS, cum ar fi nucleul, pluginurile și temele WordPress. Aceste fișiere sunt gestionate în repository-ul Git, găzduit de Pantheon, ceea ce înseamnă că putem realiza deployment-ul codului din GitLab în Pantheon folosind Git.
Fișierele din Pantheon se referă la fișierele media, adică imaginile pentru site. De obicei, ele sunt încărcate de utilizatori și Git le ignoră.

Creează un cont gratuit, află mai multe despre fluxul de lucru Pantheon sau înscrie-te pentru o demonstrație pe pantheon.io.

Presupoziții

Proiectul meu pe Pantheon și GitLab se numește pantheon-gitlab-blog-demo. Numele proiectului trebuie să fie unic. Aici vom lucra cu un site WordPress. Este posibil să folosim și Drupal, dar va fi necesar să facem câteva modificări.

Voi folosi linia de comandă Git, iar tu poți lucra în interfața grafică, dacă dorești.

Creăm proiectul

Pentru început, creăm un proiect GitLab (la care ne vom întoarce mai târziu).

Acum creăm un site WordPress pe Pantheon. Apoi, instalăm WordPress pentru tabloul de bord al site-ului.

Dacă te apucă dorința de a schimba ceva, de exemplu, să ștergi și să adaugi pluginuri, mai așteaptă. Site-ul nu este încă conectat la GitLab și ne dorim ca toate modificările de cod să treacă prin GitLab.

După ce instalăm WordPress, ne întoarcem pe tabloul de bord al site-ului Pantheon și schimbăm modul de dezvoltare la Git.

Commitul inițial pe GitLab

Acum trebuie să transferăm codul inițial WordPress de pe site-ul Pantheon pe GitLab. Pentru aceasta, clonăm codul din repository-ul Git al site-ului Pantheon local, apoi îl trimitem în repository-ul GitLab.

Pentru a face acest lucru mai ușor și mai sigur, adăugăm o cheie SSH în Pantheon și nu va trebui să introducem parola de fiecare dată când clonăm repository-ul Pantheon Git. De asemenea, deja adăugăm cheia SSH pe GitLab.

Pentru aceasta, clonăm site-ul Pantheon local, copiii comanda din câmpul Clone with Git de pe tabloul de bord al site-ului.

Dacă ai nevoie de ajutor, citește documentația privind începutul lucrului cu Git pentru Pantheon.

Acum vom schimba git remote origin, pentru a indica GitLab în loc de Pantheon. Acest lucru se poate realiza prin comanda git remote.

Să mergem în proiectul GitLab și să copiăm URL-ul repository-ului din lista derulantă Clone de pe pagina detaliilor proiectului. Vom alege opțiunea Clone with SSH, deoarece am configurat deja cheia SSH.

Implicit git remote pentru copia locală a repository-ului de cod - origin. Acesta poate fi schimbat cu git remote set-url origin [URL repository GitLab], unde în locul parantezelor introducem URL-ul actual.

În cele din urmă, rulăm git push origin master --force, pentru a trimite codul WordPress de pe site-ul Pantheon pe GitLab.

Parametrul –force este necesar o singură dată. Apoi în comenzi git push nu va fi pe GitLab.

Configurăm acreditivele și variabilele

Îți amintești cum am adăugat local cheia SSH pentru a ne autentifica în Pantheon și GitLab? Tokenul SSH poate fi folosit pentru autentificarea în GitLab și Pantheon.

GitLab are o documentație excelentă. Să ne uităm la secțiunea despre cheile SSH atunci când folosim executor Docker în documentul despre utilizarea cheilor SSH cu GitLab CI/CD.

Acum vom efectua primele două pași: vom crea o nouă pereche de chei SSH local cu ssh-keygen și vom adăuga cheia privată ca variabilă în proiect.

Apoi vom defini SSH_PRIVATE_KEY cum variabila de mediu GitLab CI/CD în setările proiectului.
La al treilea și al patrulea pas, vom crea fișierul .gitlab-ci.yml cu următorul conținut:

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

Deocamdată nu vom comite fișierul .gitlab-ci.yml, apoi va trebui să adăugăm încă câteva lucruri.

Acum să efectuăm al cincilea pas și să adăugăm cheia publică pe care am creat-o în primul pas la serviciile la care ai nevoie de acces în mediu de construcție.

În cazul nostru, dorim să obținem acces de la GitLab la Pantheon. Urmăm instrucțiunile din documentul Pantheon pentru adăugarea cheii SSH în Pantheon și să finalizăm acest pas.

Amintim: cheia SSH privată se află în GitLab, iar cea publică în Pantheon.

Să configurăm câteva variabile de mediu suplimentare. Prima se numește PANTHEON_SITE. Valoarea acesteia este numele site-ului Pantheon de pe mașina ta.

Numele de pe mașină este indicat la sfârșitul comenzii Clone with Git. Ai clonat deja site-ul local, așa că acesta va fi numele directorului din depozitul local.

Apoi configurăm variabila de mediu PANTHEON_GIT_URL. Acesta este URL-ul depozitului Git pentru site-ul Pantheon, pe care l-am folosit deja.

Introducem doar URL-ul SSH al depozitului, fără git clone și numele site-ului pe mașină la sfârșit.

Uf. Am terminat, acum putem finaliza fișierul nostru .gitlab-ci.yml.

Creăm o sarcină de deplasare

Ceea ce vom face la început cu GitLab CI este foarte asemănător cu ceea ce am făcut cu depozitele Git înainte. Dar de data aceasta vom adăuga depozitul Pantheon ca a doua sursă remote Git și apoi vom trimite codul din GitLab în Pantheon.

Pentru aceasta, vom configura etapa deploy și sarcina deploy:dev, deoarece vom face deplasarea în mediu de dezvoltare pe Pantheon. Ca urmare, fișierul .gitlab-ci.yml va arăta astfel:

stages:
- deploy

before_script:
  # Vezi 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

Variabile SSH_PRIVATE_KEY, PANTHEON_SITE și PANTHEON_GIT_URL ar trebui să pară cunoscut — am configurat aceste variabile de mediu mai devreme. Cu aceste variabile, vom putea folosi valorile din fișier .gitlab-ci.yml de mai multe ori, și va trebui să le actualizăm doar într-un singur loc.

În cele din urmă, să adăugăm, să le comitem și să trimitem fișierul .gitlab-ci.yml pe GitLab.

Verificăm deployment-ul

Dacă am făcut totul corect, sarcina deploy:dev se va finaliza cu succes în GitLab CI/CD și va trimite commit-ul .gitlab-ci.yml în Pantheon. Să vedem.

Trimitem ramurile pull request-urilor în Pantheon

Aici vom folosi funcția mea preferată din Pantheon — multidev, unde putem crea medii suplimentare Pantheon pentru ramurile Git la cerere.

Accesul la multidev este limitat, așa că această secțiune poate fi omisă. Dar dacă aveți acces, puteți îmbunătăți considerabil performanța, configurând crearea automată de medii multidev în Pantheon din pull request-urile GitLab.

Mai întâi, să creăm o nouă ramură Git local cu ajutorul git checkout -b multidev-support. Acum, să facem unele modificări din nou în .gitlab-ci.yml.

Îmi place să includ numărul pull request-ului în numele mediei Pantheon. De exemplu, primul pull request — mr-1, al doilea — mr-2 etc.

Pull request-ul se schimbă, așa că trebuie să definim dinamic numele ramurilor Pantheon. Pe GitLab este simplu — trebuie să folosim variabilele de mediu predefinite.

Putem lua $CI_MERGE_REQUEST_IID, pentru a indica numărul pull request-ului. Să aplicăm toate acestea împreună cu variabilele de mediu globale pe care le-am menționat mai devreme și să adăugăm o nouă sarcină deploy:multidev la sfârșitul fișierului .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 sursa ramurii pull request-ului
    - git checkout $CI_COMMIT_REF_NAME
    # Adaugă repository-ul git Pantheon ca un remote suplimentar
    - git remote add pantheon $PANTHEON_GIT_URL
    # Trimite ramura sursă a pull request-ului în Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  only:
    - merge_requests

Va semăna cu sarcina noastră deploy:dev, doar că ramura este trimisă în Pantheon, și nu în master.

Am adăugat și am comis fișierul actualizat .gitlab-ci.yml, și acum vom trimite noua ramură în GitLab cu git push -u origin multidev-support.

Acum să creăm un nou pull request din ramură suport multidev, făcând clic pe Creează cererea de fuziune.

După ce am creat cererea de fuziune, vom verifica cum se desfășoară sarcina CI/CD deploy:multidev.

Uitați-vă - un nou branch a fost trimis în Pantheon. Dar dacă mergem la secțiunea multidev de pe tablou, nu vom vedea acolo noul mediu

Să ne uităm la secțiunea Ramuri Git.

În cele din urmă, branch-ul nostru mr-1 a ajuns în Pantheon. Să creăm un mediu din branch-ul mr-1.

Am creat un mediu multidev, iar acum ne întoarcem la GitLab și ne uităm la secțiunea Operațiuni > Medii. Vom vedea înregistrări pentru dev și mr-1.

Asta pentru că am adăugat un înregistrare environment cu numele name și url în sarcinile CI/CD. Dacă facem clic pe pictograma mediului deschis, vom accesa URL-ul mediului multidev din Pantheon.

Automatizăm crearea multidev

De fapt, aici ne putem opri și pur și simplu să nu uităm să creăm un mediu multidev pentru fiecare cerere de fuziune, dar acest proces poate fi automatizat.

În Pantheon există un instrument de linie de comandă Terminus, unde putem lucra cu platforma automat. În Terminus putem crea medii multidev din linia de comandă - ideal pentru GitLab CI.

Avem nevoie de o nouă cerere de fuziune pentru a testa asta. Să creăm un nou branch folosind git checkout -b auto-multidev-creation.

Pentru a folosi Terminus în sarcinile GitLab CI/CD, avem nevoie de un token de mașină pentru autentificarea în Terminus și o imagine de container cu Terminus.

Creăm token-ul de mașină Pantheon, îl salvăm într-un loc sigur și îl adăugăm ca variabilă globală de mediu în GitLab cu numele PANTHEON_MACHINE_TOKEN.

Dacă ai uitat cum să adaugi variabile de mediu în GitLab, întoarce-te acolo unde am definit PANTHEON_SITE.

Creăm Dockerfile cu Terminus

Dacă nu folosești Docker sau nu îți place fișierele Dockerfile, ia-ți imaginea mea registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest și sare peste această secțiune.

În GitLab există un registru de containere, unde putem construi și găzdui Dockerfile pentru proiectul nostru. Să creăm un fișier Dockerfile cu Terminus pentru a lucra cu Pantheon.

Terminus este un instrument de linie de comandă bazat pe PHP, așa că vom începe cu imaginea PHP. Instalez Terminus prin Composer, așa că voi folosi imaginea oficială Docker Composer. Creăm Dockerfile în directorul local al repository-ului cu următorul conținut:

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

Urmăm instrucțiunile pentru construirea și trimiterea imaginilor din secțiunea Construiește și trimite imaginile în documentației registrului de containere, pentru a construi imaginea din Dockerfile și a o trimite în GitLab.

Deschidem secțiunea Registru în proiectul GitLab. Dacă totul a mers conform planului, acolo va fi imaginea noastră. Notați linkul către tag-ul imaginii - îl avem nevoie pentru fișierul .gitlab-ci.yml.

Secțiunea script din sarcină deploy:multidev începe să se extindă, așa că să-l mutăm într-un fișier separat. Creăm un nou fișier 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

Scriptul se află într-un director privat și nu oferă acces web pe Pantheon. Avem un script pentru logica noastră multidev. Acum să actualizăm secțiunea deploy:multidev fișiere. .gitlab-ci.yml, astfel încât să arate așa:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Rulează scriptul de implementare multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Trebuie să ne asigurăm că sarcinile noastre se execută în imaginea personalizată creată, așa că adăugăm definiția imagine cu URL-ul registrului în .gitlab-ci.yml. În final, am obținut un fișier astfel .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Vezi 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:
    # Rulează scriptul de implementare multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Adăugăm, comitem și trimitem private/multidev-deploy.sh și .gitlab-ci.yml. Acum ne întoarcem la GitLab și așteptăm să se execute sarcina CI/CD. Răbdare: multidev poate dura câteva minute pentru a se crea.

Apoi mergem să vedem lista multidev pe Pantheon. O, minunat! Mediu multidev mr-2 este deja aici.

Concluzie

Echipa mea a devenit mult mai veselă când am început să deschidem cereri de fuziune și să creăm medii automat.

Cu instrumentele puternice GitLab și Pantheon, putem conecta automat GitLab la Pantheon.

Deoarece folosim GitLab CI/CD, fluxul nostru de lucru va avea mult spațiu pentru a crește. Iată câteva idei pentru a începe:

• Adăugați un pas de compilare.
• Adăugați testare automatizată.
• Adăugați o sarcină pentru a garanta respectarea standardelor de cod.
• Adăugați testare dinamică a securității aplicațiilor.

Scrieți ce părere aveți despre GitLab, Pantheon și automatizare.

P.S. Știați că Terminus, instrumentul de linie de comandă Pantheon, poate fi extins prin pluginuri?

Noi, la Pantheon, am muncit din greu la versiunea 2 a pluginului nostru pentru instrumentele de compilare Terminus cu suport pentru GitLab. Dacă nu doriți să vă ocupați de configurare pentru fiecare proiect, încercați acest plugin și ajutați-ne să testăm versiunea beta v2. Pentru echipa Terminus build:project:create este nevoie doar de tokenul Pantheon și tokenul GitLab. Acesta va desfășura unul dintre exemplele de proiect cu Composer și testare automată, va crea un nou proiect în GitLab, un nou site Pantheon și le va conecta prin variabile de mediu și chei SSH.

Despre autor

Andrew Taylor creează instrumente pentru dezvoltatori în Pantheon.

Sursa: habr.com