Servers importeren uit Laravel Forge of Ploi

De import haalt servers die je met Laravel Forge of Ploi beheert naar Vimonto Deploy, met hun sites, processen, cronjobs, databases en firewallregels. Elke server wordt ter plekke overgenomen: er wordt niets opnieuw geïnstalleerd, je domeinen blijven naar dezelfde machines wijzen en de sites blijven draaien terwijl ze verhuizen.

Je geeft Vimonto Deploy een API-token van het platform, kiest de servers, en elke server wordt in een eigen taak overgenomen. Daarna beheer je de server in Vimonto Deploy zoals elke andere, en archiveer je hem in Forge of Ploi.

Voordat je begint#

• Rechten. Importeren vraagt het recht om servers aan te maken: de rol Eigenaar, Beheerder of Manager.
• Ruimte in je abonnement. Elke geïmporteerde server en elke site erop telt mee voor je abonnement. De pagina controleert vóór de start of de gekozen servers en sites passen, en elke server controleert het opnieuw als zijn taak draait. Op het gratis abonnement (1 server en 3 sites) is dat één server met hoogstens drie sites; voor meer stap je eerst over.
• Een API-token van het platform, met de rechten hieronder.
• Je SSH-sleutel (aanbevolen). Voeg je publieke sleutel toe onder Account → SSH-sleutels, zodat je zelf kunt blijven inloggen; zie SSH-sleutels.

Maak het API-token aan#

De pagina linkt naar de juiste plek voor het platform dat je kiest:

• Laravel Forge: maak een token aan op forge.laravel.com/profile/api. Vimonto Deploy gebruikt de organisatie-API van Forge en toont de servers van elke Forge-organisatie die het token kan zien. Het token moet servers en sites kunnen lezen (ook het omgevingsbestand en het deployscript), recipes kunnen aanmaken en uitvoeren, en push to deploy kunnen uitzetten.
• Ploi: maak een API-sleutel aan op ploi.io/profile/api-keys. Die moet servers en sites kunnen lezen (ook het omgevingsbestand en het deployscript), scripts kunnen aanmaken en uitvoeren, en quick deploy kunnen uitzetten.

Het token wordt alleen gebruikt om je servers te lezen en om één script uit te voeren dat Vimonto Deploy toegang geeft. Het wordt versleuteld bewaard en gewist zodra elke server van dat account is geïmporteerd (of al in je organisatie staat). Ander account gebruiken wist het ook.

Weigert het platform het token, dan zegt de pagina dat onder het veld: … weigerde de API-token, De …-token mist een benodigde rechten of … beperkt het aantal verzoeken; probeer het over een minuut opnieuw.

Stap voor stap servers importeren#

1. Ga naar Servers, open het pijltje naast Nieuwe server en kies Importeren uit Forge of Ploi. De pagina Servers importeren opent.
2. Kies onder Waar staan je servers nu? voor Laravel Forge of Ploi.
3. Plak het token onder API-token en klik op Lees mijn servers. Op je servers verandert nog niets: Vimonto Deploy leest alleen het account.
4. Het paneel Servers in Laravel Forge (of Servers in Ploi) toont elke server met zijn IP-adres, PHP-versie, database, Ubuntu-versie en de domeinen van zijn sites. Servers waarvan het IP-adres al in je organisatie staat, tonen Staat er al en kun je niet kiezen; de andere tonen Klaar om te importeren en zijn allemaal aangevinkt. Vink uit wat je wilt laten staan.
5. Lees de opmerking naast de knop en klik op de importknop (bijvoorbeeld 2 servers importeren).

Elke server wordt een eigen taak, … importeren uit …. Zijn status wordt In de wachtrij, dan Bezig met importeren, dan Geïmporteerd of Mislukt. Onder elke server toont de pagina de stap waar hij is en, gaandeweg, een verslag van wat er is gedaan en wat je aandacht nodig heeft. Je kunt de pagina sluiten: de taken lopen door, je krijgt een melding in het tabblad dat je open hebt zodra elke taak klaar is, en ze staan met hun volledige uitvoer op de pagina activiteit.

Wat gebeurt er met elke server?#

De taak heeft zes stappen.

1. De server en zijn sites lezen#

Vimonto Deploy leest alles wat het platform over de server weet: zijn sites, achtergrondprocessen en queue workers, cronjobs, databases, databasegebruikers en firewallregels. Wat het platform stuurt en niet veilig te gebruiken is (bijvoorbeeld een ongeldig domein, een ongeldige map of gebruikersnaam), blijft achter, en het verslag zegt … is niet geïmporteerd: het platform stuurde instellingen die niet veilig te gebruiken zijn.

2. De server hier toevoegen#

De server komt in je organisatie als App-server, met zijn naam, publieke en privé-IP-adres, PHP-versie, database en Ubuntu-versie. Hij krijgt een eigen SSH-sleutelpaar, zoals elke server in Vimonto Deploy. Hij is niet gekoppeld aan een cloudaccount: je beheert hem zoals een eigen VPS.

3. Toegang tot de server krijgen#

Via het platform voert Vimonto Deploy één script als root uit op die server: een recipe in Forge, een script in Ploi. Het script zet de nieuwe publieke sleutel van de server in /root/.ssh/authorized_keys. Stond SSH op PermitRootLogin no, dan wordt dat prohibit-password, zodat root met een sleutel kan inloggen en nooit met een wachtwoord. Daarna wacht Vimonto Deploy tot 5 minuten tot SSH het binnenlaat.

Vervolgens kijkt het naar de machine zelf: de Ubuntu-versie, de geïnstalleerde PHP-versies, de Supervisor-programma's, en per site of de map bestaat, of het een Laravel-app is en of hij ter plekke of vanuit releases draait. De gevonden PHP-versies verschijnen op de pagina PHP van de server, en SSH, HTTP en HTTPS als de standaard firewallregels van de server.

4. Processen en cronjobs overnemen#

• Databases en firewallregels worden vastgelegd zoals ze zijn: de databases, de databasegebruikers en welke databases ze mogen gebruiken, en de firewallregels naast SSH, HTTP en HTTPS. Op de server verandert daar niets aan.
• Supervisor-programma's: elk programma dat niet van Vimonto Deploy is, verhuist van /etc/supervisor/conf.d naar /root/vimonto-takeover-backup/supervisor, en Vimonto Deploy schrijft zijn eigen processen op basis van wat het platform meldde. Het verslag noemt de verplaatste programma's.
• Cronjobs: een kopie van de crontab van de systeemgebruiker en van root gaat naar /root/vimonto-takeover-backup/cron, en de regels die een cronjob van het platform uitvoeren worden eruit gehaald; de rest van elke crontab blijft staan. Hetzelfde gebeurt in /etc/crontab (eerst gekopieerd), en bestanden in /etc/cron.d die een job van het platform uitvoeren, gaan naar de back-upmap. Vimonto Deploy schrijft de jobs opnieuw als geplande taken.

Queue workers van een site en cronjobs die schedule:run van een site uitvoeren, worden hier niet gemaakt: die verhuizen in de volgende stap met hun site mee.

5. De sites overzetten#

De sites verhuizen één voor één. Een site die niet over kan, houdt de andere niet tegen: het verslag zegt … is niet overgezet: met de reden, bijvoorbeeld als de map niet op de server staat.

Voor elke site:

1. De site wordt toegevoegd met zijn domein en aliassen, map, webmap, PHP-versie, repository en branch, en zijn framework (Laravel, Statamic, WordPress, Symfony, statische HTML, Nuxt, Next.js of gewone PHP). Een site die als eigen Linux-gebruiker draaide, blijft geïsoleerd onder die gebruiker. De .env wordt bij het platform gelezen. Er komt geen nieuwe deploy key bij: de server houdt de Git-toegang die het platform heeft ingesteld.
2. Het deployscript wordt vertaald door Vimonto Deploy: regels die met cd de site in gaan of git pull, fetch, reset, checkout of clean uitvoeren vervallen (elke deploy begint hier met een verse checkout), de variabelen van Forge en Ploi worden die van Vimonto Deploy ($FORGE_SITE_PATH en {SITE_DIRECTORY} worden $VIMONTO_RELEASE_PATH, enzovoort), de release-commando's van Forge vervallen, en de reload van PHP-FPM gaat eruit, want elke deploy herlaadt PHP-FPM vanzelf. Blijft er een variabele van het platform over, dan zegt het verslag Het deployscript gebruikt nog …; controleer het onder Deployments. Zie deployments.
3. Het actieve certificaat gaat mee: het certificaat en de sleutel waarmee de Nginx-configuratie van het platform de site serveert, worden geïnstalleerd als certificaat van de site, zodat HTTPS tijdens de omschakeling gewoon doorgaat.
4. De code verhuist naar de release-indeling: de live code wordt gekopieerd (niet verplaatst) naar releases/000000-migrated, de .env gaat naar shared/.env, de storage van Laravel naar shared/storage, en current wijst naar de release. Dat is de indeling van elke deployment in Vimonto Deploy.
5. Nginx schakelt om in één reload: Vimonto Deploy schrijft zijn eigen siteconfiguratie, verplaatst de Nginx-bestanden van het platform voor de namen van de site naar /root/vimonto-takeover-backup/nginx en controleert het resultaat met nginx -t. Accepteert Nginx het niet, dan komen de bestanden van het platform terug en draait de site door zoals eerst. Anders herlaadt Nginx één keer. storage wordt na de omschakeling nog eens gekopieerd, zodat uploads van tussendoor bewaard blijven, en PHP-FPM herlaadt.
6. De oude kopie wordt verwijderd: bij een site die ter plekke draaide, wordt alles in de sitemap behalve releases, shared, current en .ssh verwijderd, want de release bevat alles. Een site die al releases had (de zero-downtime-deployments van Forge of die van Ploi) houdt zijn mappen, want zijn gedeelde bestanden staan daar.
7. Workers en functies: de queue workers van de site worden de eigen workers van de site en wijzen naar current. Een worker die artisan horizon draait, wordt de sitefunctie Horizon, en een Laravel-site waarvan een cronjob met schedule:run is gevonden, krijgt de scheduler-functie.
8. Push to deploy gaat uit bij het platform, zodat een push niet twee keer deployt. Het verslag meldt dat; zet het hier weer aan onder Deployments van de site (Deployen bij elke push).
9. Er wordt een Let's Encrypt-certificaat aangevraagd voor een site die met een certificaat meekwam. Vimonto Deploy vernieuwt het vanaf dan. Mislukt de aanvraag, dan blijft het meegenomen certificaat de site serveren. Had een Forge-site HTTPS maar kon het certificaat niet worden gelezen, dan zegt het verslag dat je er een aanvraagt onder Domeinen en SSL.

6. Afronden#

Vimonto Deploy installeert zijn monitoring-agent en zet de server op Actief. Het verslag eindigt met … wordt nu hier beheerd. Archiveer hem in … zodat ze hem niet allebei beheren.

Wat blijft hetzelfde?#

• De machine en zijn adres. De server blijft bij je provider met hetzelfde IP-adres, dus je domeinen en DNS hoeven niet te veranderen. Je blijft de provider zelf betalen.
• De systeemgebruiker. De server houdt zijn systeemgebruiker, forge of ploi, en de sites blijven in diens homemap.
• Je sites blijven draaien. De live code blijft serveren tot de omschakeling van Nginx, en dat is één reload, dus bezoekers merken niets.
• Software, databases en gegevens. Er wordt niets opnieuw geïnstalleerd of bijgewerkt, en databases blijven onaangeroerd.
• Wachtwoorden. Het sudo-wachtwoord van de server en de databasewachtwoorden zijn die van het platform. Vimonto Deploy heeft ze nooit gehad, dus toont ze ook niet.

Wat doe je daarna zelf?#

• Archiveer de server in Forge of Ploi, zodat maar één van beide hem beheert. Archiveer hem in plaats van hem te verwijderen: een server verwijderen in het platform kan de machine bij je provider verwijderen.
• Lees het verslag onder elke server en handel de waarschuwingen af.
• Zet push to deploy aan onder Deployments van de site, en controleer daar het vertaalde deployscript.
• Deploy één keer met Deployen om te zien dat de site hier bouwt.
• Ploi-sites met extra domeinen: de API van Ploi stuurt ze niet mee, dus voeg ze toe onder Domeinen en SSL van de site.
• Verwijder de toegangs-recipe of het script uit Forge of Ploi als je wilt; het heeft zijn werk gedaan.
• Zeg je abonnement bij Forge of Ploi op zodra elke server over is, als je het niet meer nodig hebt.

Hoe draai je een overname terug?#

Niets wat het platform heeft gemaakt, wordt verwijderd: het staat in /root/vimonto-takeover-backup op de server.

Om terug te gaan log je in als root, zet je de bestanden terug in /etc/supervisor/conf.d, /etc/nginx/sites-enabled en /etc/cron.d, herstel je een crontab met crontab -u forge /root/vimonto-takeover-backup/cron/forge.crontab, haal je de siteconfiguratie van Vimonto Deploy uit /etc/nginx/sites-enabled, en voer je supervisorctl reread && supervisorctl update, nginx -t en systemctl reload nginx uit. De code van een site die ter plekke draaide, staat nu in releases/000000-migrated (via current), dus laat de Nginx-root van het platform naar current wijzen of zet de code terug. Verwijder daarna de server in Vimonto Deploy.

Wat als een import mislukt?#

De server toont Mislukt met de fout in zijn verslag, en de volledige uitvoer van de taak staat op de pagina activiteit. Veelvoorkomende oorzaken:

• Het toegangsscript draaide niet op tijd. De taak zegt We konden niet als root inloggen op … via …. Kijk of de recipe of het script in het platform is gedraaid, en probeer het over een paar minuten opnieuw.
• De server heeft geen IP-adres in het platform, of staat niet meer in het account.
• Een sitemap ontbreekt: alleen die site wordt overgeslagen, de rest van de server wordt geïmporteerd.

Een mislukte server kun je opnieuw aanvinken: los de oorzaak op en klik op de importknop. Een server die nooit bereikt is, wordt weer verwijderd en dus opnieuw toegevoegd; een server die wel bereikt is, wordt hergebruikt. De import kun je niet annuleren terwijl hij loopt.

Veelgestelde vragen#

Gaan mijn sites offline tijdens de import?#

Nee. De code wordt gekopieerd, niet verplaatst, en blijft serveren tot Nginx in één reload overschakelt op de nieuwe configuratie. Accepteert Nginx de nieuwe configuratie niet, dan komt de oude terug.

Kan ik Forge of Ploi ernaast blijven gebruiken?#

Niet voor dezelfde server. Beide zouden er Supervisor-programma's, cronjobs en Nginx-configuraties op schrijven. Archiveer elke server in het platform zodra hij is geïmporteerd. Servers die je niet importeert, blijven gewoon in Forge of Ploi.

Welke servers kan ik importeren?#

Elke server in het Forge- of Ploi-account met een IP-adres waarop het platform een rootscript kan uitvoeren. Een server waarvan het IP-adres al in je organisatie staat, toont Staat er al. Geïmporteerde servers worden app-servers; hun sites moeten een geldig domein hebben en een map die op de server bestaat.

Hoe zit het met Envoyer of zero-downtime-sites?#

Sites die al in releases deployen (de zero-downtime-deployments van Forge of die van Ploi) worden ondersteund: de huidige release wordt gekopieerd naar releases/000000-migrated en hun mappen blijven staan. Envoyer wordt niet gelezen: een site die door Envoyer wordt gedeployd, wordt geïmporteerd op basis van wat Forge meldt, dus zet de deployments in Envoyer uit en deploy vanuit Vimonto Deploy.

Moet ik mijn abonnement bij Forge of Ploi opzeggen?#

Niet voor de import: die heeft een actief account en token nodig. Zodra elke server over en gearchiveerd is, kun je het zelf opzeggen. Vimonto Deploy doet dat niet voor je.

Wordt er iets opnieuw geïnstalleerd of bijgewerkt?#

Nee. De import voert geen inrichting uit. PHP, de database, Nginx en de rest blijven op de versies die het platform heeft geïnstalleerd.