"Nous ne sommes pas des programmeurs, nous sommes des administrateurs système"
Comme les temps ont changé, pour le pire : un barbu comme moi était attendu d'être un meilleur programmeur que des programmeurs professionnels, sinon 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 ont à un moment donné basculé vers Linux et ne peuvent pas programmer, et ne trouvent rien de mal à cela.
L'éléphant dans la pièce est pourquoi la direction tolère une telle attitude destructrice. Destructrice pour qui ou quoi? Pour l'entreprise et pour l'infrastructure.
Revenons au sujet de Puppet[, CFEngine, Chef] : dès qu'une solution comme celle-ci est mise en place, on perd. Tout le monde perd. Pourquoi? Parce que celui qui propose l'idée n'est pas capable de concevoir une gestion de configuration encapsulée sous forme de packages système Kickstart[, JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM] propres et bien organisés. Lorsque vous devez utiliser un outil de piratage automatisé comme Puppet (ou Chef, ou CFEngine), cela signifie que vous manquez de compétences pour concevoir et mettre en œuvre un processus qui, par ce même design, appliquerait des systèmes entièrement gérés, automatiques et non interactifs.
Un autre point important est que si vous devez avoir Puppet ou une telle solution pour corriger quelqu'un qui pirate la configuration du système ou de l'application à la main, cela revient également à ne pas avoir l'expérience nécessaire pour concevoir un processus, et dans ce processus un cadre où la configuration est emballée dans des composants distincts. En effet, celui qui met en œuvre Puppet et ses semblables, n'a aucune notion de propriétaires de composants, de versions, de gestion de configuration, de Modèle de Maturité des Capacités. Ce problème se propage rapidement dans l'industrie.
Travailler avec Puppet m'a également aidé à apprendre Ruby, qui a remplacé Bash comme mon langage de programmation système par défaut."
Pourquoi Ruby est-il nécessaire, alors qu'une gestion de configuration complète de bout en bout peut être encapsulée dans les sections preinst, postinst, prerm, et postrm des packages système, simplement en utilisant des programmes shell Bourne, AWK, et sed ? Que quelqu'un s'embarrasse à apprendre un langage ésotérique de Ruby, et un dialecte de celui-ci dans le contexte de Puppet, est totalement inutile. Le problème de la gestion de configuration est facile à résoudre (et de fait, il a été résolu) avec des programmes shell et AWK, et un peu de sed(1) ici et là en guise de colle.
C'est formidable de voir votre manifeste Puppet configurer une machine entière ou un nouveau service à partir de zéro.
C'est encore plus impressionnant de le voir fait par Kickstart, AutoYaST, ou JumpStart, sans une seule ligne de code, et de pouvoir interroger le système d'exploitation en utilisant les outils intégrés, sans avoir besoin de logiciels ésotériques supplémentaires, aucune architecture client-serveur requise (SSH est largement suffisant, bien plus que suffisant), et de voir votre système d'exploitation être conscient de chaque changement qui lui est apporté.
5. Séparez le code des données. Il s'agit de l'un des concepts les plus difficiles à apprendre. Inclure des valeurs telles que 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 la possibilité de pousser le code et les données séparément. Cela simplifie votre processus de développement.
...Ou vous pourriez simplement modéliser vos fichiers de configuration avec des variables shell, y compris des backquotes (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, en exploitant ainsi le même puissant analyseur dont disposent les shells en interne. Pourquoi compliquer les choses, alors qu'elles peuvent être vraiment, vraiment simples ? Où stockerez-vous les valeurs de configuration ? Eh bien, où bon vous semble, comme par exemple dans 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 être sourcée depuis les sections preinst ou postinst des packages système, éliminant ainsi la redondance et exploitant un morceau de code central...
Mais par-dessus tout, je trouve que la citation ci-dessus est un exemple de la prochaine génération d'administrateurs système ayant besoin d'être formée non pas par des administrateurs système, mais par des ingénieurs système. Trouvez-vous un barbu et engagez-vous comme apprenti.
