Un transfert de serveur déplace un serveur, avec ses sites, ses bases de données et tout ce qui s'y trouve, d'une organisation de Vimonto Deploy vers une autre. Vous proposez le serveur à quelqu'un par e-mail ; cette personne l'accepte dans l'une de ses organisations, et à partir de là il lui appartient. Rien ne change sur le serveur lui-même : il continue de tourner et ses sites restent en ligne.
Utilisez-le pour remettre un serveur à un client, pour le déplacer vers l'organisation d'un collègue ou pour le faire passer d'une de vos organisations à une autre.
Qui peut transférer un serveur ?
- Envoyer un transfert demande le droit de supprimer des serveurs dans l'organisation actuelle : le rôle Propriétaire, Administrateur ou Manager. Voir membres et rôles.
- Accepter un transfert demande un compte Vimonto Deploy avec l'adresse e-mail à laquelle le transfert a été envoyé, et le droit de créer des serveurs dans l'organisation de destination : là aussi Propriétaire, Administrateur ou Manager.
Le destinataire n'a pas besoin d'être membre de votre organisation. S'il n'a pas encore de compte, il peut en créer un depuis le lien de l'e-mail.
Envoyer un transfert
- Ouvrez le serveur et choisissez Paramètres dans la barre latérale.
- Sous Zone de danger, cliquez sur Transférer le serveur.
- Saisissez l'Adresse e-mail du nouveau propriétaire et cliquez sur Envoyer le transfert.
Le destinataire reçoit un e-mail avec un bouton Voir le transfert. Tant qu'il n'a pas accepté, rien ne change : le serveur reste dans votre organisation et fonctionne comme avant. La Zone de danger indique à qui le serveur est proposé et jusqu'à quand.
Quelques règles :
- Vous ne pouvez envoyer un transfert que lorsqu'aucune tâche ne tourne sur le serveur, comme un déploiement ou le provisionnement.
- Un serveur n'a qu'un seul transfert en cours à la fois. En envoyer un nouveau remplace l'offre précédente, et l'ancien lien ne fonctionne plus.
- Vous ne pouvez envoyer un transfert à votre propre adresse e-mail que si vous êtes membre d'une autre organisation, pour y déplacer le serveur.
- Dès que le transfert est accepté, votre organisation perd son accès : les clés SSH de votre organisation et de ses membres sont retirées du serveur, et le mot de passe sudo du serveur ainsi que les URL de déploiement des sites changent. Voir Comment l'ancienne organisation perd-elle son accès ? ci-dessous.
Combien de temps un transfert est-il valable ?
Sept jours. Ensuite, le lien ne fonctionne plus et vous envoyez un nouveau transfert si nécessaire. Le lien cesse aussi de fonctionner dès que le transfert est accepté ou annulé, ou lorsque le serveur n'est plus dans l'organisation depuis laquelle il a été proposé.
Pour retirer une offre, cliquez sur Annuler le transfert dans la Zone de danger des paramètres du serveur. Les transferts expirés sont supprimés automatiquement.
Accepter un transfert
- Ouvrez le lien de l'e-mail. Si vous n'êtes pas connecté, choisissez Se connecter ou Créer le compte avec l'adresse e-mail à laquelle le transfert a été envoyé ; vous revenez ensuite au transfert.
- La page Reprendre … affiche le serveur, son adresse IP et le nombre de sites qu'il héberge. Sous Avant d'accepter, elle liste pour ce serveur Ce que nous faisons pour vous et Il vous reste à faire (voir plus bas), puis ce qui reste en arrière.
- Sous Dans l'organisation, choisissez l'organisation qui reçoit le serveur. Seules les organisations dans lesquelles vous pouvez créer des serveurs sont proposées.
- Cliquez sur Accepter le serveur.
Le serveur et ses sites comptent dans l'offre de l'organisation qui le reçoit : avec l'offre gratuite, l'acceptation est refusée s'ils n'y tiennent pas.
Le serveur est déplacé immédiatement et sa page s'ouvre dans votre organisation. Si une tâche tourne encore sur le serveur, attendez une minute et réessayez. Si aucune de vos organisations ne peut recevoir le serveur, créez-en d'abord une (voir organisations).
Juste après l'acceptation, vous recevez un e-mail, … est désormais à vous : ce qu'il reste à faire, avec les deux mêmes listes et un bouton Voir le serveur. Le nouveau mot de passe sudo n'y figure pas : il arrive dans un e-mail séparé dès qu'il est défini.
Qu'est-ce qui suit le serveur ?
Tout ce qui se trouve sur le serveur le suit : ses sites avec leurs domaines, certificats, environnement, scripts de déploiement et historique des déploiements, les bases de données et leurs utilisateurs, les versions de PHP, les processus, les tâches planifiées, les règles de pare-feu, la supervision et ses paramètres. Les clés SSH ne suivent pas, sauf celles de votre propre organisation et de ses membres (voir ci-dessous).
La paire de clés propre au serveur et sa clé d'hôte SSH le suivent aussi, si bien que Vimonto Deploy continue de s'y connecter comme avant.
Qu'est-ce qui reste dans l'ancienne organisation ?
Ce qui appartient à l'organisation et non au serveur ne le suit pas :
| Quoi | Ce qui se passe |
|---|---|
| Compte fournisseur | Le serveur n'est plus lié au compte cloud avec lequel il a été créé. Il continue d'y tourner et reste facturé à ce compte : déplacez-le vous-même chez le fournisseur si nécessaire. Depuis la nouvelle organisation, supprimer le serveur arrête seulement sa gestion ; la machine ne peut plus être supprimée chez le fournisseur. |
| Connexions Git | Les sites perdent leur connexion Git, et le Déploiement rapide est désactivé. |
| Sauvegardes | Les planifications de sauvegarde et leur liste de sauvegardes sont supprimées. Les fichiers de sauvegarde restent dans le stockage de l'ancienne organisation. |
| Équipes | Le serveur est retiré des équipes de l'ancienne organisation. |
| Load balancers | Les liens entre ce serveur et les load balancers de l'ancienne organisation sont supprimés dans les deux sens, et la configuration Nginx des sites concernés est réécrite. Voir répartition de charge. |
Le transfert est enregistré dans le journal d'audit des deux organisations : l'envoi, l'annulation et l'acceptation.
Comment l'ancienne organisation perd-elle son accès ?
Au moment où le serveur change d'organisation, et dans une tâche juste après, Vimonto Deploy retire l'accès que l'ancienne organisation a encore :
| Quoi | Ce qui se passe |
|---|---|
| URL de déploiement | Chaque site reçoit immédiatement une nouvelle URL de déploiement. L'ancienne URL ne fonctionne plus : l'ancienne organisation ne peut plus lancer de déploiements depuis sa CI ou son webhook Git. |
| Clés SSH | La tâche Sécuriser serveur après le transfert retire chaque clé que Vimonto Deploy a placée sur le serveur et qui n'est ni une clé de la nouvelle organisation ni une clé de compte d'un de ses membres : les clés de l'ancienne organisation, celles de ses membres et les clés ajoutées sur la page Clés SSH du serveur. Elle ajoute ensuite les clés SSH de la nouvelle organisation. |
| Mot de passe sudo | La même tâche donne un nouveau mot de passe sudo à l'utilisateur système. Seule la personne qui a accepté le voit, une fois, dans la fenêtre Mots de passe de serveur de la vue d'ensemble, et en reçoit une copie par e-mail. Voir paramètres du serveur. |
| Alertes | Les moniteurs et heartbeats écrivent désormais à la personne qui a accepté au lieu des anciennes adresses. |
| Commande de connexion | Un VPS personnalisé qui attendait encore sa commande de connexion en reçoit une nouvelle ; l'ancienne ne fonctionne plus. |
La vue d'ensemble du nouveau propriétaire affiche Ce serveur vous a été transféré, avec ce qui a été fait et ce qu'il reste à faire. Si la tâche a échoué, par exemple parce que le serveur était injoignable, cliquez sur Réessayer. Cliquez sur Compris pour masquer l'avis.
Vimonto Deploy ne change rien qui mettrait vos sites hors ligne ni ce qu'il ne connaît pas : le mot de passe de la base de données (les sites le lisent dans leur environnement), les secrets de l'environnement des sites comme APP_KEY, et les accès mis en place sur le serveur en dehors de Vimonto Deploy. Les URL de ping des heartbeats restent aussi les mêmes, car les tâches planifiées du serveur les appellent, et les clés de déploiement des sites peuvent encore lire les dépôts de l'ancienne organisation jusqu'à ce qu'elle les retire chez son hébergeur Git.
Après l'acceptation : que doit faire le nouveau propriétaire ?
La liste Il vous reste à faire de la page d'acceptation, de l'e-mail et de l'avis de la vue d'ensemble reprend les points ci-dessous qui concernent votre serveur.
- Reconnecter Git. Reliez les sites à une connexion Git à vous et réactivez le Déploiement rapide là où vous le souhaitez. Voir déploiements. La clé de déploiement des sites peut encore lire le dépôt de l'ancienne organisation jusqu'à ce qu'elle la retire chez son hébergeur Git.
- Conserver le nouveau mot de passe sudo depuis la fenêtre Mots de passe de serveur de la vue d'ensemble, puis cliquer sur Je les ai enregistrés. En acceptant, vous devenez le créateur du serveur dans la vue d'ensemble : vous seul le voyez donc (Afficher une seule fois).
- Mettre à jour votre CI. Chaque site a une nouvelle URL de déploiement : copiez-la depuis la page Déploiements du site dans votre CI.
- Planifier des sauvegardes vers votre propre stockage sur la page sauvegardes.
- Changer le mot de passe de la base de données si le serveur en a une : sur la page Bases de données, cliquez sur Changer le mot de passe pour l'utilisateur système, puis mettez le nouveau mot de passe dans le
.envdes sites qui l'utilisent. Vimonto Deploy ne le change pas pour vous, car les sites le lisent dans leur.envet seraient hors ligne. Changez aussi les autres secrets que l'ancien propriétaire connaît, commeAPP_KEYet les clés d'API. - Recréer les heartbeats si leurs URL doivent rester secrètes. Les URL de ping des heartbeats restent les mêmes, car les tâches planifiées du serveur les appellent ; l'ancienne organisation les connaît donc. Supprimez les heartbeats sur la page Monitoring, ajoutez-les à nouveau et mettez les nouvelles URL dans vos tâches.
- Vérifier les accès hors de Vimonto Deploy. Les clés ajoutées à la main dans
authorized_keyset les utilisateurs Linux supplémentaires sont inconnus de Vimonto Deploy et restent en place. Retirez-les si nécessaire. - L'ajouter à vos équipes si les membres de votre organisation ne voient que les serveurs de leurs équipes. D'ici là, seuls les membres qui voient tous les serveurs le voient.
- Remettre en place la répartition de charge si le serveur se trouvait derrière un load balancer.
Questions fréquentes
Le serveur est-il hors ligne pendant un transfert ?
Non. Un transfert change seulement l'organisation qui gère le serveur dans Vimonto Deploy. Rien ne s'exécute sur le serveur, et ses sites continuent de servir les visiteurs.
Puis-je déplacer un serveur entre mes propres organisations ?
Oui. Envoyez le transfert à votre propre adresse e-mail, ouvrez le lien et choisissez l'autre organisation sous Dans l'organisation. Il vous faut le droit de supprimer des serveurs dans la première organisation et d'en créer dans la seconde.
L'ancienne organisation peut-elle encore accéder au serveur ?
Pas via Vimonto Deploy : ses URL de déploiement cessent de fonctionner immédiatement, et ses clés SSH ainsi que l'ancien mot de passe sudo sont retirés du serveur juste après. Seuls ce qui a été mis en place en dehors de Vimonto Deploy et le mot de passe de la base de données restent tels quels ; changez-les vous-même. Tant que la machine se trouve dans son compte fournisseur, l'ancienne organisation peut encore la gérer là-bas. Les URL de ping des heartbeats restent aussi les mêmes, jusqu'à ce que vous recréiez les heartbeats.
La facturation chez le fournisseur cloud suit-elle aussi ?
Non. Le serveur reste dans le compte fournisseur où il a été créé, qui continue de le facturer. Pour le déplacer vers un autre compte, utilisez la fonction de transfert du fournisseur ; ensuite, il est géré dans Vimonto Deploy comme un VPS personnel.
Et si le destinataire n'accepte jamais ?
Alors rien ne se passe. Le transfert expire après sept jours et le serveur reste où il est. Vous pouvez aussi l'annuler plus tôt avec Annuler le transfert.