Tag Archives: Puppet

Utiliser PKGNG sous FreeBSD avec Puppet

Voici la procédure que j’ai appliquée pour utiliser le nouveau package manager de FreeBSD.
Cette méthode a été testée sur une Jail en FreeBSD 8.3 avec puppet 3.2.

Mettre en place pkgng

La procédure officielle se trouve içi.

Installation de pkgng :

# portsnap fetch update
# portmaster -dB ports-mgmt/pkg

Conversion du la base de package au nouveau format de pkgng. Attention ! Comme indiqué dans la documentation, cette étape est irréversible et ne vous permettra plus d’utiliser pkg_add comme package provider.

# pkg2ng

Pour indiquer l’utilisation de pkgng, il faut modifier make.conf :

# echo "WITH_PKGNG=yes" >> /etc/make.conf

Définir le nouveau repository pour pkgng :

# mkdir -p /usr/local/etc/pkg/repos
# cat << 'EOF' > /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: {
  url: "http://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  enabled: "yes"
}
EOF
# pkg update

Votre pkgng devrait être prêt à utilisation :

# pkg update
# pkg install sl # (mon paquet de test de prédilection !)
# sl

pkg peut afficher un message d’erreur (seulement un warning) :

pkg: Invalid configuration format, ignoring the configuration file

C’est un bug connu lié au fait que le fichier /usr/local/etc/pkg.conf est vide.
La version 1.2 devrait fixer ce problème.

Ajouter le provider pkgng à Puppet

Un nouveau provider de package pour Puppet existe déjà.
Vous pouvez trouver le repo github ici.

Pour installer le module, vous pouvez cloner le repo ou utiliser puppet module install :

# cd ~puppet/modules/
# puppet module install xaque208/pkgng

Je n’ai personnellement pas utilisé le manifest du module ( init.pp et params.pp), j’utilise seulement le nouveau provider contenu dans le dossier lib.

Il faut maintenant changer le provider par de package par défault dans Puppet. Je l’ai fait dans site.pp :

if $::operatingsystem == 'FreeBSD' {
        Package {
                provider => $::operatingsystem ? {
                        FreeBSD => pkgng
                }
        }
}

Vous pouvez maintenant définir des ressources packages dans puppet qui seront managées par pkgng :

package {
	'sl':
		#ensure => installed;
		ensure => absent;
}
Share

Sortie de Foreman 1.3

Quoi de neuf dans cette nouvelle version ?

Foreman 1.3 vient d’être releasé par la Core Team, regardons les nouveautés qu’apporte cette nouvelle version :

  1. L’installeur est maintenant basé sur le projet Kafo : je ne l’ai personnellement pas testé puisque j’installe toujours Foreman à partir des sources en checkoutant avec git
  2. Le projet hammer qui est la CLI de Foreman avance ! C’est une bonne chose puisque ca manquait au début du projet. Les développeurs préviennent cependant que les fonctionnalités sont encore limitées pour le moment. Affaire à suivre donc.
  3. Au niveau des Compute Resources, le très attendu support des VPC (Virtual Private Cloud) d’Amazon EC2 arrive enfin. D’autre part, le support de GCE (Google Compute Engine) arrive en version béta. Il est pour l’instant limité, ne supportant pas par exemple la création d’instances nécessitant des disques persistants
  4. Le support de SPICE est enfin disponible avec les Compute Resources de type Libvirt
  5. Foreman permet enfin de transformer une VM vue par Foreman comme un Host BareMetal en … VM !
  6. L’API évolue toujours avec l’arrivée de la v2 qui est toujours ‘expérimentale’. Les nouveautés sont : le support de REMOTE_USER, des smart classes, la gestion des interfaces réseaux, le power management et les boot devices. L’API v1 reste toujours donc par défaut.
  7. Il existe maintenant une commande foreman-rake qui est un wrapper aux différentes commandes rake

Les traductions sont améliorées et Foreman est maintenant traduit dans 6 langues. N’hésitez pas à participer sur le Transifex de Foreman.

Notes avant de migrer

La structure des formats de Reports et d’upload de Facts à changé avec la suppression de Puppet comme dépendance de Foreman Core.

  • Il faut donc impérativement changer votre script d’external node (/etc/puppet/node.rb) sur votre puppet master et utiliser le nouveau que vous pouvez trouver ici.
  • Il faut aussi changer votre script d’upload de report sur votre puppet master et utiliser celui-ci

Supprimer Puppet de Foreman Core est une très bonne chose. Cela va permettre dorénavant l’ajout d’autre Configuration Management System tel que Chef ou CFEngine. Il est à noter qu’un projet de support de Chef à déjà commencé, vous pouvez le trouver ici

La release note originale et le changelog sont ici.
A vos migrations !

Share

Supervision distribuée avec Nagios et Puppet

Historiquement j’utilisais un seul server Nagios3 pour superviser ma production dont la configuration était
complètement générée par Puppet avec Naginator.
Cette solution bien que contraignante (difficulté à gérer les seuils spécifiques d’alerte par exemple,
appliances non puppetisée, etc ..) est vraiment puissante et me permets de ne jamais me soucier de la configuration du monitoring :
je suis sur à tout moment que tous les serveurs dans mon environnement de production sont monitorés
et que chaque service définis dans Puppet à les services Nagios associés.
Cependant mes besoins ont évolués et j’ai commencé à avoir des problématiques de monitoring distribué assez classique :
4 datacenters répartis entre l’Europe et les USA, des problèmes récurrents de réseau
qui provoquaient de nombreux faux-positifs et un ras le bol de mails trop intempestifs.
Je n’avais pas de soucis particuliers de performances : j’ai moins de 200 hosts et 2000 services.

J’ai essayé Shinken, vraiment. Y’a 2 ans une première fois puis ces derniers mois.
J’ai été obligé de le packager puisqu’aucun package Debian n’était proposé
et que tous nos serveurs sont déployés de manière unattended :
le script d’installation proposé n’était pas pour moi une solution envisageable.
Sur le papier Shinken était parfait :
* compatibilité de configuration avec Nagios
* support des directives spécifiques à Shinken dans Puppet avec Naginator
* support natif de distribution avec les realms ou poller_tag
* suport natif de la HA
* support natif de Livestatus
* une communauté sympas et des devs réactifs

Dans les faits et d’après mon expérience :
* la configuration n’est pas 100% interprétée de la même manière (mais les ajustements relativements triviaux)
* shinken prend énormément plus de RAM que nagios (même si Jean Gabès a pris le temps d’écrire un très long mail pour m’expliquer très clairement ce comportement)
* le plus important pour moi : l’ensemble n’est à mon humble avis pas assez stable / robuste dans mon cas d’usage : en cas de netsplit les démons n’arrivaient plus à se resynchroniser à la fin de l’outage, certains modules crashaient sans crier gare, des problèmes d’incompatibilité avec Pyro.

Je n’était pas assez confiant envers mon POC pour accepter de le mettre en production.

Pour être bien claire :
* Je continue de penser que Shinken sera à terme une des (sinon LA) solutions pour remplacer Nagios, mais il n’était pas encore prêt pour mes besoins.
* Certaines personnes font tourner Shinken en production, sur de grosses infras sans problèmes. Mon retour sur ce projet ne doit en aucun cas vous dissuader
de faire vos propres tests et de vous forger votre opinion.

J’ai du trouver une solution moins satisfaisante formellement mais qui repose sur des briques éprouvées.

Je suis donc partis sur l’ensemble des briques suivantes :
* Un server Nagios par datacenter pour le monitoring
* Puppet pour la gestion des configurations distribuée (il prend ici le rôle de l’arbiter de Shinken)
* Livestatus + Check_MK Multisite pour l’aggrégation des données

Nous utilisons énormément de Facts custom dans Puppet et nous avons donc
un Fact « $::hosting » qui nous indique dans quel datacenter se situe notre chaque host.
Afin de découper notre configuration entre chaque poller, j’utilise donc des targets dynamiques dans puppet pour les resources liées aux datacenter (hosts, services, hostescalation, serviceescalation):

Voici un exemple simplifié de ma définition d’host en Exported Resources :

        $puppet_conf_directory = '/etc/nagios3/conf.puppet.d'
        $host_directory = "$puppet_conf_directory/$::hosting"

        @@nagios_host { "$::fqdn" :
                tag           => 'nagios',
                address    => $::ipaddress_private,
                alias         => $::hostname,
                use           => "generic-host",
                notify        => Service[nagios3],
                target        => "$host_directory/$::fqdn-host.cfg",
        }

Toutes les resources communes à tous les pollers (contacts, contactgroups,
commands, timeperiods, etc…) sont générées dans un répertoire sourcé par tous les nagios
(ex: ‘/etc/nagios3/conf.puppet.d/common’).
Enfin dans le nagios.cfg je source pour chaque poller les dossiers des datacenters
que je souhaite monitorer depuis ce poller.

# Ex pour nagios1 : 
cfg_dir=/etc/nagios3/conf.puppet.d/common
cfg_dir=/etc/nagios3/conf.puppet.d/hosting1
# Pour nagios2 :
cfg_dir=/etc/nagios3/conf.puppet.d/common
cfg_dir=/etc/nagios3/conf.puppet.d/hosting2

J’ai pris le partis de ne pas utiliser les tags des exported resources :
ce la le permet d’avoir exactement les mêmes fichiers de configuration sur tous mes pollers dans /etc/nagios3/conf.puppet.d : seul nagios.cfg change entre les pollers.
En cas de soucis avec l’un de mes pollers, je peux très simplement ajouter le monitoring d’un autre datacenter en ajoutant l’inclusion d’un dossier en plus !
Cette configuration me permet donc d’avoir une supervision distribuée dont la configuration est homogène.

J’expliquerais dans un prochain article mon utilisation de Livestatus pour agréger l’ensemble des résultats de monitoring.

Share

Intégration Puppet, Foreman et Mcollective

Depuis que nous avons déployé Foreman en production, nous n’avions jamais pu
utiliser le bouton ‘Run Puppet’ dans l’interface de Foreman car nous n’avons
pas de daemon puppet : il tourne en crontab.

Cependant la sortie de la version 1.2 de Foreman change la donne :
le support de mcollective est maintenant intégré dans les smart-proxies.

Voici la procédure pour le faire fonctionner. Je pars du principe que vous avez déjà
un mcollective et un Foreman fonctionnel.

Vous devez configurer tous les proxy qui déclarent la fonctionnalité ‘puppet’:
Sur les proxy:
On commence par installer le client mcollective et le plugin puppet :

# apt-get install mcollective-client mcollective-puppet-client

Pensez à configurer votre client mcollective (/etc/mcollective/client.cfg), cette configuration devrait être la même que votre desktop.
Vous devez ensuite autoriser l’utilisateur foreman-proxy à utiliser le client mcollective:

# visudo 
Defaults:foreman-proxy !requiretty
foreman-proxy ALL = NOPASSWD: /usr/bin/mco puppet runonce *

Dans la configuration du proxy :

:puppet: true
:puppet_provider: mcollective

Redémarrez votre proxy (pour ma part j’utilise apache et passenger) :

# service apache2 restart

Vous devriez pouvoir tester votre installation avec un simple appel curl :

$  curl   -d "nodes=myserver.example.com" https://myproxy:8443/puppet/run

Afin de pouvoir l’utiliser j’ai du ajouter dans ma configuration de mes daemon mcollective
la directive identity :

Dans /etc/mcollective/server.cfg

identity = myserver.example.com

Dans les paramètres de Foreman, il faut
passer la directive ‘puppetrun’ à ‘true’.

Cela devrait être bon, il vous suffit d’aller sur la page de votre host et cliquer sur le bouton ‘Run puppet’

Share

Générer avec Puppet des certificat SSL avec des « Alternative Name »

J’avais besoins de cette fonctionnalité pour mettre en place la communication SSL entre mes deux serveurs Foreman et ses proxies.
Mon problème étant que mes serveurs Foreman sont utilisé en faillover (avec une VIP) avec un DNS généric et non pas en utilisant leur FQDN.
Ceci provoquait un problème avec le certificat puppet utilisé car l’adresse ne correspondait pas au CN exposé.
J’ai donc mis en place un certificat puppet dont le CN est le FQDN (ex:foreman1.example.com) de la machine et qui comprend en plus comme
‘Subject Alternative Name’ le nom du faillover utilisé (ex:foreman.example.com).

C’est très simple à réaliser mais l’info est pas très documentée sur le net.
Il faut commencer par révoquer et supprimer tous les certificats existants pour cette machine :
Sur le client (sur Debian) :

# rm -rf /var/lib/puppet/ssl

Sur le puppet master :

# puppet cert clean foreman1.example.com

Modifier le puppet.conf du client et lui ajouter la directive :

dns_alt_names = foreman.example.com

Puis lancer puppet sur le client pour forcer la création du nouveau certificat et envoyer la demande de signature au master :

# puppet agent -t --report --pluginsync

Sur le master vous pouvez voir une nouvelle demande de certificat et vous pouvez le signer :

# puppet cert list
  "foreman1.example.com" (SHA256) 2C:76:5B:85:67:28:1C:92:48:AA:10:22:44:C7:9B:A7:0D:9B:E2:A5:5F:10:71:87:B9:3F:46:E4:70:4B:43:6C (alt names: "DNS:foreman.example.com", "DNS:foreman1.example.com")
# puppet cert sign devshinken4.yzserv.com --allow-dns-alt-names

Vous avez donc maintenant un certificat signé par votre Puppet CA qui comprend un DNS Alt Name.

Share

Migrez vos Foreman et dormez sur vos deux oreilles.

Je viens de migrer Foreman pour mettre la version 1.1 en production (je reviendrais sur les nouvelles fonctionnalités de la version 1.1).

Un des points les plus important que je teste quand je mets Foreman à jour, c’est la non regression de l’output de l’ENC. C’est à dire, je vérifie que la nouvelle version de Foreman envoie le même YAML au Puppet Master pendant ENC lookup. Pour me faciliter la vie, j’ai écris un petit script ruby (en partant du script d’external node controler de Foreman) qui va comparer les réponses en YAML entre deux instances de Foreman (ex: une instance de production et une instance de QA).

Afin de supporter les classes paramétrées, Foreman à changé un peu la structure du YAML mais le script supporte ce changement.
Vous pouvez le retrouver sur mon Github. Vous avez juste à modifier les deux URLs de vos Foreman de Production et de DEV ainsi que vos identifiants et mot de passe.

Le script s’arrête automatiquement si il trouve une définition de node différente entre le Foreman de dev et celui de production. Cet outils me permet donc d’être plus tranquile quand je fais une mise à jour majeure de mes Foreman !

Share

Déploiement automatisé et sans effort d’un webserver avec Foreman

L’objectif de ce post est de montrer le niveau d’industrialisation pour le déploiement d’application sur des machines virtuelles que nous apporte Foreman à Yakaz.

Cette vidéo montre comment très facilement nous pouvons créer une nouvelle machine virtuelle et comment puppet configure de manière automatisé le serveur pour faire tourner notre application. Nous utilisons la notion de Compute Resource qui arrive avec Foreman 1.0.

Comparés à l’ancien support de la virtualisation (les hypervisors cf précédent article), les Computes Resources permettent de :

  • Déployer des VM avec plusieurs disque et interfaces réseaux
  • Avoir une console VNC directement depuis l’interface de Foreman 
  • De contrôler qui peut utiliser quelle compute resource : ceci permet d’avoir un cluster de virtualisation pour l’environnement de dévelopement où n’importe qui peut déployer des VM et un cluster de production isolé.
  • Support de la gestion de l’alimentation de la VM directement dans Foreman 
  • Suppression de l’host dans Foreman supprime maintenant aussi la VM sur l’hyperviseur
Les computes resources supportées pour l’instant par Foreman sont : 
  • oVirt / RHEV-M
  • libvirt
  • Amazon EC2
  • support partiel de VMware
Pour rappel, lors d’un déploiement en ‘Unattended Installation’, Foreman s’occupe de :
  • Créer les enregistrements A et PTR pour le domaine
  • Créer la lease DHCP pour la machine
  • Configurer puppet pour la machine via les ENC
  • Signer le certificat client puppet de votre nouvelle VM dans la PuppetCA de votre puppetmaster
Voir ces billets part1 part2 part3 pour le déploiement de Foreman.
Une fois la VM créée et buildée puppet va configurer la machine afin qu’elle soit conforme à l’environnement d’exécution de l’application sélectioné (en l’occurence nos serveurs Web avec notre site)

Cette vidéo vous montre que notre temps humain nécessaire au déploiement d’un nouveau serveur à été drastiquement réduit en misant sur l’intégration de Foreman dans notre architecture. Cette approche nous apporte une forte fléxibilité et élasticité dans la gestion de notre production.

 

Share

Auto validation et supervision de la configuration de Nagios par lui même

Attention c’est un nom bien compliqué pour les trois lignes de bash qui vont suivre.

Ma problématique était la suivante : j’utilise Puppet et son module Naginator pour écrire l’ensemble de ma configuration Nagios. En cas de création d’un nouveau serveur avec Foreman, Puppet vient m’écrire dynamiquement la conf de Nagios avec tous les checks nécessaires en fonctions des classes puppet associées à ce serveur (supervision système, applicative, etc…). Quand puppet écris des changements dans la configuration de nagios,  il notifie automatiquement nagios du changement dans sa conf pour que celui-ci fasse un reload.

Cependant mon module nagios de Puppet n’étant pas parfait, j’arrive en cas d’erreur humaine à créer une configuration Nagios qui n’est malheureusement pas valide (un host nagios est créé et affecté dans un hostgroup qui n’existe pas). Par bonheur lorsqu’une erreur se produit,  nagios vérifie toujours la validité de la configuration avant de faire son reload. Je ne perds donc pas ma supervision mais bien que puppet continue a m’écrire les changements de conf, Nagios ne se met plus à jour.

C’est pourquoi j’ai décidé d’écrire un check de trois lignes de bash qui va vérifier que la configuration de Nagios est bien valide. J’utilise pour cela le le binaire de nagios avec l’option ‘-v’. Vous pouvez retrouver ce script sur Github.

Comme cela, je suis assuré que Nagios a toujours une configuration valide et que ma supervision évolue bien au rythme de mon SI.

J’écrirais surement bientôt un petit article pour expliquer en détail comment j’utilise Foreman / Puppet et Nagios dans mon SI.

Share

Vérifiez le run de vos Puppet avec Foreman et Nagios

J’avais besoin de m’assurer de la fiabilité des runs de Puppet sur l’ensemble de ma production. Pour cela il faut m’assurer de 2 choses :

- Premièrement que puppet s’exécute correctement toute les demi-heure (j’utilise un cron et non pas le daemon puppet) . Pour cela, c’est assez simple, j’utilise un check nagios de base « check_file_age » et je vérifie l’âge du fichier « state.yaml ». Voici donc à quoi ressemble ma commande sur un serveur Debian:

/usr/lib/nagios/plugins/check_file_age -w 3780 -c 43200 -f /var/lib/puppet/state/state.yaml

- La première commande me permet de savoir que Puppet tourne bien régulièrement. Cependant je suis incapable de dire si les runs s’effectuent correctement ou non. C’est pourquoi  j’ai décidé d’utiliser la fonction de Reports de Foreman (voir ces 3 billets 1 2 3 pour l’installation de Foreman).

Vous pouvez trouver mon script içi sur Github. Pour l’utiliser sur un serveur Debian, il faut installer les dépendances (dont une qui n’est pas packagée en deb) :

# apt-get install libhttp-server-simple-perl libjson-perl
# wget http://search.cpan.org/CPAN/authors/id/M/MC/MCRAWFOR/REST-Client-243.tar.gz
# tar xvf REST-Client-243.tar.gz
# cd REST-Client-243
# make
# make install

Ensuite pour l’utiliser c’est très simple :

$ /usr/lib/nagios/plugins/check_foreman_puppet_failure.pl -H webserver.example.com -F http://foreman.example.com -w 3 -c 5 -u username -p password

Cette commande va vérifier les derniers rapports d’exécution de Puppet. Si le nombre de run en erreur est supérieur à warning ou critical alors le check retournera une erreur.

Voila, vous pouvez superviser correctement vos runs de Puppet grâce à Foreman et Nagios

Share

Intégration de PuppetDoc avec Foreman

Nous allons voir dans cet article comment intégrer la documentation de puppet à Foreman. L’objectif est de donner accès aux utilisateurs à cette documentation pour qu’ils sachent quelles règles sont appliquées dans les classes.

Patcher Puppetdoc de Debian 6

Pour les utilisateurs de Debian 6, la première chose à faire est de patcher puppetdoc (voir bug). Pour cela, vous pouvez utiliser le backport du patch que je met à disposition :

# curl http://www.fitzdsl.net/wp-content/uploads/2011/05/puppet_generator.rb_.patch | patch /usr/lib/ruby/1.8/puppet/util/rdoc/generators/puppet_generator.rb

Générer la documentation

Vous pouvez en premier lieu définir le « document root » de votre documentation. J’ai décidé pour ma part de laisser la doc dans le dossier par défaut : RAILS_ROOT/public. Pour générer la documentation, nous allons utiliser une commande rake prévue pour cela. Dans /usr/share/foreman :

# rake puppet:rdoc:generate

Pensez à mettre cette commande en Cron pour mettre à jour votre documentation au fur et à mesure.La documentation est maintenant accessible en allant dans Additional Settings, Puppet Classes, et en cliquant dans la colonne Environements de la classe.

Share