Installation MQTT avec docker

Bonjour,

Suite à des conseils de certains d’entre vous (ici), je part finalement sur une installation docker de HA (container donc)+MQTT+Zigbee2MQTT+Rhasspy…
Donc, en commençant par la doc et les tutos, simplement, je ne trouve pas ça évident :frowning: mais je ne renonce pas.
J’ai installé Portainer (le jour et la nuit par rapport aux lignes de commande docker, à mon avis), mis des images tenté mes premiers containers.

Le plus complexe, pour moi, commence avec la configuration de Mosquitto. Il y a des tuto de partout, et n’étant pas à l’aise avec tout, je ne sais pas où ça foire dans mon installation.

J’ai suivi ce tuto avec la stack proposée (bien pratique), il diffère de la doc officielle (il faudrait créer des fichiers, mais je ne sais pas où), et le fichier de conf à reprendre est parfoit étoffé par rapport à la doc officielle, mais je ne sais pas ce qu’il faut garder impérativement (exemple ici, par exemple Listener : 1883 n’est pas dans la doc de Eclipse)

Donc première question : quelle est votre stack/docker compose pour Mosquitto ? et qu’avez-vous changé (et où) dans le fichier de conf ?

Deuxième question : je n’ai pas mis de login/mdp dans mon premier essai (on va faire simple pour un premier proto). Quand je me connecte à HA, quelle adresse dois-je renseigner pour le Broker… 192.168.1.6 / 192.168.1.6:1883 / 172.18.0.2 (adresse IP du container donnée par Portainer) / 172.18.0.2 :1883 / 172.18.0.1 (IPV4 du network mosquitto sur Portainer…) ?
Dans les tutos, certain sont en 172, d’autres en 198. Je suppose que tout doit être possible, mais car j’ai du mal à comprendre les docs… que me conseillez-vous (mon RPI est connecté à ma box en ethernet en 192.168.1.6).

Voici mes networks si ça peut aider à la compréhension de mes questions :

Dernière question, faut-il remplir le nom d’utilisateur et le MDP pour HA (sachant que je n’ai rien configuré sur Mosquitto) ?

Voilà, je vous ennuie, mais je n’ai pas su trouver de tuto clair permettant d’installer Mosquitto sous docker (correspondant à mon niveau)… et l’intégrer à HA. Il doit y avoir pas mal de choses évidentes par la suite, mais je galère pas mal.

Merci d’avoir pris le temps de lire ma requête jusqu’au bout et merci d’avance !
Damien

Salut
Les fichiers de conf sont toujours à mettre dans des volumes … Par exemple

    volumes:
      - /home/pi/domoticz/userdata:/opt/domoticz/userdata

ça veut dire que le répertoire de l’hôte /home/pi/domoticz/userdata (et son contenu) est mappé avec le répertoire du container /opt/domoticz/userdata
ça fonctionne sur le même principe avec des fichiers : 1 pour 1

ça c’est dépendant de comment ton container est créer : mode host (192) / bridge (178)

  • Bridge:
    Pour faire super rapide, les containers en mode bridge peuvent discutent entre eux quand il ont le même network (des adresses 172)… Deux réseaux bridge différents ne se parlent pas par défaut, mais un conteneur peut être lié à plusieurs réseaux
    Ensuite on peut exposer les ports pour les rendre visible aux yeux du monde réel
    ports:
      - 8080:8081

Comme pour les fichiers/répertoire le port 8080 de machine hôte permettra de dialoguer avec le port 8081 du container

  • Host:
    Là c’est un peu différent, le container prends une adresse ip via le DHCP …
    expose: 
    - 80
    - 443

Ses ports sont ouverts directement sur l’ip du container …

Donc puisque tu fais ça à la main (je suis pas convaincu que pour débuter ce soit réellement plus simple que la version supervisée mais c’est un autre débat) … tu vas probablement devoir toujours passer par les ip en 192

je me permet 2 petites recommandations :

  • monter ses stacks avec portainer (ce que semble proposer le 1er tuto qui me semble bien incomplet au passage) … ouais bof. C’est pratique pour la gestion au quotidien mais ça vaut pas un fichier docker-compose… d’autant plus vrai quand il faut expliquer aux autres
  • les tutos tout faits, c’est bien aussi, il en faut mais c’est un piège : quand on sort de la partie copié/collé et ou qu’on mixe des trucs différents, on se retrouve coincé. La doc de docker (et docker-compose principalement) est pas si mal fichue… Faut y aller petit à petit mais au moins on maitrise le contexte
    Overview of Docker Compose | Docker Documentation

Voilà en synthèse… C’est très abrégé et pas 100% exact, mais ça devrait te permettre de te débloquer

Et oui ce n’est pas toujours simple de se lancer mais tu verras que tu y gagneras à la fin, dans la compréhension de ton installation et tu garderas la main sur cette installation.

Je suis dans le même cas que toi, j’ai installé HA Container. Ton installation semble bonne, tout comme l’installation de Mosquitto. Il te faut maintenant indiquer l’IP de ton raspberry dans HA (192.168.1.6 si j’ai bien compris) et ça devrait fonctionner. En tout cas ça tourne comme ça chez moi :wink:

Merci à vous deux !
Quelques compléments de réponses : HA container m’a été suggéré dans ce forum à la place de supervisor…
Depuis vos explications, et quelques doc/tuto sur docker, je commence à comprendre à peu près cette histoire de volume (permet de sortir du container et partager des objets).
Pour les networks, je ne comprends pas pourquoi Mosquitto ne voulait pas rejoindre le bridge de docker (du coup, je l’ai mis en host… et ça à l’air de fonctionner).

Je ne suis pas contre en baver un peu (je me suis mis à linux depuis le premier confinement, donc tout ceci est assez récent), mais c’est bien si tout ceci reste un peu plus accessible (diminue la marche à franchir entre « une carte électronique » → « un système domotique ».

En tout cas merci pour vos tuyaux.

Etapes suivantes : MQTT/Rhasspy/HA, puis intégration Zigbee2MQTT !

J’assume le conseil. Vu que certains containers allaient être hors gestion du superviseur, ça évite de créer un environnement hybride, forcément plus compliqué à gérer.
Là, tout est à la main. Certes, ce n’est pas trivial.

La façon de lancer mosquitto, tu as dit d’une manière ou d’une autre, créé un nouveau bridge « mosquitto_default ». Et donc étant dans un autre sous-réseau 172.18, il ne parle pas aux machines en 172.17.
Visiblement, c’est la même chose pour Z2M qui lui est en 172.19. Comment as tu lancé les containers? compose? stack? docker run? C’est là que ça c’est joué.
Et pour

Je suggère de faire d’abord z2m, c’est « simple » et bien documenté.

En docker create (ligne de commande) puis run (via portainer), via ce tuto :
docker create --name MQTT -p 1883:1883 -p 9001:9001 -v /opt/mosquitto/config:/mosquitto/config -v /opt/mosquitto/data:/mosquitto/data -v /opt/mosquitto/log:/mosquitto/log --restart always eclipse-mosquitto

Je ne comprends pas la doc officielle qui demande de créer un premier container :

docker run -it -p 1883:1883 -p 9001:9001 -v mosquitto.conf:/mosquitto/config/mosquitto.conf eclipse-mosquitto

ensuite de modifier le fichier de config, puis de recréer un container :

docker run -it -p 1883:1883 -p 9001:9001 -v mosquitto.conf:/mosquitto/config/mosquitto.conf -v /mosquitto/data -v /mosquitto/log eclipse-mosquitto

Pour Z2M, j’étais parti sur une stack trouvée sur le net… je viens de refaire un saut sur la doc officielle, qui explique :

Optional: in case your MQTT broker is running on localhost and is not within the same Docker network as the Zigbee2MQTT container also add --network host \.

Z2M serait donc en host forcément dans mon cas ?

J’ai laissé le CC debugger au boulot… donc je commence par Rhasspy en attendant :slight_smile:

Merci

Le tuto, c’est une vidéo youtube qui parle on dirait d’autre chose.
Par je ne sais quelle opération, ton container mosquitto est dans un autre bridge… Ca doit pouvoir (peut-être) marche mais ça ne me parait pas propre. Via portainer, tu arrêtes le container, tu mets le container dans le bridge par défaut. Tu relances. Il doit prendre une adresse en 172.17. Et ça ira mieux!

Idem pour zigbee2mqtt, mettre dans 172.17.

Ensuite, vu que tu as -p 1883:1883, mosquitto sera visible avec l’adresse du serveur sur le port 1883.
Pas la peine de mettre en -host les containers. Tous sur le même bridge et les ports relayés. Je ne suis pas un expert docker, donc, je ne suis pas sûr que ce soit la façon optimale de faire, mais, en tout cas, ça marche et c’est propre.

Salut,

Dans les faits, tous les conteneurs pourraient être dans un network différent à chaque fois, si les bons ports sont accessibles et qu’on passe par les ip du lan, ça fonctionnera.
A l’inverse, mettre tous les conteneurs dans un seul et unique, ça simplifie les liens entre containers, mais du coup … si ça n’a pas besoin de dialoguer ensemble ça augmente les risques…

L’idée en général c’est de faire des groupements par « architecture » / « appli » :

  • apache / phpmyadmin /mariadb pour faire un site web dans le net1
  • grafana + influxdb dans le net2
    Le cloisonement des network étant une fonction de base, on ajoute un jolie couche de sécurité sans rien faire (ni régles réseau, ni dhcp, ni dns). Donc autant ne pas s’en priver !

Et quand il y a besoin d’un proxy (en conteneur) pour rendre tout cas accessible par exemple depuis le web, on ajoute un network transverse avec un reverse proxy (jwilder par exemple sur net3) rattaché à tous les frontaux (apache et grafana). Le jwilder exposant ses ports 80/443 par exemple sur lan.
Sinon on expose les ports uniquement nécessaires

Après je le répéte…

  • Créer ses conteneurs avec portainer, c’est super pratique … sauf que ça garde pas une trace de comment c’est construit ailleurs que dans portainer.
  • Le docker run … faut oublier, ça va pour tester mais c’est un bordel à relire quand ça devient un peu complexe.
  • Et le docker create ça revient à utiliser un docker-compose, la lisibilité en moins

Avec un fichier docker-compose dans un coin (un nas, un git) on en garde une copie exploitable. ça s’importe dans portainer. Et puis c’est du yaml … comme HA

Pour s’aider dans un premier temps, je conseille https://www.composerize.com/
ça marche assez bien pour les montages simples…

1 « J'aime »

Merci du tuyau.
J’ai toujours été un peu rebuté par les compose que je trouvais en v2, alors que c’est maintenant la v3. Sans trop comprendre (ni chercher beaucoup :frowning: ) les différences.
Le docker run, c’est certes moche, mais, ça n’a pas changé :wink:

Ben, une belle pile un peu compliquée de plusieurs conteneurs avec un docker run je te souhaite bien du courage. Je comprends mieux pourquoi du coup, tu n’exploites pas forcement les différents networks

La principale différence entre une v2 et une V3 c’est surtout :

  • volumes_from qui déclare avec le partage entre 1 vers n containers. En v3 c’est devenu une déclaration d’un volume à part entière réutilisable dans chaque conteneur individuellement
  • extends qui permettait de faire du templating … Maintenant, en V3, on fait ça avec un docker-compose variabilisé et N .env (c’est très fun)
  • quelques changements syntaxiques
  • Et forcement les nouvelles fonctions de docker qui s’ajoutent au fur et à mesure

Sachant que de toute façon une version 2 est rétro-compatible avec un docker récent…

Dernier tips: L’add-on visual-studio code de HA sait lire/corriger et aide à la prédiction syntaxique des fichiers docker-compose avec le plugin docker. Quand on y a gouté difficile de s’en passer

Fait, en effet, ça fonctionne mieux !


La commande (et solution) :
docker create --name MQTT -p 1883:1883 -p 9001:9001 -v /opt/mosquitto/config:/mosquitto/config -v /opt/mosquitto/data:/mosquitto/data -v /opt/mosquitto/log:/mosquitto/log --net=bridge --restart always eclipse-mosquitto

Pour mieux comprendre, quel est l’intérêt de tout mettre dans le réseau Bridge ? Ca ne serait pas plus simple d’avoir tout dans host ?

Oui, vu mon niveau, le NAS n’est pas pour tout de suite, et git c’est là où on partage des programmes ? ta proposition est plutôt pour stocker un fichier (comme drive/dropbox) ?

Ben non…
C’est comme pour rendre HA disponible à l’extérieur : on ne le met pas dans la DMZ. Même si c’est plus simple.
Juste pour rappel quand même les images, on connaît pas forcément ce que ça contient bien caché au milieu du code…
Et moins grave mais imagine 2 conteneurs qui proposent d’ouvrir le même port 80… Ça va coincer.
Au total, les ports du host sont limités
Et tous ces conteneurs n’ont certainement pas besoin d’avoir accès à tout ton réseau local en direct et en intégralité.

Règle d’or pour docker : on utilise le minimum pour que ça fonctionne…

Non, git : ça permet de stocker les informations, les différentes versions au fur et à mesure des changements… Et optionnellenement de les partager
Dropbox & co c’est ni plus ni moins qu’un nas pas hébergé chez toi. C’est une alternative effectivement

1 « J'aime »

Il est très bien fait ce tuto :smiley:

En tout cas cela fonctionne chez moi comme cela depuis plusieurs mois. Et la commande est à l’exception du --net=bridge la même que tu utilises en tant que solution. Après dans cette vidéo je n’aborde pas Zigbee2Mqtt car c’est l’appareil Shelly qui envoyait les infos directement dans MQTT.

Mais j’ai installé aussi Zigbee2MQTT sans souci derrière et les 2 conteneurs sont dans le même network et ça fonctionne très bien.

Je n’ai jamais dit qu’il est mal fait :wink:
Mais, les tutos vidéo, c’est pas mon truc. J’aime bien les écrits. Un manuel, une doc. Un truc de vieux.

2 « J'aime »