Implications de l'utilisation des modèles et du clonage de VMware pour le provisionnement de serveurs Linux au lieu de PXE

Il semble y avoir des avantages de vitesse lors de l'utilisation des modèles de VMware pour créer de nouvelles machines virtuelles. Cependant, je suis préoccupé par des implications de sécurité et de flexibilité moins évidentes. Par exemple:

• Clés générées au premier démarrage
• Méthodes propriétaires VMware de configuration des paramètres du serveur (adresses IP, nom d'hôte, etc.)

Dans une boutique qui est presque entièrement VMware avec une majorité de distributions Linux basées sur RHEL, quelqu'un a-t-il rencontré des pièges lors du provisionnement à partir de modèles? Qu'en est-il des préoccupations lors du clonage?

BTW: Quelle que soit la méthode de provisioning initiale, elle serait principalement utilisée comme bootstrap pour Puppet pour le reste de la configuration.

En fonction de l'environnement et de votre processus d'approvisionnement, il peut être plus rapide de créer à nouveau que d'utiliser des modèles VMware et la fonction de clonage à partir d'un modèle .

J'ai travaillé dans un grand environnement VMware axé sur Linux, où le processus de déploiement n'était pas aussi automatisé qu'il aurait dû l'être. Nous nous sommes appuyés sur les modèles vSphere des systèmes RHEL, mais un peu de travail manuel a été nécessaire après le clone initial.

Avantages du modèle:

• Les modèles sont bons si vous créez d'autres applications, paramètres de configuration et autres éléments qui dépassent la portée de la gestion des configurations dans le modèle. ( par exemple, une pile d'applications Oracle complexe )
• Le temps de clonage est fonction de votre stockage et de votre infrastructure vSphere. J'ai vu des travaux de clonage très lents et gourmands en ressources.
• Si vous utilisez Red Hat / CentOS / Debian / Ubuntu, par exemple, vous pouvez profiter de la sys-unconfigcommande pour "déconfigurer" un système avant de créer des modèles. C'est l'équivalent Linux de Microsoft Sysprepet supprime les règles d'interface réseau, les clés SSH, les paramètres réseau, etc.
• Les outils d'affectation IP de VMware sont corrects et n'ont pas posé trop de problèmes avec les systèmes d'exploitation Linux traditionnels.

Avantages du déploiement PXE / kickstart:

• Habituellement plus rapide que le modèle / clonage, en supposant que vous disposez d'un référentiel local et d'une image de démarrage net.
• Plus flexible dans la mesure où vous pouvez apporter des modifications à vos images / master sans le cycle de conversion du modèle en VM, de modification, de reconversion et de clonage.
• Meilleur lorsqu'il est associé à une solution de gestion de configuration.

En fin de compte, cela dépend de votre application et de la quantité de travail supplémentaire nécessaire après l'installation initiale du système d'exploitation. J'ai adopté une approche hybride, en utilisant des clones pour les instances les plus complexes et les nouvelles versions via un système de provisioning pour les systèmes de routine. Ils ne s'excluent pas mutuellement.

Les détails dépendent de la distribution, mais je vais vous donner quelques éléments CentOS / RHEL à retenir lors de la construction de votre modèle.

• Supprimer les clés dans /etc/ssh/
• Supprimez les lignes SUBSYSTEM/etc/udev/rules.d/70-persistent-net.rules qui font référence à vos NIC

Les deux seront régénérés la première fois que vous démarrerez.

Vous avez besoin d'un moyen d'exécuter des mises à jour après avoir déployé le modèle.

Avec vSphere, vous pouvez définir la mise en réseau et le nom d'hôte. En tant qu'utilisateur Puppet, je peux simplement installer le client Puppet dans mon modèle avec un standard puppet.conf. Si j'utilise plusieurs environnements, j'ai en fait besoin d'un modèle différent pour chaque environnement.

Lorsque vous modifiez un modèle, vous devez vous rappeler de supprimer les fichiers ci-dessus.

Personnellement, bien que le déploiement à partir du modèle soit légèrement plus rapide, je préfère tout de même approvisionner à partir de PXE car il est plus flexible.

Jetez un œil à la préparation des machines virtuelles de modèle Linux et à la publication qu'il référence, Création d'une image prête pour les marionnettes (CentOS / Fedora) . Peut-être que cela aide.

Btw: J'aime vraiment votre idée de déployer des machines virtuelles JeOS, puis d'utiliser des marionnettes pour les personnaliser dans une base de données, un site Web ou tout autre serveur.

un autre point positif pour démarrer Linux vm est que les hôtes seront automatiquement entièrement corrigés lors de l'installation (les vm obtiennent les derniers packages à partir des référentiels locaux).

Vous pouvez évidemment réaliser la même chose si vous gardez vos modèles à jour, mais ce n'est pas quelque chose que j'ai vu se produire dans les environnements sur lesquels j'ai travaillé.

La section% post de nos fichiers kickstart (oui, nous en avons plusieurs en fonction de ce que nous installons pour les systèmes, comme 32 ou 64 bits, par exemple) installe simplement l'agent cfengine et à partir de là, les hôtes sont gérés par cfengine.

Je ne l'ai pas chronométré mais je doute que le clonage soit plus rapide une fois l'infrastructure en place. De plus, si c'est le cas, vous pouvez également installer de vrais hôtes ;-)

Pour les systèmes basés sur Debian, nous avons utilisé FAI , ce qui est génial aussi.