JESUISUNGEEK.COM - Mot-clé - svn2022-10-15T08:24:27+02:00urn:md5:80fcbbbeeb78d335e0ba1eaeec99fb37DotclearInstaller Kibana par Puppet (5/5)urn:md5:5de1c917075b3c23c70052da28ac48e52013-02-11T15:50:00+01:002013-02-13T15:04:38+01:00Jean-Baptiste LangloisBidouillesforemangplkibanalinuxmrepopuppetsvn<p>Déploiement et configuration automatique de Kibana par Puppet</p> <p><img src="http://www.jesuisungeek.com/public/pictures/real/kibana-logo.png" alt="kibana-logo" style="float:left; margin: 0 1em 1em 0;" title="kibana-logo, janv. 2013" />A présent, que tout est correctement installé, il ne reste plus qu'à configurer l'ensemble pour que Kibana se déploie sans soucis.<br /></p>
<ul>
<li><strong>Configuration du <em>Foreman-Proxy</em></strong><br /></li>
</ul>
<p>L'intérêt de Foreman est la forte intégration à Puppet. En effet, une fois les deux applications correctement configurés, Puppet peut très bien être configurés intégralement à travers l'interface Web de Foreman et sans plus mettre à jour les fichiers de configuration. Foreman s'occupe de tout, automatiquement ! <img src="/dotclear/themes/chestnut/smilies/whistle.gif" alt=":siffle:" class="smiley" /> Toutefois, Foreman n'étant lui-même qu'une interface Web passive, il n'a pas les compétences pour la collecte d'information de la part de Puppet. La solution consiste à utiliser un <em>Smart Proxy</em> réalisant cette tâche... Or, le hasard faisant bien les choses, Foreman fournit justement un <em>Smart Proxy</em> personnalisé, le bien nommé <strong>Foreman-Proxy</strong> <img src="/dotclear/themes/chestnut/smilies/biggrin.gif" alt=":-D" class="smiley" /> (Pour ceux qui n'ont pas compris, c'est ce <em>Smart Proxy</em> que j'ai décidé de configurer)<br />
A l'instar de Foreman, Foreman-Proxy tourne grâce à Ruby et nécessite de se connecter à la base de données pour la collecte et le dépot d'informations. Ainsi, il faut installer la bibliothèque permettant à Ruby de se connecter, dans notre cas, à MySQL.</p>
<pre>
[root@sophie conf.d]# yum -q -y install ruby-mysql
[root@sophie conf.d]# service foreman-proxy restart
</pre>
<p>Le proxy écoutant sur le port 8443, il ne faut pas oublier d'ajouter une nouvelle règle pour <em>iptables</em> dans <code>/etc/sysconfig/iptables</code>.</p>
<pre>
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT
</pre>
<ul>
<li><strong>Configuration du <em>Foreman-Proxy</em> et de <em>Foreman</em></strong><br /></li>
</ul>
<p>Tout d'abord, <em>Foreman</em> dispose de deux modes d'utilisations (Désolé pour les anglicismes, j'ai pas trouvé de bonne traduction <img src="/dotclear/themes/chestnut/smilies/sad.gif" alt=":-(" class="smiley" /></p>
<ul>
<li>Le <strong>mode <em>attended</em></strong> permet la gestion de machines déjà installés et sur lesquels <em>Puppet</em> est déjà installé. La configuration est plus rapide mais nécessite une intervention initiale sur les serveurs à déployer.</li>
<li>Le <strong>mode <em>unattended</em></strong> permet la gestion de machines dès l'installation, moment où sont créés les modèles d'installation (<em>Preseed</em> ou <em>Kickstart</em>). La configuration est plus complète mais permet la totale automatisation du processus de déploiement.</li>
</ul>
<p>Par défaut, Foreman s'installation en mode <em>unattended</em>, mais nécessite donc énormement d'information sur le serveur à configurer (Adresse MAC, domaine, etc.). A moins d'avoir un réel besoin d'installer des serveurs via <em>Foreman</em>, mieux vaut désactiver l'option, c'est plus rapide. Dans mon cas, ma machine cliente <em>charlotte</em> étant déjà installé, je n'en ai pas besoin et l'ai donc désactivé :</p>
<pre>
[root@sophie conf.d]# sed -i "s/:unattended: true/:unattended: false/g" /etc/foreman/settings.yaml
[root@sophie conf.d]# service httpd restart
</pre>
<p>L'avantage d'utiliser un <em>Smart Proxy</em>, c'est que cela rend vraiment la gestion de Foreman plus simple <img src="/dotclear/themes/chestnut/smilies/wink.gif" alt=";-)" class="smiley" /> En deux trois coups de Puppet à pot, on peut obtenir un environnement fonctionnel.</p>
<ol>
<li>Se connecter à Foreman avec les droits d'administrateur</li>
<li>Créer un nouveau <em>Smart Proxy</em> dont l'URL est <q>https://sophie.localdomain:8443</q></li>
<li>Dans <em>Settings</em>, changer le <em>modulepath</em> en <q>/etc/puppet/svn/modules</q></li>
<li>Dans <em>Settings</em>, changer le <em>puppet_server</em> en <q>sophie.localdomain</q></li>
<li>Dans <em>Settings</em>, changer le <em>foreman_url</em> en <q>sophie.localdomain</q></li>
<li>Dans <em>Settings</em>, changer le <em>remote_addr</em> en <q>127.0.0.1</q></li>
<li>Dans <em>Environnment</em>, cliquer sur <q>Import from Proxy</q> et importer environnements et classes</li>
</ol>
<p>C'est tout <img src="/dotclear/themes/chestnut/smilies/cool.gif" alt="8-)" class="smiley" /> Le serveur est dorénavant bien configuré ! Il ne reste qu'à ajouter des serveurs à la liste des <q>Hosts</q>.</p>
<pre>
[root@sophie ~]# puppetd -t
</pre>
<p>En saisissant la commande ci-dessus sur <em>sophie</em>, ce serveur-ci est ajouté au <em>Foreman</em>.<br /></p>
<ul>
<li><strong>Intégration de <em>charlotte</em> dans <em>Foreman</em></strong><br /></li>
</ul>
<p>Tout d'abord, comme rien n'est encore installé sur <em>charlotte</em>, il faut commencer par installer le client <em>Puppet</em> afin que ce serveur puisse communiquer avec le PuppetMaster. Le <em>package</em> nécessaire se trouvant dans les sources <a href="http://fedoraproject.org/wiki/EPEL" hreflang="en" title="EPEL">EPEL</a>, on ajoute un lien pour <em>YUM</em> vers ce dépot :</p>
<pre>
[root@charlotte etc]# cat > /etc/yum.repos.d/epel.repo << EOF
[epel]
name=epel
baseurl=http://mirrors.ircam.fr/pub/fedora/epel/\$releasever/\$basearch/
gpgcheck=1
enabled=1
gpgkey=http://mirrors.ircam.fr/pub/fedora/epel/RPM-GPG-KEY-EPEL-6
EOF
</pre>
<p>On peut alors installer le client demandé :</p>
<pre>
[root@charlotte etc]# yum -q -y install puppet
</pre>
<p>A présent, le client est installé. Toutefois, la configuration du fichier <code>/etc/puppet/puppet.conf</code> est celle par défaut et ne correct pas à la configuration présente. Il faut donc modifier ce fichier.</p>
<pre>
[root@charlotte etc]# cat >> /etc/puppet/puppet.conf << EOF
report = true
pluginsync = true
masterport = 8140
environment = production
certname = charlotte.localdomain # le FQDN du serveur client
server = sophie.localdomain # le FQDN du puppetmaster
listen = false
EOF
</pre>
<p>Il ne reste pas qu'à lancer une requête auprès du serveur Puppet...</p>
<pre>
[root@charlotte etc]# puppetd -t
</pre>
<p>...requête qui plantera lamentablement... Car, <strong>oui!</strong> <em>charlotte</em> n'ayant pas été ajouté au PuppetMaster, celui-ci refuse la connexion, prétextant qu'il ne reconnait pas ce client (ce qui n'est pas entièrement faux, il faut le reconnaître...). Toutefois, le serveur <em>sophie</em> a noté le <em>fingerprint</em> de <em>charlotte</em> et l'a placé en <q>attente de validation</q>. Ainsi, si ce serveur est considéré comme <q>validé</q>, il obtiendra l'insigne honneur de communiquer avec cette bonne <em>sophie</em>. Sur le serveur, on peut faire la liste des serveurs en <q>attente de validation</q>.</p>
<pre>
[root@sophie puppet]# puppetca -l
"charlotte.localdomain" (75:65:48:27:49:F0:6F:2C:F4:D6:B5:8B:A7:7A:EA:0C)
</pre>
<p>Il suffit alors de <q>signer</q> ce serveur (c'est-à-dire reconnaître sa clé SSH) pour qu'il soit considéré comme <q>validé</q> par le serveur</p>
<pre>
[root@sophie puppet]# puppetca -s charlotte.localdomain
</pre>
<p>Ceci étant fait, il ne reste qu'à relancer une requête auprès du serveur Puppet, via le client.</p>
<pre>
[root@charlotte etc]# puppetd -t
</pre>
<p>Tout un ensemble d'informations appraissent (heureusement en vert <img src="/dotclear/themes/chestnut/smilies/biggrin.gif" alt=":-D" class="smiley" /> ), preuve que le client a bien été reconnu par le serveur. Toutefois rien d'autre ne se passe... Cela s'explique par le fait que, bien que le client est reconnu, aucun module n'a été chargé à partir du serveur. Une honte ! C'est donc le moment de procéder à l'installation de Kibana <img src="/dotclear/themes/chestnut/smilies/oops.gif" alt=":oops:" class="smiley" /> <br /></p>
<ul>
<li><strong>Installation du serveur <a href="http://kibana.org/" hreflang="en" title="Kibana">Kibana</a></strong><br /></li>
</ul>
<p>Comme j'ai indiqué sur la <a href="http://www.jesuisungeek.com/index.php?post/2013/01/31/Installer-Kibana-par-Puppet-partie-1">première page de ce tutoriel</a>, <em>Kibana</em> est très simple à installer, sauf quand il n'y a pas de réseau et là, ça devient un enfer (foutues <a href="https://rubygems.org/" hreflang="en" title="Rubygems">Gems</a> <img src="/dotclear/themes/chestnut/smilies/aww.gif" alt=":-C" class="smiley" /> ). Hormi, ce fait, il faut installer des serveurs <a href="http://www.elasticsearch.org/" hreflang="en" title="ElasticSearch">ElasticSearch</a> et <a href="http://redis.io/" hreflang="en" title="Redis">Redis</a>, sans oublier <a href="http://logstash.net/" hreflang="en" title="LogStash">LogStash</a> qui a pour tâche d'expédier les flux qui vont bien là où il faut ; bref, un beau foutoir à configurer. Pour simplifier l'installation de toutes les machines, j'ai donc créé un module <q>kibana</q> pour <em>Puppet</em> et c'est ce module qui se chargera de tout installer.<br />
On télécharge donc les fichiers du module de classe et on les charge sur <em>sophie</em> grâce à <em>Subversion</em> :</p>
<pre>
[jbl@bulow ~]$ wget http://www.jesuisungeek.com/public/files/rhel/kibana-puppet.tar.gz -O - | tar zxvf - -C /répertoire/dépot/svn/local
[jbl@bulow ~]$ cd /répertoire/dépot/svn/local
[jbl@bulow local]$ svn add kibana && svn commit
</pre>
<p><div class="dcnote noteimportant">
<p>Dans le cas où, comme indiqué plus haut, il est impossible de télécharger à partir d'Internet sur notre client SVN, les fichiers d'archives sont attachés à ce post. Dans ce cas, il suffit de transférer et tout décompresser dans le répertoire du dépot SVN local avant de l'ajouter à SVN</p>
</div>
Grâce à la magie des <em>hooks</em>, le serveur SVN a été mis automatiquement à jour et il ne reste plus qu'à mettre à jour les modules gérés par <em>Foreman</em>. Pour cela, sur le <em>Foreman</em> de <em>sophie</em></p>
<ol>
<li>Dans les options, choisir l'option <q>Puppet Classes</q>, puis cliquer sur <q>Import</q> pour ajouter la nouvelle classe <code>kibana</code>.</li>
<li>Ajouter la classe <q>kibana</q> à <code>sophie</code></li>
<li>Ajouter la classe <q>kibana::server</q> à <code>charlotte</code></li>
<li>Aller dans <em>Global Parameters</em> et ajouter une variable <q>kibana_server</q> (ici : 192.168.1.48)</li>
</ol>
<p><a href="http://www.jesuisungeek.com/public/pictures/real/kibana_-_puppetclass.png" title="Foreman - Puppet classes"><img src="http://www.jesuisungeek.com/public/pictures/real/.kibana_-_puppetclass_m.jpg" alt="Foreman - Puppet classes" style="display:block; margin:0 auto;" title="Foreman - Puppet classes, fév. 2013" /></a>
Il ne reste plus qu'à déployer les classes demandés sur <em>charlotte</em> et <em>sophie</em>. Toutefois, les deux serveurs échangeront les informations à logguer via <em>Redis</em>, ne pas oublier d'ouvrir le port nécessaire (ici <q>161</q>) en ajoutant une nouvelle règle pour <em>iptables</em> dans <code>/etc/sysconfig/iptables</code>.</p>
<pre>
-A INPUT -m state --state NEW -m tcp -p tcp --dport 161 -j ACCEPT
</pre>
<p>Ensuite, il ne reste qu'à relancer l'agent <em>Puppet</em> sur les deux serveurs</p>
<pre>
[root@charlotte etc]# puppetd -t
[root@sophie etc]# puppetd -t
</pre>
<p>Après que <em>Puppet</em> ait déroulé les informations de modification de configuration, il suffit d'attendre quelqus minutes (le temps que l'ensemble des logs commence à être remonté) pour se connecter à <code>http://charlotte:8080</code> pour constater le bon fonctionnement de l'ensemble.<br />
<a href="http://www.jesuisungeek.com/public/pictures/real/kibana_-_logs.png" title="Kibana - Fonctionnement"><img src="http://www.jesuisungeek.com/public/pictures/real/.kibana_-_logs_m.jpg" alt="Kibana - Fonctionnement" style="display:block; margin:0 auto;" title="Kibana - Fonctionnement, fév. 2013" /></a></p>http://www.jesuisungeek.com/index.php?post/2013/02/11/Installer-Kibana-par-Puppet-%285/5%29#comment-formhttp://www.jesuisungeek.com/index.php?feed/atom/comments/223Installer Kibana par Puppet (4/5)urn:md5:d679ca8b0018e44611531f2d56e4f85b2013-02-04T15:15:00+01:002013-02-11T15:50:50+01:00Jean-Baptiste LangloisBidouillesforemangpllinuxmrepopuppetRed Hatsvn<p>Dans cette partie, on s'occupe du <em>versioning</em> des modules Puppet via SVN</p> <p><img src="http://www.jesuisungeek.com/public/pictures/real/kibana-logo.png" alt="kibana-logo" style="float:left; margin: 0 1em 1em 0;" title="kibana-logo, janv. 2013" /></p>
<ul>
<li><strong>Installation et configuration de <a href="http://subversion.tigris.org/" hreflang="en" title="Subversion">Subversion</a></strong><br /></li>
</ul>
<p>Il ne reste plus qu'à configurer notre serveur Subversion. Celui-ci permettra de mettre à jour plus facilement les modules puppet à partir de machines clients et de garder une trace des modifications apportées aux fichiers. Afin de gagner du temps dans la configuration, tout comme <em>Puppermaster</em>, <em>Foreman</em> et <em>MRepo</em>, celui-ci fonctionne grâce à <em>Apache</em> via le module <strong>SVN/WebDAV</strong>. Pource faire, on commecne tout d'abord par installer les packages nécessaires :<br /></p>
<pre>
[root@sophie conf.d]# yum -y -q install subversion mod_dav_svn
</pre>
<p>L'installation du package <em>mod_dav_svn</em> va, au passage, créé un fichier de configuration pour <em>Apache</em>. Dès lors, il n'y a qu'à le modifier :</p>
<pre>
[root@sophie conf.d]# cat >> /etc/httpd/conf.d/subversion.conf << EOF
<Location /svn>
DAV svn
SVNPath /var/svn
AuthType None
</Location>
EOF
</pre>
<p>Il ne reste plus qu'à affecter les droits du dépot SVN à l'utilisateur <strong>apache</strong> puisqu'à travers WebDAV, c'est cet utilisateur qui gérera l'envoi et le téléchargement des données du dépot :</p>
<pre>
[root@sophie conf.d]# mkdir -p /var/svn
[root@sophie puppet]# chown -R apache:apache /var/svn/*
[root@sophie puppet]# chmod -R 775 /var/svn/*
[root@sophie conf.d]# service httpd restart
[root@sophie conf.d]# svnadmin create /var/svn
</pre>
<p>Maintenant que <em>Subversion</em> est installé, il faut créer le dépot local et y déposer les premiers modules développés. Ces modules sont ceux qui ont été créés par <em>Foreman</em> et se situe par défault dans le répertoire <code>/etc/puppet/modules</code>. On peut très bien imaginer prendre le répertoire <code>/etc/puppet</code> comme racine pour <em>Subversion</em>, mais on devra alors se farcir les fichiers de configuration de Puppet. Le plus propre est donc de mettre tous les modules dans un répertoire <code>/etc/puppet/svn</code> qui deviendra notre racine <em>Subversion</em>.</p>
<pre>
[root@sophie puppet]# mkdir /etc/puppet/svn/
[root@sophie puppet]# mv /etc/puppet/modules/ /etc/puppet/svn/
[root@sophie puppet]# chown -R apache:apache /etc/puppet/svn/
[root@sophie puppet]# chmod -R 775 /etc/puppet/svn/
</pre>
<p>Tout est prêt pour envoyer la liste des module vers le serveur <em>Subversion</em>. Toutefois, comme <em>Subversion</em> est généré à travers <em>Apache</em>, il faut que ce soit l'utilisateur Apache qui est tous les droits sur le serveur SVN. Pour ce faire, il faut que l'utilisateur <strong>apache</strong> ajoute les modules au dépot :</p>
<pre>
[root@sophie puppet]# su apache -s /bin/sh
sh-4.1$ svn co http://sophie/svn /etc/puppet/svn/
sh-4.1$ cd /etc/puppet/svn/ && svn add * && svn commit
sh-4.1$ exit
</pre>
<p>Les données étant dorénavant correctement envoyés au serveur, n'importe quel serveur peut télécharger et modifier ces modules, sous couvert que le dit serveur ait accès au port 80 du serveur Foreman/Puppet/MRepo/SVN (ca commence à faire long <img src="/dotclear/themes/chestnut/smilies/ouch.gif" alt=":-s" class="smiley" /> ). A-t'on fini ?? NON ! Ne surtout pas qu'on a modifié la configuration du serveur puppet ; les modules, auparavant dans <code>/etc/puppet/</code>, sont maintenant dans <code>/etc/puppet/svn/</code> et il faut donc l'indiquer dans le fichier de configuration de Puppet, puis le redémarrer :</p>
<pre>
[root@sophie puppet]# sed -i "s@/etc/puppet/modules@/etc/puppet/svn/modules@g" /etc/puppet/puppet.conf
[root@sophie puppet]# service puppet restart
</pre>
<p><br /></p>
<ul>
<li><strong>Mises à jour automatiques de <em>Subversion</em></strong><br /></li>
</ul>
<p>Waow, c'est cool, on a un serveur <em>Subversion</em> flambant et ça claque ! Mais dans les faits, si à chaque modification d'un utilisateur, l'administrateur est obligé de se connecter pour balancer un <code>svn update</code> dans <em>/etc/puppet/svn</em>, non seulement c'est pas pratique mais la mauvaise humeur de l'admin va aller croissante avec le nombre de développeurs... Le mieux, ça serait de pouvoir mettre à jour automatiquement le répertoire des modules Puppet dès qu'un <code>svn commit</code> est soumis par un des utilisateurs. Pour cela nous avons utilisé les <q>hooks</q> de <em>Subversion</em> qui (contrairement au capitaine éponyme qui sert à rien) permettent de déclencher des actions au moment de certains événements. Dans notre cas, <ins>après</ins> qu'un <code>svn commit</code> a eu, on souhaite qu'un <code>svn update</code> soit executé dans le répertoire <em>/etc/puppet/svn</em> du serveur. On va utiliser pour cela le <q>hook</q> (Rien à voir non plus à voir avec un quelconque bibliothèque d'une quelconque Université de l'Invisible) dit de <strong>post-commit</strong>.</p>
<pre>
[root@sophie hooks]# cat > /var/svn/hooks/post-commit << EOF
#!/bin/sh
cd /etc/puppet/svn
svn up
EOF
[root@sophie hooks]# chmod 775 /var/svn/hooks/post-commit
</pre>
<p><br /></p>
<ul>
<li><strong>Un <q>hook</q> pour les corriger tous (facultatif}</strong><br /></li>
</ul>
<p>Un <strong>post-commit</strong>, c'est bien, mais un <strong>pre-commit</strong>, c'est mieux ! OK, la mise à jour automatique du dépot est très pratique pour le serveur mais, comme à terme, le serveur est censé déployé un code sur tous ses clients, que se passera-t-il si le code est <ins>faux</ins> ?? La question se pose d'autant plus qu'à présent, le code est mis à jour sur le serveur <ins>sans aucune vérification</ins>. C'est pour cela que j'ai mis en place ce <q>hook</q> de <strong>pre-commit</strong> qui contrôle la syntaxe des fichiers soumis. Si celle-ci n'est pas conforme, le <em>commit</em> est interrompy jusqu'à correction du code erroné.</p>
<pre>
[root@sophie puppet]# yum -y -q install rubygem-puppet-lint
</pre>
<p>On installe donc tout d'abord <em><a href="https://github.com/rodjek/puppet-lint" hreflang="en" title="Puppet-Lint">puppet-lint</a></em> donc la seule tâche est de vérifier le code Ruby soumis pour Puppet. C'est grâce à lui que mon code Ruby sera toujours propre et joli à lire <img src="/dotclear/themes/chestnut/smilies/smile.gif" alt=":-)" class="smiley" /></p>
<pre>
[root@sophie hooks]# cat > /var/svn/hooks/pre-commit << EOF
#!/bin/sh
REPOS="\$1"
TRANS="\$2"
for FILE in \$(svnlook changed -t "\$TRANS" "\$REPOS" | cut -b 5-); do
if [ "\${FILE: -3}" == '.pp' ]; then
svnlook cat -t "\$TRANS" "\$REPOS" "\$FILE" > /tmp/puppet-lint.check
puppet-lint --no-autoloader_layout-check /tmp/puppet-lint.check >&2
RETVAL=\$?
rm -f /tmp/puppet-lint.check
if [ \$RETVAL -ne 0 ]; then
echo "Commit error: Syntax error in \$FILE" >&2
exit 1
fi
fi
done
exit 0
EOF
[root@sophie manifests]# chmod 775 /var/svn/hooks/pre-commit
</pre>http://www.jesuisungeek.com/index.php?post/2013/02/04/Installer-Kibana-par-Puppet-partie-4#comment-formhttp://www.jesuisungeek.com/index.php?feed/atom/comments/221