Accueil
Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
.internal
est en cours de discussion pour une décision en avril. On va pouvoir (enfin) sortir des domaines fictifs, des domaines publics utilisés en interne (adieu macompany.org
) ou encore du "DNS menteur" (macompany.com
résolu différemment suivant si on est en interne ou en externe). Néanmoins, une bonne question émerge : comment gérer et garantir les certificats en .internal
que tout le monde peut revendiquer ? Aucune entité de certification publique ne pourra émettre de tels certificats... Cela repose alors la question de la PKI privée et de la diffusion des certificats de la CA pour valider les domaines sur votre parc informatique...keepAliveMaxRequests
et keepAliveMaxTime
pour éviter que trop de connections ouvertes restent entre votre reverse proxy et votre applicatif.Après presque 2 ans de silence et le remplacement de Hugo et Bootstrap par Zola et Tailwind/daisyUI l'été dernier pour générer le site, je vous souhaite une bonne année à tous et la résolution de publier plus régulièrement mes trouvailles...
TL;DR: DuckDB can attach MySQL, Postgres, and SQLite databases in addition to databases stored in its own format. This allows data to be read into DuckDB and moved between these systems in a convenient manner.
J'avoue que la concision de Caddy vs Traefik et le provider file
est bien appréciable:
# Caddyfile
xxx.cerenit.fr {
reverse_proxy 127.0.0.1:3000
}
# Traefik
http:
middlewares:
redirectToHttps:
redirectScheme:
permanent: true
scheme: https
routers:
grafana:
entryPoints:
- websecure
- web
middlewares:
- redirectToHttps
rule: Host(`xxx.cerenit.fr`)
service: grafana@file
tls:
certResolver: le
services:
grafana:
loadBalancer:
servers:
- url: http://127.0.0.1:3000/
Pour un serveur, la migration de Traefik vers Caddy fait passer le fichier de configuration de 172 lignes à 27 - soit presque 6 fois moins ! 😏
Exemple:
services:
whoami:
image: traefik/whoami
networks:
- caddy
labels:
caddy: whoami.example.com
caddy.reverse_proxy: "{{upstreams 80}}"
networks:
caddy:
external: true
kubernetes_manifest
permet de définir ses propres manifests et donc permet d'utiliser des CRD non disponibles dans le provider officiel. Plus pratique que de générer les manifests via des templates et de faire du kubectl apply
par dessus.time_bucket_ng
qui permet de faire de nouvelles aggrégations et d'avoir prochainement un support des timezones. La seconde fonctionnalité expérimentale porte sur la capacité à bouger de la donnée entre plusieurs nodes en mode cluster.exec
.Des nouvelles du Paris Time Series Meetup : l'éditions 6 sur TimescaleDB et l'édition 7 sur QuestDB
include
et extends
sont déjà sympathiques, les anchors
ont l'air de faire des choses intéressantes aussi !Sur la base des informations disponibles pour le moment :
Pour les moins bons côtés :
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 ;-)
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.
depends_on
, count
et for_each
. Cela devrait éviter des dépendances parfois cryptiques.docker-compose.yml
) pour la rendre plus "cloud native" et plus générique avec une extension au provider cloud d'une part et d'autre part à des solutions comme kubernetes ou Amazone ECS par ex.DEV*
soient surprovisionnés et qu'il faille envisager des profils GP*
pour avoir des performances correctes. L'offre est du coup moins compétitive en termes de prix pour des petits clusters.jQuery.htmlFilter
pour toutes les versions inférieures à 3.5.0 ; il est vivement encouragé de mettre à jour vos sites. Pour le reste, je vous renvoie à la lecture de l'article.Rendez-vous le 21 janvier prochain à la troisième édition du Paris Time Series Meetup consacré à TSL (billet introductif à TSL : TSL: a developer-friendly Time Series query language for all our metrics) et le module RedisTimeSeries qui apporte des fonctionnalités et des structures Time Seriies à Redis. Le meetup était prévu initialement le mardi 17 décembre mais a été reporté du fait des grèves.
Je n'ai plus qu'à vous souhaiter des bonnes fêtes de fin d'année ; nous nous retrouvons l'année prochaine !
Traefik, depuis sa version V1, permet d'envoyer des métriques vers différents backends (StatsD, Prometheus, InfluxDB et Datadog). J'ai enfin pris le temps d'activer cette fonctionnalité et de creuser un peu le sujet étant donné que le dashboard de Traefik V2 n'affiche plus certaines de ses statistiques.
La documentation de Traefik sur le sujet :
Commençons par créer une base traefik
dans InfluxDB (version 1.7.8)
influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.9
> auth
username: XXX
password: XXX
> CREATE DATABASE traefik
> CREATE USER traefik WITH PASSWORD '<password>'
> GRANT ALL ON traefik to traefik
> SHOW GRANTS FOR traefik
database privilege
-------- ---------
traefik ALL PRIVILEGES
> quit
Dans mon cas, l'accès à InfluxDB se fait en https au travers d'une (autre) instance Traefik. J'utilise donc la connexion en http
plutôt qu'en udp
.
Cela donne les instructions suivantes en mode CLI :
--metrics=true
--metrics.influxdb=true
--metrics.influxdb.address=https://influxdb.domain.tld:443
--metrics.influxdb.protocol=http
--metrics.influxdb.database=traefik
--metrics.influxdb.username=traefik
--metrics.influxdb.password=<password>
J'ai gardé les valeurs par défaut pour addEntryPointsLabels
(true), addServicesLabels
(true) et pushInterval
(10s).
Cela donne le Deployment
suivant :
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.0.6
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=ERROR
- --metrics=true
- --metrics.influxdb=true
- --metrics.influxdb.address=https://influxdb.domain.tld:443
- --metrics.influxdb.protocol=http
- --metrics.influxdb.database=traefik
- --metrics.influxdb.username=traefik
- --metrics.influxdb.password=<password>
Appliquer le contenu du fichier dans votre cluster Kubernetes
kubectl apply -f deployment.yml -n <namespace>
Sur le dashboard Traefik, dans la section "Features", la boite "Metrics" doit afficher "InfluxDB", comme ci-dessous :
Vous pouvez alors vous connecter à votre instance InfluxDB pour valider que des données sont bien insérées :
influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.9
> auth
username: traefik
password:
> use traefik
Using database traefik
> show measurements
name: measurements
name
----
traefik.config.reload.lastSuccessTimestamp
traefik.config.reload.total
traefik.entrypoint.connections.open
traefik.entrypoint.request.duration
traefik.entrypoint.requests.total
traefik.service.connections.open
traefik.service.request.duration
traefik.service.requests.total
Il ne vous reste plus qu'à utiliser Chronograf ou Grafana pour visualiser vos données et définir des alertes.
Un exemple rapide avec la répartition des codes HTTP dans Grafana :