CérénIT

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

InfluxDays London 2019

influxdaysinfluxdbinfluxcloudtimeseriestickinfluxdatainfluxace

La cinquième édition des InfluxDays (et la seconde édition en Europe) s'est tenue à Londres les 13 et 14 juin 2019. Les InfluxDays sont organisés par la société InfluxData, éditrice des produits Telegraf, InfluxDB, Chronograf et Kapacitor, connu aussi sous le nom de la stack TICK. Il s'agit d'une plateforme de gestion des données temporelles, depuis leur ingestion jusqu'à leur visualisation et leur traitement en passant par leur stockage. Durant ces deux jours, des présentations portent sur les produits, leurs évolutions, des retours d'expériences clients et plus généralement sur l'écosystème.

Sur InfluxData, quelques chiffres :

  • 230.000 installations d'InfluxDB dans le monde
  • 200+ plugins telegraf (agent de collecte)
  • 600+ clients InfluxData
  • 140+ employés

Avant de rentrer dans la synthèse, il faut que vous sachiez que j'ai été nominé "InfluxAce" pour la France. Ce titre permet à InfluxData de reconnaitre et promouvoir les experts de la stack TICK et de les remercier pour leur contribution à la communauté et à l'évangélisation de leurs produits. Deux autres personnes en Belgique et au Luxembourg ont été nominées également.

Si vous voulez un résumé assez détaillé, je vous invite à lire celui d'Antoine Solnichkin (en anglais) qui n'est autre que notre InfluxAce luxembourgeois.

Les principaux enseignements pour moi d'InfluxDays :

  • Influx 2.0 : de la stack TICK à une plateforme unifiée : en réintégrant les fonctionnalités de visualisation et de traitement des données dans la base elle-même, les composants "ICK" deviennent un produit unifié et plus intégré. L'idée est de pouvoir manipuler ses données très rapidement sans avoir à installer et paramétrer plusieurs composants. Telegraf n'est pas en reste car la configuration pourra être générée depuis Influx 2.x et Telegraf pourra même récupérer sa configuration via l'API.
  • Influx 2.0 : une plateforme composable et extensible : en adoptant une approche API first (en plus d'avoir été unifiée et rendue plus cohérente entre les produits), InfluxData permet des intégrations plus aisées et met aussi une CLI ou un REPL plus riches à disposition de ses utilisateurs. InfluxData travaille aussi sur l'extensibilité de sa solution via des "packages" pour Flux et Telegraf notamment. Ces packages permetteront d'apporter sa propre logique dans la plateforme (plugins telegraf pour la collecte des données, fonctions flux pour le traitement des données, modèles de dashboards, modèles de tâches, etc).
  • Influx 2.0, une plateforme "... as Code" : la solution étant extensible et une API permettant d'interagir avec elle, il sera donc possible de versionner de versionner le code des différents éléments et de les déployer via l'API proposée par Influx. Des mécanismes de templates vont aussi permettre aux utilisateurs de ne pas démarrer avec l'angoisse de la feuille vide mais au contraire d'avoir des bonnes pratiques ou des règles de gouvernance sur la façon de gérer les données.
  • Influx 2.0, un hub pour vos données temporelles : Flux, le nouveau langage pour interagir avec les données, se veut être en mesure de résoudre les limites d'InfluxQL sur la manipulation des données temporelles mais aussi de pouvoir aller requêter des sources de données tierces dans le cadre de l'enrichissement / le nettoyage des données. Des réflexions sur la gestion de datasources plus traditionnelles est en cours. Flux va également être en mesure de s'interfacer avec d'autres sources de données comme Prometheus (dont une démonstration du transpiler a été faite). Cette capacité de transpilation peut ainsi permettre de connecter Grafana à Influx 2.x via une datasource Prometheus et de continuer à avoir des requêtes PromQL. De la même façon, Flux pourrait être utilisé pour permettre la migration Influx 1.x vers Influx 2.x par ex sous Grafana sans avoir à toucher aux requêtes de ses dashboards.
  • Influx (2.0), c'est en fait trois produits avec du code partagé entre eux : InfluxDB OSS, InfluxDB Entreprise et InfluxCloud. La version cloud devrait passer en production cet été, Influx 2.x OSS devrait passer en bêta cet été et finir en GA fin 2019 / début 2020 et Influx 2.x Entreprise arrivera en 2020. InfluxCloud se déploie sur Kubernetes et chaque composant est modulaire et scalable et s'appuie aussi sur Kafka quand InfluxDB OSS 2.x restera un binaire unique en Go.

D'autres présentations ont permis de mieux comprendre le moteur de stockage d'InfluxDB, comment faire un plugin Telegraf ou bien d'avoir des retours clients intéressants.

Au final, et indépendamment de ma nomination, ce fut deux jours très intéressants pour mieux appréhender la plateforme, son fonctionnement interne, les évolutions à venir et voir différents cas d'utilisation. Ce fut enfin l'occasion de rencontrer les équipes InfluxData avec qui j'ai passé un très bon moment et il est toujours agréable de pouvoir poser ses questions au CTO et CEO d'InfluxData sur le produit ou le marché des données temporelles. Ce fut également très intéressant de discuter avec différents membres de la communauté.

Vous devriez pouvoir accéder aux vidéos et slides de l'événement via le site de l'événement d'ici quelques jours.

Un meetup "timeseries" va être organisé en France entre septembre et la fin d'année par votre serviteur et avec le support d'InfluxData.. Si vous êtes intéressés, inscrivez-vous au meetup "Paris Time Series Meetup". Il se veut ouvert à tout l'écosystème des séries temporelles et si vous avez des idées/envies/..., n'hésitez pas à me contacter ou via le Meetup ou encore twitter.

Web, Ops & Data - Juillet 2018

grafanakubernetesservice-meshansiblebrigadehelmdraftsqldevopsarchitecturemicroservicefluxtickinfluxdbdockerchronograffluxlang

Architecture

  • Goodbye Microservices: From 100s of problem children to 1 superstar : L’article fait pas mal de "bruit" en ce moment mais je ne suis pas sur qu’ils arrivent à la bonne conclusion au final ; Partir de microservices et multiples dépots gits pour revenir à un monolithe/mono dépot git, j'ai l'impression que la réponse au travers des outils n'adresse pas le problème de fond à savoir la gouvernance de l'ensemble. En effet, si les versions différaient tant que cela, l'approche centralisé a peut être mis un terme en forçant tout le monde à se rencentrer sur une version donnée mais s'il n'y a pas de règles, le résultat sera le même prochainement mais ils auront moins de liberté.
  • Miniservices as a Realistic Alternative to Microservices : du coup, pour réduire les frictions, certains proposent de faire des micro-services plus gros avec le risque d'arriver à plein de moyens monolites...
  • Je mets donc pour rappel cet article que j'ai déjà mentionné : Enough with the microservices. Il rappelle que c'est surtout la modularité et une architecture propre du code qui donne de la flexibilité. Et puis tout le monde n'a ni le contexte, ni la maturité pour se lancer dans les micro-services.

Automatisation

  • Ansible 2.6: Your Time Has Come! : une version de consolidation avec des améliorations coté cloud et surtout sur l'utilisation de la mémoire lordque l'on utilise les "Dynamic Includes".

Container et Orchestration

  • Blog: Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability : Kubernetes continue son travail de consolidation et de stabilisation.
  • Service Mesh: Promise or Peril? : si les service mesh peuvent paraitre attrayant, leur intégration n'est pas forcément évidente et il faut aussi prévoir cette couche intermédiaire dans le développement de votre application. Leur utilisation n'est donc pas toujours recommmandée/souhaitable - l'article propose de faire le point sur le sujet.
  • Container Native Development with Ralph Squillace : cet épisode de podcast petmet d'avoir une présentation d'Helm (package manager), Bridage (gestion de workflow kubernetes) et Draft (aide à la conteneurisation d'une app). D'autres outils sont mentionnés en fin d'épisode pour agrémenter son quotidien (extension vscode, etc).
  • Extending Support Cycle for Docker Community Edition : A l'occasion de la sortie de Docker CE 18.06, quelques ajustements : les versions stables sortiront tous les 6 mois maintenant (et plus tous les 3 mois) et avec une période de maintenance de 7 mois, le canal edge (monthly release) est arrêté au profit d’un canal nightly, docker for Windows/Mac gardent une release mensuelle (pour le canal edge), plus de packaging par distribution pour mieux coller à l’actualité de la distribution.

Dataviz

DevOps

(No)SQL

Timeseries

Web, Ops & Data - Avril 2018

dockerrpicockroachdbjavascriptjavatickgrafanasystemddrop-in

Container et Orchrestration

NoSQL

  • Cockroach 2.0 (What's New in v2.0.0 - CockroachDB 2.0 Has Arrived!) : la base de données Cockroach, implémentation open source de la base de données Spanner de Google, passe (déjà) en version 2.0. Au programme des améliorations mises en avant : support du format JSON (reprise du format de Postgres), amélioration des débits et de la scalabilité, amélioration de l'outillage pour la gestion d'un cluster géo-distribué.

De retour du Breizh Camp

Quelques liens récupérés des différentes conférences auxquelles j'ai pu assister.

  • Gazr : Outil créé par Dailymotion, cela leur permet d'uniformiser les tâches quelque soit la technologie sous-jacente (ou l'environnement d'exécution)
  • Nom de Zeus, j'ai typé mon code vanillia js : TS-check, disponible depuis TypeSCcipt 2.3, permet de commencer à typer (progressivement) du js vanilla même si on n'est pas encore prêt à passer à TypeScript ou autre) ; démo.
  • JVM & Orchestration Docker (slides - démo) : Java, dans un container, ne voit les ressources qui lui sont allouées via cgroups et s'appuie sur les ressources disponibles au niveau de la machine hôte. Java 8 Update 131+ et Java 9 ont des flags expérimentaux et Java 10 devient un bon citoyen de l'écosystème Docker. Lire aussi sur le sujet : Java inside docker: What you must know to not FAIL.
  • Tests d'intégration avec Docker et Elasticsearch : D. Pilato montre ainsi qu'il est possible de lancer des tests d'intégration d'Elasticsearch depuis Maven ou via JUnit et qu'en fonction, cela peut lancer un container docker, s'appuyer sur une instance elasticsearch local ou distante. Pour cela, il s'appuie sur les outils de Fabric8 et/ou l'initiative testcontainers. Tout est documenté dans le dépot et il faut suivre les branches pour les différentes itérations.

Et pour finir, mes propres slides sur la plateforme TICK & Grafana pour collecter et exploiter vos données temporelles. J'ai également eu l'opportunité de refaire cette conférence chez Les Furets (où je suis en mission actuellement). Je vais aussi la faire le 3 Mai prochain au NantesJUG.

Bonus : la vidéo est disponible

Astuce(s) du mois

Docker, lorsqu'il exécute un container, injecte normalement les serveurs DNS de la machine hôte. Sauf que quand il voit que c'est une IP locale (127.0.0.*), alors il met les DNS de Google (8.8.8.8 et 8.8.4.4) comme DNS. Typiqyement, Ubuntu utilise un résolveur DNS local via systemd-resolved pour la résolution DNS. Du coup, la configuration de /etc/resolv.conf pointe sur 127.0.0.*. Or sur un réseau local, les accès à un DNS public peuvent être filtrés. Dès lors, votre conteneur est incapable de faire une quelconque résolution DNS (interne ou externe à votre réseau).

La solution consiste à mettre en place un "drop-in" systemd

Source :

Nous voulons surcharger le fichier de type unit docker.service et surcharger plus précisément la valeur de ExectStart.

Etape 1 : Créer un répertoire /etc/systemd/system/docker.service.d

sudo mkdir -p /etc/systemd/system/docker.service.d

Etape 2 : Créer un fichier de configuration contenant la surcharge :

sudo $EDITOR /etc/systemd/system/docker.service.d/10-dns.conf

Contenu du fichier :

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --dns 192.168.2.1 --dns 192.168.2.2

Le "doublon" sur ExecStart est normal, cela permet de réinitialiser la commande pour en définir un autre ensuite.

Il ne reste plus qu'à rechercher la configuration de systemd et relancer le service docker :

sudo systemctl daemon-reload
sudo systemctl restart docker

Docker utilisera donc ces DNS lors du lancement d'un conteneur et cela évitera qu'il fasse un fallback sur les DNS de Google quand il voit un resolver local...

Par contre, si vous utilisez docker dans un autre contexte que celui du réseau de votre entreprise, cela peut ne plus fonctionner (ou alors il faut enrichir la configuration DNS pour rajouter d'autres DNS)

Une autre solution peut être de renseigner les DNS dans /etc/docker/daemon.json (documentation) avec les mêmes inconvénients.

Au-delà de cet exemple appliqué à Docker, l'utilisation des "drop-ins" systemd est une solution intéressante pour surcharger une configuration sans impacter les fichiers sources et évite tout conflit lors d'une mise à jour du fichier.

Web, Ops & Data - Mars 2018

grafanatickchronografinfluxdbdatavizansiblesparkdockerkubernetescncfsupersetjavaLet's encryptpostgrespythond3.js

Automatisation

  • Ansible 2.5: Traveling space and time : au programme de cette nouvelle version : des namespaces pour les "facts", la capacité d'interdire des modules, des nouvelles "variables magiques" (les magic vars sont des variables spécifiques à Ansible et l'exécution des playbooks). On notera aussi des améliorations sur le support Windows, des nouveaux modules cloud (AWS, GCP, Azure, VMWare) et des nouveaux plugins.

Container et Orchrestration

Dataviz

Java

  • No Free Java LTS Version? : Oracle change ses pratiques de distribution du JDK Oracle (Une version majeure tous les 6 mois, moins de report de patches, etc).

Let's encrypt

  • ACME v2 and Wildcard Certificate Support is Live : Let's Encrypt va donc fournir des certificats wildcard (*.domaine.fr). Si je m'étais réjoui de l'idée au début, je ne vois finalement pas ou peu l'intérêt du fait de la méthode de validation (enregistrement DNS avec le temps de propagation associé). En dehors du cas où l'on dépassait les limites d'enregistrement de Let's Encrypt en terme de nombre de certificats, la génération dynmique et unitaire via une méthode HTTP me semble plus simple. Surtout quand on utilise Traefik ;-)

Postgres

Python

TICK

Astuce(s) du mois

J'utilise Ansible dans une logique d'IAC et pour automatiser un maximum des actions pour la gestion de l'infrastructure et des applications de mes clients. Toutefois, chaque client avait son arborescence et la réutilisation d'un composant d'un client à l'autre était fastidieuse (copier/coller).

Un premier travail a consisté à extraire les rôles commun dans un dépôt git tiers et faire des liens symboliques mais cela n'était pas très pratique. Suite à un travail chez un autre client, j'ai revu mon approche et je pars pour le moment sur la solution suivante :

  • Un dépôt "global", contenant la configuration ansible, les plugins, les playbooks, les variables d'hotes ou de groupes, l'inventaire et les rôles.
  • Pour chaque rôle, je repars sur le principe d'extensibilité du code avec un rôle générique et des extensions par clients. Il y aura donc un répertoire du nom du composant et un répertoire <composant>.<client> ou <client>.<composant> (le choix n'est pas encore arrêté). Le second répertoire contenant les éléments spécifiques au client.

Exemple avec un rôle MariaDB :

mariadb/
├── README.md
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
├── tasks
│   └── main.yml
├── templates
│   └── my.cnf.j2
└── vars
   └── main.yml
co.mariadb/
├── README.md
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
├── templates
│   ├── my-primary.cnf.j2
│   └── my-replica.cnf.j2

Ainsi, la partie générique et la partie spécifique à mon client sont isolées. Il faut juste envisager le séquencement entre les deux rôles pour que cela se passe bien. Pour le moment, le seul code dupliqué se retrouve au niveau des handlers.

Si je devais donner accès à mes clients à leurs playbooks respectifs, il faudrait que je revois l'organisation pour ne leur donner accès qu'à leurs données. Il faudrait alors recréeer n dépots mais avec cette méthode, il est aussi facile de reconstruire a posteriori des dépots par clients depuis un dépot global. L'intérêt étant pour moi de conserver ma flexibilité et d'améliorer la réutilisabilité de mes composants.

Web, Ops & Data - Novembre 2017

sparkgrafanatickcloud-initelasticsearchelkgraphqlkafkapostgresinfluxdbprometheuscodeurs en seine

Big Data

  • Compte rendu du Spark Summit 2017 (Dublin) : La conférence européenne annulle de l'éditeur de Spark, Databricks, a cherché à montrer que le Streaming et le Deep Learning sont/seront bientôt plus accessibles via Spark et également la plateforme cloud DataBricks.

Dataviz

  • Grafana 4.6 Released : Nouvelle version de l'outil de visualisation des bases de données time series mais pas uniquement avec l'ajout de la source Postgres, du support de l'alerting pour Amazon Cloudwatch, des annotations simplifiées sur les graphs et autres améliorations sur la base prometheus.
  • Wizzy : il s'agit d'un ensemble de script pour versionner et se simplifier la gestion de ses dashboards réalisés sous Grafana. Pas encore testé, sous peu !

Cloud

  • Bootstrapping a Cloud with Cloud-Init and HypriotOS : j'avais croisé Cloud-Init dans Rancher OS mais n'avais pas eu le temps d'investiguer le sujet. Récemment, un podcast avec son créateur m'a permis d'en savoir plus sur le projet, à savoir que c'est un ensemble de script python qui permettent de configurer une machine lors de son initialisation (boot). Cet article permet du coup d'en avoir un exemple pratique par la configuration d'une image pour un Raspberry Pi 3 installant automatiquement le logiciel NextCloud sous la forme d'un container Docker.

Elasticsearch

  • An Ansible role to Manage your Elasticsearch Clusters : Synthesio publie son playbook ansible pour gérer des clusters Elasticsearch ; vu les clusters gérés, il y a surement de bonnes choses à récupérer - la limite étant peut être que pour un cluster de débutant, cela pourrait être trop complexe au regard du besoin. A évaluer suivant votre contexte.
  • Operating Large Elasticsearch Clusters : un retour d'expérience de l'équipe Synthesio sur la bonne gestion de leurs clusters ElasticSearch lors des Sysadmindays il y a peu.
  • La Stack ELK passe en 6.0 :
    • Elasticsearch 6.0.0 GA released : mise à jour sans downtime, index filtré, meilleures performances, meilleure résilience et meilleure sécurité (mot de passe, usage de TLS).
    • Logstash 6.0.0 GA released : il est désormais possible d'avoir des pipelines dont l'exécution se fait en parallèle et via X-Pack, il y a maintenant une UI pour piloter vos pipelines.
    • Kibana 6.0.0 GA released : Plein d'améliorations au programme : Export CSV, Amélioration de l'UI, Mode lecture seule pour pouvoir partager des dashboards et d'autres nouveautés spécifiques à X-Pack.
    • Beats 6.0.0 GA released : capture des données Docker/Kubernetes, auditbeat pour captuer les données d'auditd, une meilleure gestion des modules et de leur configuration, amélioration de performance et du stockage des données.
  • Devez-vous migrer vers Elasticsearch 6 : l'équipe Jolicode passe en revue les avancées de la version 6 et globalement conseille de passer vers cette version 6.

GraphQL

  • Modernisez vos API, passez à GraphQL ! (slides et vidéo) : Une introduction à GraphQL présentée à Codeurs en Seine 2017. Je reste toujours sceptique sur GraphQL, si coté client cela semble magique, personne ne montre la partie backend pour que la "magie" opère.
  • The GraphQL stack: How everything fits together : état des lieux suite à GraphQL Summit 2017 sur les parties cache, tracing (suivi d'une requête de bout en bout du système) et composabilité d'API (une requête GraphQL qui intérogge plusieurs API au lieu d'une).

Kafka

  • Apache Kafka Goes 1.0 : cette version 1.0 représente plutôt la complétude à l'égard d'une vision de ce que devait être Kafka que de sa stabilité ou de sa capacité à être utilisé en production. Le billet énoncce les derniers apports mais reviens surtout sur tout cette génése et la vision associée au produit.

(No)SQL

Time Series

select(db:"foo")
 .where(exp:{"_measurement"=="cpu" AND 
             "_field"=="usage_system" AND 
             "service"=="app-server"})
 .range(start:-12h)
 .window(every:10m)
 .max()

Web, Ops & Data - Juin 2017

brancheterraformiaacelasticsolrserverlessmysqlsécuritétestticklean

Agile

  • Feature Branching is evil ! : si la branche isole le nouveau code, il isole aussi le développeur des autres avancées et repousse à plus tard les problématiques de réintégration de code, refactoring, etc. L'auteur avance le feature flipping et le "trunk based development" pour avoir une intégration continue perpétuelle et des écarts les plus petits possibles.

DevOps

  • Terraform Layering : Pourquoi et comment ? : Un fichier Terraform peut vite devenir illisible dans le cas d'une architecture complexe et consommateur de temps lors de son exécution. Le billet présente une méthode pour traiter ces problèmes. Il s'agit de créer des "couches" (layers) permettant d'avoir plus de modularité et permettant qu'un fichier terraform s'appuie en entrée sur les données de sorties du fichier précédent et ainsi de suite.

Elastic

  • Welcome Opbeat to the Elastic family : Elastic se lance sur le marché de la performance applicative (APM) en acquérant la société Opbeat. Suite assez logique pour Elastic après l'ingestion de données plus orientée monitoring système avec Logstash/Beat ou des intégrations spécifiques pour faire de l'APM en s'appuyant sur Elastic.
  • Designing the Perfect Elasticsearch Cluster: the (almost) Definitive Guide : le billet traite le design d'un cluster Elasticsearch et les points d'attention à avoir. Ce n'est pas la recette magique (elle n'existe pas) mais donne tous les points d'attention à avoir dans le cadre du déploiement d'un cluster Elasticsearch.
  • Top 15 Solr vs. Elasticsearch Differences : pour ceux qui hésitent encore entre les 2 solutions, une petite revue en 15 poins pouvant vous aider à choisir la solution correspondant à votre besoin.

Infrastructure

  • Serverless vs Micro-Service avec infrastructure "maison" : comparaison de la mise en place d'une infrastructure à base de micro-services vs une infrastructure "serverless" avec prise en compte des effets de vendor lock-in, impacts entre infrastructure et architecture logicielle, facilité de dépoiement, flexibilité, etc.

MySQL

Sécurité

Tests

  • k6 : un outil en Go et Javascript permettant de faire des tests de performance. Sa prise en main a l'air aisé et il semble avoir des fonctionnalités assez intéressantes pour faire des tests variés que ce soit sur la profondeur du scénario (1 ou plusieurs urls) ou les niveau de tests (checks, ratio, etc)

TICK (Telegraf, InfluxDB, Chronograf, Kapacitor)

Bonus : Lecture de l'été

  • #hyperlean – Ce que signifie l’avènement du numérique : je n'ai pas encore lu le livre mais je suis le blog de Cecil depuis des années et ses aventures dans le monde de l'agile, du lean, de l'entreprise collaborative et de la transformation digitale. Son livre se veut un guide pratique de la transformation digitale en abordant le pourquoi, le quoi et le comment. Dans le comment, on va retrouver forcément la méthode lean.

Web, Ops & Data - Semaine 51

dockerkuberneteselasticsearchtickchronografpythondateansibleredishypriotarm

Plateform TICK

  • Beta 3 of Chronograf : Chronograf 1.1 continue son bonhomme de chemin avec la parution d'une bêta 3 apportant son lot d'améliorations et de correctifs.

Container & Orchestration

  • Kubernetes 1.5: Supporting Production Workloads : Kubernetes, dans cette version 1.5, apporte des améliorations notamment sur la gestion des applications statefull (passage d'un statut alpha à beta) et plein de choses en alpha : le support des containers windows, la fédération de cluster kubernetes, la haute disponibilité, etc.
  • containerd – a core container runtime project for the industry : Docker Inc continue de modulariser Docker (Engine) en publiant "containerd" et en prévoyant de le donner à une fondation en début d'année prochaine. Containerd est la partie centrale d'exécution du container. Il a été déployé silencieusement depuis Docker 1.11. L'idée de containerd serait de devenir le "format" universel pour faire tourner des containers sur lequel tout le monde s'appuierait... A suivre dans la guerre des containers et des initiatives de standardisation (ou pas).
  • An Early Look at Ansible Container v0.3.0 : Ansible 2.x permet déjà d'interagir avec les containers docker, ansible-container permet d'aller plus loin dans la gestion des containers avec ansible. Cette version apportera le support du format docker-compose v2 et le support de docker 1.12. Même si je suis parvenu à piloter des containers docker avec Ansible 2.2, j'avoue qu'il y a quelques bugs pénibles et j'ai pas forcément l'impression que ce soit la bonne façon de faire. Peut⁻être que ce module apportera des réponses ou qu'il faut repenser la chose différemment.
  • Making Elasticsearch in Docker Swarm Elastic : Un billet intéressant sur le déploiement d'Elaticsearch dans un contexte Docker Swarm. En effet, la partie pénible est de gérer la découverte par IP des noeuds et de rendre cela accessible de l'extérieur du cluster. Le billet présente des astuces pour le faire. J'aurais bien aimé l'avoir il y a de cela 6 mois à 1 an...

NoSQL

ARM

  • Hypriot OS 1.1.2 : vos raspberry pi vont être gatés avec les dernières versions de Docker, Docker-Compose et Docker-Machine. Je détaillerai en janvier la mise en place d'un cluster docker avec Hypriot OS avec 5 Raspberry et 2 Cubietruck qui permettent d'avoir un stockage distribué/résilient avec GlusterFS.

Python

Bonnes fêtes de fin d'année à tous !

Web, Ops & Data - Semaine 46

kubernetestickinfluxdbchronografanonymisation

Kubernetes

  • Introducing Operators: Putting Operational Knowledge into Software : l'équipe de CoreOS vient de dévoiler les Operators, un complément à Kubernetes permettant, pour des applications stateful, de gérer une logique "métier" (création/suppression, perte d'un composant, mise à jour, sauvegarde, etc). Autant pour des applications stateless, il suffit d'instancier une nouvelle instance du composant, autant pour des applications stateful, il faut parfois avoir des commandes supplémentaires ou récupérer des informations des autres composants. C'est cette logique que les Operators apportent. On le comprend mieux en lisant les billets sur l'Operator d'etcd ou celui de Prometheus

TICK (Telegraf, InfluxDB, Chronograf, Kapacitor)

Gestion des données personnelles

Web, Ops & Data - Semaine 37

kafkapostgreskubernetesclusterreplicationinfluxdbticksécuritéangularjshttpshstscorscspsrihpkptelegrafkapacitorcqrsevent sourcing

Containers

  • Security Best Practices for Kubernetes Deployment : les points ne sont pas propres à Kubernetes : segmentation applicative via les namespaces, segmentation réseau, quota de ressources, utilisation d'images approuvées, maintient des images à jour, etc.
  • Docker + Golang : le billet présente des astuces pour compiler un programme Go au travers de containers pour illustrer différents besoins (cross-compilation, etc)
  • 12 fractured apps : une revue des bonnes pratiques à adopter pour gérer les fichiers de configurations, les connections à des bases de données dans un monde orientée micro-services.

AngularJS

  • AngularJS 2.0 : la version 2 du framework Javascript AngularJS de Google est (enfin) sorti et se dote d'un nouveau site angular.io. Etrangement, j'ai l'impression que c'est un non événement ? Cette version mainte fois discutée, tant attendue et au final ? Ou peut être que React est passé par là et à occuper le trou laissé par cette réécriture d'Angular ?

Kafka

TICK (Telegraf, InfluxDB, Chronograf et Kapacitor)

  • La plateforme TICK atteint le palier de la version 1.0 ; InfluxDB, Telegraf et Kapacitor. Pas de grosses nouveautés dans ces releases, juste une stabilisation et le tampon 1.0 ; Chronograf est aussi estampillé 1.0 même s'il s'est fait discret depuis la version 0.13. A voir s'il rattrape son retard sur Grafana...

Sécurité

Postgres

Web, Ops & Data - Semaine 14

reverse-proxydockerkuberneteselasticsearchkibanavncsshopenshitinfluxdbtickreindex

Infrastructure

Container

  • Elastikube : une solution de gestion d'une infrastructure Kubernetes ; cela fait penser à une version allégée d'Openshift. Containers
  • Containers are not VM : Une clarification par l'équipe Docker sur la différence entre un container et une VM sur la base de l'analogie avec l'appartement (le container) et la maison (la VM). Une maison (VM) contient tout ce dont elle a besoin pour fonctionner alors que pour un immeuble, des ressources sont partagées et chaque appartement de l'immeuble en profite dans une certaine mesure.
  • Docker a annoncé Docker pour Windows/Mac (beta) ; cela permet d'utiliser Docker de façon plus native et intuitive sous Windows/Mac. Pour Windows, cela demande d'avoir Windows 10 pour bénéficier de l'hypervision via Hyper-V. Sur ce sujet, l'équipe Hypriot dans leur revue de Docker pour Mac et Docker pour Windows montre le bonus (easter egg) de cette version à savoir qu'il est possible de faire tourner des conteneurs ARM sous environnement OSX/Windows ; cela permettrait de batir des conteurs pour Raspberry ou des projets IoT plus facilement. Je ne peux hélas pas le tester pour le moment, mais cela semble plus prometteur que Docker Toolbox qui reste un peu complexe à mettre en oeuvre.
  • Rancher, une solution d'orchestration de conteneurs, après avoir annoncé le support de Kubernetes, vient d'annoncer la sortie de la version 1.0. A suivre, même si la notion d'environnement ne permettrait pas une allocation optimale des capacités d'infrastructure (chaque environnement aurait ses hôtes alors que Kubernetes pourrait a priori permettre une mutualisation totale via la gestion des "namespaces" ; à creuser !).
  • Kubernetes, la solution d'orchestration de container (Docker/Rocket) développée par Google, est sorti en version 1.2 avec diverses améliorations et notamment une nouvelle GUI.
  • Kubernetes on ARM vient de sortir sous la version 0.7.0 ; de quoi se faire la main sur Kubernetes avec vos Raspberry ;-) ; une image Rancher est d'ailleurs disponible.
  • Docker en production : la bataille sanglante des orchestrateurs de conteneurs : Pour conclure, Octo compare Docker Swarm, Kubernetes et Openshift et donnant Kubernetes gagant pour le moment. Personellement, vu qu'a minima pour Kubernetes et Docker Swarm, on peut utiliser des containers docker, il est peut être intéressant de combiner les 2 solutions qui répondent plus ou moins bien à différentes problématiques. Je vois assez bien l'utilisation de Docker Swarm dans une logique de développement / labs et plus Kubernetes en effet dans une logique de production pure. Il ne faut pas se cacher que Kubernetes est plutôt "Ops friendly" et remonte la chaine de valeur vers les développeurs quand Docker fait le contraire...

Elasticsearch & friends

InfluxDB & Friends

Sysadmin

  • Teleport ; Une passerelle (bastion) SSH qui permet d'accéder à ses serveurs via SSH ou en HTTPS via une IHM Web. A tester !

Sécurité

  • VNCFail ; vous reprendrez bien un peu de non sécurité: l'analyse des 4 milliards de plage IPv4 remonte 5 millions d'adresse pour lesquelles le logiciel VNC (prise de contrôle à distance) est accessible et au final 2.246 hotes avec des systèmes accessibles sans mot de passe dont des systèmes sensibles (contrôle d'aération, usine éléctrique, etc).
1 / 1