Quels sont les avantages et les inconvénients du déploiement via des installations automatisées par rapport à l'imagerie de lecteur? Pour Windows, je sais qu'il y a des problèmes de génération de SID lors du clonage de disques. Existe-t-il des problèmes similaires pour le déploiement de Linux via une image?
linux
installation
deployment
unattended
Charles Hepner
la source
la source
L'imagerie est une proposition perdante. Une installation complète de kickstart CentOS devrait prendre moins de 10 minutes. Si votre installation est beaucoup plus lente, c'est le problème qui mérite d'être étudié.
Le problème avec l'imagerie est que vous devez conserver une copie «dorée» et la mettre à jour lorsque vous apportez des modifications à votre build. Cela signifie que vous avez toujours besoin d'un mécanisme pour une installation sans assistance, et chaque changement nécessite de faire une telle installation, de changer l'image (nécessitant un mécanisme de personnalisation automatisée pour votre environnement) et de faire de cette copie la copie d'or. Si vous souhaitez apporter des modifications directement à votre copie d'or, vous vous retrouverez rapidement avec un gâchis après des années de correctifs, de mises à niveau, etc.
Si vous devez créer une image des systèmes, vous devez créer une image de la version par défaut du système d'exploitation et faire en sorte que votre travail de post-installation (personnalisation locale) se produise séparément sur chaque nouvelle machine. De cette façon, des modifications triviales de la build ne nécessiteront pas de reconstruire la copie d'or.
Si votre matériel n'est pas tous identiques, vous pouvez tirer parti de la détection / configuration automatisée de l'installateur. J'ai utilisé une configuration Kickstart pratiquement identique entre RedHat / CentOS 3, 4 et 5 et toutes sortes de matériel.
Le pire résultat de l'imagerie que j'ai jamais vu était un système d'installation de systèmes Solaris utilisant une image dorée (et dd avec des multipacks). Leur programme d'installation et de correction est si lent que cela semblait logique. Malheureusement, ils ne changent pas complètement le matériel d'un système installé. Chaque type de matériel avait sa propre image dorée. Un changement de build insignifiant nécessiterait une modification sur des dizaines de disques. Le deuxième pire était celui des machines d'imagerie de groupe Windows (encore une fois raisonnable en raison d'un programme d'installation paralysé) par rapport à un groupe Linux utilisant Kickstart. Le groupe Linux pourrait déployer une modification, par exemple, de la configuration DNS en quelques minutes. (Une minute pour changer la post-installation, puis une version de test, puis une poussée manuelle de la configuration sur les machines existantes). Le groupe Windows a dû démarrer chaque image dorée, faire le changement, annulez la corruption causée par le démarrage de l'image dorée, puis effectuez un test de build. (Ils ont également dû acheter des outils spéciaux pour automatiser les modifications de la configuration du système sur plusieurs machines, pour changer les machines existantes). Le groupe Windows avait également la possibilité de réinstaller l'image dorée pour effectuer leur changement, mais comme il s'agissait d'une installation manuelle du système d'exploitation et de dizaines d'applications, elle serait légèrement différente à chaque fois, nécessitant des semaines de tests et risquant de réduire les systèmes de production. identique qu'autrement possible.
Notez que dans les deux cas, les configurations Windows et Solaris utilisant une image dorée n'ont pas été traitées de la meilleure façon possible et certains des choix effectués par les administrateurs impliqués ont démenti un manque de compétence. Mais commencer avec un design qui n'était pas raisonnable n'a pas aidé.
Kickstart fonctionne si bien qu'il n'y a aucune raison d'envisager de faire autrement (j'ai beaucoup de petites plaintes à ce sujet, mais ce serait mille fois pire s'il était fait par des machines d'imagerie). Si votre programme d'installation est autre qu'Anaconda et que ses installations automatisées sont moins utiles que kickstart, vous devez vous demander si cette distribution a vraiment été conçue pour une utilisation en entreprise.
la source
L'imagerie de disque est plus rapide, mais votre matériel doit être très similaire pour qu'il fonctionne. Il est également plus difficile de personnaliser l'image, vous aurez besoin d'une image de base pour un serveur Web, un serveur de messagerie, etc. Avec les installations automatisées, vous pouvez installer toutes les machines à partir du même emplacement réseau, mais utiliser des scripts différents en fonction du type de serveur vous voulez plutôt avoir besoin de stocker et de créer plusieurs images.
la source
Je ne peux pas vraiment commenter le côté Linux des choses, mais avec Windows, je dirais qu'il n'y a pas trop de pros pour utiliser un processus automatisé sur une image.
Il y a beaucoup de conseils disponibles auprès de Microsoft, ici .
La preuve est dans le pudding. Microsoft utilise désormais des déploiements basés sur des images pour Vista, Windows 2008 et Windows 7. En utilisant les nouveaux outils et processus décrits dans le lien ci-dessus, vous pouvez déployer Windows sur n'importe quel type HAL (y compris XP), avec prise en charge complète des pilotes et sans trop d'efforts. .
la source
Le déploiement de Windows via des images est entièrement pris en charge par Microsoft à l'aide de Sysprep pour «sceller en usine» l'image avant de la déployer. Sysprep réinitialise le SID et prépare essentiellement l'image pour une nouvelle machine.
Cependant, il est fortement recommandé (sauf si vous êtes une petite entreprise) d'avoir également une installation entièrement scriptée, pour une raison simple. Chaque fois que vous devez mettre à jour votre image, vous avez deux options:
1) Modifiez continuellement l'image existante et recommencez à chaque fois. Cela entraînera éventuellement des problèmes lorsque vous continuerez de corriger, de modifier et de préparer la même image encore et encore.
2) Recréez l'image à partir de zéro, ce qui est largement préférable. Cependant, si vous n'avez pas de build scriptée, vous courez le risque élevé d'obtenir de nombreuses incohérences entre les builds.
Donc, en résumé:
Un inconvénient supplémentaire dans tout cela est que Windows Vista, 2008 et 7 utilisent tous une installation basée sur une image, de sorte que les avantages de l'utilisation d'une installation basée sur une image par rapport à une installation scriptée ont de toute façon disparu.
la source
dépend des applications que vous installerez et de la durée pendant laquelle vous conserverez l'image non mise à jour.
il y a beaucoup de mises à jour chaque mois, donc même après avoir restauré la boîte à partir de l'image, vous devrez la mettre à niveau.
en ce qui concerne le SID - pour autant que je sache, cela suffit si vous générez des clés privées uniques [pour ssh, https, tls, par exemple pour les serveurs smtp / pop3, etc.] cela devrait fonctionner correctement. également la génération de nom d'hôte unique serait bien. cela peut différer selon la distribution, j'utilise principalement debian et je n'ai eu aucun problème à cloner des machines virtuelles avec cet os.
la source
Découvrez cette question qui est très similaire:
/programming/398410/windows-disk-cloning-vs-automatic-installation-of-servers
(Je l'ai demandé sur stackoverflow.com il y a quelque temps, lorsque serverfault.com n'était pas là).
la source
Surtout si vous avez un matériel disparate, je suggère une automatisation. Pour les fenêtres, regardez sans surveillance.
http://unattended.sourceforge.net/
la source