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.
puppetd -tpour tester sur quelques boîtes avant de transmettre à tous les serveurs. Il est toujours vrai qu'un couple a quelque chose d'unique qui provoque l'échec de ses mises à jour. La marionnette est beaucoup plus facile lorsque vous avez un environnement contrôlé et cohérent pour le début.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:
la source
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.
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."
la source
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.
Ils ont besoin d'un ajustement d'attitude.
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 .
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».
Cela ne ressemble pas à un problème de marionnette, mais plutôt à un problème d’organisation ou de documentation?
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?
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.
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 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.
la source
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?
la source
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.
la source
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.
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 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.
... 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.
la source