Architecte de vos plateformes/produits et agitateur de séries temporelles

Conception, développement, déploiement et exploitation de vos plateformes, applications et données.

Contactez-nous !
Accueil >

Web, Ops, Data et Time Series - Avril 2021

falco sysdig sécurité dashboard raspberrypi pico hashicorp vault vector containerd git git-filter-repo psp gitlab-ci podman warp10 sqlite terraform timescale velero docker docker-compose grafana loki tempo kubernetes minio influxdata notebook geospatial agpl bme680 co2

Code

Conteneur et orchestration

  • Electro Monkeys - Docker Compose avec Nicolas de Loof : Retour sur la Developper Experience autour de Docker, l’historique et le futur de docker-compose, la création de la spécification Compose, les intégrations AWS/ECS et Azure/ACI, l’intégration Kubernetes, etc.
  • nerdctl: Docker-compatible CLI for contaiNERD : une CLI qui imite la CLI Docker mais en interagissant directement avec containerd. Elle permet aussi de bénéficier de certaines fonctionnalités de containerd qui ne sont pas prévues pour tout de suite dans Docker apparemment.
  • Blog: Kubernetes 1.21: Power to the Community : au programme de cette nouvelle version : Cronjobs GA, Immutable Secrets and ConfigMaps GA, IPv4/IPv6 dual-stack support, Graceful Node Shutdown, PersistentVolume Health Monitor mais aussi PodSecurityPolicy Deprecation et TopologyKeys Deprecation
  • PodSecurityPolicy Deprecation: Past, Present, and Future: article plus détaillé sur la dépréciation des PSP.
  • Podman v3.1.0 Released : ajout de la gestion des secrets, améliorations des commandes kube avec notamment la génération des PersistentVolumeClaim ou encore la gestion des propriétaires des volumes.
  • Velero 1.6.0 : améliorations diverses comme le support des identifiants par buckets (et non globaux uniquement), mise à jour de restic vers 0.12.0, etc.
  • Compose CLI Tech Preview : compose devrait devenir une sous-commande officiel de la CLI Docker ; on pourra alors faire docker compose up -d
  • Docker 20.10.6 : version de maintenance avec le support des puces Apple Silicon M1.
  • Kubernetes : vers 3 releases par an au lieu de 4 : de quoi courrir un peu moins derrière les versions et à relier avec le support de chaque version étendue à 1 an depuis la 1.19.

Data

  • sq: swiss-army knife for data : le jq pour les données relationelles. Du SQL ou des fichiers Excel/CSV/JOSN/XML en entrée et les mêmes formats en sortie (et un peu plus).
  • SQLite is not a toy database : On a souvent une fausse image de sqlite - l’article permet de se mettre à jour…

IaC

IoT

  • Pico 2 Pi Adapter Board : un petit adapteur sympathique pour Raspeberry Pi Pico et vous permettre de brancher facilement vos composants sans soudure et mener ainsi vos expériences.
  • Piper Make : Pour programmer facilement votre Raspberry Pi Pico en MicroPython mais avec une logique de blocs à la Scratch.
  • Utilisation des BME680 et RV3028 avec Raspberry Pi Pico : le composant BME680 permet d’évaluer la qualité de l’air - le projet permet donc de capturer et d’afficher cette information avec un Raspberry Pi. Son successeur, le BME688 dispose d’une pincée d’IA.
  • Projet CO2 et Makers CO2 : pour mieux comprendre les enjeux autour de l’aération des pièces et comment faire vos capteurs.

Observabilité & Monitoring

Réseau

  • The Mystery of AS8003 : Une entité inconnue jusque là mais liée à l’administration américaine a annoncé la gestion d’une très grande plage réseau. Les implications et les motivations sont encore à éclaircir. Le billet émet différents hypothèses. Le thread twitter associé est intéressant aussi.

Sécurité

Time Series

Web, Ops & Data - Février 2021

java repository artefact timescale postgres kapacitor grafana nomad hashicorp podman docker-compose registry docker golang vscode warp10 dataviz transformation vector linter

Container et orchrestration

  • Running Nomad for home server : pour avoir mené une expérience très similaire sur le mois de janvier, je me retrouve complètement dans ce retour d’expérience sur nomad (vs kubernetes dans une certaine mesure). Le trio nomad/consul/vault permet de faire des choses assez proches de ce que l’on peut faire avec kubernetes et parfois même de façon plus simple. Et ce, avec moins de couches intermédiaires (CSI, CNI, etc) mais aussi quelques fonctionnalités en moins. Un compromis assez réussi je trouve entre un docker nu et/ou avec docker-compose et un kubernetes.
  • Podman 3.0 has been released! : support de docker-compose, support des noms courts d’image, amélioration sur le réseau, apport de la dernière version de buildah, correction d’une CVE, etc.
  • Donating Docker Distribution to the CNCF : Docker Inc donne sa registry à la fondation CNCF pour fédérer les initiatives autour d’un même standard et élargir le champ des contributeurs/mainteneurs.
  • Panorama des outils de sécurité autour des conteneurs : comparaison des outils de bonnes pratiques et d’analyses de vulnérabilités des containers docker pour améliorer la sécurité de vos conteneurs.

Code

Monitoring & observabilité

Time Series

Si vous êtes en manque de news, vous pouvez aller consulter (et vous abonner) aux brèves du BigData Hebdo

Web, Ops & Data - Décembre 2020

docker runc rootless swarm cgroups kubernetes cri dockershim vector aws timestream warp10 dashboard ptsm timescale centos rhel podman influxdb timeseries

Containers et orchestration

  • Electro Monkeys #37 – Podman, l’alternative de Redhat à Docker avec Benjamin Vouillaume : je me demandais si podman permettait un management de containers à distance et l’étendue de son écosystème. Le podcast permet de compléter le tour du propriétaire et de se faire une bonne idée de son positionnement.
  • How to deploy on remote Docker hosts with docker-compose : dans la même quête, je me demandais s’il était possible de piloter un noeud docker à distance quand je me suis rappelé qu’il était possible de le faire au travers d’une connexion ssh. En creusant un peu plus, j’ai découvert la notion de contexte qui permet ainsi de cibler un noeud docker, docker swarm ou kubernetes.
  • Don’t Panic: Kubernetes and Docker et Dockershim Deprecation FAQ : A partir de kubernetes 1.20 (fin 2020) et définitivement à partir de la version 1.23 (fin 2021), le retrait du binaire docker comme CRI de Kubernetes est annoncé. Cela ne devrait pas changer grand chose et c’est essentiellement de la plomberie interne. Plutôt que de passer par Dockershim qui implémentait l’interface CRI et qui discutait ensuite avec Docker pour lancer les conteneurs via containerd, l’appel sera directement fait à containerd. Il n’y a que ceux qui montent la socket docker dans les pods qui vont avoir un souci. Si c’est pour builder des images, il y a des alternatives comme img, kaniko, etc. Pour les autres cas, il faudra peut être passer par l’API kubernetes ou trouver les alternatives qui vont bien.
  • What developers need to know about Docker, Docker Engine, and Kubernetes v1.20 et Mirantis to take over support of Kubernetes dockershim : Mirantis et Docker Inc vont assurer le support de cette interface dockershim pour permettre à ceux qui ont en besoin de pouvoir continuer à l’utliiser. La limite étant que si vous êtes sur du service managé et que votre provider ne le fournit pas, vous ne pourrez pas l’utiliser…
  • Kubernetes 1.20: The Raddest Release : voilà, la version 1.20 est sortie et apporte son lot de nouveautés et de stabilisation.
  • Announcing General Availability of HashiCorp Nomad 1.0 : Nomad 1.0 est également disponible.
  • Introducing Docker Engine 20.10 - Docker Blog : Docker 20.10 arrive avec des profondes nouveautés comme le support des cgroupsv2 et un mode rootless, docker logs fonctionne avec tous les drivers de log et non unqiement json & journald et plein d’autres améliorations/harmonisations au niveau de la CLI. Pour ceux sous Fedora qui avaient bidouillé avec firewalld précédemment pour faire fonctionner docker et qui ont un problème lié à l’interface docker0 au démarrage du service docker, allez voir par ici.
  • Docker Engine Release Notes - Version 20.10 : En plus des points précédents, il y a l’arrivée des jobs dans swarm - depuis le temps que je l’attendais 🤩 (même si on peut se toujours se poser la question de la pérénnité de swarm depuis qu’il a été racheté par Mirantis)
  • New features in Docker 20.10 (Yes, it’s alive) : un billet décrivant plus en détail certaines feautres de docker 20.10 comme support Fedora/CentOS, le rootless mode, l’option -mount, les jpbs swarm et une synthèse de l’actualité de l’écosystème docker.
  • Podman Release 2.2.0 : ajout des commandes network (dis)connect, support des alias avec des noms courts, amélioration des commandes play|generate kube et capacité de monter une image OCI dans un container.

Observabilité

  • Vector - Collect, transform, & route all observability data with one simple tool. (via) : vector est un outil en rust qui permet de collecter et manipuler des métriques/logs/événements et de les envoyer vers différentes destinations. De quoi remplacer filebeat/journalbeat voire même telegraf ? ;-)
  • Our new partnership with AWS gives Grafana users more options : AWS vient d’annoncer un service managé pour Prometheus basé sur Cortex et pour Grafana (version Entrepsise). Grafana et Cortex étant des projets édités par Grafana Labs sous licence OSS (et des déclinaisons Cloud et Entreprise). AWS changerait-il sa façon de travailler avec les projets OSS lorsqu’il souhaite en faire des services managés et prendre ainsi une attitude plus positive vis à vis de la communauté OSS ?

OSS

  • Death of an Open Source Business Model : Analyse du passage de Mapbox GL JS v2 sous licence propriétaire, le modèle de l’open core et les menaces des top cloud providers sur le reste de l’économie du logiciel. On peut étendre cela aussi “VC funded OSS company”.

Système

  • CentOS Project shifts focus to CentOS Stream, CentOS Stream: Building an innovative future for enterprise Linux et la FAQ associée : Historiquement CentOS Linux était batie sur les sources de Red Hat Entreprise Linux un fois celle-ci disponible. CentOS Stream renverse un peu la tendance avec un cycle d’intégration plutôt Fedora -> CentOS Stream -> RHEL. L’initiative CentOS Stream avait été annoncée en septembre 2019 et ce changement permet donc aux équipes CentOS de se focoaliser sur une seule version (CentOS Stream) et non plus deux versions (CentOS Stream et CentOS Linux). CentOS Linux 7 sera maintenue jusqu’à la fin du support de RHEL 7 et et CentOS 8 jusqu’à fin 2021 (et non pas 2029 comme prévu). Il n’y aura pas de version 9 de CentOS Linux. A tester pour voir si CentOS Stream est plus stable que Fedora mais moins conservateur que RHEL et pourrait alors s’avérer être un bon compromis.
  • Before You Get Mad About The CentOS Stream Change, Think About… : un billet assez long d’un employé de Red Hat qui exprime son opinion et cherche à remettre les choses en perspective en dépassionnant le débat.

Time Series

  • PTSM Edition #8 - Amazon TimeStream 101 : Edition du Paris time Series Meetup sur AWS Timestream
  • TimescaleDB vs. Amazon Timestream: 6000x higher inserts, 5-175x faster queries, 150x-220x cheaper : avec toutes les réserves habitudelles sur les benchmarks, Timescale a comparé son produit avec AWS Timestream et la conclusion semble clairement en faveur de Timescaledb. A noter que l’update des données est arrivé dans AWS Timestream entre temps.
  • Truly Dynamic Dashboards as Code : les équipes de SenX ont implémenté leur vision du “Dashboards as Code” sous le nom Discovery. Discovery veut aller plus loin que la simple description d’un dashboard comme on peut le voir dans Grafana ou InfluxDB 2.0 en apportant une touche de dynamisme et de génération dynamique des dashboards en fonction des élements obtenus (ex si valeur X > Y alors afficher la procédure AAA de résolution d’incident). J’ai commencé à jouer avec, un billet de blog sur ce sujet devrait bientôt arriver.
  • NeuralProphet : un modèle neuronal orienté série temporelles, inspiré de Facebook Prophet et développé avce PyTorch.
  • Release Notes InfluxDB 2.0.3 et Release Announcement: InfluxDB OSS 2.0.3 : build arm64 en preview, un petit conflit de packaging entre influxdb et influxdb2 à passer pour ceux qui étaient déjà en 2.0 et ceci afin d’éviter que des gens en 1.x passent involontairement en 2.x, le “delete with predicate” a été réactivé, améliorations sur le process d’upgrade, des commandes autour des actions en mode V1, mise à jour de flux, et plein d’autres corrections/améliorations.

Web

  • Web Almanac 2020 - Rapport annuel de HTTP Archive sur l’état du Web : une synthèse de l’état du web d’après HTTP Archive sur une base de 7.5 millions de sites testés, soit 31.3 To de données traitées. De quoi relativisez un peu les biais de notre bulle technologique : non tout le monde ne fait pas du React/Angular/Vue.js par ex mais plutôt du JQuery ! Suivant vos usages, plein d’enseignements et de choses intéressantes à tirer de cette synthèse.

Il ne me reste plus qu’à vous souhaiter de bonnes fêtes de fin d’année et on se retrouve l’année prochaine !

Docker et déploiement distant : tout est histoire de contexte

docker context ssh gitlab gitlab-ci

Kubernetes, c’est bien mais parfois on veut faire des choses plus simples et on n’a pas forcément besoin d’avoir un système distribué ou d’une forte disponibilité. Pour autant, il est agréable avec kubernetes de pouvoir interagit à distance avec l’API au travers de kubectl. Je me suis donc mis en quête d’une alternative. Partir sur k3s avec un déploiement mono-node ? Partir sur docker/docker-compose/docker-swarm ?

Je me souvenais que l’on pouvait exposer la socket docker sur le réseau en TCP et authentification par certificat mais cela ne me plaisait pas beaucoup. Je me suis alors rappelé que l’on pouvait interagir avec un hote docker via une connection ssh. En continuant à creuser, je suis tomber sur les contextes dans Docker et ce billet How to deploy on remote Docker hosts with docker-compose. Et là : 🤩

Alors, certes, pas de secrets, configmaps ou cronjobs mais un déploiement remote que je peux automatiser dans gitlab et/ou avec lequel je peux interagir à distance 😍

Création d’un contexte puis utilisation d’un contexte :

# Création du contexte docker
docker context create mon-serveur ‐‐docker “host=ssh://user@monserveur”

# Lister les contextes docker existant
docker context ls

# Utiliser un contexte
docker context use mon-serveur

# Vérifier le bon fonctionnement de la cli docker
docker ps
[liste de conteneurs tournant sur la machine "mon-serveur"]

# Vérifier le bon fonctionnement de la cli docker-compose
cd /path/to/docker/compose/project
docker-compose ps

Pour que cela fonctionne, en plus des versions récentes de docker et docker-compose coté client et serveur. Il vous faut aussi une version récent de paramiko coté client. Celle présente dans Debian 10 n’est pas assez à jour par ex, il a fallu passer par pip3 install paramiko. Il faut aussi avoir une authentification par clé pour se simplifier la vie.

Pour docker-compose, vous avez deux solutions pour utiliser un contexte distant :

# En deux commandes
docker context use <remote context>
docker-compose <command>

# En une commande
docker-compose --context <remote context> <command>

Dans gitlab, dans le fichier .gitlab-ci.yml, on peut alors profiter de cette intégration de la façon suivante ; je prends l’exemple du déploiement du site du Paris Time Series Meetup.

Tout d’abord, dans mon fichier docker-compose.yml, j’ai mis un place holder IMAGE qui sera remplacé par la référence de mon image docker fabriquée par gitlab-ci :

version: '3.8'
services:
  web:
    image: IMAGE
    labels:
        [...]
    restart: always

Ensuite, dans gitlab-ci :

  • le job “publish” génère la version html du site et le stock dans un artefact gitlab.
  • le job “kaniko” va générer l’image docker contenant la version html du site. Pour passer la version de l’image, je stocke l’information dans un fichier docker.env. Ce fichier sera sauvegardé en fin de job sous la forme d’un artefact disponible pour le job “docker”.
  • le job “docker” recupère ce qui était dans le docker.env sous la forme de variable d’environnement. Il remplace ensuite IMAGE par sa vraie valeur. On initialise le contexte docker pour se connecter au serveur cible et on peut alors réaliser les actions habituelles avec docker-compose.
---
stages:
  - publish
  - image
  - deploy

publish:
  image:  $CI_REGISTRY/nsteinmetz/hugo:latest
  artifacts:
    paths:
      - public
    expire_in: 1 day
  only:
    - master
    - web
  script:
    - hugo
  stage: publish
  tags:
    - hugo

kaniko:
  stage: image
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  variables:
    RELEASE_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_ID-$CI_JOB_ID
  script:
    - echo "IMAGE=${RELEASE_IMAGE}" >> docker.env
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $RELEASE_IMAGE
  only:
    - master
    - web
  when: on_success
  tags:
    - kaniko
  artifacts:
    reports:
      dotenv: docker.env

docker:
  stage: deploy
  before_script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  script:
    - sed -i -e "s|IMAGE|${IMAGE}|g" docker-compose.yml
    - docker context use mon-serveur
    - docker-compose pull
    - docker-compose up -d
  needs:
    - job: kaniko
      artifacts: true
  when: on_success
  only:
    - master
    - web
  tags:
    - shell
  environment:
    name: production
    url: https://www.ptsm.io/

Et voilà ! 😎

Avec ces contextes (que l’on peut utiliser aussi avec swarm et kubernetes), on a donc un moyen simple et efficace pour déployer des conteneurs à distance et de façon automatisée.

DataTask

python go gcp docker terraform kubernetes data pipeline

Contexte

Editeur d’une plateforme data, la société cherche à se faire accompagner et confier le role de Lead Platform à une personne en mesure d’industrialier et d’automatiser la plateforme, son déploiement et son exploitation mais aussi d’améliorer les pratiques de développement de l’équipe. Une contribution directe au produit est également envisagé.

Notre réponse

En tant que Lead Platform :

  • Passage d’un logique “Build/Ship” à une logique “Build/Ship/Run”
  • Mise en place de Gitlab et Gitlab-CI pour le suivi du code et l’automatisation des tâches,
  • Migration des outils de déploiement sous Terraform et Ansile en fonction des cas,
  • Mise à jour des composants de la plateforme et de l’outillage autour de la plateforme,
  • Amélioration des pratiques de développement et recette : amélioration du process de revue de code et de validation d’un développement, mise en place des “Architectural Design Review” pour cadrer les initiatives, etc.
  • Amélioration des pratiques de monitoring et d’exploitation des plateformes
  • POC Nomad/Consul/Terraform comme alternative à Kubernetes pour des déploiements plus légers,
  • Déploiement du logiciel chez différents cloud proviers (GCP, AWS, Scaleway, etc)
  • Etc.

Bénéfices pour l’éditeur

  • Expertise sur les pratiques d’automatisation et d’industrialisation des process de développement et de déploiement
  • Réduction de la dette technique et remise au carré des outils et des plateformes
  • Adoption des outils considérés comme à l’état de l’art
  • Fiabilisation des processus de développement et de déploiement

Bénéfices pour CérénIT

  • Premier projet professionel en Go
  • Premer POC avec Nomad, Consul et Vault
  • Travail sur la transimission des pratiques et de la culture de l’automatisation & industrialisation