Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
Cette édition et les précédentes sont également disponibles sur substack Web, Ops, IoT & Time Series pour ceux qui préfèrent les emails ou la consommation via l’app Substack
Rendez-vous à la fin du mois prochain pour une nouvelle édition.
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.
git checkout
par git switch
et git restore
pour mieux encadrer les usagesQuelques liens récupérés des différentes conférences auxquelles j’ai pu assister.
Et pour finir, mes propres slides sur la plateforme TICK & Grafana pour collecter et exploiter vos données temporelles. J’ai également eu l’opportunité de refaire cette conférence chez Les Furets (où je suis en mission actuellement). Je vais aussi la faire le 3 Mai prochain au NantesJUG.
Bonus : la vidéo est disponible
Docker, lorsqu’il exécute un container, injecte normalement les serveurs DNS de la machine hôte. Sauf que quand il voit que c’est une IP locale (127.0.0.*), alors il met les DNS de Google (8.8.8.8
et 8.8.4.4
) comme DNS. Typiqyement, Ubuntu utilise un résolveur DNS local via systemd-resolved pour la résolution DNS. Du coup, la configuration de /etc/resolv.conf
pointe sur 127.0.0.*
. Or sur un réseau local, les accès à un DNS public peuvent être filtrés. Dès lors, votre conteneur est incapable de faire une quelconque résolution DNS (interne ou externe à votre réseau).
La solution consiste à mettre en place un “drop-in” systemd
Source :
Nous voulons surcharger le fichier de type unit docker.service
et surcharger plus précisément la valeur de ExectStart
.
Etape 1 : Créer un répertoire /etc/systemd/system/docker.service.d
sudo mkdir -p /etc/systemd/system/docker.service.d
Etape 2 : Créer un fichier de configuration contenant la surcharge :
sudo $EDITOR /etc/systemd/system/docker.service.d/10-dns.conf
Contenu du fichier :
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --dns 192.168.2.1 --dns 192.168.2.2
Le “doublon” sur ExecStart
est normal, cela permet de réinitialiser la commande pour en définir un autre ensuite.
Il ne reste plus qu’à rechercher la configuration de systemd et relancer le service docker :
sudo systemctl daemon-reload
sudo systemctl restart docker
Docker utilisera donc ces DNS lors du lancement d’un conteneur et cela évitera qu’il fasse un fallback sur les DNS de Google quand il voit un resolver local…
Par contre, si vous utilisez docker dans un autre contexte que celui du réseau de votre entreprise, cela peut ne plus fonctionner (ou alors il faut enrichir la configuration DNS pour rajouter d’autres DNS)
Une autre solution peut être de renseigner les DNS dans /etc/docker/daemon.json
(documentation) avec les mêmes inconvénients.
Au-delà de cet exemple appliqué à Docker, l’utilisation des “drop-ins” systemd est une solution intéressante pour surcharger une configuration sans impacter les fichiers sources et évite tout conflit lors d’une mise à jour du fichier.