Comment les petits gars peuvent-ils apprendre et utiliser efficacement Puppet? [fermé]

Il y a six mois, dans le cadre de notre projet à but non lucratif, nous avons décidé de commencer à migrer la gestion de nos systèmes vers un environnement contrôlé par Puppet, car nous nous attendons à ce que notre nombre de serveurs augmente considérablement d'ici à un an.

Depuis que la décision a été prise, nos informaticiens sont devenus un peu trop énervés, un peu trop souvent. Leurs plus grandes objections sont:

• "Nous ne sommes pas des programmeurs, nous sommes des administrateurs système";
• Les modules sont disponibles en ligne mais beaucoup diffèrent les uns des autres; On réinvente trop souvent les roues, comment décider laquelle convient le mieux?
• Le code dans notre référentiel n'est pas assez transparent pour trouver comment fonctionne quelque chose, ils doivent récidiver à travers des manifestes et des modules qu'ils auraient même écrits eux-mêmes il y a quelque temps;
• Un nouveau démon nécessite l'écriture d'un nouveau module, les conventions doivent être similaires à celles des autres modules, ce qui est un processus difficile.
• "Lançons-le et voyons comment ça marche"
• Des tonnes d'extensions à peine connues dans les modules de la communauté: 'trocla', 'augeas', 'hiera' ... comment nos administrateurs système peuvent-ils garder la trace?

Je peux voir pourquoi une grande organisation enverrait ses administrateurs système à des cours de marionnettes pour devenir des maîtres de marionnettes. Mais comment les plus petits joueurs pourraient-ils apprendre Puppet à un niveau professionnel s’ils ne suivent pas de cours et ne l’apprennent pas en gros via leur navigateur et leur éditeur?

J'ai commencé à utiliser Puppet avant de déployer une nouvelle infrastructure et j'ai simplement acheté un livre ( bien considéré ) sur le sujet. Je ne pense pas que la plupart des gens obtiennent une formation professionnelle en marionnettes. J'ai travaillé sur des exemples jusqu'à ce que je puisse adapter le processus à mon environnement. C'était en décembre 2011, alors en quelques semaines, j'ai été capable de comprendre les bases et de mettre en place un cadre de production. Je ne connaissais pas bien la gestion de la configuration, je connais bien CFEngine , mais bon nombre des préoccupations de vos administrateurs système résonnent. J'ai fait des erreurs et j'ai dû refacturer plusieurs fois, mais j'ai réussi à faire fonctionner les choses de manière satisfaisante.

Quelques notes sur vos points ...

• Le rôle traditionnel de l'administration des systèmes est en train de changer. Adapter ou être laissé pour compte. Je suis un ingénieur système performant, mais je dois également me réoutiller (apprendre Python, par exemple). L'accent mis sur les serveurs individuels est réduit au fur et à mesure que l'abstraction matérielle via la virtualisation et les services de cloud public et privé gagnent en popularité. Cela implique une automatisation des tâches du système et l’utilisation de la gestion de la configuration pour contrôler un plus grand nombre de serveurs. Ajoutez des concepts DevOps à la combinaison et vous verrez que les attentes et les exigences du client / utilisateur final changent.

• Les modules de marionnettes disponibles en ligne diffèrent par leur style et leur structure et, oui, j’ai constaté de nombreux chevauchements, redondances et redondances. Un développeur avec lequel j'ai travaillé a déclaré: "Vous auriez pu développer vos propres outils en passant du temps à chercher en ligne quelque chose qui fonctionne!" Cela me donna une pause lorsque je réalisai que Puppet semblait intéresser davantage les développeurs que les administrateurs cherchant des pratiques optimales ou la bonne approche.

• Documenter beaucoup afin d'avoir une idée de la façon dont les choses sont connectées. Compte tenu des définitions incertaines et de l’absence de méthode standard , votre structure de gestion de la configuration est vraiment unique pour votre environnement. Cette transparence devra être développée au sein de.

• Je dirais qu'il est relativement facile de dupliquer un module pour accueillir un nouveau démon ou ajouter un service à un manifeste existant, en fonction de la manière dont vous avez organisé vos serveurs et vos rôles.

• J'ai passé beaucoup de temps à tester une seule cible avant de transmettre les modifications à des groupes de serveurs plus importants. Faire fonctionner puppetd à la main sur un serveur représentatif m'a permis de déboguer les modifications et d'évaluer leur impact. C'est peut-être un peu conservateur, mais c'était nécessaire.

• Je ne sais pas à quel point je dépends de modules communautaires. J'ai dû commencer à utiliser Augeas pour certains travaux et j'ai déploré le fait que c'était une fonctionnalité que je prenais pour acquise dans CFEngine.

Dans l’ensemble, j’ai le sentiment qu’il n’existe pas de norme bien définie en matière de marionnettes. J'ai eu du mal à comprendre comment organiser la structure de répertoires sur mon maître Puppet , comprendre comment gérer la signature de certificat, mettre en place le bon DNS inversé partout, faire en sorte que Puppet s'adapte correctement à l'environnement et comprenne quand exploiter les modules de la communauté plutôt que de construire le mien. C'est un changement de mentalité et je vois comment une telle panique se produirait. Cependant, c'était aussi une solution construite à partir de zéro, j'ai donc eu le luxe d'évaluer des outils. La décision d’aller dans cette direction était basée sur l’esprit partagé et sur l’élan derrière Puppet. Cela valait la peine d'apprendre quelque chose de nouveau.

N'oubliez pas que ce site est également une bonne ressource.

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

Cependant, il est intéressant de noter que les programmeurs sans expérience des paradigmes non traditionnels ont également un problème avec Puppet, car Puppet est déclaratif et non impératif. En ce sens, Puppet fonctionne à peu près comme n'importe quel fichier de configuration: vous dites comment les choses devraient se passer et Puppet se charge du reste.

Après le pilote, j’ai eu l’occasion de former une douzaine d’administrateurs avec Puppet et de faire des présentations à ce sujet lors de deux événements. Ce que je retiens de cette expérience, c’est que certains administrateurs l’ont prise, d’autres non. C'étaient tous des administrateurs traditionnels, sans compétences en programmation et avec différents niveaux d'expertise.

Une chose que j'ai remarquée, c'est que Puppet nécessite une pratique constante . Les personnes formées ont écrit des modules, puis passé un mois ou deux à faire autre chose, sont revenues à Puppet avec peu de compétences utiles. Les gens qui continuaient à faire de petites choses chaque semaine n'y perdaient jamais cette possibilité.

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 de marionnettes chaque semaine (de préférence au moins deux ou trois fois). Ceux qui ne peuvent toujours pas s'y habituer pourraient ne pas avoir les compétences nécessaires pour le faire.

Encore une fois, si Puppet leur était imposée d'en haut, ils pourraient simplement réagir à ce qu'ils perçoivent comme une gestion empiétant sur la façon dont ils effectuent leur travail - ce qui serait assez vrai, en fait. Il pourrait être le cas que les laisser choisir qui système de gestion de configuration à utiliser améliorerait les choses. Voici quelques alternatives:

• ANSIBLE : Ceci est nouveau, mais il est basé sur des commandes shell et ssh, ce qui pourrait l’attirer chez les administrateurs systèmes traditionnels.
• Chef : Peut-être que leur problème est un style déclaratif, auquel cas Chef serait mieux s’ils avaient l’expérience Ruby.
• SaltStack : basé sur Python et open-source
• CFEngine : vieux, rapide, traditionnel - il pourrait les convaincre pour ces raisons.

J'utilise Puppet depuis un peu plus de deux ans dans de petits magasins où j'étais le seul administrateur système. Le plus gros obstacle que j'ai eu à apprendre est d'apprendre à développer des logiciels correctement. Il ne s’est pas passé une semaine au cours de laquelle je n’ai pas foiré quelque chose que j’avais dit aux développeurs de ne pas faire douze fois. J'ai enregistré trop de code, je n'ai pas cassé les checkins, je n'ai pas tagué, je n'ai pas créé de branche, je n'ai pas exécuté de vérificateur de syntaxe, je n'ai pas utilisé de norme, etc. Si vous venez juste de commencer sur je recommanderais certaines des choses suivantes.

1. Réalisez que vous développez un logiciel que vous ne savez pas faire ou que vous faites mal. Ceci est attendu parce que c'est nouveau.
2. L'infrastructure en tant que code est la réalité et une fois que vous avez surmonté la bosse, c'est assez puissant. J'inviterais certains développeurs, leur montrerais votre processus de développement actuel (ou leur absence), ne vous fâchez pas lorsqu'ils lèvent les sourcils et prenez leurs suggestions au sérieux. Je recommanderais d'utiliser le système et le processus que vos développeurs utilisent, à moins que cela ne soit complètement inapproprié.
3. Les modules tiers de Puppet sont sucés 90% du temps. Je les lisais. Je leur volais des idées. Je ne les attirerais pas dans mon système sans modifications majeures. Cependant, je tirerais la marionnette stdlib qui ajoute quelques fonctionnalités intéressantes.
4. augeas et hiera. Apprenez ces deux. Le premier permet l'édition complexe de fichiers existants en place. Le second est un magasin de données externe.
5. Séparez le code des données. C'est l'un des concepts les plus difficiles à apprendre. Les valeurs codées en dur, telles que la surveillance des hôtes dans le code de votre module, sont mauvaises. Les placer dans un magasin de données (db, yaml (que Hiera utilise par défaut), csv, peu importe) que vos modules peuvent consommer est bon. Un exemple est une application Web qui utilise Mysql. Cela permet de pousser le code et les données séparément. Cela simplifie votre processus de développement.
6. analyseur de marionnettes valider et puppet-lint dans le cadre de votre processus d’archivage avant ou après le code. Des tests rspec peuvent également être une bonne idée une fois que vous êtes au courant.
7. écrivez un code / guide de style et utilisez-le. "où est le code qui installe Apache" est un problème courant. Si vos modules sont généralement les mêmes, cela devrait être facile.

En résumé, j'ai rencontré tous ces problèmes, de même que la plupart de mes amis administrateurs système. Il faudra un certain temps pour bien utiliser un système de gestion de configuration. Une fois que vous avez fait, vous vous demanderez comment vous avez vécu sans un. "Connectez-vous à un serveur et effectuez les modifications manuellement? Ick."

Il y a six mois, dans le cadre de notre projet à but non lucratif, nous avons décidé de commencer à migrer la gestion de nos systèmes vers un environnement contrôlé par Puppet, car nous nous attendons à ce que notre nombre de serveurs augmente considérablement d'ici à un an.

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

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

Ils ont besoin d'un ajustement d'attitude.

"We're not programmers, we're sysadmins";

Encore une fois, attitude. Vous pouvez créer un fichier de configuration pour un serveur, n'est-ce pas? Vous pouvez vous familiariser avec les modèles et les "programmeurs" à mesure que vos besoins et votre complexité évoluent .

Les modules sont disponibles en ligne mais beaucoup diffèrent les uns des autres; On réinvente trop souvent les roues, comment décider laquelle convient le mieux?

Difficile à répondre - je préfère toujours les modules puppetlabs à la plupart - et même à cela, je n'en utilise pas beaucoup. Jugement à coup sûr. À mon avis, certains modules sont «trop volumineux».

Le code dans notre référentiel n'est pas assez transparent pour trouver comment fonctionne quelque chose, ils doivent récidiver à travers des manifestes et des modules qu'ils auraient même écrits eux-mêmes il y a quelque temps;

Cela ne ressemble pas à un problème de marionnette, mais plutôt à un problème d’organisation ou de documentation?

Un nouveau démon nécessite l'écriture d'un nouveau module, les conventions doivent être similaires à celles des autres modules, ce qui est 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, marionnette vous impose assez bien les conventions, n'est-ce pas? Ou sommes-nous en train de parler de la mise en forme du code?

"Let's just run it and see how it works"

Ce n’est pas une si mauvaise idée si vous le prenez lentement et en sécurité. Je commencerais toujours par une machine virtuelle pour comprendre l'essentiel.

Des tonnes d'extensions à peine connues dans les modules de la communauté: 'trocla', 'augeas', 'hiera' ... comment nos administrateurs système peuvent-ils garder la trace?

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, modules perl .. Choisissez ce que vous voulez et utilisez-le? Je suppose que cela sonne plus comme une chose d'attitude à nouveau ...

Je peux voir pourquoi une grande organisation enverrait ses administrateurs système à des cours de marionnettes pour devenir des maîtres de marionnettes. Mais comment les plus petits joueurs pourraient-ils apprendre Puppet à un niveau professionnel s’ils ne suivent pas de cours et ne l’apprennent pas en gros via leur navigateur et leur éditeur?

Je n'ai suivi aucun cours - bien que je sois programmeur plus qu'un administrateur système, j'ai constaté qu'il ne nécessitait pas beaucoup de compétences en programmation pour que quelque chose soit accompli.

La documentation de Puppet, lorsqu'elle est suivie, est assez complète. Faites juste attention aux types intégrés et passez un peu de temps à regarder comment les autres modules sont assemblés. Je ne dirais pas que c'est super facile, mais ce n'est pas dur non plus. Préparer votre infrastructure pour la création de marionnettes prend un peu de temps, mais il est certain que le temps investi sera bien dépensé lorsque vous développerez votre infrastructure.

KISS (Keep it simple stupid) - N'utilisez pas les nouvelles technologies juste parce qu'elles existent, mais parce que vous en avez besoin, utilisez le strict minimum requis par votre déploiement, mettez à jour au besoin, n'essayez pas de suivre le rythme. bord. Si vous commencez avec une configuration de base et que vous vous appuyez sur cette dernière, il est plus facile de la récupérer au fur et à mesure, et ils ne devraient pas avoir besoin d'un cours (sont-ils même disponibles?).

Les autres domaines que vous pouvez regarder sont vos administrateurs système. S'ils ne peuvent pas également programmer, sont-ils suffisamment avancés pour un déploiement de grande envergure, où la majeure partie du travail doit être écrite avec les outils que vous utilisez?

Je travaille également pour un but non lucratif et j'étais responsable de la mise en place initiale des machines Linux, puis de la gestion de Puppet peu de temps après. Nous avons pris des mesures spécifiques qui ont vraiment contribué à faire avancer les choses.

Tout d’abord, j’ai essayé de rester à l’écart des modules tiers. Les outils intégrés gèrent 90% de notre gestion. Le plus gros utilitaire tiers que j'utilise est le module pare-feu. Tous les faits personnalisés, etc. sont développés avec toute l’équipe impliquée. Nous avons développé un module de gabarit et avons normalisé la gestion des fichiers, les packages, les services, etc.

Deuxièmement, après avoir normalisé l'utilisation des modules intégrés, nous avons commencé à utiliser Git et Atlassian's Crucible, gratuits pour les sociétés à but non lucratif, pour effectuer des analyses de toutes les modifications de configuration. Cela fournit la transparence souhaitée.

Troisièmement, j'ai automatisé la configuration de Puppet afin que de nouveaux hôtes puissent être ajoutés automatiquement avec un ensemble d'options par défaut. Il y a plusieurs façons de résoudre ce problème. Comme je disposais déjà d’un environnement complet Kickstart, j’ai choisi d’y ajouter un script.

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

La façon dont les temps ont changé a été pire: on s'attendait à ce qu'un gris comme moi soit un meilleur programmeur que les programmeurs professionnels, sans quoi il n'aurait jamais pu passer pour un administrateur système .

Nous avons maintenant des «administrateurs système», qui sont essentiellement des utilisateurs de bureau Windows qui ont été convertis à un moment donné sous Linux et qui ne peuvent pas programmer, et qui ne trouvent absolument aucun problème avec cela.

L’éléphant dans la pièce est la raison pour laquelle la direction tolère une telle attitude destructrice. Destructif à qui ou quoi? Pour l'entreprise et l'infrastructure.

Revenons à l’objet Puppet [, CFEngine, Chef]: dès que l’on installe une solution comme celle-ci, on perd. Tout le monde perd. Pourquoi? Parce que quiconque a eu cette idée n’est pas capable de concevoir une gestion de la configuration encapsulée sous forme de packages de système d’exploitation agréables et propres, Kickstart [, JumpStart, Installation automatisée, AutoYaST, Ignite-UX, NIM]. Lorsque vous devez utiliser un outil de piratage automatisé tel que Puppet (ou Chef ou CFEngine), vous ne disposez pas des moyens nécessaires pour concevoir et mettre en œuvre un processus qui, par cette même conception, imposerait des systèmes totalement gérés de manière totalement vierge et illimitée. automatisé et complètement non interactif.

Un autre point important est, si vous devez avoir des marionnettes ou d' une telle solution pour corriger quelqu'un de piratage du système ou la configuration de l' application à la main, qui remonte aussi à ne pas avoir l'expérience pour concevoir un processus, et dans ce processus un cadre dans lequel la configuration est emballé en composants discrets. En effet, quiconque implémente Puppet ou autre, n'a aucun concept de propriétaires de composants, de versions, de gestion de la configuration, de modèle de maturité de capacité. Cela devient rapidement un problème très grave dans l'industrie.

Travailler avec Puppet m'a également aidé à apprendre Ruby, qui est venu remplacer Bash comme langage par défaut pour mes outils système. "

Pourquoi Ruby est-il nécessaire, alors qu'une gestion complète de la configuration de bout en bout peut être encapsulée dans les sections preinstall, postinstall, preremove et posttremove des packages du système d'exploitation, en utilisant simplement les programmes Bourne Shell, AWK et sed? Il est absolument inutile que quelqu'un approfondisse l'apprentissage d'une langue ésotérique de Ruby et de son dialecte dans le contexte de Puppet. Le problème de la gestion de la configuration est facilement résolu (et a été résolu) avec les programmes shell et AWK, et un peu sed (1) ici et là comme une colle.

C'est un sentiment génial de voir votre manifeste de marionnettes configurer une machine complète ou un nouveau service à partir de zéro.

C’est encore plus cool de le faire avec Kickstart, AutoYaST ou JumpStart, sans une seule ligne de code , et d’interroger le système d’exploitation à l’aide d’outils intégrés, sans avoir besoin de logiciel ésotérique ou supplémentaire , sans client-serveur. l’architecture requise (SSH, c’est plus que bien, beaucoup plus que bien) et de voir votre système d’exploitation connaître chaque modification apportée.

5. code séparé des données. C'est l'un des concepts les plus difficiles à apprendre. Les valeurs codées en dur, telles que la surveillance des hôtes dans le code de votre module, sont mauvaises. Les placer dans un magasin de données (db, yaml (que Hiera utilise par défaut), csv, peu importe) que vos modules peuvent consommer est bon. Un exemple est une application Web qui utilise Mysql. Cela permet de pousser le code et les données séparément. Cela simplifie votre processus de développement.

... Ou vous pouvez simplement modéliser vos fichiers de configuration avec des variables shell, même des cotes en arrière (par exemple ls -1 ...) et écrire un script shell qui utilise AWK pour appeler eval (1) et développer toutes les variables du modèle, exploitant ainsi la même puissance puissante. analyseur dont les coquilles ont intégré. Pourquoi le rendre complexe, alors que cela peut être vraiment, vraiment simple? Où allez-vous stocker les valeurs de configuration? Pourquoi, n’importe où, par exemple des fichiers pkginfo (4), ou une base de données telle que Oracle, ou à peu près n’importe où . Pas besoin de solutions ultracomplexes. La bibliothèque que je mentionne ci-dessus pourrait simplement provenir des sections de pré-installation ou de post-installation des packages du système d'exploitation, supprimant ainsi la duplication et exploitant un élément de code central ...

Mais avant tout, je trouve que la citation ci-dessus est un exemple de la prochaine génération d’administrateurs système ayant besoin d’un tutorat, non pas d’administrateurs système, mais d’ ingénieurs système . Trouvez-vous un barbe et ouvrez une session en tant qu'apprenti.