En ce moment je joue avec Ansible au boulot pour installer et configurer un serveur sous CentOS 7. Parmi toutes les applications à installer, j’ai buté un moment sur l’installation d’un serveur MySQL en version 5.7.

A partir de cette version, la configuration par défaut du compte root change et un mot de passe temporaire est généré pour la première connexion. Du coup, la plupart des “playbook“ ou “roles“ que j’ai essayés ne fonctionnent plus. Si vous êtes dans ce cas-là aussi, voici le playbook que j’ai mis en place et qui a priori fonctionne:

---
- hosts: my-centos-server
  ## Variables ##
  vars:
    mysql_root_password: ASuperSecurePassword
  ## Tasks ##
  tasks:
  - name: Get YUM repository for MySQL
    get_url:
      url: http://dev.mysql.com/get/mysql57-community-release-el7-7.noarch.rpm
      dest: /tmp/mysql57-community-release-el7-7.noarch.rpm
  - name: Install YUM repository for MySQL
    shell: /bin/rpm -Uvh /tmp/mysql57-community-release-el7-7.noarch.rpm
    register: yum_repo_resturn
    failed_when: "'conflict' in yum_repo_return.stderr"
  - name: Install MySQL community server
    yum:
      name: mysql-community-server
      state: present
  - name: Launch MySQL service
    service:
      name: mysqld
      state: started
      enabled: yes
  - name: Install required python MySQLdb lib to create databases and users
    yum:
      name: "{{item}}"
      state: present
    with_items:
      - gcc-c++
      - MySQL-python
  - name: Get temporary MySQL root password
    shell: grep 'temporary password' /var/log/mysqld.log | awk '{print $NF}'
    register: mysql_root_temp_password
  - name: Set the MySQL root password
    shell: mysqladmin -u root --password="{{ mysql_root_temp_password.stdout }}" password "{{ mysql_root_password }}"
    register: mysql_admin_root_password_result
    failed_when: "'(using password: NO)' in mysql_admin_root_password_result.stderr"
  - name: Tune MySQL configuration
    template:
      src: ./resources/my.cnf
      dest: /etc/my.cnf
      mode: 0644
    notify:
      - restart mysqld
  - name: Create my datatable
    mysql_db:
      login_user: root
      login_password: "{{ mysql_root_password }}"
      name: MY_DATATABLE
      encoding: utf8
      collation: utf8_bin
  - name: Create MY_DBA user in MySQL and grant privileges
    mysql_user:
      login_user: root
      login_password: "{{ mysql_root_password }}"
      user: MY_DBA
      password: AnOtherSuperSecurePassword
      host: '%'
      priv: 'MY_DATATABLE.*:ALL'
  ## Handlers ##
  handlers:
    - name: restart mysqld
      service:
        name: mysqld
        state: restarted

Attention bien sûr de ne pas pousser un tel playbook contenant le mot de passe root sur un repo public !

Commenter et partager

Il y a une dizaine de jours, j’entamais une semaine de test pour essayer d’appliquer au travail la technique Pomodoro, découvert lors de ma lecture de Soft Skills.

Pomodoro c’est quoi ?

Pomodoro est une technique de travail permettant d’augmenter sa productivité. Rien que ça !
Le but est de se concentrer sur une seule tâche à la fois en évitant le “task switching” et ainsi ne pas perdre un temps de “mise en condition” à chaque (re)démarrage de tâche.

Contexte équipe et pourquoi maintenant

Je travaille actuellement au sein d’une équipe d’environ 10 personnes, dans un open space, en pratiquant Scrum. Cela facilite la communication entre nous et nous permet aussi d’être tous plus ou moins au courant de ce que chacun fait.

Nous travaillons ainsi depuis plusieurs mois et nous avons entamé la dernière phase du projet de construction, celle où les complications se présentent ! Davantage d’interrogations fonctionnelles, de cohérence globale, plus de bugs, plus de code mort, plus de questionnement. Et donc un plus gros besoin de communication. C’est normal.

Mais la contrepartie est qu’il est plus difficile de trouver un créneau pour se concentrer 2h sur une tâche qui nécessite beaucoup d’attention. Voilà pourquoi j’ai donné sa chance à Pomodoro.

Fonctionnement

Le principe est simple, un pomodoro est composé de deux étapes:

• 25 min de travail “intensif”: focus sur une tâche, pas de distraction, pas de notification, pas de mail, pas d’interruption de la part des collègues…
• 5 min de pause: marche pour détendre les muscles, réponse aux questions des collègues, …

Tous les 4 pomodori, une pause plus longue (15-20 min) pour prendre un café et s’aérer l’esprit.

Il s’agit en premier lieu d’une rigueur qu’on s’impose à soi-même pour ne pas être distrait: ne pas checker ses mails constamment ou sauter sur la première notification peut être compliqué au début. Mais quand on travaille dans une équipe de 10 personnes en open-space, l’environnement externe compte autant de distractions (si ce n’est plus) que son propre contexte individuel. Alors comment on fait ?

Mise en place

La clé est de bien prendre le temps d’expliquer en quoi Pomodoro consiste et pourquoi on le fait (manque de plage de temps à consacrer à une activité) et que ce n’est absolument pas une poussée d’associabilité soudaine !
Insister sur le fait que l’on n’est pas complètement indisponible si une question bloquante se présente à un collègue ou si le besoin d’un coup de main se fait sentir. Juste que si la question peut attendre un peu, on sera entièrement disponible et l’esprit libre pendant 5 min et plus si besoin, dans 25 minutes maximum !

Ensuite les 25 minutes sont assez facile à mettre en pratique si on part d’une base Scrum:

• on découpe un peu plus finement les tâches qu’on s’est assigné au Daily Scrum
• on met en place un timer (un plugin Chrome simple me suffit)
• on choisit une marque/repère qui permet à l’équipe de savoir qu’on est en cours de pomodoro (j’ai choisi les écouteurs car cela permet aussi de se mettre dans une bulle même si cela peut avoir quelques inconvénients, j’y reviens plus loin)
• on se met une bonne dose de rigueur sur les mails et réseaux sociaux (désactivation des notifications notamment)

Pendant les 5 minutes de pause, j’essaye de me lever le plus souvent possible pour deux raisons: cela permet un relâchement musculaire et aussi de montrer clairement que je suis disponible pour des questions, un coup de main, etc, …

Ca marche ?

Oui. Trop bien même. J’étais rincé mentalement le premier soir !
Mais par contre j’avais sorti une bonne journée de développement !

J’attribue cette fatigue à deux choses:

• un trop grand nombre de pomodori dans la journée (9 le premier jour)
• la musique, qui même si elle est assez efficace pour se couper du reste de l’open-space, ajoute quand même il me semble une fatigue mentale

Je me suis donc adapté en ne faisant que 6-8 pomodori les bons jours (ceux sans ces chronophages réunions) et en coupant la musique un pomodoro sur deux, en gardant juste le casque sur les oreilles.

Voilà, à chacun de trouver son équilibre ! Et vous, vous avez déjà essayé ?

Commenter et partager

Elixir ? C’est quoi ?

Une marque de bière !
Oui mais pas que. C’est aussi le nom d’un langage dynamique, fonctionnel, concurrentiel et fun !
On en parle de plus en plus et la communauté est très active avec une nouvelle version (1.2) qui date tout juste du mois de Mars.

Basé sur Erlang, et sa machine virtuelle Beam, créé par Ericsson pour être utilisé dans des appareils de télécommunications, Elixir en tire des propriétés intéressantes comme l’Open Telecom Platform (aka OTP, communication entre les services), la tolérance à la panne (supervisor) et le rechargement de code à chaud.

Pourquoi m’y intéresser ?

Ça peut paraître étonnant mais au jour d’aujourd’hui, je n’ai pas trouvé de technologie qui me donne entière satisfaction pour écrire un backend organisé en micro-applications ou micro-services

Java

• même si Spring Boot fait du bon boulot pour rendre la tâche plus facile, il y a encore beaucoup de verbosité et de configuration pour organiser un backend en plusieurs applications indépendantes
• les applications sont quand même assez longues à démarrer comparés à d’autres technologies (NodeJS par exemple) et ça joue sur le temps d’exécution des tests
• le refactoring est assez lourd, même si mon IDE en fait une grosse partie (avez-vous déjà essayer de renommer une micro-application ?)

JavaScript

• Express : à chaque fois que je redonne une chance à Express, je m’en veux dès que j’ai à configurer un ou deux middlewares (passportjs, connexions ssl, etc)
• HapiJS : j’avais bien accroché (voir ici), surtout pour l’approche configuration plutôt que code (comme c’est le cas dans Express). Beaucoup de plugins pour faire des choses sympas mais quand on veut sortir des sentiers battus, aïe (je n’ai pas réussi à autoriser des connexions ssl…)

Je n’ai pas tout essayé (il faudrait peut-être que je donne une chance à Vert.X ou Wisdom) mais quitte à essayer quelque chose d’autre, j’ai choisi d’y aller à fond.

Et Elixir fait mieux ?

Je ne sais pas. Je débute.

Mais il y a quelques indices qui m’incitent à pousser l’apprentissage un peu loin :

• programmation fonctionnelle -> ce dont j’ai besoin la plupart du temps dans mes backend REST, c’est des morceaux de code stateless qui appliquent un traitement à des données.
  Et bien c’est le cas d’usage parfait pour de la programmation fonctionnelle (parallélisme, enchaînements de tâches simples, etc)
• utilisation des actors -> les actors sont un modèle de concurrence qui impliquent des process indépendants qui ne partagent pas d’état et qui communiquent par messages.
  Ça me paraît bien pour faire des micro-services indépendants, non ?
• OTP -> l’Open Telecom Platform permet de faire communiquer simplement nos process et même de les superviser pour les redémarrer en cas de crash (tolérance à la panne) ainsi que de les monitorer (usage CPU, RAM, applications lancées, etc).
  Et tout ça, inclus de base !
• mix -> mix est la chaîne d’outils d’Elixir. Elle permet de gérer les dépendances avec hex, de compiler, de lancer les tests, de générer la documentation à la JavaDoc, lancer des applications, etc.
  Ce qui me plaît le plus avec mix (outre le fait que c’est un vrai couteau suisse), c’est qu’il révèle une véritable culture du test (même les exemples de la documentation sont inclus dans l’exécution des tests…). Et ça, ça me plaît.

Penser autrement

Je ne vais pas entrer plus loin dans le détail. L’apprentissage d’Elixir est un peu déroutante quand on est habitué à la programmation objet (pattern matching partout, récursion à fond, pas de boucle, etc) mais elle en vaut la peine, ne serait-ce que pour apprendre à penser autrement.
Pour ça je vous conseille la lecture du très bon Programming Elixir 1.2 de Dave Thomas et surtout de réaliser les exercises qu’il contient. Ce n’est qu’à cette condition que votre lecture sera efficace. Et n’hésitez pas à partager vos implémentations, voici les miennes.

Mais ce n’est pas tout

Elixir a indubitablement quelque chose à apporter dans la conception de nos backend.
Ça se sent. Mais ce n’est pas tout.
On a un autre outil à notre disposition pour nous aider: Phoenix, LE framework web écrit en Elixir !

Ça sera l’objet de ma prochaine lecture, Programming Phoenix et de mon prochain post.

Think differently !

Commenter et partager

Let’s Encrypt est un projet d’autorité de certification gratuite, automatisé et libre.

Concrètement, cela nous permet notamment d’avoir des sites et applications web en https, reconnues comme dignes de confiance par les navigateurs internet. Et cela sans payer et surtout basé sur des logiciels open source !

La beta est ouverte au public depuis jeudi, j’en ai donc profité pour remplacer les certificats auto-signés de mon GitLab sous Nginx par de vrais certificats “made by” Let’s Encrypt.

Installation et génération des certificats

L’installation de Let’s Encrypt est simple, il suffit de cloner le repository et de lancer un script qui va installer la bonne version du logiciel selon l’OS.

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help

La cible de Let’s Encrypt est de fournir un service permettant d’automatiser la génération des certificats et leur renouvellement. Cela marche bien pour un serveur Apache mais pas encore pour Nginx (ne pas oublier que c’est une beta).

On va donc lui demander de seulement générer les certifacts et de ne pas tout gérer. Pour cela, il suffit de stopper Nginx (la coupure ne sera pas très longue) et lancer la génération du certificat pour son domaine.

sudo nginx -s stop
./letsencrypt-auto certonly --standalone -d my-gitlab-domain.fr -d www.my-gitlab-domain.fr

Et voilà, les certifacts sont prềts dans /etc/letsencrypt/live/my-gitlab-domain.fr/

Redémarrer nginx et configurer le domaine

On redémarre le service Nginx.

sudo service nginx start

Et on modifie la configuration de notre serveur Nginx.

server {
	listen 443;
	listen [::]:443;
	# Make site accessible from http://localhost/
	server_name www.my-gitlab-domain.fr my-gitlab-domain.fr;
	ssl on;
  ssl_certificate /etc/letsencrypt/live/my-gitlab-domain.fr/cert.pem;
  ssl_certificate_key /etc/letsencrypt/live/my-gitlab-domain.fr/privkey.pem;
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/my-gitlab-domain.fr/fullchain.pem;
	location / {
    ...
  }
}

On recharge la configuration pour qu’elle soit prise en compte par Nginx.

sudo ngnix -s reload

Le tour est joué !

Renouvellement

Le certificat est valide pour 60 jours et sans renouvellement automatique pour Nginx pour l’instant, il suffira de relancer la commande pour le renouveller.

./letsencrypt-auto certonly --standalone -d my-gitlab-domain.fr -d www.my-gitlab-domain.fr

Sources:

• https://letsencrypt.org/howitworks/
• https://community.letsencrypt.org/t/nginx-installation/3502/5

Commenter et partager

Dans le cadre d’un projet basé sur Hapi.js (je reviendrai dessus dans un prochain article), j’ai pris un peu de temps pour améliorer la façon de déployer mes applications Node.js.

Voici ce que j’ai mis en place pour mes petits projets.

Déployer à chaque “git push”

Quoi de plus sympa qu’une application qui se déploie en production sur un simple commit/push ? Rien, on est bien d’accord ?
Je me suis donc inspiré de cet article pour mettre en place, sur mon serveur Ubuntu, un bare repository vers lequel je push lorsque je veux déployer mon application.

branches  config  description  HEAD  hooks  index  info  objects  refs

Je définis une action sur l’événement post-receive, ce qui se fait simplement en créant un fichier du même nom dans le répertoire hooks.

#!/bin/sh
GIT_WORK_TREE=/opt/my-app git checkout -f
cd /opt/my-app
npm install

Ainsi à chaque push, un checkout est fait dans le repertoire d’installation de mon application (un git clone ayant était fait manuellement la première fois) puis un npm install pour mettre à jour mon application.

Facile, non ?

Oui. Un peu trop facile peut-être…

Mettre à jour son application d’un simple push c’est cool, mais encore faut-il s’assurer que la qualité est toujours au rendez-vous. Mon projet étant hébergé sous GitHub, j’utilise Travis CI comme outil d’intégration continu, parfaitement intégré puisqu’il déclenchera un build à chaque push sur GitHub.
Il se configure assez simplement grâce au fichier .travis.yml à la racine du projet.

sudo: false
language: node_js
node_js:
- 4.0
services: mongodb
addons:
  apt:
    sources:
    - mongodb-3.0-precise
    packages:
    - mongodb-org-server
...
...

On déclare le langage et runtime qu’on utilise (ici Node.js v4) et les services dont on a besoin (ici MongoDB en l’installant à chaque build).

...
...
  ssh_known_hosts:
    - my.server.fr
after_success:
  - eval "$(ssh-agent -s)"
  - mkdir ~/.ssh
  - mv .travis-config ~/.ssh/config
  - mv .deploy.pem ~/.ssh/deploy.pem
  - chmod 600 ~/.ssh/deploy.pem
  - git remote add deploy ssh://user@my.server.fr/opt/my-app-bare
  - git push deploy master
before_install:
  - openssl aes-256-cbc -K $encrypted_d3a1e9dbde14_key -iv $encrypted_d3a1e9dbde14_iv
    -in .deploy.pem.enc -out .deploy.pem -d

Et vient la partie un peu plus velue.

Tout d’abord, on met en place la tuyauterie pour ssh en rajoutant notre serveur comme hôte de confiance (ssh_known_hosts) puis en décodant notre clé privée ssh (before_install) qui sera utilisé par Travis pour faire le push et qui avait été commit encryptée sur le repository.
La partie intéressante se trouve dans le after_success, juste après la tambouille pour initialiser la connexion ssh, on ajoute notre bare repository sous le nom deploy et on pousse notre branche master vers ce deploy.

Voilà, on a automatisé notre push vers notre serveur de production lorsqu’on push sur GitHub.

Bon, c’est bien joli tout ça mais en apparence on ne fait que dire à Travis de faire un push une fois le build terminé, ce qu’on savait déjà faire manuellement…

En apparence seulement, car ce qui est bien avec Travis c’est que si une cible test est présente dans notre package.json, il va l’exécuter automatiquement et la prendre en compte dans son résultat de build !
Ainsi si nos tests ne passent pas, le build est en échec et notre application n’est pas redéployée.
On peut même aller encore plus loin en fixant un seuil minimal de couverture de code de nos tests en dessous duquel ils sont considérés en échec. C’est ce que je fais avec Lab, l’outil de test de Hapi.js, avec la commande suivante qui fixe le seuil de couverture à 95% :

lab -c -t 95 -L

Sympa non ?

Oui. Mais c’est pas suffisant…

C’est pas suffisant parce que même si notre application est installée à la volée, il faut que notre serveur Node.js redémarre pour prendre en compte toutes les modifications. Pour ça, j’utilise PM2 en mode watch qui est un utilitaire qui va monitorer nos serveurs Node.js.

Ainsi lorsque des fichiers vont être mis à jour par notre push, PM2 va automatiquement redémarrer le serveur Node.js qu’on lui avait spécifié avec la commande :

pm2 start my-app.js

Cool !

PM2 est un outil vraiment sympa qui possède plein de fonctionnalités. Je vous recommande d’y jeter un oeil si vous ne connaissez pas.

Bonus

Bien, notre application est redéployée à chacun de nos push à condition que la qualité soit là et les modifications sont prises en compte sans qu’on ait à intervenir grâce à PM2.

Ce qui serait sympa, c’est d’avoir toutes les infos de build, de couverture de tests, versions de nos dépendances, etc, centralisées dans un seul endroit. Et les badges du README.md sont parfaits pour ça.

Les versions de dépendances npm (prod et dev) sont fournis par david-dm.org, le status de build par Travis et la couverture de code par Coverall.io qui se plugge lui-aussi sur GitHub.

Pour transmettre les informations à Coverralls, j’ai rajouté un script coverage dans package.json qui lance coveralls en sortie de rapport de Lab :

lab -c -L -r lcov | ./node_modules/.bin/coveralls

Je rajoute l’appel à ce script (npm run-script coverage) dans la cible after_success du fichier .travis.yml et le tour est joué.

Tous les outils utilisés ici sont gratuits pour des projets open-source.

Enjoy !

Commenter et partager

Commenter et partager

Deuxième étape de ma cure de rattrapage Java après Effective Java, The Well-Grounded Java Developer est un livre introduisant les nouveautés de Java 7 ainsi que les langages polyglottes tournant sur la JVM. Il a été écrit par Ben Evans, membre du comité exécutif du Java Community Process, et Martijn Verburg, coleader du London JUG, entre autres.

J’ai choisi ce livre car il permet à la fois de faire le tour des nouveautés Java 7 (Project Coin, NIO.2), de rentrer dans des sujets techniques (injection de dépendances, concurrence, manipulation de .class et bytecode) ainsi que de faire un tour d’horizon des nouveaux langages développés sur la JVM (Groovy, Scala, Clojure), en terminant sur une touche de software craftsmanship : mixer de façon judicieuse tous ces langages pour tirer partie de leurs qualités respectives.

Je conseille fortement ce livre à tous ceux qui, comme moi, auraient mis Java entre parenthèses ces dernières années et qui seraient restés bloqués à Java 6. Même si j’aurais aimé que certains points soient un peu plus approfondis, on voit beaucoup de choses, on découvre un tas de sujets et on code aussi ! Et les pages défilent très vite.

J’ai vraiment apprécié la partie polyglotte et notamment le fait chacun des langages présentés soit approfondi en mettant l’accent sur un de leurs points forts, avec pour chacun un petit projet à coder :
    - GRails, framework web orienté “rapid web development” pour Groovy
    - ScalaTest, framework de tests pour Scala
    - Compojure, framework web pour Clojure

Un livre à garder dans sa bibliothèque et à ressortir souvent. Cerise sur le gâteau, pour l’achat en version papier, Manning offre l’ebook en multiples versions et non-limité dans le temps, ce qui est un vrai plus pour emporter sa lecture partout !

Commenter et partager

Commenter et partager

Commenter et partager