OpenBeerMap – La Carte des bières

Aperogeek c’est de la Bière et du Linux.

Et pour l’instant j »ai abordé beaucoup de sujets Geek et très peut de bière. Du coup je vais vous parler d’une appli super qui permet de trouver facilement les bons bars qui servent de la bonne bière !

Il s’agit d’OpenBeerMap ! Une surcouche d’OpenStreetMap pour visualiser tous les bars et la liste des bières que servent chacun.

open_beer_map

Bien sur comme c’est Open Source, tout le monde peut contribuer en allant renseigner les bières pressions servies à chaque adresse !

J’ai déjà commencé en ajoutant quelques bonnes adresse sur Lyon 😉

Zabbix JMX : Auto Discovery + JBoss + Weblogic T3

zabbix_logo_500x131Java_logo

Dernièrement j’ai patché le code source du collecteur JMX de Zabbix pour rajouter quelques features :

  • Découverte automatiques des attributs / Name
  • JMX JBoss
  • JMX Weblogic en T3

Les sources sont disponibles sur mon github

Comment ça marche ?

Il faut spécifier une macro Zabibx $JMX_USER avec <login>:<protocol> ou juste « :<protocole> » si il n’y a pas d’authentification JMX.

Voici les valeurs possible pour protocole :

  • jmx : URL JMX classique
  • jboss : URL jboss remoting JMX
  • t3 : Pour utiliser une connection weblogic t3
  • t3s : Pour se connecter à la console weblo en T3S

voici les URL exacte définies pour chaque protocole :

String jmx_url      = "service:jmx:rmi:///jndi/rmi://[" + conn + "]:" + port + "/jmxrmi"; // default
String jboss_url    = "service:jmx:remoting-jmx://" + conn + ":" + port; // jboss
String t3_url       = "service:jmx:t3://"+conn+":"+port+"/jndi/weblogic.management.mbeanservers.runtime"; // T3
String t3s_url      = "service:jmx:t3s://"+conn+":"+port+"/jndi/weblogic.management.mbeanservers.runtime"; // T3S

Ainsi, dans chaque template JMX, on ajoute 2 macros {$JMX_USER} et {$JMX_PASS} et on renseigne le protocole dans {$JMX_USER}.

Si aucun protocole n’est renseigné, c’est l’url classique qui est utilisée.

Dépendances

Copier les libs suivantes dans le répoertoire lib de zabbix_java_gateway :

  • wlthint3client.jar : pour faire du weblogic t3
  • jboss-remoting-3.2.18.GA-redhat-1.jar : pour jboss

Compilation

Pour compiler tout ça il y a juste a cloner le repo git, éditer le Makefile pour renseigner le PATH de la JDK et des binaiures javac / jar.

Puis :

make

Ca va générer un package bin/zabbix-java-gateway-X.Y.Z.jar

Deploiement

Pour installer, il suffi de copier le jar généré dans le répertoire bin de zabbix_java_gateway. et de re-démarrer zabbix_java_gateway.

 

 

Alpine Linux : A Tiny Tiny Docker Image

Do you know Alpine Linux ? It’s a Tiny Linux distribution based on busybox.

Every one working with docker now that it takes a lot of disk space. That’s why here at ERDF Lyon we are using Docker-Alpine to build our own services..

It is very cool to have a very small containers, for example the base image is only 5 Mb, comparatively to a debian base docker or a centos it’s amazing !!

Here is a list of some images builds by our team :

[root@XXXXX ~]# docker images

REPOSITORY                                               TAG                 IMAGE ID            CREATED             VIRTUAL SIZE

library/alpine-java                  latest              b1ac8a415cc2        8 minutes ago       167 MB

library/alpine-nginx-php             latest              04dd1dd5f3a8        36 minutes ago      73.07 MB

library/alpine-adaje-nginx           latest              babdce2f7acb        2 hours ago         22.34 MB

library/alpine-influxdb              latest              8c1c8602ab3d        5 hours ago         43.71 MB

library/alpine-grafana               latest              87e008359f09        7 hours ago         105 MB

alpine-libc                          latest              768e1a26255d        8 hours ago         14.01 MB

alpine                               latest              809d1eb48c44        9 weeks ago         5.244 MB

library/centos6                      latest              5af3557457ba        5 months ago        396.1 MB

 

as you can see the base alpine is only 5.2MB, an Alpine image with nginx is only 43 MB and even an image with the full java runtime pre-installed is 167MB.

Against a centos6 base (with nothing on it) that takes nearly 400MB : y’a pas photo !!

 

We already have our own docker registry so we just have to build and push a lot of new images base on this tiny Docker image..

Here what’s in the pipeline :

  • alpine-mysql
  • alpine-postgresql
  • alpine-apache (already build from a centos)
  • alpine-zabbix-server
  • alpine-zabbix-frontend
  • alpine-jenkins (already build from a centos)
  • alpine-python (already build from a centos)
  • alpine-ansible (already build from a centos)

How to Use Ansible with Jenkins and Gitlab

ansible_logo-360x288

Ansible

In this article I will try to explain how, here at OI-ERDF Lyon we use ansible Through Jenkins.

Ansible is an Open source Deployment and automation tool.

It is based on ssh, so no agents are required and it’s compatible on Linux / Aix / Solaris and even Windows !

It use playbooks, writted in YAML, to describe the list of tasks that have to be executed on remote servers.

Each task can be associated to a specific host or host group defined in an inventory.

For example :

we have an inventory like this:

dev\

    group_vars\
        main.yml
    host_vars\
        main.yml
    hosts.txt

recette\

    group_vars\
        main.yml
    host_vars\
        main.yml
    hosts.txt

production

    group_vars\
        main.yml
    host_vars\
        main.yml
    hosts.txt

 

 

where a host file looks like :

[apache]

server1

server2

[database]

server3

server4

[mysql]

server3

[postgresql]

server4

 

 

then a playbook define a list of tasks:

hosts: all

  - tasks:

    - name: "display host type"

      shell: uname

      register: host_type

    - debug: host_type.stdout

hosts: apache

  - roles:

    - role: apache

hosts: mysql

  - roles:

    - roles: mysql_server

hosts: postgresql

  - roles:

    - roles: postgresql_server

hosts: database

  - roles:

    - role: mysql_client

 

 

Here we can see that all hosts will execute the uname command and display the result, then each inventory group is affected to the corresponding role.

Simple, clear, powerfull.

to launch a playbook just use :

ansible-playbook -i dev/hosts.txt playbook.yml

Gitlab

GitLab-logo

First, we need a version control system to store all our ansible stuffs.

We choosed Gitlab, cause it has a lot of good features :

  • User friendly
  • Wiki integrated for all projects
  • Issue tracker
  • ldap auth integration
  • Open source
  • hooks
  • and more…

One it’s installed with the community edition packages (rpm or deb) on a dedicated server, you juste have to create a new group « ANSIBLE » in which all the galaxy will be stored.

Ansible Galaxy

 

galaxy_logo_main

The best way to capitalize and re-use Ansible roles, modules and plugins is the Ansible Galaxy.

Our servers are in DMZ so we can’t access the internet web site ansible galaxy. We have to create our own Galaxy with our own ansible roles and module.

In the ANSIBLE group previously created in Gitlab juste create as many role, modules and plugins as you need for ansible deployments.

To find easlily our modules we have defined some dev rules :

  • all ansible roles starts with « role_ »
  • all ansible modules starts with « module_ »
  • all ansible plugins starts with « plugin_ »

a role has the following structure :

role_example:
    defaults\
        main.yml
    files\
        file1
        file2
    handlers\
        main.yml
    meta\
        main.yml
    tasks\
        main.yml
        include1.yml
        include2.yml
    templates\
        template1.conf.j2
        template2.conf.j2
    vars\
        main.yml
    README.md

Where :

  • defaults is the directory where all the defaults variables for the role are defined. Each var can be overloaded by a project by a host var / group var or extra var.
  • files is the directory where the role can store fixed files (almost not used)
  • handlers is the directory where the ansible handlers tasks are defined for the role (i.e. restart service etc…)
  • meta is used to store the ansible galaxy metadata (author / description / dependencies / tags / etc..)
  • tasks is the directory where all the the role main tasks are defined (create FS, apt-get, yum, deploy config file, restart service, etc…)
  • templates is the directory where we store the role’s Jinja2 template files (withe the {{ variables }} replaced)
  • vars is a directory where are stored role specific variables. This variable cannot be overloaded !
  • README.md is the Markdown readme file used to describe the role and defaults vars that can be overridden.

Then publish your role to a new project role_example in your ansible group in Gitlab.

Ansible Projects

Now we can create projects that will use the galaxy.

To use the Ansible Galaxy, just create re requirements.yml file and put

- src: git+https://gitlab.aperogeek.fr/ansible/role_apache.git
  path: roles
  name: role_apache

- src: git+https://gitlab.aperogeek.fr/ansible/role_mysql_server.git
  path: roles
  name: role_mysql

- src: git+https://gitlab.aperogeek.fr/ansible/role_postgresql.git
  path: roles
  name: role_postgresql

- src: git+https://gitlab.aperogeek.fr/ansible/role_mysql_client.git
  path: roles
  name: role_mysql_client

- src: git+https://gitlab.aperogeek.fr/ansible/plugin_tail.git
  path: filter_plugins
  name: tail

- src: git+https://gitlab.aperogeek.fr/ansible/module_assert.git
  path: library
  name: assert

 

 

And install it to your project by using the command

ansible-galaxy install -r requirements.yml

This will fetch all roles, plugins and modules into the corrects directory.

Now you can use this roles into your project and overload roles defaults variable with your inventory.

Of course the project use Gitlab to store the playbooks,  inventory and requirements.

Jenkins

jenkins

Now we have :

  • Gitlab to store ansible galaxy and projects playbooks and inventory
  • Ansible Galaxy with our own roles that respect our dev rules and the enterprise standards
  • Projects that use the ansible galaxy to deploy their apps

All we need is a web UI to simplify the deployments.

Jenkins is a unit test / task launcher with a lot of plugins like GIT, MultiSCM, Rebluid, etc..

We have created jobs that will :

  • Checkout our project playbook, inventory and requirements file (with the Jenkins MultiSCM plugin)
  • Install the requirements in the job workspace (ansible-galaxy install -r requirements.yml)
  • launch the ansible playbook (ansible-playbook -i ${env}/hosts.txt playbook.yml

The job has some parameters like

  • git branch : the name of the git branch to use (master by default)
  • env : the name of the environnement we want to deploy (aka the inventory file)
  • extra var : if you want to specify some more extra vars
  • ansible options : to allow users to specify more options (–limit=apache for example).

jenkins_job

 

Then the job use the git or MultiSCM plugin to fetch playbooks from gitlab

jenkins_git_config

 

Don’t forget to create a deploy key in gitlab with the public key of the jenkins user (www-data for example).

And finally launch the playbook from the job workspace :

jenkins_build_step

Now every user with jenkins permissions can run deployments on any environment with just a few clicks

Conclusion

Ansible Galaxy with Gitlab and Jenkins give a lot of benefits :

  • Stabilization or Production deployments (no more forgotten tasks)
  • Shortest deployments duration (we can deploy all applications stack from scratch in less than an hour with ansible (a week before) )
  • Capitalization : each project can re-use roles from the galaxy and contribute !
  • Documentation : Gitlab integrate a wiki, so each role of the galaxy is documented. (We also have example projects, 10 steps tutorials)
  • Collaboration through Gitlab issue system.
  • Simplicity : Just click on the BIG DEPLOY button !

And you : which automation system are you using ? Chef ? Puppet ?

[QEMU] – Linux virtuel sur windows sans droits d’admins

Comme beaucoup, je travail en clientèle sur un poste de m**** qui ne  peut booter que sur Windows et, cerise sur le gâteau, nous n’avons aucun droits… Dans ce monde cruel on ne rêve que d’une chose, pouvoir utiliser Linux !

Continuer la lecture de [QEMU] – Linux virtuel sur windows sans droits d’admins

grafana-zabbix

   grafana+zabbix_logo_500x131

En lisant des news sur les comptes rendu de la conférence Zabbix 2015 qui a eu lieu à Riga la semaine dernière, je suis tombé sur un article qui parlait de grafana-zabbix : Un plugin datasource zabbix pour grafana.

Concrètement, cela permet de grapher n’importe quelle donnée issue de Zabbix directement depuis un Dashboard Grafana.

Du coup, ni une, ni deux j’ai téléchargé la dernière version de Grafana, qui est sortie récemment (avec une liste de features hallucinante !)

J’ai ensuite copié le répertorie zabbix du plugin grafana-zabbix dans le répertoire « public/app/plugins/datasource » de grafana, et c’est tout !

Il suffit ensuite de se rendre dans l’interface de Grafana et paramétrer une nouvelle datasource de type Zabbix, en spécifiant l’url de l’api Zabbix et de commencer à créer des Dashboards.

grafana-zabbix

On se retrouve rapidement avec des Dashboards super classe !

En plus il y a même moyen de Templatiser les écrans pour fournir le groupe zabbix et le host en paramètre, et actualiser automatiquement le tableau de bord !

Bref, un projet Github a suivre de près !

Et vivement les prochaines versions de Zabbix qui intègreront l’API directement dans la partie serveur (et donc codé en C avec un max de perfs !)

 

PS : Il est possible de patcher Zabbix pour include les trends dans la récupération d’historique zabbix via l’API.

 

 

Logstash input HTTP + gitlab

Depuis la nouvelle version de Logstash (1.5.2), il y a un nouveau type d’input qui est « http ». Cela permet, depuis n’importe quel autre application d’envoyer des données au format json directement dans logstash.

Ensuite, grâce aux multiples plugins filter et output, il est possible de convertir et exporter ces données comme on le souhaite.

gitlab

Au taf, on utilise Gitlab pour administrer les projets sous git. Du coup j’ai configuré un web hook sur mes projets pour envoyer directement les stats de commit / issues / merges / etc dans ELK.

dans logstash, il suffit de créer un nouveau input :

input {
    http {
      port => 8084
    }
}

Et ensuite, dans Gitlab, configurer le web hook pour envoyer les données directement dans logstash.

logstash-gitlab-http-hook

 

Enfin,  après chaque commit, un message http est envoyé est envoyé au logstash qui va l’insérer dans la base elasticsearch.

Il ne reste plus qu’a configurer un petit Dashboard Kibana pour avoir les stats du nombre de commits par branches / utilisateur / etc..

Et voila le résultat :

kibana-commits-par-branche

Ansible pour déployer des agents Zabbix + auto-registration

ansible_logo-360x288+ zabbix_logo_500x131

Depuis quelques temps, j’utilise Ansible au boulot, et je doit dire c’est un outil super classe !

Je vais décrire ici comment déployer des agents Zabbix sur un ensemble de serveurs grâce à Ansible.

Rôle zabbix_agent

Voici le playbook zabbix_agent :

zabbix_agent.yml

---
- hosts: all:!localhost

  roles:
    - role: zabbix_agent

roles/zabbix_agent/task/main.yml

---
- name: "[zabbix_agent - linux] Installation agent zabbix"
  yum: name={{ item }} state=present
  with_items:
    - "zabbix-2.4.2-1.el6.x86_64.rpm"
    - "zabbix-agent-2.4.2-1.el6.x86_64.rpm"
  sudo: yes

- name: "[zabbix_agent - linux] Configuration de l'agent zabbix"
  template:
    src: "etc/zabbix/zabbix_agentd.conf.j2"
    dest: "/etc/zabbix/zabbix_agentd.conf"
    mode: 0644
  register: zabbix_config_updated
  sudo: yes


- name: "[zabbix_agent - linux] Demarrage de l'agent"
  service: name="zabbix-agent" state="restarted"
  when: zabbix_config_updated|changed
  sudo: yes

Il est bien sur possible d’étendre ce rôle pour qu’il puisse déployer des agents sur d’autres types de serveur (debian, aix, etc..)

roles/zabbix_agent/templates/etc/zabbix/zabbix_agentd.conf.j2

---
LogFileSize=0
Server={{ zabbix_server }}
ServerActive={{ zabbix_server }}
Hostname={{ inventory_hostname }}
HostMetadata={{ zabbix_metadata if zabbix_metadata is defined else "" }},{{ ansible_system }}
Include=/etc/zabbix/zabbix_agentd.d/

roles/zabbix_agent/vars/main.yml

---
zabbix_server: "IP DU SERVEUR ZABBIX"

Configuration Zabbix

Host Groups

Il faut d’abord créer des hosts groups dans Zabbix pour pouvoir « ranger » les équipements.
Par exemple, créer un host group « Recette » dans lequel on va ranger tous les serveurs de recette.

Actions

Une étape indispensable avant de lancer le playbook zabbix_agent est de configurer les règles d’auto-registration dans Zabbix.
Pour cela, aller dans le menu Config->Actions et sélectionner « auto-registration » dans le menu déroulant.
Puis, cliquer sur créer une nouvelle règle.

Dans le premier onglet Action, choisir un nom sympa pour cette règle. Par exemple « Linux auto-registration Recette »
Dans le second onglet Conditions, choisir les options « host metadata » like « recette » et host metadata like « linux »
Dans le troisième onglet Operations, choisir :

  • Add Host
  • Add host to host group Recette
  • Link host to template « Template OS Linux »

Lancement du playbook

Enfin, il ne reste plus qu’à lancer le playbook zabbix_agent en lui spécifiant le fichier d’inventaire de recette et les options zabbix_metadata qui vont bien :

ansible-playbook zabbix_agent.yml -i inventory/recette --extra-vars="zabbix_metadata=Recette"

Et voila !
Si tout se passe bien ansible va déployer un agent zabbix sur le serveur, configurer celui-ci avec la bonne IP du serveur zabbix et les méta données qu’on a fourni en paramètres.
Ensuite, le serveur Zabbix va auto ajouter les équipements en les classant dans les bons groupes et y associer les bons templates.

Petite astuce :
* Ne pas hésiter à créer plein de groupes zabbix pour ranger les équipements (un host peut bien évidement appartenir à plusieurs groupes)
* Utiliser le bouton « Cloner » dans la configuration des actions pour créer plein de règles en fonction des méta données (Linux + Recette, Aix + Recette, Linux + Préprod, Aix + Préprod, Linux + préprod + backup, etc…)

Ansible + Jenkins : Le combot qui déboite !

AnsibleLogo_transparent_web

Ansible est un outil de déploiement et de gestion de configuration super efficace, et surtout super simple à utiliser !

En effet, il se base sur des fichiers de configuration en YAML, et donc facilement lisible par un être humain.

Le principe d’Ansible est de lancer des « playbooks » qui vont alors lancer des tâches sur un ensemble de serveurs dans l’ordre où elles ont été écrites.

Par exemple, on peut avoir un playbook apache.yml qui va installer et configurer apache sur tous les serveurs du groupe « apache » définis dans le fichier d’inventaire ansible.

Ansible utilise pour cela des « rôles » qui définissent un ensemble de tâches, par exemple :

  • installer le package (apt-get / yum install)
  • Copie le fichier de configuration à tel endroit
  • Relance le service en cas de modification du fichier de conf, etc…

Il suffit alors de lancer la commande :

ansible-playbook apache.yml

et Ansible va se connecter en ssh sur tous les serveurs correpondant, et effecter les tâches si c’est nécessaire..

Bien sur il est important de versionner ces fichiers de configuration ansible dans un gestionnaire de source (GIT / SVN / Mercurial).

 

687474703a2f2f6a656e6b696e732d63692e6f72672f73697465732f64656661756c742f66696c65732f6a656e6b696e735f6c6f676f2e706e67

A partir de là, pourquoi ne pas utiliser un outil d’intégration continue comme Jenkins pour automatiser tout ça ?

Il suffit alors de créer un job jenkins paramétrable, qui va récupérer la configuration ansible depuis le repository puis lancer le playbook correspondant.

Une fois les Jobs Jenkins bien paramétrés, et la conf ansible préparée, on obtient alors une interface web simple qui permet à n’importe qui de lancer le déploiement d’application en ayant simplement à fournir un fichier d’inventaire et quelques variables de paramétrage.