CérénIT

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

Web, Ops, IoT et Time Series - Avril 2024

redis licence xz backdoor valkey ia http2 warp10 duckdb jq hashicorp ibm sxsw

Cette édition et les précédentes sont également disposnibles sur substack Web, Ops, IoT & Time Series pour ceux qui préfèrent les emails ou la consommation via l’app Substack

Data

  • DuckDB as the new JQ : DuckDB pouvant lire des fichiers JSON, il était tentant pour certains de manipuler des fichiers JSON en SQL…

Database

  • Redis Adopts Dual Source-Available Licensing | Redis - The race to replace Redis - Linux Foundation Launches Open Source Valkey Community : A compter de la version 7.4, Redis passe d’une version open source (licence BSD) à une double licence “Source Available” pour officiellement contrer les vilains méchants concurrents qui ne reversent pas à la communauté. Bizarrement, la “Common Clause” adoptée en 2018 pour les mêmes raisons n’a pas suffit. La réponse de la communauté ne s’est pas fait attendre avec la création du projet Valkey sous l’égide de la Linux Foundation. Si le passage d’un projet dans le giron d’une fondation peut rassurer ses utilisateurs et contributeurs sur la licence du projet, il n’en reste pas moins qu’il faut sécuriser les revenus de la société éditrice du projet. Cela pose aussi la question de notre attachement à l’Open Source - est-ce par philosophie ou par confort d’utilisation et la gratuité ? La fin de l’argent facile montre aussi les limites du financement des projets OSS via des VC ; certains ont fait évolué leur produit de façon plus subtile (ou pas) ou leur criticité est moindre pour ne pas provoquer une réaction comme pour Redis (Inc).
  • Valkey 7.2.5 : Première version de Valkey, un Redis 7.2.4 nettoyé et avec quelques améliorations. Cela aura été rapide, mais avant de sauter le pas, il va falloir voir comment l’écosystème prend…

IA

Infrastructure as Code

  • HashiCorp joins IBM to accelerate multi-cloud automation : après le changement de licence en aout 2023, il semblait assez évident qu’HashiCorp cherchait à se faire racheter. IBM est donc l’heureux élu avec une valorisation d’HashiCorp à 6.4 Milliards de dollars. Après l’arrivée des projets OpenTofu (fork de Terraform) et OpenBao (fork de Vault) sous l’égide de la Linux Foundation, on pouvait se demander comment cela allait finir pour Hashicorp. Même si IBM contribue à l’open source, on aurait pu espérer meilleure maison pour HashiCorp. IBM n’est pas forcément perçu comme une zone d’innovation. Une piste qui pourrait néanmoins être intéressante avec cette acquisition et pour réconcilier la communauté, c’est que HashiCorp soit rattaché à Red Hat dans une division “Cloud & Automatisation / DevSecOps” au coté de projets comme Ansible par ex.

Sécurité

Time Series

Web, Ops, Data et Time Series - Juillet 2021

kubernetes gitlab-ci buildah podman kaniko golang scaleway ia aws frenchtech euclidia vector sécurité opnsense wireguard katz facebook prophet arima sarima holt-winters lstm

CI/CD

Cloud

Container & Orchestration

Golang

IA

  • AI Days 2020 : la playlist youtube des AI Days 2021 est disponible, avec un angle industriel qui change de d’habitude.

Monitoring

  • Vector v0.15.0 release notes : de nouveaux sinks & sources, des transformations et de la visualisation. Vector s’améliore au fil des versions.

Sécurité

Time Series

WireGuard

Web, Ops & Data - Septembre 2018

cassandra docker swarm python jquery lambda ansible influxdb terraform hashicorp facebook ia engineering cloud

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 :