Quand est-il approprié d'utiliser un gestionnaire de configuration (par exemple Puppet / Chef / Ansible)?

Sur mon lieu de travail actuel, je gère deux machines hôtes VMware, une machine physique OpenBSD, trois machines virtuelles Debian et six machines virtuelles Windows Server (2008/2012).

J'envisage d'implémenter un outil de gestion de configuration tel que Puppet ou Chef. Est-ce raisonnable ou les frais généraux liés à l'apprentissage de l'outil l'emporteront-ils sur les avantages? Où est le point de basculement entre la gérabilité et les coûts de mise en œuvre?

À mon humble avis, cela vaut la peine d'apprendre même si vous ne gérez qu'un seul serveur,

Oui, il y aura une courbe d'apprentissage. Oui, vous serez frustré. Pour ces coûts, cependant, vous serez remboursé en plusieurs fois grâce à des déploiements fiables et cohérents en un seul clic, une configuration de serveur à version contrôlée, une facilité de configuration des environnements de test / développement, etc.

En plus des avantages de votre emploi actuel, être en mesure d'ajouter un système CM à votre CV est une grande victoire. On s'attend maintenant à ce que les administrateurs système modernes soient au moins exposés à un système de gestion de configuration, sinon à des compétences.

(Sidenote: considérez également Ansible. C'est mon CM préféré, et il est très facile de démarrer et de fonctionner avec - beaucoup plus facile que Puppet ou Chef. De plus, le support Windows dans Ansible se déroule bien.)

J'envisage d'implémenter un outil de gestion de configuration tel que Puppet ou Chef. Est-ce raisonnable ou les frais généraux liés à l'apprentissage de l'outil l'emporteront-ils sur les avantages?

C'est raisonnable selon le temps et l'argent que vous devez brûler, et si c'est votre argent que vous brûlez ou non.

Un outil de gestion de configuration (n'importe lequel d'entre eux) devient une compétence précieuse sur le marché actuel.

Passer du temps à apprendre et à mettre en œuvre un outil de CM n'est peut-être pas la chose la plus efficace à faire du point de vue de votre entreprise ou de votre environnement, mais de vos compétences, cela peut valoir la peine.

Où est le point de basculement entre la gérabilité et les coûts de mise en œuvre?

La plupart des outils de gestion de la configuration sont disponibles gratuitement avec la mise en garde qu'ils sont plus difficiles à installer et à démarrer.

Cette question est un peu difficile à répondre car elle dépend vraiment de ce que vous faites au quotidien pour gérer ces serveurs. Si vous n'êtes pas obligé de faire grand-chose, un outil de gestion de la configuration peut être totalement exagéré.

Si vous n'avez vraiment besoin que de mettre en place votre infrastructure dans un état prévisible et basique, cela peut ne pas faire beaucoup de mal de reprendre les bases de quelque chose comme SaltStack ou Ansible.

D'après mon expérience personnelle, Salt est très facile à démarrer et à démarrer sur les serveurs, et peut être utilisé pour une exécution et des rapports à distance très basiques, ce qui peut être utile si vous ne l'avez pas déjà implémenté dans votre environnement.

Gardez à l'esprit, je suis partial. Vous devez évaluer chaque outil CM par vous-même.

Tout comme @EEAA l'a dit - le nombre de serveurs n'est pas pertinent. Vous pouvez profiter des avantages de l'utilisation de la gestion de la configuration avec une seule machine:

• configuration documentée (documentée via des scripts CM)
• un déploiement fiable (vous pouvez [re] déployer votre configuration encore et encore
• résilience de la configuration (croassement du serveur actuel - en faire tourner un nouveau)
• réutilisation (lorsque vous arrivez au point d'avoir un deuxième serveur - vous avez déjà des scripts CM que vous pouvez recycler à partir du premier)
• mises à niveau (c'est un peu comme une nouvelle configuration, juste au sommet d'une plate-forme différente)

Je peux dire que j'ai dû implémenter CM pour tous mes serveurs personnels car j'y travaille rarement et j'oublie tous les petits détails. Avoir des scripts CM peut sembler prendre beaucoup de temps (c'est le cas), le retour sur investissement en vaut la peine. À long terme, vous économiserez beaucoup plus de temps que vous passerez à configurer les choses.

J'ai de l'expérience avec Puppet et Ansible. Ansible est IMO plus simple, car il est procédural, tandis que Puppet est déclaratif. Il y a des avantages et des inconvénients pour les deux, mais j'ai tiré suffisamment de cheveux en raison des erreurs cryptiques de Puppet.

Les deux nécessitent beaucoup de travail si vous souhaitez créer une configuration propre et réutilisable. Les coûts commencent vraiment à porter leurs fruits si vous avez au moins deux serveurs très similaires, par exemple des clouds ou des clusters.

Cependant, il a une certaine utilité, même pour les serveurs autonomes - vous pouvez configurer des utilisateurs administratifs, des configurations standard (avec des variations locales) sshd, postfix ou snmpd et les utiliser également pour une collecte d'informations simple, comme le respect de la politique ou le test de vulnérabilité shellshock.

En outre, comme mentionné par l'EEAA, il a une valeur pour documenter la configuration si vous vérifiez qu'il amène vraiment un serveur de l'état de base à l'état en cours d'exécution. Il est bon de le combiner avec le système de contrôle de version (git), afin que les modifications que vous apportez soient versionnées et documentées. C'est très utile si vous avez une équipe d'administrateurs.

La marionnette ou tout autre système de gestion apporte de grands avantages qui ont tous été mis en évidence par d'autres réponses ici, mais il n'y a pas de solution miracle en matière de gestion.

Par exemple, la création de classes de marionnettes pour des systèmes complexes coûte beaucoup de temps et d'efforts et parfois des larmes car il y a de nombreux pièges, et les messages d'erreur ne sont pas toujours clairs à 100%, et lorsque les mises à niveau logicielles, vous devez investir du temps pour adapter vos classes de marionnettes pour correspondre à toute nouvelle spécification ou la procédure et déterminer quelle approche est la plus appropriée pour cela (marionnette par exemple déclarative et une mise à niveau est généralement procédurale)

Vous devez également comprendre comment vous envisagez de déployer les modifications apportées à vos classes de manière contrôlée et comment maintenir les différentes versions de vos manifestes.

Vous devriez également réfléchir à la façon de mettre à niveau votre solution de gestion lorsque le moment sera venu.

Si vous passez beaucoup de temps à écrire, par exemple des classes de marionnettes, vous devrez effectuer de nombreuses installations en un clic pour en retirer de réels avantages.

Je recommande d'explorer encore et le cas échéant, c'est-à-dire que la distribution de fichiers de configuration peut être un bon endroit pour commencer et le reprendre à partir de là.