Tip : Trouvez les erreurs d’application et les problèmes de performance instantanément avec Stackify Retrace

Le dépannage et l’optimisation de votre code sont faciles avec les erreurs intégrées, les journaux et les aperçus de performance au niveau du code.

Similitudes

Chef et Puppet ont des similitudes dans la façon dont ils gèrent les configurations dans les serveurs. Même si les deux outils fonctionnent de manière différente en interne, le résultat est le même. Avec les deux outils, vous pouvez définir l’état souhaité par le biais du code. Les deux outils fonctionnent avec une architecture maître-nœud où le maître est chargé de stocker toutes les données, et les nœuds sont chargés de s’assurer que les serveurs ont toujours la configuration de l’état désiré en place.

Par exemple, l’un des principaux objectifs de l’utilisation de Chef ou Puppet pour la gestion de la configuration est que vous pouvez définir en tant que code ce qui devrait être l’état désiré d’un groupe de serveurs. Cela ne devrait pas avoir d’importance si vous voulez appliquer la même configuration aux serveurs, Chef et Puppet s’assureront de mettre en œuvre tout changement de manière indépendante. De la même manière, nous appuyons tous plusieurs fois sur Ctrl + S pour nous assurer que nous enregistrons bien les modifications. Mais là où ce type d’outils brille, c’est que si quelqu’un entre manuellement dans le serveur, et change l’état souhaité du serveur, ces outils mettront les serveurs à jour en les reconfigurant.

Du point de vue de l’architecture, Chef et Puppet sont assez similaires puisqu’ils utilisent tous deux une architecture maître-agent. Un nœud maître est l’endroit où toutes les configurations de serveur sont stockées. Les maîtres des deux outils sont hautement disponibles (HA), mais avec de légères différences – nous y reviendrons plus tard. Ensuite, pour chaque serveur que vous souhaitez gérer, un agent est installé et récupère automatiquement la configuration par périodes. Les agents vérifient toujours que l’état souhaité est conforme, et non l’inverse. Les deux outils peuvent gérer des serveurs Linux et Windows.

Enfin, les deux outils ont une version open-source et une version payante avec plus de fonctionnalités comme une meilleure configuration HA.

Différences

J’ai dit précédemment que l’architecture de Chef et Puppet sont similaires, mais ils diffèrent légèrement sur la façon dont ils gèrent HA. Dans Puppet, le maître réplique ses données sur un autre serveur, et ils travaillent de manière active/passive. Pour Chef, HA est géré avec trois serveurs en mode actif/actif avec un frontal API qui peut évoluer horizontalement.

Une différence significative entre Chef et Puppet réside dans la façon dont ils définissent la configuration d’état souhaitée pour les serveurs. Chaque outil possède son propre langage spécifique au domaine (DSL). Chef utilise Ruby comme DSL. Vous avez plus de liberté pour créer des configurations complexes car vous utilisez un langage de programmation. Chef appelle ces configurations d’état souhaitées que vous écrivez des recettes. Tout ce que vous pouvez faire avec Ruby, vous pouvez le faire dans Chef pour créer des recettes comme les conditions if ou l’appel d’autres bibliothèques. L’avantage de cette approche est que les développeurs peuvent se sentir plus à l’aise pour écrire des recettes Chef. De plus, les développeurs ne se sentiront pas limités à un DSL uniquement, en ajoutant lors de la définition d’une configuration.

D’autre part, Puppet a son propre DSL, « qui a été conçu pour être accessible aux sysadmins. » Et si vous avez de l’expérience avec les fichiers de configuration de Nagios, écrire des manifestes (leur version des recettes Chef) ne sera pas un problème. Vous n’avez pas trop de liberté ici, mais c’est aussi une bonne chose dans la perspective d’avoir un langage universel. Par conséquent, vous n’avez pas besoin d’avoir une formation de développeur pour utiliser et apprendre Puppet.

Enfin, ces outils diffèrent dans la façon dont vous développez et testez les recettes ou les manifestes. Chef a une station de travail comprenant le SDK Chef que vous pouvez installer dans votre ordinateur local comme un environnement de mise en scène. Vous pouvez tester les recettes localement, puis les télécharger vers le nœud maître. Puppet ne dispose pas d’une station de travail, mais d’un SDK où vous pouvez tester les manifestes tout en les développant. De plus, vous pouvez appliquer les manifestes localement avec la commande puppet apply.

Exemples

Regardons un exemple de code sur la façon de s’assurer que l’agent Stackify est installé.

Une recette dans Chef ressemblera à ceci (Ruby pur):

# ...# bunch of variables declared# ...# download and extract stackify agenttar_extract node do target_dir Chef::Config creates "#{Chef::Config}/#{stackify_agent_install_relative_path}/#{stackify_agent_install_script_name}" not_if { File.exist?(stackify_agent_jar_location) }endtemplate_file = "#{Chef::Config}/#{stackify_agent_install_relative_path}/stackify-agent.conf"template template_file do source "stackify-agent.conf.erb"end# run stackify agent install scriptbash 'agent_install' do user 'root' cwd "#{Chef::Config}/#{stackify_agent_install_relative_path}" code <<-EOH ./#{stackify_agent_install_script_name} #{stackify_agent_install_script_options} rm -rf #{Chef::Config}/Linux rm -rf #{Chef::Config}/#{stackify_agent_install_relative_path} EOH not_if { File.exist?(stackify_agent_jar_location) }end

Pour Puppet, il y a un module pour installer l’agent Stackify, et le manifeste ressemblera à ceci:

 class { 'stackify': package_ensure => 'present', package_install_options_environment => 'development', package_install_options_activationkey => 'XXXXXXXXXXXXXXXXXXXXXXXXXX', file_download_directory => 'C:\Temp', service_manage => true, service_ensure => true, service_enable => true, }

Comme vous pouvez le voir, les exemples de code ci-dessus confirment ce que j’ai dit auparavant. Dans Chef, vous avez plus de liberté. Mais dans Puppet, le code pourrait sembler plus simple quand il y a un module que vous pouvez utiliser.

Fonctionnalités premium

Passons la comparaison, y compris les fonctionnalités premium, qui incluent d’autres choses que la gestion de la configuration.

Pour Puppet, ils ont Puppet Enterprise qui comprend les capacités suivantes :

• Des rapports qui aident avec les politiques de conformité
• Orchestration des déploiements d’applications et d’infrastructures
• Automatisation du provisionnement de l’infrastructure avec l’infrastructure en tant que code
• Gestion du code pour promouvoir automatiquement les changements d’infrastructure
• Gestion des nœuds pour un contrôle granulaire des serveurs
• Politiques de contrôle d’accès basées sur le rôle.based access control policies for users
• Support via email ou téléphone

Ils ont également Puppet Remediate, qui est un outil de gestion des vulnérabilités de vos serveurs. Vous pouvez obtenir de meilleurs aperçus sur les vulnérabilités qui existent dans vos serveurs, et appliquer des correctifs à l’échelle à tous les serveurs.

Dans Chef, outre la gestion de la configuration, la version payante comprend les fonctionnalités suivantes :

• Gestion de la conformité et de la sécurité
• Créer des pipelines CI/CD et gérer les versions pour toutes les applications
• Visibilité avec des tableaux de bord sur toute votre pile d’infrastructure

Vous obtenez plus de détails sur le site de chaque fournisseur, ils ont d’assez bonnes ressources pour vous aider à démarrer rapidement.

Comment choisir

Comment choisir entre Chef et Puppet est une question difficile, et la réponse, comme toujours, est … « ça dépend »

Quel que soit l’outil que vous choisissez, il devrait être une décision d’équipe, en particulier de ceux qui finiront par travailler avec l’outil. Une bonne approche pourrait être de considérer les antécédents de l’équipe. Les personnes ayant une formation d’administrateur système pourraient trouver plus approprié d’utiliser Puppet. Même s’ils devront apprendre le DSL, ce ne sera pas comme apprendre un langage de programmation. Bien que, s’ils ont une expérience dans le développement, les gens pourraient apprécier Chef davantage (même s’ils ne connaissent pas Ruby).

Mais vous devriez également considérer les fonctionnalités premium de chaque outil. Laquelle de ces fonctionnalités aidera votre organisation à réduire les silos et le gaspillage ? Encore une fois, tout dépend de vos besoins. J’ai vu que les deux vendeurs essaieront toujours de se mettre au niveau de l’autre avec les fonctionnalités. Par exemple, dans Puppet, vous pouvez créer des fonctions personnalisées avec Ruby.

Et bien sûr, un autre aspect essentiel est le prix. Je ne veux pas inclure les prix ici parce que cela fluctue beaucoup, et cela varie en fonction des besoins de chaque client. Une autre raison est que dans le cas de Puppet, leur page de tarification n’a pas de numéro public mais un bouton « Nous contacter ». Chef, en revanche, sa page de tarification comporte des numéros, mais vous devez toujours les contacter. Je vous conseille de les contacter directement et de chercher une bonne offre. En fonction du nombre de serveurs que vous devez gérer, ils pourraient vous offrir un meilleur prix.

Il n’y a pas de balle d’argent

Comme un rappel amical, il n’y a pas de balle d’argent pour un outil de gestion de la configuration. Chef et Puppet sont tous deux très matures aujourd’hui, et ils améliorent constamment leur produit, font des investissements dans la recherche, créent de meilleures façons pour les gens d’apprendre leur outil, etc. J’espère que cette comparaison vous a permis de mieux comprendre le fonctionnement des deux outils. Peut-être vous préparez-vous à un entretien d’embauche ou êtes-vous curieux de connaître les principales différences et similitudes.

Mais si vous décidez de l’outil à utiliser pour votre entreprise, assurez-vous d’avoir une idée claire des problèmes que vous rencontrez et de la façon dont ce type d’outils peut vous aider à alléger la charge. Il y aura toujours une courbe d’apprentissage, et cela dépendra de l’expérience de l’équipe et de l’outil qui lui convient le mieux. De plus, regardez les fonctionnalités et les services premium en plus de la gestion de la configuration, car votre entreprise pourrait avoir besoin de plus d’aide avec les politiques de conformité.

• À propos de l’auteur
• Derniers messages

À propos de Christian Melendez

Christian Meléndez est un technologue qui a commencé comme développeur de logiciels et est devenu plus récemment un architecte de nuage axé sur la mise en œuvre de pipelines de livraison continue avec des applications dans plusieurs saveurs, y compris .NET, Node.js et Java, en utilisant souvent des conteneurs Docker.

• AWS Elastic Beanstalk .NET Core Getting Started – January 17, 2020
• AWS Batch : Un guide détaillé pour donner le coup d’envoi de votre premier travail – 26 décembre 2019
• Azure Container Service (AKS) – Une introduction détaillée – 18 décembre 2019
• Envoi de métriques personnalisées CloudWatch depuis Lambda avec des exemples de code – 14 novembre 2019
• Chef vs Puppet : Différences, similitudes et comment choisir – 24 septembre 2019

.