Options de haute disponibilité multisite avec Puppet

Je maintiens deux centres de données, et comme une plus grande partie de notre infrastructure importante commence à être contrôlée via des marionnettes, il est important que le maître des marionnettes travaille sur le deuxième site en cas de défaillance de notre site principal.

Encore mieux serait d'avoir une sorte de configuration active / active pour que les serveurs du deuxième site ne soient pas interrogés sur le WAN.

Existe-t-il des méthodes standard de haute disponibilité multi-sites pour les marionnettes?

Puppet se prête plutôt bien aux environnements multi-maîtres, avec des mises en garde. Le principal? Beaucoup de parties de Puppet aiment être centralisées. L'autorité de certification, les services d'inventaire et de tableau de bord / rapport, le regroupement de fichiers et les configurations stockées - tous sont à leur meilleur dans (ou nécessitent simplement) une configuration où il n'y a qu'un seul endroit pour parler.

Il est tout à fait réalisable, cependant, de faire fonctionner un grand nombre de ces pièces mobiles dans un environnement multimaître, si vous êtes d'accord avec la perte gracieuse de certaines fonctionnalités lorsque vous avez perdu votre site principal.

Commençons par la fonctionnalité de base pour obtenir un nœud faisant rapport à un maître:

Modules et manifestes

Cette partie est simple. La version les contrôle. S'il s'agit d'un système de contrôle de version distribué, il suffit de centraliser et de synchroniser et de modifier votre flux push / pull selon les besoins sur le site de basculement. Si c'est Subversion, alors vous voudrez probablement svnsyncle repo sur votre site de basculement.

Autorité de certification

Une option ici consiste à simplement synchroniser les fichiers d'autorité de certification entre les maîtres, afin que tous partagent le même certificat racine et soient capables de signer des certificats. Cela m'a toujours semblé "mal faire";

• Un maître doit-il vraiment voir son propre certificat présenté dans l'authentification client pour une connexion entrante d'un autre maître comme valide?
• Cela fonctionnera-t-il de manière fiable pour le service d'inventaire, le tableau de bord, etc.?
• Comment ajoutez-vous d'autres noms DNS valides sur la route?

Je ne peux honnêtement pas dire que j'ai fait des tests approfondis de cette option, car elle semble horrible. Cependant, il semble que Puppet Labs ne cherche pas à encourager cette option, selon la note ici .

Donc, ce qui reste est d'avoir un maître CA central. Toutes les relations d'approbation continuent de fonctionner lorsque l'autorité de certification est en panne, car tous les clients et autres maîtres mettent en cache le certificat de l'autorité de certification et la liste de révocation de certificats (bien qu'ils ne rafraîchissent pas la liste de révocation de certificats aussi souvent qu'ils le devraient), mais vous ne pourrez pas signer de nouveaux certificats avant vous récupérez le site principal ou restaurez le maître CA à partir de sauvegardes sur le site de basculement.

Vous choisirez un maître pour agir en tant qu'autorité de certification et tous les autres maîtres le désactiveront:

[main]
    ca_server = puppet-ca.example.com
[master]
    ca = false

Ensuite, vous souhaiterez que ce système central obtienne tout le trafic lié au certificat. Il y a quelques options pour cela;

1. Utilisez la nouvelle SRVprise en charge des enregistrements dans 3.0 pour pointer tous les nœuds d'agent au bon endroit pour l'autorité de certification -_x-puppet-ca._tcp.example.com
2. Configurer l' ca_serveroption de configuration dans puppet.conftous les agents

3. Proxy tout le trafic des demandes liées à l'autorité de certification des agents vers le maître approprié. Par exemple, si vous exécutez tous vos maîtres dans Apache via Passenger, configurez cela sur les non-CA:

   SSLProxyEngine On
   # Proxy on to the CA.
   ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
   # Caveat: /certificate_revocation_list requires authentication by default,
   # which will be lost when proxying. You'll want to alter your CA's auth.conf
   # to allow those requests from any device; the CRL isn't sensitive.
   

Et cela devrait le faire.

Avant de passer aux services auxiliaires, une note annexe;

Noms DNS pour les certificats maîtres

Je pense que c'est ici la raison la plus convaincante de passer à 3.0. Supposons que vous souhaitiez pointer un nœud vers "n'importe quel maître actif".

Sous 2.7, vous auriez besoin d'un nom DNS générique comme puppet.example.com, et tous les maîtres en ont besoin dans leur certificat. Cela signifie définir dns_alt_namesdans leur configuration, réémettre le certificat qu'ils avaient avant d'être configuré en tant que maître, réémettre à nouveau le certificat lorsque vous devez ajouter un nouveau nom DNS à la liste (comme si vous vouliez plusieurs noms DNS pour ont des agents préfèrent les maîtres dans leur site) .. moche.

Avec 3.0, vous pouvez utiliser des SRVenregistrements. Donnez ceci à tous vos clients;

[main]
    use_srv_records = true
    srv_domain = example.com

Ensuite, aucun certificat spécial n'est nécessaire pour les masters - ajoutez simplement un nouvel enregistrement à votre SRVRR sur _x-puppet._tcp.example.comet vous êtes prêt, c'est un master live dans le groupe. Mieux encore, vous pouvez facilement rendre la logique de sélection principale plus sophistiquée; "n'importe quel maître qui travaille, mais préférez celui de votre site" en configurant différents jeux d' SRVenregistrements pour différents sites; pas dns_alt_namesnécessaire.

Rapports / tableau de bord

Celui-ci fonctionne mieux centralisé, mais si vous pouvez vivre sans quand votre site principal est en panne, alors pas de problème. Configurez simplement tous vos maîtres avec le bon endroit pour mettre les rapports.

[master]
    reports = http
    reporturl = https://puppetdash.example.com/reports/upload

..et vous êtes prêt. Le non-téléchargement d'un rapport n'est pas fatal pour l'exécution de la configuration; il sera juste perdu si le toast du serveur de tableau de bord.

Inventaire des faits

Une autre bonne chose à avoir collé dans votre tableau de bord est le service d'inventaire. Avec la valeur facts_terminusdéfinie restcomme recommandé dans la documentation, cela interrompra réellement la configuration lorsque le service d'inventaire central est arrêté. L'astuce consiste à utiliser le inventory_serviceterminus sur les maîtres non centraux, ce qui permet un échec gracieux.

facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140

Ayez votre serveur d'inventaire central configuré pour stocker les données d'inventaire via ActiveRecord ou PuppetDB, et il devrait être à jour chaque fois que le service est disponible.

Donc - si vous êtes d'accord avec un environnement de gestion de configuration assez dépouillé où vous ne pouvez même pas utiliser l'autorité de certification pour signer le certificat d'un nouveau nœud jusqu'à ce qu'il soit restauré, cela peut très bien fonctionner - même si ce serait vraiment bien si certains de ces composants étaient un peu plus conviviaux pour être distribués .

L'approche de "marionnette sans maître" que Ladadadada décrit est celle que je connais le mieux (c'est essentiellement ce que nous faisons avec radmind dans mon entreprise). Je suppose que c'est plus précisément "plusieurs maîtres synchronisés par un processus externe", où un serveur donné pourrait (théoriquement) servir tout notre univers en cas d'urgence.

Dans notre cas, en raison de la nature de radmind, nous utilisons simplement rsyncles transcriptions et les fichiers de données d'un maître approuvé vers le serveur radmind de chaque site distant, et les clients extraient leurs mises à jour du serveur avec un nom d'hôte court radmind(par la magie deresolv.conf ceci, il est évalué à radmind.[sitename].mycompany.com- toujours le local serveur radmind. Si le serveur local est en panne, il est assez facile de remplacer et de pointer vers le serveur de n'importe quel autre site).

Ce type de processus rsync fonctionnerait probablement aussi dans votre situation, mais il est probablement sous-optimal par rapport à une solution basée sur le contrôle de version.

Pour les marionnettes ou les chefs, un système basé sur le contrôle de version est plus logique que le simple rsync pour plusieurs raisons - le plus important étant que vous contrôlez la version des scripts de marionnettes (plutôt que des images de système d'exploitation complètes comme vous le feriez avec radmind). Le branchement et la fusion créatifs vous permettent même de gérer une mise à niveau majeure du système d'exploitation ou une autre transition dans le cadre de contrôle de version - Une fois que vous avez bien fait, passez simplement à la nouvelle branche et (espérons-le) la poussée de la production fonctionnera simplement.
Comme avantages supplémentaires de la gestion basée sur le contrôle de version, vous pouvez avoir plusieurs personnes travaillant sur le référentiel à la fois (grande victoire pour le parallélisme), vous obtenez l'historique des révisions essentiellement gratuitement, et si quelqu'un casse l'environnement Puppet, vous avez un retour en arrière facile (en supposant que vous '' réutiliser gitvous avez également git blamequi fait ce qu'il dit sur l'étain).

Si j'implémentais cela ici, je profiterais probablement des crochets de pré-validation et de post-validation dans git pour garantir que les configurations de marionnettes en cours de validation sont saines (pré-client) et les pousser vers le reste de l'univers si elles sont (publication côté serveur - peut également déclencher une mise à jour de l'environnement si vos stratégies de déploiement autorisent un tel comportement).

En termes de mise en place de nouveaux serveurs puppetmaster sur chaque site, vous pouvez simplement vérifier l'environnement de marionnettes pour chaque maître de marionnettes distant et utiliser soit le piratage resolv.conf / hostname que j'ai décrit ci-dessus, soit les adresses IP du service anycast redirigées vers des systèmes locaux comme Michuelnik l'a suggéré ( ce dernier est pratique si vous voulez un basculement automatique si le marionnettiste d'un site explose) pour s'assurer que chaque site voit le "bon" marionnettiste et n'obstrue pas vos liens WAN en essayant d'obtenir des mises à jour.

Les gens de Brain Tree Payments ont apparemment combiné les solutions de contrôle de version et rsync avec certaines tâches Capistrano personnalisées - leur solution semble être à moitié cuite dans le sens où elle repose toujours sur des éléments de flux de travail manuels, mais elle pourrait être adaptée et automatisée sans trop de travail.
Le testeur compulsif paranoïaque en moi a un penchant pour leur noopétape de vérification de la santé mentale - les processus de haine des manuels souhaitent en moi un certain niveau d'automatisation ...