Aller au contenu

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


.Shad.

Messages recommandés

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"

Lien vers le commentaire
Partager sur d’autres sites

@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é par oracle7
Lien vers le commentaire
Partager sur d’autres sites

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, 1388225557_Capturedcran2021-08-15162901.png.d468e9ddd5ca3085d74f7b5b8fa73988.png

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.

Lien vers le commentaire
Partager sur d’autres sites

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é par .Shad.
Lien vers le commentaire
Partager sur d’autres sites

  • 2 mois après...

Hello par ici 🙂

Dites, depuis que j'ai fait la MAJ du paquet Docker DSM hier soir, j'ai plein de petits soucis...

W1G9XIW.png

 

Ç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
KuicC2J.png


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 😉

 

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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…

Lien vers le commentaire
Partager sur d’autres sites

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

Lien vers le commentaire
Partager sur d’autres sites

  • 2 mois après...

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

Lien vers le commentaire
Partager sur d’autres sites

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

Lien vers le commentaire
Partager sur d’autres sites

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

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é par .Shad.
Lien vers le commentaire
Partager sur d’autres sites

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

 

Lien vers le commentaire
Partager sur d’autres sites

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.

Invité
Répondre à ce sujet…

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

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

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

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

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

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.