Server aus Laravel Forge oder Ploi importieren

Der Import holt Server, die du mit Laravel Forge oder Ploi verwaltest, zu Vimonto Deploy, mit ihren Sites, Prozessen, Cronjobs, Datenbanken und Firewall-Regeln. Jeder Server wird an Ort und Stelle übernommen: Nichts wird neu installiert, deine Domains zeigen weiter auf dieselben Maschinen, und die Sites laufen weiter, während sie umziehen.

Du gibst Vimonto Deploy ein API-Token der Plattform, wählst die Server aus, und jeder Server wird in einer eigenen Aufgabe übernommen. Danach verwaltest du den Server in Vimonto Deploy wie jeden anderen und archivierst ihn in Forge oder Ploi.

Bevor du anfängst#

• Berechtigung. Zum Importieren brauchst du das Recht, Server anzulegen: die Rolle Owner, Administrator oder Manager.
• Platz in deinem Tarif. Jeder importierte Server und jede Site darauf zählt für deinen Tarif. Die Seite prüft vor dem Start, ob die gewählten Server und Sites hineinpassen, und jeder Server prüft es erneut, wenn seine Aufgabe läuft. Im kostenlosen Tarif (1 Server und 3 Sites) ist das ein Server mit höchstens drei Sites; für mehr wechselst du vorher den Tarif.
• Ein API-Token der Plattform, mit den unten beschriebenen Rechten.
• Dein SSH-Schlüssel (empfohlen). Füge deinen öffentlichen Schlüssel unter Account → SSH-Schlüssel hinzu, damit du dich weiterhin selbst anmelden kannst; siehe SSH-Schlüssel.

Das API-Token erstellen#

Die Seite verlinkt die richtige Stelle für die gewählte Plattform:

• Laravel Forge: Erstelle ein Token unter forge.laravel.com/profile/api. Vimonto Deploy nutzt die Organisations-API von Forge und listet die Server jeder Forge-Organisation, die das Token sehen kann. Das Token muss Server und Sites lesen dürfen (auch die Umgebungsdatei und das Deploy-Skript), Recipes anlegen und ausführen und Push-to-Deploy ausschalten dürfen.
• Ploi: Erstelle einen API-Schlüssel unter ploi.io/profile/api-keys. Er muss Server und Sites lesen dürfen (auch die Umgebungsdatei und das Deploy-Skript), Skripte anlegen und ausführen und Quick Deploy ausschalten dürfen.

Das Token wird nur genutzt, um deine Server zu lesen und ein Skript auszuführen, das Vimonto Deploy Zugriff gibt. Es wird verschlüsselt gespeichert und gelöscht, sobald jeder Server dieses Kontos importiert ist (oder schon in deiner Organisation steht). Anderes Konto verwenden löscht es ebenfalls.

Lehnt die Plattform das Token ab, sagt die Seite das unter dem Feld: … hat das API-Token abgelehnt, Dem …-Token fehlt eine benötigte Berechtigung oder … begrenzt die Anfragen; versuch es in einer Minute noch einmal.

Server Schritt für Schritt importieren#

1. Geh zu Server, öffne den Pfeil neben Neuer Server und wähle Aus Forge oder Ploi importieren. Die Seite Server importieren öffnet sich.
2. Wähle unter Wo sind deine Server jetzt? Laravel Forge oder Ploi.
3. Füge das Token unter API-Token ein und klicke auf Meine Server lesen. Auf deinen Servern ändert sich noch nichts: Vimonto Deploy liest nur das Konto.
4. Der Bereich Server in Laravel Forge (oder Server in Ploi) listet jeden Server mit IP-Adresse, PHP-Version, Datenbank, Ubuntu-Version und den Domains seiner Sites. Server, deren IP-Adresse schon in deiner Organisation steht, zeigen Bereits hier und können nicht gewählt werden; die anderen zeigen Bereit zum Import und sind alle angehakt. Entferne den Haken bei denen, die bleiben sollen.
5. Lies den Hinweis neben dem Button und klicke auf den Import-Button (zum Beispiel 2 Server importieren).

Jeder Server wird eine eigene Aufgabe, … aus … importieren. Sein Status wechselt zu In der Warteschlange, dann Wird importiert, dann Importiert oder Fehlgeschlagen. Unter jedem Server zeigt die Seite den aktuellen Schritt und nach und nach einen Bericht darüber, was erledigt wurde und was deine Aufmerksamkeit braucht. Du kannst die Seite schließen: Die Aufgaben laufen weiter, du bekommst eine Meldung im geöffneten Tab, sobald eine endet, und sie stehen mit ihrer vollständigen Ausgabe auf der Seite Aktivität.

Was passiert mit jedem Server?#

Die Aufgabe hat sechs Schritte.

1. Server und Sites lesen#

Vimonto Deploy liest alles, was die Plattform über den Server weiß: seine Sites, Hintergrundprozesse und Queue-Worker, Cronjobs, Datenbanken, Datenbankbenutzer und Firewall-Regeln. Was die Plattform sendet und nicht sicher verwendet werden kann (zum Beispiel eine ungültige Domain, ein ungültiges Verzeichnis oder ein ungültiger Benutzername), bleibt zurück, und der Bericht sagt … wurde nicht importiert: Die Plattform hat Einstellungen gesendet, die nicht sicher verwendet werden können.

2. Server hier hinzufügen#

Der Server kommt als App-Server in deine Organisation, mit Name, öffentlicher und privater IP-Adresse, PHP-Version, Datenbank und Ubuntu-Version. Er bekommt ein eigenes SSH-Schlüsselpaar, wie jeder Server in Vimonto Deploy. Er ist mit keinem Cloud-Konto verbunden: Du verwaltest ihn wie einen eigenen VPS.

3. Zugriff auf den Server erhalten#

Über die Plattform führt Vimonto Deploy ein Skript als root auf diesem Server aus: ein Recipe in Forge, ein Skript in Ploi. Das Skript trägt den neuen öffentlichen Schlüssel des Servers in /root/.ssh/authorized_keys ein. Stand SSH auf PermitRootLogin no, wird daraus prohibit-password, damit root sich mit einem Schlüssel anmelden kann, nie mit einem Passwort. Dann wartet Vimonto Deploy bis zu 5 Minuten, bis SSH es hereinlässt.

Anschließend schaut es sich die Maschine selbst an: die Ubuntu-Version, die installierten PHP-Versionen, die Supervisor-Programme und pro Site, ob das Verzeichnis existiert, ob es eine Laravel-App ist und ob sie an Ort und Stelle oder aus Releases läuft. Die gefundenen PHP-Versionen erscheinen auf der Seite PHP des Servers, und SSH, HTTP und HTTPS als die Standard-Firewall-Regeln des Servers.

4. Prozesse und Cronjobs übernehmen#

• Datenbanken und Firewall-Regeln werden erfasst, wie sie sind: die Datenbanken, die Datenbankbenutzer und welche Datenbanken sie nutzen dürfen, und die Firewall-Regeln neben SSH, HTTP und HTTPS. Auf dem Server ändert sich daran nichts.
• Supervisor-Programme: Jedes Programm, das nicht von Vimonto Deploy ist, wird von /etc/supervisor/conf.d nach /root/vimonto-takeover-backup/supervisor verschoben, und Vimonto Deploy schreibt seine eigenen Prozesse aus dem, was die Plattform gemeldet hat. Der Bericht nennt die verschobenen Programme.
• Cronjobs: Eine Kopie der Crontab des Systembenutzers und von root kommt nach /root/vimonto-takeover-backup/cron, und die Zeilen, die einen Cronjob der Plattform ausführen, werden entfernt; der Rest jeder Crontab bleibt. Dasselbe passiert in /etc/crontab (vorher kopiert), und Dateien in /etc/cron.d, die einen Job der Plattform ausführen, kommen in den Backup-Ordner. Vimonto Deploy schreibt die Jobs neu als geplante Jobs.

Queue-Worker einer Site und Cronjobs, die schedule:run einer Site ausführen, werden hier nicht angelegt: Sie ziehen im nächsten Schritt mit ihrer Site um.

5. Sites übernehmen#

Die Sites ziehen eine nach der anderen um. Eine Site, die nicht umziehen kann, hält die anderen nicht auf: Der Bericht sagt … wurde nicht übernommen: mit dem Grund, zum Beispiel wenn ihr Verzeichnis nicht auf dem Server liegt.

Für jede Site:

1. Die Site wird angelegt mit Domain und Aliassen, Verzeichnis, Web-Verzeichnis, PHP-Version, Repository und Branch sowie ihrem Framework (Laravel, Statamic, WordPress, Symfony, statisches HTML, Nuxt, Next.js oder einfaches PHP). Eine Site, die als eigener Linux-Benutzer lief, bleibt unter diesem Benutzer isoliert. Die .env wird bei der Plattform gelesen. Es kommt kein neuer Deploy-Key hinzu: Der Server behält den Git-Zugriff, den die Plattform eingerichtet hat.
2. Das Deploy-Skript wird übersetzt: Zeilen, die per cd in die Site wechseln oder git pull, fetch, reset, checkout oder clean ausführen, entfallen (jedes Deploy beginnt hier mit einem frischen Checkout), die Variablen von Forge und Ploi werden zu denen von Vimonto Deploy ($FORGE_SITE_PATH und {SITE_DIRECTORY} werden zu $VIMONTO_RELEASE_PATH und so weiter), die Release-Befehle von Forge entfallen, und der Reload von PHP-FPM fällt weg, weil jedes Deploy PHP-FPM von selbst neu lädt. Bleibt eine Variable der Plattform übrig, sagt der Bericht Das Deploy-Skript nutzt noch …; prüfe es unter Deployments. Siehe Deployments.
3. Das aktive Zertifikat kommt mit: Zertifikat und Schlüssel, mit denen die Nginx-Konfiguration der Plattform die Site ausliefert, werden als Zertifikat der Site installiert, damit HTTPS während der Umstellung weiterläuft.
4. Der Code zieht ins Release-Layout: Der Live-Code wird nach releases/000000-migrated kopiert (nicht verschoben), die .env kommt nach shared/.env, Laravels storage nach shared/storage, und current zeigt auf das Release. Das ist das Layout jedes Deployments in Vimonto Deploy.
5. Nginx schaltet mit einem Reload um: Vimonto Deploy schreibt seine eigene Site-Konfiguration, verschiebt die Nginx-Dateien der Plattform für die Namen der Site nach /root/vimonto-takeover-backup/nginx und prüft das Ergebnis mit nginx -t. Akzeptiert Nginx es nicht, kommen die Dateien der Plattform zurück, und die Site läuft weiter wie vorher. Sonst lädt Nginx einmal neu. storage wird nach der Umstellung noch einmal kopiert, damit Uploads aus der Zwischenzeit erhalten bleiben, und PHP-FPM lädt neu.
6. Die alte Kopie wird entfernt: Bei einer Site, die an Ort und Stelle lief, wird alles im Site-Verzeichnis außer releases, shared, current und .ssh entfernt, denn das Release enthält alles. Eine Site, die schon Releases hatte (die Zero-Downtime-Deployments von Forge oder die von Ploi), behält ihre Ordner, weil ihre gemeinsamen Dateien dort liegen.
7. Worker und Features: Die Queue-Worker der Site werden zu den eigenen Workern der Site und zeigen in current. Ein Worker, der artisan horizon ausführt, wird zum Site-Feature Horizon, und eine Laravel-Site, für die ein Cronjob mit schedule:run gefunden wurde, bekommt das Scheduler-Feature.
8. Push-to-Deploy wird bei der Plattform ausgeschaltet, damit ein Push nicht zweimal deployt. Der Bericht sagt das; schalte es hier unter Deployments der Site wieder ein (Bei jedem Push deployen).
9. Ein Let's-Encrypt-Zertifikat wird beantragt für eine Site, die mit einem Zertifikat kam. Vimonto Deploy erneuert es von da an. Schlägt der Antrag fehl, liefert das mitgenommene Zertifikat die Site weiter aus. Hatte eine Forge-Site HTTPS, aber ihr Zertifikat konnte nicht gelesen werden, sagt der Bericht, dass du eines unter Domains und SSL beantragst.

6. Abschließen#

Vimonto Deploy installiert seinen Monitoring-Agenten und setzt den Server auf Aktiv. Der Bericht endet mit … wird jetzt hier verwaltet. Archiviere ihn in …, damit ihn nicht beide verwalten.

Was bleibt gleich?#

• Die Maschine und ihre Adresse. Der Server bleibt bei deinem Provider mit derselben IP-Adresse, deine Domains und dein DNS müssen sich also nicht ändern. Du bezahlst den Provider weiter direkt.
• Der Systembenutzer. Der Server behält seinen Systembenutzer, forge oder ploi, und die Sites bleiben in dessen Home-Verzeichnis.
• Deine Sites laufen weiter. Der Live-Code liefert aus, bis Nginx umschaltet, und das ist ein einziger Reload, Besucher merken also nichts.
• Software, Datenbanken und Daten. Nichts wird neu installiert oder aktualisiert, und Datenbanken werden nicht angerührt.
• Passwörter. Das sudo-Passwort des Servers und die Datenbankpasswörter sind die der Plattform. Vimonto Deploy hatte sie nie und zeigt sie deshalb nicht.

Was machst du danach selbst?#

• Archiviere den Server in Forge oder Ploi, damit nur noch eine der beiden Plattformen ihn verwaltet. Archiviere ihn, statt ihn zu löschen: Einen Server in der Plattform zu löschen, kann die Maschine bei deinem Provider löschen.
• Lies den Bericht unter jedem Server und kümmere dich um seine Warnungen.
• Schalte Push-to-Deploy ein unter Deployments der Site, und prüfe dort das übersetzte Deploy-Skript.
• Deploye einmal mit Jetzt deployen, um zu prüfen, dass die Site hier baut.
• Ploi-Sites mit zusätzlichen Domains: Die API von Ploi liefert sie nicht mit, füge sie also unter Domains und SSL der Site hinzu.
• Entferne das Zugriffs-Recipe oder -Skript aus Forge oder Ploi, wenn du magst; es hat seine Arbeit getan.
• Kündige dein Forge- oder Ploi-Abo, sobald jeder Server umgezogen ist, wenn du es nicht mehr brauchst.

Wie machst du eine Übernahme rückgängig?#

Nichts, was die Plattform angelegt hat, wird gelöscht: Es liegt in /root/vimonto-takeover-backup auf dem Server.

Um zurückzugehen, meldest du dich als root an, verschiebst die Dateien zurück nach /etc/supervisor/conf.d, /etc/nginx/sites-enabled und /etc/cron.d, stellst eine Crontab mit crontab -u forge /root/vimonto-takeover-backup/cron/forge.crontab wieder her, entfernst die Site-Konfiguration von Vimonto Deploy aus /etc/nginx/sites-enabled und führst supervisorctl reread && supervisorctl update, nginx -t und systemctl reload nginx aus. Der Code einer Site, die an Ort und Stelle lief, liegt jetzt in releases/000000-migrated (über current), lass also das Nginx-Root der Plattform auf current zeigen oder verschiebe den Code zurück. Lösche danach den Server in Vimonto Deploy.

Was tun, wenn ein Import fehlschlägt?#

Der Server zeigt Fehlgeschlagen mit dem Fehler in seinem Bericht, und die vollständige Ausgabe der Aufgabe steht auf der Seite Aktivität. Häufige Ursachen:

• Das Zugriffsskript lief nicht rechtzeitig. Die Aufgabe sagt Wir konnten uns nicht als root bei … auf … anmelden. Prüfe, ob das Recipe oder Skript in der Plattform gelaufen ist, und versuch es in ein paar Minuten erneut.
• Der Server hat keine IP-Adresse in der Plattform oder steht nicht mehr im Konto.
• Ein Site-Verzeichnis fehlt: Nur diese Site wird übersprungen, der Rest des Servers wird importiert.

Einen fehlgeschlagenen Server kannst du erneut anhaken: Behebe die Ursache und klicke auf den Import-Button. Ein Server, der nie erreicht wurde, wird wieder entfernt und also neu hinzugefügt; einer, der erreicht wurde, wird weiterverwendet. Der Import lässt sich nicht abbrechen, während er läuft.

Häufige Fragen#

Gehen meine Sites während des Imports offline?#

Nein. Der Code wird kopiert, nicht verschoben, und liefert weiter aus, bis Nginx mit einem einzigen Reload auf die neue Konfiguration umschaltet. Akzeptiert Nginx die neue Konfiguration nicht, kommt die alte zurück.

Kann ich Forge oder Ploi parallel weiter nutzen?#

Nicht für denselben Server. Beide würden Supervisor-Programme, Cronjobs und Nginx-Konfigurationen darauf schreiben. Archiviere jeden Server in der Plattform, sobald er importiert ist. Server, die du nicht importierst, bleiben unverändert in Forge oder Ploi.

Welche Server lassen sich importieren?#

Jeder Server im Forge- oder Ploi-Konto mit einer IP-Adresse, auf dem die Plattform ein root-Skript ausführen kann. Ein Server, dessen IP-Adresse schon in deiner Organisation steht, zeigt Bereits hier. Importierte Server werden zu App-Servern; ihre Sites brauchen eine gültige Domain und ein Verzeichnis, das auf dem Server existiert.

Was ist mit Envoyer oder Zero-Downtime-Sites?#

Sites, die schon in Releases deployen (die Zero-Downtime-Deployments von Forge oder die von Ploi), werden unterstützt: Das aktuelle Release wird nach releases/000000-migrated kopiert, und ihre Ordner bleiben stehen. Envoyer wird nicht gelesen: Eine Site, die Envoyer deployt, wird aus dem importiert, was Forge meldet, schalte also ihre Deployments in Envoyer aus und deploye aus Vimonto Deploy.

Muss ich mein Forge- oder Ploi-Abo kündigen?#

Nicht für den Import: Der braucht ein aktives Konto und Token. Sobald jeder Server umgezogen und archiviert ist, kannst du es selbst kündigen. Vimonto Deploy macht das nicht für dich.

Wird etwas neu installiert oder aktualisiert?#

Nein. Der Import führt keine Provisionierung aus. PHP, die Datenbank, Nginx und der Rest bleiben auf den Versionen, die die Plattform installiert hat.