🥇Come collegare GitLab e Pantheon e ottimizzare i flussi di lavoro per Drupal e WordPress

Il nostro ospite, creatore di strumenti per sviluppatori di Pantheon, spiega come automatizzare i deployment di WordPress usando GitLab CI/CD.

In Pantheon Mi occupo di relazioni con gli sviluppatori, quindi cerco sempre nuovi modi per aiutare gli sviluppatori di WordPress e Drupal a risolvere problemi di automazione nei flussi di lavoro. Per questo, mi piace sperimentare con nuovi strumenti e combinarli tra loro per un lavoro efficace.

Spesso vedo gli sviluppatori che si affannano con un server intermedio.

Non è un grande piacere aspettare il proprio turno per usare un server intermedio o inviare ai clienti un URL con la nota: «Guarda qui, ma non qui per ora».

Gli ambienti multidev — uno degli strumenti fantastici di Pantheon — risolvono questo problema, poiché consentono di creare ambienti su richiesta per i branch Git. Ogni ambiente multidev ha il suo URL e database, quindi gli sviluppatori lavorano tranquillamente, controllano la qualità e ottengono approvazioni, senza pestarsi i piedi tra di loro.

Ma in Pantheon non ci sono strumenti per il controllo delle versioni o per l'integrazione e deployment continui (CI/CD). Tuttavia, è una piattaforma flessibile, dalla quale è possibile integrare qualsiasi strumento.

Ho anche notato che per lo sviluppo le squadre utilizzano un tipo di strumenti, mentre per la costruzione e il deployment — altri.

Ad esempio, hanno strumenti diversi per il controllo delle versioni e il CI/CD. Devono destreggiarsi e passare da uno strumento all'altro per modificare il codice e diagnosticare problemi.

A GitLab Esiste un pacchetto completo di strumenti per lo sviluppo: per il controllo delle versioni, ticket, merge request, un pipeline CI/CD di classe mondiale, un registro dei contenitori e tutto ciò che serve. Non mi è ancora capitato di trovare applicazioni che offrissero così tanto per gestire i flussi di lavoro di sviluppo.

Adoro l'automazione, quindi ho imparato come collegare Pantheon a GitLab, in modo che i commit nel branch principale su GitLab vengano deployati nell'ambiente di sviluppo principale di Pantheon. Inoltre, le merge request su GitLab possono creare e deployare codice negli ambienti multidev di Pantheon.

In questa guida, spiegherò come impostare la connessione tra GitLab e Pantheon e ottimizzare il flusso di lavoro di WordPress e Drupal.

Certo, possiamo rispecchiare il repository di GitLab, ma faremo tutto manualmente per esaminare GitLab CI e in futuro usare questo strumento non solo per il deployment.

Introduzione

Per questo post, è importante comprendere che Pantheon suddivide ogni sito in tre elementi: codice, database e file.

Il codice comprende i file CMS, come il nucleo, i plugin e i temi di WordPress. Questi file sono gestiti nel repository Git, ospitato da Pantheon, il che significa che possiamo distribuire il codice da GitLab a Pantheon utilizzando Git.
I file in Pantheon si riferiscono ai file multimediali, ovvero le immagini per il sito. Di solito vengono caricati dagli utenti e Git li ignora.

Crea un account gratuito, scopri di più sul workflow di Pantheon o e prenota una demo su pantheon.io.

Assunzioni

Il mio progetto su Pantheon e GitLab si chiama pantheon-gitlab-blog-demo. Il nome del progetto deve essere unico. Qui lavoreremo con un sito WordPress. Si può scegliere anche Drupal, ma dovremo apportare alcune modifiche.

Userò la riga di comando Git, ma puoi lavorare in un'interfaccia grafica, se lo desideri.

Creiamo un progetto

Per iniziare, creiamo un progetto GitLab (ci torneremo ancora).

Ora creiamo un sito WordPress su Pantheon. Poi installiamo WordPress per il dashboard del sito.

Se hai voglia di apportare modifiche, ad esempio rimuovere e aggiungere plugin, aspetta. Il sito non è ancora collegato a GitLab, e vogliamo che tutte le modifiche al codice avvengano tramite GitLab.

Quando avremo installato WordPress, torniamo al dashboard del sito Pantheon e cambiamo la modalità di sviluppo in Git.

Il commit iniziale su GitLab

Ora dobbiamo trasferire il codice iniziale di WordPress dal sito Pantheon a GitLab. Per farlo, cloniamo il codice dal repository Git del sito Pantheon in locale, e poi lo inviamo al repository GitLab.

Per semplificare e rendere tutto più sicuro, aggiungiamo una chiave SSH a Pantheon e non dovremo inserire ogni volta la password quando cloniamo il repository Pantheon Git. Approfittiamo anche per aggiungere la chiave SSH su GitLab.

Per farlo, cloniamo il sito Pantheon in locale, copiando il comando dal campo Clona con Git nel dashboard del sito.

Se hai bisogno di aiuto, consulta la documentazione per iniziare a lavorare con Git per Pantheon.

Ora modifichiamo git remote origin, per puntare a GitLab invece che a Pantheon. Questo può essere fatto con il comando git remote.

Andiamo al progetto GitLab e copiamo l'URL del repository dal menu a discesa Clona nella pagina dei dettagli del progetto. Scegliamo l'opzione Clona con SSH, dato che abbiamo già configurato la chiave SSH.

Per impostazione predefinita git remote per la copia locale del repository di codice — origin. Questo può essere cambiato con git remote set-url origin [URL del repository GitLab], dove al posto delle parentesi introduciamo l'URL effettivo.

Infine, eseguiamo git push origin master --force, per inviare il codice WordPress dal sito Pantheon a GitLab.

Il parametro –force è necessario solo una volta. Poi nei comandi git push non ci sarà su GitLab.

Configurando le credenziali e le variabili

Ricordate come abbiamo aggiunto localmente la chiave SSH per autorizzarci in Pantheon e GitLab? Il token SSH può essere utilizzato per l'autenticazione su GitLab e Pantheon.

GitLab ha una documentazione eccellente. Vediamo la sezione sulle chiavi SSH quando si utilizza l'esecutore Docker nel documento sull'uso delle chiavi SSH con GitLab CI/CD.

Ora eseguiremo i primi due passaggi: creeremo una nuova coppia di chiavi SSH localmente con ssh-keygen e aggiungeremo la chiave privata come variabile nel progetto.

Poi imposteremo SSH_PRIVATE_KEY come variabile d'ambiente GitLab CI/CD nelle impostazioni del progetto.
Nel terzo e quarto passaggio creeremo il file .gitlab-ci.yml con il seguente contenuto:

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

Non committiamo il file per ora .gitlab-ci.yml, poi ci sarà bisogno di aggiungere qualcos'altro.

Ora eseguiamo il quinto passaggio e aggiungiamo la chiave pubblica che abbiamo creato nel primo passaggio ai servizi ai quali è necessario accedere nell'ambiente di build.

Nel nostro caso vogliamo accedere a Pantheon da GitLab. Seguiamo le istruzioni nel documento di Pantheon per aggiungere la chiave SSH in Pantheon e completiamo questo passaggio.

Ricordiamo: la chiave SSH privata va su GitLab, quella pubblica su Pantheon.

Imposteremo altre variabili d'ambiente. La prima si chiama PANTHEON_SITE. Il suo valore è il nome del sito Pantheon sul vostro computer.

Il nome sul computer è indicato alla fine del comando Clone with Git. Avete già clonato il sito localmente, quindi sarà il nome della directory del repository locale.

Poi imposteremo la variabile d'ambiente PANTHEON_GIT_URL. Questo è l'URL del repository Git per il sito Pantheon, che abbiamo già utilizzato.

Inseriamo solo l'URL SSH del repository, senza git clone e senza il nome del sito sul computer alla fine.

Fuh. Fatto, ora possiamo terminare il nostro file .gitlab-ci.yml.

Creiamo un'attività di deploy

Ciò che faremo inizialmente con GitLab CI è molto simile a quello che abbiamo fatto prima con i repository Git. Ma questa volta aggiungeremo il repository Pantheon come secondo source remoto Git, e poi invieremo il codice da GitLab a Pantheon.

Per fare ciò imposteremo il stage deploy e l'attività deploy:dev, poiché stiamo deployando nell'ambiente di sviluppo su Pantheon. Di conseguenza, il file .gitlab-ci.yml avrà questo aspetto:

fasi:
- distribuzione

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

distribuzione:dev:
  fase: distribuzione
  ambiente:
    nome: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  script:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  solo:
    - master

Variabili SSH_PRIVATE_KEY, PANTHEON_SITE e PANTHEON_GIT_URL dovrebbero sembrare familiari — abbiamo configurato queste variabili ambientali in precedenza. Con queste variabili potremo utilizzare i valori nel file .gitlab-ci.yml molte volte, e dovranno essere aggiornate solo in un unico posto.

Infine, aggiungiamo, facciamo il commit e inviamo il file .gitlab-ci.yml su GitLab.

Verifichiamo la distribuzione

Se abbiamo fatto tutto correttamente, il job deploy:dev verrà eseguito con successo in GitLab CI/CD e invierà il commit .gitlab-ci.yml a Pantheon. Diamo un'occhiata.

Inviamo i rami delle merge request a Pantheon

Qui useremo la mia funzione preferita di Pantheon — multidev, dove è possibile creare ambienti aggiuntivi di Pantheon per i rami Git su richiesta.

L'accesso a multidev è limitato, quindi questa sezione può essere saltata. Ma se hai accesso, puoi migliorare notevolmente le prestazioni configurando la creazione automatica di ambienti multidev su Pantheon dalle merge request di GitLab.

Prima facciamo un nuovo ramo Git localmente usando git checkout -b multidev-support. Ora modifichiamo ancora qualcosa in .gitlab-ci.yml.

Mi piace inserire il numero della merge request nel nome dell'ambiente Pantheon. Ad esempio, la prima merge request è mr-1, la seconda è mr-2 e così via.

La merge request cambia, quindi dobbiamo definire dinamicamente i nomi dei rami Pantheon. Su GitLab è semplice – basta usare variabili ambientali predefinite.

Possiamo prendere $CI_MERGE_REQUEST_IID, per indicare il numero della merge request. Mettiamo insieme tutto questo con le variabili ambientali globali che abbiamo specificato in precedenza e aggiungiamo un nuovo job deploy:multidev alla fine del file .gitlab-ci.yml.

deploy:multidev:
  fase: distribuzione
  ambiente:
    nome: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Controlla il ramo sorgente della merge request
    - git checkout $CI_COMMIT_REF_NAME
    # Aggiungi il repository git di Pantheon come remote aggiuntivo
    - git remote add pantheon $PANTHEON_GIT_URL
    # Spingi il ramo sorgente della merge request a Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  solo:
    - merge_requests

Sarà simile al nostro job deploy:dev, solo che il ramo viene inviato a Pantheon, e non a master.

Abbiamo aggiunto e fatto il commit del file aggiornato .gitlab-ci.yml, e ora inviamo il nuovo ramo a GitLab con git push -u origin multidev-support.

Ora creiamo una nuova merge request dal ramo supporto multidev, facendo clic su Crea richiesta di unione.

Dopo aver creato la richiesta di unione, vediamo come viene eseguita l'attività CI/CD deploy:multidev.

Guarda - è stata inviata una nuova branch a Pantheon. Ma se andiamo alla sezione multidev sulla dashboard del sito su Pantheon, non vedremo lì il nuovo ambiente

Esaminiamo la sezione Git Branches.

Alla fine la nostra branch mr-1 è arrivata a Pantheon. Creiamo un ambiente dalla branch mr-1.

Abbiamo creato un ambiente multidev, ora torniamo su GitLab e diamo un'occhiata alla sezione Operazioni > Ambienti. Vedremo le voci per dev e mr-1.

Questo perché abbiamo aggiunto una voce ambiente con il nome name e url nelle attività CI/CD. Se facciamo clic sull'icona dell'ambiente aperto, verremo indirizzati all'URL dell'ambiente multidev su Pantheon.

Automatizziamo la creazione di multidev

In linea di massima, possiamo fermarci qui e semplicemente non dimenticare di creare un ambiente multidev per ogni richiesta di unione, ma questo processo può essere automatizzato.

In Pantheon c'è uno strumento da riga di comando Terminus, dove possiamo lavorare sulla piattaforma in modo automatico. Con Terminus possiamo creare ambienti multidev tramite la riga di comando — ideale per GitLab CI.

Abbiamo bisogno di una nuova richiesta di unione per testare questo. Creiamo una nuova branch usando git checkout -b auto-multidev-creation.

Per utilizzare Terminus nelle attività CI/CD di GitLab, è necessario un token macchina per l'autenticazione su Terminus e un'immagine del contenitore con Terminus.

Creiamo un token macchina Pantheon, salviamolo in un luogo sicuro e aggiungiamolo come variabile d'ambiente globale in GitLab chiamata PANTHEON_MACHINE_TOKEN.

Se hai dimenticato come aggiungere variabili d'ambiente in GitLab, torna dove abbiamo definito PANTHEON_SITE.

Creiamo un Dockerfile con Terminus

Se non stai usando Docker o non ti piacciono i file Dockerfile, prendi la mia immagine registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest e salta questa sezione.

In GitLab c'è un registro di contenitori, dove possiamo assemblare e pubblicare il Dockerfile per il nostro progetto. Creiamo un file Dockerfile con Terminus per lavorare con Pantheon.

Terminus è uno strumento da riga di comando in PHP, quindi iniziamo con l'immagine PHP. Installo Terminus tramite Composer, quindi partiamo dall' immagine Docker ufficiale di Composer. Creiamo Dockerfile nella directory del repository locale con il seguente contenuto:

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

Segui le istruzioni per costruire e pubblicare le immagini dalla sezione Costruisci e pubblica immagini in della documentazione del registro di contenitori, per costruire l'immagine da Dockerfile e pubblicarla su GitLab.

Apriamo la sezione Registro nel progetto GitLab. Se tutto è andato secondo i piani, lì troveremo la nostra immagine. Prendi nota del link del tag dell'immagine — ci servirà per il file .gitlab-ci.yml.

La sezione script nell'attività deploy:multidev inizia a espandersi, quindi spostiamolo in un file separato. Creiamo un nuovo file 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

Lo script si trova nella directory privata e non fornisce accesso web su Pantheon. Abbiamo uno script per la nostra logica multidev. Adesso aggiorniamo la sezione deploy:multidev del file .gitlab-ci.yml, in modo che diventi così:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Esegui lo script di distribuzione multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Dobbiamo assicurarci che i nostri compiti vengano eseguiti nell'immagine personalizzata creata, quindi aggiungiamo la definizione image con l'URL del registro in .gitlab-ci.yml. In definitiva, abbiamo ottenuto un file così .gitlab-ci.yml:

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

stages:
- deploy

before_script:
  # Vedi 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:
    # Esegui lo script di distribuzione multidev
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Aggiungiamo, registriamo e inviamo private/multidev-deploy.sh e .gitlab-ci.yml. Ora torniamo su GitLab e aspettiamo che il compito CI/CD venga completato. Abbiate pazienza: il multidev potrebbe richiedere alcuni minuti per essere creato.

Poi andiamo a controllare l'elenco multidev su Pantheon. Oh meraviglia! L'ambiente multidev mr-2 è già qui.

Conclusione

Il mio team ha iniziato a lavorare molto più felicemente quando abbiamo iniziato ad aprire merge request e creare ambienti automaticamente.

Con i potenti strumenti di GitLab e Pantheon è possibile connettere GitLab a Pantheon automaticamente.

Poiché utilizziamo GitLab CI/CD, il nostro flusso di lavoro avrà molto spazio per crescere. Ecco alcune idee per iniziare:

Aggiungi un passaggio di build.
Aggiungi test automatizzati.
Aggiungi un compito per garantire la conformità agli standard di codice.
Aggiungi test di sicurezza delle applicazioni dinamico.

Scrivi cosa pensi di GitLab, Pantheon e automazione.

P.S. Sapevi che Terminus, lo strumento da riga di comando di Pantheon, può essere esteso tramite plugin?

In Pantheon abbiamo lavorato sodo sulla versione 2 del nostro plugin per gli strumenti di build Terminus con il supporto di GitLab. Se non vuoi impazzire con la configurazione per ogni progetto, prova questo plugin e aiutaci a testare la beta v2. Per il team di Terminus build:project:create necessiti solo del token Pantheon e del token GitLab. Installerà uno degli esempi di progetto con Composer e test automatici, creerà un nuovo progetto in GitLab, un nuovo sito Pantheon e li collegherà tramite variabili di ambiente e chiavi SSH.