Problème DNS dans jeedom/jeedom:master

[Darato]

Bonjour,

Je tente d’installer Jeedom dans un conteneur Docker en utilisant l’image jeedom/jeedom:master.

Et j’ai un blocage à l’étape wget voici le log que j’ai :

Start jeedom installation
--2019-10-25 05:52:09--  https://raw.githubusercontent.com/jeedom/core/master/install/install.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... failed: Temporary failure in name resolution.
wget: unable to resolve host address 'raw.githubusercontent.com'

La partie de code qui exécute cette commande dans init.sh (dépôt Git jeedom/core) est :

if [ -f /var/www/html/core/config/common.config.php ]; then
	echo 'Jeedom is already install'
else
	echo 'Start jeedom installation'
	rm -rf /root/install.sh
	wget https://raw.githubusercontent.com/jeedom/core/master/install/install.sh -O /root/install.sh
	chmod +x /root/install.sh
	/root/install.sh -s 6
fi

Le problème est que je souhaite créer un conteneur dans mon réseau de conteneurs où tous mes autres conteneurs tournent.

J’utilise ce réseau pour que chaque conteneur ait une IP propre dans mon VLAN et éviter les conflits de ports.

Voici la partie qui concerne Docker :

Ce réseau a été créé comme suit :

docker network create -d bridge \
--subnet=10.0.10.0/24 \
--ip-range=10.0.10.192/26 \
--gateway=10.0.10.160 \
--aux-address="DefaultGatewayIPv4=10.0.10.1" \
--opt com.docker.network.bridge.default_bridge=true \
--opt com.docker.network.bridge.enable_icc=true \
--opt com.docker.network.bridge.enable_ip_masquerade=true \
--opt com.docker.network.bridge.host_binding_ipv4="0.0.0.0" \
--opt com.docker.network.bridge.name="brvlan_10" \
--opt com.docker.network.driver.mtu=1500 \
docker_subntk_vlan10

Quand je crée le conteneur avec la commande suivante :

docker create --network docker_subntk_vlan10 --ip 10.0.10.201 \
--name jeedom-server \
-v /opt/jeedom/html:/var/www/html \
-e ROOT_PASSWORD=<root_password> \
-e MODE_HOST=0 \
--restart always jeedom/jeedom:master \
&& docker start jeedom-server && docker logs -f jeedom-server

J’obtiens le message d’erreur du début.
Lorsque je me connecte au conteneur avec docker exec -it jeedom-server /bin/bash j’arrive bien à exécuter le wget.

Lorsque je crée le conteneur avec la commande :

docker create --net host\
--name jeedom-server \
-v /opt/jeedom/html:/var/www/html \
-e ROOT_PASSWORD=<root_password> \
-e APACHE_PORT=9080 \
-e SSH_PORT=9022 \
-e MODE_HOST=1 \
--restart always \
jeedom/jeedom:master

Tout se passe bien.
Je n’arrive pas à trouver ce qui peut causer un problème de résolution de nom uniquement dans init.sh en mode bridge, et pas en mode host.

Pour info tous mes autres conteneurs sur ce sous-réseau fonctionnent correctement niveau réseau, y compris le conteneur Jeedom avec docker exec, il n’y a que l’execution de l’ENTRYPOINT (init.sh) qui échoue.

[Darato]

Bonsoir/Bonjour,

J’ai enfin trouvé d’où venait mon problème, ce n’était pas la faute de l’image jeedom, mais bien de ma config.

En réalité, le « problème », vient du fait que dans la configuration de mon bridge dans /etc/network/interfaces j’ai activé le STP.

Pas facile à trouver, j’ai compris d’où ça venait car en créant un conteneur, il avait le réseau au bout d’une bonne 30aine de secondes.
Ce qui posait problème dans le conteneur jeedom car il fait des wget rapidement, mais plus de soucis lorsque je me connectais avec docker exec -ti jeedom-server /bin/bash car les 30 secondes étaient passée !!

Je m’arrête là pour ce soir, pour info la stack suivante docker-compose semble pas mal fonctionner à première vue, j’affinerais par la suite.

docker-compose.yml

version: '3'
services:
  zigbee2mqtt:
    image: koenkk/zigbee2mqtt
    restart: unless-stopped
    volumes:
      - /mnt/datastore0/domotique/zigbee2mqtt/data:/app/data
    devices:
      - /dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B00194AD935-if00:/dev/ttyUSB0
    environment:
      - TZ="Europe/Paris"
    networks:
      back:
        ipv4_address: 172.20.0.2


  # Le **broker** *MQTT Mosquitto* 
  mosquitto_1:
    image: eclipse-mosquitto
    restart: unless-stopped
    volumes:
      - /mnt/datastore0/domotique/mosquitto:/mosquitto
    networks:
      back:
        ipv4_address: 172.20.0.3
  
  # Le server *MariaDB*
  mariadb_jeedom:
    image: mariadb:10.1
    restart: unless-stopped
    volumes:
      - /opt/jeedom/mysql:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=<PASSWORD>
      - MYSQL_USER=jeedom
      - MYSQL_PASSWORD=<PASSWORD>
    networks:
      front:
        ipv4_address: 10.0.10.196
      back:
        ipv4_address: 172.20.0.4
      
  jeedom-server:
    image: jeedom/jeedom:master
    restart: unless-stopped
    environment:
      - TZ="Europe/Paris"
      - ROOT_PASSWORD=<PASSWORD>
    hostname: JeedomRaisin
    volumes:
      - /opt/jeedom/html:/var/www/html
    networks:
      front:
        ipv4_address: 10.0.10.201
      back:
        ipv4_address: 172.20.0.5

networks:
  front:
    external:
      name: "docker_subntk_vlan10"
  back:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.20.0.0/16
          #gateway: 172.20.0.1

Avec le réseau front routable et le réseau back non routable

[Gsyltc]

Juste une petite question. Pourquoi exposer la bdd en front ?

Ensuite j’ai quelques petites remarques

1. Si tu utilises des hostnames pour tes conteneurs, tu pourrais te passer de spécifier les IP dans le back. Le DNS se chargera de la resolution des noms, et tu pourras directement utiliser les hostnames dans tes applications.
   Cela pourras être utile si tu décides de passer avec un swarm (avec X conteneurs par services) ou un kubernetes (avec plusieurs pods, création d’un service et le tout avec un ingress ou un load balancer). Dans le dernier cas, utiliser la gestions par variables d’environnement serait pas mal car le cluster partagera tes variables entre pods.

2. Pour des raisons de sécurité, personnellement je fais une image des images master que je tag. Et j’utilise ces images. Pourquoi ? Imaginons un push avec un problème sérieux dans l’image. Si ton conteneur tombe, il repartira avec la nouvelle image corrompue. Et là, c’est la galère.

3. si tu veux utiliser les pleines fonctionnalités de compose, tag la version 3.7

4. Je ne comprend pas pourquoi tu fais les deux réseaux en fait. Tu as besoin du multicast ? Sinon, tu peux juste créer un seul réseau en bridge, exposer le port 80 et/ou 443 (en fonction des tes besoins), et éventuellement d’autres ports. Et ca fonctionne parfaitement. Avec le mode host, tu perds le principe du conteneur, l’isolation.

5. Tu peux éventuellement faire un volume - volume-session:/var/lib/php/sessions dans le conteneur jeedom

Cordialement