PatrickBt Posté(e) le 15 août 2021 Posté(e) le 15 août 2021 Ma question va certainement paraître bête et idiote, mais je la pose tout de même avant de faire des conneries en SSH. Dans le tuto Citation 4-A. En lignes de commande (SSH) Voici un exemple de configuration : docker create --name=watchtower \ --hostname=watchtower-nas --restart=unless-stopped \ --label "com.centurylinklabs.watchtower.enable=true" \ -e WATCHTOWER_CLEANUP=true \ -e WATCHTOWER_DEBUG=true \ -e WATCHTOWER_LABEL_ENABLE=true\ -e WATCHTOWER_TIMEOUT=30s \ -e WATCHTOWER_SCHEDULE="0 0 5 * * 6"\ -e TZ=Europe/Brussels \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower Comment faut-il saisir ce code ? par ligne et valider par entrée ou copier l'ensemble d'un coup et valider par entrée ? Je pencherais pour l'ensemble car le programme qui exécute les paramètres doit être "docker create" 0 Citer
oracle7 Posté(e) le 15 août 2021 Posté(e) le 15 août 2021 (modifié) @PatrickBt Bonjour, Tu sélectionnes/copies l'ensemble du code suscité et tu le colles dans un terminal sous SSH (PuTTY, WinSCP, Terminal MacOS, ...) et tu valides. C'est tout ... Les "\" en fin de chaque ligne permettent simplement de clarifier la ligne de code dans sa présentation (en la "coupant" et renvoyant à la ligne la suite) afin de mieux comprendre/identifier chaque option de celle-ci. Cordialement oracle7😉 Modifié le 15 août 2021 par oracle7 0 Citer
PatrickBt Posté(e) le 15 août 2021 Posté(e) le 15 août 2021 Bon alors, j'ai téléchargé l'image de "watchtower" avec la commande "docker pull containrrr/watchtower" : j'ai vérifié si l'image s'était bien téléchargée, c'est ok. Par contre, pour la commande de création du conteneur, j'ai juste modifié la ville dans la commande TZ et je n'ai rien changé aux autres paramètres de configuration. J'ai ceci, Le curseur s'arrête su l'avant dernière ligne "containrrr/watchtower". J'ai fini par valider au bout d'une minute, car çà n'évoluait pas. 0 Citer
MilesTEG1 Posté(e) le 15 août 2021 Posté(e) le 15 août 2021 @PatrickBt : Je ne sais pas vraiment ce qui ne va pas avec ta commande, mais quitte à passer par la ligne de commande, pourquoi ne pas utiliser un fichier docker-compose.yml et la commande dans le dossier contenant le yml : docker-compose up -d 0 Citer
.Shad. Posté(e) le 15 août 2021 Auteur Posté(e) le 15 août 2021 La première commande tu as oublié le "\" après l'argument hostname. La 2eme il y a un c/c foireux avec un restart commenté en début de commande. 0 Citer
PatrickBt Posté(e) le 15 août 2021 Posté(e) le 15 août 2021 @MilesTEG1 Je n'ai pas encore pris le temps de voir comment le docker-compose.yml fonctionnait. Faudra que j'étudie cette possibilité. @.Shad. C'est quoi un c/c ? Avec la correction du "\" çà donne cela. Le nom du référentiel, c'est bien containrrr/watchtower ? 0 Citer
.Shad. Posté(e) le 15 août 2021 Auteur Posté(e) le 15 août 2021 (modifié) c/c c'est copié/collé. Et tu as oublié un espace entre le guillemet de fermeture de WATCHTOWER_SCHEDULE et le \ de fin de ligne. D'où la remarque sur la majuscule de l'output. EDIT : et aussi un espace à la fin de WATCHTOWER_LABEL_ENABLE entre le true et le \. Modifié le 15 août 2021 par .Shad. 0 Citer
PatrickBt Posté(e) le 15 août 2021 Posté(e) le 15 août 2021 @.Shad. Merci, çà a fonctionné et il manquait aussi un autre espace ici : -e WATCHTOWER_LABEL_ENABLE=true \ Il faut vraiment que je prête attention à tous ces détails. 0 Citer
MilesTEG1 Posté(e) le 27 octobre 2021 Posté(e) le 27 octobre 2021 Hello par ici 🙂 Dites, depuis que j'ai fait la MAJ du paquet Docker DSM hier soir, j'ai plein de petits soucis... Ça a commencé par Tautulli qui ne pouvait plus se connecter à mon PMS... (je n'ai rien changé niveau réglages...)... Puis j'ai vu cette erreur dans DSM : System failed to get External IP. J'ai rebooté le NAS, et ce dernier s'est éteint (oui je ne me suis pas trompé de ligne pour le clic, j'ai bien choisi redémarrer ^^), et pas moyen de le rallumer au bouton... il a fallu que je débranche la prise d'alimentation du NAS et que je la rebranche pour qu'il se rallume. Bref, voilà pour la mise en situation... Et ce matin, je reçois cet email de Watchtower : Could not do a head request for "lissy93/dashy:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:42909->192.168.2.210:53: i/o timeout Unable to update container "/Dashy": Error response from daemon: Get "https://registry-1.docker.io/v2/": context deadline exceeded (Client.Timeout exceeded while awaiting headers). Proceeding to next. Could not do a head request for "gitea/gitea:1", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:58762->192.168.2.210:53: i/o timeout Could not do a head request for "grafana/grafana:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:41298->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/tautulli:amd64-latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:34463->192.168.2.210:53: i/o timeout Could not do a head request for "vaultwarden/server:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:38384->192.168.2.210:53: i/o timeout Could not do a head request for "ttionya/vaultwarden-backup:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:39918->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/plex:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:49616->192.168.2.210:53: i/o timeout Found new ghcr.io/linuxserver/plex:latest image (b3c421db2d05) Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:55395->192.168.2.210:53: i/o timeout Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:49073->192.168.2.210:53: i/o timeout Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:52051->192.168.2.210:53: i/o timeout Could not do a head request for "influxdb:1.8", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:53334->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/calibre-web:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:48934->192.168.2.210:53: i/o timeout Could not do a head request for "portainer/portainer-ce:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:47582->192.168.2.210:53: i/o timeout Found new portainer/portainer-ce:latest image (a1c22f3d250f) Could not do a head request for "ghcr.io/crazy-max/fail2ban:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:40619->192.168.2.210:53: i/o timeout Could not do a head request for "adguard/adguardhome:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:37464->192.168.2.210:53: i/o timeout Stopping /portainer (439b51c93047) with SIGTERM Stopping /plex_PlexMediaServer (476f6d42f77f) with SIGTERM Creating /plex_PlexMediaServer Creating /portainer Removing image 6fd0acb4c97f Removing image bc46de77a3ff Et en copiant/collant ce log... je me rends compte que c'est probablement la résolution DNS qui n'a pas marché... Car 192.168.2.210 c'est mon serveur adguard... Hier j'avais modifié les IP DNS dans DSM pour mettre en 2ème IP celle du routeur, la première étant celle de AdGuard (macvlan). Et pour une raison que j'ignore, ce matin ça a merdé... J'ai tenté là, de mettre que l'IP de mon routeur : pas de soucis cette fois-ci J'ai tenté de repasser sans configurer manuellement le DNS, donc en prenant ce qui est fourni par le serveur DHCP du routeur (donc l'IP de mon AdGuard), et là aussi watchtower n'a pas remonté d'erreurs. (J'ai bien changé le cron pour ce dernier ^^) J'ai remis le DNS personnalisé avec l'IP du routeur. Bref, je ne sais pas ce qu'il s'est passé... je verrais demain. Je vais aller aussi poser ma question sur la dernière MAJ de docker dans le bon sujet ^^ @tout de suite sur l'autre topic. PS : la maj de docker a eu lieu hier soir à 19h30, en même temps que plein d'autres paquets 😉 0 Citer
Lelolo Posté(e) le 27 octobre 2021 Posté(e) le 27 octobre 2021 Sous DSM 6 ou DSM 7, tes problèmes ? Car sous DSM 7 je n'ai pas eu de mises à jour hier. 0 Citer
MilesTEG1 Posté(e) le 27 octobre 2021 Posté(e) le 27 octobre 2021 Il y a 2 heures, Lelolo a dit : Sous DSM 6 ou DSM 7, tes problèmes ? Car sous DSM 7 je n'ai pas eu de mises à jour hier. Ha je pensais avoir mis la version 😅 dsm7. Faut que j’ajoute la version dans ma signature 😊 0 Citer
.Shad. Posté(e) le 27 octobre 2021 Auteur Posté(e) le 27 octobre 2021 Si tu as màj le paquet Docker, l'interface virtuelle a sauté. D'où la perte de résolution DNS car le NAS (et par extension les conteneurs en bridge/host) ne peut plus contacter le conteneur en macvlan. En revanche la résolution DNS de tous tes autres périphériques devrait être fonctionnelle. Donc : juste relancer le script de création de l'interface virtuelle et ça devrait être bon. Si c'est un autre problème je regarderai ce soir, je n'ai pas encore fait les mises à jour. 0 Citer
Pascalou59 Posté(e) le 27 octobre 2021 Posté(e) le 27 octobre 2021 @.Shad. @MilesTEG1Bonjour J'ai fait la mise a jour du docker en 20.10.3-1239 rien a signaler ... 1 Citer
MilesTEG1 Posté(e) le 27 octobre 2021 Posté(e) le 27 octobre 2021 Il y a 2 heures, .Shad. a dit : Donc : juste relancer le script de création de l'interface virtuelle et ça devrait être bon. Si c'est un autre problème je regarderai ce soir, je n'ai pas encore fait les mises à jour. Ok donc normalement après le reboot que j’ai fait hier soir vers 20h mon interface virtuelle a du être recréée. Ce qui normalement permettait à mon watchtower de ce matin 6h de fonctionner correctement… étrange… 0 Citer
oracle7 Posté(e) le 27 octobre 2021 Posté(e) le 27 octobre 2021 @MilesTEG1 Bonjour, Juste pour mon info, je dois être très en retard car je vois dans ta signature que ton SRM est en version 7.0.1. Waouh ????? Ce serait pas plutôt 1.2.5 ? 🤣 Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 27 octobre 2021 Auteur Posté(e) le 27 octobre 2021 @MilesTEG1 Tu as vérifié en SSH qu'elle était bien présente ? 0 Citer
MilesTEG1 Posté(e) le 27 octobre 2021 Posté(e) le 27 octobre 2021 il y a 37 minutes, .Shad. a dit : @MilesTEG1 Tu as vérifié en SSH qu'elle était bien présente ? Heu non... Mais après un reboot, elle est censé être présente vu que j'ai un script qui se lance après le reboot... Du coup la prochaine fois je vérifierais. il y a 43 minutes, oracle7 a dit : @MilesTEG1 Bonjour, Juste pour mon info, je dois être très en retard car je vois dans ta signature que ton SRM est en version 7.0.1. Waouh ????? Ce serait pas plutôt 1.2.5 ? 🤣 Cordialement oracle7😉 LoL J'ai oublié de faire le copier/coller ici aussi 😉 Ou alors j'ai voyagé dans une faille spatio-temporelle pour atterrir en 2340 😄 Synology a changé de nom au moins 5 fois d'ici là 😜 1 Citer
oracle7 Posté(e) le 28 décembre 2021 Posté(e) le 28 décembre 2021 @.Shad. Bonjour, Je reviens sur la gestion décentralisée des crédentials évoquées au §4.B du TUTO. J'ai bien compris comment le faire avec la solution "env_file", pas de soucis avec cette façon de procéder. Maintenant j'aimerais "durcir" la sécurité des choses en codant base64 (en plus) ces valeurs de crédentials et en les intégrant dans un fichier "config.json". J'ai donc examiné la doc sur le sujet mais j'avoue ne pas bien tout appréhender et notamment vis à vis de la syntaxe à donner à ce fichier "config.json". La doc donne ceci en ex : { "auths": { "<REGISTRY_NAME>": { "auth": "XXXXXXX" } } } avec "XXXXXXX" le couple "user:passwrd" codé base64. avec "<REGISTRERY_NAME>" = (si je comprends bien) " secret.ndd.tld " qui serait l'URL de mon dépot privé. Mais comment je relie cette URL à un fichier particulier contenant les données secrètes par ex : "/volume1/docker/watchtower/config.json " ? Il me manque un truc là ... C'est pas clair du tout dans mon esprit. Par ailleurs, est-ce que la syntaxe/agencement suivante du fichier "config.json" est-elle correcte selon toi ? { "auths": { "secret.ndd.tld": { "WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG": "[ Watchtower-MonNas ]", "WATCHTOWER_NOTIFICATION_EMAIL_FROM": "my-Gmail-email", "WATCHTOWER_NOTIFICATION_EMAIL_TO": "my-Gmail-email", "WATCHTOWER_NOTIFICATION_EMAIL_SERVER": "smtp.gmail.com", "WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT": "587", "WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER": "my-Gmail-email", "WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD": "apasswordtomyemail", "WATCHTOWER_NOTIFICATION_EMAIL_DELAY": "2" } } } ou bien ne serait-ce pas tout simplement plutôt ce type de syntaxe qu'il faille employer ? { "WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG": "[ Watchtower-MonNas ]", "WATCHTOWER_NOTIFICATION_EMAIL_FROM": "my-Gmail-email", "WATCHTOWER_NOTIFICATION_EMAIL_TO": "my-Gmail-email", "WATCHTOWER_NOTIFICATION_EMAIL_SERVER": "smtp.gmail.com", "WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT": "587", "WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER": "my-Gmail-email", "WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD": "apasswordtomyemail", "WATCHTOWER_NOTIFICATION_EMAIL_DELAY": "2" } Sauf que là, les valeurs ne sont pas codées base64. Du coup, faut-il chacune les coder base64 mais watchtower va-t-il ensuite bien les décoder automatiquement car a priori je n'ai rien vu qui lui indique qu'elles le sont. Comme tu peux le voir, je m'y perd un peu beaucoup dans cette notion de dépôt privé.🤪 Pourrais-tu STP m'aider à sortir de l'ornière et pour me remettre sur le chemin ... Cordialement oracle7😉 0 Citer
MilesTEG1 Posté(e) le 28 décembre 2021 Posté(e) le 28 décembre 2021 @oracle7 Pourquoi j'ai pas compris grand chose dans ce que tu viens de dire ? 😅 Comment fais-tu pour dire dans le docker-compose que les variables d'environement sont à prendre dans un JSON et qui plus est chiffré ? 0 Citer
oracle7 Posté(e) le 28 décembre 2021 Posté(e) le 28 décembre 2021 @MilesTEG1 Bonjour, C'est sûr que j'ai essayer de transcrire quelque chose qui n'est déjà pas clair déjà dans mon esprit. 😳 Regardes le lien sur la doc que j'ai donné. Si j'ai bien compris c'est possible de relire un fichier "config.json" qui contient une valeur cryptée pour le couple "user:passwrd". Voilà ce que j'essaie de transposer à l'ensemble des données d'environnement de watchtower. Ni plus ni moins. Cordialement oracle7😉 1 Citer
MilesTEG1 Posté(e) le 28 décembre 2021 Posté(e) le 28 décembre 2021 Ok 🙂 Bon et bien je vais attendre que tu ais fini, bien compris, et que tu ais fait un addendum tuto à ajouter à celui de @.Shad. 😄 😛 0 Citer
.Shad. Posté(e) le 6 janvier 2022 Auteur Posté(e) le 6 janvier 2022 (modifié) @oracle7 J'avais oublié ce message. Le fichier config.json existe juste pour se connecter à des dépôts publics ou privés, et c'est propre à Watchtower, c'est tout. Par exemple pour être authentifié sur hub.docker.com, j'ai transformé mon user:password comme demandé dans la doc via un encodage en base 64. Pour des dépôts privés ça fonctionnerait pareil. Ca n'a aucun rapport avec la sécurisation de variables d'environnement. En alternative à l'env_file, tu as les "secrets" Docker, c'est compatible avec la version implémentée dans DSM, voir : https://docs.docker.com/compose/compose-file/compose-file-v3/ https://docs.docker.com/engine/swarm/secrets/ NOTE : Il te faudra passer sur une version de docker-compose plus récente, à vérifier mais je pense 3 minimum. Ou alors utiliser stack au lieu de docker-compose. Modifié le 6 janvier 2022 par .Shad. 0 Citer
oracle7 Posté(e) le 6 janvier 2022 Posté(e) le 6 janvier 2022 @.Shad. Bonjour, Merci pour ta réponse. Il y a 4 heures, .Shad. a dit : Ca n'a aucun rapport avec la sécurisation de variables d'environnement. A la réflexion j'en étais finalement arrivé à cette conclusion. Pour les docker secret, j'étudie cela à tête reposée ... Tu as raison c'est sans doute mieux comme solution. Cordialement oracle7😉 0 Citer
MilesTEG1 Posté(e) le 6 janvier 2022 Posté(e) le 6 janvier 2022 J'ai jamais rien compris au docker secret... Je vois l'objectif, mais je comprends pas du tout la mise en place... 😅😆 0 Citer
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.