Nous avons mis en place un serveur qui exécute l'infrastructure pour une petite association. Jusqu'à présent, nous avons essayé de gérer la configuration avec Ansible, mais cela n'a pas été un grand succès. Peut-être que nous le faisons mal.
En principe, l'idée est que ce serveur sera laissé seul la plupart du temps, les gens ajoutant ou modifiant des choses une fois dans une lune bleue. Il est donc crucial que tout ce qui est configuré et exécuté sur le serveur soit bien documenté et clair, car les personnes qui n'administrent pas fréquemment le système perdront inévitablement la vue d'ensemble (sans parler des détails). De plus, au fil du temps, la composition du groupe de personnes qui administrera ce serveur changera (à mesure que les gens quittent et rejoignent le «comité»).
Nous avons commencé avec une installation propre, en ajoutant des rôles dans ansible chaque fois que nous voulions configurer quelque chose (nginx, phpfpm, postfix, pare-feu, sftp, munin, ..). Peut-être en raison de notre inexpérience, nous ne sommes bien sûr jamais en mesure de taper un ensemble de tâches ansibles exactement comme nous en avons besoin en une seule fois, également parce que la configuration est un peu un processus d'essai et d'erreur. Cela signifie que dans la pratique, nous configurons généralement d'abord le service que nous voulons exécuter sur le serveur , puis nous traduisons en tâches ansibles. Vous pouvez voir où cela va. Les gens oublient ensuite de tester la tâche, ou ont peur de le faire au risque de casser des choses, ou pire: on oublie ou néglige d'ajouter des choses à ansible.
Aujourd'hui, nous avons très peu de confiance que la configuration ansible reflète réellement ce qui est configuré sur le serveur.
Actuellement, je vois trois problèmes principaux:
- Il est difficile de (lire: nous n'avons pas un bon moyen de) tester des tâches ansibles sans risquer de casser des choses.
- Il ajoute du travail supplémentaire pour d'abord déterminer la configuration souhaitée, puis comprendre comment traduire cela en tâches ansibles.
- (Idéalement,) nous ne l'utilisons pas assez fréquemment pour développer la familiarité et la routine.
Une considération importante ici est que pour tout ce que nous finissons par faire, il devrait être facile pour les nouveaux arrivants d'apprendre les cordes sans une tonne de pratique.
Existe-t-il une alternative viable qui offre encore des garanties et des contrôles (comparables à la fusion de fichiers Ansible à certains master) que «configurer les choses et noter ce que vous avez fait» ne parvient pas à fournir?
EDIT: Nous avons envisagé de nous engager /etcà git. Existe-t-il un moyen raisonnable de protéger les secrets (clés privées, etc.) de cette façon, mais le dépôt de configuration est-il toujours disponible en dehors du serveur?
Bien qu'il existe d' autres problèmes (comme ne pas avoir un environnement de test), vous pouvez avoir une grande amélioration en ne faisant pas ce .
L'un des principaux objectifs de conception d' Ansible est d'être idempotent , ce qui signifie que l'exécution de votre playbook plusieurs fois ne devrait rien changer (sauf si vous avez modifié les jeux). Ainsi, lorsque je configure un nouveau logiciel, mes étapes sont les suivantes:
Si vous ne pensez pas que vous écrirez la bonne chose la première fois dans Ansible, écrivez-la quand même et répétez-la jusqu'à ce qu'elle soit correcte, comme tout autre code. Cela réduit considérablement les chances d'oublier à Ansiblize certaines modifications que vous avez apportées, car chaque modification que vous avez effectuée était déjà dans Ansible à un moment donné de votre processus de développement.
la source
Ansible a un temps de montée en puissance avant de dépasser votre niveau de productivité précédent, mais une fois que vous le faites, l'état de votre système est facile à assurer. Vos pratiques ne semblent pas synchronisées avec vos objectifs finaux. Vous pouvez être productif avec un ensemble d'outils CM, tout en conservant de bonnes pratiques d'ingénierie, mais il faut du temps pour le structurer correctement. Vous êtes essentiellement une efficacité commerciale et facile à implémenter, pour la stabilité et l'évolutivité de l'entreprise. De la même manière qu'un programmeur professionnel expérimenté n'écrit pas de vilains hacks, les conséquences l'emportent toujours sur les avantages.
Pour commencer, vous pouvez avoir trop de cuisiniers, sans propriété claire, si vous vous attendez à une tragédie des communs. Chaque priorité commerciale l'emportera à chaque fois sur les problèmes d'ingénierie système, à moins qu'elle ne soit largement désamorcée et que ce qui reste soit directement répercuté sur l'ingénieur responsable.
Un ensemble d'outils CM n'est pas capable d'être conçu par les administrateurs, c'est ce que je viens de réaliser. Ils peuvent réutiliser le travail existant, ou éventuellement s'étendre sur une base solide, mais même alors cela nécessiterait une quantité contraignante de mise en application des pratiques. Ce qu'un ingénieur peut faire n'est simplement PAS ce qu'un administrateur peut faire. De nombreux concepts dans Ansible sont presque les mêmes que dans une base de code, pouvez-vous enseigner à un administrateur Python et vous attendre à des résultats compétents? Non, certainement pas, je m'attendrais à un travail de piratage, vous devez donc rendre la tâche suffisamment structurée pour qu'un travail de piratage soit supportable.
Vous devez donc mettre les choses en place pour réussir, concevoir des solutions pour les points d'administration inutiles. Échangez la complexité des systèmes de bas niveau contre des choses qu'un administrateur pourrait réellement réussir. Un jeu d'outils CM ne vous évitera PAS de disparités architecturales ou de conception.
L'ordre est donc sujet à modification, évidemment parce que la mise en œuvre dépend du chemin le moins perturbateur pour votre état actuel.
Déplacez tout travail système lié au flux de travail lié à l'entreprise vers un aperçu dédié.
Répartissez les tâches sur la boîte, vous pouvez avoir deux ou plusieurs boîtes en une en ce moment.
Réimplémentez votre CM de manière plus structurée et suivez de meilleures pratiques ansibles, des playbooks représentant des objets PAS des fonctions ou des rôles. Chaque système doit être décrit en une seule pièce.
la source