CérénIT

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.

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

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.

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

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.

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes elasticsearch kafka postgres traefik ansible grafana python aws influxdb sécurité tick mysql redis timeseries cloud ovh chronograf swarm test cassandra hashicorp ksql log microservice serverless spark terraform angularjs cncf confluent container docker-compose graphql helm javascript machine-learning opensource rancher service-mesh stream timescaledb windows api architecture arm csp devops dns documentation elastic git hpkp iac ingress java kafka-streams kapacitor kibana lambda lean licence microsoft monitoring nginx npm orientdb prometheus redhat rest rethinkdb reverse-proxy rook sql ssh telegraf agile apm azure bash big-data bilan cert-manager certificat cli cluster continous-delivery continous-integration cookie cérénit fluxlang gcp gdpr grav hsts https hypriot istio json k3s kubedb lets-encrypt linux load-balancer mobile mongodb perspective php pip ptsm replication rpi rsyslog s3 scale scaleway schema secrets solr sre systemd vault virtualenv vue.js wagtail warp10 yarn accessibilité akka alerte alibaba amazon-emr anonymisation anthos ara automatisation bastion beam beat bounded-context branche brigade browser buildkit cd cdc ceph certificats checklist chrome ci cloud-init cloud-native cloud-storage clusterip cockroachdb code codeurs-en-seine confluence consul containerd continous-deployment coreos cors cqrs crash cron crontab csrf css curl d3.js daemonset dashboard data-pipelining data.gouv.fr datacenter dataviz date ddd debezium debian deployment desktop devoxx diff distributed-systems dive docker-app docker-hub docker-registry documentdb dokcer draft drop-in déploiement ebs ec2 edge elassandra electron elk engineering etcd event-sourcing facebook falcor feature-policy feed filebeat firebase firefox fish flash flask fleet flink fluentd flux foundation framework frontend fsync fullstack github gitlab gke glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy hdfs header html html5 http http/3 hue ia iaac ibm immutable incident index influxace influxcloud influxdata influxdays infrastructure-as-code ingénierie inspec jenkins jq jquery jwt k3d k8s k9s kubeadm kubecon kubectl laravel liste-de-diffusion loadbalancer logstash logstatsh loi maesh mailing-list management mariadb meetup message metallb micro-service molecule mot-de-passe multi-cloud médecine métrique newsletter nodeport nomad nosql null opendata openebs openmetrics openshit openssh openweb operator over-engineering packaging pandas partiql password percona performance persistent-volume-claim pipeline pipenv pod portainer prediction prescience publicité push pyenv quasardb quay queue quic ram rambleed raml react reaper recaptcha recherche registry reindex reinvent reliability responsive revocation revue-de-code rkt rolespec root rpo rto runc rwd résilience scanner search select serverless-architecture service-worker sha1 sharding shell shipyard société souveraineté-numérique spinnaker sri ssh-agent ssl statistique superset sympa syslog-ng test-unitaire tidb tiers timer timezone tls training travail ubuntu unikernel unit ux vendredi vie-privée virtualbox virtualisation vitess vm vnc volume voxxeddays vpc vscode yubikey

Syndication

Atom