CérénIT

Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)

Web, Ops & Data - Semaine 41

docker microsoft windows kubernetes kubeadm ansible postgres rethinkdb elasticsearch vue.js

Container & Orchestration

Ansible

  • Ansible Container 0.2.0 Release : ansible-container est une extension ansible qui doit permettre de créer des images docker et de les orchestrer depuis des playbooks Ansible. Cette version 0.2 montre les améliorations apportées grâce aux retours de la communauté et le chemin restant à faire pour être plus facile à utiliser.

Base de données

  • Postgres 9.6 Released ! : comme tous les ans au mois de septembre, une nouvelle version de la base de données Postgres. Au programme notamment de cette version 9.6 : parallélisme des requêtes, nouveaux mode de réplication synchrone et de fédération, amélioration des recherches orientée phrase (ie ensemble de mots).
  • RethinkDB is shutting down : l’entité commercial derrière RethinkDB (base documentaire orientée temps réel) ferme faute d’avoir trouvé un modèle économique adéquat. Il y a une réflexion pour voir comment la communauté peut continuer à maintenir RethinkDB et à ouvrir le code d’Horizon.

Elasticsearch

  • An Elasticsearch cheat sheet : une collection de commandes utiles pour gérer un cluster Elasticsearch dès lors que l’on sort d’un usage basique.
  • Docker Stats Monitoring: Taking Dockbeat for a Ride : une introduction à Dockbeat (anciennement Dockerbeat) et son intégration dans une plateforme ELK. Il a le mérite de remonter des métriques sur vos containers (CPU, RAM, etc). Cela n’empêchera pas de devoir ajouter une seconde solution pour la remontée des logs systèmes / applicatifs.

Frontend

  • Vue 2.0 is Here! : le framework Javascript qui fait de l’ombre à AngularJS voir même à Réact sort en version 2.0 avec des améliorations de performances, améliorations des API, etc. Pas encore eu le temps de tester ça mais de la présentation vue à DevoxxFR cela semblait plus léger et moins inutilement complexe qu’AngularJS.

Ansible, à la rescousse en cas de crash serveur

ansible automatisation crash rto rpo incident

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.

Web, Ops & Data - Semaine 22

kafka orientdb confluent ansible revue de code traefik

Traefik

OrientDB

Ansible

Revue de code

Kafka

1 2 3 4