Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
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.
python == python2
pour le motif de ne pas se tirer une balle dans le pied et qu’il y a alternatives --set python /usr/bin/python3
pour ça.Feature-Policy
indique au navigateur les fonctionnalités nécessaires pour le bon fonctionnement du site et désactiver les autres.runc
à terme, kaniko pourrait replacer docker build
. La registry docker étant aussi en passe de standardisation, on peut s’attendre à voir un nouveau produit arriver. Si Kubernetes (+ Google + CNCF + …) ont encore besoin de la liaison avec Docker d’un point de vue marketing, on a l’impression que cela cherche à s’éloigner des outils Docker Inc et dans une moindre mesure du projet Moby (qui lui même semble aussi avoir quelques distances avec Docker Inc). Certes, le docker engine de Docker Inc est basé sur containerd et donc Docker ne disparait pas de la plateforme mais ça semble bien en prendre le chemin.Quelques 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.