Es war eine aufregende Zeit, seit wir Upsun gestartet haben, und wie Sie sich vorstellen können, haben wir alle eine Menge experimentiert. Wir testen Frameworks, die wir schon immer einsetzen wollten, und nutzen Upsun als perfekte Ausrede, um ein oder zwei Stunden Zeit zu haben, um sie auszuprobieren.
Wir führen auch eine Menge Migrationen durch. Wir nehmen Websites, die oft auf Platform.sh bereitgestellt werden, und vergleichen ihre Konfiguration, Leistung und Ressourcenflexibilität mit Upsun.
Daher waren wir sehr erfreut, als ein Kollege ein WordPress-Kunstportfolio-Projekt in unseren Slack-Channel brachte, das er mit den folgenden Spezifikationen zu migrieren versuchte:
- Standard-Plan
- Ein einzelner Hauptentwickler
- 20 GB Speicherplatz
- Läuft auf PHP 7.4
- Verwendung von MariaDB 11.2
In diesem Beitrag möchte ich berichten, wie ich ihm geholfen habe, dieses Projekt von Platform.sh auf Upsun zu migrieren. Sie können das Experiment gerne mitverfolgen, beachten Sie nur, dass ich:
- Ich hatte bereits die Upsun CLI installiert
- bereits ein Konto und eine Organisation auf
console.upsun.comerstellt habe
Und das gleiche gilt für Platform.sh. Also, los geht's!
1. Einrichten
Ich habe mit dem ursprünglichen Projekt auf Platform.sh begonnen, auf das wir uns hier mit der Projekt-ID Xplatform-shX beziehen werden. Wir werden es in ein Projekt auf Upsun migrieren, auf das wir uns hier mit der Projekt-ID YYYYupsunYYYY beziehen. Um ein Projekt für die Migration von Platform.sh zu Upsun einzurichten, gehen Sie wie folgt vor:
- Klonen Sie das Platform.sh Projekt-Repository:
platform get Xplatform-shX - Erstellen Sie ein Upsun-Projekt:
upsun project:create - Konfigurieren Sie Upsun als Remote:
upsun project:set-remote YYYYupsunYYYY
2. Konfigurieren für Upsun
Wie Sie vielleicht schon gesehen haben, ist die Konfiguration für Upsun mehr oder weniger die gleiche wie die von Platform.sh. Die einzigen Unterschiede, die Sie in diesem Prozess feststellen werden, beziehen sich entweder auf das Kombinieren von Konfigurationsdateien oder das Entfernen von Attributen, die für die Konfiguration von Ressourcen auf Platform.sh verwendet werden - die neue Ressourcen-API ist der Hauptunterscheidungsfaktor von Upsun.
Um unser ausgewähltes WordPress Platform.sh Projekt für Upsun zu konfigurieren, habe ich die folgenden Schritte durchgeführt:
1. Das Platform.sh-Projekt, das unser Kollege zur Verfügung gestellt hat, enthielt das, was man erwarten würde: .platform.app.yaml, .platform/services.yaml und .platform/routes.yaml Dateien. Wir haben jetzt - von project:set-remote - ein .upsun-Verzeichnis, dem wir eine .upsun/config.yaml-Datei hinzufügen können. In dieser Datei habe ich alle meine Platform.sh-Konfigurationen unter einigen ziemlich intuitiven Schlüsseln zusammengefasst:
# .upsun/config.yaml applications: app: type: "php:7.4" dependencies: php: wp-cli/wp-cli-bundle: "^2.4" psy/psysh: "^0.10.4" Beziehungen: database: "db:mysql" Variablen: php: ... web: locations: "/": ... "/wp-content/cache": ... "/wp-content/uploads": ... disk: 19400 mounts: "public_html/wp-content/cache": source: local source_path: "cache" "public_html/wp-content/uploads": source: local source_path: "uploads" hooks: deploy: | ... services: db: type: mariadb:11.2 disk: 512 routes: "https://{default}/": type: upstream upstream: "app:http" cache: enabled: true cookies: ... "https://www.{default}/": type: redirect to: "https://{default}/" Alles befindet sich jetzt in einer einzigen Datei. Dienste sind unter Dienste, Routen unter Routen und die einzelne Anwendung(app) ist unter Anwendungen (jetzt unter dem Schlüssel app, anstatt das Attribut name von Platform.sh zu verwenden).
2. Bei Upsun werden, wie bereits erwähnt, die Ressourcen über die API und nicht über YAML konfiguriert. Aus diesem Grund müssen wir die Festplattendefinitionen sowohl für die Anwendung(app) als auch für den MariaDB-Dienst db entfernen.
3. Und schließlich sind die _Typen_ der Mounts in Platform.sh nicht ganz die gleichen wie die Optionen in Upsun. Das heißt, wir müssen unsere beiden Mounts aktualisieren, um den Typ storage statt local für das Quellattribut zu verwenden. Der Grund dafür liegt in der Namensgebung - Mounts auf Upsun sind nicht auf die gleiche Weise lokal. Jeder Anwendungscontainer kann auf mehrere Instanzen skaliert werden, wobei die Daten in dem, was vorher ein lokales Mount war, zwischen ihnen geteilt werden müssen. storage ist nur ein besserer Name für dieses Verhalten, und für eine einzelne Instanz ist das Verhalten identisch zu Platform.sh. Für die Neugierigen unter Ihnen: Hinter den Kulissen ist dieser Mount-Typ eigentlich ein Netzwerkspeicherdienst.
Alle diese Änderungen führen zu einer endgültigen Konfigurationsdatei, wie dieser:
# .upsun/config.yaml applications: app: type: "php:7.4" dependencies: php: wp-cli/wp-cli-bundle: "^2.4" psy/psysh: "^0.10.4" Beziehungen: database: "db:mysql" Variablen: php: ... web: locations: "/": ... "/wp-content/cache": ... "/wp-content/uploads": ... mounts: "public_html/wp-content/cache": source: storage source_path: "cache" "public_html/wp-content/uploads": Quelle: storage source_path: "uploads" hooks: deploy: | ... services: db: type: mariadb:11.2 routes: "https://{default}/": type: upstream upstream: "app:http" cache: enabled: true cookies: ... "https://www.{default}/": type: redirect to: "https://{default}/" 3. Daten: Fertigstellung der Migration
Mit unserer Konfiguration können wir das Projekt mit einem Upsun-Push testen.
Wenn Sie die Migration Ihres eigenen WordPress-Projekts zu Upsun verfolgen, werden Sie kurz vor dem Ausführen des Deploy-Hooks etwas wie das folgende sehen:
Konfigurieren der Ressourcen Verwenden der Standardgrößen Einstellen der 'app' Profilgröße auf '0.5'. Einstellen der 'app' Festplatte auf '512MB'. Einstellen der 'db' Profilgröße auf '0.5'. Einstellen der 'db' Festplatte auf '512MB'.
Erstellen der Umgebung main Starten der Umgebung Öffnen der Anwendung app und ihrer Beziehungen Ausführen des Deploy-Hooks für die Anwendung app ... Öffnen der Umgebung Umgebungskonfiguration app (Typ: php:7.4, cpu: 0.5, Speicher: 224, Festplatte: 512) mariadb (Typ: mariadb:10.11, cpu: 0.5, Speicher: 1408, Festplatte: 512)Während die Ressourcen-API Ihnen die Flexibilität bietet, die für Ihre Container und Umgebungen verfügbaren Ressourcen zu ändern, wird Upsun beim ersten Push automatisch einige vernünftige Standardwerte setzen.
Hier gibt es eigentlich nichts zu tun, es ist nur nett, darauf hinzuweisen, denke ich.
Wenn die Aktivität abgeschlossen ist, haben wir den WordPress-Installationsbildschirm, d. h. unseren gesamten Code, aber keine unserer Daten. Lassen Sie uns also diese Daten migrieren, indem wir mit dem Folgenden beginnen:
- Rufen Sie die Platform.sh-Datenbank ab:
platform db:dump - Abrufen der Dateien:
platform mount:download
Und da es sich bei diesem speziellen Migrationsprojekt um eine Kunstportfolio-Website mit fast 15 GB Kunst in Mounts handelte, nahm ich mir eine Episode von Ted Lasso vor, während der Download abgeschlossen wurde. Als er beendet war, befanden sich alle hochgeladenen Dateien in den Ressourcen unseres neuen Upsun-Projekts. Sie können diese Ressourcen mit dem CLI-Befehl upsun resources:set aktualisieren. Hier habe ich alles so belassen, wie es vorher war, nur die Festplatte, die der Anwendung zugewiesen wurde, auf 20048 MB aufgestockt.
Dann das Gleiche wie zuvor in umgekehrter Reihenfolge, um die Daten hochzuladen:
upsun sql < ZZZZ...ZZZZ--dump.sqlupsun mount:upload- Eine weitere Folge von Ted Lasso für den Upload
4. Erfolgreich!
Und einfach so wurde unser Projekt - abgesehen vom Hinzufügen unserer Domain -von Platform.sh zu Upsun migriert.
Jetzt, wo wir fertig sind, können wir:
- unsere Infrastrukturmetriken beobachten, um festzustellen, ob wir zu viele Ressourcen für das Projekt zugewiesen haben
- diese Informationen nutzen, um unsere Ressourcen anzupassen
- einen Zweig erstellen und auf eine aktuellere Version von PHP und MariaDB aktualisieren
Viel Erfolg bei Ihren eigenen Migrationen! Treten Sie unserer Community bei und lassen Sie uns wissen, wie es Ihnen geht.
Nützliche Links
Ihr größtes Werk
steht vor der Tür
