Source Operations Zauberei für WordPress

Source Operations wurde vor etwa 4 Jahren auf Platform.sh veröffentlicht, war aber auf Kunden mit Enterprise- und Elite-Tarifen beschränkt. Bei Upsun ist der Zugang zu Source Operations für alle Pläne verfügbar.

Wenn Sie mit Source Operations nicht vertraut sind, handelt es sich dabei um eine Funktion, die es Ihnen ermöglicht, Befehle festzulegen, die bei ihrem Aufruf Änderungen an das Repository Ihres Projekts übertragen können. Mit Source Operations können Sie beispielsweise Ihre Abhängigkeiten aktualisieren und sogar ein Composer-Update an einen Cron-Job koppeln, so dass die Aktualisierungen der Abhängigkeiten automatisch in einer bestimmten Umgebung erfolgen.

Aber was ist, wenn Sie keinen Composer verwenden? Was ist, wenn Sie so etwas wie ein traditionelles WordPress-Setup haben?

Vanilla-Verzicht

Wir bezeichnen diesen Fall als Vanilla WordPress; er unterscheidet sich durch seine Inkompatibilitätspunkte von der Art und Weise, wie wir bei Upsun die Dinge normalerweise angehen. WordPress-Entwickler sind es gewohnt, per SFTP auf einen Server zuzugreifen, auf dem WordPress läuft, um Änderungen vorzunehmen oder die CLI zu verwenden, um Updates zu erhalten. Aber die auto_update_core-Funktion von WordPress funktioniert nicht mit den schreibgeschützten Dateisystemen, die Sie auf unseren App-Containern erhalten.

Aus diesem Grund empfehlen wir Ihnen, WP_AUTO_UPDATE_CORE zu deaktivieren und den Entwicklern die Verwendung von Composer zu empfehlen. Wenn Sie die Vanilla-Route wählen müssen, können Sie nur "lokal aktualisieren, übertragen und pushen".

Mit Source Operations ist es jedoch möglich, auf ein beschreibbares Dateisystem zuzugreifen, das in den aktuellen Zweig ausgecheckt ist, und diese Art von Änderungen vorzunehmen. Sollten Sie das tun? Nun, es gibt eine Reihe von Vorbehalten und Randfällen, die wir noch entdecken müssen. Vielleicht ist es am besten, diesen Artikel als eine Art "Schauen Sie sich an, was Source-Operationen tun können" zu betrachten, nach dem wir gemeinsam herausfinden können, was die besten Praktiken für diese Operationen sein sollten, sowie ihre Grenzen.

Einrichten

Für den Anfang folgen wir der Anleitung für die Bereitstellung einer WordPress Vanilla Codebasis auf Upsun. Wenn Sie versuchen, Ihre eigene Vanilla-WordPress-Website zu migrieren, ist diese Anleitung die beste Ressource dafür. Sobald Sie den Leitfaden durchgelesen und Ihre Website eingerichtet haben, melden Sie sich im WordPress-Administrations-Dashboard an. Dort finden Sie in der Seitenleiste den Abschnitt "Updates". Wenn ein Update für ein Plugin, ein Theme oder den WordPress-Kern verfügbar ist, werden Sie auf dieser Registerkarte eine Benachrichtigung sehen. Normalerweise würden wir Ihnen an dieser Stelle raten, die Updates zu ziehen, zu aktualisieren, zu übertragen und in eine neue Umgebung zu pushen, um sie zu testen.

Aber versuchen wir es diesmal mit Source Operations.

CLI und Authentifizierung

Die Durchführung der Aktualisierung erfordert die Verwendung der Upsun-CLI in der Umgebung und somit ein API-Token. Holen Sie sich ein Token von Ihrer "Accounts"-Seite der Verwaltungskonsole und erstellen Sie dann (bei lokal installierter CLI ) eine Umgebungsvariable auf Projektebene mit diesem Token:

$ upsun variable:create -l project --prefix env:--name UPSUN_CLI_TOKEN --value "API_TOKEN" --json N --sensitive y --visible-build y --visible-runtime y

Im nächsten Abschnitt werden wir noch einige Einschränkungen hinzufügen, die verhindern, dass der Vorgang in Ihrer Produktionsumgebung ausgeführt wird, aber durch das projektweite Festlegen der Variable können wir sie zur Build-Zeit sichtbar machen, was die Ebene ist, die wir benötigen, damit sie während eines Quellcodevorgangs sichtbar ist. An diesem Punkt gibt es die erste große Warnung: Wie sicher ist es, ein API-Token auf diese Weise in Ihr Projekt aufzunehmen?

Nun, wenn nur Sie selbst an dem Projekt arbeiten, gibt es hier wirklich kein Problem. In der Praxis kommt dies jedoch nur selten vor, und Ihr persönliches API-Token ist - auch wenn es über die Verwaltungskonsole nicht sichtbar ist - für jeden mit SSH-Zugang zu einer der Umgebungen des Projekts sichtbar. Jemand könnte dieses Token verwenden, wenn es dem Projekteigentümer gehört, und die Website löschen, wenn er so motiviert ist. Das ist nicht gut.

Wir empfehlen im Allgemeinen die Verwendung von API-Tokens, die Maschinenbenutzern¹gehören , einem Upsun-Konto mit eingeschränkten Rechten für das Projekt, dessen einziger Zweck es ist, Automatisierungsaufgaben wie diese auszuführen.

Nachdem Sie das Token als Umgebungsvariable hinzugefügt haben, können Sie die Upsun CLI als Build-Abhängigkeit zu Ihrer .upsun/config.yaml-Dateihinzufügen :

dependencies: php: wp-cli/wp-cli-bundle: "^2.4" psy/psysh: "^0.10.4" platformsh/cli: "*"

In anderen Tutorials haben wir Sie angewiesen, die CLI in Ihren Build-Hooks herunterzuladen, aber es stellt sich heraus, dass das hier nicht wirklich wie erwartet funktioniert. Source-Operationen finden auf Dateisystemen in einem Zustand statt, der kurz vor der Ausführung des Build-Hooks liegt. Die Build-Abhängigkeiten sind also verfügbar, aber wenn die CLI später installiert wird, ist sie es nicht. Wenn Sie die CLI nicht auf diese Weise als Build-Abhängigkeit einbinden möchten, können Sie sie trotzdem während Ihrer Build-Hooks installieren. Sie müssen dann aber auch den gleichen Installationsbefehl innerhalb der Source Operation Definition ausführen.

Die Update-Operation

Fügen Sie in Ihrer .upsun/config.yaml-Datei den folgenden Block hinzu:

source: operations: update-wordpress: command: | ENVIRONMENT=$(git rev-parse --abbrev-ref HEAD) platform tunnel:open -p $PLATFORM_PROJECT -e $ENVIRONMENT -y # Exportiere das Beziehungsobjekt und dann unsere Datenbank-Zugangsdaten in die Umgebung.
        export PLATFORM_RELATIONSHIPS="$(platform tunnel:info --encode)" export DB_NAME=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].path") export DB_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].host") export DB_PORT=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].port") export DB_USER=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].username") export DB_PASSWORD=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].password") export DB_HOST=$DB_HOST:$DB_PORT # WordPress mit der WP CLI aktualisieren.
        wp core --path=$PLATFORM_SOURCE_DIR/wordpress update wp plugin --path=$PLATFORM_SOURCE_DIR/wordpress update-all wp theme update --path=$PLATFORM_SOURCE_DIR/wordpress --all # Stage changes, committing only when updates are available.
        git add . STAGED_UPDATES=$(git diff --cached) if [ ${#STAGED_UPDATES} -gt 0 ]; then git commit -m "Gloriously autoupdated Wordpress." else echo "No WordPress updates found." fi # Close the connection. platform tunnel:close -y

Hinweis: Wenn Sie in der Anleitung "Erste Schritte" MySQL statt MariaDB gewählt oder den Namen Ihres Datenbankdienstes in etwas anderes als mariadb geändert haben, müssen Sie den obigen Code entsprechend dem von Ihnen verwendeten Namen ändern.

Wir haben hier also einen interessanten YAML-Block - nehmen wir ihn mal auseinander. Wenn die Operation ausgeführt wird, werden wir das CLI verwenden, um einen Tunnel zur Umgebung zu öffnen und diesen Tunnel zu verwenden, um das Beziehungs-Array lokal zu imitieren, genau wie in einem lokalen Entwicklungsszenario mit Tethering. Mit unseren Datenbankanmeldeinformationen können wir dann unsere Aktualisierungsbefehle mit der WordPress-CLI ausführen.

Sobald wir das getan haben, führen wir das Update aus. Dann haben wir hier einen kleinen Fangblock, der überprüft, ob nach dem Update Dateiveränderungen im Repository aufgetreten sind. Wir haben nämlich festgestellt, dass ein Aktualisierungsbefehl, der zu keinen verfügbaren Aktualisierungen führt (nichts zum Übertragen, ein bereinigter Arbeitsbaum sollte eine gute Nachricht sein), manchmal dazu führt, dass die Operation hängen bleibt, wenn wir versuchen, eine Übertragung vorzunehmen, wenn er nicht ausgeführt wird. Dieser Block prüft, ob etwas für die Übergabe bereitsteht und beendet sich, wenn alles aktuell ist. Dann schließen wir unseren Tunnel, um hinter uns aufzuräumen.

Nachdem wir die Operation an das Projekt übertragen haben, erstellen wir einen neuenZweig², den wir für das Testen von Updates verwenden können.

$ upsun environment:branch update-wordpress

Sobald dies erfolgreich durchgeführt wurde, können wir die Operation jederzeit in dieserUmgebungausführen:

$ upsun source-operation:run update-wordpress

Sie werden sehen, dass die Operation ausgeführt wird und, falls Aktualisierungen für Plugins, Themes oder den WordPress-Kern verfügbar sind, diese in die Umgebung übertragen werden, damit sie getestet werden können.

Automatische Aktualisierungen

Es ist großartig, dass wir einen neuen Endpunkt für das Projekt erstellt haben, um nach Updates zu suchen und diese auf unsere Vanilla-WordPress-Site anzuwenden. Aber ich werde mich nicht daran erinnern, dies regelmäßig zu tun, und da ich davon ausgehe, dass Sie und ich nicht aus dem gleichen Holz geschnitzt sind, sollten wir dies automatisieren.

Fügen Sie das Folgende zu .upsun/config.yaml hinzu:

crons: auto-update-wordpress: spec: "0 1 * * *" cmd: | if [ "$PLATFORM_BRANCH" = update-wordpress ]; then platform environment:sync code data --no-wait --yes platform source-operation:run update-wordpress --no-wait --yes fi

Jetzt haben wir einen Cron-Job, der jeden Tag um 1 Uhr nachts läuft,Code⁴ und Daten von unserer Produktionsseitesynchronisiert und dann unseren Aktualisierungsvorgang ausführt. Wir haben sogar einige Verzweigungsbeschränkungen eingebaut, damit alle unsere Aktualisierungen am selben Ort stattfinden - nur in unserer speziellen Aktualisierungsumgebung.

Nachdem wir Ihnen nun die Geheimnisse dieses Source-Operations-Tricks gezeigt haben, hoffen wir, dass Sie ihn ausprobieren und uns dann berichten, ob er ein echter Knaller oder nur eine Rauchwolke war.