Docker

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

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