
Unser Gast, der Entwickler-Tools von Pantheon erstellt, erklärt, wie man WordPress-Deployments mit GitLab CI/CD automatisiert.
In Ich arbeite in der Entwicklerkommunikation und suche ständig nach neuen Möglichkeiten, WordPress- und Drupal-Entwicklern bei der Automatisierung ihrer Workflows zu helfen. Dabei experimentiere ich gerne mit neuen Tools und kombiniere sie für eine effiziente Arbeitsweise.
Ich sehe oft, wie Entwickler mit einem einzigen Staging-Server kämpfen.
Es ist nicht angenehm, auf seine Reihe zu warten, um einen Staging-Server zu benutzen, oder den Kunden einen Link zu schicken mit dem Vermerk: „Hier ansehen, aber hier nicht“.
— eines der großartigen Tools von Pantheon — lösen dieses Problem, da man damit auf Anfrage Umgebungen für Git-Branches erstellen kann. Jede Multidev-Umgebung hat ihre eigene URL und Datenbank, sodass die Entwickler in Ruhe arbeiten, die Qualität prüfen und die Genehmigung erhalten können, ohne sich gegenseitig in die Quere zu kommen.
Aber Pantheon bietet keine Versionskontroll- oder CI/CD-Tools. Die Plattform ist jedoch flexibel und ermöglicht die Integration beliebiger Tools.
Ich habe außerdem bemerkt, dass das Team verschiedene Werkzeuge für die Entwicklung und andere für den Build- und Deployment-Prozess nutzt.
Sie verwenden beispielsweise unterschiedliche Werkzeuge für die Versionskontrolle und CI/CD. Man muss ständig zwischen den Werkzeugen wechseln, um den Code zu bearbeiten und Probleme zu diagnostizieren.
Auf Es gibt ein umfassendes Set an Entwicklungswerkzeugen: für die Versionskontrolle, Ticketverwaltung, Merge-Requests, eine der besten CI/CD-Pipelines, ein Container-Registry und so weiter. Mir sind bisher keine Anwendungen begegnet, die so viele Elemente zur Verwaltung des Entwicklungsprozesses bieten.
Ich liebe Automatisierung, deshalb habe ich gelernt, wie man Pantheon mit GitLab verbindet, damit Commits in den Hauptzweig auf GitLab in der Haupt-Entwicklungsumgebung in Pantheon deployed werden. Außerdem können Merge-Requests auf GitLab Code in Multidev-Umgebungen in Pantheon erstellen und deployen.
In diesem Leitfaden werde ich erklären, wie man die Verbindung zwischen GitLab und Pantheon einrichtet und den Workflow für WordPress und Drupal optimiert.
Man könnte natürlich auch , aber wir werden alles manuell durchführen, um ein besseres Verständnis zu bekommen und in Zukunft dieses Werkzeug nicht nur für das Deployment zu verwenden.
Einführung
Für diesen Beitrag ist es wichtig zu verstehen, dass Pantheon jede Website in drei Elemente unterteilt: Code, Datenbank und Dateien.
Der Code umfasst CMS-Dateien, wie das Core, Plugins und Themes von WordPress. Diese Dateien werden in , das bei Pantheon gehostet wird. Das bedeutet, dass wir den Code aus GitLab in Pantheon mit Git bereitstellen können.
Die Dateien bei Pantheon beziehen sich auf Mediendateien, also Bilder für die Website. Diese werden normalerweise von Nutzern hochgeladen und von Git ignoriert.
, erfahren Sie mehr über oder unter pantheon.io.
Annahmen
Mein Projekt bei Pantheon und GitLab heißt pantheon-gitlab-blog-demo. Der Projektname muss einzigartig sein. Hier werden wir mit einer WordPress-Website arbeiten. Es ist auch möglich, Drupal zu verwenden, aber dann müssen einige Anpassungen vorgenommen werden.
Ich werde verwenden, während Sie auch im arbeiten können, wenn Sie möchten.
Projekt erstellen
Zuerst erstellen wir ein (darauf kommen wir noch zurück).
Jetzt . Danach installieren wir WordPress für das Dashboard der Website.
Wenn Sie das Bedürfnis verspüren, etwas zu ändern, wie zum Beispiel Plugins zu löschen oder hinzuzufügen, warten Sie bitte. Die Website ist noch nicht mit GitLab verbunden, und wir möchten, dass alle Codeänderungen über GitLab erfolgen.
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 ursprünglichen WordPress-Code von der Pantheon-Website nach GitLab übertragen. Dazu klonen wir den Code aus dem Git-Repository der Pantheon-Website lokal und senden ihn anschließend an das GitLab-Repository.
Um es einfacher und sicherer zu machen, und müssen nicht jedes Mal das Passwort eingeben, wenn wir das Pantheon Git-Repository klonen. Zusätzlich fügen wir .
Dafür klonen wir die Pantheon-Website lokal, indem wir den Befehl aus dem Feld "Clone with Git" auf dem Dashboard der Website kopieren.
Wenn Sie Hilfe benötigen, lesen Sie die Dokumentation .
Jetzt ändern wir git remote origin, um auf GitLab anstatt auf Pantheon zu zeigen. Das kann man .
machen. Gehen wir zum GitLab-Projekt und kopieren die URL des Repositories aus dem Dropdown-Menü "Clone" auf der Projektseite. Wir wählen die Option "Clone with SSH", da wir bereits den SSH-Schlüssel eingerichtet haben.
Standardmäßig git remote für die lokale Kopie des Code-Repositories – origin. Das kann man ändern mit git remote set-url origin [URL des GitLab-Repositorys], wobei wir statt der Klammern die tatsächliche URL eingeben.
Zuletzt führen wir aus git push origin master --force, um den WordPress-Code von Pantheon nach GitLab zu übertragen.
Der Parameter –force wird nur einmal benötigt. Danach wird er in den Befehlen
git pushin GitLab nicht mehr vorhanden sein.
Wir richten die Anmeldeinformationen und Variablen ein
Erinnern Sie sich, 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 nachsehen .
Jetzt werden wir die ersten beiden Schritte ausführen: wir erstellen lokal ein neues SSH-Schlüsselpaar mit ssh-keygen und fügen den privaten Schlüssel als Variable im Projekt hinzu.
Dann setzen wir SSH_PRIVATE_KEY als in den Projekteinstellungen.
In den dritten und vierten Schritten 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, dann müssen wir noch etwas hinzufügen.
Nun führen wir den fünften Schritt aus und fügen den öffentlichen Schlüssel hinzu, den wir im ersten Schritt erstellt haben, zu den Diensten, auf die Sie in der Build-Umgebung zugreifen müssen..
In unserem Fall möchten wir von GitLab auf Pantheon zugreifen. Wir folgen den Anweisungen im Pantheon-Dokument zum und führen diesen Schritt aus.
Wir erinnern uns: der private SSH-Schlüssel ist in GitLab, der öffentliche in Pantheon.
Lassen Sie uns noch einige Umgebungsvariablen einstellen. Die erste heißt PANTHEON_SITE. Ihr Wert ist der Name der Pantheon-Website auf Ihrem Machine.
Der Name auf der Maschine wird am Ende des Befehls Clone with Git angegeben. Sie haben die Website bereits lokal geklont, also wird dies der Name des lokalen Repository-Verzeichnisses sein.
Das nächste, was wir tun werden, ist, die Umgebungsvariable PANTHEON_GIT_URLeinzustellen. Dies ist die URL des Git-Repositories für die Pantheon-Website, die wir bereits verwendet haben.
Wir geben nur die SSH-URL des Repositories ein, ohne
git cloneund den Namen der Website auf der Maschine am Ende.
Puh. Das haben wir geschafft, jetzt können wir unsere Datei beenden. .gitlab-ci.yml.
Wir erstellen eine Deployment-Aufgabe.
Was wir zunächst mit GitLab CI tun werden, ähnelt stark dem, was wir zuvor mit Git-Repositories gemacht haben. Aber diesmal fügen wir das Pantheon-Repository als zweiten Remote-Git-Quellen 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. Dadurch wird die Datei .gitlab-ci.yml so aussehen:
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:
- masterVariablen SSH_PRIVATE_KEY, PANTHEON_SITE und PANTHEON_GIT_URL sollten bekannt vorkommen – wir haben diese Umgebungsvariablen bereits eingerichtet. Mit diesen Variablen können wir die Werte in der Datei .gitlab-ci.yml häufig verwenden, und sie müssen nur an einer Stelle aktualisiert werden.
Schließlich fügen wir die Datei hinzu, committen und senden sie .gitlab-ci.yml zu GitLab.
Überprüfen des Deployments
Wenn wir alles richtig gemacht haben, wird die Aufgabe deploy:dev erfolgreich in GitLab CI/CD ausgeführt und sendet den Commit .gitlab-ci.yml an Pantheon. Lassen Sie uns das ansehen.
Übertragen von Merge-Request-Branches nach Pantheon
Hier werden wir meine Lieblingsfunktion von Pantheon verwenden – , bei der zusätzliche Pantheon-Umgebungen für Git-Branches auf Anfrage erstellt werden können.
, so this section can be skipped. However, if you have access, you can significantly enhance performance by configuring automatic creation of multidev environments on Pantheon from GitLab merge requests.
Let’s first create a new Git branch locally using git checkout -b multidev-support. Now, let’s modify something again in .gitlab-ci.yml.
I like to include the merge request number in the Pantheon environment name. For example, the first merge request is mr-1, the second is mr-2 and so on.
The merge request changes, so we need to dynamically determine Pantheon branch names. This is straightforward on GitLab—you just need to use .
We can take $CI_MERGE_REQUEST_IID, to specify the merge request number. Let’s combine all of this with the global environment variables we specified earlier, and add a new task deploy:multidev at the end of the 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_requestsIt will look like our task deploy:dev, nur der Branch wird nach Pantheon gesendet, nicht nach master.
Wir haben die aktualisierte Datei hinzugefügt und bestätigt .gitlab-ci.yml, und jetzt senden wir den neuen Branch zu GitLab mit git push -u origin multidev-support.
Jetzt erstellen wir eine neue Merge-Anfrage aus dem Branch multidev-support, indem wir auf Merge-Anfrage erstellen.
Nach dem Erstellen der Merge-Anfrage sehen wir, wie der CI/CD-Prozess abläuft deploy:multidev.
Sehen Sie - ein neuer Branch wurde an Pantheon gesendet. Wenn wir jedoch zum Abschnitt multidev im Dashboard der Website auf Pantheon wechseln, sehen wir dort keine neue Umgebung.
Werfen wir einen Blick auf den Abschnitt Git Branches.
Letztendlich 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 im Abschnitt Operations > Environments. Wir sehen Einträge für dev und mr-1.
Das liegt daran, dass wir einen Eintrag hinzugefügt haben environment mit dem Namen name und url in den CI/CD-Aufgaben. Wenn wir auf das Symbol der offenen Umgebung klicken, gelangen wir zur URL der multidev-Umgebung auf Pantheon.
Automatisierung der Erstellung von multidev
Im Grunde genommen könnte man hier aufhören und einfach nicht vergessen, für jede Merge-Anfrage eine multidev-Umgebung zu erstellen, aber dieser Prozess kann automatisiert werden.
In Pantheon gibt es ein Kommandozeilen-Tool , mit dem man automatisch mit der Plattform arbeiten kann. In Terminus können Umgebungen für multidev über die Kommandozeile erstellt werden – ideal für .
Wir benötigen einen neuen Merge-Request, um dies zu testen. Lassen Sie uns einen neuen Branch erstellen mit git checkout -b auto-multidev-creation.
Um Terminus in GitLab CI/CD-Aufgaben zu verwenden, wird ein Machine-Token zur Authentifizierung bei Terminus und ein Container-Image mit Terminus benötigt.
, speichern Sie es an einem sicheren Ort und fügen Sie 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 Punkt, an dem wir
PANTHEON_SITE.
erarbeitet haben.
Erstellen Sie ein Dockerfile mit Terminus. DockerfileWenn Sie Docker nicht verwenden oder keine Lust auf Dateien haben, , nehmen Sie mein Image registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest
GitLab hat ein Container-Registry,
, wo wir das Dockerfile für unser Projekt erstellen und bereitstellen können. Lassen Sie uns ein Dockerfile mit Terminus erstellen, um mit Pantheon zu arbeiten. Image2 Dockerfile das offizielle Docker Composer-Image
# 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"im Verzeichnis des lokalen Repositories mit folgendem Inhalt: Befolgen Sie die Anweisungen zum Erstellen und Pushen von Images aus dem Abschnitt in der Container-Registry-Dokumentation, um ein Image aus Dockerfile und senden Sie es an GitLab.
Öffnen wir den Abschnitt Registry im GitLab-Projekt. Wenn alles nach Plan läuft, wird dort unser Image sein. Notieren Sie sich den Link zum Tag des Images – wir benötigen ihn für die Datei .gitlab-ci.yml.
Abschnitt script in der Aufgabe deploy:multidev beginnt zu wachsen, also lassen Sie uns das 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 Skript befindet sich im privaten Verzeichnis und Wir haben ein Skript für unsere multidev-Logik. Lassen Sie uns nun den Abschnitt aktualisieren deploy:multidev Datei .gitlab-ci.yml, sodass 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-Bereitstellungsskript aus
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsWir müssen sicherstellen, dass unsere Aufgaben im erstellten benutzerdefinierten Image ausgeführt werden, also fügen wir die Definition hinzu image mit der URL des Registrierungsservers in .gitlab-ci.yml. Am Ende haben wir eine solche Datei erhalten .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 Deploy-Skript aus
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsWir fügen hinzu, committen und senden. private/multidev-deploy.sh und .gitlab-ci.yml. Jetzt gehen wir zurück zu GitLab und warten, bis der CI/CD-Job abgeschlossen ist. Haben Sie Geduld: Multidev kann einige Minuten zur Erstellung benötigen.
Dann schauen wir uns die Liste der Multidevs auf Pantheon an. Oh Wunder! Die Multidev-Umgebung mr-2 ist bereits hier.
Fazit
Mein Team hat viel mehr Spaß gehabt, als wir begonnen haben, Merge-Requests zu öffnen und Umgebungen automatisch zu erstellen.
Mit den leistungsstarken Tools von GitLab und Pantheon können Sie GitLab automatisch mit Pantheon verbinden.
Da wir GitLab CI/CD verwenden, wird unser Arbeitsablauf in Zukunft viel größer sein. 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 die Einhaltung der Codestandards sicherzustellen.
- Fügen Sie hinzu .
Teilen Sie uns Ihre Meinung zu GitLab, Pantheon und Automatisierung mit.
P.S. Wussten Sie, dass Terminus, das Befehlszeilenwerkzeug von Pantheon, ?
Wir bei Pantheon haben intensiv an Version 2 unseres das GitLab unterstützt. Wenn Sie nicht für jedes Projekt mit der Konfiguration herumexperimentieren 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ötigen Sie lediglich ein Pantheon-Token und ein GitLab-Token. Dieses wird ein Beispielprojekt mit Composer und automatisierten Tests bereitstellen, ein neues Projekt in GitLab, eine neue Pantheon-Website erstellen und sie mithilfe von Umgebungsvariablen und SSH-Schlüsseln verbinden.
Über den Autor
Andrew Taylor entwickelt Entwicklerwerkzeuge in .
Quelle: habr.com
