[TUTO] Docker : Introduction

.Shad. · le 23 mai 2020

Salut, merci de ton retour 🙂

Concrètement cela signifie que le NAS ne pourra pas joindre le conteneur, et vice-versa.
Si tu es en SSH sur le NAS, tu peux ping le conteneur il te répondra destination injoignable.
Pareil si tu te connectes au conteneur et que tu ping le NAS sur son IP locale.

Donc ton problème vient sûrement de là. Pour contourner ce problème on va créer une nouvelle interface, équivalente à eth0, sur laquelle le NAS pourra être joint, une 2ème porte d'entrée si tu préfères par laquelle les conteneurs en macvlan pourront communiquer avec le NAS.

ip link add <nom_interface_macvlan> link <interface_physique> type macvlan mode bridge
ip addr add <IP_virtuelle>/32 dev <nom_interface_macvlan>
ip link set dev <nom_interface_macvlan> address <adresse_MAC>
ip link set <nom_interface_macvlan> up
ip route add <Plage_DHCP_réseau_macvlan> dev <nom_interface_macvlan>

Il ne te reste plus qu'à adapter les variables à ton utilisation. Tu pourras renseigner <IP_virtuelle>:3000 pour joindre ton NAS.
NOTE : pour le nom_interface_macvlan, tu peux choisir choisir ce que tu veux. Pour l'IP_virtuelle, choisir évidemment une IP en dehors de la plage réseau du serveur DHCP de ta box/routeur. Pour l'adresse_MAC, prends-une au hasard, tant qu'elle n'existe pas déjà sur ton réseau.
Enfin la plage_DHCP_réseau_macvlan est celle qui a été définie lors de la création de ton réseau. Par exemple : 192.168.132.0/24
Comme dit dans le tutoriel, cette interface disparaît au prochain redémarrage, libre à toi de créer une tâche dans le planificateur pour exécuter ces commandes au démarrage.

Modifié le 23 mai 2020 par .Shad.

Phenix21 · le 23 mai 2020

Ca marche, je testerai demain en rentrant !

Je te tiens au courant des résultats 😉 , merci

Edit suite à tests

J'ai voulu configurer une ip "secours" en 192.168.0.220, pour une ip de base du NAS en 192.168.0.20, sur le macvlan_dsm. Par ailleurs j'ai un macvlan_pihole qui héberge le pihole ainsi que quelques autres conteneurs. La procédure se passe correctement, mais j'ai 2 soucis dans le lance le ifconfig :

d'une part je ne retrouve nulle part le macvlan_pihole
d'autre part le macvlan_dsm se trouve avec l'ip .200 (ou lieu du .220).

Est ce que à tout hasard ce serait une mauvaise config de mon macvlan_pihole (cf extrait du docker-compose ci dessous pour zigbee2mqtt, avec un ip figée dans la définition du service)


services:
  zigbee2mqtt:
    networks:
      pihole_network:
        ipv4_address: 192.168.0.206

networks:
  pihole_network:
    driver: macvlan
    driver_opts:
      parent: ovs_eth0
    ipam:
      config:
        - subnet: 192.168.0.0/24

C'est con, je pensais galérer pour faire reconnaitre la clé zigbee par zigbee2mqtt, mais c'est le lien zigbee-mqtt que je n'arrive pas à monter ^^

Merci d'avance si tu as quelques minutes pour moi !

Bonne soirée

Nota : pour le calculateur je suis passé par ce lien en français, c'était plus clair pour moi 😁

Modifié le 24 mai 2020 par Phenix21
Test mise en place

bruno78 · le 28 mai 2020

Bonjour,

peux-tu stp donner la définition complète du reseau pihole_network ? (subnet / gateway / ip_range) ?
en fait c'est l'ensemble de tes déclarations de reseaux et de services qui pourraient nous aider à trouver où est le bug ....

Merci

.Shad. · le 29 mai 2020

Salut,

J'ai l'impression que tu confonds le réseau macvlan (macvlan_pihole par exemple), pour lequel tu définis un sous-réseau, un gateway et un range IP sur lequel il sera actif.
Et l'interface virtuelle que tu crées sur ton NAS pour communiquer avec les conteneurs dans ce réseau macvlan.

Pour afficher l'interface tu sais faire vu l'impression d'écran.
Pour afficher les données du réseau, tu tapes :

docker network inspect macvlan_pihole

(ajouter sudo si pas en root)

Modifié le 29 mai 2020 par .Shad.

aware · le 30 mai 2020

Hello

Merci pour ce tuto (jeedom).

Mais j'ai un problème, au lancement à la création du conteneur jeedom-v4.

Il redémarre en boucle. Dans le journal, j'ai :

/root/init.sh: 2: /root/init.sh: 
: not found
/root/init.sh: 4: /root/init.sh: 
: not found
/root/init.sh: 7: /root/init.sh: Syntax error: Bad fd number

(le not found n'apparait pas visuellement, mais en copier/coller)

image.png.a3fbdf3e397d215bd436704804f56530.png

J'ai fait un copier/coller du init.sh, j'ai vérifié c'est identique au tuto.

Je l'ai placé dans /volume1/docker/jeedom-v4/install/OS_specific/Docker/init.sh

Une idée du problème ?

Edit :

Bon j'ai repris les dernières étapes et l'install et en cours. J'ai dû faire une boulette quelque part.

Modifié le 30 mai 2020 par aware

Phenix21 · le 30 mai 2020

Le 29/05/2020 à 10:33, .Shad. a dit :
Salut,

J'ai l'impression que tu confonds le réseau macvlan (macvlan_pihole par exemple), pour lequel tu définis un sous-réseau, un gateway et un range IP sur lequel il sera actif.
Et l'interface virtuelle que tu crées sur ton NAS pour communiquer avec les conteneurs dans ce réseau macvlan.

Pour afficher l'interface tu sais faire vu l'impression d'écran.
Pour afficher les données du réseau, tu tapes :
docker network inspect macvlan_pihole
(ajouter sudo si pas en root)

Le 28/05/2020 à 08:39, bruno78 a dit :

Bonjour,

peux-tu stp donner la définition complète du reseau pihole_network ? (subnet / gateway / ip_range) ?

en fait c'est l'ensemble de tes déclarations de reseaux et de services qui pourraient nous aider à trouver où est le bug ....

Merci

Bonsoir !

Désolé, je n'avais pas vu vos retours. Je vous envoie les infos demain ou lundi.

Entre temps, j'ai contourné le problème en passant tout sous le même macvlan ^^

Bonne soirée !

aware · le 30 mai 2020

Re bonjour

Je me permets une question concernant Jeedom sur Docker en réseau macvlan.

J'héberge d'autres conteneur, en mode bridge par exemple.

Ensuite, je crée un cname sur mon domaine, puis un proxy inversé côté Synology dans le portail des applications, et je termine par un certificat let's encrypt.

Du coup j'ai accès à tous mes services de l'extérieur, en sous-domaine, avec certificat, par exemple bitwarden.mondomaine.com

Concernant Jeedom en macvlan, je me retrouve avec une autre adresse ip, du coup le proxy inversé ne fonctionne pas côté Synology.

une idée comment contourner ça, ou c'est mort à cause du réseau macvlan ?

.Shad. · le 30 mai 2020

Tu as essayé de créer une interface virtuelle (comme à la fin du tutoriel) ?

EDIT : Après réflexion je ne vois pas pourquoi le fait que le NAS n'arrive pas à communiquer avec le conteneur pourrait poser problème pour le proxy inversé. Et tu devrais pouvoir résoudre le problème avec l'astuce de l'interface virtuelle.

Modifié le 30 mai 2020 par .Shad.

aware · le 30 mai 2020

Je suis parti avec le nouveau tuto, qui ne parlait pas de l'interface virtuelle.

Et quand je faisais le proxy inversé, je tombais sur la page Synology : Sorry, the page you are looking for is not found

Du coup j'ai regardé le tuto "obsolète", et appliqué le routage IP, ça fonctionne.

Merci !

Phenix21 · le 1 juin 2020

Bonjour !

De retour pour les infos

Le 28/05/2020 à 08:39, bruno78 a dit :

Bonjour,

peux-tu stp donner la définition complète du reseau pihole_network ? (subnet / gateway / ip_range) ?

en fait c'est l'ensemble de tes déclarations de reseaux et de services qui pourraient nous aider à trouver où est le bug ....

Merci

Ci dessous la définition du réseau pihole_network tel qu'enregistrée dans mes docker-compose :

networks:
  pihole_network:
    driver: macvlan
    driver_opts:
      parent: ovs_eth0
    ipam:
      config:
        - subnet: 192.168.0.0/24

Je n'y ai pas défini ni passerelle ni ip_range. Chaque conteneur fait ensuite l'objet d'une attribution d'ip fixe avec le paramètre suivant :

    networks: 
      pihole_network:
        ipv4_address: 192.168.0.XXX

où XXX est un valeur fixée dans une plage que je me suis réservée pour tous les maclan. Le DHCP du réseau est hors de cette plage là pour éviter les conflits d'IP.

Ca fonctionne plutôt bien, aujourd'hui j'ai plusieurs conteneurs (pihole, HA, nodered, zigbee2mtt, mosquitto, ...) qui tournent de cette manière et sont accessibles via leurs IP respectives. Ces conteneurs communiquent entre eux sans souci également

Le 29/05/2020 à 10:33, .Shad. a dit :
Salut,

J'ai l'impression que tu confonds le réseau macvlan (macvlan_pihole par exemple), pour lequel tu définis un sous-réseau, un gateway et un range IP sur lequel il sera actif.
Et l'interface virtuelle que tu crées sur ton NAS pour communiquer avec les conteneurs dans ce réseau macvlan.

Pour afficher l'interface tu sais faire vu l'impression d'écran.
Pour afficher les données du réseau, tu tapes :
docker network inspect macvlan_pihole
(ajouter sudo si pas en root)

Je n'ai pas recréé le réseau au reboot. Voilà ce que me donne l'inspect :

ash-4.3# docker network inspect docker_pihole_network
[
    {
        "Name": "docker_pihole_network",
        "Id": "09ca946f83e7b991c2fb63678fafa48ba19598dfbe14507a94996e66136c0eb8",
        "Created": "2019-09-28T16:26:25.638250549+02:00",
        "Scope": "local",
        "Driver": "macvlan",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "192.168.0.0/24",
                    "IPRange": "192.168.1.192/28",
                    "Gateway": "192.168.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "a3d22349f394487fa497997a13560cfd7bbc2e44daa153606a3fef3262965a85": {
                "Name": "pihole",
                "EndpointID": "XXX",
                "MacAddress": "02:42:c0:a8:00:c8",
                "IPv4Address": "192.168.0.XXX/24",
                "IPv6Address": ""
            },
            "a638ff6992e28a2bff57a7beb880332de5169e379f645ef9d6eb89afda9efdd2": {
                "Name": "ha",
                "EndpointID": "XXX",
                "MacAddress": "02:42:c0:a8:00:db",
                "IPv4Address": "192.168.0.XXX/24",
                "IPv6Address": ""
            }
        },
        "Options": {
            "parent": "ovs_eth0"
        },
        "Labels": {}
    }
]

(dites moi s'il faut éditer des infos). L'adresse MAC est générique et s'incrémente petit à petit.

.Shad. · le 1 juin 2020

il y a 37 minutes, Phenix21 a dit :

Je n'ai pas recréé le réseau au reboot.

Ce n'est pas le réseau qui disparaît au redémarrage, mais l'interface virtuelle du NAS par laquelle le NAS peut communiquer avec ses conteneurs en macvlan.

Et je ne comprends pas pourquoi tu donnes un ip_range 192.168.1.192/28 à ton réseau macvlan, tu peux très bien le mettre hors de la plage DHCP de ton routeur ou de ta box tout en restant dans le sous-réseau 192.168.0.0/24.
Par exemple définir dans ton serveur DHCP une plage de 192.168.0.2 à 192.168.0.99. Dans ce cas-là, utiliser 192.168.0.192/28 sur ton réseau macvlan te donnera une disponibilité d'adresse de 0.193 à 0.206 pour tes conteneurs macvlan (quitte à descendre le CIDR si tu as besoin de plus d'adresses).

Pas de chevauchement et tu pares à tout problème éventuel de communication.

Et tant que tu ne crées pas d'interface virtuelle sur ton NAS (voir fin du tutoriel), aucun moyen que le NAS communique avec tes conteneurs macvlan, quels qu’ils soient.

Phenix21 · le 2 juin 2020

Bonjour !

Il y a 14 heures, .Shad. a dit :

Et je ne comprends pas pourquoi tu donnes un ip_range 192.168.1.192/28 à ton réseau macvlan, tu peux très bien le mettre hors de la plage DHCP de ton routeur ou de ta box tout en restant dans le sous-réseau 192.168.0.0/24.

J'avoue moi non plus, je sais plus pq j'avais fait comment, surtout que derrière je fige une IP fixe en 192.168.0.X !

Il y a 14 heures, .Shad. a dit :

Ce n'est pas le réseau qui disparaît au redémarrage, mais l'interface virtuelle du NAS par laquelle le NAS peut communiquer avec ses conteneurs en macvlan.

Et tant que tu ne crées pas d'interface virtuelle sur ton NAS (voir fin du tutoriel), aucun moyen que le NAS communique avec tes conteneurs macvlan, quels qu’ils soient.

Je vais retenter du coup, à voir si je me retrouve avec l'interface virtuelle avec la bonne IP. J'ai contourné le problème en mettant tous les conteneurs qui devaient communiquer entre eux dans le même macvlan.

Merci !

.Shad. · le 2 juin 2020

il y a 2 minutes, Phenix21 a dit :

J'ai contourné le problème en mettant tous les conteneurs qui devaient communiquer entre eux dans le même macvlan.

Si tu as juste besoin qu'ils communiquent entre eux alors c'est ok, reste qu'ils ne pourront jamais communiquer avec leur hôte.
Est-ce que Jeedom n'a pas besoin de communiquer avec le NAS pour tout ce qui est dongle ? (je ne connais pas du tout Jeedom, mais @Didier3L avait l'air de dire qu'il avait ce besoin).
Si tu utilises pihole, le NAS doit pouvoir contacter l'IP de ton Pihole pour accéder à Internet s'il est en DHCP. Ou alors il va mouliner pendant x secondes, se rabattre sur le deuxième serveur DNS (s'il y en a un configuré), ou carrément être incapable de résoudre la requête.

Un cas où par exemple tu te fiches d'avoir une communication entre ton NAS et son conteneur sur réseau macvlan, c'est unifi-controller, ou la plupart des applications en fait...

Vérifie quand même que tout fonctionne comme tu le souhaites.

Phenix21 · le 2 juin 2020

Il y a 14 heures, .Shad. a dit :

Est-ce que Jeedom n'a pas besoin de communiquer avec le NAS pour tout ce qui est dongle ? (je ne connais pas du tout Jeedom, mais @Didier3L avait l'air de dire qu'il avait ce besoin).

HA pas de souci. J'ai également une clé zigbee2mqtt qui fonctionne nickel, sans problème

Il y a 14 heures, .Shad. a dit :

Si tu utilises pihole, le NAS doit pouvoir contacter l'IP de ton Pihole pour accéder à Internet s'il est en DHCP. Ou alors il va mouliner pendant x secondes, se rabattre sur le deuxième serveur DNS (s'il y en a un configuré), ou carrément être incapable de résoudre la requête.

Effectivement ça peut être le souci, je n'ai pas le NAS sur le PiHole. Idem pour pouvoir monitorer le NAS depuis HA

Il y a 14 heures, .Shad. a dit :

Un cas où par exemple tu te fiches d'avoir une communication entre ton NAS et son conteneur sur réseau macvlan, c'est unifi-controller, ou la plupart des applications en fait...

Aujourd'hui ce qui fonctionne c'est l'ensemble chronograp/influxdb/grafana, zigbee2mqtt, mosquitto, nodered

Aujourd'hui je galère avec une passerelle homekit, mais c'est le cas pour ma version d'HA en bridge.

Edit 2 : ben si je dois avoir un problème de réseau, ma config homekit passe sur le HA bridgé...

Edit 3 : je n'arrête pas les edit... Je viens de faire le point, et je n'ai aucun conflit de port pour tous mes containers "domotique". Conclusion : pourquoi tout vouloir passer sur un macvlan ? Conclusion bis : des fois, je ferais mieux de réfléchir un peu plus avant de me lancer dans les bidouilles, surtout quand la doc HA spécifie çà :

Citation

Note that Docker command line option --net=host or the compose file equivalent network_mode: host must be used to put Home Assistant on the host’s network, otherwise certain functionality - including mDNS and UPnP - will break.

Edit : j'en profite pour poser une petite question complémentaire. Sur certains docker-compose on voit des paramètres depends_on. A quoi cela sert-il ? Quel est l'intérêt de déclarer ces dépendances ?

Modifié le 2 juin 2020 par Phenix21
Question sup + màj

.Shad. · le 2 juin 2020

Si tu n'as aucun conflit de port, aucune raison de passer en macvlan, quand la documentation HA parle de fonctionnalité cassée c'est parce qu'en bridge le conteneur n'a pas accès au broadcast sur le réseau physique, ce qui en domotique est assez problématique.

Donc mode host a priori, ça me semble tout indiqué.

.Shad. · le 4 juin 2020

J'ai oublié de répondre à ta dernière question : depends_on permet de demander à ce que le service pour lequel on précise l'option démarre après le service cible.

Donc typiquement :

services:
   carddav:
      ...
      depends_on: mariadb
      ...

   mariadb:
      ...

L'utilisation typique c'est qu'un conteneur attende le démarrage d'une base de données, pour éviter les erreurs de communication parce que la base de données ne serait pas encore initialisée.

PS : Cette option ne peut, de mémoire, faire référence qu'à des services définis dans le même fichier compose.

Phenix21 · le 4 juin 2020

Il y a 6 heures, .Shad. a dit :
J'ai oublié de répondre à ta dernière question : depends_on permet de demander à ce que le service pour lequel on précise l'option démarre après le service cible.

Donc typiquement :
services:
   carddav:
      ...
      depends_on: mariadb
      ...

   mariadb:
      ...
L'utilisation typique c'est qu'un conteneur attende le démarrage d'une base de données, pour éviter les erreurs de communication parce que la base de données ne serait pas encore initialisée.

PS : Cette option ne peut, de mémoire, faire référence qu'à des services définis dans le même fichier compose.

Merci !

testadaz · le 16 juin 2020

Bonjour,
J'ai une question, depuis quelques temps, je remarque qu’après un redémarrage de mon synology le package docker ne se lance pas tout seul...
Est ce que vous avez déjà rencontré ce problème ? Si oui avez vous une solution pour résoudre le pb ?
Merci

DSM : 6.2.3-25426
docker : 18.09-0.0.513

.Shad. · le 16 juin 2020

Je n'ai jamais eu ce problème personnellement, tu n'as rien trouvé via Google ?

bruno78 · le 16 juin 2020

Bonjour, aucun problème de redemarrage constaté non plus ....

Des changements de configuration ou des ajouts particuliers qui pourraient être mis en cause ? ou à configuration strictement équivalente ?

testadaz · le 16 juin 2020

j'ai du mal à vous répondre factuellement parce que mon nas est resté allumé pdt des mois (donc oui il y a eu des changements, bcp et je ne suis pas capable de les lister) et récemment j'ai changé de fournisseur internet, j'ai du le rebooter plusieurs fois (parce que chg de box et de sous réseau) et à chaque fois qu'il redémarre le package ne se lance pas, il faut que j'aille dans le gestionnaire de package pour cliquer sur "run"
bon je vais continuer à essayer de comprendre ce pb

.Shad. · le 29 juin 2020

@testadaz Problème toujours présent ? As-tu testé de désinstaller le paquet et de le réinstaller ?

testadaz · le 29 juin 2020

oui pb toujours présent.
J'ai effectivement désinstallé le paquet et reinstallé plusieurs fois.

Rien n'y fait. et c'est de pire en pire, j'arrive meme plus à lancer le paquet.

je crois que je vais demande de l'aide au support, parce que je m'en sors plus

Car même la commande ci dessous ne marche plus :

synoservice --start pkgctl-Docker
service [pkgctl-Docker] start failed, synoerr=[0x3900]

Par contre

synoservice --hard-start pkgctl-Docker

a bien voulu lancé le paquet...

Modifié le 29 juin 2020 par testadaz

.Shad. · le 29 juin 2020

As-tu regardé ce que dit /var/log/messages à ce sujet ?
Tu peux aussi taper dmesg en SSH, tu pourrais y trouver quelques infos.

Sinon le support, insiste pour avoir l'équipe technique directement, tu risques d'être baladé entre du support de premier niveau.

Lelolo · le 29 juin 2020

L'erreur que tu rencontres correspond à "ERR REMOVE FAILED 0x3900 Failed to remove file.", mais je ne sais pas si cela va t'aider

Connexion

[TUTO] Docker : Introduction

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

.Shad.

Geoff1330

CyberFr

Images postées

Rejoindre la conversation

Qui est en ligne 1 membre, 0 anonyme, 143 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante