Comment les petits peuvent-ils apprendre et utiliser efficacement Puppet ?

Lors d'un précédent emploi, on m'avait confié la tâche de faire une implémentation pilote de Puppet. Maintenant, j'ai des antécédents en programmation, bien que pas en Ruby, donc je n'ai pas autant de problèmes que d'autres.

Cependant, il est intéressant de noter que les programmeurs sans expérience des paradigmes non traditionnels rencontrent également des problèmes avec Puppet, car Puppet est déclaratif, pas impératif. En ce sens, Puppet fonctionne pratiquement comme n'importe quel fichier de configuration : vous indiquez comment les choses doivent être, et Puppet se charge du reste.

Après la phase pilote, j'ai eu l'opportunité de former une douzaine d'autres administrateurs à Puppet, ainsi que de faire des présentations à ce sujet lors de deux événements. Ce que j'ai retenu de cette expérience, c'est que certains administrateurs ont réussi, et d'autres non. Ils étaient tous des administrateurs traditionnels, sans compétences en programmation, et avec des niveaux d'expertise variables.

Une chose particulière que j'ai remarquée, c'est que Puppet nécessite une pratique constante. Les personnes formées, qui ont écrit des modules, et qui ont ensuite passé un mois ou deux à faire autre chose, sont revenues à Puppet avec peu de compétences utiles. Les personnes qui ont continué à faire de petites choses chaque semaine n'ont jamais perdu la capacité.

Sur la base de ces deux observations, je vous recommande de vous assurer que tout le monde continue d'ajouter une classe, une définition ou un module Puppet chaque semaine (de préférence au moins deux ou trois fois). Ceux qui ne parviennent toujours pas à s'y habituer pourraient vraiment manquer des compétences pour le faire.

Cependant, si Puppet leur était imposé par le haut, ils pourraient simplement réagir à ce qu'ils perçoivent comme une ingérence de la direction dans leur façon de travailler -- ce qui serait en fait vrai. Il se pourrait que leur laisser le choix du quel système de gestion de configuration à utiliser améliore les choses. Voici quelques alternatives :

• ANSIBLE : C'est nouveau, mais il est basé sur des commandes shell et ssh, ce qui pourrait séduire les administrateurs système traditionnels.
• Chef : Peut-être que leur problème est le style déclaratif, auquel cas Chef serait mieux s'ils ont de l'expérience en Ruby.
• SaltStack : Basé sur Python, et open-source
• CFEngine : ancien, rapide, traditionnel -- cela pourrait les convaincre sur ces points.

J'ai utilisé Puppet pendant un peu plus de deux ans dans de petites entreprises où j'étais le seul administrateur système. Le plus grand obstacle que j'ai rencontré est d'apprendre à développer correctement des logiciels. Il n'y avait pas une semaine où je n'avais pas commis une erreur que j'avais demandé aux développeurs de ne pas faire une douzaine de fois. J'ai trop vérifié de code, je n'ai pas fractionné les validations, je n'ai pas tagué, je n'ai pas branché, je n'ai pas exécuté le vérificateur de syntaxe, je n'ai pas utilisé de standard, etc. Si vous débutez, je recommanderais ce qui suit.

1. Reconnaissez que vous développez des logiciels que vous ne savez pas faire ou que vous faites mal. C'est normal car c'est nouveau.
2. L'infrastructure en tant que code est une réalité et une fois que vous avez compris le fonctionnement, c'est très puissant. J'inviterais quelques développeurs, leur montrerais votre processus de développement actuel (ou son absence), ne vous offusquez pas lorsqu'ils froncent les sourcils, et prenez leurs suggestions au sérieux. Je recommande d'utiliser le système et le processus que vos développeurs utilisent, sauf s'ils sont totalement inappropriés.
3. Les modules tiers de Puppet sont souvent médiocres à 90%. Je les lirais. Je volerais des idées chez eux. Je ne les incorporerais pas dans mon système sans modifications majeures. Cependant, j'incorporerais le stdlib de puppet qui ajoute des fonctionnalités intéressantes.
4. augeas et hiera. Apprenez ces deux-là. Le premier permet une édition complexe des fichiers existants sur place. Le deuxième est un magasin de données externe.
5. Séparez le code des données. Ceci est l'un des concepts les plus difficiles à apprendre. Entrer des valeurs en dur comme les hôtes de surveillance dans le code de votre module est mauvais. Les mettre dans un magasin de données (base de données, yaml (Hiera l'utilise par défaut), csv, peu importe) que vos modules peuvent consommer est bon. Un exemple est une application web qui utilise Mysql. Ce que cela permet, c'est de pouvoir pousser le code et les données séparément. Cela rend votre processus de développement plus simple.
6. validate le parser puppet et puppet-lint comme partie de votre processus de validation de code pré ou post. Les tests rspec pourraient également être une bonne idée une fois que vous êtes à l'aise.
7. écrivez un guide de style / un standard de code et utilisez-le. "Où se trouve le code qui installe Apache" est un problème courant. Si vos modules sont principalement les mêmes, cela devrait être facile.

En résumé, j'ai rencontré tous ces problèmes et la plupart de mes amis administrateurs système aussi. Il faudra un certain temps pour devenir bon en utilisant un système de gestion de configuration. Une fois que vous l'aurez fait, vous vous demanderez comment vous avez pu vivre sans. "Se connecter à un serveur et apporter des modifications manuellement ? Beurk."

Il y a six mois, dans notre projet à but non lucratif, nous avons décidé de commencer à migrer notre gestion système vers un environnement contrôlé par Puppet car nous prévoyons une augmentation substantielle du nombre de serveurs entre maintenant et d'ici un an.

Cela semble être une très bonne idée de commencer tôt - Puppet est plus que simplement une gestion de configuration, c'est une forme de documentation.

Depuis que la décision a été prise, nos informaticiens sont devenus un peu trop agacés un peu trop souvent.

Ils ont besoin d'un ajustement d'attitude.

"Nous ne sommes pas des programmeurs, nous sommes des administrateurs système";

Encore une fois, l'attitude. Vous -pouvez- créer un fichier de configuration pour un serveur, n'est-ce pas ? Vous pouvez vous habituer à la templating/'programmation' au fur et à mesure que vos besoins et votre complexité évoluent.

Des modules sont disponibles en ligne mais beaucoup d'entre eux diffèrent les uns des autres; les roues sont réinventées trop souvent, comment décider lequel répond à vos besoins;

C'est difficile à répondre - je préfère toujours les modules de puppetlabs à la plupart des autres - et même à cela, je n'en utilise pas beaucoup. C'est définitivement à vous de juger. À mon avis, certains modules sont 'trop élaborés'.

Le code dans notre dépôt n'est pas assez transparent, pour comprendre comment quelque chose fonctionne, ils doivent parcourir en récursif les manifests et les modules qu'ils ont peut-être même écrits eux-mêmes il y a un certain temps;

Cela ne semble pas être un problème de Puppet, mais plutôt un problème d'organisation ou de documentation, non?

Un nouveau démon nécessite l'écriture d'un nouveau module, les conventions doivent être similaires aux autres modules, un processus difficile;

Ce démon pourrait être une classe s'il est assez simple à gérer. Je ne suis pas sûr de ce que vous entendez par conventions, Puppet n'impose-t-il pas déjà des conventions sur vous? Ou parlons-nous de formatage du code?

"Laissez juste tourner et voyons comment cela fonctionne"

Pas une si mauvaise idée si vous allez doucement et en toute sécurité. Je commencerais quand même par une machine virtuelle pour avoir une idée des choses.

Des tonnes d''extensions' à peine connues dans les modules communautaires: 'trocla', 'augeas', 'hiera'... comment nos administrateurs système peuvent-ils s'y retrouver?

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, modules perl.. Choisissez ce que vous voulez et utilisez-le ? Je pense que cela ressemble encore une fois à une question d'attitude...

Je comprends pourquoi une grande organisation enverrait ses administrateurs système suivre des cours Puppet pour devenir des maîtres Puppet. Mais comment les petits acteurs pourraient-ils apprendre Puppet à un niveau professionnel s'ils ne suivent pas de cours et apprennent essentiellement via leur navigateur et leur éditeur?

Je n'ai suivi aucun cours - bien que je sois plus un programmeur qu'un administrateur système, je trouve qu'il n'est pas nécessaire d'avoir de grandes compétences en programmation pour accomplir quoi que ce soit.

La documentation de Puppet, lorsqu'elle est suivie, est assez complète. Faites attention aux types intégrés et passez du temps à regarder comment les autres modules sont assemblés. Je ne dirais pas que c'est -super- facile, mais ce n'est pas -difficile- non plus. Il faut un peu de temps pour préparer votre infrastructure pour Puppet, mais le temps investi est assuré d'être bien dépensé lorsque vous vous développez.

KISS (Keep it simple stupid) - Ne pas utiliser de nouvelles technologies juste parce qu'elles existent, mais plutôt parce que vous en avez besoin, utilisez le strict minimum que votre déploiement nécessite, mettez à jour comme nécessaire sans essayer de suivre la dernière tendance. Si vous commencez par une configuration de base et que vous construisez à partir de celle-ci, il est plus facile de s'adapter au fur et à mesure, et ils ne devraient pas avoir besoin d'une formation (sont-elles même disponibles ?).

L'autre domaine sur lequel vous pouvez vous pencher concerne vos administrateurs système. S'ils ne peuvent pas non plus programmer, sont-ils assez avancés pour un déploiement de grande envergure, où la plupart du travail doit être scripté quelles que soient les outils utilisés ?