Vagrant ou Docker peuvent-ils remplacer Clonezilla pour le clonage de machines de développement sur des machines virtuelles?
La question d'origine Comment migrer Ubuntu actuellement installé vers une machine virtuelle? était perspicace, mais avec les améliorations et les développements dans des systèmes comme Vagrant ou Docker, peut-être Clonezilla devient-il archaïque pour répliquer des environnements de développement. Je pense que cela mérite d'être revu.
Mes impressions sur Vagrant et Docker par rapport à ce sujet:
- Vagrant . Idéal pour créer des machines virtuelles dans lesquelles exécuter votre code. Cependant, si vous avez une machine Ubuntu existante avec beaucoup de configurations, etc ... il semble qu'il n'y ait aucun moyen d'exporter le paramètre de cette machine vers un fichier vagrant?
- Docker . Semble être bon pour en cours d'exécution votre application partout où Docker est installé, mais pas en développement votre application n'importe où. Je me trompe peut-être, c'est pourquoi je demande. Si votre machine de développement principale tombe en panne, le fait d'avoir un conteneur Docker est-il suffisant pour être opérationnel rapidement dans un environnement de développement?
Question: Vagrant ou Docker peuvent-ils remplacer Clonezilla pour le clonage de machines de développement sur des machines virtuelles? Si oui, lequel choisiriez-vous et pourriez-vous donner quelques points clés sur la mise en œuvre dans ce cas?
Bien sûr, mais ce sont des approches différentes pour à peu près la même chose.
- Clonezilla (et al) implique de prendre une image complète du chargeur de démarrage via l'application. C'est grand et il n'y a pas de déduplication. Si vous disposez de 50 instances d'une pile similaire, effectuez une sauvegarde complète de chacune et stockez 50 images complètes. Vous stockez un tas de trucs qui sont facilement remplaçables.
- Docker s'installe sur le stock Ubuntu (installable à partir d'un CD). Chaque conteneur peut être basé sur une image publique. Vous superposez vos données irremplaçables par-dessus. C'est tout ce dont vous avez besoin pour sauvegarder. Dans le scénario précédent, cela signifie qu'il existe désormais 50 copies de base d'Ubuntu que vous n'avez pas à sauvegarder.
Pour restaurer le premier, il vous suffit d'obtenir votre image et de la graver. Pour restaurer une pile Docker entière, vous devez réinstaller Ubuntu, Docker, prenez l'image de base [minuscule] Ubuntu, puis réinstallez vos couches et votre configuration. Vous pouvez - et devez - automatiser le processus de construction (Chef, Puppet, etc.).
La ramification à long terme est simple: l'espace disque. Vous pouvez sauvegarder votre application Docker un milliard de fois dans le même espace que vos images Clonezilla ... Au prix de la complexité.
Sidebar: Bien que je mentionne l'automatisation, il existe une troisième école de pensée qui utilise simplement Chef/Puppet pour automatiser l'installation et la configuration des installations Ubuntu. Vous vous retrouvez avec des installations complètes, donc aucun des avantages de stockage/mémoire d'exécution que Docker ne vous offre, mais de petites sauvegardes et une réplication facile.
Les conteneurs sont une bonne idée. Les conteneurs et les couches sont probablement une idée encore meilleure. Je ne les ai pas encore implémentés avec colère, mais je commence à peine à voir les avantages de LXC, donc ce ne sera pas long, j'en suis sûr.
Et dans votre cas, n'oubliez pas vous pouvez utiliser les deux techniques de sauvegarde à la fois si vous n'êtes pas sûr. Cela signifie que vous pouvez prendre une image Clonezilla d'un hôte Docker (et conserver des sauvegardes de vos images Docker privées ailleurs)