Dns on bersace.cae.li

.docker (bis)

Thu, 25 Sep 2025 09:00:00 +0200

En 2018, je partageais ici une configuration pour résoudre en DNS vos conteneurs sous le domaine local .docker. Depuis, la technologie et mes usages ont évolués. Voici une petite mise-à-jour !

resolved vs dnsmasq

La solution était basé sur dnsmasq, or, depuis systemd 258, le service resolved permet de déléguer la résolution DNS d’une zone à un serveur spécifique.

L’intérêt ? La simplicité d’administration et la performance. dnsmasq est aussi un serveur DHCP, un cache DNS. Ce n’est pas utile pour ce besoin.

.virt

Tue, 09 Oct 2018 09:00:00 +0200

Printemps dernier, j’avais exposé la configuration système pour résoudre ses conteneurs sous le domaine .docker. C’est pratique, et on voudrait bien ça pour ses conteneurs LXC et ses VM !

L’astuce à la base de la configuration, c’est que dnsmasq sait résoudre les machines auxquelles il distribue une IP. C’est un vrai couteau suisse ! Il suffit de donner un domaine à dnsmasq et de configurer le hostname des conteneurs ou des VM. Cet article détaille les étapes pour mettre ça en place.

.docker

Fri, 27 Apr 2018 09:00:00 +0200

Isoler l’environnement de développement apporte deux avantages critiques : jeter et recréer l’environnement sans toucher à sa station de developpement ; lancer plusieurs environnement de developpement / test en parallèle.

Docker Compose est ma technologie d’isolation d’env de dév préférée. J’entends l’arrivée de Kubernetes. Pour 2018, je reste sur Docker Compose en natif sur ma station.

Docker Compose est bien plus efficace que Vagrant. La configuration YAML est simple, bien plus que pour Kubernetes. Les performances sont meilleures. L’immutabilité rends les environnements réellement jetables. Monter le code édité directement dans le conteneur, c’est parfait. Malgré les efforts d’HashiCorp, connaître Vagrant ne sert pas beaucoup en production. Tandis que connaître les contraintes de Docker est un vrai plus.

Configurer la résolution DNS dans Docker

Thu, 22 Mar 2018 17:00:00 +0200

Dans l’article précédent sur l’aiguillage DNS nous avons demandé la résolution DNS au serveur dnsmasq écoutant sur 127.0.0.1.

Problème, les conteneurs Docker ont basculé sur le serveur DNS 8.8.8.8 au lieu d’utiliser la résolution DNS du réseau interne. Les conteneurs envoient leurs requêtes DNS à Google. Pourquoi ??

Lorsque le moteur Docker cherche un serveur DNS pour ses conteneurs, impossible d’utiliser l’adresse 127.0.0.1 puisque les conteneurs sont dans un réseau isolé. L’adresse 127.0.0.1 est ignorée. Le moteur Docker ne trouvant pas de serveur résolvable, il bascule sur Google DNS.

Aiguillage DNS

Sat, 03 Feb 2018 09:00:00 +0200

Pour notre travail connecté, une bonne configuration réseau est importante. La mobilité croissante nous rends plus sensibles aux bricolages qui ne marchent qu’une fois. Un point particulier est la résolution des noms de domaines.

C’est courant d’avoir un domaine privé pour nommer les services internes d’une entreprise, pourr ceux qui ne sont pas dans le cloud. On se contente souvent d’utiliser le serveur DNS fourni par l’entreprise pour toutes les requêtes DNS : web publique et services internes. Ça devient lourd quand on est en VPN et qu’on dépends de la qualité du VPN pour résoudre un simple gitlab.com. Et comment gérer d’autres domaines comme .docker ou .lxc ?