Gestion de la configuration: dépendances entre ordinateurs

J'ai utilisé des outils comme des marionnettes pour gérer des systèmes individuels, avec généralement un haut niveau de succès. Là où la marionnette tombe, c'est qu'elle n'est pas bonne pour gérer les dépendances en dehors d'un serveur individuel.

Par exemple, sur un serveur MySQL, je configure la marionnette pour faire ce qui suit:

• Configurer l'authentification sur la machine pour frapper mon serveur LDAP
• Configurer apt pour utiliser mon miroir de référentiel local
• Installer les packages MySQL
• Écrivez my.cnf
• Démarrez MySQL
• Créer des utilisateurs dans la base de données

Dans cet ensemble d'étapes, un certain nombre de dépendances sont résolues - par exemple, je ne peux pas démarrer le service de base de données à moins d'avoir installé les packages, ce que je ne peux pas faire à moins que le dépôt apt soit correctement configuré.

Ce serveur MySQL est une boîte dans une configuration de réplication maître-> maître. Dans un monde idéal, la marionnette (ou un autre outil similaire) me permettrait de représenter le fait que le serveur B doit attendre que le serveur A soit disponible, puis tenter d'établir une relation de réplication avec lui.

Beaucoup de texte ici - essentiellement ce que je demande, c'est: y a-t-il des outils comme marionnette qui peuvent gérer des dépendances inter-machines comme celle-ci?

Si vous utilisez Puppet, les ressources exportées (et donc les configurations stockées ) sont l'outil pour le travail. Cela vous permet de partager des informations entre les nœuds. Y compris les paramètres de réplication réels, le cas échéant.

Alternativement, et bien que je ne sois pas moi-même abonné, certaines personnes traitent leurs manifestes / runs comme non déterministes. Cela signifie qu'une seule exécution ne déclare pas nécessairement le résultat complet d'un nœud. Cela peut prendre deux ou plusieurs exécutions avant que le nœud n'atteigne son état souhaité.

Étant donné que la configuration de l'esclave MySQL avant que le maître ne soit disponible ne serait pas entièrement fatale, vous souhaiterez peut-être emprunter cette voie. Ce n'est pas aussi "intelligent" à mon avis.

N'étant pas un utilisateur de marionnettes, je suis sûr que d'autres répondront avec des réponses plus appropriées, mais il semble qu'un script wrapper puisse être implémenté avec une relative facilité qui vérifie avant de démarrer le service.

La marionnette peut très bien faire cela. Demandez à chaque serveur d'exporter une ressource pour configurer les autres serveurs appropriés pour faire ce qui doit être fait une fois qu'ils sont opérationnels. Je n'ai pas d'exemple pour MySQL, mais nous configurons beaucoup (comme environ 80, au nombre actuel) de ressources DRBD de cette façon, ainsi que toutes nos configurations Nagios.

Le niveau de contrôle pourrait bien être ce que vous recherchez. Vous pouvez l'utiliser en conjonction avec une marionnette afin que la courbe d'apprentissage ne soit pas trop abrupte.