Invité Posté(e) le 15 décembre 2020 Posté(e) le 15 décembre 2020 Les deux dépôts seront maintenu a l'identique ( pour le moment en tout cas ). Mais non, la prochaine image ( en cas de MAJ par Watchtower par exemple ), ne sera indiqué que avec le dépot ghcr.io Elle se retrouvera marqué du linuxserver/plex que si tu pull depuis dockerhub 0 Citer
MilesTEG1 Posté(e) le 15 décembre 2020 Posté(e) le 15 décembre 2020 Il y a 2 heures, EVOTk a dit : Les deux dépôts seront maintenu a l'identique ( pour le moment en tout cas ). Mais non, la prochaine image ( en cas de MAJ par Watchtower par exemple ), ne sera indiqué que avec le dépot ghcr.io Elle se retrouvera marqué du linuxserver/plex que si tu pull depuis dockerhub Ok, merci 🙂 Je viens de changer aussi le dépôt pour tautulli, et c'était pour lui que j'avais eu plein d'images inutiles : C'est normal ça ? j'ai ça comme début de fichier docker-compose : --- version: "2.1" services: linuxserver_plex_tautulli: #image: linuxserver/tautulli:latest image: ghcr.io/linuxserver/tautulli container_name: linuxserver_plex_tautulli environment: J'utilise Portainer aussi ^^ 0 Citer
Invité Posté(e) le 15 décembre 2020 Posté(e) le 15 décembre 2020 Non, ce n'est pas normal. Il faudra que je vois si cela me fait pareil mais j'ai nettoyer il y a peu ( merci au bug de watchtower .... ) , mais on dirait qu'il ne sait pas qu'elle image prendre et qu'il prend tout 😄 Pour ma part, quand c'est indiqué dans le github, j'ai tendance a indiquer aussi l'architecture dans le compose : image: ghcr.io/linuxserver/plex:amd64-latest image: ghcr.io/linuxserver/tautulli:amd64-latest 0 Citer
MilesTEG1 Posté(e) le 16 décembre 2020 Posté(e) le 16 décembre 2020 (modifié) Il y a 8 heures, EVOTk a dit : Non, ce n'est pas normal. Il faudra que je vois si cela me fait pareil mais j'ai nettoyer il y a peu ( merci au bug de watchtower .... ) , mais on dirait qu'il ne sait pas qu'elle image prendre et qu'il prend tout 😄 Pour ma part, quand c'est indiqué dans le github, j'ai tendance a indiquer aussi l'architecture dans le compose : image: ghcr.io/linuxserver/plex:amd64-latest image: ghcr.io/linuxserver/tautulli:amd64-latest C'est je pense LA solution indiquée 😄 Mais je ne sais pas quelle est mon architecture 😅 J'ai un DS920+, si jamais tu sais laquelle c'est avant que je n'arrive à trouver la réponse ^^ Edit1 : Alors j'ai trouvé ça : Du coup c'est intel64 je suppose, mais comment je connais le terme exact pour docker ? Edit2 : Sur l'image plex : Du coup pour mon nas, ce serait tout le temps amd64-latest que je dois utiliser. C'est bien ça ? @EVOTk Modifié le 16 décembre 2020 par MilesTEG1 Ajout des "réponses" que j'ai trouvé 0 Citer
Invité Posté(e) le 16 décembre 2020 Posté(e) le 16 décembre 2020 Oui oui, l'architecture est x86_64 donc comme moi tu doit utiliser AMD64 0 Citer
MilesTEG1 Posté(e) le 16 décembre 2020 Posté(e) le 16 décembre 2020 Merci 🙂 Vu que je cherche à virer en une seule commande (faut que je la retrouve, je ne me rappelle plus ce que c'est) toutes ces images inutilisées, j'ai vu avec un docker info : Operating System: (containerized) OSType: linux Architecture: x86_64 CPUs: 4 Total Memory: 11.54GiB Name: Syno-DS920Plus Hmmm, je pensais que ça serait bon avec cette commande, mais non, ça ne supprime pas : @EVOTk : tu utilises quoi comme commande ? 0 Citer
Invité Posté(e) le 16 décembre 2020 Posté(e) le 16 décembre 2020 (modifié) Sur Portainer tu peu filtrer les images non utilisées. Ensuite tu peu faire un force remove En ssh c'est : ( doc officielle ) docker image prune -a Modifié le 16 décembre 2020 par Invité 0 Citer
MilesTEG1 Posté(e) le 16 décembre 2020 Posté(e) le 16 décembre 2020 @EVOTk vu que j'avais une sessions SSH ouverte, j'ai voulu en profiter ^^ Je mettrais le -a la prochaine fois. Et dans Portainer, si je ne force pas la suppression j'ai ces messages : Ca a bien supprimé quelques images, mais ça m'en a laisse les 3/4 😅 0 Citer
Invité Posté(e) le 16 décembre 2020 Posté(e) le 16 décembre 2020 Oui sur portainer je force toujours pour la suppression des image ms inutilisé 0 Citer
MilesTEG1 Posté(e) le 16 décembre 2020 Posté(e) le 16 décembre 2020 Petite question du soir : J'ai eu une MAJ de Heimdall ce soir via Watchtower... Or la dernière publication date de 2019... Normal ? Pas normal ? Possible explication : j'ai changé le dépôt de linuxserver par le nouveau hier ou avant hier, mais il me semblait avoir relancé watchtower après, et il avait récupéré la version... Bref, rdv demain ^^ 0 Citer
.Shad. Posté(e) le 17 décembre 2020 Auteur Posté(e) le 17 décembre 2020 Heimdall n'est plus développé depuis déjà longtemps, je suis passé sur Dashmachine personnellement. 0 Citer
MilesTEG1 Posté(e) le 17 décembre 2020 Posté(e) le 17 décembre 2020 Dashmashine est sympa, mais je crois que je n'ai pas poursuivi avec lui parce qu'il n'avait pas certains template... et que ça me faisait chier de chercher à les faire à la main... 0 Citer
MilesTEG1 Posté(e) le 21 décembre 2020 Posté(e) le 21 décembre 2020 @.Shad. @EVOTk depuis hier j'ai ces emails : 2020-12-21 19:15:22 (info): Found multiple running watchtower instances. Cleaning up. 2020-12-21 19:15:22 (info): Stopping /MmsABglUAOOJLKBakaCrbbBRLMsSxPIM (13b5128141da9045da0f48be66497ac8abebbc8d8438265eb48c9c6cb9c77bae) with SIGTERM 2020-12-21 19:15:25 (info): Removing image sha256:0dda0892dac4b9a6d5c97e78d3d4d04d27aded317592aff67f33a40581d35f55 2020-12-21 19:15:25 (info): Starting Watchtower and scheduling first run: 2020-12-22 19:15:00 +0100 CET Est-ce que c'est normal ? Je ne suis pas sur qu'il y ait eu des MAJ de watchtower chaque jour... Mon docker-compose : # # Doc de Watchtower : https://containrrr.dev/watchtower/ # --- version: "2.1" services: watchtower: image: containrrr/watchtower:latest container_name: watchtower network_mode: bridge environment: - WATCHTOWER_NOTIFICATIONS=email - WATCHTOWER_CLEANUP=true - WATCHTOWER_DEBUG=true - WATCHTOWER_LABEL_ENABLE=true - WATCHTOWER_TIMEOUT=30s # Utiliser soit SCHEDULE soit INTERVAL (ce dernier en sec) # Pour SCHEDULE : https://crontab.guru/#0_9_*_*_* # Ajouter un 0 en premier pour les secondes : secondes | minutes | heures | jour du mois | mois | jour de la semaine - WATCHTOWER_SCHEDULE=0 15 19 * * * #- WATCHTOWER_RUN_ONCE #- WATCHTOWER_POLL_INTERVAL=3000 - TZ=Europe/Paris env_file: - /volume1/docker/watchtower/watchtower.env labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - /var/run/docker.sock:/var/run/docker.sock restart: unless-stopped Merci d'avance 😉 0 Citer
Invité Posté(e) le 21 décembre 2020 Posté(e) le 21 décembre 2020 Salut, Il y a eu une MAJ de watchtower hier qui corrige le bug de suppression d'image quand on a le rolling restart actif et également une MAJ il y a 2h https://github.com/containrrr/watchtower/releases/tag/v1.1.2 https://github.com/containrrr/watchtower 0 Citer
MilesTEG1 Posté(e) le 21 décembre 2020 Posté(e) le 21 décembre 2020 @EVOTk Haaa, ok, alors tout est normal ^^ Je verrais demain si y a un message du même type ^^ merci 0 Citer
Einsteinium Posté(e) le 21 décembre 2020 Posté(e) le 21 décembre 2020 Pour un nettoyage : docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm 😉 0 Citer
MilesTEG1 Posté(e) le 22 décembre 2020 Posté(e) le 22 décembre 2020 (modifié) Rebelote ce soir, les mêmes messages : time="2020-12-22T19:15:20+01:00" level=debug time="2020-12-22T19:15:20+01:00" level=debug msg="Sleeping for a second to ensure the docker api client has been properly initialized." time="2020-12-22T19:15:21+01:00" level=debug msg="Retrieving running containers" time="2020-12-22T19:15:21+01:00" level=info msg="Found multiple running watchtower instances. Cleaning up." time="2020-12-22T19:15:21+01:00" level=info msg="Stopping /uqikZdqiFcJqqiBvblzIrktJBFPOYqiq (39870e8c038fad4876e8920bdae01d9b257106629d606e8a958e61df2d48f48f) with SIGTERM" time="2020-12-22T19:15:23+01:00" level=debug msg="Removing container 39870e8c038fad4876e8920bdae01d9b257106629d606e8a958e61df2d48f48f" time="2020-12-22T19:15:24+01:00" level=info msg="Removing image sha256:c97723e0dae5329c96bc33e4a3cec3f3eb611469e1ab3e0a263207221878de16" time="2020-12-22T19:15:24+01:00" level=info msg="Starting Watchtower and scheduling first run: 2020-12-23 19:15:00 +0100 CET" Ce qui m'étonne c'est qu'il n'est mention nulle part dans ce log de téléchargement d'une nouvelle image... comme c'est le cas par exemple là : 2020-12-17 19:15:20 (info): Found new grafana/grafana:latest image (sha256:3c7f996712896e42940e010623c44d35754d8bb447a777971578dea5050186f7) 2020-12-17 19:15:28 (info): Stopping /monitoring_grafana (d5c024d4eacb778294b7d414748a92409945dc4e3045dca7ed6d5da8dd319edc) with SIGTERM 2020-12-17 19:15:34 (info): Creating /monitoring_grafana 2020-12-17 19:15:37 (info): Removing image sha256:71716d95fc524f8599bece0a09cd16a8176f5d51e3258ee130626030e6d89862 Comment je peux connaitre la version de watchtower installée ? Je ne peux pas entrer dans la ligne de commande du conteneur via Portainer, et je ne sais pas faire directement depuis iTerm... Sinon le conteneur a été créé le : 2020-12-22 19:15:17 Donc juste après avoir reçu les emails de notification. Modifié le 22 décembre 2020 par MilesTEG1 0 Citer
.Shad. Posté(e) le 22 décembre 2020 Auteur Posté(e) le 22 décembre 2020 Tape en SSH sur le NAS : docker ps Et vérifie que tu voies la même chose que sur Portainer. 0 Citer
MilesTEG1 Posté(e) le 22 décembre 2020 Posté(e) le 22 décembre 2020 ça indique la même chose ^^ 0 Citer
MilesTEG1 Posté(e) le 14 janvier 2021 Posté(e) le 14 janvier 2021 Hello, J'ai depuis quelques temps ces messages, dans des emails séparés : Found multiple running watchtower instances. Cleaning up. Stopping /tKFQbnQXXXXXXXXXXXXXXXXppgUWf (69551232a9dd213522f87000000000000000000009199c6c9e71ac506e71bd) with SIGTERM Removing image sha256:2ddeb26d6d30132b5XXXXXXXXXXXXXXXXXb16a08a8e7efba947cd84fc1 Starting Watchtower and scheduling first run: 2021-01-11 20:00:00 +0100 CET Pourquoi ça me dit qu'il y a plusieurs instance de Watchtower en cours ?? Comment le vérifier ? et faire en sorte qu'il n'y en ait qu'une seule ? Et aussi, j'ai toujours des volumes non utilisés : Alors que normalement j'ai mis ce qu'il fallait dans le docker-compose pour que ça supprime les volumes inutilisés : Si vous avez des idées ^^ 0 Citer
Jeff777 Posté(e) le 14 janvier 2021 Posté(e) le 14 janvier 2021 (modifié) Bonjour @MilesTEG1 Je n'ai pas de réponse mais j'ai eu exactement le même problème. J'ai l'impression qu'un redémarrage du NAS ou peut-être simplement du container crée une nouvelle instance. Le nombre de volumes unused était impressionnant, je les ai supprimés. Modifié le 14 janvier 2021 par Jeff777 0 Citer
.Shad. Posté(e) le 14 janvier 2021 Auteur Posté(e) le 14 janvier 2021 (modifié) J'ai les mêmes messages, mais les volumes non utilisés sont liés à un autre conteneur, c'est une conséquence. Un conteneur crée des volumes, on peut voir ces volumes dans le Dockerfile : On voit tout en bas : VOLUME /config /sync Ca veut dire que si l'on ne monte qu'un des deux volumes, par exemple /config, dans notre fichier docker-compose, Docker va créer ce qu'on appelle un "volume" Docker qui comprendra les fichiers que l'image place dans /sync, et ce sera un dossier créé dans les répertoires dédiés à Docker, dans /volume1/@docker/... (qui est un lien symbolique de /var/packages/Docker/...) Ces dossiers sont non persistants, donc à chaque fois que le conteneur est supprimé, le volume n'est plus utilisé, à la recréation du conteneur, un nouveau volume sera créé. D'où la liste de volumes non utilisés, il suffit d'identifier quel volume de quelle image tu ne définis actuellement pas dans tes fichiers docker-compose. Pour éviter qu'ils aient un nom bâtard, et que les données persistent, c'est simple : version: ... services: blabla... ... volumes: - exemple:/etc ... volumes: exemple: Ca va te créer un volume Docker qui aura pour chemin : /volume1/@docker/volumes/exemple/_data/... Pour l'histoire des instances multiples, il faudrait aller voir sur le Github de Watchtower, je l'utilise sur 4 machines différentes et toutes ont ce message après mise à jour. Modifié le 14 janvier 2021 par .Shad. 0 Citer
MilesTEG1 Posté(e) le 14 janvier 2021 Posté(e) le 14 janvier 2021 @.Shad. @Jeff777 Merci pour vos réponses. Du coup j'ai regardé ces volumes inutilisés, et c'est toujours ce chemin (sauf le hash shamachin) : /volume1/@docker/volumes/d2d56f5985e73307f1d1501e99005a257a552fe26eeed4a698394f58b485a269/_data Du coup faut que je me tape tous les dépôts pour identifier dans les fichiers dockerfile celui qui me fait ce dossier _data. J'ai ceci comme conteneur, si vous savez lequel utiliser le dossier _data avant que j'ai fini de parcourir les dépôts 😄 0 Citer
MilesTEG1 Posté(e) le 14 janvier 2021 Posté(e) le 14 janvier 2021 J'ai trouvé, c'était le conteneur arrêté SCENARI... Et si je crée un volume pour lui dans le fichier docker-compose, bah ça fonctionne plus... Bon après, je faisais des tests pas très concluants avec... Je pense que je vais le supprimer. 0 Citer
.Shad. Posté(e) le 14 janvier 2021 Auteur Posté(e) le 14 janvier 2021 il y a 36 minutes, MilesTEG1 a dit : Et si je crée un volume pour lui dans le fichier docker-compose, bah ça fonctionne plus... Aucune raison que ça ne fonctionne plus, es-tu sûr d'avoir déclaré le volume correctement dans la section volumes du fichier docker-compose ? 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.