CérénIT

Il y a de cela une dizaine de jours, la partition système d’un serveur d’un de nos clients est passé en lecture seule suite à un problème de consistence sur le disque. Pour les services en cours et ne dépendant pas de fichiers sur cette partition, les services continuaient de fonctionner. Pour les autres, ils étaients hors service ou dans une situation de dsyfonctionnement dès lors qu’ils avaient besoin d’écrire un fichier sur la partition système.

Pour rétablir le service dans les plus brefs délais et investiguer ce problème dans un second temps, nous avons décidé de créer un nouveau serveur, de lui attacher les données et l’IP du serveur hors-service. Cette opération a été grandement facilitée vu que nous utilisons dans ce cas l’offre IAAS de Gandi : en quelques clicks, un nouveau serveur a été provisionné, et les disques contenant les données et les backups ont été attachés au nouveau serveur.

Vient alors Ansible : grâce aux playbooks, préalablement rédigés par nos soins, pour installer l’ensemble des logiciels et le paramétrage associé des serveurs de notre client, le serveur était opérationnel dans les 15 minutes. Quelques tests plus tard, nous pouvions alors migrer l’IP de l’ancien serveur vers le nouveau et rendre le site à nouveau accessible au bout de 30 minutes environ.

Malheureusement, toutes les modifications et quelques actions n’étaient pas encore reportées ou rédigées dans nos playbooks. L’heure suivante a donc consisté à rattrapper ces informations et jouer les actions manquantes. Depuis lors, elles ont été réintégrées dans les playbooks .

Au final, en 1h30 après décision de reconstruire le serveur, le service était totalement rétabli et avec un retour partiel au bout de 30 minutes environ. Si nous avions du rejouer toute l’installation à la main, cela aurait durer bien plus de temps et avec des risques d’erreurs / oublis non négligeables et sans parler du doute persistent : a-t-on bien tout récupéré ?

Un crash serveur est une situation stressante pour tout le monde ; il est agréable de pouvoir compter sur un outil comme Ansible pour garantir l’état final d’un serveur (prédictibilité). Cela apporte une certaine sérénité et permet de rétablir le service au plus vite pour le bien de tous. Au-delà du premier déploiement, cela requiert une certaine hygiène de vie du serveur pour maintenir les playbooks à jour.

Docker

La version 1.12 apporte son lot de nouveautés :

• Docker 1.12: Now with Built-in Orchestration! ; une version “améliorée” de swarm est intégrée nativement dans Docker ; en gros Docker s’orchestre lui-même.
• Announcing the Docker for Mac and Windows Public Beta : après une phase de béta privée, une phase de béta publique.
• Introducing the Docker for AWS and Azure Beta : dans la même veine que Docker for Mac/Windows, une solution rapide pour monter un environnement docker sur AWS/Azure ; en s’appuyant bien sûr sur les capacités d’orchestration de Docker 1.12.
• Introducing Experimental Distributed Application Bundles ; là encore, on peut le voir comme une version améliorée de docker-compose et l’idée est de pouvoir déplaoyer des applications sous la forme d’un “bundle”.
• More Microservices Bliss with Docker 1.12 and Swarm only : l’article permet d’avoir un avant/après pour mieux comprendre les apports de la 1.12 et voir en quoi elle simplifie la gestion du cluster et le déploiement d’application. Il semblerait que consul ait disparu à moins que pour le moment seul la création d’un cluster par token soit supporté. Je nuancerai également le point sur l’absence de besoin d’un reverse proxy, si cela peut ne pas être nécessaire dans une logique de laboratoire, pour de la production, cela me semble nettement plus discutable.
• How to use Docker 1.12 Built-In Orchestration and Service Creation : un autre exemple sur les apports de la version 1.12
• Introducing the Docker Store Private Beta : Docker lance une market place, version améliorée de Docker Hub permettant aux distributeurs de logiciels d’avoir un nouveau canal de diffusion et un certain nombre de services (sécurité, conformité de licences, etc)
• Xebian était présent à la DockerCon 16 : compte-rendu en français de la conférence par Xebia.

OrientDB

• Pattern matching with OrientDB : pour un cas d’usage d’une connaissance, nous avons investigué les données Graph comme OrientDB pour matérialiser des relations et des inter-connexions. Le billet montre comment via des requêtes SQL on peut parcourir le graph et définir des pattern.

HTML/JS/CSS

• Comparaison de plugins JS : les select widgets ; “Beaucoup de plugins existent pour rendre plus beaux ou plus pratiques les éléments HTML select, petite comparaison pour choisir le bon”

Streams

• Apache Kafka and Kafka Streams at Berlin Buzzwords ; la CTO de Confluent a fait un tour d’Europe où elle présente Kafka, Kafka Connect et Kafka Streams et surtout sa vision du Stream processing et les impacts que cela a sur notre façon de développer des applications et consommer de la donnée. Ils ont une approche assez pragmatique du sujet, l’ayant mis en place notamment chez LinkedIn et chez d’autres clients.
• Why Apache Beam ? : Beam est un projet Apache et la version Open Source de ce qu’a implémenté Google pour sa plateforme Google Cloud Data Flow. C’est un modèle de programmation pour traiter de la donnée dans une logique de streaming. Le billet porte sur l’intégration de Beam dans Flink (un moteur de processing temps réel). De quoi voler la vedette à Spark Streaming ?

Elasticsearch & friends

• Elastic Stack Release 5.0.0-alpha3 : Elastic continue son bonhomme de chemin avec diverses améliorations et efforts de stabilisations pour l’ensemble de leurs produits. On notera aussi quelques incompatibilités ascendentes (gestion des propriétés d’Elasticsearch) dans le cadre de la version 5.0

Big Data

• Hue 3.10 with it’s new sql editor is out : Hue, une interface web d’accès et de suivi des données et des jobs d’une plateforme Hadoop est sortie fin mai dernier avec son lot de nouveautés et notamment une refonte graphique.

Git

• Git, the simple guide : un revue très claire des principales commandes git ; existe en plusieurs langues.

Architecture Serverless

• Serverless architectures : c’est le buzzword du moment, l’idée consiste à dire qu’on ne gère plus des serveurs mais que l’on déploie son application sur la base de différentes services cloud. On y voir la notion de “Backend as a service” ou de “Function as a Service”. L’idée étant que pour chaque foncitonnalité attendue (stockage, authentification, etc), l’application finale s’appuie sur n services et que l’entreprise développant l’application ne possède en soi aucun serveur.

Traefik

• Pour les amateurs de containers docker au format ARM : traefik-arm
• Traefik active load balancer on Ranger : Rancher, une solution d’orchestration de containers Docker, intègre Traefik en mode expérimental.

OrientDB

• OrientDB v2.2 GA - Improved Security, Performance, Operations & APIs : la base qui mixe documents et graph sort en version 2.2 avec diverses améliorations de performances, sécurité et un nouveau module Teleporter pour faciliter la migration de bases SQL vers OrientDB. Une série de billets présente Teleporter (OrientDB Teleporter - Making Migrations Easier (Part 1), OrientDB Teleporter - Making Migrations Easier (Part 2))

Ansible

• Six Ways Ansible Makes Docker-Compose Better : Etat des lieux et perspective sur l’intégration Ansible/Docker pour faciliter la vie de ses déploiements.
• Introducing Ansible 2.1: Networking, Windows, Azure, and Containers : Ansible dans sa version, amène des améliorations sur la gestion des équipements réseaux (Ciso, Juniper, etc), un meilleur support d’Azure et Windows et pour ce qui m’intéresse et comme décrit précédemment, un support de docker plus complet.

Revue de code

• Mention bot, cibler la revue de code : Eric nous fait découvrir, en plus du feedback par emoj, mention-bot qui permet de déterminer qui doit relire les Pull Requests (PR) d’un projet.

Kafka

• Announcing Kafka 0.10 and Confludent Platform 3.0 :
  • Kafka 0.10 : Les Kafka streams sont officiels ; cf Introducing Kafka streams ; stream processing made simple
  • Kafka 0.10 : Les messages ont maintenant un timestamp
  • Dans sa version propriétaire, Confluent Platform se dote d’une interface de monitoring “Confluent Control Center” et d’une interface de gestion des connecteurs.
• Open sourcing Kafka Monitor ; LinkedIn rend open source son framework de monitoring Kafka qui semble aussi faire des tests de non régression.
• Paris Kafka Meetup -Introduction, concepts et architecture : Présentation assez claire sur Kafka ; à voir si les slides sont suffisament autoportantes ou pas.
• Paris Kafka Meetup - How to develop with Kafka : Premières intéractions avec un cluster Kafka coté Producer et consomumer.

Python

• Python et HTML : David a publié une collection de librairies python pour manipuler du HTML en Python. J’utilise déjà la magnifique requests, je vais pouvoir en ajouter quelques-unes à la liste.

Elasticsearch

• How to make a Dockerfile for Elasticsearch : Si vous souhaitez bâtir votre propre container plutôt que d’utiliser [l’image officielle(https://hub.docker.com/_/elasticsearch/)]
• Docker networking avec Elastiscsearch : rien de nouveau sur le réseau mais plutôt sur le moyen de bien configurer Elasticsearch et Docker
• Effective elasticsearch plugin management with Docker : la gestion des plugins qui peut avoir un impact sur les volumes (notamment pour la partie config).

REST

• Repenser ses échanges de données client-serveur sur le Web ; un billet qui énonce les limites du protocole REST et surtout présente les approches de Falcor (Netflix) et GraphQL (Facebook) pour compenser ces manques.