Gestion de la configuration pour «plusieurs administrateurs à serveur unique»

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?

ansible configuration-management

— Joost
source

Réponses:

Faites simplement tourner une machine virtuelle de test / de transfert que vous pouvez utiliser pour valider vos modifications. Votre méthode actuelle pour effectuer manuellement les modifications en premier est désespérément interrompue et vouée à l'échec. Vous et votre équipe devez vous engager à utiliser correctement CM et une partie de cela est d'avoir un système de test disponible. Même juste une VM vagabonde locale serait suffisante.

Non seulement cela aidera à tester de nouveaux changements, mais cela servira également de banc d'essai pour les nouveaux employés (ou les employés plus âgés qui n'ont pas utilisé le système depuis un certain temps) pour se familiariser avec votre configuration ansible.

Concernant la conservation de / etc / in git: non, ne faites pas ça. Ce répertoire n'est qu'une infime partie de ce qu'ansible est en train de changer, et avoir git en place ne fera qu'encourager les gens à faire des changements locaux.

Gardez vos playbooks ansible dans git. Envisagez de restreindre les autorisations de manière à ce que vous seul puissiez appliquer des modifications visibles au serveur en direct. D'autres peuvent soumettre des demandes d'extraction avec leurs modifications, que vous pouvez consulter et fusionner en maître si nécessaire.

— EEAA
source

C'est le scénario idéal. Je comprends ça. Le fait est que nous ne sommes pas une entreprise et que nous n'avons pas de personnes travaillant à temps plein. J'ai peut-être rendu l'échelle de ce manque de clarté insuffisante. Chaque partie supplémentaire (comme un fichier vagrant) ajoute de la complexité qui devrait être transmise, et l'exécution de deux configurations (c'est-à-dire un système de test où des choses comme l'automatisation de l'encryptage permet de se moquer) fait n'aide pas la simplicité.

— Joost

Eh bien, vous avez demandé comment résoudre vos problèmes et j'ai donné ma réponse. Ce qui précède est exactement la façon dont nous faisons les choses dans mon entreprise, et cela fonctionne très bien. Oui, il y a un coût supplémentaire en termes d'espace serveur et de temps requis pour tester, mais cela en vaut la peine car nous avons un niveau d'assurance très élevé qu'en quelques minutes, nous pourrions reconstruire n'importe lequel de nos serveurs si nécessaire.

— EEAA

Au fond, c'est vraiment un problème culturel et de ressources, pas un problème technique. Vous ne vous êtes pas engagé à utiliser la gestion de configuration. Que vous soyez ou non une entreprise est sans importance. Vous demandez de l'aide sur la façon de faire les choses correctement, et avoir un environnement de mise en scène en fait partie.

— EEAA

À mon humble avis, vous devriez vous y engager. Cependant, savoir si vous pouvez convaincre vos collègues est une autre question. Il n'existe aucun moyen léger de le faire qui ne nécessite pas un certain niveau d'intentionnalité de la part de ceux qui gèrent le serveur. Parmi les systèmes CM modernes, ansible est de loin le plus facile à mettre à jour. Vous ne voulez suivre les changements au fil du temps du serveur. La seule façon de le faire de manière fiable est d'utiliser CM.

— EEAA

@ThomWiggers Je vais présumer que vous faites partie de la même équipe depuis que vous avez utilisé "nous". OK, vous avez demandé comment procéder correctement. J'ai répondu. Soit vous voulez le faire correctement, soit vous ne le faites pas. Faire correctement la CM prend du temps, de l'argent et de l'intentionnalité. Si vous avez des exigences telles que l'obtention et le déploiement de certificats via LE, alors mettez en place une machine virtuelle à 5 USD / mois avec Digital Ocean et utilisez-la pour les tests. Heck, vous pouvez même le déployer à la demande lorsque vous souhaitez tester les modifications, puis le tuer.

— EEAA

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.

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:

Apportez des modifications aux tâches Ansible.
Exécutez le playbook.
Examinez le système et, s'il n'est pas correct, revenez à l'étape 1.
Validez mes modifications.

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.

— Boycott SE pour Monica Cellio
source

Oui, c'est un excellent conseil. Faire cela et vous assurer que vous pouvez toujours remettre votre serveur dans un état connu est très libérateur - si les choses tournent au sud, il vous suffit de neutraliser le serveur et de le redéployer.

— EEAA

À droite, je suis d'accord pour dire qu'il s'agit d'un juste milieu entre où nous en sommes et où nous devrions être. Bien sûr, c'est ainsi que nous avons commencé. Je suppose que la principale raison pour laquelle nous avons dérivé là où nous en sommes maintenant est que l'étape 2 a rendu le cycle entier trop long. Il se pourrait que nous fassions de mauvais livres de lecture. Maintenant que nous avons appris à écrire des tâches Ansible, il vaut peut-être la peine de réessayer. D'après votre expérience, combien de temps prendrait un cycle complet et à quelle fréquence se répéterait-il? Je me rends compte que tous les chiffres vont être basés sur toutes sortes d'hypothèses ..

— Joost

Un problème différent que j'ai rencontré avec ce processus itératif se produit lorsque vous écrivez une tâche qui apporte des modifications, apportez les modifications au serveur, découvrez que les modifications sont incorrectes, mettez à jour votre tâche et réappliquez le playbook. Maintenant, le serveur contient un mélange de deux ensembles de modifications: celles de la première itération de la tâche et celles de la seconde. Habituellement, la deuxième itération remplace la première, mais pas nécessairement toujours. Existe-t-il un moyen raisonnable de «nettoyer» plutôt que 1) de SSH manuellement pour annuler, ou 2) à partir d'une installation propre à chaque fois?

— Joost

De plus, nuking le serveur n'est souvent pas trivial si vous n'en avez qu'un

— Thom Wiggers

"D'après votre expérience, combien de temps prendrait un cycle complet et à quelle fréquence se répéterait-il?" - J'ai commencé à utiliser Ansible en janvier; Vers le mois de juin, je suis arrivé au point où je fais plus rapidement tout le processus dans Ansible qu'à la main, pour la plupart des tâches. Le temps spécifique dépend bien sûr du projet, de quelques minutes à quelques semaines (pour certains logiciels particulièrement difficiles). Si vous constatez que l'exécution du playbook lui-même vous ralentit, vous pouvez envisager d'utiliser des balises pour exécuter uniquement un sous-ensemble pendant vos boucles d'itération.

— Boycott SE pour Monica Cellio

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.

— JM Becker
source