Importer des serveurs depuis Laravel Forge ou Ploi

L'import fait venir dans Vimonto Deploy les serveurs que vous gérez avec Laravel Forge ou Ploi, avec leurs sites, processus, tâches cron, bases de données et règles de pare-feu. Chaque serveur est repris sur place : rien n'est réinstallé, vos domaines pointent toujours vers les mêmes machines et les sites continuent de tourner pendant leur transfert.

Vous donnez à Vimonto Deploy un token API de la plateforme, vous choisissez les serveurs, et chaque serveur est repris dans sa propre tâche. Ensuite, vous gérez le serveur dans Vimonto Deploy comme n'importe quel autre, et vous l'archivez dans Forge ou Ploi.

Avant de commencer#

• Une permission. Importer nécessite le droit de créer des serveurs : le rôle Propriétaire, Administrateur ou Manager.
• De la place dans votre offre. Chaque serveur importé et chaque site qu'il héberge comptent dans votre offre. La page vérifie avant de commencer que les serveurs et sites choisis tiennent dans l'offre, et chaque serveur vérifie à nouveau quand sa tâche s'exécute. Avec l'offre gratuite (1 serveur et 3 sites), c'est un serveur avec au plus trois sites ; pour plus, changez d'offre d'abord.
• Un token API de la plateforme, avec les droits décrits ci-dessous.
• Votre clé SSH (recommandé). Ajoutez votre clé publique dans Compte → Clés SSH pour pouvoir toujours vous connecter vous-même ; consultez clés SSH.

Créer le token API#

La page renvoie au bon endroit pour la plateforme choisie :

• Laravel Forge : créez un token sur forge.laravel.com/profile/api. Vimonto Deploy utilise l'API d'organisation de Forge et liste les serveurs de chaque organisation Forge que le token peut voir. Le token doit pouvoir lire les serveurs et les sites (y compris le fichier d'environnement et le script de déploiement), créer et exécuter des recipes, et désactiver le push to deploy.
• Ploi : créez une clé API sur ploi.io/profile/api-keys. Elle doit pouvoir lire les serveurs et les sites (y compris le fichier d'environnement et le script de déploiement), créer et exécuter des scripts, et désactiver le quick deploy.

Le token sert uniquement à lire vos serveurs et à exécuter un script qui donne l'accès à Vimonto Deploy. Il est stocké chiffré et effacé dès que chaque serveur de ce compte est importé (ou déjà dans votre organisation). Utiliser un autre compte l'efface aussi.

Si la plateforme refuse le token, la page l'indique sous le champ : … a refusé le jeton API, Il manque au jeton … une permission nécessaire ou … limite les requêtes ; réessayez dans une minute.

Importer des serveurs étape par étape#

1. Allez dans Serveurs, ouvrez la flèche à côté de Nouveau serveur et choisissez Importer depuis Forge ou Ploi. La page Importer des serveurs s'ouvre.
2. Sous Où sont vos serveurs aujourd'hui ?, choisissez Laravel Forge ou Ploi.
3. Collez le token sous Token API et cliquez sur Lire mes serveurs. Rien ne change encore sur vos serveurs : Vimonto Deploy se contente de lire le compte.
4. Le panneau Serveurs dans Laravel Forge (ou Serveurs dans Ploi) liste chaque serveur avec son adresse IP, sa version de PHP, sa base de données, sa version d'Ubuntu et les domaines de ses sites. Les serveurs dont l'adresse IP est déjà dans votre organisation affichent Déjà ici et ne peuvent pas être choisis ; les autres affichent Prêt à importer et sont tous cochés. Décochez ceux que vous voulez laisser.
5. Lisez la note à côté du bouton, puis cliquez sur le bouton d'import (par exemple Importer 2 serveurs).

Chaque serveur devient une tâche à part, Importer … depuis …. Son statut passe à En file d'attente, puis Import en cours, puis Importé ou Échoué. Sous chaque serveur, la page montre l'étape en cours et, au fur et à mesure, un rapport de ce qui a été fait et de ce qui demande votre attention. Vous pouvez fermer la page : les tâches continuent, vous recevez un message dans l'onglet que vous avez ouvert quand chacune se termine, et elles figurent avec leur sortie complète sur la page activité.

Que se passe-t-il pour chaque serveur ?#

La tâche compte six étapes.

1. Lire le serveur et ses sites#

Vimonto Deploy lit tout ce que la plateforme sait du serveur : ses sites, processus en arrière-plan et workers de file, tâches cron, bases de données, utilisateurs de base de données et règles de pare-feu. Ce que la plateforme envoie et qui ne peut pas être utilisé en toute sécurité (par exemple un domaine, un dossier ou un nom d'utilisateur invalide) est laissé de côté, et le rapport indique … n'a pas été importé : la plateforme a envoyé des paramètres qui ne peuvent pas être utilisés en toute sécurité.

2. Ajouter le serveur ici#

Le serveur est ajouté à votre organisation comme Serveur d'application, avec son nom, ses adresses IP publique et privée, sa version de PHP, sa base de données et sa version d'Ubuntu. Il reçoit sa propre paire de clés SSH, comme tout serveur dans Vimonto Deploy. Il n'est lié à aucun compte cloud : vous le gérez comme un VPS personnalisé.

3. Obtenir l'accès au serveur#

Via la plateforme, Vimonto Deploy exécute un script en root sur ce serveur : une recipe dans Forge, un script dans Ploi. Le script ajoute la nouvelle clé publique du serveur à /root/.ssh/authorized_keys. Si SSH était réglé sur PermitRootLogin no, il le passe à prohibit-password, pour que root puisse se connecter avec une clé, jamais avec un mot de passe. Vimonto Deploy attend ensuite jusqu'à 5 minutes que SSH le laisse entrer.

Il examine alors la machine elle-même : la version d'Ubuntu, les versions de PHP installées, les programmes Supervisor, et pour chaque site si son dossier existe, s'il s'agit d'une application Laravel et s'il tourne sur place ou depuis des releases. Les versions de PHP trouvées apparaissent sur la page PHP du serveur, et SSH, HTTP et HTTPS comme règles de pare-feu standard du serveur.

4. Reprendre les processus et tâches cron#

• Les bases de données et règles de pare-feu sont enregistrées telles quelles : les bases de données, les utilisateurs de base de données et les bases qu'ils peuvent utiliser, et les règles de pare-feu en plus de SSH, HTTP et HTTPS. Rien ne change pour elles sur le serveur.
• Les programmes Supervisor : chaque programme qui n'appartient pas à Vimonto Deploy passe de /etc/supervisor/conf.d à /root/vimonto-takeover-backup/supervisor, et Vimonto Deploy écrit ses propres processus d'après ce que la plateforme a indiqué. Le rapport liste les programmes déplacés.
• Les tâches cron : une copie de la crontab de l'utilisateur système et de root va dans /root/vimonto-takeover-backup/cron, et les lignes qui exécutent une tâche cron de la plateforme sont retirées ; le reste de chaque crontab reste en place. La même chose se fait dans /etc/crontab (copié d'abord), et les fichiers de /etc/cron.d qui exécutent une tâche de la plateforme vont dans le dossier de sauvegarde. Vimonto Deploy réécrit les tâches comme tâches du planificateur.

Les workers de file d'un site et les tâches cron qui lancent le schedule:run d'un site ne sont pas créés ici : ils suivent leur site à l'étape suivante.

5. Transférer les sites#

Les sites sont transférés un par un. Un site qui ne peut pas être transféré n'arrête pas les autres : le rapport indique … n'a pas été transféré : avec la raison, par exemple quand son dossier n'est pas sur le serveur.

Pour chaque site :

1. Le site est ajouté avec son domaine et ses alias, son dossier, son dossier web, sa version de PHP, son dépôt et sa branche, et son framework (Laravel, Statamic, WordPress, Symfony, HTML statique, Nuxt, Next.js ou PHP simple). Un site qui tournait sous son propre utilisateur Linux reste isolé sous cet utilisateur. Le .env est lu auprès de la plateforme. Aucune nouvelle clé de déploiement n'est ajoutée : le serveur garde l'accès Git que la plateforme a mis en place.
2. Le script de déploiement est traduit : les lignes qui font un cd dans le site ou lancent git pull, fetch, reset, checkout ou clean disparaissent (chaque déploiement part ici d'un checkout neuf), les variables de Forge et Ploi deviennent celles de Vimonto Deploy ($FORGE_SITE_PATH et {SITE_DIRECTORY} deviennent $VIMONTO_RELEASE_PATH, etc.), les commandes de release de Forge sont retirées, et le rechargement de PHP-FPM disparaît, car chaque déploiement recharge PHP-FPM de lui-même. S'il reste une variable de la plateforme, le rapport indique Le script de déploiement utilise encore … ; vérifiez-le dans Déploiements. Consultez les déploiements.
3. Le certificat actif est repris : le certificat et la clé avec lesquels la configuration Nginx de la plateforme sert le site sont installés comme certificat du site, pour que HTTPS continue pendant la bascule.
4. Le code passe à la structure des releases : le code en ligne est copié (pas déplacé) dans releases/000000-migrated, le .env va dans shared/.env, le storage de Laravel dans shared/storage, et current pointe vers la release. C'est la structure de chaque déploiement dans Vimonto Deploy.
5. Nginx bascule en un seul rechargement : Vimonto Deploy écrit sa propre configuration de site, déplace les fichiers Nginx de la plateforme pour les noms du site vers /root/vimonto-takeover-backup/nginx et vérifie le résultat avec nginx -t. Si Nginx le refuse, les fichiers de la plateforme reviennent et le site continue de tourner comme avant. Sinon, Nginx se recharge une fois. storage est copié à nouveau après la bascule, pour garder les uploads arrivés entre-temps, et PHP-FPM se recharge.
6. L'ancienne copie est supprimée : pour un site qui tournait sur place, tout ce qui se trouve dans le dossier du site sauf releases, shared, current et .ssh est supprimé, car la release contient tout. Un site qui avait déjà des releases (les déploiements zero-downtime de Forge ou ceux de Ploi) garde ses dossiers, car ses fichiers partagés s'y trouvent.
7. Workers et fonctionnalités : les workers de file du site deviennent les workers propres du site et pointent dans current. Un worker qui lance artisan horizon devient la fonctionnalité de site Horizon, et un site Laravel dont une tâche cron schedule:run a été trouvée reçoit la fonctionnalité planificateur.
8. Le push to deploy est désactivé chez la plateforme, pour qu'un push ne déploie pas deux fois. Le rapport l'indique ; réactivez-le ici sous Déploiements du site (Déployer à chaque push).
9. Un certificat Let's Encrypt est demandé pour un site arrivé avec un certificat. Vimonto Deploy le renouvelle désormais. Si la demande échoue, le certificat repris continue de servir le site. Si un site Forge était en HTTPS mais que son certificat n'a pas pu être lu, le rapport vous invite à en demander un dans Domaines et SSL.

6. Finaliser#

Vimonto Deploy installe son agent de monitoring et passe le serveur à Actif. Le rapport se termine par … est désormais géré ici. Archivez-le dans … pour qu'il ne soit pas géré des deux côtés.

Qu'est-ce qui reste identique ?#

• La machine et son adresse. Le serveur reste chez votre fournisseur avec la même adresse IP, donc vos domaines et votre DNS n'ont pas à changer. Vous continuez de payer le fournisseur directement.
• L'utilisateur système. Le serveur garde son utilisateur système, forge ou ploi, et les sites restent dans son dossier personnel.
• Vos sites continuent de tourner. Le code en ligne sert les visiteurs jusqu'à la bascule de Nginx, qui est un seul rechargement : les visiteurs ne remarquent rien.
• Logiciels, bases de données et données. Rien n'est réinstallé ni mis à jour, et les bases de données ne sont pas touchées.
• Mots de passe. Le mot de passe sudo du serveur et les mots de passe des bases de données sont ceux de la plateforme. Vimonto Deploy ne les a jamais eus, il ne les affiche donc pas.

Que faites-vous vous-même ensuite ?#

• Archivez le serveur dans Forge ou Ploi, pour qu'une seule des deux plateformes le gère. Archivez-le plutôt que de le supprimer : supprimer un serveur dans la plateforme peut supprimer la machine chez votre fournisseur.
• Lisez le rapport sous chaque serveur et traitez ses avertissements.
• Réactivez le push to deploy sous Déploiements du site, et vérifiez-y le script de déploiement traduit.
• Déployez une fois avec Déployer maintenant pour vérifier que le site se construit ici.
• Sites Ploi avec des domaines supplémentaires : l'API de Ploi ne les transmet pas, ajoutez-les donc dans Domaines et SSL du site.
• Supprimez la recipe ou le script d'accès de Forge ou Ploi si vous le souhaitez ; il a fait son travail.
• Résiliez votre abonnement Forge ou Ploi une fois tous les serveurs transférés, si vous n'en avez plus besoin.

Comment annuler une reprise ?#

Rien de ce que la plateforme a créé n'est supprimé : tout est dans /root/vimonto-takeover-backup sur le serveur.

Pour revenir en arrière, connectez-vous en root, remettez les fichiers dans /etc/supervisor/conf.d, /etc/nginx/sites-enabled et /etc/cron.d, restaurez une crontab avec crontab -u forge /root/vimonto-takeover-backup/cron/forge.crontab, retirez la configuration de site de Vimonto Deploy de /etc/nginx/sites-enabled, puis lancez supervisorctl reread && supervisorctl update, nginx -t et systemctl reload nginx. Le code d'un site qui tournait sur place se trouve désormais dans releases/000000-migrated (via current) : faites pointer la racine Nginx de la plateforme vers current ou remettez le code en place. Supprimez ensuite le serveur dans Vimonto Deploy.

Que faire si un import échoue ?#

Le serveur affiche Échoué avec l'erreur dans son rapport, et la sortie complète de la tâche figure sur la page activité. Causes fréquentes :

• Le script d'accès n'a pas tourné à temps. La tâche indique Impossible de se connecter en root à … sur …. Vérifiez que la recipe ou le script a tourné dans la plateforme, puis réessayez dans quelques minutes.
• Le serveur n'a pas d'adresse IP dans la plateforme, ou n'est plus dans le compte.
• Un dossier de site manque : seul ce site est ignoré, le reste du serveur est importé.

Un serveur en échec peut être coché à nouveau : corrigez la cause et cliquez sur le bouton d'import. Un serveur jamais atteint est retiré, puis ajouté à neuf ; un serveur atteint est réutilisé. L'import ne peut pas être annulé pendant qu'il tourne.

Questions fréquentes#

Mes sites sont-ils coupés pendant l'import ?#

Non. Le code est copié, pas déplacé, et continue de servir les visiteurs jusqu'à ce que Nginx bascule sur la nouvelle configuration en un seul rechargement. Si Nginx refuse la nouvelle configuration, l'ancienne revient.

Puis-je continuer à utiliser Forge ou Ploi en parallèle ?#

Pas pour le même serveur. Les deux y écriraient des programmes Supervisor, des tâches cron et des configurations Nginx. Archivez chaque serveur dans la plateforme une fois importé. Les serveurs que vous n'importez pas restent tels quels dans Forge ou Ploi.

Quels serveurs peuvent être importés ?#

Tout serveur du compte Forge ou Ploi qui a une adresse IP et sur lequel la plateforme peut exécuter un script en root. Un serveur dont l'adresse IP est déjà dans votre organisation affiche Déjà ici. Les serveurs importés deviennent des serveurs d'application ; leurs sites doivent avoir un domaine valide et un dossier qui existe sur le serveur.

Et Envoyer ou les sites zero-downtime ?#

Les sites qui déploient déjà dans des releases (les déploiements zero-downtime de Forge ou ceux de Ploi) sont pris en charge : la release actuelle est copiée dans releases/000000-migrated et leurs dossiers restent en place. Envoyer n'est pas lu : un site déployé par Envoyer est importé d'après ce que Forge indique, désactivez donc ses déploiements dans Envoyer et déployez depuis Vimonto Deploy.

Dois-je résilier mon abonnement Forge ou Ploi ?#

Pas pour l'import : il a besoin d'un compte actif et d'un token. Une fois chaque serveur transféré et archivé, vous pouvez le résilier vous-même. Vimonto Deploy ne le fait pas pour vous.

Quelque chose est-il réinstallé ou mis à jour ?#

Non. L'import ne lance pas de provisionnement. PHP, la base de données, Nginx et le reste restent aux versions installées par la plateforme.