CérénIT

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

Web, Ops & Data - Janvier 2018

mysql mariadb root dns ssh bastion docker kubernetes let's encrypt test unitaire test coreos redhat

Container & Orchestration

  • Core Workloads API GA : la version 1.9 de Kubernetes sortie tout début janvier marque un tourant intéressant avec le passage en stable des “Core Workload API” (Pod, ReplicationController, ReplicaSet, Deployment, DaemonSet, and StatefulSet). Avec cette stabilisation des termes, des concepts et des API, c’est le socle de Kubernetes qui se stabilise sérieusement. Une bonne raison de plus de creuser cette solution au fur et à mesure que l’écosystème va se stabiliser et se simplifier.
  • The Twelve-Factors Kubernetes : Revue de la terminilogie et des concepts de Kubernetes au travers de 12 points et énonciation de quelques bonnes pratiques générales associées.
  • Traefik 1.5 - Cancoilote Is Here : cette version corrige notamment le problème de méthode de génération de certificat de Let’s Encrypt (voir plus bas). En plus de celà, cette version apporte notamment une gestion dynamique des certificats par frontend/backend et de la qualité de service avec la possibilité de définir des limites de consommation de ressources.
  • Container Structure Tests: Unit Tests for Docker Images : Google vient de sortir son framework de tests unitaires pour les containers Docker. A creuser pour voir s’il n’est possible de faire que de tests de “surface” ou bien si on peut aller plus en profondeur (mais est-ce souhaitable ?)
  • CoreOS to join Red Hat to deliver automated operations to all : CoreOS rejoint la galaxie RedHat qui fait son retour dans le monde des conteneurs… après Openshift (qui s’appuie sur Docker + Kubernetes), voilà qu’ils mettent la main sur CoreOS + Tectonic (la version de Kubernetes packagée par CoreOS), ainsi que les autres projets CoreOS (etcd, etc). Ils vont pouvoir proposer un sacré vertical et revenir dans la cour des acteurs majeurs du conteneur ; sans parler du fait qu’ils ont aussi Ansible pour la partie automatisation…

Infrastructure

  • Le Bastion SSH : Petite revue théorique et pratique d’un bastion SSH, la passerelle SSH qui vous permet d’accéder depuis un réseau X à des machines d’un réseau Y en SSH dans exposer tout le réseau Y en libre accès ou parce que le réseau Y n’a pas d’IP publique ou … Si vous prévoyer de déployer un bastion, prévoyez d’en avoir deux pour éviter le SPOF (ou qu’il soit redéployable très rapidement).
  • PHP et les résolveurs DNS : à l’heure des micro-services et des API, une mauvaise couche réseau et votre application peut très mal se comporter. L’article porte ici sur la résolution DNS et les solutions de cache possible pour que votre application soit plus résiliente.

(No)SQL

  • Moving from MySQL to MariaDB in Debian 9 : je me demandais pourquoi je perdais mon accès au compte root d’une instance MariaDB suite à un mysql_secure_installation, voici enfin la réponse. Sur les nouvelles installations, l’accès au compte root de mariadb est protégé. Il faut passer par sudo mysql -u root -p ... par ex pour pouvoir se connecter en root.
  • How to Install MariaDB on Debian 9 Stretch : l’article qui m’a mis sur la piste et qui donne éventuellement une solution de contournement pour reproduire l’ancien mécanisme (à vos risques et périls).
  • An update on Redis Streams development : les Streams dans Redis, ce sera pour la version 5.0 prévue pour dans 2 mois. Pour rappel, les Streams, ce sont des listes Redis + PubSub + historique. C’est une réponse de Redis sur la partie Topic/Message de Kafka.

Certificats

  • Let’s Encrypt a annoncé le 10 janvier avoir identifié une “faille” lors de la génération du certificat lié à l’utilisation de Let’s Encrypt dans un environnement mutualisé via la méthode TLS-SNI. Avec le partage d’une même IP, il serait possible pour une personne malveillante de récupérer un certificat pour votre domaine à votre insu. Let’s Encrypt a finalement décidé de désactiver complètement les méthodes TLS-SNI-001 et TLS-SNI-002 et de travailler sur une nouvelle méthode TLS-SNI-003 qui corrigerait ce problème. En attendant, il faut utiliser les méthodes HTTP-01 ou DNS-01.

Astuce(s) du mois

La commande docker history (ou docker image history) permet de voir le nombre de layers d’une image, la taille de ces layers et leur âge. Exemple avec l’image nginx:stable :

docker image history nginx:stable
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
dfe062ee1dc8        6 weeks ago         /bin/sh -c #(nop)  CMD ["nginx" "-g" "daemon…   0B
<missing>           6 weeks ago         /bin/sh -c #(nop)  STOPSIGNAL [SIGTERM]         0B
<missing>           6 weeks ago         /bin/sh -c #(nop)  EXPOSE 80/tcp                0B
<missing>           6 weeks ago         /bin/sh -c ln -sf /dev/stdout /var/log/nginx…   22B
<missing>           6 weeks ago         /bin/sh -c set -x  && apt-get update  && apt…   53.1MB
<missing>           6 weeks ago         /bin/sh -c #(nop)  ENV NJS_VERSION=1.12.2.0.…   0B
<missing>           6 weeks ago         /bin/sh -c #(nop)  ENV NGINX_VERSION=1.12.2-…   0B
<missing>           6 weeks ago         /bin/sh -c #(nop)  LABEL maintainer=NGINX Do…   0B
<missing>           6 weeks ago         /bin/sh -c #(nop)  CMD ["bash"]                 0B
<missing>           6 weeks ago         /bin/sh -c #(nop) ADD file:f30a8b5b7cdc9ba33…   55.3MB

Pour avoir l’intégralité du contenu de la ligne “CREATED BY”, il suffit de rajouter un --no-trunc.

Source : Docker - history

C’est assez pratique lorsque l’on cherche notamment à comprendre et optimiser la taille de ses images Docker.

Systemd timer pour les Cro(o)ners

cron crontab systemd timer unit

Cron et Crontab sont dans un bateau…

Il fut un temps où pour programmer le lancement des actions, notre meilleur ami était “cron” et la “crontab”. Outre la syntaxe et l’organisation de la crontab peu mémorisable, les tâches cron restaient complexes à déployer et à monitorer dans leur exécution. Si le fait d’avoir des répertoires plus génériques comme /etc/cron.{d,hourly,daily,weekly,monthly} ont un peu amélioré la partie exploitabilité/déployabilité, ils offraient assez peu de souplesses pour une plannification fine des tâches. De nombreux serveurs ont donc eu un mix de crontab classique et de ce format pendant des années.

Debian 9.0 (mais d’autres aussi comme Archlinux par ex) a fait le choix dans le cadre de son adoption de systemd de ne plus proposer un logiciel de type cron mais de s’appuyer sur l’implémentation interne à systemd, à savoir les “timers”. C’est une unité (unit) spéciale de systemd qui est controllée et supervisée par systemd et qui s’exécute selon une configuration temporelle donnée.

Voyons comment passer de cette crontab :

0 4 * * * /path/to/scripts/backup.sh >> /var/log/backup.log 2>&1

… ou de /etc/cron.daily/mybackup.sh appelant le même script à son équivalent sous un timer systemd.

Implémentation d’un timer systemd.

Si vous gérez déjà vos services via systemd, vous avez déjà utilisé des “unit” systemd de type “service”. Ces “unit” permettent de définir un process et son mode d’éxécution.

Pour implémenter un “timer” sous systemd, il va nous falloir un fichier “service”.

Pour notre tâche à planifier, nous allons avoir au final 3 fichiers :

  • Le script à exécuter ; c’est votre script /path/to/scripts/backup.sh ; il est inchangé par rapport à précédemment.
  • Le fichier “service” qui va dire quel script exécuter
  • Le fichier “timer” qui va indiquer quand il doit être exécuté.

A noter que par convention, les fichiers service et timer doivent avoir le même nom (foo.service, foo.timer).

Pour le fichier service, une base simple est la suivante :

/etc/systemd/system/mybackup.service :

[Unit]
Description=My Daily Backup

[Service]
Type=simple
ExecStart=/path/to/scripts/backup.sh
StandardError=journal

Je fournis une description à mon service, indique que c’est un process de type simple, le chemin vers mon script et je rajoute que le flux d’erreur est envoyé dans le journal. Pour plus d’information, se reporter à la doc des services et des exécutions.

Attention néanmoins, il ne faut pas de section [Install] car le script va être piloté par le fichier timer.

Ensuite, il nous faut un fichier “timer” :

/etc/systemd/system/mybackup.timer :

[Unit]
Description=My Daily Backup

[Timer]
# Define a calendar event (see `man systemd.time`)
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Au-delà de la description, les lignes importantes sont la section [Timer] et [Install] :

  • OnCalendar permet d’indiquer l’occurrence et la fréquence d’exécution du script. Il y a les abréviations classiques (daily, weekly, etc) mais vous pouvez avoir des choses plus complexes comme "Mon,Tue *-*-01..04 12:00:00" - voir systemd.time
  • Persistent va forcer l’exécution du script si la dernière exécution a été manquée suite à un reboot de serveur ou autre événement.
  • Enfin, la section Install va créer la dépendance pour que votre “timer” soit bien exécuté et pris en compte par systemd.

Il ne reste plus qu’à activer le timer et le démarrer :

systemctl enable mybackup.timer
systemctl start mybackup.timer

Gestion et suivi d’un timer

Pour voir la liste des “timers” actifs sur votre serveur, la date de leur dernière et prochaine exécution :

systemctl list-timers
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Mon 2018-01-29 17:25:59 CET  2h 27min left Sun 2018-01-28 22:20:35 CET  16h ago      apt-daily.timer              apt-daily.service
Tue 2018-01-30 06:36:33 CET  15h left      Mon 2018-01-29 06:37:35 CET  8h ago       apt-daily-upgrade.timer      apt-daily-upgrade.service
Tue 2018-01-30 09:25:48 CET  18h left      Mon 2018-01-29 09:25:48 CET  5h 33min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

et accéder aux logs de vos “timers” :

journalctl -f -u apt-daily
-- Logs begin at Tue 2018-01-23 13:50:12 CET. --
Jan 28 22:20:35 codb2d9 systemd[1]: Starting Daily apt download activities...
Jan 28 22:20:35 codb2d9 systemd[1]: Started Daily apt download activities.

En cas de modification du .timer ou du .service, ne pas oublier de faire un system daemon-reload pour que la version actualisée de vos fichiers soit prise en compte par systemd.

Passé la petite prise en main de ce nouveau cadre d’exécution, elle me semble plus simple et surtout plus facile à intégrer dans des chaines de déploiements pilotées par Ansible ou autre.

Bilan 2017 et perspectives 2018

bilan perspective cérénit

Rien de tel que la finalisation du bilan de cette première année d’activité pour faire un petit bilan sur l’année écoulée et les perspectives pour 2018.

Bilan 2017

Il est positif, tant d’un point de vue comptable que d’activité.

D’un point de vue comptable, cela donne :

  • cela donne 100 K€ de CA réalisé,
  • 20 K€ de résultat après impôts
  • et l’équivalent de 160 - 170 jours facturés.

C’est clairement un succès. En reprenant mes prévisions et hypothèses d’activité de début d’année dernière, je suis dans la fourchette haute.

D’un point de vue activité, c’est plus contrasté :

  • le permier semestre fut l’opportunité de travailler avec de petites structures et sur des projets intéressants. Mais l’effet élection présidentielle a aussi créé un certain attentisme, diminuant le nombre de sollicitations, mettant fin plus tôt que prévu à certains projets et rendant l’appel de charges de Juillet un peu stressant.
  • Une mission à compter de mi-juin a permis de stabiliser la situation et de se remettre à flot.
  • Une propsition pour rejoindre une autre structure en cours de création en fin d’année a permis de se poser pas mal de questions sur mes aspirations et sur ma façon de travailler.

Un autre objectif que je m’étais donné en démarrant cette aventure était de contribuer en retour aux communautés Open Source. Profitant de l’écosystème open source, il est de notre devoir d’entreprise de contribuer à cet écosystème. Ce fut chose faite avec le sponsoring (modeste) des Rencontres Django à Toulon et ma partipation à l’édition 2017 de Codeurs En Seine où j’ai pu parler de la plateforme TICK et de Grafana.

Au final, une année riche en enseignements à de multiples niveaux (personnel, professionel, gestion d’une entreprise, etc)

Perspectives 2018

2018 commence bien avec une première mission intéressante et des sujets en cours de réflexion. Voici quelques objectifs que je me suis fixé :

  • Rester indépendant et développer CérénIT. Si l’année dernière, la question de rejoindre d’autres structures en tant que salarié s’est posée plusieurs fois, elle ne se pose plus. Seule celle de rejoindre une autre structure en tant qu’associé peut subsister sous réserve de certains critères.
  • D’un point de vue positionnement, se limiter à deux grandes activités. D’une part l’architecture et la direction technnique. D’autre part, l’automatisation et l’industrialisation dans une perspective de mise en place de pratiques DevOps/SRE.
  • Réflexion autour d’une logique de mentorat, d’accompagnement et de partage de connaissances avec des projets idéalement portés par des femmes pour favoriser la diversité dans notre milieu.

Pour atteindre ces objectifs, il y a quelques pistes :

  • Ne pas travailler 5/5j pour pouvoir dégager un peu de temps pour me former à différentes technologies ou pouvoir faire autre chose (mentorat & co ?). Si d’un point de vue facturation, cela peut paraitre contre-productif, c’est investir sur l’avenir pour obtenir de nouvelles missions, pouvoir augmenter progressivement mon TJM ou simplement avoir la satisfaction de contribuer à d’autres projets.
  • Continuer à contribuer en retour aux communautés open source
  • Continuer à postuler à des conférences (DevoxxFR, BreizhCamp, etc)
  • Continuer à aller à des conférences (Paris Serverless Conf, etc)
  • (Re)prendre contact avec des initiatives comme Led by Her, Start Her ou d’autres projets favorisant la diversité dans la tech.

Si certains sujets vous interpellent ou si vous avez des contacts à me suggérer, n’hésitez pas à me contacter.

Comme il est encore temps, j’en profite pour vous souhaiter à tou(te)s une bonne année 2018 et au plaisir de vous rencontrer, voire de collaborer ensemble.

Web, Ops & Data - Décembre 2017

accessibilité ansible spinnaker aws reinvent lambda serverless kubernetes s3 glacier sql ec2 gdpr kafka elasticsearch confluent postgres telegraf

Accessibilité

  • L’accessibilité n’est pas un luxe : un bon billet de rappel sur la nécessité et la relative facilité d’appliquer les bonnes pratiques d’accessibilité, y compris en utilisant les derniers frameworks à la mode.

Automatisation

AWS:ReInvent 2017

Cloud

  • EC2Instances.info Easy Amazon EC2 Instance Comparison (code source : un site permettant de comparer (plus) facilement les types d’instances EC2 chez AWS.
  • AWS GDPR Center : AWS met à disposition des ressources pour voir comment ils répondent aux objectifs de la GDPR qui s’applique à compter de Mai prochain et en quoi les plateformes cloud contribuent ou pas à ces efforts. Google Cloud a aussi son centre, tout comme Azure.
  • Servers.LOL : devriez-vous instancier une vm EC2 ou bien utiliser AWS Lambda ? Ce petit configurateur vous aide à prendre la “bonne” décision.

Elasticsearch

  • Elastic Stack 6.0 Upgrade Guide : un petit assistant mis à disposition par Elastic pour vous accompagner dans la migration vers Elastic 6.0 pour l’ensemble des composants.
  • Docker Performance Monitoring with Metricbeat and ELK Stack : Tutoriel indiquant comment remonter des métriques Docker (container, réseau, healthcheck, etc) via Metricbeat et leur ingestion dans Elasticsearch puis visualisation dans Kibana.
  • Elastic Stack 6.1.0 Released : le module d’APM a sa propre UI, Beats apprend à faire de l’autodiscovery sur docker en plus de voir la liste de modules s’enrichir, Kibana améliore toujours sa visualisation, etc.

Kafka

  • Introducing Confluent Platform 4.0 : nouvelle version majeure de cette plateforme autour de Kafka 1.0 et la consolidation des autres outils autour (Control Center, Kafka Streams, Connecteurs Kafka, etc)
  • Enabling Exactly-Once in Kafka Streams : le billet présente comment se gère le “exactly once message” dans un contexte Kafka Streams.
  • Kafkapocalypse: Monitoring Kafka Without Losing Your Mind : l’équipe de New Relic a transcrit un talk réalisé lors d’une conférence sur un incident majeur qu’ils ont eu avec Kafka et les points de vigilance qu’ils ont développé pour monitorer au mieux leur infrastructure kafka. Ils surveillent les notions de rétention (temps ET espace), la réplication et le retard des consommateurs (“consumer lag”). Si Kafka est une solution très intéressante, son monitoring reste une bête noire pour moi. La nécessité de passer par Confluent Platform et son Control Center semble être une nécessité pour le faire dans de bonnes conditions (ou de devoir monter ses propres dashboards).

(No)SQL

Serverless

TICK

Il ne me reste plus qu’à vous souhaiter de bonnes fêtes de fin d’année et à vous retrouver l’année prochaine pour de nouvelles aventures.

Web, Ops & Data - Novembre 2017

spark grafana tick cloud-init elasticsearch elk graphql kafka postgres influxdb prometheus codeurs en seine

Big Data

  • Compte rendu du Spark Summit 2017 (Dublin) : La conférence européenne annulle de l’éditeur de Spark, Databricks, a cherché à montrer que le Streaming et le Deep Learning sont/seront bientôt plus accessibles via Spark et également la plateforme cloud DataBricks.

Dataviz

  • Grafana 4.6 Released : Nouvelle version de l’outil de visualisation des bases de données time series mais pas uniquement avec l’ajout de la source Postgres, du support de l’alerting pour Amazon Cloudwatch, des annotations simplifiées sur les graphs et autres améliorations sur la base prometheus.
  • Wizzy : il s’agit d’un ensemble de script pour versionner et se simplifier la gestion de ses dashboards réalisés sous Grafana. Pas encore testé, sous peu !

Cloud

  • Bootstrapping a Cloud with Cloud-Init and HypriotOS : j’avais croisé Cloud-Init dans Rancher OS mais n’avais pas eu le temps d’investiguer le sujet. Récemment, un podcast avec son créateur m’a permis d’en savoir plus sur le projet, à savoir que c’est un ensemble de script python qui permettent de configurer une machine lors de son initialisation (boot). Cet article permet du coup d’en avoir un exemple pratique par la configuration d’une image pour un Raspberry Pi 3 installant automatiquement le logiciel NextCloud sous la forme d’un container Docker.

Elasticsearch

  • An Ansible role to Manage your Elasticsearch Clusters : Synthesio publie son playbook ansible pour gérer des clusters Elasticsearch ; vu les clusters gérés, il y a surement de bonnes choses à récupérer - la limite étant peut être que pour un cluster de débutant, cela pourrait être trop complexe au regard du besoin. A évaluer suivant votre contexte.
  • Operating Large Elasticsearch Clusters : un retour d’expérience de l’équipe Synthesio sur la bonne gestion de leurs clusters ElasticSearch lors des Sysadmindays il y a peu.
  • La Stack ELK passe en 6.0 :
    • Elasticsearch 6.0.0 GA released : mise à jour sans downtime, index filtré, meilleures performances, meilleure résilience et meilleure sécurité (mot de passe, usage de TLS).
    • Logstash 6.0.0 GA released : il est désormais possible d’avoir des pipelines dont l’exécution se fait en parallèle et via X-Pack, il y a maintenant une UI pour piloter vos pipelines.
    • Kibana 6.0.0 GA released : Plein d’améliorations au programme : Export CSV, Amélioration de l’UI, Mode lecture seule pour pouvoir partager des dashboards et d’autres nouveautés spécifiques à X-Pack.
    • Beats 6.0.0 GA released : capture des données Docker/Kubernetes, auditbeat pour captuer les données d’auditd, une meilleure gestion des modules et de leur configuration, amélioration de performance et du stockage des données.
  • Devez-vous migrer vers Elasticsearch 6 : l’équipe Jolicode passe en revue les avancées de la version 6 et globalement conseille de passer vers cette version 6.

GraphQL

  • Modernisez vos API, passez à GraphQL ! (slides et vidéo) : Une introduction à GraphQL présentée à Codeurs en Seine 2017. Je reste toujours sceptique sur GraphQL, si coté client cela semble magique, personne ne montre la partie backend pour que la “magie” opère.
  • The GraphQL stack: How everything fits together : état des lieux suite à GraphQL Summit 2017 sur les parties cache, tracing (suivi d’une requête de bout en bout du système) et composabilité d’API (une requête GraphQL qui intérogge plusieurs API au lieu d’une).

Kafka

  • Apache Kafka Goes 1.0 : cette version 1.0 représente plutôt la complétude à l’égard d’une vision de ce que devait être Kafka que de sa stabilité ou de sa capacité à être utilisé en production. Le billet énoncce les derniers apports mais reviens surtout sur tout cette génése et la vision associée au produit.

(No)SQL

Time Series

select(db:"foo")
 .where(exp:{"_measurement"=="cpu" AND 
             "_field"=="usage_system" AND 
             "service"=="app-server"})
 .range(start:-12h)
 .window(every:10m)
 .max()
19 20 21 22 23