Comment les petits gars peuvent-ils apprendre et utiliser efficacement Puppet?
Il y a six mois, dans notre projet à but non lucratif, nous avons décidé de commencer à migrer notre gestion de système vers un environnement contrôlé par Puppet parce que nous prévoyons que notre nombre de serveurs augmentera considérablement d'ici un an.
Depuis que la décision a été prise, nos informaticiens sont devenus un peu trop agacé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; les roues sont réinventées trop souvent, comment décidez-vous laquelle correspond au projet de loi;
- Le code dans notre référentiel n'est pas suffisamment transparent, pour trouver comment quelque chose fonctionne, ils doivent recurer à travers des manifestes et des modules qu'ils auraient peut-être même écrits il y a quelque temps;
- Un nouveau démon nécessite l'écriture d'un nouveau module, les conventions doivent être similaires aux autres modules, un processus difficile;
- "Disons simplement l'exécuter et voir comment cela fonctionne"
- Des tonnes d '"extensions" à peine connues dans les modules communautaires: "trocla", "augeas", "hiera" ... comment nos administrateurs système peuvent-ils suivre?
Je peux voir pourquoi une grande organisation enverrait ses administrateurs système aux cours de marionnettes pour devenir des maîtres de marionnettes. Mais comment les petits joueurs pourraient-ils apprendre Puppet à un niveau professionnel s'ils ne vont pas aux cours et l'apprennent essentiellement 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, donc en quelques semaines, j'ai pu comprendre les bases et mettre en place un cadre de production. Je n'étais pas nouveau dans la gestion de configuration, ayant un arrière-plan CFEngine , mais plusieurs des préoccupations de vos administrateurs système résonnent. J'ai fait des erreurs et j'ai dû refaçonner plusieurs fois, mais j'ai réussi à faire fonctionner les choses de manière satisfaisante.
Quelques notes sur vos points ...
Le rôle traditionnel d'administration des systèmes est en train de changer. Adaptez-vous ou laissez-vous distancer. J'ai été un ingénieur système performant, mais je dois également me réorganiser (apprentissage de Python, par exemple). L'accent mis sur les serveurs individuels diminue à mesure que l'abstraction matérielle via la virtualisation et les services de cloud public et privé gagnent du terrain. Cela signifie l'automatisation des tâches des systèmes et l'utilisation de la gestion de la configuration pour prendre le contrôle d'un plus grand nombre de serveurs. Ajoutez concepts DevOps au mélange, et vous verrez que attentes des clients/utilisateurs finaux et les exigences changent.
Les modules de marionnettes disponibles en ligne diffèrent par leur style et leur structure et oui, j'ai vu beaucoup de chevauchements, de redondances et d'efforts dupliqués. Un développeur avec qui j'ai travaillé a déclaré: "Vous auriez pu développer vos propres outils pendant le temps que vous avez passé à chercher en ligne quelque chose qui fonctionne!" Cela m'a donné une pause car je me suis rendu compte que Puppet semble plaire davantage aux types de développeurs qu'aux administrateurs cherchant une meilleures pratiques ou la bonne approche .
Documentez abondamment afin d'avoir une idée de la façon dont les choses sont connectées. Étant donné les définitions chancelantes et le manque d'une manière standard de faire les choses, votre structure de gestion de configuration est vraiment unique à votre environnement. Cette transparence devra être développée à l'intérieur.
Je dirais qu'il est raisonnablement facile de dupliquer un module pour accueillir un nouveau démon ou d'ajouter un service à un manifeste existant, selon la façon dont vous avez organisé vos serveurs et rôles.
J'ai passé beaucoup de temps à tester sur une seule cible avant de proposer des modifications à de plus grands groupes de serveurs. L'exécution de marionnettes à 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 combien je dépendrais des modules communautaires. Je devais commencer à utiliser Augeas pour certains travaux , et déplorais le fait que c'était une fonctionnalité que je tenais pour acquise dans CFEngine.
Dans l'ensemble, j'ai l'impression qu'il n'y a pas de norme bien définie en ce qui concerne Puppet. J'ai eu du mal à comprendre comment organiser la structure de répertoires sur mon Puppetmaster, à comprendre comment gérer la signature des certificats, à mettre DNS inverse approprié en place partout, à faire évoluer Puppet de manière appropriée pour le environnement et comprendre quand tirer parti des modules communautaires par rapport à la construction du mien. C'est un changement de pensée et je vois comment cela pourrait paniquer un administrateur système. Cependant, c'était aussi une solution construite à partir de zéro, j'ai donc eu le luxe d'évaluer les outils. La décision de suivre cette voie était basée sur la mentalité et l'élan derrière Puppet. Cela valait la peine d'apprendre quelque chose de nouveau.
Rappelez-vous, ce site est également une bonne ressource.
Lors d'un travail précédent, on m'a confié la tâche de faire une implémentation pilote de Puppet. Maintenant, j'ai une formation 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 avec les paradigmes non traditionnels ont également des problèmes avec Puppet, car Puppet est déclarative , non impérative. En ce sens, Puppet fonctionne à peu près comme n'importe quel fichier de configuration: vous dites comment les choses devraient être, et Puppet s'occupe du reste.
Après le pilote, j'ai eu l'occasion de former une douzaine d'autres administrateurs avec Puppet, ainsi que de faire des présentations à ce sujet dans deux événements. Ma prise de cette expérience est que certains administrateurs y ont pris part, et d'autres non. Ce sont tous des administrateurs traditionnels, sans compétences en programmation et à différents niveaux d'expertise.
Une chose particulière que j'ai remarquée est que Puppet nécessite une pratique constante . Les gens qui ont été formés, ont écrit des modules, puis ont passé un mois ou deux à faire autre chose sont revenus à Puppet avec peu de compétences utiles. Les gens qui continuaient à y 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 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 vraiment avoir les compétences nécessaires pour le faire.
Là encore, si Puppet leur était imposé d'en haut, ils pourraient simplement réagir à ce qu'ils perçoivent comme une gestion qui s'immisce dans la façon dont ils font leur travail - ce qui serait assez vrai, en fait. Il pourrait être le cas de les laisser choisir quel système de gestion de configuration utiliser améliorerait les choses. Voici quelques alternatives:
- ANSIBLE : Ceci est nouveau, mais il est basé sur les commandes Shell et ssh, ce qui pourrait l'attirer vers les administrateurs système traditionnels.
- Chef : Peut-être que leur problème est le style déclaratif, auquel cas Chef serait mieux s'ils avaient une expérience Ruby.
- SaltStack : basé sur Python et open-source
- CFEngine : vieux, rapide, traditionnel - il pourrait les gagner sur ces terrains.
J'utilise Puppet depuis un peu plus de deux ans dans de petites boutiques où j'étais le seul administrateur système. Le plus gros obstacle que j'ai eu est d'apprendre à développer correctement un logiciel. Il ne s'est pas écoulé une semaine où je n'ai pas foiré quelque chose que j'ai dit aux développeurs de ne pas faire une douzaine de fois. J'ai archivé trop de code, je n'ai pas interrompu les enregistrements, je n'ai pas tagué, je n'ai pas créé de branche, je n'ai pas exécuté le vérificateur de syntaxe, je n'ai pas utilisé de norme, etc. Je recommanderais certains des éléments suivants.
- Sachez que vous développez un logiciel que vous ne savez pas comment faire ou que vous faites mal. Cela est attendu car c'est nouveau.
- L'infrastructure en tant que code est la réalité et une fois que vous avez surmonté la bosse, elle est assez puissante. J'inviterais certains développeurs à venir, leur montrer votre processus de développement actuel (ou son absence), ne pas vous offenser lorsqu'ils haussent les sourcils et prendre leurs suggestions au sérieux. Je recommanderais d'utiliser n'importe quel système et processus que vos développeurs utilisent, sauf s'il est complètement inapproprié.
- Les modules tiers de marionnettes sont nuls dans 90% des cas. Je les avais lus. Je leur volerais des idées. Je ne les intégrerais pas à mon système sans modifications majeures. Cependant, je tirerais la marionnette stdlib qui ajoute de belles fonctionnalités.
- augeas et hiera. Apprenez ces deux-là. Le premier permet une édition complexe des fichiers existants en place. Le second est un magasin de données externe.
- Séparez le code des données. C'est l'un des concepts les plus difficiles à apprendre. Les valeurs de codage en dur comme Monitoring Hosts dans le code de votre module sont incorrectes. Les placer dans un magasin de données (db, yaml (Hiera l'utilise par défaut), csv, peu importe) que vos modules peuvent consommer est une bonne chose. Un exemple est une webapp qui utilise Mysql. Cela permet de pousser le code et les données séparément. Cela rend votre processus de développement plus simple.
- l'analyseur de marionnettes valide et puppet-lint dans le cadre de votre processus de vérification du code pré ou post. Les tests rspec peuvent également être une bonne idée une fois que vous êtes au courant.
- rédiger un guide de style/code standard et l'utiliser. "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, tout comme 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 le ferez, vous vous demanderez comment vous avez pu vivre sans. "Connectez-vous à un serveur et apportez des modifications manuellement? Ick."
Il y a six mois, dans notre projet à but non lucratif, nous avons décidé de commencer à migrer notre gestion de système vers un environnement contrôlé par Puppet parce que nous prévoyons que notre nombre de serveurs augmentera considérablement d'ici un an.
Cela ressemble à une sacrée 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 agacés un peu trop souvent.
Ils ont besoin d'un ajustement d'attitude.
"We're not programmers, we're sysadmins";
Encore une fois, l'attitude. Vous -pouvez- faire un fichier conf pour un serveur non? Vous pouvez vous familiariser avec les modèles/"programmeur" selon vos besoins et votre complexité évolue.
Les modules sont disponibles en ligne mais beaucoup diffèrent les uns des autres; les roues sont réinventées trop souvent, comment décidez-vous laquelle correspond au projet de loi;
Difficile à répondre - je préfère toujours les modules puppetlabs à la plupart - et même à cela, je n'en utilise pas autant. Le jugement appelle à coup sûr. À mon avis, certains modules sont "trop froufrous".
Le code dans notre référentiel n'est pas suffisamment transparent, pour trouver comment quelque chose fonctionne, ils doivent recurer à travers des manifestes et des modules qu'ils auraient peut-être même écrits 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 aux autres modules, un processus difficile;
Ce démon pourrait être une classe s'il est assez simple à gérer. Je ne sais pas ce que vous entendez par conventions, la marionnette vous applique assez bien les conventions, n'est-ce pas? Ou parlons-nous le long du formatage du code?
"Let's just run it and see how it works"
Ce n'est pas une si mauvaise idée si vous la prenez lentement et en toute sécurité. Je commencerais toujours par un VM pour obtenir l'essentiel des choses.
Des tonnes d '"extensions" à peine connues dans les modules communautaires: "trocla", "augeas", "hiera" ... comment nos administrateurs système peuvent-ils suivre?
postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, Perl, Perl modules .. Choisissez ce que vous voulez et utilisez-le? Je suppose que cela ressemble plus à une chose d'attitude ...
Je peux voir pourquoi une grande organisation enverrait ses administrateurs système aux cours de marionnettes pour devenir des maîtres de marionnettes. Mais comment les petits joueurs pourraient-ils apprendre Puppet à un niveau professionnel s'ils ne vont pas aux cours et l'apprennent essentiellement via leur navigateur et leur éditeur?
Je n'ai suivi aucun cours - alors que je suis un programmeur plus qu'un administrateur système, j'ai trouvé qu'il n'avait pas besoin de beaucoup de compétences en programmation pour accomplir quoi que ce soit.
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 -hard- non plus. Préparer votre infrastructure pour la marionnette prend un peu de temps, mais le temps investi est assuré d'être bien dépensé lorsque vous vous développez.
Je travaille également pour un organisme à but non lucratif et j'ai été initialement chargé d'apporter les boîtes Linux en interne et peu de temps après Puppet pour les gérer. Il y a quelques choses spécifiques que nous avons faites qui ont vraiment aidé à 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 grand utilitaire tiers que j'utilise est le module de 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 modèle et gardons la gestion des fichiers, le package, les services, etc. tous normalisés à partir de ce modèle.
Deuxièmement, après avoir normalisé l'utilisation des modules intégrés, nous avons commencé à utiliser Git et Atlassian's Crucible - gratuit pour les organisations à but non lucratif, soit dit en passant - pour effectuer des révisions de tous les changements 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 existe plusieurs façons de résoudre ce problème. Comme j'avais déjà un environnement Kickstart complet, j'ai choisi d'y ajouter un script.
KISS (Keep it simple stupid) - N'utilisez pas de nouvelles technologies simplement parce qu'elles sont là plutôt 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 saignement Bord. Si vous commencez avec une configuration de base et que vous en tirez parti, il est plus facile de les reprendre au fur et à mesure, et ils ne devraient pas avoir besoin d'un cours (sont-ils même disponibles?).
L'autre domaine que vous pouvez examiner sont vos administrateurs système. S'ils ne peuvent pas programmer aussi bien, sont-ils suffisamment avancés pour un déploiement à grande échelle, où la plupart du travail doit être scripté quels que soient les outils que vous utilisez?
"Nous ne sommes pas des programmeurs, nous sommes des administrateurs système"
Ma façon dont les temps ont changé, pour le pire: une barbe grise comme moi devait être un meilleur programmeur que des programmeurs professionnels, sinon elle n'aurait jamais pu à passer pour un administrateur système .
Maintenant, nous avons des "administrateurs système", qui sont essentiellement des utilisateurs de bureau Windows qui à un moment donné se sont convertis à Linux et ne peuvent pas programmer, et ne trouvent rien de mal à cela.
L'éléphant dans la pièce est la raison pour laquelle la direction tolère une attitude aussi destructrice. Destructeur pour qui ou quoi? À l'entreprise et à l'infrastructure.
Retour à Puppet [ CFEngine, Chef] sujet: dès qu'on met une solution comme ça dans, on perd. Tout le monde y perd. Pourquoi? Parce que celui qui a l'idée n'est pas capable de concevoir une gestion de configuration encapsulée sous la forme de packages de système d'exploitation Nice, propre, Kickstart [ JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM]. Lorsque vous devez utiliser un outil de piratage automatisé comme Puppet (ou Chef, ou CFEngine), cela signifie que vous n'avez pas les moyens de concevoir et de implémente un processus qui, par cette même conception, imposerait des systèmes gérés parfaitement vierges et totalement éteints, entièrement automatisés et totalement non interactifs.
Un autre point important est, si vous devez avoir Puppet ou une telle solution pour corriger quelqu'un piratage configuration système ou application à la main , cela revient également à ne pas avoir l'expérience de concevoir un processus, et dans ce processus un cadre où la configuration est empaquetée dans des composants discrets. En effet, quiconque implémente Puppet et similaires, n'a aucun concept de propriétaires de composants, de versions, de gestion de 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 d'outils système par défaut. "
Pourquoi est-ce Ruby nécessaire, quand une gestion complète de la configuration de bout en bout peut être encapsulée dans les sections préinstallation, postinstallation, pré-suppression et post-suppression des packages du système d'exploitation, simplement en utilisant les programmes Bourne Shell, AWK Que quelqu'un irait jusqu'à apprendre une langue ésotérique de Ruby, et un dialecte de celui-ci dans le contexte de Puppet, est complètement inutile. Le problème de la gestion de la configuration est facilement résoluble (et à savoir, a été résolu) avec les programmes Shell et AWK, et un peu sed (1) ici et là comme colle.
C'est un sentiment génial de voir votre manifeste Puppet configurer une machine entière ou un nouveau service à partir de zéro.
C'est encore plus cool de le voir fait par Kickstart, AutoYaST ou JumpStart, sans une seule ligne de code , et pouvoir interroger le système d'exploitation en utilisant des outils intégrés, sans avoir besoin de logiciel ésotérique ou supplémentaire , aucune architecture client-serveur requise (SSH est plus que bien, bien plus que bien), et de voir votre système d'exploitation conscient de chaque modification qui y est apportée.
5. code séparé des données. C'est l'un des concepts les plus difficiles à apprendre. Les valeurs de codage en dur comme Monitoring Hosts dans le code de votre module sont incorrectes. Les placer dans un magasin de données (db, yaml (Hiera l'utilise par défaut), csv, peu importe) que vos modules peuvent consommer est une bonne chose. Un exemple est une webapp qui utilise Mysql. Cela permet de pousser le code et les données séparément. Cela rend votre processus de développement plus simple.
... Ou vous pouvez simplement modèle vos fichiers de configuration avec des variables Shell, même des guillemets (par exemple ls -1 ...) et écrire un script Shell qui utilise AWK pour appeler eval (1) et développer toutes les variables dans le modèle, exploitant ainsi exactement le même analyseur puissant que les shells ont intégré. Pourquoi le rendre complexe alors qu'il peut être vraiment, vraiment simple? Où allez-vous stocker les valeurs de configuration? Pourquoi, n'importe où, comme par exemple les fichiers pkginfo (4), ou une base de données comme Oracle, ou à peu près n'importe où . Pas besoin de solutions ultra-complexes. La bibliothèque que je mentionne ci-dessus pourrait simplement provenir des sections préinstallées ou postinstallées dans les packages du système d'exploitation, supprimant ainsi la duplication et exploitant un morceau de code central. ..
Mais surtout, je trouve que la citation ci-dessus est un exemple de la prochaine génération d'administrateurs système nécessitant un tutorat non pas par les administrateurs système, mais par ingénieurs système . Trouvez-vous une barbe grise et connectez-vous en tant qu'apprenti.