[TUTO] Mise à jour automatique des images et conteneurs Docker

[PatrickBt]

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"

[oracle7]

@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

[PatrickBt]

@oracle7 Merci beaucoup. 😀

[PatrickBt]

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.

[MilesTEG1]

@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 

[.Shad.]

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.

[PatrickBt]

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

[.Shad.]

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.

[PatrickBt]

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

[MilesTEG1]

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 😉

 

[Lelolo]

Sous DSM 6 ou DSM 7, tes problèmes ? Car sous DSM 7 je n'ai pas eu de mises à jour hier.

[MilesTEG1]

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 😊

[.Shad.]

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.

[Pascalou59]

@.Shad. @MilesTEG1Bonjour

J'ai fait la mise a jour du docker  en 20.10.3-1239   rien a signaler ...

 

[MilesTEG1]

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…

[oracle7]

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

[.Shad.]

@MilesTEG1 Tu as vérifié en SSH qu'elle était bien présente ?

[MilesTEG1]

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à 😜  

[oracle7]

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

[MilesTEG1]

@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é ?

[oracle7]

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

[MilesTEG1]

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

[.Shad.]

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

[oracle7]

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

 

[MilesTEG1]

J'ai jamais rien compris au docker secret...

Je vois l'objectif, mais je comprends pas du tout la mise en place... 😅😆