CérénIT

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

Web, Ops & Data - Avril 2020

traefikscalewaykubernetestelegrafcassandrakafkaconfluenthelminfluxdbwarp10timescaledbdocker-composeapache-pulsarpubsubdeprek8conftestoparaspberrypigitlabsidecar

Code et Outillage

Container & orchestration

(Big) Data

Time Series

Web

  • jQuery 3.5.0 Released! : une faille XSS a été identifiée sur jQuery.htmlFilter pour toutes les versions inférieures à 3.5.0 ; il est vivement encouragé de mettre à jour vos sites. Pour le reste, je vous renvoie à la lecture de l'article.

Web, Ops & Data - Mars 2020

ansiblemoleculetestjavaredistimeseriesinfluxdbwarp10

IaC

  • Ansible Molecule 3.0 : l'outil de test des rôles Ansible est passé en version 3.0. Pas mal de changement avec l'externalisation des providers d'infrastructure sous la forme de module python et d'autres rationalisation. Une check list de migration est disponible

Langages

  • What Tens of Millions of VMs Reveal about the State of Java : NewRelic publie une synthèse des versions et configuration de Java déployées dans la nature. ~85% tourne encore sur Java 8 et 11% sur Java 11 et le tout principalement avec les versions fournies par Oracle. On se moquait des communautés PHP (pour PHP 5 à PHP 7) ou Python (2 vers 3) mais visiblement chaque langage d'un certain age rencontre les mêmes soucis.

Time Series

Paris Time Series Meetup - Edition 4 et 3

timeseriesinfluxdbmeetupptsmtelegraffluxtslredistimeseriesredis

L'édition 4 du Paris Time Series Meetup s'est tenue hier soir. J'ai eu le plaisir d'accueillir David McKay, Developer Advocate InfluxData, qui est venu nous présenter la plateforme InfluxDB 2.0, le nouveau langage Flux et l'outil de collecte Telegraf (et les bonnes pratiques associées).

Vous pouvez d'ores et déjà retrouver les vidéos en ligne ; les présentations sont en anglais :

Et pour les ressources complémentaires mentionnées par David McKay :

Concernant l'édition 3 sur TSL et RedisTimeSeries, initiallement prévue en décembre 2019 et replanifiée le 21 janvier, elle aura finalement lieu le mercredi 25 Mars chez OVHCloud. Pour alimenter votre attente et comme indiqué dans le dernier billet de veille mensuelle, OVHCloud a publié erlenmeyer et vient de publier un billet de blog sur le sujet : TSL (or how to query time series databases).

Nous espérons vous y voir nombreux et en attendant, bon visionnage et bonne lecture !

Web, Ops & Data - Janvier 2020

timeseriescloudovhs3object storagedeltagitdifffaascontainerdraspberrypidockerinfluxdbvscodefluxwarp10observabilitédockercnabpostgresqlgrafana

Meilleurs voeux à tous pour cette nouvelle année !

Cloud

  • OVHcloud Object Storage clusters support S3 API : pour ceux qui ne voulaient pas aller chez OVH car leur système de stockage objet est basé sur Openstack/Swift et ne voulaient pas modifier leurs appels d'API S3, une bonne nouvelle : le stockage objet d'OVH Cloud supporte l'API S3.

Container & Orchestration

  • Managing the TICK Stack with Docker App : cet article aurait pu être dans la section Time Series mais le focus étant sur Docker et Docker App, il sera dans la section Container. L'article montre comment déployer la stack TICK (Telegraf, InfluxDB, Chronograf et Kapacitor) tout d'abord via un fichier docker-compose.yml et ensuite il montre les apports de Docker App, qui permet d'avoir un niveau de personnalisation supplémentaire. Ainsi, on peut avoir un seul fichier docker-compose.yml de référence et auquel on rajoute un fichier avec des propriétés par environnement ou par client ou par instance par ex. Une combinaison intéressante pour améliorer l'industrialisation de vos containers.
  • Kubernetes 1.17 disponible sur l'offre kubernetes managé d'OVHCloud

DevOps/SRE

  • The 3 Myths of Observability : l'observabilité ne va pas directement baisser votre nombre d'incidents, l'observabilité n'est pas qu'une suite d'outils et elle n'est pas gratuite.

Outillage

  • delta : pour améliorer le rendu de vos diff et certaines commandes git (diff, show, log, stash, reflog). L'outil est réalisé en rust. Cela donne un rendu à la github/gitlab dans votre console. Sympa !

Raspberry Pi

  • faasd - lightweight Serverless for your Raspberry Pi : si vous jugez k3s encore trop gros pour vos raspberry pi pour faire tourner OpenFaaS ou que vous ne voulez pas déployer du kubernetes, vous pourriez trouver la solution du coté de faasd. Une implémentation du projet basée sur containerd (le runtime utilisée par Docker)
  • HypriotOS v1.12.0 : la distribution optimisée pour Raspberry Pi et fournissant Docker arrive en version 1.12. Elle permet d'utiliser Docker sur tous les modèles de Raspberry (0, 1, 2, 3, 4) avec les dernières versions de docker, docker-compose et docker-machine.

SQL

  • Améliorez votre SQL : utilisez des index filtrés : Postgresql permet de définir des index filtrés : plutôt que de créer un index sur toutes les données d'une table, vous pouvez définir un index qui répond à un filtre et ne faire un index que sur ce sous-ensemble de données.

Time Series

  • Grafana v6.6 Released : nouvelle version de Grafana avec comme d'habitude plein d'améliorations à tous les étages (data source, panels, alerting, explore, etc)
  • Release Announcement: Flux VSCode Support : InfluxData a publié une extension VSCode pour le langage flux.
  • InfluxDB 2.0 Open Source Beta Released : InfluxData passe la version OSS d'iInfluxDB 2.0 en béta après une année de versions alpha. On y trouve notamment une approche Configuration As Code avec la possibilité de définir des Tasks, Dashboards, ainsi que de la configuration via des Manifest en YAML et un système de packages. Flux, le nouveau langage de requêtage continue à s'améliorer et enfin le transpiler InfluxQL vers Flux fait son entrée mais demande à s'améliorer au fil du temps. La beta 2 est sortie aussi.
  • telegaf warp10 output : la prochaine version de Telegraf supportera nativement Warp10.
  • Erlenmeyer: Time Series query translator : OVHCloud vient d'opensourcer le code de leur proxy en go qui leur permet de parser des requêtes de différentes bases de données time series (OpenTSDB, PromQL, Prometheus Remote Read, InfluxQL et Graphite) en Warpscript pour requêter les données stockées dans Warp10. Pour rappel, la solution OVHMetrics est basée sur Warp10.
  • Le traitement et l'utilisation de la data dans l'industry 4.0 : SenX, la société éditrice de Warp10, a réalisé une vidéo intéressante sur le traitement et l'utilisation de la data dans l'industrie 4.0. On y voit notamment les 4 niveaux de maturité quant à la donnée et le rôle d'une base de données temporelles dans ce contexte. Un billet de blog (en anglais) est également disponible.

Web, Ops & Data - Décembre 2019

influxdbdockerkubernetestraefikgrafanadashboardcassandrareaperwarp10timeseriestimescaledbhelmmachine-learning

Rendez-vous le 21 janvier prochain à la troisième édition du Paris Time Series Meetup consacré à TSL (billet introductif à TSL : TSL: a developer-friendly Time Series query language for all our metrics) et le module RedisTimeSeries qui apporte des fonctionnalités et des structures Time Seriies à Redis. Le meetup était prévu initialement le mardi 17 décembre mais a été reporté du fait des grèves.

Container et orchestration

  • DockerSlim : le projet vise à réduire la taille de vos images et à améliorer leur sécurité en procédant à différentes optimisations. Cela peut être intéressant dans une stratégie d'améliorations de vos images docker mais à tester néanmoins. Les exemples données partent d'Ubuntu 14.04 dont l'image fait 60 / 65 Mo alors que l'image Ubuntu 16.04 fait moitié moins et Alpine fait 30 fois moins. Donc certains gains semblent faciles à obtenir, à creuser plus en détail.
  • Kubernetes 1.17: Stability : après une version 1.16 marquée notamment par la dépréciation de certaines APIs, cette version se veut plus une consolidation autour des "Cloud Provider Labels" qui passent en GA, le snapshot de volumes qui passe en beta, ainsi que la couche de stockage CSI avec la poursuite de la migration des plugins "in-tree" vs "out-of-tree". La fin de cette migration est prévue pour les versions 1.19 / 1.20 et le retrait complet des plugins "in-tree" pour les versions 1.21 / 1.22.
  • A visual guide on troubleshooting Kubernetes deployments : un guide du troublehooting des déploiements sous kubernetes avec un joli diagramme des cas possibles et les explications associées en repartant d'un exemple simple.
  • How to migrate from Helm v2 to Helm v3 : les opérations à mener pour migrer de Helm V2 à Helm V3.
  • Traefik 2.1 : le provider Consul Catalog fait son retour (il était absent en 2.0.x) et diverses améliorations sur la CRD Kubernetes ont été apportées pour mieux gérer le mirroring du traffic, les déploiements canary et la gestion des sessions. La migration ne consistant pas seulement à changer le numéro de version et suite à une remarque de ma part, une note a été ajoutée pour la migration 2.0.x vers 2.1.x

Dataviz

NoSQL

  • Cassandra Reaper 2.0 was released : la solution de réparation de vos clusters Cassandra passe en 2.0 ; elle apporte un déploiement en mode sidecar (reaper est lancé dans la même jvm que Cassandra), le support d'Apache Cassandra 4.0 (pas encore officiellement disponible), de nouveaux thèmes, une amélioration du support de Postgresql comme backend de déploiement et pleins d'autres choses.

Time Series

Je n'ai plus qu'à vous souhaiter des bonnes fêtes de fin d'année ; nous nous retrouvons l'année prochaine !

Exporter les métriques Traefik dans InfluxDB dans un contexte Kubernetes

kubernetestraefikinfluxdbmétriquetimeseries

Traefik, depuis sa version V1, permet d'envoyer des métriques vers différents backends (StatsD, Prometheus, InfluxDB et Datadog). J'ai enfin pris le temps d'activer cette fonctionnalité et de creuser un peu le sujet étant donné que le dashboard de Traefik V2 n'affiche plus certaines de ses statistiques.

La documentation de Traefik sur le sujet :

Commençons par créer une base traefik dans InfluxDB (version 1.7.8)

influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.9
> auth
username: XXX
password: XXX
> CREATE DATABASE traefik
> CREATE USER traefik WITH PASSWORD '<password>'
> GRANT ALL ON traefik to traefik
> SHOW GRANTS FOR traefik
database privilege
-------- ---------
traefik  ALL PRIVILEGES
> quit

Dans mon cas, l'accès à InfluxDB se fait en https au travers d'une (autre) instance Traefik. J'utilise donc la connexion en http plutôt qu'en udp.

Cela donne les instructions suivantes en mode CLI :

    --metrics=true
    --metrics.influxdb=true
    --metrics.influxdb.address=https://influxdb.domain.tld:443
    --metrics.influxdb.protocol=http
    --metrics.influxdb.database=traefik
    --metrics.influxdb.username=traefik
    --metrics.influxdb.password=<password>

J'ai gardé les valeurs par défaut pour addEntryPointsLabels (true), addServicesLabels (true) et pushInterval (10s).

Cela donne le Deployment suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: traefik2-ingress-controller
  labels:
    k8s-app: traefik2-ingress-lb
spec:
  replicas: 2
  selector:
    matchLabels:
      k8s-app: traefik2-ingress-lb
  template:
    metadata:
      labels:
        k8s-app: traefik2-ingress-lb
        name: traefik2-ingress-lb
    spec:
      serviceAccountName: traefik2-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:2.0.6
        name: traefik2-ingress-lb
        ports:
          - name: web
            containerPort: 80
          - name: admin
            containerPort: 8080
          - name: secure
            containerPort: 443
        readinessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 1
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        livenessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        args:
          - --entryPoints.web.address=:80
          - --entryPoints.secure.address=:443
          - --entryPoints.traefik.address=:8080
          - --api.dashboard=true
          - --api.insecure=true
          - --ping=true
          - --providers.kubernetescrd
          - --providers.kubernetesingress
          - --log.level=ERROR
          - --metrics=true
          - --metrics.influxdb=true
          - --metrics.influxdb.address=https://influxdb.domain.tld:443
          - --metrics.influxdb.protocol=http
          - --metrics.influxdb.database=traefik
          - --metrics.influxdb.username=traefik
          - --metrics.influxdb.password=<password>

Appliquer le contenu du fichier dans votre cluster Kubernetes

kubectl apply -f deployment.yml -n <namespace>

Sur le dashboard Traefik, dans la section "Features", la boite "Metrics" doit afficher "InfluxDB", comme ci-dessous :

Traefik Dashboard avec les métriques InfluxDB activés

Vous pouvez alors vous connecter à votre instance InfluxDB pour valider que des données sont bien insérées :

influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.9
> auth
username: traefik
password:
> use traefik
Using database traefik
> show measurements
name: measurements
name
----
traefik.config.reload.lastSuccessTimestamp
traefik.config.reload.total
traefik.entrypoint.connections.open
traefik.entrypoint.request.duration
traefik.entrypoint.requests.total
traefik.service.connections.open
traefik.service.request.duration
traefik.service.requests.total

Il ne vous reste plus qu'à utiliser Chronograf ou Grafana pour visualiser vos données et définir des alertes.

Un exemple rapide avec la répartition des codes HTTP dans Grafana :

Graphiques des données de Traefik depuis InfluxDB dans Grafana

Web, Ops & Data - Aout 2019

gitlabcicdcontinous integrationcontinous deploymentgitdiffdockerrpitraefikkubernetesovhhelmpostgresperconaawspartiqlredistimeseriesinfluxdbkafkaprometheus

Surveillez le Time Series Paris Meetup, car la première édition du Meetup sera annoncée mardi avec une présentation des usages avancées des séries temporelles avec Warp10 (comprendre au-delà du monitoring classique) et une présentation par les équipes OVH sur du monitoring de datacenter aidé par du machine learning et leur offre Préscience.

CI/CD

  • How to trigger multiple pipelines using GitLab CI/CD : depuis une pipeline d'un dépôt gitlab, il va être possible d'appeler les pipelines des autres projets gitlab. Une fonctionnalité intéressante et qui pourrait lever la dépendance à Jenkins lorsque l'on a des pipelines un peu complexes et inter-projets.
  • New up and coming GitLab CI/CD Features : bilan et perspectives par le responsable produit de gitlab sur les fonctionnalités CI/CD qui ont été rajoutées cette année et celles à venir.

Code

Conteneurs & orchestration

SQL

time series

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 - Avril 2019

influxdbtimescaledbtraefikkubernetesssh-agentpostgresrecherchedockerloggoogle cloud nextserverlessapmglowrootdocker registry

Deux petites annonces pour démarrer cette édition :

  • Je serai à KubeCon EU du 20 au 23 Mai à Barcelone. Si vous y allez aussi, dites le moi, ce sera une occasion de se rencontrer.
  • Le BigData Hebdo a ouvert son slack - Vous pouvez nous rejoindre par vous même via ce lien

APM

  • Glowroot : Pour ceux qui s'intéressent au sujet de l'APM et qui ne veulent pas aller chez AppDynamics, Dynatrace ou Elastic, j'ai assisté à une démo intéressante sur Glowroot - il est forcément moins riche que ces concurrents mais il a l'air de faire l'essentiel de ce que l'on peut attendre d'un APM. Il ne marche qu'avec la JVM.

Cloud

Container et Orchestration

DevOps

  • JSON as configuration files: please don’t : Si certains pensaient utiliser JSON pour décrire des fichiers de configurations, l'article rappelle que JSON n'est qu'un format d'échange de données et surtout pas de fichiers de configuration. On peut comprendre la tentation mais on a déjà bien assez à faire avec YAML, INI voire XML. Aucun n'est parfait certes mais pas la peine d'en rajouter.
  • In Defense of YAML : L'auteur critique l'abus autour de YAML pour l'utiliser pour tout et n'importe quoi. Comme format de données, il est utilisable mais nous voyons des détournements où du yaml devient du pseudo code. L'auteur cite la CI Gitlab ou encore Tekton. On ne peut que lui donner raison. Il serait plus simpe d'avoir un vrai langage de programmation plutôt que de tout "YAMLiser".

Licences

  • Deprecation Notice: MIT and BSD (via Les Cast Codeurs) : Intéressant, les licences BSD/MIT serait à considérer comme dépréciée. L'auteur travaille pour le Blue Oak Council qui publie la licence du même nom. On peut éventuellement lui reprocher un certain biais mais il indique quand même que des licences modernes (comme ASL 2.0) seraient plus judicieuses que de rester sur du MIT/BSD.

Sécurité

SQL

Timeseries

Astuce du mois : gestion de la rotation des logs d'un container docker

Dans les bonnes pratiques Docker, il est dit d'utliser stdout/stderr pour avoir les logs de votre conteneur via docker logs. Toutefois, cette pratique va alimenter un fichier de log /var/lib/docker/containers/<container id>/<conteiner id>-json.log. Ce fichier peut donc saturer votre disque et aller jusqu'à corrompre vos conteneurs. L'autre bonne pratique étant que tout fichier de log doit avoir une politique de rotation du fichier associée pour éviter toute saturation de disque ou d'avoir des trop gros fichiers de logs.

Docker permet de configurer le driver de logs au niveau du démon (via /etc/docker/daemon.json), en argument lors d'un docker run ou dans docker-compose.yml.

Si l'on reste sur le driver json-file et que l'on veut piloter la rotation des logs au niveau de docker-compose.yml, cela donne par ex (version simplifiée) :

version: '3'
services:
  service_xxx:
    image: docker_image_xxx
    [...]
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "10"

Vous pouvez alors définir une stratégie de rotation des logs par container si vous le souhaitez. Ainsi, vous gérer la taille maximale de logs qui vont être générés et êtes ainsi assurés de ne pas avoir de mauvaises surprises à ce niveau là.

Web, Ops & Data - Septembre 2018

cassandradockerswarmpythonjquerylambdaansibleinfluxdbterraformhashicorpfacebookiaengineeringcloud

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 :

← Précédent 3 / 4 Suivant →