Web, Ops & Data - Mai 2020


27/05/2020 docker ovh openstack fedora harbor registry traefik maesh percona mysql operator devops timescaledb grafana kubernetes terraform iac cert-manager devops raspberrypi

Le mois prochain, dans le cadre d'InfluxDays London, j’aurai le plaisir de présenter un talk sur le passage d’un monitoring Bare Metal vers un monitoring dans un monde Kubernetes avec Telegraf et InfluxDB.

Cloud

Container & orchestration

  • How To Install Docker On Fedora 32 Or 31 (And Alternatives) : Même si l’utilisation de podman est recommandée en lieu et place de docke-ce depuis Fedora 31, il peut être nécessaire de vouloir utiliser docker-ce sous Fedora. Avec Fedora 32, il faut en plus des cgroups v1 à activer, il y a une règle firewall à ajouter pour que vos conteneurs aient accès au réseau / à internet.
  • Harbor 2.0 : Version 2.0 de la registry Harbor qui permet d’héberger aussi des charts Helm. Pour la partie scan de vulnérabilités, le produit Clair de Quay a été remplacé par Aqua Trivy
  • Announcing Maesh 1.2 : la solution de Service Mesh de Containous basée sur Traefik sort en 1.2 ; elle se base sur Traefik 2.2 et apporte donc le support de l’UDP au niveau reverse proxy. Cette version permet aussi des améliorations au niveau ACL, gestion de la configuration et gestion des middlewares par service.
  • Introduction to Percona Kubernetes Operator for Percona XtraDB Cluster
  • Cert-manager v0.15 and beyond
  • CDK for Kubernetes : AWS vient de sortir un “Cloud Development Kit” permettant de manipuler et déployer des ressources kubernetes en python, typescript ou javascript.

DevOps

IoT

Time Series

Web, Ops & Data - Janvier 2020


29/01/2020 timeseries cloud ovh s3 object storage delta git diff faas containerd raspberrypi docker influxdb vscode flux warp10 observabilité docker cnab postgresql grafana

Meilleurs voeux à tous pour cette nouvelle année !

Cloud

  • OVHcloud Object Storage clusters support S3 API : pour ceux qui ne voulaient pas aller chez OVH car leur système de stockage objet est basé sur Openstack/Swift et ne voulaient pas modifier leurs appels d’API S3, une bonne nouvelle : le stockage objet d’OVH Cloud supporte l’API S3.

Container & Orchestration

  • Managing the TICK Stack with Docker App : cet article aurait pu être dans la section Time Series mais le focus étant sur Docker et Docker App, il sera dans la section Container. L’article montre comment déployer la stack TICK (Telegraf, InfluxDB, Chronograf et Kapacitor) tout d’abord via un fichier docker-compose.yml et ensuite il montre les apports de Docker App, qui permet d’avoir un niveau de personnalisation supplémentaire. Ainsi, on peut avoir un seul fichier docker-compose.yml de référence et auquel on rajoute un fichier avec des propriétés par environnement ou par client ou par instance par ex. Une combinaison intéressante pour améliorer l’industrialisation de vos containers.
  • Kubernetes 1.17 disponible sur l’offre kubernetes managé d’OVHCloud

DevOps/SRE

  • The 3 Myths of Observability : l’observabilité ne va pas directement baisser votre nombre d’incidents, l’observabilité n’est pas qu’une suite d’outils et elle n’est pas gratuite.

Outillage

  • delta : pour améliorer le rendu de vos diff et certaines commandes git (diff, show, log, stash, reflog). L’outil est réalisé en rust. Cela donne un rendu à la github/gitlab dans votre console. Sympa !

Raspberry Pi

  • faasd - lightweight Serverless for your Raspberry Pi : si vous jugez k3s encore trop gros pour vos raspberry pi pour faire tourner OpenFaaS ou que vous ne voulez pas déployer du kubernetes, vous pourriez trouver la solution du coté de faasd. Une implémentation du projet basée sur containerd (le runtime utilisée par Docker)
  • HypriotOS v1.12.0 : la distribution optimisée pour Raspberry Pi et fournissant Docker arrive en version 1.12. Elle permet d’utiliser Docker sur tous les modèles de Raspberry (0, 1, 2, 3, 4) avec les dernières versions de docker, docker-compose et docker-machine.

SQL

  • Améliorez votre SQL : utilisez des index filtrés : Postgresql permet de définir des index filtrés : plutôt que de créer un index sur toutes les données d’une table, vous pouvez définir un index qui répond à un filtre et ne faire un index que sur ce sous-ensemble de données.

Time Series

  • Grafana v6.6 Released : nouvelle version de Grafana avec comme d’habitude plein d’améliorations à tous les étages (data source, panels, alerting, explore, etc)
  • Release Announcement: Flux VSCode Support : InfluxData a publié une extension VSCode pour le langage flux.
  • InfluxDB 2.0 Open Source Beta Released : InfluxData passe la version OSS d’iInfluxDB 2.0 en béta après une année de versions alpha. On y trouve notamment une approche Configuration As Code avec la possibilité de définir des Tasks, Dashboards, ainsi que de la configuration via des Manifest en YAML et un système de packages. Flux, le nouveau langage de requêtage continue à s’améliorer et enfin le transpiler InfluxQL vers Flux fait son entrée mais demande à s’améliorer au fil du temps. La beta 2 est sortie aussi.
  • telegaf warp10 output : la prochaine version de Telegraf supportera nativement Warp10.
  • Erlenmeyer: Time Series query translator : OVHCloud vient d’opensourcer le code de leur proxy en go qui leur permet de parser des requêtes de différentes bases de données time series (OpenTSDB, PromQL, Prometheus Remote Read, InfluxQL et Graphite) en Warpscript pour requêter les données stockées dans Warp10. Pour rappel, la solution OVHMetrics est basée sur Warp10.
  • Le traitement et l’utilisation de la data dans l’industry 4.0 : SenX, la société éditrice de Warp10, a réalisé une vidéo intéressante sur le traitement et l’utilisation de la data dans l’industrie 4.0. On y voit notamment les 4 niveaux de maturité quant à la donnée et le rôle d’une base de données temporelles dans ce contexte. Un billet de blog (en anglais) est également disponible.

Kubernetes @ OVH - Traefik2 et Cert Manager pour le stockage des certificats en secrets


08/11/2019 kubernetes traefik ovh secrets cert-manager

Avec la sortie de Traefik 2, il était temps de mettre à jour le billet Kubernetes @ OVH - Traefik et Cert Manager pour le stockage des certificats en secrets pour tenir compte des modifications.

L’objectif est toujours de s’appuyer sur Cert-Manager pour la génération et le stockage des certificats Let’s Encrypt qui seront utilisés par Traefik. L’idée est de stocker ces certificats sous la forme d’un objet Certificate et de ne plus avoir à provisionner un volume pour les stocker. On peut dès lors avoir plusieurs instances de Traefik et non plus une seule à laquelle le volume serait attaché.

Installation de cert-manager :

# Install the CustomResourceDefinition resources separately
kubectl apply --validate=false -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.11/deploy/manifests/00-crds.yaml

# Create the namespace for cert-manager
kubectl create namespace cert-manager

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io

# Update your local Helm chart repository cache
helm repo update

# Install the cert-manager Helm chart
helm install \
  --name cert-manager \
  --namespace cert-manager \
  --version v0.11.0 \
  jetstack/cert-manager

Nous allons ensuite devoir créer un Issuer dans chaque namespace pour avoir un générateur de certificats propre à chaque namespace. Cela est notamment du au fait que Traefik s’attend à ce que le secret et l’ingress utilisant ce secret soient dans le même namespace. Nous spécifions également que nous utiliserons traefik comme ingress pour la génération des certificats.

cert-manager/issuer.yml:

apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: user@example.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod
    # Enable HTTP01 validations
    solvers:
    - selector: {}
      http01:
        ingress:
          class: traefik

Puis créons le “issuer” dans la/les namespace(s) voulu(s) :

# Create issuer in a given namespace
kubectl create -n <namespace> -f cert-manager/issuer.yml

Installons ensuite traefik V2

Créons le namespace traefik2 :

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

En premier lieu, Traefik V2 permet d’avoir un provider Kubernetes qui se base sur des Custom Ressources Definition (aka CRD).

Créeons le fichier traefik2/crd.yml :

---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressroutes.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRoute
    plural: ingressroutes
    singular: ingressroute
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: middlewares.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: Middleware
    plural: middlewares
    singular: middleware
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressroutetcps.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRouteTCP
    plural: ingressroutetcps
    singular: ingressroutetcp
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressrouteudps.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRouteUDP
    plural: ingressrouteudps
    singular: ingressrouteudp
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: tlsoptions.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TLSOption
    plural: tlsoptions
    singular: tlsoption
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: tlsstores.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TLSStore
    plural: tlsstores
    singular: tlsstore
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: traefikservices.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TraefikService
    plural: traefikservices
    singular: traefikservice
  scope: Namespaced

Vous pouvez retrouver les sources de ces CRD.

Continuons avec traefik2/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). Si vous venez d’une installation avec Traefik 1, ce n’est pas tout à fait la même définition des permissions.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik2-ingress-controller
  namespace: traefik2
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik2-ingress-controller
  namespace: traefik2
rules:
  - apiGroups:
      - ""
    resources:
      - services
      - endpoints
      - secrets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses/status
    verbs:
      - update
  - apiGroups:
      - traefik.containo.us
    resources:
      - middlewares
      - ingressroutes
      - traefikservices
      - ingressroutetcps
      - ingressrouteudps
      - tlsoptions
      - tlsstores
    verbs:
      - get
      - list
      - watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik2-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik2-ingress-controller
subjects:
- kind: ServiceAccount
  name: traefik2-ingress-controller
  namespace: traefik2

Nous pouvons alors songer à déployer Traefik V2 sous la forme d’un Deployment. Mais avant de produire le fichier, ce qu’il faut savoir ici :

  • lorsque cert-manager fait une demande de certificat, il crée un ressource de type Ingress. Dès lors, il faut activer les deux providers kubernetes disponibles avec Traefik V2 : KubernetesCRD et KubernetesIngress. Le premier provider permettra de profiter des nouveaux objets fournis par la CRD et le second permet que Traefik gère les Ingress traditionnelles de Kubernetes et notamment celles de cert-manager.
  • Contrairement à la version 1 de Traefik, le provider KubernetesIngress ne supporte pas les annotations
  • En activant le provider KubernetesIngress, on se simplifie aussi la migration d’un socle Traefik V1 vers V2, au support des annotations près.

traefik2/deployment.yml :

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: traefik2-ingress-controller
  labels:
    k8s-app: traefik2-ingress-lb
spec:
  replicas: 2
  selector:
    matchLabels:
      k8s-app: traefik2-ingress-lb
  template:
    metadata:
      labels:
        k8s-app: traefik2-ingress-lb
        name: traefik2-ingress-lb
    spec:
      serviceAccountName: traefik2-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:2.1.1
        name: traefik2-ingress-lb
        ports:
          - name: web
            containerPort: 80
          - name: admin
            containerPort: 8080
          - name: secure
            containerPort: 443
        readinessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 1
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        livenessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        args:
          - --entryPoints.web.address=:80
          - --entryPoints.secure.address=:443
          - --entryPoints.traefik.address=:8080
          - --api.dashboard=true
          - --api.insecure=true
          - --ping=true
          - --providers.kubernetescrd
          - --providers.kubernetesingress
          - --log.level=DEBUG

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

---
kind: Service
apiVersion: v1
metadata:
  name: traefik2-ingress-service-clusterip
spec:
  selector:
    k8s-app: traefik2-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: traefik2-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 traefik2/api-ingress.yml :

---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik2-web-ui
spec:
  entryPoints:
    - secure
  routes:
    - match: Host(`traefik2.k8s.cerenit.fr`)
      kind: Rule
      services:
        - name: traefik2-ingress-service-clusterip
          port: 8080
  tls:
    secretName: traefik2-cert
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik2-web-ui-http
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`traefik2.k8s.cerenit.fr`)
      kind: Rule
      services:
        - name: traefik2-ingress-service-clusterip
          port: 8080

L’idée est donc de rentre le dashboard accessible via l’url traefik2.k8s.cerenit.fr.

La section tls de l’ingress indique le nom d’hôte pour lequel le certificat va être disponible et le nom du secret contenant le certificat du site que nous n’avons pas encore créé.

Il nous faut donc créer ce certificat :

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: traefik2-cert
  namespace: traefik2
spec:
  secretName: traefik2-cert
  issuerRef:
    name: letsencrypt-prod
  commonName: traefik2.k8s.cerenit.fr
  dnsNames:
    - traefik2.k8s.cerenit.fr

Il ne reste plus qu’à faire pour instancier le tout :

kubectl apply -f traefik2/

Pour la génération du certificat, il conviendra de vérifier la sortie de

kubectl describe certificate traefik2-cert

A ce stade, il nous manque :

  • L’authentification au niveau accès
  • La redirection https

C’est là que les Middlewares rentrent en jeu.

Pour la redirection https: traefik2/middleware-redirect-https.yml

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: https-only
spec:
  redirectScheme:
    scheme: https

Pour l’authentification : traefik2/middleware-auth.yml

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: auth-traefik-webui
spec:
  basicAuth:
    secret: traefik-auth

Il faut alors créer un secret kubernetes qui contient une variable users contenant la/les ligne(s) d’authentification :

apiVersion: v1
kind: Secret
metadata:
  name: traefik-auth
  namespace: traefik2
data:
  users: |2
    dGVzdDokYXByMSRINnVza2trVyRJZ1hMUDZld1RyU3VCa1RycUU4d2ovCnRlc3QyOiRhcHIxJGQ5aHI5SEJCJDRIeHdnVWlyM0hQNEVzZ2dQL1FObzAK

Cela correspond à 2 comptes test/test et test2/test2, encodés en base64 et avec un mot de passe chiffré via htpasswd.

test:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/
test2:$apr1$d9hr9HBB$4HxwgUir3HP4EsggP/QNo0

On peut alors mettre à jour notre fichier traefik2/api-ingress.yml et rajouter les deux middlewares que nous venons de définir :

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik2-web-ui
spec:
  entryPoints:
    - secure
  routes:
    - match: Host(`traefik2.k8s.cerenit.fr`)
      middlewares:
        - name: auth-traefik-webui
      kind: Rule
      services:
        - name: traefik2-ingress-service-clusterip
          port: 8080
  tls:
    secretName: traefik2-cert
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik2-web-ui-http
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`traefik2.k8s.cerenit.fr`)
      middlewares:
        - name: https-only
      kind: Rule
      services:
        - name: traefik2-ingress-service-clusterip
          port: 8080

Et pour le prendre en compte:

kubectl apply -f traefik2/

Vous devez alors avoir une redirection automatique vers le endpoint en https et une mire d’authentification.

Pour ceux qui font une migration dans le même cluster de Traefik V1 vers Traefik V2 :

  • Si vous avez chaque instance Traefik avec son LoadBalancer et donc son IP dédiée, alors pour que les demandes de certificats ne soient pas interceptées par Traefik V1, il faudra personnaliser l'ingressClass de Traefik et créer un issuer cert-manager qui utilise cette même ingressClass.
  • Si vous utilisiez les annotations pour générer vos certificats, il vous faut passer par un object Certificate
  • Comme dit plus haut, en activant le provider kubernetesIngress, vous pouvez directement migrer sur un socle Traefik v2 puis migrer progressivement vos Ingress vers des IngressRoute. Pas besoin de faire une migration en mode big bang.

Sources utiles:

Paris Time Series Meetup - Edition 1


22/09/2019 timeseries warp10 ovh prescience machine-learning monitoring datacenter ptsm

Ce mercredi, j’ai le plaisir d’organiser la première édition du Paris Time Series Meetup - il reste des places, vous pouvez encore vous inscrire et nous rejoindre !

Ce meetup est organisé conjointement avec InfluxData suite à ma nomination en tant qu’InfluxAce lors d'InfluxDays London 2019. J’ai alors cherché à organiser le meetup en mettant en avant la communauté et les acteurs français autour de la série temporelle, de ne pas me limiter à des présentations produits mais de les enrichir avec des retours clients et aussi à proposer des usages plus avancés que de stocker ses données et de faire deux à trois graphiques avec ces métriques. Je pense que cette première édition respecte ces critères.

Au programme donc :

  • Time Series with Warp10 - Technology and Advanced Use Cases (because time series are way more than monitoring) par Mathias Herberts (CTO et Fondateur de SenX, la société éditrice de la plateforme opensource Warp10). Le talk sera en français et Mathias nous présentera Warp10 et différents cas d’usages autour de la platforme.

  • Pilotage du monitoring de datacenter grâce au Machine Learning par Christophe Rannou (OVH Machine Learning Services Team Leader) et Clément Bataille (OVH Machine Learning Services, Data Scientist) : Comment OVH utilise le Machine Learning appliqué au monitoring dans le but d’extraire des tendances et de détecter les anomalies afin de se prémunir d’incidents et de passer d’un entretien réactif a un entretien proactif. On y parlera notamment de leur offre Prescience mais pas uniquement !

Le meetup se fera dans les locaux de ManoMano qui nous font le plaisir de nous héberger.

Retrouvez toutes les informations sur la page de l’événement sur Meetup.

Web, Ops & Data - Aout 2019


31/08/2019 gitlab ci cd continous integration continous deployment git diff docker rpi traefik kubernetes ovh helm postgres percona aws partiql redis timeseries influxdb kafka prometheus

Surveillez le Time Series Paris Meetup, car la première édition du Meetup sera annoncée mardi avec une présentation des usages avancées des séries temporelles avec Warp10 (comprendre au-delà du monitoring classique) et une présentation par les équipes OVH sur du monitoring de datacenter aidé par du machine learning et leur offre Préscience.

CI/CD

  • How to trigger multiple pipelines using GitLab CI/CD : depuis une pipeline d’un dépôt gitlab, il va être possible d’appeler les pipelines des autres projets gitlab. Une fonctionnalité intéressante et qui pourrait lever la dépendance à Jenkins lorsque l’on a des pipelines un peu complexes et inter-projets.
  • New up and coming GitLab CI/CD Features : bilan et perspectives par le responsable produit de gitlab sur les fonctionnalités CI/CD qui ont été rajoutées cette année et celles à venir.

Code

Conteneurs & orchestration

SQL

time series

Web, Ops & Data - Février 2019


27/02/2019 kubernetes traefik postgres pandas python docker runc operator ansible vitess tidb sharding timeseries ovh kubedb fsync ovh dns

Container et orchestration

  • The Journey to Traefik Enterprise Edition: Product Evaluation
  • Docker Security Update: CVE-2019-5736 and Container Security Best Practices : Vous avez sans doute tous entendus parlé de la faille de runc, sous le doux nom de CVE-2019-5736. Le billet indique qu’il faut utiliser une version 18.06.2+ pour Docker CE et rappelle quelques bonnes pratiques de gestion de containers. Il n’y a pas que les serveurs à mettre à jour, il y a aussi les postes de développeurs, tout aussi exposés.
  • rancher/runc-cve : Pour les gens qui ne peuvent pas mettre à jour le binaire docker, l’équipe de Rancher met à disposition des versions du binaire runc pour les versions depuis docker 1.12.6 jusqu’à 18.06.1
  • CVE 2019-5736 dans runC : l’article indique une façon d’exploiter la faille de RunC.
  • Ansible Operator: What is it? Why it Matters? What can you do with it? : Ansible ne fournit pas un “oprator” en tant que tel pour Kubernetes mais de quoi permettre de créer un operator en se basant sur des playbooks/roles ansible. Ainsi, si votre ressource change d’état par exemple, alors le playbook associé est joué. Idem pour la gestion d’un upgrade, etc. Cela s’inscrit dans la logique de pouvoir développer ses propres Operator sans avoir à les écrire en Go.
  • Mastering the KUBECONFIG file : différentes astuces autour de la gestion du fichier KUBECONFIG.
  • KubeDB : KubeDB est un operator kubernetes qui vise à pouvoir déployer et gérer différentes bases sur un cluster kubernetes. Les bases supportées sont MySQL, Postgres, Elasticsearch, Redis, MongoDB et Memcached. Le niveau de fonctionnalités dépend beaucoup de la base de données retenus (la réplication semble être gérée pour Postgres mais pas pour MySQL par ex). La version 0.10 vient de sortir, apportant le support du cluster Redis
  • Managed Kubernetes Service : OVH vient de lancer son offre kubernetes managé et pour l’utiliser depuis deux mois maintenant, elle fonctionne plutôt bien.

DNS

(No)SQL

  • Contrainte d’exclusion : nous connaissons tous les contraintes d’unicité mais parfois cela ne suffit pas. L’exmple montre comment mettre en place une contrainte d’exclusion sur la base de filtre de plage de réseaux : 192.168.122.0/28 est compris dans 192.168.122.0/24, donc si le 2nd est entré dans la base, le 1er ne pourra jamais être ajouté car il y a recouvrement. On retrouve un autre exemple de cette contrainte d’exclusion sur des dates dans l’astuce de la semaine de l’édition 289 de Posrgres Weekly.
  • Understanding Database Sharding : un billet très explicite sur le partitionnement (sharding) de base de données, pourquoi et comment le faire. Il rappelle aussi les inconvénients à le faire et ce qu’il vaut mieux faire avant d’en arriver au sharding.
  • TiDB: Distributed NewSQL with Kevin Xu : TIDB est une base qui se déploie sur Kubernetes et qui s’appuie sur RocksDB. Elle se veut “NewSQL” dans le sens où elle veut supporter à la fois des transactions et de l’analytique. Elle veut offrir notamment un support de MySQL mais dans les faits, le support reste encore limité. Pour ceux qui veulemnt déployer du MySQL sur Kubernetes avec du sharding, il vaut mieux aller voir du coté de Vitess
  • Farewell to fsync(): 10× faster database tests with Docker : alors que l’actualité était plutôt sur le fait que Postgres gérait mieux les erreurs lors d’un fsync(), l’astuce consiste ici à désactiver fsync() et/ou à mettre le dossier des données de votre base en RAM pour accélérer les temps de déroiulement de tests. Testé chez un client, c’est un gain d’au moins 20s qui a été constaté sur une opération de quelques minutes (< 5).

Timeseries

  • Tutorial: Time Series Analysis with Pandas : un tutoriel assez progressif et didactique sur la manipulation de données temporelles avec Pandas.
  • TSL: a developer-friendly Time Series query language for all our metrics : L’équipe d’OVH Metrics a crée son propre langage de requêtage orienté séries temporelles pour Prometheus et Warp10. Le billet raconte leur épopée dans le monde des base de données temporelles et comment ils en sont arrivés à créer TSL. On retrouve une syntaxe fonctionnelle et qui se retrouve assez proche de celle de Flux, qui lui supporte InfluxDB et Prometheus.

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes traefik influxdb ansible elasticsearch grafana kafka postgres timeseries python aws sécurité redis terraform warp10 mysql tick cassandra cloud ovh helm rancher swarm telegraf test timescaledb chronograf docker-compose git résilience architecture confluent ksql log machine-learning microservice prometheus ptsm serverless spark angularjs api arm cert-manager cncf container dashboard devops flux gitlab graphql hashicorp iac java javascript monitoring opensource operator optimisation raspberrypi s3 service-mesh sql stream windows bilan csp cérénit dns documentation elastic gcp hpkp ingress jenkins kafka-streams kapacitor kibana kubedb lambda lean licence maesh maintenance microsoft mobile nginx npm orientdb perspective redhat rest rethinkdb reverse-proxy rook sauvegarde scaleway ssh vscode agile apm automatisation azure bash big-data ceph certificat ci/cd cli cluster containerd continous-delivery continous-integration cookie deployment diff fluxlang forecast framework gdpr gke grav hsts http/3 https hypriot hébergement influxace influxdata influxdays istio json k3s lets-encrypt linux load-balancer longhorn mariadb meetup molecule mongodb nosql openebs percona performance php pip pipeline postgresql reaper registry replication rpi rsyslog scale secrets société solr sre systemd timezone tls vault virtualenv vue.js wagtail yarn accessibilité acme akka alerte alibaba amazon-emr anonymisation anthos apache-pulsar ara arima audit bastion beam beat bigdatahebdo bounded-context branche brigade browser buildkit cahier-des-charges calico cassandra-reaper cd cdc cdk centralisation-de-logs certificats chart checklist chrome ci cilium cloud-init cloud-native cloud-storage clusterip cnab cni cockroachdb code codeurs-en-seine commit confluence conftest consul continous-deployment conventional-commit coreos cors covid19 cqrs crash cron crontab csi csrf css curl d3.js daemonset data-engineer data-pipelining data.gouv.fr datacenter dataviz date date-scientist ddd debezium debian delta deprek8 desktop devoxx distributed-systems dive docker-app docker-hub docker-registry docker-swarm documentdb dokcer données-personnelles draft drop-in déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering entreprise ergonomie etcd event-sourcing faas facebook faisabilité falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink flows fluentd formation foundation frontend fsync fullstack github gitignore gitlab-ci glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy harbor hdfs header html html5 http hue ia iaac ibm immutable incident index influxcloud infrastructure-as-code ingénierie inspec jq jquery jwt k3d k8s k9s kotlin kubeadm kubecon kubectl laravel letsencrypt linky liste-de-diffusion loadbalancer logstash logstatsh loi mailing-list management message metallb micro-service mot-de-passe multi-cloud médecine métrique network newsletter nodeport nomad null nvidia object-storage observabilité opa opendata openmetrics openshit openssh openstack openweb over-engineering packaging pandas partiql password persistent-volume-claim pipenv pod podman portainer portworx prediction prescience ptyhon publicité pubsub push pyenv quasardb quay questdb queue quic ram rambleed raml react recaptcha recherche redistimeseries reindex reinvent reliability responsive revocation revue-de-code rgpd rkt rolespec root rpo rto runc rwd safe-harbor scalabilité scanner schema sdk search select serverless-architecture service-account service-worker setuptools sha1 sharding shell shipyard sidecar souveraineté-numérique spinnaker spécifications sri ssh-agent ssl stash statistique storage superset suse sympa syslog-ng terracost terrascan test-unitaire tidb tiers timer training travail tsl ubuntu unikernel unit ux vendredi victoria-metrics vie-privée virtualbox virtualisation vitess vm vnc volume voxxeddays vpc warpscript warpstudio web yubikey

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)