Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
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.
*.domaine.fr
). Si je m’étais réjoui de l’idée au début, je ne vois finalement pas ou peu l’intérêt du fait de la méthode de validation (enregistrement DNS avec le temps de propagation associé). En dehors du cas où l’on dépassait les limites d’enregistrement de Let’s Encrypt en terme de nombre de certificats, la génération dynmique et unitaire via une méthode HTTP me semble plus simple. Surtout quand on utilise Traefik ;-)J’utilise Ansible dans une logique d’IAC et pour automatiser un maximum des actions pour la gestion de l’infrastructure et des applications de mes clients. Toutefois, chaque client avait son arborescence et la réutilisation d’un composant d’un client à l’autre était fastidieuse (copier/coller).
Un premier travail a consisté à extraire les rôles commun dans un dépôt git tiers et faire des liens symboliques mais cela n’était pas très pratique. Suite à un travail chez un autre client, j’ai revu mon approche et je pars pour le moment sur la solution suivante :
<composant>.<client>
ou <client>.<composant>
(le choix n’est pas encore arrêté). Le second répertoire contenant les éléments spécifiques au client.Exemple avec un rôle MariaDB :
mariadb/
├── README.md
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
├── tasks
│ └── main.yml
├── templates
│ └── my.cnf.j2
└── vars
└── main.yml
co.mariadb/
├── README.md
├── handlers
│ └── main.yml
├── tasks
│ └── main.yml
├── templates
│ ├── my-primary.cnf.j2
│ └── my-replica.cnf.j2
Ainsi, la partie générique et la partie spécifique à mon client sont isolées. Il faut juste envisager le séquencement entre les deux rôles pour que cela se passe bien. Pour le moment, le seul code dupliqué se retrouve au niveau des handlers.
Si je devais donner accès à mes clients à leurs playbooks respectifs, il faudrait que je revois l’organisation pour ne leur donner accès qu’à leurs données. Il faudrait alors recréeer n dépots mais avec cette méthode, il est aussi facile de reconstruire a posteriori des dépots par clients depuis un dépot global. L’intérêt étant pour moi de conserver ma flexibilité et d’améliorer la réutilisabilité de mes composants.