CérénIT

Avant de commencer cette revue de presse, un peu d’auto-promo, vu que j’ai eu le plaisir et l’honneur de participer au numéro de rentrée (épisode 59) du BigData Hebdo.

Cloud

  • Multi-Cloud Is a Trap : sujet à la mode, le multi-cloud selon l’auteur du billet est inutile/idiot et ne serait qu’une distraction/perte de temps et d’argent dans la plupart des cas ; certaines exceptions sont acceptées en fin de billet). Un point intéressant étant de dire qu’en voulant éviter le “lock-in”, on se prive de profiter au maximum de la plateforme cloud et que l’on se créée du coup un coût de “lock-out”.

Containers et Orchestration

  • The Future of Docker Swarm : Etat des lieux et perspectives sur Swarm par un Capitaine Docker. Le projet n’est pas mort et il peut suffire dans bon nombre de cas.
  • Docker Config, how to always use base image with Docker Swarm! : Depuis Docker 17.06 et dans un contexte Swarm, il est possibile d’utiliser les configs. Les configs permettent de stocker un fichier de configuration au sein du cluster swarm et de le mettre à disposition des containers. Ainsi, en cas des modifications de la configuration, plus besoin de rebuilder l’image, il suffit de mettre à jour le service pour qu’une nouvelle version du container la prenne en compte.
  • Pros and Cons of running all Docker Swarm nodes as Managers? : Revue par le Docker Captain Bret Fisher des avantages/incovénients d’utiliser que des nodes de type “managers” au sein d’un cluster Swarm. Trop est déconseillé (> 5) et ensuite c’est un compromis entre la sécurité, la disponibilité et la résilience.
  • Traefik 1.7 — Yet Another Slice of Awesomeness : dans les nouveautés principales : une image Docker pour windows, le support de l’authentification dans les frontends, le support d’AWS Fargate, HC2 Support et le support du challenge TLS pour Let’s Encrypt (plus besoin d’avoir le port 80 ouvert). Apparemment pour la prochaine version, l’équipe de dév va prendre quelques libertés pour introduire des nouveautés - il faut donc s’attendre à quelques incompatibilités à l’avenir.

DevOps

  • Ansible Tips : Reboot & Continue : Astuce utile pour gérer un reboot d’un serveur via ansible et reprendre ensuite la connexion et l’exécution du reste d’un playbook.

IA

  • Finding and fixing software bugs automatically with SapFix and Sapienz : Sapienz et SapFix ne sont pas des produits SAP mais des projets Facebook. Le premier est un agent de test automatique et SapFix est une IA qui est en mesure d’identifier des correctifs pour les bugs identifiés par le premier. Le fix peut être un retour partiel ou total au code précédent mais aussi de prospoer des correctifs sur la base de modèle de code. Une fois les correctifs testés et qu’aucune régression n’est identifiée, alors le fix est proposé pour validation aux développeurs.

Ingénierie

  • Software disenchantment : “That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.” - un plaidoyer pour de meilleures pratiques d’ingénierie partant du constat que les applications développées sont de plus en plus grosses, de moins en moins performantes pour un niveau de fonctionnalité à peine meilleur. Heureusement que les machines ont progressé pour compenser cette “obésité logicielle”.

(No)SQL

(Open)Web

  • Removing jQuery from GitHub.com frontend : Github raconte son adoption jusqu’au retrait de JQuery de sa base de code. Il est intéressant de voir que les standards ont permis de remplacer pas mal de fonctionnalités et il reste encore quelques polyfills.
  • The Cost Of JavaScript In 2018 : l’utilisation de Javascript, en particulier sur mobile, n’est pas neutre. L’article revoit les bonnes et mauvaises pratiques.
  • your web app is bloated : Etude sur la consommation de mémoire de différnts sites sous Firefox - cela va de 0.8Mo (Gmail Vintage) à 200 Mo (Google Inbox)

Python

Astuce du mois

J’ai cru à un bug ansible sur les surcharges de variables mais en fait non - pour des variables de même niveau (ici group_vars), l’ordre de fusion des variables est :

  1. “all.yaml” est chargé en premier
  2. Les autres fichiers yaml sont chargés par ordre alphabétique et s’écrase les uns les autres le cas échéant

Donc si on a :

all.yaml:

monitoring:
     datadog: false

cassandra.yaml:

monitoring:
     datadog: true

et infra.yaml:

monitoring:
     datadog: false

alors datadog est à false à la fin lorsqu’on exécute le playbook.

A l’inverse:

all.yaml

monitoring:
     datadog: false

infra.yaml:

monitoring:
     datadog: false

swarm.yaml:

monitoring:
     datadog: true

alors datadog est à true à la fin lorsqu’on exécute le playbook.

Sources :

Cloud & Open Source

Container et orchestration

(Big) Data & (No)SQL

  • Reaper 1.2 Released : l’outil de gestion des “réparations” des données d’un keyspace Cassandra, initialement réalisé par Spotify et désormais maintenu par The Last Pickle, vient de sortir en version 1.2 avec son lot d’améliorations. Pour un client, il a été déployé, ce qui me permet de pouvoir contribuer modestement (#472, #473, #474)
  • Re-Bootstrapping Without Bootstrapping : que faire lorsqu’un noeud d’un cluster Cassandra est sorti depuis plus longtemps que le temps de grace défini ? Le billet répond à la question pour ne pas repartir de zéro et le faire de façon “marginale”.
  • Introducing Confluent Platform 5.0 : à l’occasion de la sortie d’Apache Kafka 2.0, une nouvelle version de la plateforme Confluent sort également avec les dernières nouveautés de KSQL, des améliorations coté stabilité/sécurité (Auth LDAP, Disaster Recovery, etc). Allez lire les notes pour en savoir plus et voir ce qui relève de la version 0SS et de la version Entreprise.
  • Showdown: MySQL 8 vs PostgreSQL 10 – Hacker Noon : l’article confirme qu’avec MySQL 8.0, MySQL rattraperait Postgres au niveau des grandes fonctionnalités de base.

DevOps

  • The Site Reliability Workbook : Google sort un complément à son livre “Site Reliability Engineering”. Le livre est sensé donner des conseils pratiques ou partager des eemples issus de la réalité dans le cadre de la mise en place d’une démarche SRE.

Timeseries

  • Querying Prometheus with Flux (video - slides) : Paul Dix, CTO d’InfluxData, montre comment il est possible de requêter des données issues de Prometheus via Flux, le nouveau langage qu’InfluxData est en train de créer et dont l’objectif est de pouvoir manipuler des données temporelles. Ce cas permet de montrer l’utilisation de Flux dans un contexte autre qu’InfluxDB.
  • CNCF to Host OpenMetrics in the Sandbox : OpenMetrics est une initiative de standardisation des formats de métriques - le projet rentre donc dans l’initiative de la CNCF.
  • OpenMetrics to Join the CNCF ; Paul Dix a annoncé le support de ce format comme “citoyen de première classe” pour une version ultérieure d’InfluxDB. Le billet fait l’état des lieux du support au niveau de Telegrad et de Kapacitor.
  • Prometheus Graduates Within CNCF : toujours coté CNCF, Prometheus, la plateforme de métriques, est le second projet (après Kubernetes) à passer au niveau officiel.
  • TimescaleDB vs. InfluxDB: purpose built differently for time-series data : Comparaison par les gens de TimescaleDB entre leur produit TimescaleDB et InfluxDB. Même s”il est forcément un peu biaisé, il reste intéressant.

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

Cloud

Container & Orchestration

  • Making Compose Easier to Use with Application Packages : Docker Inc. sort un nouveau produit appelé “docker-app”. Il se veut comme une surcouche à docker-compose en permettant d’injecter des variables dans vos fichiers docker-compose.yml. Ainsi, vous n’auriez plus qu’un seul fichier docker-compose avec ses variables et les valeurs de ses variables dans des fichiers additionnels. Lors de l’exécution du container, docker-app réconcilie les deux et lance le conteneur avec les bonnes valeurs. Docker Swarm et Kubernetes seraient supportés si l’on en croit les exemples. Rigolo, sur le principe, c’est exactement ce que je fais pour une mission actuellement…
  • Découverte de Buildkit : dans le cadre du découpage de Docker en programme modulaire indépendant, Moby avait lancé Buildkit. Il s’agit du builder d’images. L’article présente son fonctionnement et son architecture.
  • HashiCorp Consul 1.2: Service Mesh : Hashicorp sort en beta son offre de service mesh basé sur Consul. Après le “Service Discovery” et le “Service Configuration”, voilà le Service Mesh. A voir dans la vraie vie mais on retrouve apparemment pas mal de fonctionnalités disponibles dans Istio.

(No)SQL

  • Vitess : J’en avais entendu parler, j’ai profité d’un épisode de Software Engineering Daily pour en savoir un petit peu plus : Je ne suis pas encore au bout du podcast mais cela semble être une couche entre l’application et la DB - elle analyse la requête et la distribue ensuite au sein du cluster. Vitess permettrait notamment que le développeur n’ait pas à connaitre la logique de clustering/sharding des données. L’overhead n’a pas encore été mentionné.
  • Redis 5.0 RC1 : la version 5.0 de Redis pointe le bout de son nez avec notamment le type de donnée Stream - cf Introduction to redis streams
  • Streaming Data out of the Monolith: Building a Highly Reliable CDC Stack : un CDC, Change Data Capture, est un système qui capture les changements de données (INSERT, UPDATE, DELETE) d’une source de données. BlaBlaCar explique ici comment ils ont mis en place leur CDC sur la base de Debezium et Kafka. Un des défis à relever étant la gestion de la déduplication des données.
  • Elasticsearch 6.3.0 Released : plein de nouveautés mais la plus symoblique étant un début de support d’un requêtage SQL dans Elasticsearch.

Sécurité

  • Attacking Private Networks from the Internet with DNS Rebinding : TL;DR Following the wrong link could allow remote attackers to control your WiFi router, Google Home, Roku, Sonos speakers, home thermostats and more. il est donc possible d’abuser un navigateur via un DNS malicieux et donc être en mesure de scanner le réseau local de la personne abusée. Il faut donc considérer le réseau local comme une zone hostile et y appliquer les bonnes pratiques habituelles (authentification, urls en https, etc)

Timeseries

Astuce(s) du mois

Faîtes-vous plaisir et écouter le podcast Artisan Développeur - dans des formats de 10mn environ, un sujet autour de l’agilité, des tests, du TDD, de la responsabilité des développeurs, de SaFE, et de tout ce qui fait partie de notre quotidien de développeurs sont abordés. Depuis quelques épisodes, cela se fait en duo avec d’autres personnes (comme JP Lambert) ce qui rend les échanges encore plus intéressants. Vous retrouvez le podcast sur Soundcloud, Pocketcasts, etc.

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.

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