
Unser Gast, der Entwickler-Tools von Pantheon erstellt, erklärt, wie man WordPress-Deployments mit GitLab CI/CD automatisiert.
Im Ich beschäftige mich mit Entwicklerbeziehungen, daher suche ich immer nach neuen Möglichkeiten, um WordPress- und Drupal-Entwicklern bei der Automatisierung ihrer Arbeitsabläufe zu helfen. Dabei experimentiere ich gerne mit neuen Werkzeugen und kombiniere sie für eine effiziente Arbeit.
Ich sehe oft, wie Entwickler mit einem Staging-Server kämpfen.
Es ist nicht gerade angenehm, darauf zu warten, dass man an der Reihe ist, einen Staging-Server zu benutzen, oder den Kunden URLs zu schicken mit dem Hinweis: "Hier anschauen, und dort noch nicht."
– eines der coolen Tools von Pantheon – lösen dieses Problem, da man damit auf Anfrage Umgebungen für Git-Zweige erstellen kann. Jede Multidev-Umgebung hat ihre eigene URL und Datenbank, sodass Entwickler problemlos arbeiten, die Qualität überprüfen und Feedback erhalten können, ohne sich gegenseitig in die Quere zu kommen.
Aber bei Pantheon gibt es keine Werkzeuge zur Versionskontrolle oder kontinuierlichen Integration und Bereitstellung (CI/CD). Dennoch ist es eine flexible Plattform, die sich mit beliebigen Tools integrieren lässt.
Ich habe außerdem bemerkt, dass Teams für die Entwicklung andere Werkzeuge verwenden als für den Build und die Bereitstellung.
Zum Beispiel nutzen sie unterschiedliche Werkzeuge für die Versionskontrolle und CI/CD. Man muss hin und her wechseln zwischen den Werkzeugen, um Code zu bearbeiten und Probleme zu diagnostizieren.
Auf Sie haben ein umfassendes Set an Entwicklungswerkzeugen: für die Versionskontrolle, Tickets, Merge-Requests, eine erstklassige CI/CD-Pipeline, einen Container-Registry und all solche Dinge. Mir sind bisher keine Anwendungen begegnet, die so viele Ressourcen für das Management des Entwicklungsprozesses bieten.
Ich liebe Automatisierung, deshalb habe ich herausgefunden, wie man Pantheon mit GitLab verbindet, sodass Commits in den Hauptzweig bei GitLab in die Hauptentwicklungsumgebung bei Pantheon bereitgestellt werden. Außerdem können Merge-Requests bei GitLab den Code in die Multidev-Umgebungen bei Pantheon erstellen und bereitstellen.
In diesem Leitfaden werde ich erklären, wie man die Verbindung zwischen GitLab und Pantheon einrichtet und den Arbeitsablauf von WordPress und Drupal optimiert.
Man kann natürlich , aber wir werden alles manuell machen, um uns damit auseinanderzusetzen. und in Zukunft dieses Tool nicht nur für das Deployment verwenden.
Einführung
Für diesen Beitrag muss man verstehen, dass Pantheon jede Website in drei Elemente unterteilt: Code, Datenbank und Dateien.
Zu den Codes gehören die CMS-Dateien, wie das Kernsystem, Plugins und WordPress-Themes. Diese Dateien werden in , das bei Pantheon gehostet wird, verwaltet, was bedeutet, dass wir den Code von GitLab in Pantheon mit Git deployen können.
Dateien in Pantheon sind Mediendateien, das heißt Bilder für die Website. Normalerweise werden sie von Benutzern hochgeladen, und Git ignoriert sie.
, erfahren Sie mehr über oder auf pantheon.io.
Annahmen
Mein Projekt auf Pantheon und GitLab heißt pantheon-gitlab-blog-demo. Der Projektname muss einzigartig sein. Hier werden wir mit einer WordPress-Website arbeiten. Man könnte auch Drupal verwenden, aber es müssten einige Änderungen vorgenommen werden.
Ich werde die verwenden, aber Sie können auch im arbeiten, wenn Sie möchten.
Projekt erstellen
Zuerst erstellen wir (darauf werden wir später zurückkommen).
Jetzt . Danach installieren wir WordPress für das Dashboard der Webseite.
Wenn Sie in den Fingern kribbeln, etwas zu ändern, wie Plugins zu entfernen und hinzuzufügen, warten Sie bitte. Die Website ist noch nicht mit GitLab verbunden, und wir möchten, dass alle Codeänderungen über GitLab laufen.
Sobald wir WordPress installiert haben, kehren wir zum Dashboard der Pantheon-Website zurück und ändern den Entwicklungsmodus auf Git.
Erster Commit auf GitLab
Jetzt müssen wir den anfänglichen WordPress-Code von der Pantheon-Website auf GitLab übertragen. Dazu klonen wir den Code aus dem Git-Repository der Pantheon-Website lokal und senden ihn dann an das GitLab-Repository.
Um es einfacher und sicherer zu machen, und müssen nicht jedes Mal ein Passwort eingeben, wenn wir das Pantheon Git-Repository klonen. Außerdem .
Dazu klonen wir die Pantheon-Website lokal, indem wir den Befehl aus dem Feld Clone with Git im Dashboard der Website kopieren.
Wenn Sie Hilfe benötigen, lesen Sie die Dokumentation .
Jetzt ändern wir git remote origin, um auf GitLab anstelle von Pantheon zu verweisen. Das kann man tun .
Wir gehen zum GitLab-Projekt und kopieren die Repository-URL aus dem Dropdown-Menü Clone auf der Projektseite. Wir wählen die Option Clone with SSH, da wir den SSH-Schlüssel bereits eingerichtet haben.
Standardmäßig git remote für die lokale Kopie des Code-Repositories ist originDas kann man ändern mit git remote set-url origin [URL des GitLab-Repositorys], wobei wir anstelle der Klammern die tatsächliche URL eingeben.
Endlich starten wir git push origin master --force, um den WordPress-Code von der Pantheon-Website nach GitLab zu senden.
Der Parameter –force ist nur einmal erforderlich. Danach wird er in den Befehlen
git pushauf GitLab nicht mehr benötigt.
Wir konfigurieren die Zugangsdaten und Variablen
Erinnert ihr euch, wie wir lokal den SSH-Schlüssel hinzugefügt haben, um uns bei Pantheon und GitLab zu authentifizieren? Das SSH-Token kann zur Authentifizierung bei GitLab und Pantheon verwendet werden.
GitLab hat eine hervorragende Dokumentation. Lassen Sie uns den .
jetzt die ersten beiden Schritte ausführen: unser neues SSH-Schlüsselpaar lokal mit ssh-keygen erstellen und den privaten Schlüssel als Variable im Projekt hinzufügen..
Dann legen wir SSH_PRIVATE_KEY als in den Projekteinstellungen.
In Schritt drei und vier erstellen wir die Datei .gitlab-ci.yml mit folgendem Inhalt:
before_script:
# Siehe 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"Lassen Sie uns die Datei vorerst nicht committen .gitlab-ci.yml, später müssen wir noch etwas hinzufügen.
Jetzt führen wir Schritt fünf aus und fügen den öffentlichen Schlüssel hinzu, den wir im ersten Schritt erstellt haben, zu den Services, für die Sie im Build-Umfeld Zugriff benötigen..
In unserem Fall möchten wir von GitLab auf Pantheon zugreifen. Befolgen Sie die Anweisungen im Pantheon-Dokument zum und führen Sie diesen Schritt aus.
Denken Sie daran: Der private SSH-Schlüssel ist in GitLab, der öffentliche in Pantheon.
Lassen Sie uns noch ein paar Umgebungsvariablen einrichten. Die erste heißt PANTHEON_SITE. Ihr Wert ist der Name der Pantheon-Website auf Ihrem Computer.
Der Name auf Ihrem Computer wird am Ende des Befehls "Clone with Git" angegeben. Sie haben die Website bereits lokal geklont, also ist das der Name des lokalen Repository-Verzeichnisses.
Dann konfigurieren wir die Umgebungsvariable PANTHEON_GIT_URL. Das ist die URL des Git-Repositories für die Pantheon-Website, die wir bereits verwendet haben.
Geben Sie nur die SSH-Repository-URL ein, ohne
git cloneund den Namen der Website auf Ihrem Computer am Ende.
Puh. Das haben wir geschafft, jetzt können wir unsere Datei abschließen. .gitlab-ci.yml.
Wir erstellen die Deploy-Aufgabe
Das, was wir anfangs mit GitLab CI tun werden, ähnelt sehr dem, was wir zuvor mit Git-Repositories gemacht haben. Aber dieses Mal fügen wir das Pantheon-Repository als zweiten Remote-Git-Quell-Repository hinzu und senden dann den Code von GitLab nach Pantheon.
Dazu konfigurieren wir deploy und deploy:dev, denn wir werden in die Entwicklungsumgebung auf Pantheon deployen. Infolgedessen wird die Datei so aussehen: .gitlab-ci.yml so aussehen wird:
Stufen:
- Bereitstellung
Vor-Skript:
# Siehe 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"
bereitstellung:dev:
stufe: bereitstellung
umgebung:
name: dev
url: https://dev-$PANTHEON_SITE.pantheonsite.io/
skript:
- git remote add pantheon $PANTHEON_GIT_URL
- git push pantheon master --force
nur:
- masterVariablen SSH_PRIVATE_KEY, PANTHEON_SITE und PANTHEON_GIT_URL sollten vertraut aussehen - wir haben diese Umgebungsvariablen bereits früher konfiguriert. Mit diesen Variablen können wir die Werte in der Datei .gitlab-ci.yml mehrmals verwenden, und wir müssen sie nur an einem Ort aktualisieren.
Schließlich fügen wir die Datei hinzu, committen sie und senden sie .gitlab-ci.yml an GitLab.
Wir überprüfen die Bereitstellung
Wenn wir alles richtig gemacht haben, wird der Job deploy:dev erfolgreich in GitLab CI/CD ausgeführt und sendet den Commit .gitlab-ci.yml an Pantheon. Lassen Sie uns das ansehen.
Wir senden Merge-Request-Branches an Pantheon
Hier werden wir meine Lieblingsfunktion von Pantheon verwenden - , wo man zusätzliche Pantheon-Umgebungen für Git-Branches auf Anfrage erstellen kann.
, sodass dieser Abschnitt möglicherweise nicht ausgeführt werden muss. Aber wenn Sie Zugriff haben, können Sie die Effizienz erheblich steigern, indem Sie die automatische Erstellung von multidev-Umgebungen auf Pantheon aus GitLab-Merge-Requests konfigurieren.
Zuerst erstellen wir lokal einen neuen Git-Branch mit git checkout -b multidev-support. Jetzt ändern wir wieder etwas in .gitlab-ci.yml.
Ich gebe gerne die Merge-Request-Nummer im Namen der Pantheon-Umgebung an. Zum Beispiel, der erste Merge-Request - mr-1, der zweite - mr-2 usw.
Der Merge-Request ändert sich, sodass wir die Namen der Pantheon-Branches dynamisch bestimmen müssen. Bei GitLab ist das einfach - wir müssen .
Wir können $CI_MERGE_REQUEST_IIDverwenden, um die Merge-Request-Nummer anzugeben. Lassen Sie uns das alles zusammen mit den globalen Umgebungsvariablen, die wir zuvor angegeben haben, anwenden und eine neue Aufgabe deploy:multidev am Ende der Datei hinzufügen. .gitlab-ci.yml.
deploy:multidev:
stufe: bereitstellung
umgebung:
name: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
skript:
# Checkout des Quell-Branches des Merge-Requests
- git checkout $CI_COMMIT_REF_NAME
# Fügen Sie das Pantheon-Git-Repository als zusätzliches Remote hinzu
- git remote add pantheon $PANTHEON_GIT_URL
# Pushen Sie den Quell-Branch des Merge-Requests nach Pantheon
- git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
nur:
- merge_requestsEs wird ähnlich wie unsere Aufgabe aussehen deploy:dev, nur wird der Branch an Pantheon und nicht nach master.
Wir haben die aktualisierte Datei hinzugefügt und committet .gitlab-ci.yml, und jetzt senden wir den neuen Branch an GitLab mit git push -u origin multidev-support.
Lass uns jetzt einen neuen Merge-Request aus dem Branch erstellen multidev-support, indem wir auf Merge-Request erstellen.
Nachdem wir den Merge-Request erstellt haben, sehen wir, wie die CI/CD-Aufgabe ausgeführt wird deploy:multidev.
Sieh mal – ein neuer Branch wurde an Pantheon gesendet. Aber wenn wir zum Bereich Multidev im Dashboard der Website auf Pantheon gehen, sehen wir dort keine neue Umgebung.
Schauen wir uns den Abschnitt Git Branches an.
Irgendwann hat unser Branch mr-1 Pantheon erreicht. Lassen Sie uns eine Umgebung aus dem Branch erstellen. mr-1.
Wir haben die Multidev-Umgebung erstellt, und jetzt kehren wir zu GitLab zurück und schauen uns den Bereich Operations > Umgebungenan. Wir werden Einträge für sehen. dev und mr-1.
Das liegt daran, dass wir einen Eintrag hinzugefügt haben Umgebung mit dem Namen name und url in die CI/CD-Aufgaben. Wenn wir auf das Symbol der offenen Umgebung klicken, gelangen wir zur URL der Multidev-Umgebung auf Pantheon.
Automatisieren wir die Erstellung von Multidev
Eigentlich könnte man hier aufhören und einfach nicht vergessen, eine Multidev-Umgebung für jeden Merge-Request zu erstellen, aber diesen Prozess kann man automatisieren.
In Pantheon gibt es ein Befehlszeilen-Tool , mit dem man automatisch auf der Plattform arbeiten kann. Mit Terminus kann man Multidev-Umgebungen aus der Befehlszeile erstellen – ideal für .
Wir brauchen einen neuen Merge-Request, um dies zu testen. Lassen Sie uns einen neuen Branch mit git checkout -b auto-multidev-creation.
erstellen. Um Terminus in GitLab CI/CD-Aufgaben zu verwenden, benötigen wir ein Maschinen-Token zur Authentifizierung in Terminus und ein Container-Image mit Terminus.
, bewahren wir es an einem sicheren Ort auf und fügen es als globale Umgebungsvariable in GitLab mit dem Namen hinzu PANTHEON_MACHINE_TOKEN.
Wenn Sie vergessen haben, wie man Umgebungsvariablen in GitLab hinzufügt, gehen Sie zurück zu dem Ort, wo wir definiert haben
PANTHEON_SITE.
Erstellen wir eine Dockerfile mit Terminus
Wenn Sie Docker nicht verwenden oder die Dateien nicht mögen Dockerfile, nehmen Sie mein Image registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest und überspringen Sie diesen Abschnitt.
, wo Sie die Dockerfile für unser Projekt erstellen und ablegen können. Lassen Sie uns eine Dockerfile mit Terminus erstellen, um mit Pantheon zu arbeiten.
Terminus ist ein Befehlszeilen-Tool in PHP, also fangen wir mit einem PHP-Image an. Ich installiere Terminus über Composer, daher verwende ich als Basis das offizielle Docker Composer-Image Dockerfile im Verzeichnis des lokalen Repositories mit folgendem Inhalt:
# 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"Befolgen Sie die Anweisungen zum Erstellen und Hochladen von Bildern im Abschnitt Bilder erstellen und hochladen in , um ein Image aus Dockerfile zu erstellen und es nach GitLab zu senden.
Öffnen Sie den Bereich Registry im GitLab-Projekt. Wenn alles nach Plan gelaufen ist, wird dort unser Image sein. Notieren Sie den Link zum Image-Tag – er wird für die Datei benötigt. .gitlab-ci.yml.
Abschnitt script in der Aufgabe deploy:multidev wächst, also lassen Sie uns dieses in eine separate Datei verschieben. Wir erstellen eine neue Datei 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..."
fiDas Script befindet sich im privaten Verzeichnis und . Wir haben ein Script für unsere multidev-Logik. Lassen Sie uns nun den Abschnitt deploy:multidev der Datei .gitlab-ci.yml, damit es so aussieht:
deploy:multidev:
stage: deploy
environment:
name: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Führen Sie das multidev-Bereitstellungsscript aus
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsWir müssen sicherstellen, dass unsere Aufgaben im erstellten benutzerdefinierten Image ausgeführt werden. Fügen wir eine Definition hinzu Image mit der URL des Registrys in .gitlab-ci.yml. Am Ende haben wir eine Datei wie diese .gitlab-ci.yml:
image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest
stages:
- deploy
before_script:
# Siehe 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:
# Führen Sie das multidev-Bereitstellungsscript aus
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsWir fügen hinzu, committen und senden private/multidev-deploy.sh. und .gitlab-ci.ymlJetzt kehren wir zu GitLab zurück und warten, bis der CI/CD-Job abgeschlossen ist. Geduld: multidev kann einige Minuten in Anspruch nehmen.
Dann schauen wir uns die Liste der multidevs auf Pantheon an. Oh Wunder! Die multidev-Umgebung mr-2 ist schon hier.
Fazit
Mein Team hat viel mehr Spaß gehabt, als wir begannen, Merge-Requests zu öffnen und Umgebungen automatisch zu erstellen.
Mit den leistungsstarken Tools von GitLab und Pantheon können wir GitLab automatisch mit Pantheon verbinden.
Da wir GitLab CI/CD verwenden, wird unser Workflow viel Raum für Wachstum haben. Hier sind ein paar Ideen, um loszulegen:
- Fügen Sie einen Build-Schritt hinzu.
- Fügen Sie automatisierte Tests hinzu.
- Fügen Sie eine Aufgabe hinzu, um sicherzustellen, dass die Codestandards eingehalten werden.
- Fügen Sie .
Teilen Sie uns mit, was Sie über GitLab, Pantheon und Automatisierung denken.
P.S. Wussten Sie, dass Terminus, das Kommandozeilen-Tool von Pantheon, ?
Wir bei Pantheon haben hart an Version 2 gearbeitet. mit Unterstützung für GitLab. Wenn Sie sich nicht mit der Einrichtung für jedes Projekt beschäftigen möchten, probieren Sie dieses Plugin aus und helfen Sie uns, die Beta v2 zu testen. Für das Terminus-Team build:project:create benötigt nur ein Pantheon-Token und ein GitLab-Token. Es wird eines der Projektbeispiele mit Composer und automatisierten Tests bereitstellen, ein neues Projekt in GitLab, eine neue Pantheon-Website erstellen und sie über Umgebungsvariablen und SSH-Schlüssel miteinander verbinden.
Über den Autor
Andrew Taylor erstellt Entwickler-Tools in .
Quelle: habr.com
