[TUTO] Docker : Introduction

[.Shad.]

il y a 7 minutes, Geoff1330 a dit :

Cela a été résolut avec " -- Network host "

C'est la solution de facilité, car en fait ce n'est pas une solution. Je suis toujours étonné que des gens du métier se contentent de proposer de faire ça. On perd une partie de l'intérêt d'isolation de Docker en host, on ne le fait généralement que pour de bonnes raisons (problème de NAT, nécessité de broadcast sur le réseau physique). Le réseau bridge utilise la résolution DNS de l'hôte, tu devrais investiguer du côté de ton pare-feu et t'assurer que tu autorises a minima les requêtes DNS (port 53) depuis le sous-réseau 172.17.0.0/255.255.0.0.

Dans ton cas il n'y aura aucune différence de fonctionnement entre réseau bridge par défaut et réseau personnalisé (user-defined bridge), les différences sont listées dans mon tutoriel introductif en signature.

Car sinon c'est normal que le résolveur DNS renvoie un timeout.
En host tu es sur l'IP du NAS, donc le pare-feu n'entre pas en compte (par défaut les requêtes de 127.0.0.1 sont autorisées).

[Geoff1330]

@.Shad. Merci pour c'est information.

Effectivement, on a beaucoup chercher avec le dns du docker ect.

Je viens de revoir le paragraphe sur le sujet dans ton tuto.

Je vais faire des tests, maintenant que je  sais que l'apps fonctionne.

docker0   Link encap:Ethernet  HWaddr 02:42:62:DE:D7:07
          inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0
          inet6 addr: fe80::42:62ff:fede:d707/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3002401 errors:0 dropped:0 overruns:0 frame:0
          TX packets:801030 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8166854992 (7.6 GiB)  TX bytes:61933391 (59.0 MiB)

docker-25 Link encap:Ethernet  HWaddr 02:42:80:BF:BF:3E
          inet addr:172.18.0.1  Bcast:172.18.255.255  Mask:255.255.0.0
          inet6 addr: fe80::42:80ff:febf:bf3e/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:15 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:764 (764.0 B)  TX bytes:2946 (2.8 KiB)

docker3b0 Link encap:Ethernet  HWaddr 56:60:F4:62:10:93
          inet6 addr: fe80::5460:f4ff:fe62:1093/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2856680 errors:0 dropped:0 overruns:0 frame:0
          TX packets:768194 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:7785028000 (7.2 GiB)  TX bytes:58940916 (56.2 MiB)

J'ai plusieurs paramètres Docker, pourquoi?

 

Dans le docker icloudpd, problème du dns était ici

2021-09-21 14:05:26 INFO LAN IP Address: 172.17.0.3
2021-09-21 14:05:26 INFO Default gateway: 172.17.0.1
2021-09-21 14:05:26 INFO DNS server: 10.0.1.1
2021-09-21 14:05:26 ERROR Cannot find icloud.com IP address. Please check your DNS settings
2021-09-21 14:05:31 ERROR No route to icloud.com found. Please check your container's network settings

Si je comprend bien, je devrais avoir un DNS en 172.17.0.1 ?

Modifié le 22 septembre 2021 par Geoff1330

[.Shad.]

il y a 14 minutes, Geoff1330 a dit :

J'ai plusieurs paramètres Docker, pourquoi?

Les interfaces avec une IPv4 dans la plage 172.16.0.0/12 (de 172.16.0.0 à 172.31.255.255) sont les portes d'entrée/sortie des réseaux bridge avec le reste du monde.
La docker3b0 correspond à l'interface d'appairage des conteneurs. Ce qui t'intéresse c'est le premier type.

172.17.0.1 représente le NAS dans le réseau bridge par défaut.
172.18.0.1 à 172.31.0.1 représentent le NAS dans les réseaux personnalisés.
Ce sont les interfaces de passerelle que tu retrouves dans les logs de ton conteneur icloud.

il y a 14 minutes, Geoff1330 a dit :

Si je comprend bien, je devrais avoir un DNS en 172.17.0.1 ?

Dans les faits oui, ça revient à ça, mais Docker a son propre système de résolution interne. Normalement tu n'as rien à configurer. Si tu tapes la commande suivante en SSH :

docker exec -it icloudpg cat /etc/resolv.conf

Tu devrais avoir comme nameserver l'adresse 127.0.0.1 ou 127.0.0.11
D'ailleurs tu peux aussi tester la commande suivante :

docker exec -it icloudpg nslookup www.google.fr

Et poster le résultat. Pas sûr que la commande soit disponible dans l'image.

2 (3) autres questions :

• 10.0.1.1 correspond à l'IP locale du routeur ou de la box de ton réseau local ?
• Si tu recrées le conteneur et que tu ajoutes la ligne suivante dans le script, dis-moi si ça fonctionne :

--dns 127.0.0.1

• Si pas tu modifies la ligne précédente comme suit, tu recrées le conteneur et tu me dis ce qu'il en est :

--dns 80.67.169.12

 

Modifié le 22 septembre 2021 par .Shad.

[MilesTEG1]

il y a 42 minutes, Geoff1330 a dit :

@.Shad. si, mais c'est réglé 😉

Le problème était que le conteneur n'avait pas accès à icloud.com.

Cela a été résolut avec " -- Network host "

 

Et donc avec ce docker, j'ai une copie sur le NAS des photos venant d'iCloud automatiquement.

Avant j'utilisais "moment", mais cela m’obligeait de démarrer l'app régulièrement pour exécuté la sauvegarde.

Oh mais j’ai suivi de loin ton soucis et là je vois que tu as mis en place une solution pour récupérer tes photos iCloud 😊

ça m’intéresse 😁

est-ce que ça récupère les noms des albums ? Ou bien les photos sont récupérées en vrac ?

et dernière question : est-ce que ça récupère juste les nouvelles photos qui apparaissent ou bien ça va aussi récupérer les photos qui ont été modifiées depuis la dernière fois ?

[Geoff1330]

il y a 3 minutes, .Shad. a dit :

10.0.1.1 correspond à l'IP locale du routeur ou de la box de ton réseau local ?

• Si tu recrées le conteneur et que tu ajoutes la ligne suivante dans le script, dis-moi si ça fonctionne :

--dns 127.0.0.1

• Si pas tu modifies la ligne précédente comme suit, tu recrées le conteneur et tu me dis ce qu'il en est :

--dns 80.67.169.12

 

Le 10.0.1.1 est bien l'IP de mon routeur. Quand j'avais ce DNS dans le docker, cela ne fonctionnait pas.

Nous avions essayé en faisant un DNS 127...:

2021-09-21 17:55:24 INFO DNS server: 127.0.0.11
2021-09-21 17:55:24 ERROR Cannot find icloud.com IP address. Please check your DNS settings
2021-09-21 17:55:29 ERROR No route to icloud.com found. Please check your container's network settings

 

[.Shad.]

Et du côté du pare-feu est-ce que tu autorises bien le sous-réseau 172.17.0.0 à communiquer avec le NAS ?
Car ça expliquerait tous tes problèmes.

Une impression d'écran du pare-feu si tu n'es pas sûr.

PS : Ca va il ne s'est pas contenté de te dire de mettre en host, je suis (un peu) rassuré. 🙂 

[Geoff1330]

@.Shad. effectivement, j'ai pas de règle dans le pare-feu sur le 172.17.0.0

Je vais faire cela et faire un test.

 

@MilesTEG1 pour le moment je peux juste te dire qu'il reprend les photos en frac et que tu peux les classer dans des dossier genre Année/Mois/jour. (Mais il y a plein d'option que je n'ai pas encore regardé. déjà le faire fonctionner etait du sport 🙂 )

Aussi, il prend tout ce qui est dans iCloud et compare a chaque connexion: si tu modifies un truc, je pense qu'il le fait aussi.

[Geoff1330]

@.Shad. test effectué. Cela fonctionne en -- network bridge et avec la règle dans le pare-feu 🙂

Merci pour tout ces détails, cela me permet de comprendre encore mieux comment dockers fonctionne et surtout les commande ssh 🙂

 

Modifié le 22 septembre 2021 par Geoff1330

[.Shad.]

Pas de quoi. 😉 

[Geoff1330]

Je vais faire un Tuto pour @MilesTEG1 😉 et en même temps, cela me permettra de retrouver la procédure au besoin.

[oracle7]

@Geoff1330

Bonjour,

Je serais aussi preneur de ton TUTO si te le veux bien. Mais peut-être aussi que si tu le mettais directement dans la rubrique TUTORIEL du frum, comme cela il profiterait à tous.

Merci d'avance.

Cordialement

oracle7😉

[Geoff1330]

il y a 2 minutes, oracle7 a dit :

@Geoff1330

tu le mettais directement dans la rubrique TUTORIEL du forum

C'est l'idée 😉

[Lud]

Bonjour,

Tuto exceptionnel ! Merci @.Shad. !

Je suis peut-être passé à côté de la réponse, je cherche comment ajouter un volume qui n'est pas proposé en variable d'environnement.

Par exemple, pour certains containers, pour lier les fichiers suivants :

/etc/localtime -> /etc/localtime
/etc/TZ -> /etc/timezone

Comme ils sont en dehors des dossiers partagés, je ne sais pas comment m'y prendre. Et pour certains containers, la variable d'environnement "TZ" ou équivalent n'existe pas.

Merci encore !

[oracle7]

@.Shad.

Bonjour,

il y a 1 minute, Lud a dit :

Et pour certains containers, la variable d'environnement "TZ" ou équivalent n'existe pas.

Justement dans ce cas, le TZ pris par défaut n'est-il pas celui de docker donc du NAS support ? Je dis une co...ie ou pas ?

Cordialement

oracle7😉

[Lud]

Bonjour @oracle7

Pour moi dans ce cas le container garde la timezone configurée à l'origine lors de la création du container.

[oracle7]

@Lud

Bonjour,

il y a 4 minutes, Lud a dit :

Pour moi dans ce cas le container garde la timezone configurée à l'origine lors de la création du container.

Donc je ne disais pas de c...ie, c'est bien celle de docker par défaut si rien n'est précisé dans le docker-compose du conteneur, non ?

Cordialement

oracle7😉

[.Shad.]

Non, un conteneur ne prend pas la timezone par défaut de son hôte.
Certains conteneurs n'ont ni fichier /etc/timezone, ni variable d'environnement TZ.

Ca dépend de ce qu'implémente l'image.

@Lud Tu peux toujours monter ce que tu veux dans le conteneur, que ce soit dans /volume1 ou non. Tu peux par exemple taper, pour un conteneur de nom "toto" :

docker exec -it toto bash

(remplacer par ash ou sh si bash pas disponible).

Et taper ensuite :

env

Tu verras vite s'il existe une variable TZ. Si oui alors tu peux l'ajouter dans les variables d'environnement, même si ce n'est pas repris dans la doc.

[oracle7]

@.Shad.

Bonjour,

il y a 11 minutes, .Shad. a dit :

Non, un conteneur ne prend pas la timezone par défaut de son hôte.

Bon bah comme cela c'est clair. Merci pour la précision.

il y a 11 minutes, .Shad. a dit :

Et taper ensuite :

env

Tu verras vite s'il existe une variable TZ.

 Et si Non, comment fait-on pour fixer le TZ à notre situation géographique ?

Pour comprendre, finalement est-ce aussi bien utile de le forcer ?

Cordialement

oracle7😉

[Lud]

@.Shad.

En fait, ma question est : comment ajouter des volumes dans les paramètres d'un container, mais qui ne sont pas situés dans /volume1 ?

Comme par exemple pour ce container :

https://hub.docker.com/r/lmscommunity/logitechmediaserver

Où la timezone est gérée au niveau des volumes, mais pas des variables d'environnement.

C'est faisable via l'interface graphique de Docker quand l'emplacement est dans /volume1, mais pas quand c'est dans /etc par exemple.

Dans mon cas, je souhaite ajouter en tant que volume (et pas en variable d'environnement), l'information suivante :

-v "/etc/localtime":"/etc/localtime":ro
-v "/etc/TZ":"/etc/timezone":ro

Mais je ne sais pas comment ajouter ou modifier cette configuration, sur un container déjà créé et configuré, en SSH sur le NAS, puisque ce n'est pas possible via l'interface graphique.

Je viens de tester tes lignes de commande, top pour voir les différentes variables d'environnement !

Je me demande juste si l'histoire d'ajouter un volume pour faire un bind sur un fichier en dehors de dossier /volume1 est possible sur un NAS Synology, ou est-ce que c'est bloqué ?

Modifié le 6 octobre 2021 par Lud
Ajout.

[.Shad.]

@Lud Je t'ai dit tu peux monter ce que tu veux dans un conteneur :

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

Tu peux toujours monter ce que tu veux dans le conteneur, que ce soit dans /volume1 ou non.

Mais tu ne peux rien monter à la volée. Il faut supprimer le conteneur et le recréer, d'où le fait de favoriser docker-compose qui trivialise le process.

Modifié le 6 octobre 2021 par .Shad.

[Lud]

@.Shad.

Ah d'accord ! Je pensais qu'on pouvait arrêter le conteneur, modifier certains paramètres en ligne de commande, puis le redémarrer sans avoir à le supprimer et le recréer complètement, puisque ça se fait depuis l'interface graphique.

Je me demandais si par exemple, en stoppant le container, puis en exécutant la commande que tu as indiquée :

docker exec -it toto bash

On rentre à ce moment là dans la configuration du container, d'ailleurs, pour moi ça ressemble très fortement à un chroot, et si on peut directement à partir de là modifier la configuration du container, soit directement dans un ou plusieurs fichiers, soit par une ligne de commande, puis faire un exit de la configuration du container, et enfin le relancer.

[.Shad.]

il y a 15 minutes, Lud a dit :

Ah d'accord ! Je pensais qu'on pouvait arrêter le conteneur, modifier certains paramètres en ligne de commande, puis le redémarrer sans avoir à le supprimer et le recréer complètement, puisque ça se fait depuis l'interface graphique.

Pas que je sache en tout cas. Après je n'utilise jamais l'interface DSM, peut-être qu'en fond elle supprime et recrée le conteneur, mais j'en doute fortement.

docker exec ne fonctionnera pas si le conteneur est arrêté ou supprimé. la commande permet d'exécuter une commande donnée dans un conteneur donné. Ce n'est pas un chroot, faut plus assimiler ça à une connexion SSH sans passer par SSH.

[Lud]

Ok, je comprends, merci !

[Geoff1330]

Bonjour,

Est-il possible de planifier un arrêt/démarrage d'un container?

J'ai des containers qui non pas besoin de tourner H24.

Merci

[EDIT] J'ai trouvé.

J'ai créé une tache dans le planificateur du DSM avec les commandes

docker start /le nom du countainer/

docker stop /le nom du countainer/

 

Ce n’était donc pas très bien compliqué 🙂

Modifié le 22 octobre 2021 par Geoff1330

[.Shad.]

En effet. 🙂