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 que lorsqu'ils sont lancés, ce sont des installations nues d'AWS Linux. Notre processus d'amorçage intégrera 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, c'est que si nous utilisions Puppet, nous aurions 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 16k que nous pouvons rencontrer ou non.

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 par rapport à CloudInit? Oui, absolument, beaucoup d'entre eux!

Bien sûr, vous pouvez écrire de haut en bas des scripts CloudInit 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 forcément 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: pour initialiser l'agent Puppet / Chef / autre.

Puppet ne vous aide pas seulement à automatiser l'installation de packages, à configurer des 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 modifie à nouveau. Vous pouvez changer rapidement la version de Python pour tout ou pour des groupes de nœuds, et si quelqu'un installe une version différente, Puppet la changera.

Lorsque votre pile d'applications change et que vous commencez à utiliser, disons 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, comme le reporting 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 parfaits lorsque vous êtes uniquement limité à 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 des machines de développement?

Si vous existez uniquement dans AWS, je suppose que vous pourriez vous en tirer avec cloudinit et rien d'autre, mais je ne suis pas convaincu que ce soit réaliste pour des applications de toute échelle (Netflix, par exemple, pré-cuit leurs AMI en utilisant les technologies OSS qu'ils ont écrites. et publié dans le monde; regardez cette vidéo pour plus de détails). Les applications hautement disponibles sont transrégionales, souvent basées sur des VPC, ont tendance à être sauvegardées dans des centres de données via des VPN, et cela ne concerne même pas les environnements de démonstration, de préparation, de test ou de développement. En tant que personne chargée de l'approvisionnement des machines, la dernière chose que je veux faire est de répéter le travail ou de rester coincé dans le débogage de plusieurs méthodes d'approvisionnement.

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 plutôt que de maintenir à la fois cloudinit et Chef ou Puppet.

Pour les serveurs jetables, disons courir derrière un groupe d'autoscaling, je dirais que cloudinit est probablement suffisant. les scripts shell Linux ou les scripts PowerShell Windows devraient faire l'affaire.

Si c'est un serveur de longue date que vous prévoyez de gérer, peut-être que le chef, la marionnette ou le 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 à mesure que vous entrez dans des choses plus complexes, vous commencez à découvrir qu'il existe 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.