Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress
Vores gæst, skaberen af udviklerværktøjer fra Pantheon, fortæller, hvordan man automatiserer WordPress-deploys med GitLab CI/CD.

I Pantheon 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.’

Multidev-miljøer — 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å GitLab 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 spejle GitLab-repositoriet, men vi vil gøre det manuelt for at dykke ned i GitLab CI 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 a Git repository, 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.

Create a free account, learn more about the Pantheon workflow eller sign up for a demo 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 the Git command line, while you can work in the graphical interface, if you prefer.

Creating a project

First, we create a GitLab project (we will return to this).

Now We create a WordPress site on Pantheon. 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.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

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, we'll add an SSH key to Pantheon and won’t have to enter a password each time we clone the Pantheon Git repository. At the same time, we’ll also add the SSH key to GitLab..

To do this, we clone the Pantheon site locally, copying the command from the Clone with Git field on the site's dashboard.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress
If you need help, read the documentation on getting started with Git for Pantheon..

Now we will change git remote origin, to point to GitLab instead of Pantheon. This can be done with the git remote command..

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.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

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 push it 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 section on SSH keys when using the Docker executor in the documentation about using SSH keys with GitLab CI/CD.

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 GitLab CI/CD environment variable 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 adding an SSH key to Pantheon 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.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

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 clone and 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 the stage deploy og task 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:
    - master

Variabler 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.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

Sender merge request branches til Pantheon

Her vil vi bruge min yndlingsfunktion i Pantheon — multidev, hvor man kan oprette ekstra Pantheon-miljøer til Git-branches på anmodning.

Adgang til multidev er begrænset, 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 foruddefinerede miljøvariabler.

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_requests

Det 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.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

Når vi har oprettet mersch-request, kan vi se, hvordan CI/CD opgaven udføres deploy:multidev.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

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ø

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

Lad os se på sektionen Git Branches.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

Til slut er vores gren mr-1 kommet til Pantheon. Lad os oprette et miljø fra grenen mr-1.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

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 Terminus, hvor vi kan arbejde med platformen automatisk. I Terminus kan vi skabe multidev-miljøer fra kommandolinjen – ideelt til GitLab CI.

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.

Opretter maskintoken til Pantheon, 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.

I GitLab er der et containerregister, 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 det officielle Docker Composer-billede. 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 i dokumentationen for containersregisteret, 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.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

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..."
fi

Scriptet ligger i en privat mappe og giver ikke webadgang til Pantheon. 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_requests

Vi 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_requests

Tilfø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.

Hvordan forbinder man GitLab med Pantheon og optimerer arbejdsprocesserne for Drupal og WordPress

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:

Skriv hvad du synes om GitLab, Pantheon og automatisering.

P.S. Vidste du, at Terminus, Pantheons kommandolinjeværktøj, kan udvides via plugins?

Vi hos Pantheon har arbejdet hårdt på version 2 af vores plugin til build-værktøjer Terminus 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 Pantheon.

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster