[TUTO] Docker : Introduction

[.Shad.]

 

 

1. 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.

2. Prérequis

On peut trouver la liste des modèles compatibles sur le site de Synology.

3. 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 par rapport aux versions officielles.
• DSM fournit une interface relativement claire et épurée pour Docker, mais 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.
• Corollairement, sous réserve que le paquet Docker soit implémenté correctement par Synology, les mises à jour de DSM (même majeures) ne devraient poser aucun problème de compatibilité.

4. Aller plus loin

J'ai réalisé quelques autres tutoriels sur le forum qui permettent une fois les bases acquises, de mettre en place quelques outils intéressants via Dcker, que ce soit par la réflexion que ça amène ou leur finalité, souvent les deux 😉 

• Mise à jour automatisée de ses images et conteneurs (en cours d'adaptation pour watchtower au lieu d'ouroboros) : https://www.nas-forum.com/forum/topic/63740-tuto-mise-à-jour-automatique-des-containers-docker/
• Centralisation de la gestion de plusieurs instances Docker : https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/
• Monitoring du réseau via Telegraf - InfluxDB - Grafana : https://www.nas-forum.com/forum/topic/63273-tuto-monitoring-nas-et-réseau/ (pour le monitoring de la Freebox voir le tutoriel de @bruno78 : https://www.nas-forum.com/forum/topic/66394-tuto-monitorer-sa-freebox-revolution/)
• Gestion de certificat SSL et proxy inversé : https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/
• Mise en place du serveur d'authentification Authelia : https://www.nas-forum.com/forum/topic/71875-tuto-docker-authelia-serveur-dauthentification/
• Installation de Pi-hole via réseau macvlan sur un NAS (ou tout autre périphérique) : https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/
• Utilisation de SMBv1 de manière sécurisée : https://www.nas-forum.com/forum/topic/72162-tuto-docker-smbv1/
• Audio multiroom avec Mopidy/Iris/Snapcast : https://www.nas-forum.com/forum/topic/77063-tuto-audio-multiroom-mopidyirissnapcast/

5. 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

La première peut paraître séduisante mais on est vite limité dans nos possibilités, dans les faits l'utilisation de docker-compose (qui permet une sorte de mise en forme analytique de la ligne de commande) est un excellent compromis entre de la ligne de commande pure et dure et une interface graphique. Pour ceux qui tiennent absolument à avoir une interface graphique, il peut être intéressant de s'orienter vers Portainer, dont je propose un guide d'installation dans mon tutoriel sur la centralisation des instances Docker.

6. Installation de Docker et bonnes pratiques

6-A. Installation et mise en place de Docker

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 !
Suite à une remarque de @oracle7, assurez-vous de ne pas avoir créé de dossier partagé "docker" en amont de son installation, cela peut amener à des erreurs dûes au fait que le dossier existe déjà.

Il est aussi recommandé de créer un groupe "docker" auquel on pourra ajouter des utilisateurs pour lesquels on souhaite autoriser son utilisation.

Direction DSM -> Panneau de configuration -> Groupe (ou Utilisateur & Groupe sous DSM7) -> Créer groupe.

On y ajoute les utilisateurs qu'on souhaite voir accéder au dossier partagé créé ci-avant.
On autorise également l'accès en lecture/écriture pour ce dossier.

On valide.

6-B. Recommandations

Avant de commencer le tutoriel et de télécharger vos premières images, quelques recommandations :

• Docker Hub est un centre de dépôts où la qualité des images peut très fortement varier, 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 (généralement appelé "wiki" et dont le lien est rapidement donné dans le Readme, ou la page liée 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 native (paquet DSM ou paquet Linux classique). Si pour X ou Y raisons il existe des incompatibilités avec un NAS Synology, s'il y a des problèmes de droit d'écriture (ça représente une bonne partie des difficultés qu'on peut rencontrer avec Docker sur un NAS), si les difficultés sont trop nombreuses, si la documentation fait cruellement défaut, ou encore que l'image est à l'abandon, je vous conseille d'opter pour une machine virtuelle et réaliser une installation classique. Ou déporter l'ensemble sur un Raspberry Pi par exemple. C'est du temps gagné et des cheveux épargnés. 🙂

Pour illustrer le tutoriel j'utiliserai comme exemple Heimdall, qui est une dashboard permettant de créer des liens rapidement vers ses applications via des épingles.

7. Interface de Docker dans DSM

On clique sur Docker pour arriver sur cette interface :

On peut voir l'utilisation globale 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...

L'onglet Registre est celui qui permet de télécharger les images des applications qui nous intéressent.
Ce sont les images que l'on trouve dans le dépôt publique d'images Docker, disponible ici, il peut être intéressant d'y faire un tour.

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 dédié :

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

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...)

7-A. Chronologie

La logique est la suivante :

1. On télécharge l'image d'une application qui nous intéresse. Cette image correspond à notre application, qu'on va adapter à nos besoins en 2).
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 persistante? par défaut, Docker supprime les données lorsqu'un conteneur est arrêté ou supprimé), les réseaux (liés à l'accessibilité et à la communication), etc...
3. On démarre le conteneur.

7-B. Exemple

7-B-1. 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). Il suffit de cliquer sur Paramètres puis Ajouter. Dans 99% des cas Docker Hub est la seule source dont vous avez besoin.
Pour notre image en question, on trouve différentes informations :

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 sur une version bien précise de l'image.
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 :

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 :

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

7-B-2. 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 :

Un nom nous est proposé par défaut, on peut évidemment le modifier pour quelque chose de plus simple.
On laisse décoché 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.

7-B-2-a. Conditions d'exécution

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.

7-B-2-b. Volumes

Pour utiliser une application via Docker, les données de cette application doivent bien être écrites quelque part.

Précisions : Il n'est pas possible de gérer cet aspect de Docker via l'interface de DSM, uniquement en ligne de commande ou par Docker-compose.

Sans aucune précision de votre part concernant l'emplacement de ces données, elles sont écrites, sur nos NAS, dans /volume1/@docker/volumes/ (à ne pas confondre avec /volume1/docker, le premier étant un dossier "caché" dans File Station (visiblement uniquement via SSH/Telnet), le deuxième visible, accessible et créé par nos soins), et sur une distribution Linux classique, /var/lib/docker/volumes/.

Si l'image prévoit la création de volumes (visible dans le Dockerfile d'une image via la commande EXPOSE volume), Docker les créera, si vous les déclarez vous pourrez choisir leur emplacement, dans le dossier partagé docker ou ailleurs, si vous ne les déclarez pas, ils seront créés dans les dossiers mentionnés dans le paragraphe précédent.
Dans le deuxième cas, si vous supprimez le conteneur, les données ne seront pas effacées, mais les volumes seront laissés à l'abandon (dangling en anglais), et ne seront pas réutilisés en cas de recréation ultérieure.
Le plus simple est donc de les déclarer, qu'on souhaite les mettre dans un dossier accessible via File Station, ou non. On assure ainsi la persistance des données. En ce cas, trois méthodes sont possibles :

1. On définit un volume au moment de la création du conteneur, voir ici. Ce volume ne sera pas supprimé à la suppression du conteneur, en revanche il n'est utilisable que par le conteneur en question.
   => Pratique pour l'essai rapide d'une application
    
2. On définit un volume indépendamment d'un conteneur. Il est donc autonome des conteneurs qui l'utilisent, car en effet n'importe quel conteneur peut décider d'accéder son contenu en son sein à sa création.
   => Intéressant si on souhaite que plusieurs applications partagent un même volume
    
3. On demande au conteneur d'utiliser des dossiers existants du NAS pour y lire ou écrire des données existantes. Ce ne sont pas des volumes Docker à proprement parler. Donc toutes les opérations disponibles via la commande docker volume ne sont pas disponibles pour ce procédé, on appelle plus généralement ces volumes des bind pour les différencier des volumes Docker.
   => Cette troisième solution est celle qui est le plus souvent utilisée car généralement, on souhaite que l'application qu'on déploie puisse mettre à disposition soit le contenu de dossiers déjà peuplés du NAS, soit permettre que les données générées par l'application ou envoyées vers celle-ci écrivent dans un dossier du NAS accessible par File Station

Pour illustrer ce que contient un conteneur, à 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) :

    

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

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 assurer la persistance (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 :

Et on clique sur Ajouter un dossier.
On est alors amené à choisir le dossier dans lequel on va monter /config.
Lorsqu'on installe Docker sur son NAS, un dossier partagé docker est créé, libre à vous de vous organiser de la manière qui vous conviendra le mieux.
Souvent, on crée un dossier par conteneur.
Je choisis mon dossier et valide :

Dans la colonne Chemin d'accès, je suis venu écrire manuellement le chemin absolu du dossier dans lequel je vais monter mes données.

7-B-2-c. 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.

7-B-2-c-1. Bridge

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/16. 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 : c'est l'équivalent de votre box par rapport à Internet.
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.

7-B-2-c-2.  host

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 :

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, on appelle ça des réseaux bridge personnalisés ou définis par l'utilisateur.
Les réseaux bridge personnalisés font l'objet de remarques supplémentaires en fin de tutoriel.

7-B-2-d. 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 en utilisant via SSH en root la commande :

sudo netstat -tulpn | grep LISTEN

Autrement, DSM nous préviendra au moment de la création du conteneur que le ou les ports choisis sont déjà utilisés et la création échouera. 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 est utilisé par Nginx, donc j'en ai choisi d'autres qui, eux, sont libres :

NDLR : Lorsque la documentation ne précise pas le protocole du transport des données par le dit port, on parle du port TCP par défaut.
NOTE : Si on a choisi le mode host, on n'a pas besoin de faire de redirection de ports

7-B-2-e. 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.

7-B-2-f. Variables d'environnement

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 :

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.
Les NAS sont généralement assez capricieux au niveau des permissions, car les dossiers sont régis par des ACL (Access Control List), ce qui correspond à l'onglet Utilisateur et Groupe dans le panneau de configuration de DSM. On rencontre beaucoup moins de problèmes sur une distrubition Linux classique.

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.

7-B-3. 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.

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 :

Et pour la version HTTPS :

7-B-4. 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.

8. Docker via SSH

8-A. Analyse

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 :

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).

8-B. En détail

Voyons plus en détail les possibilités pour chaque paramètre.
Lorsqu'un paramètre n'est pas précisé lors de la création du conteneur, Docker regarde dans son démon, à savoir un fichier qui contient des directives à utiliser par défaut sans précision contradictoire de la part de l'utilisateur. Ce fichier se trouve à l'emplacement : /var/packages/Docker/etc/dockerd.json

8-B-1. Restart policies

L'argument restart permet de définir le comportement de redémarrage du conteneur :

• --restart=no : C'est le comportement par défaut, le conteneur ne redémarrera pas s'il s'arrête, que ce soit proprement ou à cause d'une erreur.
• --restart=always : A contrario, le conteneur tente continuellement d'être redémarré, sauf s'il a été stoppé manuellement. Par contre, en cas de redémarrage du service Docker ou du NAS, le conteneur sera redémarré.
• --restart=unless-stopped : En cas d'erreur, le conteneur tentera de redémarrer indéfiniment. S'il est arrête manuellement, le conteneur ne sera pas relancé. En cas de redémarrage du service Docker ou du NAS, le conteneur ne sera pas redémarré.
• --restart=on-failure[:4] : Le conteneur ne sera redémarré qu'en cas d'arrêt pour cause d'erreur, et ce par exemple ici dans une limite de quatre fois.

8-B-2. Network

L'argument network permet de définir la connectivité d'un conteneur par rapport à son environnement :

• --network=none : le conteneur est totalement isolé et autonome, le seul moyen d'y accéder est par terminal.
• --network=my-network : permet de se connecter à un réseau bridge personnalisé ou macvlan nommé my-network.

Si on ne précise rien, le conteneur rejoint le réseau bridge par défaut (voir 7-B-2-c-1).

8-B-3. Ports

La gestion des ports permet de rendre une application dans un conteneur accessible sur son hôte via des ports spécifiques.
C'est indispensable si on souhaite accéder à un conteneur sur un réseau bridge. Un conteneur sur réseau macvlan a tous ses ports exposés sur sa propre IP, il est comme une machine à part entière sur le réseau, tous ses ports sont accessibles sur le réseau sur lequel il se trouve.

8-B-3-a. Interfaces

Pour translater un port, on désigne le port sur lequel l'application est exposée dans le conteneur ainsi que le port sur l'hôte par lequel on accède à cette application.

Par exemple :

-p 8080:80

L'application disponible sur le port 80 dans le conteneur est translatée sur le port 8080 de l'hôte.

-p 0.0.0.0:8080:80

Écrire 8080:80 revient à écrire 0.0.0.0:8080:80

0.0.0.0:8080 signifie l'application est disponible sur le port 8080 de l'hôte sur toutes ses interfaces.
Que ce soit localhost (127.0.0.1 => seul l'hôte peut y accéder), l'IP local (par exemple 192.168.0.10), l'IP passerelle bridge 172.17.0.1 ou encore l'IP VPN.
Je voudrais par exemple pouvoir vouloir n'accéder à une application que lorsque la requête arrive sur l'IP VPN de l'hôte :

-p 10.0.8.1:8080:80

http://10.0.8.1:8080 aboutira, alors que 192.168.0.10:8080 ne donnera rien.

8-B-3-b. Protocoles

Si on souhaite autoriser uniquement un protocole, il suffit de le préciser à la fin de l'argument :

-p 8080:80/tcp
-p 1194:1194/udp

8-B-4. Commandes utiles

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.

9. Docker-compose via SSH

Docker-compose vient compenser les lacunes de la création de conteneur par Docker, dont voici un exemple :

Les points forts de docker-compose sont :

- écriture analytique, plus lisible qu'un script
- possède beaucoup plus de fonctionnalités (dont on n'aborde ici qu'une infime partie)
- possibilité de définir plus applications (appelés services) au sein d'un même fichier

Dans un fichier docker-compose.yml, on peut définir 3 types d'objets :

- des services : ce sont les applications en elles-mêmes
- des volumes : ce sont des dossiers dans lesquels on va pouvoir écrire des données de manière persistante
- des réseaux (networks) : ils définissent la manière dont sont exposés les 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.

10. 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é.

11. Informations complémentaires

11-A. 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.

11-A-1. Création du réseau macvlan

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...)

11-A-2. Création de l'interface virtuelle

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 depuis un conteneur sur le réseau macvlan y accéder via 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.

MàJ : 08/07/2023

Modifié le 8 juillet 2023 par .Shad.
Ajout tutoriel mopidy

[Mic13710]

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.

[pikeupe]

slt

 

merci pour ce tuto

[Pascalou59]

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....

103. *
104. * @param string $path
105. * @return string
106. */
107. public function hash($path)
108. {
109. return md5_file($path);
110. }
111.  
112. /**
113. * Write the contents of a file.
114. *
115. * @param string $path
116. * @param string $contents
117. * @param bool $lock
118. * @return int
119. */
120. public function put($path, $contents, $lock = false)
121. {
122. return file_put_contents($path, $contents, $lock ? LOCK_EX : 0);
123. }
124.  
125. /**
126. * Write the contents of a file, replacing it atomically if it already exists.
127. *
128. * @param string $path
129. * @param string $content
130. * @return void
131. */
132. public function replace($path, $content)
133. {
134. // If the path already exists and is a symlink, get the real path...
135. clearstatcache(true, $path);
136.  
137. $path = realpath($path) ?: $path;
138.  
139. $tempPath = tempnam(dirname($path), basename($path));
140.  
141. // Fix permissions of tempPath because `tempnam()` creates it with permissions set to 0600...
142. 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é le 17 janvier 2020 par Pascalou59

[.Shad.]

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 ?

[Pascalou59]

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.

 

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é le 21 janvier 2020 par Pascalou59

[Pascalou59]

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é le 22 janvier 2020 par Pascalou59

[Didier3L]

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  👍

[.Shad.]

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é le 9 mars 2020 par .Shad.

[Didier3L]

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 🤪

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

[Didier3L]

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 ?

Point 2 et 3 :

Je mets exactement la même chose ?

Point 4 :

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

Voici la configuration de mon réseau de Synology

 

 

[.Shad.]

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é le 18 mars 2020 par .Shad.

[Didier3L]

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

 

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

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é le 18 mars 2020 par Didier3L

[bruno78]

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é le 19 mars 2020 par bruno78

[.Shad.]

@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. 😉 

[bruno78]

@.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

[Didier3L]

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 ....

[Didier3L]

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

Le réseau de ma Freebox

Le réseau de mon NAS

Les réseaux ifconfig du NAS

 

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é le 19 mars 2020 par Didier3L

[.Shad.]

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é le 19 mars 2020 par .Shad.

[Didier3L]

Merci .Shad.

C'est plus clair pour moi
Je mets cela en œuvre ce week-end 👍

[Didier3L]

Bonsoir 😎

Petit problème 🥺

[bruno78]

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" \ ??

[.Shad.]

Ah oui totalement, tu peux mettre /29 ou partir de 230 au lieu de 240 😉

[Didier3L]

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

Modifié le 20 mars 2020 par Didier3L

[.Shad.]

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.