Per què els contenidors de Docker ignoren el resolutor DNS de la VPN

La VPN està activa, el navegador arriba als llocs interns, i el contenidor encara no pot resoldre els mateixos noms. Una instal·lació de paquet mor amb un error de resolució de noms com EAI_AGAIN, o una aplicació no troba un amfitrió de base de dades que la màquina amfitriona resol sense cap queixa. El contenidor no utilitza el resolutor que la VPN ha instal·lat. Docker va copiar la configuració del resolutor de l’amfitrió quan es va crear el contenidor, i res no la va tornar a copiar després.

Dues visions del resolutor en una mateixa màquina

A Linux, Docker dóna a cada contenidor una còpia de la configuració del resolutor de l’amfitrió en el moment de crear-lo, filtra les adreces de loopback i executa un servidor DNS incrustat a 127.0.0.11 que reenvia les consultes cap a fora. Un client de VPN que reescrigui /etc/resolv.conf després que el contenidor s’hagi iniciat no canvia res dins seu. Reiniciar el contenidor només ajuda si el resolutor de l’amfitrió és correcte en aquell moment per casualitat.

Docker Desktop a macOS o Windows afegeix una capa, perquè el dimoni viu en una màquina virtual. Pot ser que el resolutor de la VPN de l’amfitrió no sigui mai visible per a aquesta VM, així que reiniciar no canvia absolutament res. Compareu les dues visions abans de triar una solució: docker exec mycontainer cat /etc/resolv.conf al costat de la llista de resolutors de l’amfitrió.

Un contenidor que llista un resolutor públic mentre l’amfitrió en llista un d’intern resoldrà els noms públics i fallarà amb els interns. Aquesta divisió és la signatura d’aquest problema.

Opció A: passar el resolutor del túnel per contenidor

Docker accepta paràmetres DNS per contenidor, que és el canvi més petit que funciona. Primer llegiu les adreces del resolutor de la VPN: scutil --dns a macOS, resolvectl status o la sortida d’estat del propi client a Linux. Després inicieu el contenidor amb elles, per exemple docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. A Compose el mateix paràmetre és una llista sota el servei, on viu al control de versions en lloc de l’historial de shell d’algú.

Una matriu dns a /etc/docker/daemon.json s’aplica a cada contenidor nou, cosa que sona més endreçada i no ho és. També s’aplica quan el túnel està caigut, i aleshores un resolutor accessible només a través de la VPN trenca les baixades d’imatges normals. Els paràmetres per contenidor són més fàcils de raonar i més fàcils de desfer.

Opció B: deixar que el contenidor comparteixi la xarxa de l’amfitrió

La xarxa de l’amfitrió evita la còpia del tot, perquè el contenidor utilitza el resolutor de l’amfitrió i el túnel de l’amfitrió. També elimina l’aïllament de xarxa que probablement volíeu, i no es comporta igual sota Docker Desktop. A Linux és l’opció pragmàtica per a una eina puntual que ha de resoldre noms interns.

Per a les compilacions no s’aplica cap de les dues opcions, ja que els passos de compilació no hereten els indicadors d’execució. Compileu amb la xarxa de l’amfitrió on la plataforma ho permeti, o manteniu la instal·lació de dependències en una etapa que no necessiti el túnel.

Què no arregla cap de les dues opcions

Una adreça DNS és inútil si el contenidor no hi té ruta. El resolutor de la VPN normalment se situa dins de l’espai d’adreces del túnel, així que el contenidor necessita un camí cap a aquest prefix. El pont per defecte de Docker normalment encamina cap a fora a través de l’amfitrió, cosa que n’hi ha prou quan l’amfitrió té la ruta del túnel i l’enviament està activat. Les xarxes pont personalitzades amb els seus propis rangs d’adreces poden xocar amb la subxarxa de la VPN, i aleshores les consultes van a un altre lloc del tot.

Comproveu la subxarxa de la xarxa de Docker contra la subxarxa de la VPN abans de depurar el resolutor mateix. La superposició produeix una fallada que sembla exactament un servidor DNS espatllat.

Verifiqueu dins del contenidor

Proveu amb getent hosts db.internal dins del contenidor en lloc d’un navegador o d’un entorn d’execució de llenguatge, perquè aquests apliquen la seva pròpia política DNS i la seva pròpia memòria cau. Si getent resol el nom i l’aplicació encara falla, el resolutor ara és correcte i el problema restant és a nivell d’aplicació. Si no el resol, el pas de DNS no està acabat.

Torneu a crear el contenidor després de canviar-ne els paràmetres DNS. Editar /etc/resolv.conf dins d’un contenidor en marxa desapareix amb ell i amaga el problema de configuració exactament durant el temps que algú triga a reiniciar-lo.