monitor.stateChanges() et monitor.stateChangesOnly().Si vous êtes en manque de news, vous pouvez aller consulter (et vous abonner) aux brèves du BigData Hebdo
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.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.
Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)