CérénIT

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

  • Une décennie DevOps, quels enseignements tirer ? : synthèse globale et assez factuelle sur 10 ans de DevOps qui a le mérite de signaler les points où ce n’est pas encore ça. Courage, la transformation/l’adoption est en cours malgré tout.

(No)SQL

Timeseries

Big Data, Machine Learning & co

  • Confluent Platform 4.1 with Production-Ready KSQL Now Available : Basé sur Apache Kafka 1.1, la nouvelle mouture de la platform de Confluent signe l’arrivée de KSQL comme “production ready” notamment - a voir si le “Replicator” est dans la version OSS ou bien EE seulement. Le seul souci que j’ai avec kafka, c’est que l’on ne peut pas monitorer finement la consommation des queues vu que l’intelligence est coté consommateur et pas coté broker… Même avec la version EE et le Control Center qui ne remonte que des métriques globaux mais ne donne pas de détail sur l’état du topic.
  • Tensorflow with Javascript Brings Deep Learning to the Browser : j’avais lu l’annonce il y a quelques temps mais sans bien comprendre l’intérêt de la chose. L’idée ici est de pouvoir faire tourner Tensorflox dans le navigateur au travers de Javascript et de WebGL (et donc de tirer parti des capacités de la carte graphique). En plus de rendre accessible le ML aux développeurs Web, cela permettrait aussi de soumettre des modèles ou d’entrainer des modèles dans le navigateur de l’utilisateur. Vers le Machine Learning au plus près de l’utilisateur ?
  • Introducing Confluent Platform Preview Releases : Confluent met à disposition des versions intermédiaires de sa distribution. Cette première version permet de jouer avec KSQL et il semble que l’interface Control Center soit disponible sans frais particuliers. On notera d’ailleurs qu’en plus de la partie KSQL, des efforts ont été faits sur la partie inspection de topic et consumer lag. Cela progresse donc enfin dans l’observabilité et le monitoring d’un cluster kafka.
  • Introducing the Confluent Operator: Apache Kafka® on Kubernetes Made Simple : Confluent va mettre à disposition un “Kubernetes Operator” permettant de déployer Kafka ou Confluent platform de façon (plus) aisée sur un cluster Kubernetes. Les templates Kubernetes et les images Docker vont être mis à disposition le mois prochain et le Kubernetes Operator d’ici le milieu d’année.

Container et Orchrestration

  • Announcing Docker Enterprise Edition 2.0 : Docker Inc annonce la version 2.0 de sa version Entreprise. Elle se veut indépendante de tout lock-in (Multi-Linux, Multi-OS, Multi-Cloud) et permettre d’utiliser soit Swarm ou Kubernetes comme orchestrateur. Cette version apporte également un routage avancé au niveau de Swarm (niveau L7).
  • feat(agent): add agent support : Portainer est une solution de gestion d’un environnement Docker ou Docker Swarm. L’inconvénient sous Docker Swarm est que l’instance Portainer ne voit que les containers présents sur le même noeud que le sien et pas l’ensemble des containers (cf [FEATURE REQUEST] Be able to use all the Portainer built-in functionalities in all the containers running in a swarm cluster). Via un mécanisme d’agent (code source fermé) à déployer sur chaque noeud, l’éditeur annonce pouvoir contourner les limitations de l’API Docker. La justification du code fermée est motivée par les efforts de R&D réalisés. Un gist indique comment installer l’agent. Il n’est pas stipulé si en plus d’un code fermé, il y aura une offre commerciale autour ou pas.
  • Traefik 1.6 — Get Our Latest tetedemoine! : la version 1.6 apporte le support des certificats Wildcard Let’s Encrypt, une nouvelle Web UI, le support des outils de tracing Zipkin et OpenTracing, le support du stockage des certficiats dans les secrets Kubernetes, une capacité d’altération des logs en vue du respect de la GDPR et une homogénéisation interne sur la gestion des labels.
  • Open-sourcing gVisor, a sandboxed container runtime : Google vient de rendre opensource gvisor, une mécanisme permettant d’accroitre l’isolation des containers via un mécanisme de Sandbox. C’est “transaprent” pour l’utilisateur au sens qu’il peut utiliser gvisor de la même façon qu’il interagissait avec Docker ou Kubernetes. C’est juste le runtime qui change. C’est codé en go, cela intercepte les appels SYSCALLS et l’équivalent d’un noyaux linux codé en Go répond en lieu et place du noyau linux de la mâchine hôte. Par ailleurs, cette sandbox a un impact sur les performances du containers comme leurs auteurs l’expliquent bien dans le 3ème épisode du Kubernetes Podcast by Google. InfoQ publie également un article sur ce sujet : Google Release “gVisor”, a Lightweight Container Runtime Sandbox Used to Provide Secure Isolation
  • Containers, Security, and Echo Chambers : Une ex employée de Docker ayant travaillé sur la sécurité et l’isolation des containers nuance le marketing autour de gvisor. Elle avait déjà nuancé l’arrivée de Kaniko (le builder d’images Docker make in Google).
  • Introducing Play with Kubernetes : l’équipe Docker Inc, après son Play with Docker qui permet de se former à Docker depuis son poste de travail, annonce officiellement l’existence de son pendant pour Kubernetes : Play with Kubernetes. Officiellement, car le billet indique qu’il existe depuis l’été dernier. Il se base sur le workshop de Jerome Petazzoni.
  • Kubernetes Containerd Integration Goes GA : Containerd est un runtime de containers, venant de chez Docker Inc et placé mainteant sous l’égide de la CNCF. Il semble en bonne voie de devenir le runtime par défaut de Kubernetes en lieu et place de docker. Même si Kubernetes se défend de s’affranchir de Docker, force est de constater qu’il y a des travaux pour s’affranchir des outils estampillés Docker Inc : gvisor pourrait remplacer runc à terme, kaniko pourrait replacer docker build. La registry docker étant aussi en passe de standardisation, on peut s’attendre à voir un nouveau produit arriver. Si Kubernetes (+ Google + CNCF + …) ont encore besoin de la liaison avec Docker d’un point de vue marketing, on a l’impression que cela cherche à s’éloigner des outils Docker Inc et dans une moindre mesure du projet Moby (qui lui même semble aussi avoir quelques distances avec Docker Inc). Certes, le docker engine de Docker Inc est basé sur containerd et donc Docker ne disparait pas de la plateforme mais ça semble bien en prendre le chemin.

Développement

  • Using Github CODEOWNERS file : Github, via un fichier CODEOWNERS, permet d’indiquer qui sont les responsables présumés d’une Pull Request. De quoi simplifier son workflow.

Dataviz

  • Grafana v5.1 Released : en plus de la consolidation de la version 5.x, les deux ajouts significatis sont une heatmap pour Prometheus et l’arrivée de SQL Server comme data source et donc faire des graphs sur vos données SQL Server.

Infrastructure as code

(No)SQL

  • What’s New in MySQL 8.0? (Generally Available) : même si je n’utilise plus trop MySQL (au mieux MariaDB pour quelques clients), il est intéressant de voir la progression significative de cette base avec cette nouvelle version : Window functions, Document Store, support du JSON, etc. Elle pourrait presque recommencer à concurrencer Postgres ;-)
  • Installing MySQL 8.0 on Ubuntu 16.04 LTS in Five Minutes : tout est dans le titre - cela permet de déclarer le dépot Oracle/MySQL et d’accéder à differentes versions de MySQL, dont la 8.0.

Python

Sécurité

  • Use A Good Password Generator : revue de différents outils de génération et gestion de mots de passe. La feuille de calcul contient plusieurs onglets et permet de faire le tour des solutions existantes.

TICK Platform (Telegaf, InfluxDB, Chronograf, Kapacitor)

  • Kapacitor and Continuous Queries: How To Decide Which Tool You Need : la question m’a été posée à Breizhcamp et je n’avais pas forcément de réponse à fournir. Elle est fournie par l’éditeur : Conitunous Queries pour l’échantillonage et Kapacitor pour les requêtes custom et éventuellement déporter des workloads consommatrice de ressources. Le mode streaming de kapacitor permet aussi de faire vos requêtes au fil de l’eau et consommer moins de ressources (mais plus régulièrement)
  • Intelligent Monitoring: Automating Dashboard Annotations in Chronograf : tutoriel intéressant qui montre comment l’on peut générer dynamiquement des annotations sur vos graphs dans Chronograf au travers de Kapacitor. Intéressant, car en général, les annotations sont souvent posées manuellement et a posteriori par des humains et pas de façon automatique/continue.
  • Chronograf 1.5 and Kapacitor 1.5 Released : Chronograf permet maintenant d’avoir une vue tabulaire des données (et pas uniquement un graph ou une donnée) et Kapacitor peut maintenant envoyer des alertes vers Kafka, vers plusieurs canaux Slack.

Web

Container et Orchrestration

  • Au revoir : Solomon Hykes, un des fondateurs de Docker tire sa révérance dans une note qui se veut positive. Un autre article nuance un peu cette réalité. Crise de croissance ? Rachat en perspective ? Let’s see…
  • Releasing HypriotOS 1.8.0: Raspberry Pi 3 B+, Stretch and more : l’équipe Hypriot a mis à jour sa distribution Hypriot OS en version 1.8. Elle est basée sur Raspbian Stretch (et non plus Jessie), supporte le dernier modèle de Raspberry Pi et fourni les dernières versions de docker, docker-compose et docker-machine. Une version 1.8.1 est déjà en cours de préparation, suivez de près la page de release du projet
  • Docker Registry API to be standardized in OCI : après la standardisation des images et du runtime des conteneurs, c’est au tour de la distribution de faire son effort de standardisation. La registry docker, standard de fait, devrait donc devenir une norme.
  • A House of Cards: An Exploration of Security When Building Docker Containers : une revue des éventuelles failles de sécurité qui pourraient être exploitées lors de la construction d’un conteneur. Mais bon, vous relisez vos Dockerfile bien sûr !

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.

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.

API, Rest, GraphQL

  • GraphQL at the REST-aurant : une introduction à GraphQL et à ses avantages par rapport à un modèle REST en faisant une analogie avec un REST-aurant. J’ai découvert les “persisted queries”.

Container & orchestration

  • Going Production with Docker and Swarm : une présentation repassant les bonnes et mauvaises pratiques de Docker et Docker Swarm, les outils disponibles, des éléments de sizing de cluster swarm, etc. Globalement en phase avec ce que je pratique chez un client actuellement. Prochaine étape, ne plus utiliser “latest” comme référence d’images !

Dataviz

  • What’s New in Grafana v5.0 : Grosse refonte de Grafana pour l’arrivée de cette version 5.0 : nouveau système de dashboard, gestion des permissions, gestion de groupes, gestion de dossiers, nouvelle UX, etc.

Git

  • –force considered harmful; understanding git’s –force-with-lease : Si l’usage de git --force est déconseillée si ce n’est proscrite, sa variante git --force-with-lease est plus intéressante et permet d’éviter d’écraser le travail de vos camarades alors que vous pensiez juste faire un push en force sur une branche distante suite à un rebase local.
  • Advantages of monolithic version control : le débat mono-dépot vs multi-dépots est récurrent - celui- ci donne des raisons pro mono dépôt. Au delà du mono/multi dépôt, c’est surtout l’architecture d’une application et sa modularité qui sont prépondérants.

Kafka

Sécurité & Compliance

  • La fin d’une époque… : si vous utilisez des certificats issues de chez Thawte, GeoTrust et RapidSSL ayant été générés avant le 1er juin 2016 pour la 1er vague ou avant le 1er décembre 2017 (date de rachat de l’autorité de Symantec par Digicert), alors vos sites risquent d’être bloqués par les version de printemps et d’automne de Firefox et Chrome. Il vous faut renouveller vos certificats. Si votre certificat a été généré après le 1er Décembre 2017, vous n’avez rien à faire.
  • Chef InSpec 2.0 Puts the Security into DevSecOps : la spécification InSpec permet de définir/tester/valider l’état d’une machine au regard de règles de conformité et de sécurité. Cette spécification a été initiée par l’entreprise Chef (éditrice du logiciel du même nom et d’Habitat entre autres). La version 2.0 vient de sortir et apporte une intégration AWS/Azure, de nouvelles ressources de validation (docker, configuration serveurs web, clés & certificats, etc) et une amélioration des performances.

Astuce(s) du mois

Lorsque l’on déploie une même application dans plusieurs contextes via docker-compose, il est intéressant d’utiliser le COMPOSE_PROJECT_NAME qui permet de donner un préfixe à vos réseaux et containers docker a minima.

L’inconvénient est qu’il faut ajouter à vos commandes un -p <project_name> :

docker-compose -p instancea build --pull
docker-compose -p instancea up -d
docker-compose -p instancea logs -f
docker-compose -p instancea stop <service>
docker-compose -p instancea down
...

Ainsi, vos conteneurs seront nommés instancea_<service name>_<occurence> et votre réseau instancea_<network name>.

Mais il est possible d’aller plus loin avec les fichiers d’environnement .env.

Dans votre fichier .env à la racine de votre dossier où se trouve votre fichier docker-compose.yml, définissez la/les variable(s) dont vous avez besoin. Ici, nous allons nous limiter à COMPOSE_PROJET_NAME mais ne vous privez pas.

COMPOSE_PROJECT_NAME=instancea

A partir de ce moment-là, plus besoin de précier l’argument -p <project name>, vos commandes redeviennent :

docker-compose build --pull
docker-compose up -d
docker-compose logs -f
docker-compose stop <service>
docker-compose down
...

… et pour autant, vos réseaux et containers ont le bon préfix car le fichier .env est lu à l’exécution de la commande docker-compose avant de parser docker-compose.yml.

On peut aller encore plus loin en utilisant ce COMPOSE_PROJECT_NAME dans le taggage des images d’un container par ex ou

version: '3'
services:
  nginx:
    build:
      context: ./nginx/
    image: "registry.mycompany.com/nginx:${COMPOSE_PROJECT_NAME}"

Lors de la phase de build, l’image sera tagguée avec le nom passé au projet compose. Ensuite, vous pouvez poussez sur la registry de votre entreprise puis déployer cette version sur votre cluster Swarm par ex.

A noter justement une limitation actuelle de docker stack deploy <stack name> -c docker-compose.yml qui ne lit pas le fichier .env en amont et donc COMPOSE_PROJECT_NAME reste vide lors de la lecture du fichier docker-compose.yml.

Une solution possible est par ex dans le script (simplifié) de déploiement :

cd $BUILDDIR/compose/
source .env

# Remplace la variable COMPOSE_PROJECT_NAME par sa valeur
sed -i -e "s/\${COMPOSE_PROJECT_NAME}/${COMPOSE_PROJECT_NAME}/g" docker-compose.yml

docker stack deploy ${COMPOSE_PROJECT_NAME} -c docker-compose.yml

Et voilà !

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()

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes elasticsearch kafka postgres ansible grafana mysql tick influxdb sécurité python aws chronograf redis swarm cassandra cloud microservice spark terraform angularjs confluent container graphql hashicorp javascript rancher serverless stream test traefik api architecture arm csp devops docker-compose documentation hpkp kapacitor kibana lambda lean log microsoft npm orientdb rest rethinkdb reverse-proxy service-mesh sql ssh windows agile azure bash big-data certificat cli cluster cncf cookie elastic fluxlang gcp gdpr git grav hsts https hypriot iac istio java json ksql lets-encrypt licence linux mobile monitoring opensource php prometheus redhat replication rsyslog scale solr systemd telegraf vue.js wagtail yarn accessibilité akka alerte amazon-emr anonymisation apm automatisation bastion beam beat bilan bounded-context branche brigade buildkit cdc certificats checklist cloud-init cockroachdb code codeurs-en-seine consul containerd continous-delivery coreos cors cqrs crash cron crontab csrf css curl cérénit d3.js dashboard data-pipelining dataviz date ddd debezium debian desktop devoxx distributed-systems dns docker-app dokcer draft drop-in ebs ec2 elassandra electron elk engineering event-sourcing facebook falcor feed filebeat firebase firefox fish flash flask fleet fluentd flux foundation framework frontend fullstack github glacier google grid géospatial hacker hadoop header helm html html5 http hue ia iaac ibm immutable incident index infrastructure-as-code ingénierie inspec jq jquery jwt k8s kubeadm laravel liste-de-diffusion logstatsh loi machine-learning mailing-list management mariadb message micro-service molecule mot-de-passe multi-cloud médecine newsletter nginx nomad nosql null openmetrics openshit openweb over-engineering packaging password performance perspective pip portainer publicité push queue raml react reaper reindex reinvent responsive revocation revue-de-code rkt rolespec root rpi rpo rto rwd s3 scaleway search select serverless-architecture service-worker sha1 shell shipyard société spinnaker sre sri ssl statistique superset sympa syslog-ng test-unitaire tiers timer timescaledb timezone tls training travail unikernel unit ux vault vie-privée virtualenv vm vnc voxxeddays vpc

Syndication

Atom