Dns

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. ...

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. ...

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. ...

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. ...

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 ? ...