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

[Invité]

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

[MilesTEG1]

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 ^^

[Invité]

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

 

[MilesTEG1]

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é

[Invité]

Oui oui, l'architecture est x86_64 donc comme moi tu doit utiliser AMD64

[MilesTEG1]

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 ?

[Invité]

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é

[MilesTEG1]

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

[Invité]

Oui sur portainer je force toujours pour la suppression des image ms inutilisé  

[MilesTEG1]

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 ^^

[.Shad.]

Heimdall n'est plus développé depuis déjà longtemps, je suis passé sur Dashmachine personnellement.

[MilesTEG1]

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

[MilesTEG1]

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

 

[Invité]

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

[MilesTEG1]

@EVOTk Haaa, ok, alors tout est normal ^^
Je verrais demain si y a un message du même type ^^

merci

[Einsteinium]

Pour un nettoyage :

docker image prune -f

docker volume ls -qf dangling=true | xargs -r docker volume rm

😉

[MilesTEG1]

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

[.Shad.]

Tape en SSH sur le NAS :

docker ps

Et vérifie que tu voies la même chose que sur Portainer.

[MilesTEG1]

ça indique la même chose ^^

 

[MilesTEG1]

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 ^^

[Jeff777]

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

[.Shad.]

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.

[MilesTEG1]

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

[MilesTEG1]

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.

[.Shad.]

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 ?