This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

.Shad.

[TUTO] Docker : Introduction

Messages recommandés

 

610px-Docker_(container_engine)_logo_svg.png.af445cb7077117841de7dc90e3c29b9f.png

 

Qu'est-ce que Docker ?

Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n'importe quel serveur. On ne parle pas ici de virtualisation mais de conteneurisation, une forme plus légère, qui s'appuie sur certaines parties de la machine hôte pour son fonctionnement. En effet, une machine virtuelle nécessite son propre système d'exploitation et nécessite donc une certaine quantité de mémoire dédiée, tout cela parfois dans le but de faire tourner une seule application.
Synology fournit sa propre version du moteur Docker via le centre de paquets.

Pré-requis

Les modèles compatibles sont :

  • Les modèles +
  • Les modèles RS, FS, SA
  • Le DS620slim

Seuls les NAS Synology de série 10 et plus peuvent en bénéficier.

Pourquoi utiliser Docker sur un NAS Synology ?

  • DSM est un système basé sur un noyau Linux, cependant c'est un système propriétaire et si certains éditeurs de logiciels font l'effort et ont les ressources pour développer un paquet adapté, force est de reconnaître que ça reste limité.
  • SynoCommunity fournit certains paquets très utiles, mais les paquets étant maintenus sur la base du volontariat, les mises à jour sont fréquemment en retard.
  • DSM fournit une interface relativement claire et épurée pour Docker, bien que limitée pour certains cas d'utilisation.
  • Vous pouvez a priori exécuter n'importe quelle application disponible pour une distribution Linux classique.
  • Enfin, le point le plus intéressant, le système n'est en rien affecté et aucune dépendance n'a besoin d'être installée.
  • Vous ne risquez donc pas (du moins sans le vouloir) de planter votre installation DSM et les mises à jour de ce dernier n'ont que très peu de chances d'impacter l'exécution de vos conteneurs.

Comment utiliser Docker ?

Nous verrons trois méthodes pour créer des conteneurs :

  • Par l'interface intégrée à DSM
  • via SSH par ligne de commande
  • via SSH en utilisant Docker-compose

Les deux dernières méthodes, bien qu'un peu moins accessibles pour des images simples à configurer, se révèlent plus efficaces lorsqu'on sort des sentiers battus.

Installation de Docker et recommandations

Pour installer Docker, il suffit de se rendre dans le centre de paquets et de chercher Docker dans la liste des paquets tiers, on clique sur Installer. Done !
Mais avant de commencer le tutoriel et de télécharger vos premières images, quelques précautions, pour les besoins du tutoriel j'utiliserai comme exemple Heimdall, qui est une dashboard permettant de créer des liens rapidement vers ses applications via des épingles.

  • Docker Hub est un centre de dépôts où la qualité des images peut varier très fortement, dès lors à moins de ne pas avoir le choix, évitez les images qui ne fournissent aucune documentation
  • Parfois, la page Docker Hub d'une image ne fournit pas beaucoup d'information, vous trouverez généralement plus d'informations concernant la dite image sur GitHub (page GitHub / page DockerHub)
  • En cas de difficulté pour créer un conteneur fonctionnel, il est toujours intéressant d'aller consulter les pages relatives au support et aux soucis techniques sur GitHub (https://github.com/linuxserver/Heimdall/issues)
  • Il n'est pas toujours plus simple d'utiliser la version conteneurisée d'une application que sa version classique. Si pour x ou y raisons il existe des incompatibilités avec un NAS Synology ou si les difficultés sont trop nombreuses, si la documentation fait cruellement défaut, ou encore que l'image est à l'abandon, je vous conseiller d'opter pour une machine virtuelle et réaliser une installation classique. C'est du temps gagné et des cheveux épargnés. 🙂

Interface de Docker dans DSM

On clique sur Docker pour arriver sur cette interface :

ui_docker.thumb.PNG.2068747a06e95dcdceeaea4769c30ff2.PNG

On peut voir l'utilisation générale du processeur et de la mémoire, ainsi que l'utilisation des ressources pour chaque conteneur créé.

Dans l'onglet Conteneur, on peut venir éditer nos différents conteneurs : les arrêter et les démarrer (interrupteur à droite), les modifier, les supprimer, etc...

ui_docker_conteneur.thumb.PNG.e8f4078d0ba2c96ec7977b606f3c49e9.PNG

L'onglet Registre est celui qui permet de télécharger les images des applications qui nous intéressent :

ui_docker_registre.thumb.PNG.bac43b459c9a1a334a4f3c6697583dda.PNG

L'onglet Image liste les images qu'on a téléchargées sur le NAS et la taille qu'elles occupent dans l'espace de stockage :

ui_docker_image.thumb.PNG.33c0d4888582ae3c76d46e63071b2dc7.PNG

L'onglet Réseau définit les réseaux sur lesquels nos conteneurs seront actifs.

ui_docker_reseau.thumb.PNG.e8f02f62834c46cc011ada66ba581c55.PNG

L'onglet Journal est un fichier log des différentes actions réalisées (création et suppression de conteneurs, téléchargement d'images, etc...)

Chronologie

La logique est la suivante :

  1. On télécharge l'image d'une application qui nous intéresse.
  2. On crée un conteneur basé sur cette image en personnalisant les données à notre utilisation : les variables (un login/mdp, l'utilisateur du NAS qui va exécuter l'application, un fuseau horaire, etc...), les ports (comment on y accède), les volumes (souhaite-t-on stocker des données de manière persistente?), les réseaux (liés à l'accessibilité et à la communication), etc...
  3. On démarre le conteneur.

Exemple

Image

Je reprends l'exemple de l'image linuxserver/heimdall (le terme à gauche est le nom de l'éditeur de l'image, à droite le nom de l'application).
Par défaut, toutes les images qu'on peut rechercher dans l'interface Docker de DSM correspondent aux images hébergées sur Docker Hub. Il est possible d'ajouter des registres supplémentaires (GitLab et d'autres). Dans 99% des cas Docker Hub est la seule source dont vous avez besoin.
Pour notre image en question, on trouve différentes informations :

dockerhub1.PNG.d403582f20e39fa8e1f69eeb9d0d8a70.PNG

Le tag latest correspond à la dernière version stable en date, development parle d'elle-même, vous pouvez également avoir des numéros de version spécifique, si vous ne souhaitez pas que l'image se mette à jour.
La plupart du temps, c'est la version latest qui nous intéressera. Par convention (respectée dans l'immense majorité), si le tag n'est pas précisé, on parle de la version latest.

On retourne dans l'onglet Registre, et on double-clique sur l'image une fois trouvée via le champ de recherche :

dockerhub2.thumb.PNG.2aa0e943bd7a2f12bda741b9b0be7547.PNG

On sélectionne le tag latest.

L'image se télécharge, on peut voir l'avancement dans l'onglet Image, à droite la taille que l'image occupe sur votre NAS :

dockerhub3.thumb.PNG.1f9aa6c4dfc16509b02d410abe313ea5.PNG

L'image est téléchargée, on va maintenant pouvoir créer le conteneur.

Paramétrage du Conteneur

On va donc créer notre conteneur, ce sera la version exécutée de notre image. Pour en créer un, il suffit de double-cliquer sur l'image qu'on a fini de télécharger :

conteneur1.PNG.c2d2f1e38259a546ccf87460d7fe713d.PNG

Un nom nous est proposé par défaut, on peut évidemment le modifier pour quelque chose de plus simple.
On laisse décocher Exécuter le conteneur à l'aide de privilèges élevés car cela revient à donner un accès root au conteneur, sauf cas très précis c'est déconseillé. C'est une des rares options dans Docker qui peut compromettre l'intégrité de votre NAS si mal utilisée. Si un tutoriel demande à cocher cette option, prenez le temps de comprendre pourquoi et vous demander si c'est vraiment utile.

On peut limiter la quantité de mémoire que le conteneur utilisera pour s'exécuter.
On clique ensuite sur Paramètres avancés pour poursuivre la configuration du conteneur.

Conditions d'exécution

conteneur2.PNG.68834867bc88e309d28836daab8d4c65.PNG

En cas d'arrêt inopportun du NAS ou du paquet Docker, on peut autoriser le redémarrage automatique, suivant l'application concernée c'est généralement un paramètre intéressant, on le coche donc.
On peut créer un raccourci sur le bureau si on le souhaite. D'autres comportements que le redémarrage automatique sont disponibles mais à ma connaissance, non sélectionnables via l'interface graphique Docker de DSM.

Volumes

Un conteneur, lorsqu'il est créé, écrit des données sur votre NAS. Par défaut, si rien n'est précisé, les données seront écrites dans des dossiers cachés relativement peu exploitables. Lorsqu'on supprime un conteneur, les données y affairant sont également supprimées. C'est un gros avantage de Docker, rien n'est éparpillé et ne viendra polluer DSM ou votre stockage. En revanche, en cas de suppression involontaire ou d'un bug nécessitant la recréation du conteneur, il est très vite arrivé d'en perdre toute la configuration.
Le montage d'un volume permet de s'affranchir de ces limitations en localisant des données (dossiers ou fichiers) à un endroit précis du NAS. Outre l'accessibilité rendue aisée, ces données ne disparaîtront pas lors de la suppression du conteneur, ou même de l'image dont il est tiré, on parle de données persistantes.
A l'instar de tout système d'exploitation, il est tout à fait possible d'explorer l’arborescence d'un conteneur comme on le ferait pour notre NAS ou n'importe quelle autre machine.
Ci-dessous, l’arborescence à la racine du NAS (à gauche) et l'arborescence du conteneur (à droite).
 

conteneur4.PNG.239295ddd45620f1cbc7b89b022a1212.PNG     conteneur5.PNG.114c2bea4fbbb26e06ddd1e467aad784.PNG

Reprenons les directives du créateur de l'image :

dockerhub4.PNG.b1294d1893baa94c1d63b807f9cbefed.PNG

On s'intéresse aux paramètres précédés d'un -v, ici on nous dit que /config (chemin dans le conteneur, que les plus observateurs auront vu dans l'arborescence du conteneur sur l'image de droite un peu plus haut) peut être monté vers le NAS si on souhaite faire persister les données (on le veut dans ce cas, on n'a pas envie de tout reconfigurer à chaque redémarrage du conteneur).
On va donc dans l'onglet Volume :

conteneur3.PNG.80e82837e35c999ab517833bb7b4ea16.PNG

Et on clique sur Ajouter un dossier.
On est alors amené à choisir le dossier dans lequel on va monter /config.
Par commodité, j'ai créé un dossier partagé docker dans lequel je crée un dossier pour chaque conteneur, libre à vous de vous organiser de la manière qui vous conviendra le mieux.
Je choisis mon dossier et valide :

conteneur7.PNG.05cbfa8db6abaf5c7b1d3c3565f29931.PNG

Dans la colonne Chemin d'accès, je suis venu écrire manuellement le chemin absolu du dossier à monter.

Réseau

Pour l'accessibilité du tutoriel, je ne mentionne dans cette partie que deux types de réseau : le mode bridge (défaut) et le mode host. Le fonctionnement avancé des réseaux faisant l'objet d'une description plus exhaustive en fin de tutoriel pour ceux que ça intéresse.
Par défaut, le mode bridge est sélectionné. Dans ce mode, lorsqu'un conteneur est créé, il obtient une adresse IP privée libre dans le sous-réseau 172.17.0.0/24. La passerelle de ce conteneur sera toujours 172.17.0.1, qui est une des nouvelles interfaces du NAS (consécutivement à l'installation de Docker). Pour s'en assurer, connectez-vous en SSH sur votre NAS et tapez :

ifconfig

Vous verrez une interface docker0 avec l'IP 172.17.0.1, c'est la porte vers le monde extérieur (LAN + WAN) pour tous les conteneurs dans le réseau bridge 172.17.0.0/24
En mode bridge, si les ports ne sont pas translatés de la passerelle (le NAS) vers le conteneur, le conteneur n'est pas accessible depuis votre réseau local (hormis le NAS). On a un fonctionnement similaire à un routeur auquel on dit de translater certains ports vers une machine de notre réseau pour y accéder de l'extérieur.

Le mode host permet lui d'exposer directement le conteneur sur le NAS, à la manière de n'importe quel paquet Synology. En gardant l'avantage de conserver les dépendances en son sein et de ne pas impacter le système d'exploitation. Il n'y a dans ce cas aucune redirection de ports à effectuer, ils sont directement joignables sur l'IP du NAS (sous réserve que le pare-feu l'autorise).

Dans l'onglet Réseau, on va donc laisser tel quel pour rester en mode bridge :

conteneur8.PNG.e6ce8cb9681e1e4b272c2476bd316370.PNG

Si on veut passer en mode host, il faut cocher l'option Utiliser le même réseau que Docker host.

On notera en dernier lieu qu'il est possible par l'intermédiaire du "+" de créer des réseaux bridge différents de celui par défaut, cela peut avoir un certain intérêt lorsqu'on souhaite faire communiquer des conteneurs entre eux (voir fin du tutoriel).

Ports

Si on a choisi le mode bridge, Docker liste par défaut les différents ports qu'utilise le conteneur, en proposant la valeur Auto pour le port du NAS. Si vous laissez Auto, alors un port libre aléatoire sera choisi par le système. Dans l'extrême majorité des cas, on préfère définir nous même les ports à exposer, il faut simplement s'assurer qu'ils ne sont pas déjà en cours d'utilisation par un autre service (auquel cas DSM nous préviendra au moment de valider le choix des ports). On aurait pu garder les mêmes ports que dans le conteneur, mais dans le cas présent, 80 est le port utilisé par Web Station, et 443 peut servir pour la mise en place d'un proxy inversé, donc j'ai préféré en choisir d'autres qui, eux, sont libres :

conteneur9.PNG.1136a7620a68cf676289d0123a66d51e.PNG

Note : Lorsque la documentation ne précise pas le protocole du transport des données par le dit port, c'est TCP qui est concerné.

Si on a choisi le mode host, on n'a pas besoin de faire de redirection de ports (voir partie précédente)

Liens

Les liens permettent de connecter plusieurs conteneurs entre eux, dans la partie de gauche on choisit un autre conteneur, dans la partie de droite un alias, qui permettra de personnaliser des variables d'environnement dans le conteneur lié.
Cette fonctionnalité étant dépréciée, je ne m'étendrai pas plus dessus, voir le chapitre Réseau en fin de tutoriel pour une méthode alternative.

conteneur13.PNG.385249897bd4d9b1ee8f92a28512edf6.PNG

Variables d'environnement

dockerhub4.PNG.b1294d1893baa94c1d63b807f9cbefed.PNG

Elles permettent de personnaliser le conteneur pour notre utilisation personnelle. Dans l'image ci-dessus, elles sont identifiées par le -e, on en identifie donc trois : PUID, PGID et TZ

Dans l'onglet correspondant, je crée ces trois variables en utilisant le "+" en haut à gauche du cadre :

conteneur10.PNG.771e3565e210b97b9f3831beac131a21.PNG

Concernant les variables PUID et PGID, elles vont permettre de définir l'utilisateur du NAS qui exécutera le conteneur. On les retrouve par exemple, mais pas seulement, dans toutes les images Linuxserver, qui est un collectif de développeurs réalisant le portage d'applications phares vers des images Docker standardisées et surtout NAS friendly. Lorsque vous cherchez une application, je vous conseille en premier lieu d'aller jeter un oeil à la liste de leur releases, les ajouts sont fréquents et les mises à jour encore plus.
Pour connaître les valeurs numériques à entrer, il faut se connecter en SSH sur le NAS, et taper :

id user

user étant l'utilisateur qu'on souhaite employer. On obtient plusieurs valeurs, un UID >= 1026, un GID = 100 ou plus, d'autres valeurs de GID dont on ne se servira pas ici.
On fait correspondre le PUID au UID et le PGID au GID.

Il faut également remplir deux autres conditions pour ne pas avoir de problème de permissions d'écriture dans nos volumes :

  1. que l'utilisateur choisi a des droits suffisants dans les dossiers partagés qui seront utilisés, dans mon cas le dossier partagé docker
  2. que l'utilisateur soit idéalement propriétaire du dossier heimdall, dans lequel j'ai décidé de monter /config du conteneur.

Ces conditions sont très importantes pour que tout fonctionne sans accroc.

Pour TZ, c'est une variable permettant de définir le fuseau horaire à l'intérieur du conteneur, vous pouvez trouver sur cette page une liste des valeurs à entrer suivant votre localisation.

Création du conteneur

On valide les Paramètres avancés, et on clique sur Suivant, un dernier écran propose un récapitulatif de la configuration du conteneur, on applique.

conteneur12.thumb.PNG.d233f52fef6efbca26e6a590129a5701.PNG

On peut vérifier dans l'onglet Conteneur que le conteneur est en cours d'exécution.
Il ne reste plus qu'à aller sur notre navigateur et entrer l'adresse du NAS suivi du port HTTP qu'on a translaté depuis le conteneur vers le NAS :

application_http.thumb.PNG.4a44e98e96828a928439a27356dbebad.PNG

Et pour la version HTTPS :

application_https.thumb.PNG.9cf0c2205c1e85298eabf49fbf37f2f4.PNG

Aperçu et Logs du conteneur

Dans notre cas c'est merveilleux tout marche bien, mais il faut savoir que toutes les images ne sont pas aussi bien documentées, et qu'on n'est jamais à l'abri d'une erreur. Dans l'onglet Conteneur, si on en sélectionne un et qu'on clique sur Détail, on peut avoir un aperçu des statistiques du conteneur, et surtout les logs du conteneur dans l'onglet Journal, c'est la première chose à regarder en cas de conteneur non fonctionnel (accès impossible, redémarrage en boucle, etc...).

________________________________________

Ceci conclut la partie destinée à l'interface Docker de DSM, elle conviendra pour la majorité de vos besoins mais peut clairement révéler des insuffisances dans des cas plus poussés.

Docker via SSH

Un des principaux problèmes qu'on peut rencontrer avec l'interface de DSM c'est l'impossibilité de choisir des dossiers sur le NAS en dehors de /volume1, or Docker s'appuyant sur le système d'exploitation de l'hôte, il peut avoir besoin d'accéder à ses ressources.
il est possible de contourner ce problème avec l'interface DSM de Docker via des liens symboliques (symlink) mais je trouve ça plus personnellement plus compliqué qu'un bête script.
Par chance, pour les images comportant peu d'infos, il y a souvent a minima le script de démarrage du conteneur, exemple avec l'image utilisée ci-avant :

docker_ssh1.PNG.f06256faa74f770ebc2e71252d23e21c.PNG

On comprend assez vite la correspondance entre ce qu'on a fait précédemment et ce qu'on lit ici, quelques remarques tout de même :

  • les \ permettent d'effectuer un retour à la ligne et de rendre le script présentable, il est tout à fait possible d'écrire tout à la suite.
  • si j'écris -p 8080:80, je demande de faire correspondre le port 8080 de l'hôte avec le port 80 du conteneur, l'ordre est donc primordial.
  • de la même manière qu'on peut mapper les ports, on peut mapper les volumes : /volume1/docker/heimdall est ici mon dossier sur le NAS, /config mon dossier dans le conteneur, j'écrirai donc ça : -v /volume1/docker/heimdall:/config
  • on voit qu'ici il est possible de définir un autre type de comportement pour le redémarrage (celui qu'on avait validé dans l'interface correspondant à --restart always), ici on empêche le redémarrage automatique si le conteneur a été stoppé correctement.
  • la dernière ligne reprend le nom de l'image, si aucun tag n'est précisé alors latest est implicite.
  • il n'est pas nécessaire de télécharger l'image au préalable, au lancement du script il va aller chercher la version la plus récente du tag demandé, la re-télécharger si l'image est obsolète et enchaîner sur la création du conteneur.
  • il faut ajouter sudo en début de commande si on n'est pas connecté en root au terminal.

Cette commande permet de créer le conteneur, on doit ensuite taper :

docker start heimdall

pour exécuter le conteneur (pensez à ajouter sudo aux commandes docker si vous n'êtes pas connecté en root).
Assez intuitivement, pour arrêter le conteneur on tape :

docker stop heimdall

Pour supprimer le conteneur :

docker rm heimdall

Pour voir la liste des conteneurs actifs, on écrit la commande :

docker ps

Pour voir les logs d'un conteneur en direct, on écrit (CTRL+C pour arrêter la visualisation) :

docker logs -f heimdall

Pour gérer les réseaux, reportez-vous à l'aide via la commande :

docker network --help

Enfin, ça peut être parfois très utile, il est possible de se connecter à l'intérieur d'un conteneur, pour cela :

docker exec -it heimdall bash

Notes :

  • En général, le paquet bash est présent dans la plupart des images que vous utiliserez. Parfois, si bash ne fonctionne pas, essayez ash.
  • Si bash n'est pas disponible, rien ne vous empêche de taper directement la commande qui vous intéresse, par exemple :
    docker exec -it heimdall ls -la /etc
  • Pour sortir du conteneur, tapez exit.

A vous d'explorer l'ensemble des commandes à votre disposition en consultant le manuel d'aide :

docker --help

En dernier lieu, je vous invite à parcourir la documentation de Docker,  bien que touffue elle est extrêmement claire : https://docs.docker.com/

Comme je disais au début du chapitre, le gros avantage de cette méthode est qu'elle permet de définir des chemins absolus hors /volume1 pour nos volumes. Rien ne m'empêcherait d'aller mapper /var/lib/temperature pour un dossier quelconque du conteneur.
Cette possibilité est particulièrement utile quand une application va devoir utiliser le cœur de docker, le fichier /var/run/docker.sock. Ce fichier est particulièrement important, car à partir du moment où on le mappe en tant que volume vers un conteneur, on peut prendre le contrôle de Docker avec cette application. Typiquement, Portainer est une interface graphique à la manière de l'interface Docker de DSM pour gérer ses conteneurs, ses images, et toutes les infos exploitables (mais en mieux 😛).
Avertissement !!
A partir du moment où vous donnez accès à d'autres dossiers que ceux dans /volume1, le conteneur sera nécessairement lancé avec l'utilsateur root du NAS, car seul lui a accès à cette partie du système. Soyez donc attentifs aux nécessaires précautions que cela implique.

Docker-compose via SSH

Docker-compose vient compenser les lacunes de la création de conteneur par Docker :
docker-compose_ssh1.PNG.5c4f700941d93adf7cabaa9705cbb9c4.PNG

Ça permet entre autre d'adopter une forme plus analytique et donc plus lisible, on peut également définir plusieurs "services" (voir image ci-dessus) au sein d'un même fichier docker-compose.yml
Concrètement, je pourrais vouloir créer un fichier docker-compose reprenant trois services : une application, une base de données, un client syslog. Aucun des trois n'a vocation à fonctionner seul, il est donc pratique de les réunir vu qu'ils forment une entité à part entière. Je pourrais également définir directement des réseaux dans ce fichier, et que ceux-ci soient créés de manière concomitante à la création des conteneurs.
Il suffit de placer ce fichier dans un dossier, d'en faire le répertoire de travail dans son terminal, et de taper :

docker-compose up -d

Si je souhaite supprimer les conteneurs (et les éventuels réseaux définis dans le fichier), il me suffit de taper :

docker-compose down

Ça a également l'avantage de garder la configuration du conteneur au sein d'un fichier.

Ce fichier docker-compose.yml peut être créé par Notepad++ sous Windows, ou via l'éditeur de texte sous Linux.
Attention !! le fichier ne doit pas contenir de tabulation, tous les décalages sont réalisés à partir d'espace !!

Plus d'infos sur Docker-compose à cette page.

Quelques autres commandes utiles

docker stats

Affiche les ressources utilisées par vos conteneurs, se rafraîchit constamment.

docker network inspect <nom_du_réseau>

Permet d'avoir toutes les informations relatives à un réseau donné.

docker rmi <nom_image>

Permet de supprimer l'image avec le nom spécifié.

Informations complémentaires

Réseaux

Le mode bridge par défaut (c'est-à-dire si on utilise le driver bridge, et qu'on ne rattache le conteneur à aucun réseau bridge particulier) n'est pas idéal si l'on souhaite isoler les conteneurs les uns des autres. Tous les conteneurs appartenant au réseau bridge par défaut peuvent communiquer les uns avec les autres par leur IP, et se situent sur un même sous-réseau (par exemple 172.17.0.0).
Si on souhaite s'affranchir des adresses IP (qui peuvent changer entre chaque création et suppression de conteneur) et utiliser plutôt le nom du conteneur pour communiquer avec, il existe deux méthodes :

  1. Les liens (évoqués plus avant) : c'est une fonctionnalité officiellement dépréciée dans les nouvelles versions de Docker, elle est cependant présente dans l'inteface Docker de DSM, dans l'onglet Lien lorsqu'on crée ou modifie un conteneur. En précisant le nom d'un autre conteneur, on autorise la communication notre conteneur en devenir et celui-ci.
  2. Les réseaux bridge définis par l'utilisateur : la commande docker network permet de gérer les réseaux docker et donc d'en créer de nouveaux. Lorsqu'on crée un réseau bridge, celui-ci aura la propriété intrinsèque que tous les conteneurs qui y sont connectés pourront communiquer entre eux via leurs noms de conteneur.
    Le réseau 172.17.0.0/24 étant réservé au réseau bridge par défaut, le premier réseau disponible est le 172.18.0.0/24, et ce jusqu'à 172.32.0.0/24.
    Un réseau de type bridge créé dans l'interface Docker de DSM est un réseau de cette catégorie.

Il existe un autre type de réseau appelé macvlan : il permet de donner une IP sur le réseau physique à un conteneur, donc par exemple 192.168.0.0/24, et sera donc directement accessible par les autres périphériques de votre réseau local.
Merci à @bruno78 pour son apport sur ce sujet en particulier, la suite est très largement inspirée de ses commentaires, et @Didier3L dont les questions ont permis de défricher le terrain.

Ce driver possède de gros avantages et un gros défaut :

  • Si le conteneur a une IP sur le réseau physique, elle est directement accessible via tous ses ports. C'est excessivement pratique si certaines applications de l'hôte, ici le NAS, utilisent déjà certains ports : 80, 443, 53, etc...
    Prenez l'exemple parlant de Pihole, ce dernier utilise le port 80 pour plusieurs tâches, ainsi que le port 53 qui est le port DNS non sécurisé.
    Si vous utilisez le paquet DNS Server du NAS, le port 53 est déjà en écoute, pareil avec le port 80 si Webstation est exécuté.
    Nous avons précédemment vu qu'il était possible de translater, sauf que certains ports comme le port 53 ne sont pas réellement déplaçables sur un autre port.
  • Je n'ai donc aucune redirection à faire, j'accéderai à mon application via par exemple 192.168.0.101:80, tout simplement, sans me soucier de ce que le NAS utilise.
  • Attention cependant, en macvlan, l'hôte ne peut plus communiquer, via son interface physique, avec le conteneur !! Ce n'est pas gênant dans le cas du contrôleur Unifi d'Ubiquity, mais beaucoup plus dans le cas de Pihole par exemple.

Pour créer un réseau macvlan, on peut le créer de manière externe, via docker network via ligne de commande ou de manière interne lors de l'écriture d'un script ou dans un fichier docker-compose.
Dans ce cas, on va créer le réseau macvlan toto de façon externe :

docker network create -d macvlan \
--subnet=192.168.0.0/24 \
--ip-range=192.168.0.144/28 \
--gateway=192.168.0.254 \
-o parent=ovs_eth0 \
toto

Notes : (les valeurs sont données à titre d'exemple évidemment)
 - subnet => on choisit le sous-réseau physique, celui de nos machines.
 - ip-range => on va définir la plage d'IP couverte par le réseau, un calculateur d'IP sera d'une grande aide pour définir le nombre d'IP qu'on réserve et ajuster à notre besoin.
Important !! Il est fortement recommandé que la plage d'IP couverte par le serveur DHCP de votre réseau soit dissociée de la plage d'IP allouée au réseau macvlan.
 - gateway => c'est notre passerelle, vu qu'on est sur le réseau physique c'est généralement votre box ou votre routeur.
 - parent => c'est le nom de l'interface physique (tapez ifconfig pour vérifier)

On valide et notre réseau est créé.
Maintenant, il reste un problème à résoudre ; comme évoqué plus haut, tout conteneur dans ce réseau ne sera pas joignable par l'hôte, quelque soit le protocole (ICMP, TCP, UDP, HTTP, etc...)

Une solution existe toutefois, il suffit de créer une nouvelle interface sur le NAS, une interface virtuelle, par lequel il sera aussi normalement accessible que par son interface physique.
Pour illustrer, si j'accède à DSM via 192.168.0.100:5000 en temps normal, je pourrai créer une interface avec l'IP 192.168.0.140 tel que DSM sera également accessible à l'adresse 192.168.0.200:5000
Le conteneur pourra donc communiquer avec le NAS via cette nouvelle interface.

Pour cela, il suffit de taper quelques lignes de commande en SSH :

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>

Si on veut faire correspondre à l'exemple du réseau ci-dessus :

 - <nom_interface_macvlan> => un nom au hasard, pas de caractères spéciaux, macvlan_int par exemple, peu importe
 - <interface_physique> => ovs_eth0
 - <IP_virtuelle> => on avait choisi arbitrairement l'adresse 192.168.0.140, on vérifie que cette IP n'est pas dans la plage couverte par le réseau macvlan toto
 - <adresse MAC> => on peut définir une adresse MAC pour notre interface
 - <Plage_DHCP_réseau_macvlan> => ça correspond à --ip-range dans le script plus haut

Vous devriez maintenant avoir maintenant une nouvelle interface visible en tapant ifconfig en SSH. Vous verrez également cette interface sur l'assistant Synology par exemple. Si vous tentez un ping depuis votre NAS vers un conteneur sur le réseau macvlan, cela devrait marcher.
Inconvénient majeur : Au reboot, l'interface sera supprimée et le code précédent devra être réintroduit. Pour éviter cela, on peut créer une tâche dans le planificateur de tâches, à exécuter au démarrage du NAS, qui exécute un script comprenant toutes les commandes ci-dessus (celles commençant par IP). On peut également ajouter un sleep 60 pour temporiser 60 secondes avant l'exécution du script, on s'assure ainsi que la machine a bien démarré avant toute chose.

En dernier lieu, il existe un driver dhcp, qui se comporte vraiment comme un périphérique physique, dans le sens où, contrairement au driver macvlan où la plage d'IP est pré-déterminée, le conteneur ira chercher son IP auprès du serveur DHCP du réseau, très probablement la box ou le routeur. On a donc les avantages du driver macvlan sans les inconvénients. Ce driver reste toutefois à l'heure actuelle à l'état de beta, mais affaire à suivre...

MàJ : 23/05/2020

Modifié par .Shad.
Ajout commandes utiles

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci @.Shad. pour cet excellent tuto qui manquait cruellement à la panoplie du site.

Désormais, ceux qui sont intéressés par Docker (moi y compris lorsque j'aurai un nas de production compatible), pourront aborder plus sereinement le sujet.

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour

Merci pour cet excellent  tuto , pour test j' ai pris le paquet  heimdall/server mais impossible a ouvrir en http , j'ai une page qui s'ouvre avec une erreur , je pense que c'est lié aux permissions

J' ai un accès complet au dossier heimdall/config , ?? , sur un forum php il parle de mettre la permission sur fichier : sudo chmod -Rf 0777 mais ou je ne sais pas....

  1. *
  2. * @param string $path
  3. * @return string
  4. */
  5. public function hash($path)
  6. {
  7. return md5_file($path);
  8. }
  9.  
  10. /**
  11. * Write the contents of a file.
  12. *
  13. * @param string $path
  14. * @param string $contents
  15. * @param bool $lock
  16. * @return int
  17. */
  18. public function put($path, $contents, $lock = false)
  19. {
  20. return file_put_contents($path, $contents, $lock ? LOCK_EX : 0);
  21. }
  22.  
  23. /**
  24. * Write the contents of a file, replacing it atomically if it already exists.
  25. *
  26. * @param string $path
  27. * @param string $content
  28. * @return void
  29. */
  30. public function replace($path, $content)
  31. {
  32. // If the path already exists and is a symlink, get the real path...
  33. clearstatcache(true, $path);
  34.  
  35. $path = realpath($path) ?: $path;
  36.  
  37. $tempPath = tempnam(dirname($path), basename($path));
  38.  
  39. // Fix permissions of tempPath because `tempnam()` creates it with permissions set to 0600...
  40. chmod($tempPath, 0777 - umask());
Arguments
  1. "file_put_contents(/var/www/localhost/heimdall/storage/framework/views/6e20ab287578f40c9d75e1ed674de8d70913e45a.php): failed to open stream: Permission denied"
    
Modifié par Pascalou59

Partager ce message


Lien à poster
Partager sur d’autres sites

Salut,

L'image dont tu parles n'existe pas, tu voulais parler de celle du tutoriel ?
Quelle erreur ?
Est-ce que les ports bien accessibles ?

Ce que tu as mis comme extrait de log correspond à quoi ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour @.Shad.

vu le nom on dirait bien que c'est la meme  image que le tuto . J' ai aussi suivi cette vidéo youtube  https://www.youtube.com/watch?v=Kn7Vw5de2gA

c' était juste pour tester docker et une image.

200121072612747738.png

 

Mon soucis avec docker , je suis fraichement arrivé dans ce domaine il a 15 jours , je n' ai pas encore réussi a afficher une page http(s) , j' ai testé une autre image ...pour la citer  ( jacobalberty/unifi ) . Il y a des  video youtube  pour cette image . Je dois louper quelque chose , j' ouvre bien les ports , je met le PUI et GUID qui correspond a mon ID..... https://192.168.0.X:8443 ou 8080 etc ...la page que vous demandez est inaccessible...

 

Modifié par Pascalou59

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonsoir @.Shad.

J' ai enfin reussi a faire tourner l' image jacobalberty/unifi  , et c'est bien moi qui a Mer...👁️‍🗨️, je n' avais pas coché dans onglet réseau une case tout en bas , en tout cas c'est nickel pour ma borne Ubitiqui et la visu globale des appareils connectés

Modifié par Pascalou59

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour @.Shad.

En préambule, je voulais te remercier pour ce tuto. 😉
Il a le mérite de démocratiser et comprendre encore mieux l’utilisation de Docker.

Car il faut bien le dire, son utilisation est bien loin d’être évidente même avec l’interface graphique de Synology.

Pour ma part, j’utilise Docker via le paquet de Synology pour faire tourner Jeedom. https://www.jeedom.com/site/fr/soft.html

Jeedom est une application domotique très ouverte grâce notamment à l’installation de plugin.
Cette application s’installe sur un Raspberry ou en Docker

Son utilisation en mode Docker impose des points particuliers :

Des droits SUDO et une écoute en mode Broadcast

  • Le point « Broadcast » sera résolu en configurant le container en mode Host.

  • Mais le point « SUDO » devra faire l’objet d’une modification système Linux du container.
    Ce point revient régulièrement sur des forums avec d’autres utilisation de container

Pour détailler mes propos et aider nos amis utilisateurs de jeedom, j’ai réalisé un tuto
https://community.jeedom.com/t/tuto-installation-de-jeedom-sur-synology-avec-docker-en-mode-host/5290

L’installation est 100% opérationnelle. 😀
Mais tout n’est pas parfait

L’accès en SSH via Putty est impossible ! 😪 seul l’utilisation du terminal du paquet Docker est possible 😬

Et surtout de devoir modifier le système avec une version de Debian que celle officielle

Enfin concernant le PUID et GUID, j’ai mon PGID = 101 et PUID = 0, alors que je vois régulièrement des valeurs à 1000 dans des tutos.

Si tu as le temps de regarder cela, je t’en remercierais grandement  👍

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)

Salut,

Moi je serais parti comme la première réponse à ton tutoriel sur un conteneur en réseau macvlan (donc sur le réseau physique).
En créant un réseau intermédiaire pour permettre au NAS de communiquer avec le conteneur.

Mais pour jeedom en particulier, je pense qu'il est préférable de passer par une machine virtuelle, tu peux la mettre en pause contrairement à un conteneur, tu peux également ajouter tous les plugins que tu veux sans devoir toucher au DockerFile, il est aussi très facile d'ajouter toutes les dépendances que tu veux...

De plus sûr, je pense que les plugins dont parle ton interlocuteur dans sa réponse (tutoriel) n'auront aucun problème avec une marchine virtuelle, placée sur le réseau physique.

PS : pour les uid/gid, 1000/1000 est le tandem de tout utilisateur linux standard créée à la mise en route de l'OS. Sur un Synology, le premier uid disponible est 1026, le groupe users c'est 100 et administrators c'est 101.
root c'est 0/0.
Je ne sais pas d'où sort ton 101 du coup ?

Pour connaître l'uid d'un utilisateur, tu tapes "id" connecté en SSH pour l'utilisateur en cours, ou "id user" pour un user déterminé.

Modifié par .Shad.

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonsoir

Merci pour ton analyse

Je vais regarder ce que je peux faire avec macvlan

pour les uid/gid, je pense que je me suis trompé !
j'ai récupéré les infos dans le système Jeedom au lieu du système Synology 🤪

image.png.56ef6b8fd374177ca722cf466f54a475.png

Avec mon nom utilisateur admin du Synology j'ai UID 1032 / GID 101

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour @.Shad.

J’ai regardé pour le réseau macvlan.

J’ai suivi un tuto qui permet de créer un réseau macvlan à l’aide de portainer

https://www.portainer.io/2018/09/using-macvlan-portainer-io/

Point 1 :
Si j’ai bien compris on doit attacher le réseau macvlan au réseau de l’hôte
Mon hôte est bien mon Synology ?
J’ai plusieurs réseaux et je ne sais pas lequel prendre ?

StrokesPlus_4Wi6RcNPqB.thumb.png.269268f8575f8858f3a7aeb89072afd7.png

Point 2 et 3 :


Je mets exactement la même chose ?

Point 4 :


C’est l’adresse IP du Synology (192.168.1.10) ?

StrokesPlus_un5LgqhSw1.thumb.png.1b05cd35c1c348e84160fdc74bd6165e.png

Voici la configuration de mon réseau de Synology

StrokesPlus_gIiDSHw3Qx.png.ed0893c0312b20309dd915724eb292c0.png

 

 

StrokesPlus_un5LgqhSw1.png

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)

Le lien en question dit juste comment créer un réseau macvlan, et même si j'adore Portainer et que je m'en sers souvent, je ne trouve pas leur méthode plus simple, c'est vraiment équivalent en terme de temps en ligne de commande.

L'interface qui t'intéresse c'est ovs_etho, tu peux voir que l'adresse IP physique de ton NAS lui est attribuée. Moi j'ai utilisé ce guide-là, qui lui traite de la manière de faire communiquer l'hôte (le Synology), avec tous les conteneurs présents dans le réseau macvlan avec lesquels, sans rien faire, ton NAS ne pourra communiquer.

L'inconvénient c'est qu'au reboot du NAS, il faut refaire le lien entre l'interface et le réseau intermédiaire.
Je pense qu'en allant fouiller dans /etc/sysconfig/network-scripts/ il y a moyen de réactiver l'interface au démarrage, mais n'ayant jamais eu besoin que mes hôtes communiquent avec leur conteneur sur réseau macvlan, je ne m'y suis jamais aventuré.

Quoiqu'il en soit, dans ce commentaire, kevindd992002 attire l'attention de l'OP sur un problème qu'il a rencontré sur son Syno.

Après mon NAS je le reboot p-e trois fois par an, donc faire un petit script avec la manipulation peut rendre cet inconvénient trivial si c'est aussi ton cas.

PS : Sur le principe cela dit ça me semble bon, dans ton cas je ne sais pas si tu es passé en swarm par rapport aux impressions du tutoriel que tu as suivi, c'est tout à fait faisable avec docker en standalone (classique). A partir du moment où tu ajouteras un conteneur à ton réseau mymacvlanconfig, , il ira chercher une IP disponible disponible l'IP range, attention ici il n'y en a qu'une de disponible avec le CIDR que tu as précisé (192.168.1.80).
Par contre, la chose primordiale est de t'assurer que cette IP est en dehors de la plage d'attribution des IP du serveur DHCP sur ton réseau, et que l'IP n'est pas déjà prise/réservée.

Modifié par .Shad.

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)

Bonsoir @.Shad.

Je ne sais pas ce que c'est swarn ... j'ai déja du mal avec docker
C'est pour ça que j'utilise des outils "simple" comme portainer

J'ai créé un réseau macvlan et mon conteneur jeedom-test est connecté.

Sauf que quand je vais à l'adresse 192.168.1.60 j'ai l'erreur Le serveur à l’adresse 192.168.1.60 met trop de temps à répondre.
et en bridge 192.168.1.10:9082 j'ai SQLSTATE[HY000] [2002] No route to host

 

StrokesPlus_qeh7rHwkoO.png

Ensuite à force de faire mu-muse je ne peux supprimer les deux réseaux mymacvlanconfig
J'ai tout essayé 🤬

J'ai pourtant aucun conteneur de connecté sur ces deux réseaux

StrokesPlus_cY5PrWFaqY.png

image.png.ee5d2544a8de9fbe651e1a38eee8819a.png

image.png.17860548904d68186205b971daec9712.png

Et pour finir, j'ai toujours une erreur si je lance pas les conteneurs dans le bon ordre

Sinon j'ai l'erreur Start container jeedom-test failed: {"message":"cgroups: cannot find cgroup mount destination: unknown"}.

Bref, macvlan c'est pas si simple ....

 

Modifié par Didier3L

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)

Bonjour @Didier3L, à propos de macvlan :

  • supprimer des réseaux : il faut donner le nom (NAME) du réseau que tu veux supprimer, pas son Id (NETWORK ID)
    • par exemple : # docker network rm mymacvlanconfig
  • il faut définir la bonne plage d'adresse pour ton réseau macvlan
    • ici tu donnes 192.168.1.60/24 : c'est incohérent.
    • mettons que tu aies besoin de 3 ou 4 adresses sur ton macvlan, alors tu vas définir en réseau en /29 : 8 adresses IP, dont celle du réseau et celle de broadcast. Donc 6 adresses IP unicast utilisables.
    • Cette plage d'adresses doit être en dehors de ta plage DHCP pour éviter les adresses dupliquées sur le réseau
    • Par exemple, tu peux les placer en fin de plage réseau :
      • réseau macvlan : 192.168.1.240/29
      • ca veut dire :
        • adresse réseau : 192.168.1.240
        • adresses IPv4 unicast utilisables pour les dockers : 192.168.1.241 à 192.168.1.246
        • adresse de braodcast sur ton réseau macvlan : 192.168.1.247
      • tu pourras donc allouer aux dockers que tu configures sur ce macvlan les adresses de 192.168.1.241 à 192.168.1.246
  • enfin il faut permettre au réseau macvlan de communiquer avec le reste de ton environnement :
    • il faut donc rajouter une interface logique sur le NAS et ajouter le routage associé. Le faire patr un script qui sera lancé automatiquement au demarrage du NAS.
    • par exemple dans ce cas : (mon script adapté à ton réseau et adresses ci-dessus. A corriger en fonction de chaque environement). Attention, on consomme une premiere adresse pour cette interface (192.168.1.241)

#!/bin/sh
# Created on October 17, 2019, by Bruno78
# http://tonylawrence.com/posts/unix/synology/free-your-synology-ports/
#
# mis à jour 24 janvier 2020
# definition d'un subnet complet /29 pour pouvoir rattacher plusieurs container docker
#
# creation non persistante
# a relancer a chaque demarrage du NAS

#Set timeout to wait host network is up and running

sleep 60

#Host macvlan bridge recreate

ip link add bridgemacvlan link ovs_eth0 type macvlan  mode bridge
ip addr add 192.168.1.241/32 dev bridgemacvlan
# address MAC. cf https://www.cyberciti.biz/faq/linux-ip-command-examples-usage-syntax
# il faut que le premier octet soit PAIR
# cela permet d'avoir a chaque redemarrage la meme addr MAC, sinon elle change
ip link set dev bridgemacvlan address 0:1:2:3:4:5
ip link set bridgemacvlan up
#
ip route add 192.168.1.240/29 dev bridgemacvlan

Voilà 🙂

J'espère ne pas avoir été trop confus dans ces explications. Ceci dit, j'ai mis un petit moment avant de le faire fonctionner et de regrouper toutes les données et informations nécessaires. Donc si ça peut servir .

Si problème, n'hésites pas à nous faire part de tes avancées. Pour info, moi je l'ai mis en place pour un docker PiHole pour lequel j'avais besoin de conserver les ports standards, tout en ayant le paquet Syno DNS également actif.

Bruno78

 

Modifié par bruno78

Partager ce message


Lien à poster
Partager sur d’autres sites

@bruno78

Pour s'assurer que l'adresse 192.168.1.241 ne soit pas attribué par le réseau macvlan à un conteneur, il peut ajouter l'option suivante lors de la création du réseau :

--aux-address 'host=192.168.1.241' 

Ainsi l'adresse est réservée, pas de risque de conflit.

@Didier3L

Beaucoup de choses à assimiler, je suis en congé demain j'essaierai de t'aider si tu ne t'en sors pas. 😉 

Partager ce message


Lien à poster
Partager sur d’autres sites

@.Shad.,

oui effectivement il faut employer le --aux-address.

J'avoue qu' attribuant mes adresses IP de façon explicite via le docker-compose.yaml, je n'ai a priori pas ce genre de surprise. Je n'ai pas d'attribution automatique et incontrôlée d'adresse IP. L'adresse IP et l'adresse MAC de mes conteneurs sont inscrits dans le docker-compose.

Bruno78

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour à vous deux 😎

@bruno78

J'ai essayé également docker network rm mymacvlanconfig et cela ne fonctionne pas non plus

J'ai trouvé une solution sur un forum : 
supprimer le fichier /volume1/@docker/network/files/local-kv.db et redémarrer le NAS 😉

les deux réseaux parasites ont disparu 😀

Je vais pouvoir m'y remettre sereinement ....

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)

Concrètement et sur la base des données suivantes :

Le réseau de ma Freebox

StrokesPlus_e8grofJmBX.png.08786dfd94c510c69ccc27b3de9866d7.png

Le réseau de mon NAS

StrokesPlus_gIiDSHw3Qx.png.c823b147d029e47480cbb01d24d6786f.png

Les réseaux ifconfig du NAS

image.png.196e94e2abe8a14662708e6eb9281c38.png

 

Si je souhaite un réseau macvlan avec un accès d'adresse IP utilisables pour mes dockers : 192.168.1.240 à 192.168.1.250

Je saisi cela comment ?

docker network create --driver macvlan -- ??????????????

 

 

Modifié par Didier3L

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)

Tu peux partir sur un sous-réseau 192.168.1.240/28 ce qui donne une bloc d'IP allant de 192.168.1.240 à 192.168.1.254, si tu utilises /29 ce sera de 241 à 246. Je considère dans mon exemple que tu pars sur la première.
Ensuite, ta passerelle c'est ton routeur, donc 192.168.1.254
L'interface c'est eth0, d'après ton impression d'écran (elle possède l'IP physique du NAS).

A partir de là on va créer un réseau macvlan externe :

docker network create \
-d macvlan # --driver étant équivalent à -d
--subnet=192.168.1.0/24 \
--ip-range=192.168.1.240/28 \
--gateway=192.168.1.254 \
--aux-address="freebox=192.168.1.254" \
--aux-address="host_bridge=192.168.1.241" \
-o parent=eth0 \
mymacvlan

On a exclu une adresse pour le NAS (241) pour l'interface virtuelle permettant la communication avec les conteneurs appartenant au sous-réseau, et celle de la Freebox (254).

Lorsque tu vas créer un conteneur, il faudra ajouter la commande :

--net=mymacvlan
--ip=192.168.1.X

ou si tu utilises docker-compose :

services:
   jeedom: # par exemple
      image: ....
      ...
      ...
      networks:
         default:
            ipv4_address: 192.168.1.X

networks:
   default:
      external:
         name: mymacvlan

Ça permet :

  • de connecter le conteneur à ton réseau macvlan
  • de spécifier une IP plutôt que de la laisser être choisie arbitrairement par le réseau macvlan (X allant de 242 à 253)

A partir de là, ton conteneur sera accessible depuis le réseau physique, sauf depuis son hôte, le NAS.

Et pour pallier cela, il faut t'inspirer du script réalisé (intelligemment) par @bruno78 car chaque redémarrage supprimera le pont entre ton NAS et le conteneur cible.

Modifié par .Shad.

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonsoir,

Je n'ai pas fait le test, mais est-ce que l'on peut mettre la même adresse pour gateway et aux-address ?? Ne faudrait'il pas supprimer le --aux-address="freebox=192.168.1.254" \ ??

Partager ce message


Lien à poster
Partager sur d’autres sites
Posté(e) (modifié)
Citation

On a exclu une adresse pour le NAS (241) pour l'interface virtuelle permettant la communication avec les conteneurs appartenant au sous-réseau, et celle de la Freebox (254).

L'adresse IP de mon NAS sur le réseau de ma Freebox est 192.168.1.10

donc je lance cela ?

docker network create \
-d macvlan \
--subnet=192.168.1.0/24 \
--ip-range=192.168.1.240/29 \
--gateway=192.168.1.254 \
--aux-address="host_bridge=192.168.1.241" \
-o parent=eth0 \
mymacvlan

image.png.987b87867c332d5215fc0bfb1b5470ca.png

Modifié par Didier3L

Partager ce message


Lien à poster
Partager sur d’autres sites

L'adresse IP de ton NAS n'a pas d'importance là, le réseau est relié à ton interface eth0 c'est là que le lien s'est fait. L' adresse en 241 va servir à créer une nouvelle interface, virtuelle, sur ton NAS pour communiquer avec tes conteneurs sur le réseau macvlan, vu que c'est impossible depuis eth0.

Partager ce message


Lien à poster
Partager sur d’autres sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.