🥇Hoe je GitLab en Pantheon verbindt en workflows optimaliseert Drupal и WordPress

Onze gast, Pantheon, maker van ontwikkelaarstools, vertelt over het automatiseren van implementaties. WordPress gebruikmakend van GitLab CI/CD.

В Pantheon Ik werk in de relatiebeheer voor ontwikkelaars, dus ik ben altijd op zoek naar nieuwe manieren om ontwikkelaars te helpen. WordPress и Drupal Los automatiseringsproblemen in workflows op. Daarvoor experimenteer ik graag met nieuwe tools en combineer ik ze om de efficiëntie te verhogen.

Ik zie ontwikkelaars vaak worstelen met een enkele staging-server.

Het is zo leuk om op jouw beurt te wachten om een tussenliggende server te gebruiken of klanten een URL te sturen met de opmerking: "Kijk hier, maar kijk nog niet hier."

Multidev-omgevingen - een van de coole Pantheon-tools - lost dit probleem op, omdat je hiermee op aanvraag omgevingen voor Git-takken kunt creëren. Elke multidev-omgeving heeft zijn eigen URL en database, zodat ontwikkelaars rustig kunnen werken, de kwaliteit kunnen controleren en goedkeuring kunnen krijgen zonder elkaar op de tenen te trappen.

Maar Pantheon beschikt niet over tools voor versiebeheer of continue integratie en implementatie (CI/CD). Maar het is een flexibel platform waarmee je alle tools kunt integreren.

Ik merkte ook dat teams bepaalde tools gebruiken voor ontwikkeling, en verschillende voor assemblage en implementatie.

Ze hebben bijvoorbeeld verschillende tools voor versiebeheer en CI/CD. Je moet wat rommelen en schakelen tussen tools om code te bewerken en problemen te diagnosticeren.

Op GitLab er is een volledige set ontwikkelingstools: voor versiebeheer, tickets, samenvoegverzoeken, een best-in-class CI/CD-pijplijn, een containerregister en al dat soort dingen. Ik ben nog geen applicatie tegengekomen die zoveel biedt om je ontwikkelworkflow te beheren.

Ik hou van automatisering, dus ik heb geleerd hoe ik Pantheon met GitLab kan verbinden, zodat commits naar de hoofdbranch op GitLab worden geïmplementeerd in de hoofdontwikkelomgeving in Pantheon. En samenvoegverzoeken op GitLab kunnen code maken en implementeren in multidev-omgevingen in Pantheon.

In deze handleiding laat ik je zien hoe je een verbinding tussen GitLab en Pantheon opzet en je workflow optimaliseert. WordPress и Drupal.

Natuurlijk is het mogelijk, mirror GitLab-repository, maar we zullen er alles aan doen om ons er met onze handen in te verdiepen GitLab-CI en gebruik deze tool in de toekomst niet alleen voor implementatie.

Introductie

Voor dit bericht moet je begrijpen dat Pantheon elke site in drie elementen opsplitst: code, database en bestanden.

De code bevat CMS-bestanden zoals de core, plugins en thema's. WordPressDeze bestanden worden beheerd in Git-opslagplaatsen, gehost door Pantheon, wat betekent dat we met Git code van GitLab naar Pantheon kunnen implementeren.
Bestanden in Pantheon zijn mediabestanden, dat wil zeggen afbeeldingen voor de site. Normaal gesproken worden ze door gebruikers geüpload en negeert Git ze.

Maak een gratis account, meer informatie over Pantheon-workflow of meld u aan voor een demo op pantheon.io.

Aannames

Mijn project op Pantheon en GitLab heet pantheon-gitlab-blog-demoDe projectnaam moet uniek zijn. We gaan hier met een website werken. WordPressJe kunt het ook meenemen. DrupalMaar sommige dingen zullen moeten worden veranderd.

ik zal gebruiken Git-opdrachtregelen je kunt er in werken grafische interface, als je wilt.

Maak een project

Laten we eerst creëren GitLab-project (hier komen we later op terug).

Nu We zijn een website aan het maken. WordPress op PantheonDaarna installeren we het. WordPress voor het website-dashboard.

Als je handen jeuken om iets te veranderen, bijvoorbeeld plug-ins verwijderen of toevoegen, wees dan geduldig. De site is nog niet verbonden met GitLab en we willen dat alle codewijzigingen via GitLab gaan.

Wanneer gaan we het installeren? WordPressGa terug naar het dashboard van de Pantheon-website en wijzig de ontwikkelmodus naar Git.

Eerste commit op GitLab

Nu moet je de begincode overzetten. WordPress Van de Pantheon-website naar GitLab. Hiervoor klonen we de code van de Git-repository van de Pantheon-website lokaal en pushen deze vervolgens naar de GitLab-repository.

Om het gemakkelijker en veiliger te maken, voeg een SSH-sleutel toe aan Pantheon en we hoeven niet elke keer een wachtwoord in te voeren als we een Pantheon Git-repository klonen. Tegelijkertijd al voeg een SSH-sleutel toe aan GitLab.

Om dit te doen, kloont u de Pantheon-site lokaal door de opdracht uit het veld Klonen met Git op het sitedashboard te kopiëren.

Als u hulp nodig heeft, lees dan de documentatie aan de slag met Git voor Pantheon.

Laten we nu veranderen git remote originom naar GitLab te verwijzen in plaats van naar Pantheon. Het kan gedaan worden командой git remote.

Laten we naar het GitLab-project gaan en de repository-URL kopiëren uit de vervolgkeuzelijst Klonen op de pagina met projectdetails. Laten we de optie Klonen met SSH kiezen, omdat we de SSH-sleutel al hebben geconfigureerd.

Bij verstek git remote voor een lokale kopie van de coderepository - origin. Dit kan gewijzigd worden. c git remote set-url origin [URL репозитория GitLab], waarbij we in plaats van haakjes de daadwerkelijke URL invoeren.

Eindelijk lanceren we git push origin master --forceom de code te verzenden WordPress van de Pantheon-website op GitLab.

De optie –force is slechts één keer nodig. Daarna in ploegen git push het zal niet op GitLab staan.

Referenties en variabelen instellen

Weet je nog hoe we lokaal een SSH-sleutel hebben toegevoegd om in te loggen bij Pantheon en GitLab? Het SSH-token kan worden gebruikt om GitLab en Pantheon te autoriseren.

GitLab heeft uitstekende documentatie. Laten we eens kijken sectie over SSH-sleutels bij gebruik van de Docker-uitvoerder in het document over het gebruik van SSH-sleutels met GitLab CI/CD.

We zullen nu de eerste twee stappen voltooien: Laten we lokaal een nieuw SSH-sleutelpaar maken met ssh-keygen en de privésleutel als variabele aan het project toevoegen.

Dan gaan we het vragen SSH_PRIVATE_KEY hoe GitLab CI/CD-omgevingsvariabele in de projectinstellingen.
In de derde en vierde stap maken we een bestand aan .gitlab-ci.yml met inhoud als deze:

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"

Laten we het bestand nog niet vastleggen .gitlab-ci.yml, dan zul je er nog iets aan moeten toevoegen.

Nu voeren we de vijfde stap uit en voeg de openbare sleutel die u in de eerste stap hebt gemaakt toe aan de services waartoe u toegang nodig heeft in de bouwomgeving.

In ons geval willen we toegang krijgen tot Pantheon vanuit GitLab. We volgen de instructies in het Pantheon-document op een SSH-sleutel toevoegen aan Pantheon en voer deze stap uit.

Onthoud: privé-SSH bevindt zich in GitLab, open SSH bevindt zich in Pantheon.

Laten we nog een paar omgevingsvariabelen instellen. De eerste heet PANTHEON_SITE. De waarde ervan is de naam van de Pantheon-site op uw computer.

De naam op de machine wordt vermeld aan het einde van de opdracht Klonen met Git. Je hebt de site al lokaal gekloond, dus dit zal de naam zijn van de lokale repositorymap.

Laten we vervolgens de omgevingsvariabele instellen PANTHEON_GIT_URL. Dit is de Git-repository-URL voor de Pantheon-site die we al hebben gebruikt.

Voer alleen de SSH-repository-URL in, zonder git clone en de naam van de site op de machine aan het einde.

Opluchting. Dat is klaar, nu kunnen we ons dossier afmaken .gitlab-ci.yml.

Maak een implementatietaak

Wat we in eerste instantie gaan doen met GitLab CI lijkt erg op wat we in het verleden met Git-repository's hebben gedaan. Maar laten we deze keer de Pantheon-repository toevoegen als een tweede externe Git-bron, en vervolgens de code van GitLab naar Pantheon pushen.

Om dit te doen, gaan we configureren stadium deploy и taak deploy:dev, omdat we zullen implementeren in de ontwikkelomgeving op Pantheon. Het resulterende bestand .gitlab-ci.yml zal er zo uitzien:

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

variabelen SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL zou er bekend uit moeten zien - we hebben deze omgevingsvariabelen eerder ingesteld. Met deze variabelen kunnen we de waarden in het bestand gebruiken .gitlab-ci.yml vele malen, en ze hoeven maar op één plek te worden bijgewerkt.

Voeg ten slotte het bestand toe, voer het vast en verzend het .gitlab-ci.yml op GitLab.

Het controleren van de implementatie

Als we alles goed hebben gedaan, is de taak deploy:dev zal succesvol draaien in GitLab CI/CD en een commit indienen .gitlab-ci.yml bij Pantheon. Laten we eens kijken.

Threads met samenvoegverzoeken naar Pantheon verzenden

Hier zullen we mijn favoriete Pantheon-functie gebruiken − multi-dev, waar u op aanvraag extra Pantheon-omgevingen voor Git-takken kunt creëren.

Toegang tot multidev is beperkt, zodat dit gedeelte kan worden overgeslagen. Maar als je toegang hebt, kun je de productiviteit aanzienlijk verhogen door het automatisch aanmaken van multidev-omgevingen op Pantheon in te stellen vanuit samenvoegverzoeken van GitLab.

Laten we eerst lokaal een nieuwe Git-branch maken met behulp van git checkout -b multidev-support. Laten we nu weer iets veranderen .gitlab-ci.yml.

Ik wil graag het samenvoegverzoeknummer opnemen in de Pantheon-omgevingsnaam. Het eerste samenvoegverzoek is bijvoorbeeld mr-1, seconde - mr-2 enzovoort.

Het samenvoegverzoek verandert, dus we moeten de namen van de Pantheon-filialen dynamisch bepalen. Het is gemakkelijk op GitLab - je hoeft het alleen maar te gebruiken vooraf gedefinieerde omgevingsvariabelen.

We kunnen nemen $CI_MERGE_REQUEST_IIDom het nummer van het samenvoegverzoek op te geven. Laten we dit allemaal toepassen samen met de globale omgevingsvariabelen die we eerder hebben gespecificeerd en een nieuwe taak implementeren:multidev toevoegen aan het einde van het bestand .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_requests

Het zal vergelijkbaar zijn met onze taak deploy:dev, wordt alleen het filiaal naar Pantheon gestuurd, niet naar master.

We hebben het bijgewerkte bestand toegevoegd en vastgelegd .gitlab-ci.yml, en laten we nu een nieuwe branch naar GitLab pushen git push -u origin multidev-support.

Laten we nu een nieuw samenvoegverzoek maken vanuit de vertakking multidev-supportdoor te drukken Samenvoegverzoek maken.

Nadat we een samenvoegverzoek hebben aangemaakt, kijken we hoe de CI/CD-taak wordt uitgevoerd deploy:multidev.

Kijk, er is een nieuw draadje naar Pantheon gestuurd. Maar als we naar de multidev-sectie op het Pantheon-sitedashboard gaan, zullen we de nieuwe omgeving daar niet zien

Laten we eens kijken naar de sectie Git Branches.

Met als resultaat onze draad mr-1 Pantheon bereikt. Laten we een omgeving creëren vanuit een branch mr-1.

We hebben een multidev-omgeving gemaakt. Laten we nu teruggaan naar GitLab en naar de sectie kijken Bewerkingen > Omgevingen. We zullen vermeldingen zien voor dev и mr-1.

Dit komt omdat we een vermelding hebben toegevoegd environment Met naam name и url in CI/CD-taken. Als we op het pictogram van de open omgeving klikken, worden we naar de URL van de multidev-omgeving op Pantheon geleid.

Automatiseer de creatie van multidev

In principe kunt u hier stoppen en er rekening mee houden dat u voor elk samenvoegverzoek een multidev-omgeving moet maken, maar dit proces kan worden geautomatiseerd.

Pantheon heeft een opdrachtregelprogramma Eindpunt, waar u automatisch met het platform kunt werken. Met Terminus kunt u vanaf de opdrachtregel multidev-omgevingen creëren - ideaal voor GitLab-CI.

Om dit te testen hebben we een nieuw samenvoegverzoek nodig. Laten we een nieuwe branch maken met behulp van git checkout -b auto-multidev-creation.

Om Terminus in GitLab CI/CD-taken te gebruiken, hebt u een machinetoken nodig voor authenticatie bij Terminus en een containerimage bij Terminus.

Een Pantheon-machinetoken maken, sla het op een veilige plaats op en voeg het toe als een globale omgevingsvariabele in GitLab met de naam PANTHEON_MACHINE_TOKEN.

Als je bent vergeten hoe je GitLab-omgevingsvariabelen moet toevoegen, ga dan terug naar waar we hebben gedefinieerd PANTHEON_SITE.

Een Dockerfile maken met Terminus

Als je Docker niet gebruikt of niet van bestanden houdt Dockerfile, neem mijn afbeelding registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest en sla dit gedeelte over.

GitLab heeft een containerregister, waar we de Dockerfile voor ons project kunnen bouwen en plaatsen. Laten we een Dockerfile maken met Terminus om met Pantheon te werken.

Terminus is een PHP-opdrachtregelprogramma, dus laten we beginnen met de PHP-image. Ik installeer Terminus via Composer, dus ik zal het gebruiken officiële Docker Composer-afbeelding. We creëren Dockerfile in de lokale repositorymap met de volgende inhoud:

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

Volg de instructies voor het samenstellen en verzenden van afbeeldingen uit de sectie Bouw en push afbeeldingen в documentatie voor containerregisterom een afbeelding van te verzamelen Dockerfile en push het naar GitLab.

Het openen van de sectie register in het GitLab-project. Als alles volgens plan verliep, zal ons imago er zijn. Schrijf een link naar de afbeeldingstag op. Deze hebben we nodig voor het bestand .gitlab-ci.yml.

Sectie script in het probleem deploy:multidev begint te groeien, dus laten we het naar een apart bestand verplaatsen. Maak een nieuw bestand 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

Het script bevindt zich in een privémap en staat geen webtoegang tot Pantheon toe. We hebben een script voor onze multidev-logica. Laten we nu de sectie bijwerken deploy:multidev het dossier .gitlab-ci.ymlzodat het zo wordt:

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_requests

We moeten ervoor zorgen dat onze taken worden uitgevoerd in de gemaakte aangepaste afbeelding, dus laten we een definitie toevoegen image van register-URL naar .gitlab-ci.yml. Het resultaat was dat we uiteindelijk een bestand als dit kregen .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_requests

Toevoegen, vastleggen en verzenden private/multidev-deploy.sh и .gitlab-ci.yml. Nu keren we terug naar GitLab en wachten tot de CI/CD-taak is voltooid. Wees geduldig: het maken van multidev kan enkele minuten duren.

Dan gaan we kijken naar de multidev-lijst op Pantheon. O wonder! Multidev-omgeving mr-2 al hier.

Conclusie

Mijn team had veel meer plezier toen we samenvoegverzoeken begonnen te openen en automatisch omgevingen gingen maken.

Met de krachtige tools van GitLab en Pantheon kunt u GitLab automatisch aan Pantheon koppelen.

Omdat we GitLab CI/CD gebruiken, heeft onze workflow ruimte om te groeien. Hier zijn een paar ideeën om u op weg te helpen:

Voeg een bouwstap toe.
Voeg geautomatiseerd testen toe.
Voeg een taak toe om ervoor te zorgen dat aan de codestandaarden wordt voldaan.
Toevoegen dynamische testen van applicatiebeveiliging.

Laat ons weten wat u vindt van GitLab, Pantheon en automatisering.

PS Wist je dat Terminus, het opdrachtregelprogramma van Pantheon, kan worden uitgebreid via plug-ins?

Wij bij Pantheon hebben goed werk verricht met versie 2 van ons plug-in voor Terminus-buildtools met GitLab-ondersteuning. Als u zich geen zorgen wilt maken over de instellingen voor elk project, probeer dan deze plug-in en help ons de v2-bèta te testen. Voor het Terminus-team build:project:create Je hebt alleen een Pantheon-token en een GitLab-token nodig. Ze zal een van de voorbeeldprojecten implementeren met Composer en geautomatiseerd testen, een nieuw project maken in GitLab, een nieuwe Pantheon-site, en deze verbinden met behulp van omgevingsvariabelen en SSH-sleutels.