Il nostro ospite, creatore di strumenti per sviluppatori di Pantheon, spiega come automatizzare i deploy di WordPress utilizzando GitLab CI/CD.
In Mi occupo di relazioni con gli sviluppatori, quindi cerco sempre nuovi modi per aiutare gli sviluppatori di WordPress e Drupal a risolvere i problemi di automazione nei loro workflow. A tal fine, mi piace sperimentare nuovi strumenti e combinarli per un lavoro efficace.
Vedo spesso sviluppatori alle prese con un server intermedio.
Non è molto divertente dover aspettare il proprio turno per utilizzare il server intermedio o inviare ai clienti un URL con la nota: "Guarda qui, ma non qui per ora".
sono uno degli ottimi strumenti di Pantheon che risolvono questo problema, consentendo di creare ambienti per rami Git su richiesta. Ogni ambiente multidev ha il proprio URL e database, permettendo così agli sviluppatori di lavorare tranquillamente, controllare la qualità e ottenere approvazioni senza pestarsi i piedi l'uno con l'altro.
Ma in Pantheon non ci sono strumenti per il controllo delle versioni o l'integrazione e il deployment continuo (CI/CD). Tuttavia, è una piattaforma flessibile che consente di integrare qualsiasi strumento.
Ho notato che per lo sviluppo il team utilizza strumenti diversi rispetto a quelli per la costruzione e il deployment.
Ad esempio, hanno strumenti distinti per il controllo delle versioni e per CI/CD. È necessario destreggiarsi e passare tra vari strumenti per modificare il codice e diagnosticare problemi.
Su C'è un kit completo di strumenti per lo sviluppo: per il controllo delle versioni, i ticket, le richieste di merge, un pipeline CI/CD di prim'ordine, un registro dei contenitori e tutto il resto. Non ho mai visto applicazioni con così tanto per gestire il flusso di lavoro dello sviluppo.
Adoro l'automazione, quindi ho studiato come collegare Pantheon a GitLab, in modo che i commit nel ramo principale di GitLab vengano eseguiti nella principale ambiente di sviluppo in Pantheon. Inoltre, le richieste di merge su GitLab possono creare e distribuire codice negli ambienti multidev in Pantheon.
In questa guida, spiegherò come configurare la connessione tra GitLab e Pantheon e ottimizzare il flusso di lavoro per WordPress e Drupal.
Certo, , ma faremo tutto manualmente per esplorare e in futuro utilizzare 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 include i file CMS, come il core, i plugin e i temi di WordPress. Questi file sono gestiti in , ospitato su Pantheon, quindi possiamo distribuire il codice da GitLab a Pantheon tramite Git.
I file in Pantheon si riferiscono a file multimediali, ovvero immagini per il sito. Di solito vengono caricati dagli utenti, e Git li ignora.
, scopri di più sul o 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ò usare anche Drupal, ma serviranno alcune modifiche.
Utilizzerò , ma puoi lavorare in , se preferisci.
Creiamo un progetto
Per iniziare, creiamo (ci torneremo più tardi).
Ora . Poi installeremo WordPress per il dashboard del sito.
Se hai voglia di apportare delle modifiche, come rimuovere o aggiungere plugin, aspetta. Il sito non è ancora connesso a GitLab e vogliamo che tutte le modifiche al codice passino attraverso GitLab.
Quando installeremo WordPress, torniamo alla dashboard del sito Pantheon e cambiamo la modalità di sviluppo su Git.
Primo commit su GitLab
Ora dobbiamo spostare il codice iniziale di WordPress dal sito Pantheon a GitLab. Per farlo, cloniamo il codice dal repository Git del sito Pantheon localmente e poi lo inviando al repository di GitLab.
Per rendere tutto più semplice e sicuro, in modo da non dover inserire ogni volta la password quando cloniamo il repository Git di Pantheon. Inoltre, .
Per fare ciò, cloniamo il sito Pantheon localmente, copiando il comando dal campo Clone with Git sulla dashboard del sito.
Se hai bisogno di aiuto, consulta la documentazione .
Ora modifichiamo git remote origin, per fare riferimento a GitLab invece che a Pantheon. Questo può essere fatto .
Andiamo al progetto GitLab e copiamo l'URL del repository dal menu a discesa Clone nella pagina dei dettagli del progetto. Scegliamo l'opzione Clone with SSH, dato che abbiamo già configurato la chiave SSH.
Di default 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 inseriamo 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 sola volta. Poi nei comandi
git pushsu GitLab non ci sarà.
Configuriamo le credenziali e le variabili
Ricordate come abbiamo aggiunto localmente la chiave SSH per autenticarci in Pantheon e GitLab? Il token SSH può essere utilizzato per l'autenticazione su GitLab e Pantheon.
GitLab ha una documentazione eccellente. Diamo un'occhiata .
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 ZFS archivia i dati su disco. 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 commettiamo ancora il file .gitlab-ci.yml, poi dovremo aggiungere ancora qualcosa.
Adesso eseguiamo il quinto passaggio e aggiungiamo la chiave pubblica che abbiamo creato nel primo passaggio ai servizi ai quali serve l'accesso nell'ambiente di build..
Nel nostro caso, vogliamo accedere a Pantheon tramite GitLab. Seguiamo le istruzioni nel documento di Pantheon per e portiamo a termine questo passaggio.
Ricordiamo: la chiave SSH privata è in GitLab, quella pubblica è in Pantheon.
Configuriamo alcune variabili di ambiente aggiuntive. La prima si chiama PANTHEON_SITE. Il suo valore è il nome del sito Pantheon sulla vostra macchina.
Il nome sulla macchina è indicato alla fine del comando Clone with Git. Avete già clonando il sito localmente, quindi sarà il nome della cartella del repository locale.
Proseguiamo configurando la variabile di 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 clonee il nome del sito sulla macchina alla fine.
Phew. Fatto, ora possiamo completare il nostro file .gitlab-ci.yml.
Creiamo un compito di deployment.
Quello che inizialmente faremo con GitLab CI è molto simile a quanto facevamo con i repository Git in passato. Ma questa volta aggiungeremo il repository Pantheon come secondo remote Git e poi invieremo il codice da GitLab a Pantheon.
Configuriamo per questo deploy e deploy:dev, poiché effettueremo il deploy nell'ambiente di sviluppo su Pantheon. Il file risultante .gitlab-ci.yml avrò questo aspetto:
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:
- masterVariabili SSH_PRIVATE_KEY, PANTHEON_SITE e PANTHEON_GIT_URL dovrebbero sembrarti familiari — abbiamo configurato queste variabili d'ambiente in precedenza. Con queste variabili potremo utilizzare i valori nel file .gitlab-ci.yml numerose volte, e sarà necessario aggiornarli solo in un luogo.
Infine, aggiungiamo, facciamo il commit e inviamo il file .gitlab-ci.yml su GitLab.
Controlliamo il deploy
Se abbiamo fatto tutto correttamente, il compito deploy:dev verrà eseguito correttamente in GitLab CI/CD e invierà il commit .gitlab-ci.yml a Pantheon. Diamo un'occhiata.
Invio dei branch dei merge request a Pantheon
Qui utilizzeremo la mia funzione preferita di Pantheon — , dove è possibile creare ulteriori ambienti Pantheon per branch Git su richiesta.
, quindi questa sezione può essere saltata. Ma se hai accesso, puoi seriamente aumentare le prestazioni configurando la creazione automatica degli ambienti multidev su Pantheon dai merge request di GitLab.
Iniziamo a creare un nuovo ramo Git localmente usando git checkout -b multidev-support. Ora apportiamo alcune modifiche in .gitlab-ci.yml.
Mi piace includere il numero del merge request nel nome dell'ambiente Pantheon. Ad esempio, il primo merge request è mr-1, il secondo è mr-2 ecc.
Il merge request cambia, quindi dobbiamo determinare dinamicamente i nomi dei rami Pantheon. Su GitLab è semplice: basta usare .
Possiamo prendere $CI_MERGE_REQUEST_IID, per indicare il numero del merge request. Mettiamo tutto questo insieme con le variabili ambiente globali che abbiamo definito in precedenza e aggiungiamo un nuovo task deploy:multidev alla fine del file .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_requestsSarà simile al nostro task deploy:dev, solo il ramo viene inviato a Pantheon, non a master.
Abbiamo aggiunto e committato il file aggiornato .gitlab-ci.yml, e ora invieremo un nuovo ramo in GitLab con git push -u origin multidev-support.
Ora creiamo una nuova merge request dal ramo multidev-support, facendo clic su Crea merge request.
Dopo aver creato la merge request, vediamo come procede il task CI/CD deploy:multidev.
Guarda—un nuovo ramo è stato inviato a Pantheon. Ma se andiamo alla sezione multidev nel dashboard del sito su Pantheon, non vedremo l'ambiente nuovo
Diamo un'occhiata alla sezione Git Branches.
Alla fine il nostro ramo mr-1 è arrivato a Pantheon. Creiamo un ambiente dal ramo mr-1.
Abbiamo creato un ambiente multidev, e ora torniamo in GitLab e controlliamo la sezione Operations > Environments. Vedremo delle voci per dev e mr-1.
Questo perché abbiamo aggiunto una voce environment chiamato name e url nelle attività CI/CD. Se clicchiamo sull'icona dell'ambiente aperto, andremo all'URL dell'ambiente multidev su Pantheon.
Automatizziamo la creazione di multidev
In linea di principio, possiamo fermarci qui e semplicemente ricordarci di creare un ambiente multidev per ogni merge request, ma questo processo può essere automatizzato.
Su Pantheon c'è uno strumento da riga di comando , dove è possibile lavorare con la piattaforma in modo automatico. Con Terminus si possono creare ambienti multidev dalla riga di comando—ideale per .
Abbiamo bisogno di una nuova merge request per testarlo. Creeremo un nuovo branch utilizzando git checkout -b auto-multidev-creation.
Per utilizzare Terminus nei task GitLab CI/CD, è necessario un token macchina per autenticarsi in Terminus e un'immagine del container con Terminus.
, lo conserviamo in un luogo sicuro e lo aggiungiamo come variabile d'ambiente globale in GitLab con il nome PANTHEON_MACHINE_TOKEN.
Se hai dimenticato come aggiungere le variabili d'ambiente in GitLab, torna a dove abbiamo definito
PANTHEON_SITE.
Creiamo un Dockerfile con Terminus
Se non utilizzi Docker o non ti piace lavorare con i file Dockerfile, prendi la mia immagine registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest e salta questa sezione.
, dove puoi costruire e ospitare 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 un'immagine PHP. Installo Terminus tramite Composer, quindi prenderò come base . 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"Seguiamo le istruzioni per costruire e inviare immagini dalla sezione Build and push images in , per costruire un'immagine da Dockerfile e inviarlo a GitLab.
Apriamo la sezione Registry nel progetto GitLab. Se tutto è andato secondo i piani, lì ci sarà la nostra immagine. Annotate il link al tag dell'immagine - ci serve per il file .gitlab-ci.yml.
Sezione script nell'attività deploy:multidev inizia a crescere, quindi trasferiamolo 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..."
fiLo script si trova nella directory privata e . Abbiamo uno script per la nostra logica multidev. Ora aggiorniamo la sezione deploy:multidev file .gitlab-ci.yml, per ottenere questo risultato:
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 deploy multidev
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsDobbiamo assicurarci che le nostre attività vengano eseguite nell'immagine personalizzata creata, quindi aggiungiamo la definizione image con l'URL del registry in .gitlab-ci.yml. Alla fine abbiamo ottenuto un file del genere .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_requestsAggiungiamo, committiamo e inviamo private/multidev-deploy.sh e .gitlab-ci.yml. Torniamo quindi su GitLab e aspettiamo che il job CI/CD venga eseguito. Pazientate: la creazione di multidev potrebbe richiedere alcuni minuti.
Poi andiamo a controllare l'elenco dei multidev su Pantheon. Oh, meraviglia! L'ambiente multidev mr-2 è già qui.
Conclusione
Il mio team è diventato molto più collaborativo da quando abbiamo iniziato ad aprire richieste di merge e creare gli ambienti automaticamente.
Con gli strumenti potenti di GitLab e Pantheon è possibile collegare GitLab a Pantheon automaticamente.
Dal momento che utilizziamo GitLab CI/CD, il nostro flusso di lavoro avrà molto spazio per crescere. Ecco un paio di idee per iniziare:
- Aggiungi un passaggio di build.
- Aggiungi test automatizzati.
- Aggiungi un'attività per garantire il rispetto degli standard di codifica.
- Aggiungi .
Scrivi cosa pensi di GitLab, Pantheon e automazione.
P.S. Sapevi che Terminus, l'outil da riga di comando di Pantheon, ?
Noi di Pantheon abbiamo lavorato sodo sulla versione 2 del nostro con supporto per GitLab. Se non vuoi perderti in configurazioni per ogni progetto, prova questo plugin e aiutaci a testare la beta v2. Per il team di Terminus, build:project:create serve solo un token Pantheon e un token GitLab. Questo lancerà uno dei progetti di esempio con Composer e test automatici, creerà un nuovo progetto in GitLab, un nuovo sito Pantheon e li collegherà tramite variabili d'ambiente e chiavi SSH.
Informazioni sull'autore
Andrew Taylor crea strumenti per sviluppatori in .
Fonte: habr.com
