26/09/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
- So you have a broken Cassandra SSTable file? : que faire lorsqu’une SSTable est corrmpue, c’est tout l’objet de cet article, de la plus simple et moins impactante à la plus complexe/impactante. Sans aller jusqu’à la corruption, nous avons eu un cas similaire et un
nodetool scrub <keysapce> <table> a été suffisant.
- Incremental Repair Improvements in Cassandra 4 : les réparations incrémentales, déconseillées jusqu’alors par les gens de The Last Pickle, semblent devenir la solution recommandée avec la sortie prochaine de Cassandra 4.0. Les réprations complètes (full) ne seraient alors utiles que dans certains cas, car moins efficientes.
- Introducing cstar: The Spotify Cassandra orchestration tool, now open source : Spotify ouvre le code de son shell distribué pour Cassandra, sous le nom de cstar Il a pour intérêt d’être conscient de la topology du cluster et donc de pouvoir faire les commandes de façon optimisées.
- Architecture Lambda, Cassandra et synchronisation des données : après un petit rappel sur l’architecture lambda, l’article présente les différents patterns permettant de garantir qu’une donnée stockée dans Cassandra et pouvant être mise à jour de façon concurrente par un flux batch et un flux temps réel ait toujours la valeur la plus fraîche.
- Why We Built an Open Source Cassandra-Operator to Run Apache Cassandra on Kubernetes : Instaclustr propose un Operator Cassandra pour déployer plus faciment Cassandra sur Kubernetes.
- Terraform InfluxDB Module : InfluxData a annoncé un partenariat avec Hashicorp et le premier livrable est un module terraform permettant de déployer InfluxDB OSS ou Entreprise sur AWS.
(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 :
- “all.yaml” est chargé en premier
- 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 :