Menu principal

Statut de la page

Alerting Grafana 4 et images sur Amazon S3

Je suis en train de tester l’alerting de Grafana arrivé récemment avec la version 4.0.0 (beta2). Pour afficher une alerte avec le graphe, il faut utiliser S3 ou un Webdav public. J’en ai donc profité pour tester Amazon S3 et comme la configuration n’a pas fonctionné du premier coup, c’est l’occasion d’un billet rapide sur le sujet ! Bonne lecture… Installation Je suis parti de l’image Docker officielle. Vous aurez besoin de persister sur disque la configuration et les datas de Grafana. Pour du docker standalone, je vous renvoie à la documentation sur le docker hub. Pour du kubernetes vous pouvez utiliser helm et le  [...]
Lire la suite
Vus : 65
Publié par binbash.fr : 29

Installer un registry Docker privé et multiarch

Un registry Docker privé, c’est pratique ! Mais s’il est en plus multiarch, c’est parfait ! Pourquoi faire ? Pour par exemple pouvoir installer avec le même docker pull une image x86 ou une image arm. Mais encore ? Si votre cluster Kubernetes est composé de noeuds x86 et de noeuds arm et que vous faites un daemonset, il est plutôt indispensable de pouvoir pointer sur une image unique ;-) (c’est aussi valable pour du Swarm, du déploiement via du compose…). Let’s Encrypt Pour générer un certificat Let’s Encrypt pour votre registry, vous aurez besoin du client certbot. Vérifiez s’il existe dans les paquets de votre [...]
Lire la suite
Vus : 264
Publié par binbash.fr : 29

Puppet 3.6 et PuppetDB 2.0

Je viens de passer mon environnement de test à Puppet 3.6.1 et PuppetDB 2.0. J’ai rencontré quelques soucis suite à cette mise à jour. Quelques points peuvent être gênants et doivent vous alerter en cas de mise à jour dans un environnement de production. Voici le résumé des problèmes rencontrés… Nouvelle gestion des environnements Un des gros changements de la version 3.6, c’est la modification de la configuration des environnements : l’ancienne méthode est deprecated. Si vous utilisez des blocs environnements dans votre puppet.conf ou si vous utilisez des valeurs globales pour manifest, modulepath, config_version, template_dir, vous aurez comme moi un beau : Warning: Setting templatedir is deprecated. See http://links.puppetlabs.com/env-settings-deprecations  [...]
Lire la suite
Vus : 36
Publié par binbash.fr : 29

Quelques news…

Il y a longtemps que je n’ai pas publié d’articles ici, j’ai pourtant encore quelques trucs à raconter ! Je suis pas mal occupé en ce moment, mon activité tourne à 100% autour de Puppet.

Je bosse par exemple sur une IHM qui nous permet d’inventorier, de piloter nos serveurs et d’appliquer des mises à jour. Le tout grâce à Puppet et Mcollective, sujet que je n’ai pas encore abordé ici.

L’autre point chaud du moment, c’est tout l’outillage qui se met en place pour aider les utilisateurs à cohabiter avec un Puppet qui va gérer un serveur de A-Z.

A ce sujet, un nouvel auteur (Seb) va vous présenter au travers d’un article un petit outil plutôt super pratique qu’on est en train de tester ! Je n’en dis pas plus, il prépare l’article en ce moment.

Bonne lecture ;-)

Vus : 27
Publié par binbash.fr : 29

Puppet : outillage et plugins

Avoir un serveur Puppet scalable, à jour et qui tourne comme une horloge c’est parfait. Ça facilite la vie de beaucoup de monde dès que l’on connaît un peu son fonctionnement. Cependant, il y a des moments où des utilisateurs ne connaissent pas mais doivent intervenir sur les machines (oui … la vie est dure). Et bien qu’au début cela peut être amusant d’observer quelqu’un modifier son fichier 10 fois avant de se demander pourquoi ses modifications ne sont pas conservées, à la longue ça l’est beaucoup moins. Du coup, une problématique se pose : Comment une personne ne parlant pas Puppet couramment peut savoir ce qui est géré par puppet ? La réponse simple : il modifie son fichier et lance un run .. si ça change c’est que c’est géré par puppet. Étonnamment ça ne séduit pas les [...]
Lire la suite
Vus : 30
Publié par binbash.fr : 29

Varnish 3.0.3s et tinyproxy sur Wheezy

Dans un article précédent, je vous avais présenté la solution que j’utilisais pour profiter du cache de Varnish afin de combler les manques d’un proxy sur lequel je n’avais pas forcément la main. Aujourd’hui j’utilise toujours cette méthode, même à mon chez moi. C’est bien pratique. J’ai cependant rencontré quelques petits soucis en passant sur la Wheezy. C’est donc l’occasion de faire une petite mise à jour sur le sujet… Un segfault avec Varnish 3.0.2s J’ai eu droit à un joli segfault avec la version 3.0.2s de Varnish en passant sous Wheezy. Je n’ai pas cherché le comment du pourquoi sachant que la 3.0.3s était disponible et que ce problème ne se reproduit pas avec cette version. Si vous avez une erreur du style [...]
Lire la suite
Vus : 31
Publié par binbash.fr : 29

Puppet 3 et PuppetDB

Je viens de mettre à jour mon environnement de test vers Puppet 3 (depuis une version 2.7.19). Pas de grosses difficultés, pas de grosses surprises… Je vais vous décrire dans cet article la méthode utilisée. Le principal point bloquant que j’ai rencontré lors de cette mise à jour s’est trouvé être mon serveur MySQL (utilisé pour la partie storeconfigs/inventory). J’ai eu toute une série de bugs que je n’ai pas réussi à résoudre et le fait que cette méthode sera bientôt obsolète m’a encouragé à passer à PuppetDB. J’ai eu également 2⁄3 erreurs plus simples liées à certains de mes manifests… Un état des lieux de votre environnement Puppet Avant d’attaquer la mise à jour, faites [...]
Lire la suite
Vus : 23
Publié par binbash.fr : 29

bash : centraliser l’historique de vos commandes avec syslog

Dans cet article, je vais vous présenter une solution pour envoyer l’ensemble des commandes exécutées avec le shell bash sur un serveur syslog distant. Cette option est possible en utilisant la variable d’environnement PROMPT_COMMAND ou nativement avec bash à condition de le recompiler. C’est cette deuxième solution que je vais vous présenter avec deux alternatives : recompiler bash et l’installer directement depuis les sources ou modifier le paquet Debian. Nous verrons également une configuration rsyslog client/serveur pour centraliser tous vos logs à un seul endroit. Installer bash depuis les sources Compilation de bash avec syslog Voici les étapes [...]
Lire la suite
Vus : 950
Publié par binbash.fr : 29

bash : centraliser l’historique de vos commandes avec syslog

Dans cet article, je vais vous présenter une solution pour envoyer l’ensemble des commandes exécutées avec le shell bash sur un serveur syslog distant. Cette option est possible en utilisant la variable d’environnement PROMPT_COMMAND ou nativement avec bash à condition de le recompiler. C’est cette deuxième solution que je vais vous présenter avec deux alternatives : recompiler bash et l’installer directement depuis les sources ou modifier le paquet Debian. Nous verrons également une configuration rsyslog client/serveur pour centraliser tous vos logs à un seul endroit. Installer bash depuis les sources Compilation de bash avec syslog Voici les étapes nécessaires pour compiler bash 4.2 sur une Debian Squeeze : Installez le paquet [...]
Lire la suite
Vus : 22
Publié par binbash.fr : 29

Pacemaker 1.1

Il existe aujourd’hui plusieurs séries de Pacemaker : la version 1.0 sur laquelle sont basés les précédents tutoriels (la version stable actuelle), la version 1.2 qui sera la future version stable et la version 1.1 qui contient les nouvelles fonctionnalités en provenance de la version de dev et les corrections de bugs. C’est sur cette version que sera basé Pacemaker 1.2 qui devrait sortir en fin d’année. Pour pouvoir utiliser la version 1.1 en production, les développeurs ont rajoutés 2 nouveaux schémas de configuration. Avec cette nouvelle version, vous pouvez utiliser Corosync 2.0, utiliser de nouvelles fonctionnalités (déplacer les ressources en fonction de l’utilisation de votre serveur, gestion des ACLs…). Choix du schéma A ce jour, vous avez le choix entre les schémas suivants [...]
Lire la suite
Vus : 27
Publié par binbash.fr : 29
Powered by BilboPlanet