CérénIT

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

Web, Ops & Data - Octobre 2020

kubernetes ingress yaml pipeline gitlab traefik rootless mesh yq jq devops data maturité mariadb s3 flows warp10 timeseries influxdb pulsar amqp mqtt kafka python git vscode arm nvidia

Des nouvelles du Paris Time Series Meetup : l’éditions 6 sur TimescaleDB et l’édition 7 sur QuestDB

CI/CD

  • 3 YAML tips for better pipelines : la troisième est certainement la plus intéressante - il est possible d’avoir des mécanismes de “composabilité” / “héritage” avec YAML et Gitlab. Si les include et extends sont déjà sympathiques, les anchors ont l’air de faire des choses intéressantes aussi !

Code

  • What’s New In Python 3.9 et un thread twitter qui donne des exemples des principales nouveautés : au programme nouvelle syntaxe pour la fuston des dictionnaires, des méthides pour supprimer des suffixes/préfixes sur les strings, du typage et plein d’autres améliorations et corrections.
  • Fortunately, I don’t squash my commits : s’il peut être tentant sur une MR/PR de faire un squash des commits, l’article vous confortera dans l’idée que ce n’est pas une bonne idée. En écrasant l’historique des commits, on y perd sur nos capacités de debug. Par ailleurs, il est conseillé de faire des petits commits pour capturer un ensemble de changements traduisant un moment précis du développement.

Container et orchestration

  • Kubernetes Ingress Goes GA : l’apparition de IngressClassName dans k8s 1.19 va plus loin qu’un simple renommage de champ comme je l’avais compris initialement. C’est une vraie ressource et cela ouvre aussi des possibilités. Avant de l’utiliser, vérifiez aussi que vos ingress controller le supporte (en plus d’attendre d’être en 1.19)
  • Houston, we have Plugins! Traefik 2.3 Announcement : la version 2.3 dont on a déjà parlé ici, est arrivé en version stable avec son support des plugins, son intégration avec Traefik Pilot, le support d’Amazone ECS et le support de la ressource IngressClassName. Au passage, Containous, la société éditrice de Traefik s’appelle maintenant Traefik Labs.
  • Introducing Traefik Pilot 1.0: the Traefik Control Center : Version 1.0 de ce nouveau “Control Plane” de Traefik qui permet d’avoir une vision globale sur ses instances traefik, d’utiliser les plugins et d’avoir un monitoring et des alertes autour de la disponibilité, des performances et de la sécurité.
  • Rootless mode : A voir si cela pourra être inclus dans la version 1.20 mais le rootless mode est clairement une tendance de fond dans kubernetes et les conteneurs en général. Si vous ne vous y êtes pas déjà mis, ne tardez pas !
  • Announcing Traefik Mesh 1.4 - New Name, New Features : nouvelle version du service mesh par Traefik Labs et qui s’appelle maintenant Traefik Mesh (et non uniquement Maesh). Le reste des améliorations semble porter sur le filtrage des headers et des paths.
  • yq : A command line tool that will help you handle your YAML resources better : vous voulez faire des opératoins sur des fichiers YAML sans faire un chart helm ou sortir kustomize, vous pouvez faire des choses minimalistes avec yq (le pendant yaml de jq).
  • Bridge to Kubernetes GA, “bridge to kubernetes” est une extension pour vscode permettant de connecter une application tournant en local avec d’autres applications situées dans un ckuster kubernetes et faciliter ainsi l’expérience des développeurs.

Culture DevOps

Data

Hardware

IaC

  • Announcing HashiCorp Terraform 0.14 Beta: la capacité à marquer des variables comme sensibles pour éviter que leur valeur soit visible dans les logs/diff/…, un diff plus concis, un lock sur les providers et des binaires disponibles pour arm64.

Monitoring

Pratique

  • endoflife.date : recense les dates de fin de support de vos langages et technologies préférées. Tout n’est pas complètement à jour mais cela permet de récupérer rapidement les informations.

SQL

  • Exciting and New Features in MariaDB 10.5 : évoqué au mois d’aout, le support de S3 dans MariaDB est disponible en version GA dans la version 10.5. D’autres améliorations existent comme le support du type INET6, des améliorations sur ColumnStore, la gestion des privilèges, le cluster Galera supporte complètement le GTID, du refactoring au niveau d’InnoDB et enfin les binaires mariadb vont enfin s’appeler mariadb et non plus mysql (avec une couche de compatibilité via des liens symboliques)

Time Series

Sur la base des informations disponibles pour le moment :

  • vous définissez une période de rétention en mémoire (entre 1h et 1 an) et une période de rétention sur stockage magnétique (1 jour à 200 ans),
  • le requêtage des données se fait en SQL (via Presto ?),
  • les données à requêter communément sont à mettre dans la même table,
  • le join est limité à la même table,
  • des mesures simples (pas de multi mesures pour un même enregistrement),
  • une intégration avec l’écosystème comme telegraf, grafana, etc en plus de l’intégration avec différents composants AWS

Pour les moins bons côtés :

  • pas d’UPDATE/DELETE sur vos données ; en cas de doublons, c’est le premier arrivé qui gagne
  • pas de bulk import de vos données, donc pas de reprise de vos données existantes. En effet, il n’est pas possible d’ingérer des données plus vieille que la période en mémoire,
  • dans la même veine, si un incident de production dépasse votre période de rétention, vous ne pourrez pas réinjecter vos données
  • il ne semble pas possible de mettre à jour ses durées de rétention - donc pas de ménage possible ou d’ajustements en cours de route

Une solution a priori très orienté pour du monitoring et qui semble souffir des mêmes travers qu’InfluxDB avec InfluxQL et pourtant en passe d’être résolus avec Flux.

On devrait en parler plus en détail dans une prochaine édition du Paris Time Series Meetup avec des personnes de chez AWS ;-)

Work

Web, Ops & Data - Mai 2019

kafka sécurité s3 aws vscode openebs rook kubedb nginx ingress grafana elasticsearch ansible timeseries timescaledb

Cloud

Container et Orchestration

  • Rook v1.0 — A Major Milestone : Rook atteint le stade de la version 1.0 avec une amélioration de l’opérateur Ceph (simplification de la configuration, gestion des mises à jour, prise en charge des dernières versions de Ceph, etc), le driver Ceph CSI passe en bêta, le support d’EdgeFS passe en bêta également, l’opérateur NFS supporte l’approvisionnement dynamique et l’opérateur Minio a reçu également des améliorations.
  • KubeDB 0.12 : cette version apporte principalement le support du sharding MongoDB et du Clustering MySQL et divers correctifs pour les autres “backends”.
  • Announcing NGINX Ingress Controller for Kubernetes Release 1.5.0 : nouvelle version de l’ingress nginx avec une nouvelle configuration, des métriques (via prometheus), simplification de la gestion des certificats, etc.
  • Grafana v6.2 Stable Release! : améliorations de sécurité sur le chiffrement des données des datasources, une nouvelle gauge et pleins d’autres améliorations.
  • OpenEBS Project Update and whats coming in v1.0 : la solution de stockage sous kubernetes vient de sortir en version 0.9 et de rejoindre la CNCF. C’est l’occasion de faire un point sur le projet et la route vers la version 1.0

(Big) Data

  • Kafka : Migrer un consommateur vers Streams et Connect : retour d’expérience intéressant sur la migration d’une intégration Kafka basée sur les producteurs/consommateurs vers une approche basée sur Kafka Connect et Kafka Streams.
  • Security for Elasticsearch is now free : ces fonctionnalités, prélablement disponibles uniquement dans la version commerciale, font partie de la version gratuite : chiffrement des flux via TLS, authentification et gestion des rôles.

IAC

  • Ansible 2.8 : de nombreuses améliorations au rendez-vous, la liste est très longue. Pour ma part, je note l’arrivée du support de “docker stack” pour gérer des déploiements sur un cluster docker swarm.

IDE

Sécurité

  • The inception bar: a new phishing method : sur mobile, dès lors que l’utilisateur fait défiler sa page, la barre de navigation va disparaitre et du coup il est possible d’injecter une fausse barre de navigation et faire croire à l’utilisateur qu’il est sur un autre site.

Time series

  • Zabbix, Time Series Data and TimescaleDB : le billet explique en quoi Zabbix doit faire face à l’enjeu des séries temporelles dans le cadre d’une solution de monitoring. Comme ils veulent avoir une technologie leur permettant d’utiliser SQL, ils ont fait le choix de TimescaleDB. Le point intéressant est en fin d’article lorsque les performances de Postgres 10 et TimescaleDB sont comparées.

Web, Ops & Data - Janvier 2019

machine-learning recaptcha flink alibaba cloud mongodb aws documentdb postgres test iac kubernetes ingress clusterip loadbalancer volume persistent volume claim nodeport logstash python pip virtualenv pipenv pyenv

Cloud

Container et orchestration

  • APIServer dry-run and kubectl diff : Un des soucis majeurs avec Kubernetes est l’écriture de fichiers YAML où la moindre faute peut s’insérer très rapidement et à l’insu de son auteur. Le billet présente les efforts fait pour ajouter un mode “dry run” qui simule les modifications et retourne l’objet qui aurait du être créé. Dans la même veine, un kubectl diff montrera les différences entre la ressource existante et celle décrite dans la nouvelle version du fichier yaml.
  • 9 Kubernetes Security Best Practices Everyone Must Follow : rien de transcendental mais une petite piqure de rappel après la faille majeure découverte en fin d’année.
  • Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what? : billet synthétique sur les avantages et inconvénients d’utiliser un service de type ClusterIP, NodePort, LoadBalancer ou Ingress. Sachant que l’on peut combiner LoadBalancer & Ingress !.
  • Why Is Storage On Kubernetes So Hard? : Les données, c’est tout sauf stateless et le stockage distribué c’est pas facile non plus. Le billet revient sur les logiques de stockages sous Kubernetes (PV, PVC), la couche d’interface de stockage CSI et sur des solutions comme Ceph ou Rook.
  • Stateful Kubernetes with Saad Ali - Software Engineering Daily : une présentation globale des Volumes, Persistent Volume, Persistent Volume Claims et des StorageClass sous Kubernetes et de l’évolution de la gestion du stockage sous k8s
  • Kubernetes Podcast - #36 Rook : une présentation de Rook, un opérateur k8s de gestion de stockage (Ceph, NFS, etc).

Data

IDE

Infrastructure (as Code)

  • Tester son code d’infrastructure avec Terratest : le billet présente terratest, un outil en go qui permet de tester du code Terraform, des templates Packer ou encore des images Docker. La conclusion montre qu’il n’est pas parfait certes mais peut être intéressant.
  • Infrastructure as (real) code : Faire de l’IaC, ce n’est pas que rédiger des fichiers YAML. Le billet montre comment on pourrait avoir de l’IaC avec du vrai code (du go en l’occurence). Avoir un vrai langage et un moteur de template semble en effet plus complet que juste du YAML pour lequel les validateurs sont assez faibles et la probabilité d’écrire une faute assez importante.
  • Reactive planning is a cloud native pattern : Le reactive planning tiendrait dans l’idée que pour une action donnée, il va y avoir un plan et que ce plan est constitué d’une multitude de petites étapes. Chaque étape informant la/les précédentes et voire globalement sur l’état de l’étape en cours et peut décider des étapes suivantes.

Langages

  • Why you should use pyenv + Pipenv for your Python projects : Une solution propre pour mieux gérer ses versions de python installées sur son poste / sur un serveur avec pyenv et pipenv (mix de pip et virtualenv) pour gérer les dépendances. A tester !
  • Pipenv: promises a lot, delivers very little : le billet nuance les propos autour de pipenv comme le nouveau gestionnaire officiel (autopromu) et fait le point sur l’outil.
  • shiv : Shiv permet de packager des applications python en une seule archive zip avec toutes les dépendances incluses. Disponible pour Windows / Linux / OSX, il faut néanmoins builder sur l’OS Cible pour que cela fonctionne - pas de “build one, run everywhere”.

Logs

(No)SQL

Kubernetes @ OVH - Traefik en Deployment et intégration des Load Balancers

kubernetes traefik ovh deployment load-balancer ingress

Pour faire suite au billet sur le déploiement de Traefik sous la forme d’un DaemonSet chez OVH, j’ai profité de la sortie en mode beta des Load Balancers pour revoir ma copie :

  • Déploiement de Traefik sous la forme d’un Deployment plutôt qu’un DaemonSet,
  • Intégration des Load Balancers,
  • Utilisation d’un namespace “traefik” plutôt que de tout mettre dans kube-system.

Par simplicité, je n’ai toujours qu’une node en plus du master fourni par OVH. Cela m’évite la problématique du stockage distribué des certificats. Cela fera l’objet d’un autre billet.

Créons le namespace traefik :

# Create namespace
kubectl create ns traefik
# Change context to this namespace so that all commands are by default run for this namespace
# see https://github.com/ahmetb/kubectx
kubens traefik

Commençons par traefik/rbac.yml - le fichier défini le compte de service (Service Account), le rôle au niveau du cluster (Cluster Role) et la liaison entre le rôle et le compte de service (Cluster Role Binding)

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik-ingress-controller
  namespace: traefik
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
rules:
  - apiGroups:
      - ""
    resources:
      - services
      - endpoints
      - secrets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-ingress-controller
subjects:
- kind: ServiceAccount
  name: traefik-ingress-controller
  namespace: traefik

Ensuite, pour Traefik, j’ai besoin d’un fichier traefik.toml avec la configuration que je mets à disposition sous la forme d’une ConfigMap dans un fichier traefik/traefik-toml-configmap.yml :

apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-conf
data:
  traefik.toml: |
    defaultEntryPoints = ["http", "https"]

    logLevel = "INFO"

    insecureSkipVerify = true

    [entryPoints]
      [entryPoints.http]
        address = ":80"
        [entryPoints.http.redirect]
          entryPoint = "https"
      [entryPoints.https]
        address = ":443"
        [entryPoints.https.tls]
      [entryPoints.api]
        address = ":8080"

    [acme]
    email = "contact@cerenit.fr"
    storage = "/acme/acme.json"
    entryPoint = "https"
    onHostRule = true
    [acme.httpChallenge]
      entryPoint = "http"

    [api]
    entryPoint = "api"
    dashboard = true
    debug = false

    [kubernetes]

Le dashboard est à protéger par une authentification pour éviter tout accès non souhaité. Je l’ai supprimé de la configuration par simplicité.

Ensuite, pour stocker mes certificats, il me faut un volume que je défini via le fichier traefik/traefik-certificates-pvc.yml :

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: traefik-certificates
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: cinder-classic

1 Go pour des certificats, c’est clairement trop mais il n’est pas possible pour le moment d’avoir un stockage plus réduit.

Je peux donc enfin déployer Traefik via le fichier traefik/traefik-deployment.yml :

---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: traefik-ingress-controller
  labels:
    k8s-app: traefik-ingress-lb
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: traefik-ingress-lb
  template:
    metadata:
      labels:
        k8s-app: traefik-ingress-lb
        name: traefik-ingress-lb
    spec:
      serviceAccountName: traefik-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:1.7.7
        name: traefik-ingress-lb
        volumeMounts:
        - mountPath: /config
          name: traefik-config
        - mountPath: /acme
          name: certificates
        ports:
        - name: http
          containerPort: 80
        - name: admin
          containerPort: 8080
        - name: secure
          containerPort: 443
        args:
        - --configfile=/config/traefik.toml
      volumes:
        - name: traefik-config
          configMap:
            name: traefik-conf
        - name: certificates
          persistentVolumeClaim:
            claimName: traefik-certificates

Nous déployons donc :

  • Traefik en Deployment
  • Les ports 80, 443 et 8080 sont définis
  • La configuration est une ConfigMap
  • Les certificats sont à déployer dans un volume

Pour permettre au cluster d’accéder aux différents ports, il faut définir un service via le fichier traefik-service-clusterip.yml :

---
kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service-clusterip
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 8080
      name: admin
    - protocol: TCP
      port: 443
      name: secure
  type: ClusterIP

Et pour avoir un accès de l’extérieur, il faut instancier un load-balancer via le fichier traefik/traefik-service-loadbalancer.yml

kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service-lb
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 443
      name: secure
  type: LoadBalancer

Pour donner l’accès au dashboard via une url sécurisée par un certificat Let’s Encrypt, il faut déclarer un Ingress, dans le fichier traefik/traefik-api-ingress.yml :

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: traefik-web-ui
spec:
  rules:
  - host: traefik.k8s.cerenit.fr
    http:
      paths:
      - path: /
        backend:
          serviceName: traefik-ingress-service
          servicePort: admin

Il ne nous reste plus qu’à faire :

# Create k8s ressources for traefik
kubectl create -f traefik/
# Watch service to get IPs
kubectl get svc -w

Une fois votre IP obtenue, il suffit de faire pointer votre entrée DNS vers cette IP ou de tester via :

curl -H "Host: traefik.k8s.cerenit.fr" https://xxx.xxx.xxx.xxx/

Pour l’obtention du certificat Let’s Encrypt, il faut que votre enregistrement DNS soit à jour préalablement. Sinon vous aurez un certificat autosigné par Traefik en attendant.

Dès lors, vous pouvez accéder au dashboard de Traefik via l’url définie. Pour donner accès à d’autres sites, il faut déclarer d’autres ingress sur le même modèle et le tour est joué.

Comparativement au dernier tutoriel :

  • Nous n’exposons plus le port 8080 au niveau de l’hôte,
  • Nous respectons plus les guidelines kubernetes à savoir de donner accès à une ressource via un service de type Load-Balancer ou NodePort
  • Nous utilisons une seule IP externe et nous appuyons sur les ingress pour mutualiser le load balancer et éviter d’avoir une IP publique par service à exposer
  • Nous ne sommes pas sur d’avoir un pod traefik par noeud mais nous gagnons en flexibilité - il faudra jouer avec les replicas dès qu’on ajoutera des nodes dans le cluster.

Il reste encore le problème des stockage des certificats à résoudre pour passer à un contexte multi-nodes. Ce sera l’objet d’un prochain billet avec idéalement l’intégration de Traefik avec cert-manager (plutôt que de devoir déployer une base clé/valeur comme etcd ou consul pour y stocker les infos de traefik).

N’hésitez pas à me faire part de vos retours.