
Vores gæst, skaberen af udviklerværktøjer fra Pantheon, fortæller, hvordan man automatiserer WordPress-deploys med GitLab CI/CD.
I Jeg arbejder med udviklerrelationer, så jeg leder altid efter nye måder at hjælpe WordPress- og Drupal-udviklere med at løse automatiseringsproblemer i deres arbejdsgange. Derfor elsker jeg at eksperimentere med nye værktøjer og kombinere dem for at optimere arbejdet.
Jeg ser ofte, hvordan udviklere kæmper med én midlertidig server.
Det er ikke sådan, at man glæder sig over at skulle vente på sin tur til at bruge den midlertidige server, eller at sende kunderne en URL med kommentaren: ‘Se her, men se ikke her endnu.’
— et af de fantastiske værktøjer fra Pantheon — løser dette problem, da det gør det muligt at oprette miljøer pr. anmodning til Git-grene. Hvert multidev-miljø har sin egen URL og database, så udviklerne kan arbejde uforstyrret, tjekke kvaliteten og få godkendelse uden at træde hinanden over tæerne.
Men der er ikke værktøjer til versionskontrol eller kontinuerlig integration og deployment (CI/CD) i Pantheon. Men det er en fleksibel platform, hvor man kan integrere alle slags værktøjer.
Jeg har også bemærket, at teams bruger forskellige værktøjer til udvikling og andre til compilering og deployment.
For eksempel har de forskellige værktøjer til versionskontrol og CI/CD. Det kræver, at man roder og skifter mellem værktøjer for at redigere koden og diagnosticere problemer.
På Der findes et omfattende sæt værktøjer til udvikling: til versionskontrol, ticketer, merge-forespørgsler, en førsteklasses CI/CD-pipeline, en containerregister og meget mere. Jeg har endnu ikke set applikationer, der har så meget til styring af udviklingsarbejdsgange.
Jeg elsker automatisering, så jeg har undersøgt, hvordan man forbinder Pantheon til GitLab, så commits til hovedgrenen på GitLab bliver deployet til hovedudviklingsmiljøet i Pantheon. Desuden kan merge-forespørgsler på GitLab oprette og deploye kode til multidev-miljøer i Pantheon.
I denne vejledning vil jeg vise, hvordan man opsætter forbindelsen mellem GitLab og Pantheon og optimerer arbejdsgangen for WordPress og Drupal.
Man kan selvfølgelig , men vi vil gøre det manuelt for at dykke ned i og i fremtiden bruge dette værktøj ikke kun til deployment.
Introduktion
For this post, it's important to understand that Pantheon splits each site into three elements: code, database, and files.
The code includes CMS files, such as the core, plugins, and themes of WordPress. These files are managed in , hosted by Pantheon, meaning we can deploy code from GitLab to Pantheon via Git.
Files in Pantheon refer to media files, namely images for the site. Typically, they are uploaded by users, and Git ignores them.
, learn more about eller on pantheon.io.
Assumptions
My project on Pantheon and GitLab is called pantheon-gitlab-blog-demo. The project name must be unique. Here, we will work with a WordPress site. Drupal can also be used, but some adjustments are needed.
I will be using , while you can work in , if you prefer.
Creating a project
First, we create a (we will return to this).
Now . Then we install WordPress for the site's dashboard.
If you're eager to make changes, such as removing or adding plugins, hold on. The site isn't connected to GitLab yet, and we want all code changes to go through GitLab.
Once we install WordPress, we return to the Pantheon site's dashboard and switch the development mode to Git.
Initial commit to GitLab
Now we need to transfer the initial WordPress code from the Pantheon site to GitLab. To do this, we clone the code from the Pantheon site's Git repository locally and then send it to the GitLab repository.
To make it easier and more secure, and won’t have to enter a password each time we clone the Pantheon Git repository. At the same time, we’ll also .
To do this, we clone the Pantheon site locally, copying the command from the Clone with Git field on the site's dashboard.
If you need help, read the documentation .
Now we will change git remote origin, to point to GitLab instead of Pantheon. This can be done with .
Let's go to the GitLab project and copy the repository URL from the Clone dropdown on the project details page. We will choose the Clone with SSH option since we have already set up the SSH key.
By default git remote for the local copy of the code repository— origin. This can be changed with git remote set-url origin [GitLab repository URL], where we input the actual URL instead of the brackets.
Finally, we run git push origin master --force, to transfer the WordPress code from the Pantheon site to GitLab.
Parameter –force is only needed once. Then in the commands
git pushit will not be on GitLab.
Setting up credentials and variables
Remember how we locally added an SSH key to authenticate with Pantheon and GitLab? An SSH token can be used for authentication with GitLab and Pantheon.
GitLab has excellent documentation. Let's take a look at the .
Right now we will perform the first two steps: we will create a new pair of SSH keys locally with ssh-keygen and add the private key as a variable in the project.
Then we will set the SSH_PRIVATE_KEY hvordan in the project settings.
In the third and fourth steps, we will create a file .gitlab-ci.yml med følgende indhold:
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"For now, let's not commit the file .gitlab-ci.yml, we will need to add a few more things to it later.
Now we execute the fifth step and add the public key we created in the first step to the services you need access to in the build environment.
In our case, we want to access Pantheon from GitLab. We follow the instructions in the Pantheon document for and complete this step.
Remember: the private SSH key goes in GitLab, the public key goes in Pantheon.
Let's set up a few more environment variables. The first is called PANTHEON_SITE. Its value is the Pantheon site name on your machine.
The name on the machine is given at the end of the Clone with Git command. Since you have already cloned the site locally, it will be the name of the local repository directory.
Next, we will set up the environment variable PANTHEON_GIT_URL. This is the Git repository URL for the Pantheon site we have already used.
We only enter the URL of the SSH repository, without
git cloneand the site name on the machine at the end.
Phew. We did that, now we can finish our file .gitlab-ci.yml.
Creating a deployment task
What we will initially do with GitLab CI is very similar to what we did with Git repositories before. But this time we will add the Pantheon repository as a second remote Git source and then send the code from GitLab to Pantheon.
To do this, we will configure deploy og deploy:dev, since we will be deploying to the development environment on Pantheon. As a result, the file .gitlab-ci.yml will look like this:
faser:
- deploy
before_script:
# Se 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:
fase: deploy
miljø:
navn: dev
url: https://dev-$PANTHEON_SITE.pantheonsite.io/
script:
- git remote add pantheon $PANTHEON_GIT_URL
- git push pantheon master --force
kun:
- masterVariabler SSH_PRIVATE_KEY, PANTHEON_SITE og PANTHEON_GIT_URL bør se bekendt ud — vi har sat disse miljøvariabler op tidligere. Med disse variabler kan vi bruge værdier i filen .gitlab-ci.yml mange gange, og opdatere dem skal kun ske ét sted.
Til sidst tilføjer, committer og sender vi filen .gitlab-ci.yml til GitLab.
Vi tester deployment
Hvis vi har gjort alt korrekt, vil opgaven deploy:dev blive udført med succes i GitLab CI/CD og sende commit .gitlab-ci.yml til Pantheon. Lad os tage et kig.
Sender merge request branches til Pantheon
Her vil vi bruge min yndlingsfunktion i Pantheon — , hvor man kan oprette ekstra Pantheon-miljøer til Git-branches på anmodning.
, så dette afsnit kan måske springes over. Men hvis du har adgang, kan du virkelig forbedre ydelsen ved at indstille automatisk oprettelse af multidev-miljøer på Pantheon fra GitLab merge requests.
Lad os først lave en ny Git-branch lokalt med git checkout -b multidev-support. Nu vil vi ændre lidt i .gitlab-ci.yml.
Jeg kan godt lide at inkludere nummeret på merge requesten i navnet på miljøet i Pantheon. For eksempel, første merge request — mr-1, den anden — mr-2 osv.
Merge requesten ændres, så vi skal dynamisk definere navnene på Pantheon-branches. På GitLab er det ret enkelt — vi skal bruge .
Vi kan tage $CI_MERGE_REQUEST_IID, for at angive nummeret på merge requesten. Lad os samle alt dette med de globale miljøvariabler, vi har angivet tidligere, og tilføje en ny opgave deploy:multidev i slutningen af filen .gitlab-ci.yml.
deploy:multidev:
fase: deploy
miljø:
navn: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Tjek kildes branch for merge requesten ud
- git checkout $CI_COMMIT_REF_NAME
# Tilføj Pantheon git-repositoriet som en ekstra remote
- git remote add pantheon $PANTHEON_GIT_URL
# Push kildes branch for merge requesten til Pantheon
- git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
kun:
- merge_requestsDet vil se ud som vores opgave deploy:dev, kun at branchen sendes til Pantheon, og ikke til master.
Vi har tilføjet og committet den opdaterede fil .gitlab-ci.yml, og nu sender vi den nye branch til GitLab med git push -u origin multidev-support.
Nu opretter vi en ny merge request fra branchen multidev-support, ved at klikke Opret mersch-request.
Når vi har oprettet mersch-request, kan vi se, hvordan CI/CD opgaven udføres deploy:multidev.
Se – der er sendt en ny gren til Pantheon. Men hvis vi går til multidev-sektionen på Pantheon-dashboardet, vil vi ikke se den nye miljø
Lad os se på sektionen Git Branches.
Til slut er vores gren mr-1 kommet til Pantheon. Lad os oprette et miljø fra grenen mr-1.
Vi har oprettet et multidev-miljø, og nu vender vi tilbage til GitLab og kigger i sektionen Operations > Environments. Vi vil se poster for dev og mr-1.
Dette er fordi, vi har tilføjet en post environment med navnet name og url til CI/CD-opgaverne. Hvis vi klikker på ikonet for det åbne miljø, vil vi blive sendt til URL'en for multidev miljøet på Pantheon.
Vi automatiserer oprettelsen af multidev
I princippet kan vi stoppe her og blot huske at oprette et multidev-miljø til hver mersch-request, men denne proces kan automatiseres.
I Pantheon er der et kommandolinjeværktøj , hvor vi kan arbejde med platformen automatisk. I Terminus kan vi skabe multidev-miljøer fra kommandolinjen – ideelt til .
Vi har brug for en ny mersch-request for at teste dette. Oprette en ny gren ved hjælp af git checkout -b auto-multidev-creation.
For at bruge Terminus i GitLab CI/CD-opgaverne, har vi brug for en maskintoken for autentificering i Terminus og et containerbillede med Terminus.
, gem det et sikkert sted, og tilføj det som en global miljøvariable i GitLab med navnet PANTHEON_MACHINE_TOKEN.
Hvis du har glemt, hvordan man tilføjer miljøvariable i GitLab, gå tilbage til hvor vi definerede
PANTHEON_SITE.
Opretter Dockerfile med Terminus
Hvis du ikke bruger Docker eller ikke er fan af filer Dockerfile, tag mit billede registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest og spring dette afsnit over.
, hvor vi kan samle og placere Dockerfile til vores projekt. Lad os oprette en Dockerfile med Terminus for at arbejde med Pantheon.
Terminus er et kommandolinjeværktøj skrevet i PHP, så lad os starte med PHP-billedet. Jeg installerer Terminus via Composer, så jeg vil tage udgangspunkt i . Opretter Dockerfile i mappen i det lokale repository med følgende indhold:
# 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"Følg instruktionerne til at bygge og sende billeder fra sektionen Build and push images i , for at bygge et billede fra Dockerfile og sende det til GitLab.
Åbn sektionen Registry i GitLab-projektet. Hvis alt gik som planlagt, vil vores billede være der. Notér linket til billedtaggen – det skal vi bruge til filen .gitlab-ci.yml.
Partition script i opgaven deploy:multidev begynder at vokse, så lad os flytte det til en separat fil. Opretter en ny fil 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..."
fiScriptet ligger i en privat mappe og . Vi har et script til vores multidev-logik. Lad os nu opdatere sektionen deploy:multidev filen .gitlab-ci.yml, så det bliver sådan her:
deploy:multidev:
stage: deploy
environment:
name: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Kør multidev deploy scriptet
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsVi skal sikre, at vores opgaver kører i det oprettede brugerdefinerede billede, så lad os tilføje definition billede med URL'en til registret i .gitlab-ci.yml. Til sidst har vi fået sådan en fil .gitlab-ci.yml:
image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest
stages:
- deploy
before_script:
# Se 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:
# Kør multidev deploy scriptet
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsTilføjer, committer og sender private/multidev-deploy.sh og .gitlab-ci.yml. Nu går vi tilbage til GitLab og venter på, at CI/CD-opgaven bliver udført. Vær tålmodig: multidev kan tage nogle minutter at oprette.
Derefter går vi for at se listen over multidev på Pantheon. Åh mirakler! Multidev-miljøet mr-2 er allerede her.
Konklusion
Mit team har haft det meget sjovere, siden vi begyndte at åbne merge requests og oprette miljøer automatisk.
Med de kraftfulde værktøjer fra GitLab og Pantheon kan man automatisk forbinde GitLab til Pantheon.
Da vi bruger GitLab CI/CD, vil vores arbejdsproces have mulighed for at vokse. Her er et par idéer til at komme i gang:
- Tilføj et build-trin.
- Tilføj automatiseret testning.
- Tilføj en opgave for at sikre overholdelse af kodestandarderne.
- Tilføj .
Skriv hvad du synes om GitLab, Pantheon og automatisering.
P.S. Vidste du, at Terminus, Pantheons kommandolinjeværktøj, ?
Vi hos Pantheon har arbejdet hårdt på version 2 af vores med GitLab-support. Hvis du ikke vil bøvle med opsætningen for hvert projekt, så prøv denne plugin og hjælp os med at teste beta v2. Til Terminus-teamet build:project:create du har kun brug for Pantheon-token og GitLab-token. Det vil implementere et af eksemplerne på projektet med Composer og automatisk test, skabe et nyt projekt i GitLab, en ny hjemmeside på Pantheon, og forbinde dem med miljøvariabler og SSH-nøgler.
Om forfatteren
Andrew Taylor skaber værktøjer for udviklere i .
Kilde: habr.com
