Duplication d'instance

Vous avez besoin d'une copie d'une VM. Peut-être que vous montez un nouvel environnement. Peut-être que vous testez un changement risqué et voulez une copie de sécurité pour expérimenter. Peut-être que vous devez simplement scaler horizontalement et que le chemin le plus rapide est de cloner ce qui marche.

Sur Outscale, cloner une VM manuellement est une opération en plusieurs étapes : faire un snapshot de chaque volume attaché, créer une image ou lancer depuis les snapshots, configurer les BlockDeviceMappings pour réattacher tous les volumes, définir les groupes de sécurité, choisir le bon subnet. Ça fait une douzaine d'appels API, chacun une occasion de se tromper de paramètre ou d'oublier un volume.

La console n'a pas de bouton "dupliquer". Et la plupart des équipes n'ont pas le scripting API pour le faire proprement.

Ce que ça fait

La Duplication d'instance clone une VM Outscale — avec tous les volumes attachés — en une seule opération. Vous choisissez l'instance source, confirmez la configuration cible, et Vextnd crée une copie complète. Volume root, volumes de données, tout. Via les BlockDeviceMappings, pas un attachement manuel de volumes après coup.

Le résultat est une nouvelle VM qui est un réplica de l'originale. Même layout de disques, mêmes données, mêmes types de volumes et IOPS. ID d'instance différent, IPs différentes — évidemment — mais la même machine pour tout ce qui compte.

Comment ça marche

Sélectionnez l'instance à dupliquer. Vextnd lit sa configuration complète : type d'instance, volumes (root + données), groupes de sécurité, placement. Vous voyez un aperçu de ce qui sera créé.

Confirmez — ou ajustez. Vous voulez un type d'instance différent ? Changez-le. Vous voulez placer dans un autre subnet ? Changez-le. Les volumes sont copiés tels quels par défaut, en préservant type, taille et IOPS.

Vextnd snapshote tous les volumes attachés, crée la nouvelle instance avec des BlockDeviceMappings qui référencent ces snapshots, et lance. Les volumes sont créés et attachés dans l'appel de lancement lui-même — pas boulonnés après. C'est important parce que les BlockDeviceMappings sont la méthode correcte et atomique pour lancer une instance avec des volumes sur Outscale. L'attachement manuel après lancement est fragile et peut vous laisser avec une instance en marche et des volumes détachés.

Chaque étape est auditée : création de snapshot, lancement d'instance, mapping de volumes, état final. Si une étape échoue, vous savez exactement ce qui s'est passé et ce qui nécessite un nettoyage.

Pourquoi c'est important

La duplication devrait être ennuyeuse. Ça devrait être un clic, pas un projet. Quand ça prend 30 minutes et une connaissance poussée de l'API, les équipes évitent de le faire — ce qui veut dire qu'elles testent des changements risqués sur les machines de production, sautent la création de copies staging propres, et retardent le scaling parce que "cloner c'est compliqué."

Rendre la duplication triviale change les comportements. Besoin d'une copie sandbox de la prod pour un test de charge ? Trois clics. Besoin de scaler un worker en clonant celui qui existe ? Trois clics. Besoin d'une copie sûre avant une mise à jour risquée ? Trois clics.

La trace d'audit compte ici aussi. Quand vous dupliquez une instance, il y a un enregistrement de ce qui a été copié, depuis quelle source, par qui. Pour les environnements soumis à la conformité, c'est pas un bonus — c'est une exigence.

Clonez en un clic. Lancez votre essai gratuit sur Vextnd.