Pourquoi les gens utilisent-ils Puppet / Chef avec Amazon Cloud Formation au lieu d'utiliser simplement CloudInit?
Nous prévoyons d'utiliser des instances AMI EC2 qui ne sont pas "précuites". C'est à dire. lorsqu'ils sont lancés, ce sont des installations nues d'AWS linux. Notre processus bootstrap récupérera les différentes installations dont nous avons besoin, par exemple python, Tomcat. Nous aurons un minimum de 3 instances et un maximum de 8.
Compte tenu de ces exigences, l'utilisation de Puppet/Chef serait-elle utile plutôt que d'utiliser Amazon Cloud Formation (CloudInit)?
Le mieux que je puisse voir est que si nous utilisions Puppet, nous aurions alors une programmation déclarative qui est plus facile à auditer pour voir ce qui se passe par rapport à un script. CloudInit a également une limite de taille de script de 16 Ko que nous pouvons ou non rencontrer.
Quelqu'un est-il passé de CloudInit à Puppet ou Chef pour une raison spécifique qu'il peut fournir ici en réponse à ma question?
Y a-t-il un avantage sur CloudInit? Oui, absolument, beaucoup d'entre eux!
Bien sûr, vous pouvez écrire des scripts CloudInit de haut en bas une fois pour provisionner un serveur. Mais que se passe-t-il lorsque vous devez modifier un fichier de configuration, ajouter un utilisateur, mettre à jour un package ou installer un nouveau package? Vous finirez par vous connecter aux serveurs ou écrire des scripts pour ce faire, et inévitablement un état incongru des serveurs.
CloudInit n'est pas une gestion de configuration. Si vous choisissez de commencer à utiliser le logiciel de gestion de la configuration, utilisez cloud init pour une seule tâche: démarrer le marionnette/chef/autre agent.
Puppet ne vous aide pas seulement à automatiser l'installation des packages, à configurer les clés ssh ou à régler votre tas Tomcat. Il assure l'état des choses. Lorsqu'un développeur dépanne une application Java à 3 heures du matin et modifie votre configuration Tomcat, Puppet la modifiera à nouveau. Vous pouvez rapidement changer la version de Python pour tous). ou des groupes de nœuds, et si quelqu'un installe une version différente, Puppet la modifiera à nouveau.
Lorsque votre pile d'applications change et que vous commencez à utiliser, par exemple RabbitMQ, ou Jetty, ou un nouveau SGBDR, vous pouvez facilement tester et déployer les modifications sur des dizaines ou des milliers de serveurs.
Il existe de nombreuses autres raisons d'utiliser un logiciel de gestion de la configuration, telles que les rapports back-end, l'audit et la conformité de la sécurité.
L'intérêt de la gestion de la configuration est de faire tourner les machines de manière prévisible et cohérente. CloudFormation et cloudinit sont excellents lorsque vous êtes limité uniquement à AWS (bien que le débogage des modèles CloudFormation soit une expérience misérable ), mais qu'en est-il des applications qui utilisent à la fois les ressources du centre de données et AWS, ou des environnements de test locaux ou le développement Machines?
Si vous existez uniquement dans AWS, je suppose que vous pourriez vous en sortir avec cloudinit et rien d'autre, mais je ne suis pas convaincu que ce soit réaliste pour des applications de toute taille (Netflix, par exemple, précuit leurs AMI en utilisant les technologies OSS qu'ils ont écrites et publié dans le monde; considérez cette vidéo pour plus de détails). Les applications hautement disponibles sont transrégionales, souvent basées sur des VPC, ont tendance à sauvegarder dans les centres de données sur les VPN, et cela ne touche même pas les environnements de démonstration, de transfert, de test ou de développement. En tant que personne chargée de provisionner des machines, les dernières choses que je veux faire sont de répéter le travail ou de bloquer le débogage de plusieurs méthodes de provisioning.
D'où chef ou marionnette. Ils fonctionnent aussi bien pour AWS que pour mon centre de données, et aussi bien pour ma machine de développement exécutant Vagrant que pour les environnements de démonstration dont j'ai parfois besoin à la volée. Je préfère de loin lancer Chef ou Puppet à partir de cloudinit que de maintenir à la fois cloudinit et Chef ou Puppet.
Pour les serveurs jetables, dites courir derrière un groupe de mise à l'échelle automatique, je dirais que cloudinit est probablement suffisant. Les scripts shell Linux ou les scripts Windows PowerShell devraient faire l'affaire.
Si c'est un serveur de longue durée que vous prévoyez de gérer, peut-être un chef, une marionnette ou un docker pourrait vous donner un avantage, comme mentionné dans la réponse acceptée. Si vous ne voyez pas l'avantage après les avoir utilisés, vous n'avez probablement pas besoin de l'outil.
D'après mon expérience, il y a des choses simples qui sont faciles à faire avec les outils GUI prêts à l'emploi fournis par AWS, mais lorsque vous entrez dans des choses plus complexes, vous commencez à découvrir qu'il y a des limites à ce que vous pouvez faire avec juste leurs outils.
À ce stade, vous pouvez soit vous arrêter, soit trouver d'autres outils (comme Chef ou Puppet) qui peuvent vous aider à atteindre ces objectifs plus complexes et à faire les choses les plus simples.
Votre choix.