Proxy Docker distant

Un proxy Docker distant donne un pouvoir d'administration important. Ne l'exposez jamais sur Internet et ne publiez jamais la socket Docker brute. Préférez un réseau privé avec filtrage source ; pour un réseau non maîtrisé, ajoutez TLS ou un tunnel authentifié.

Architecture LAN ou Tailscale

Sur l'hôte Docker distant :

services:
  docker-proxy:
    image: tecnativa/docker-socket-proxy:latest
    restart: unless-stopped
    environment:
      CONTAINERS: 1
      IMAGES: 1
      VOLUMES: 1
      NETWORKS: 1
      INFO: 1
      POST: 1
      DELETE: 0
      AUTH: 0
      BUILD: 0
      EXEC: 0
      SYSTEM: 0
    ports:
      # Définissez cette variable dans le .env local de l'hôte distant.
      - "${DOCKER_PROXY_BIND_IP}:2375:2375"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

Définissez DOCKER_PROXY_BIND_IP dans le fichier .env local avec l'IP Tailscale ou LAN réelle de l'hôte distant. Ne committez pas ce fichier. Ajoutez au pare-feu une règle qui n'autorise que l'IP source de l'hôte NasDash vers TCP 2375.

Dans NasDash :

http://IP_PRIVEE_DU_PROXY:2375

Variante SSH sans publier 2375

Créez depuis l'hôte NasDash un tunnel persistant qui lie un port local à 127.0.0.1:2375 sur l'hôte distant, puis rendez ce port joignable depuis le conteneur NasDash. Cette approche demande une gestion rigoureuse de la clé SSH et du service de tunnel ; elle n'est pas fournie automatiquement par NasDash.

Test depuis le conteneur

docker compose exec nasdash node -e "fetch('http://IP_PRIVEE_DU_PROXY:2375/_ping').then(r=>r.text()).then(console.log)"

Si l'hôte répond depuis la machine mais pas depuis le conteneur, contrôlez le routage Docker, le pare-feu et les règles Tailscale. Consultez aussi Accès distant.