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

[.Shad.]

WATCHTOWER

 

1. Préambule

Le but de ce tutoriel est de mettre en place une application, containrrr/watchtower (Docker Hub, Github) qui va vérifier suivant un intervalle que vous définirez la présence d'une nouvelle version pour totalité ou partie de vos images Docker.
C'est un fork de v2tec/watchtower qui n'est maintenant plus mis à jour depuis près de deux ans.
Ce tutoriel se basait historiquement sur l'image pyouroboros/ouroboros, qui n'est plus maintenue.

NOTES : Les commentaires concernant watchtower (et pas ouroboros) commencent au milieu de la page 2.

Avantages :
- Plus besoin de vérifier via Docker Hub si une mise à jour est disponible
- Processus entièrement automatisé
- Ne consomme quasi aucune ressource

Inconvénients :
- Nécessite un accès à docker.sock, d'un point de vue sécurité ça peut être gênant pour certains
- Suivant l'intervalle de vérification que vous définissez, la quantité de données échangée peut être importante, à surveiller si vous avez un quota
- On ne peut l'installer par l'interface Docker de DSM (en fait si, mais c'est fastidieux).

Je pondérerai le volet concernant la sécurité, si vous avez bien respecté les conseils de sécurité développés dans les tutoriels de référence de ce forum vous ne devriez pas avoir de souci à vous faire.

2. Prérequis

- Savoir se connecter en SSH (root)
- Avoir Docker installé sur son NAS

C'est parti !

On commence par se connecter en SSH avec l'utilisateur root (voir le tutoriel  [TUTO] Accès SSH et ROOT via DSM 6).
On télécharge l'image :

docker pull containrrr/watchtower

Il ne reste plus qu'à créer le conteneur, mais il est avant tout intéressant de voir les fonctionnalités que l'application propose dans la documentation, et en particulier sur cette page.
C3es paramètres sont personnalisés par l'ajout de variables d'environnement à la création du conteneur.

3. Configuration

3-A. Fréquence de mise à jour

- INTERVAL : Définit un intervalle de mise à jour en secondes.
Ex : WATCHTOWER_POLL_INTERVAL=300
- SCHEDULING : Le plus intéressant pour des particuliers je trouve, cron permet de définir une périodicité très personnalisable : tous les x jours, tous les mardi, 3 fois par jour le mercredi et le vendredi, à telle heure, x fois par mois, etc... la documentation de l'image renvoie vers ce site, mais je trouve ce générateur ou celui-ci très pratiques. L'image utilise un format CRON à 6 champs, contrairement aux liens ci-avant qui n'utilisent que 5 champs, en réalité, tous les champs sont décalés vers la droite pour proposer un réglage sur les secondes.
Donc au lieu d'avoir :
minutes | heures | jour du mois | mois | jour de la semaine vous avez secondes | minutes | heures | jour du mois | mois | jour de la semaine
Ex : WATCHTOWER_SCHEDULE=0 0 5 * * 6
Cela correspond à une exécution hebdomadaire, tous les samedi matin à 5:00
Un conseil : Évitez d'utiliser 2:00 ou 3:00, à cause des changements d'heure 😉 

Ces deux méthodes sont exclusives, c'est donc l'une ou l'autre.

3-B. Tri sélectif

Par défaut, watchtower surveille tous les conteneurs. Mais on ne souhaite pas spécialement mettre à jour tous ses conteneurs automatiquement, certains sont gérés par des scripts de mise à jour (Bitwarden par exemple), d'autres sont peu maintenus, et il est plus risqué de mettre à jour aveuglément ce type d'images que celles issues de collectifs reconnus (Linuxserver, Bitnami, etc...). Plusieurs méthodes de tri sont proposées :

- LABEL ENABLE : Permet d'utiliser les labels (des tags en quelque sorte) comme signes de distinction. Lorsqu'on crée un conteneur, on peut décider de lui ajouter un label, composé d'un intitulé et d'une valeur de type chaîne ou entier. Pour permettre à watchtower de mettre à jour un conteneur donné, il doit avoir parmi ses labels :

com.centurylinklabs.watchtower.enable=true

L' avantage énorme c'est que le nom du conteneur cible n'a pas d'importance, le fait qu'il n'existerait plus à un instant t n'a pas davantage d'incidence.
Pour faire en sorte que la sélection des conteneurs à surveiller se fasse par label, il faut ajouter la variable suivante à la création du conteneur watchtower :
WATCHTOWER_LABEL_ENABLE=true
- FULL EXCLUDE (Ce n'est pas une variable d'environnement !!) : L'approche est exclusive au lieu d'être inclusive, elle se base sur le comportement par défaut de watchtower (surveillance de tous les conteneurs), mais il n'y a ici aucune variable d'environnement à préciser à la création du conteneur watchtower, en revanche les conteneurs que vous ne souhaiteriez pas surveiller doivent avoir le label suivant :

com.centurylinklabs.watchtower.enable=false

Notes :
- Il n'est pas possible d'ajouter un label à un conteneur déjà existant. Il faut le recréer et insérer le label dans le script de création du conteneur. Si vous savez les recréer facilement (peu de paramètres à entrer, vos volumes sont persistants et les fichiers de configuration sont maintenus à la suppression du conteneur, ou si vous utilisez docker-compose) alors je préconise la méthode des labels, dans le cas contraire préférez la méthode FULL EXCLUDE.
- La documentation est particulièrement claire à ce sujet.

3-C. Gestion des images

- CLEANUP : Supprime la version précédente de l'image quand une plus récente a été téléchargée et qu'un nouveau conteneur a été créé. Cette fonctionnalité est désactivée par défaut.
Ex : WATCHTOWER_CLEANUP=true
- ROLLING RESTART : Par défaut, watchtower met à jour toutes les images avant de relancer les conteneurs, cette variable d'environnement permet de relancer les conteneurs au fur et à mesure, utilise si on souhaite réduire les périodes d'indisponibilités.
Ex : WATCHTOWER_ROLLING_RESTART=true
- WAIT UNTIL TIMEOUT : Par défaut, watchtower attend 10 secondes qu'un conteneur s'arrête une fois le signal d'extinction transmis. Certaines applications lourdes nécessitent plus de temps, cette variable permet d'ajuster ce délai.
Ex : WATCHTOWER_TIMEOUT=30s

Notes :
- On notera la présence du "s" pour "seconde".

- LINKED CONTAINERS : Certains conteneurs peuvent nécessiter que d'autres conteneurs soient opérationnels avant d'être créés, on prend souvent comme exemple le cas typique d'une application et d'une base de données. Afin d'éviter des erreurs, on souhaite que la base de données soit disponible avant l'application à la création, et inversement à la suppression. Ces relations existent par exemple lorsqu'on utilise l'argument --link en ligne de commande, ou avec l'instruction depends_on via docker-compose. On peut écraser ces réglages via le label :

com.centurylinklabs.watchtower.depends-on

tel que par exemple, si on applique ce label à un conteneur MariaDB :

com.centurylinklabs.watchtower.depends-on=wordpress,caldav

En cas de mise à jour disponible pour ce dernier, watchtower arrêtera au préalable les conteneurs wordpress et caldav.

3-D. Autres paramètres

- DEBUG : Augmente le niveau de verbosité du stdout dans les logs du conteneur.
Ex :  WATCHTOWER_DEBUG=true
- TRACE : Un debug encore plus verbeux, attention les credentials éventuels sont en clair !
Ex :  WATCHTOWER_TRACE=true
- TZ : Permet de définir le fuseau horaire, assure le lien entre la variable CRON si vous l'utilisez et votre fuseau horaire. La liste des timezone est disponible à cette adresse.
Ex : TZ=Europe/Brussels

Il y a encore énormément de fonctionnalités que je n'aborderai pas ici, citons parmi les plus notables :
- les notifications => https://containrrr.dev/watchtower/notifications/
- La supervision de plusieurs instances Docker via un seul conteneur watchtower => https://containrrr.dev/watchtower/remote-hosts/ et https://containrrr.dev/watchtower/secure-connections/ (pour une connexion sécurisée (TLS), une lecture de https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ peut être instructive 😉)
- la possibilité d'exécuter des scripts avant et après la mise à jour (par l'utilisation de labels) => https://containrrr.dev/watchtower/lifecycle-hooks/
- la possibilité d'utiliser d'autres dépôts que Docker Hub, ouvrant la voie à des dépôts privés => https://containrrr.dev/watchtower/private-registries/

Au final ce tutoriel se contente de traduire et de mettre en valeur les variables importantes, la documentation (je crois que je me répète 😛) est très complète.

4. Création du conteneur

On a maintenant tous les outils en main, on va pouvoir créer notre conteneur. Pour se faire, plusieurs possibilités :

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

Notes :
- On est obligé de monter en volume le socket Docker au vu des opérations que doit pouvoir effectuer watchtower sur les autres conteneurs.
- On peut tout à fait demander via le label de mise à jour que watchtower se mette lui-même à jour.

Si tout a bien fonctionné, vous devriez avoir comme retour une suite de chiffres et de lettres (correspondant à l'ID du conteneur), il ne reste plus qu'à le démarrer :

docker start watchtower

4-B. Par Docker-compose (SSH)

Une autre personnalisation de l'image au format docker-compose : docker-compose.yml

version: '2.1'
services:

   watchtower:
      image: containrrr/watchtower
      container_name: watchtower
      hostname: watchtower-nas
      network_mode: bridge
      environment:
         - WATCHTOWER_NOTIFICATIONS=email
         - WATCHTOWER_CLEANUP=true
         - WATCHTOWER_DEBUG=true
         - WATCHTOWER_LABEL_ENABLE=true
         - WATCHTOWER_TIMEOUT=30s
         - WATCHTOWER_SCHEDULE=0 0 5 * * 6
         - TZ=Europe/Brussels
      env_file:
         - /volume1/docker/watchtower/watchtower.env
      labels:
         - "com.centurylinklabs.watchtower.enable=true"
      volumes:
         - /var/run/docker.sock:/var/run/docker.sock
         - /volume1/docker/watchtower/config.json:/root/.docker/config.json
      restart: unless-stopped

Notes :
- J'ai cette fois-ci ajouté les notifications par mail, mais on remarque qu'on ne retrouve pas les autres variables qui sont liées au relais SMTP (https://containrrr.dev/watchtower/notifications/#email). En réalité, pour des raisons de confidentialié, j'ai regroupé les variables qui sont plus "sensibles" dans un fichier .env qui est invoqué par :

env_file:
   - /volume1/docker/watchtower/watchtower.env

Fichier qui se présente sous la forme, et dont les permissions sont correctement réglées pour assurer le niveau de confidentialité désiré :

WATCHTOWER_NOTIFICATION_EMAIL_FROM=...
WATCHTOWER_NOTIFICATION_EMAIL_TO=...
WATCHTOWER_NOTIFICATION_EMAIL_SERVER=...
WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=...
WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=...
WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=...
WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG=...

- J'ai monté le fichier config.json pour y ajouter des credentials pour des dépôts privés.

Pour créer le conteneur, on se place (cd) dans le dossier où se trouve le fichier docker-compose.yml et on tape :

docker-compose up -d

5. Configuration

Ci-après un exemple de logs suite à un déclenchement programmé de Watchtower :

2020-11-14 05:01:31 (info): Found new grafana/grafana:latest image (sha256:68f75fcab5a9372fb0844f5898c65a40b0ca34cff4176e269bade17ddb17ee75)
2020-11-14 05:01:48 (info): Found new telegraf:latest image (sha256:146c415345a26f48f8ef06c2f62ebde90c8ca4ca518db5d88137e60eeb0abeec)
2020-11-14 05:01:59 (info): Found new authelia/authelia:latest image (sha256:d05b2f15beecd4c164a861e0464ddfef1d574b1c67f8e343779daec26c7bbde9)
2020-11-14 05:03:17 (info): Found new linuxserver/mariadb:latest image (sha256:f48f265a3ed8b786973e85c2c681f2f79db1b64d38660c43900bfc48651c6f83)
2020-11-14 05:03:19 (info): Stopping /grafana (bfdbba3a284d51c1a5c5c807f8583857a0c6a03718a083e93e5bcf9671f7130f) with SIGTERM
2020-11-14 05:03:21 (info): Stopping /telegraf (56e1c8624a98344cba07ca6f745c0cd8a93d66b36ebc0af8992cac210c8e0d51) with SIGTERM
2020-11-14 05:03:22 (info): Stopping /authelia (6d4202898398cf0b46886d38c6591a15b83334e00fe20a0025fcd4437747f84c) with SIGTERM
2020-11-14 05:03:23 (info): Stopping /mariadb (763aeebe73c029c20de2a15d114c054ba70b26879fdaf82b3019944179f31573) with SIGTERM
2020-11-14 05:03:27 (info): Creating /mariadb
2020-11-14 05:03:31 (info): Creating /authelia
2020-11-14 05:03:34 (info): Creating /telegraf
2020-11-14 05:03:40 (info): Creating /grafana
2020-11-14 05:03:42 (info): Removing image sha256:ec8e3ebf50429170fa6387bb04e64e5b5f3d87f3221c42750b7fb5d922c5e978
2020-11-14 05:03:43 (info): Removing image sha256:48121fbe19c845fa401be9fdbf3cbeef50840b7537d8a0b9ca2eab081117beb6
2020-11-14 05:03:43 (info): Removing image sha256:7606d5ee069fcab20036c4bd521e1133ac8ca31e44f7d241f0d83a36315d6ca6
2020-11-14 05:03:43 (info): Removing image sha256:900b03b57e41a8bf7f43b8979872bb2d6642d9a4bcb738d053fb67e1d989e926

MàJ : 10/04/2021

Modifié le 6 janvier 2022 par .Shad.
Numérotations paragraphe + ajout hostname

[Superthx]

Salut @shadowking

Merci pour le tuto qui va bien me servir......

Mais j'ai plusieurs questions:

Le 28/07/2019 à 15:31, shadowking a dit :

- MONITOR [chaîne] : On liste le nom des containers (pas des images) que l'on souhaite mettre à jour.

As-tu un exemple ??? Faut-il le mettre dans le docker-compose environment ? Du style

environment:
            -   MONITOR = grafana
-   MONITOR = jackett

 

Le 28/07/2019 à 15:31, shadowking a dit :

LABEL_ENABLE [booléen : true ou false] : Permet d'utiliser des labels (des tags) comme signe de distinction. Lorsqu'on crée un container, on peut décider de lui ajouter un label, et lui attribuer une valeur, de type chaîne ou entier. Ici ouroboros propose parmi d'autres labels, le label com.ouroboros.enable qui permet, si la valeur qui lui est attribuée est true, de mettre à jour les containers ayant cette propriété. L' avantage énorme c'est que le nom du container cible n'a pas d'importance, comme le fait qu'il n'existerait plus.

 

Le 28/07/2019 à 15:31, shadowking a dit :

La mise à jour se fera uniquement pour les containers ayant été créés avec le label com.ouroboros.enable ayant la valeur true.

Et comment mettre à jour ceux déjà existants ? Faut-il rajouter un label ? Comment ?

Si tu peux m'aider.......

Merci

[.Shad.]

Hello,

Le wiki donne plus d'infos à ce sujet, à titre d'exemple :

Citation

-e MONITOR="nginx telegraf portainer"

Donc les uns à la suite des autres. Avec le "-e" en lignes de commande, et dans environment comme tu dis dans le fichier docker-compose.

Pour les labels, c'est à la création d'un container que ça s'ajoute oui, donc il faut recréer les containers qu'on souhaite mettre à jour si on veut utiliser cette méthode.

Si tu n'utilises pas docker-compose ou que tes données ne sont pas persistantes ça peut être compliqué de tout refaire, dans ce cas-là autant passer par MONITOR ou IGNORE suivant le nombre.

Pour ajouter un label, voir l'exemple de ligne de commande ou le fichier docker-compose joint.

Modifié le 1 août 2019 par shadowking

[Superthx]

Hello @shadowking

Il y a 5 heures, shadowking a dit :

Pour les labels, c'est à la création d'un container que ça s'ajoute oui, donc il faut recréer les containers qu'on souhaite mettre à jour si on veut utiliser cette méthode.

Donc je prends l'exemple de jackett j'ai crée son fichier compose comme cela:

version: "2"
services:

  jackett:
    image: linuxserver/jackett                               
    container_name: jackett
    network_mode: bridge          
    environment:
      - PUID=1024
      - PGID=100
      - TZ=Europe/Madrid
      - RUN_OPTS=run options here #optional
      
    labels:
      -   "com.ouroboros.enable=true"
    volumes:
      - /volume1/docker/jackett/config:/config
      - /volume1/docker/jackett/downloads:/downloads
    ports:
      - 9117:9117
    restart: unless-stopped

Est-ce bien comme cela qu'il faut rajouter labels ? Si c'est le cas il me reste plus que recréer les compose de chaque.

EDIT :

et pour celui de ourobouros

version: "2"
services:

    ouroboros:
        image: pyouroboros/ouroboros
        container_name: ouroboros
        network_mode: bridge
        environment:
            - CLEANUP=true
            - SELF_UPDATE=true
            - LOG_LEVEL=debug
            - LABEL_ENABLE=true
            - LABELS_ONLY=true
            - CRON="0 * * * *"
            - TZ=Europe/Madrid
            - MONITOR="jackett grafana influxdb telegraf"
        labels:
            - "com.ouroboros.enable=true"
        volumes:
            - "/var/run/docker.sock:/var/run/docker.sock"
        restart: unless-stopped

Merci de ton aide.

Modifié le 1 août 2019 par Superthx

[.Shad.]

Oui pour jackett.
Non pour ouroboros.

Là tu utilises la variable LABELS_ONLY, donc par conséquent il ne se basera que sur ce critère pour mettre à jour les containers, MONITOR sera donc complètement ignoré.
Ce que tu peux faire c'est avoir LABEL_ENABLE=true, ne pas utiliser LABELS_ONLY (donc false par définition), et laisser MONITOR, même si ça n'a pas beaucoup de sens à mon goût.

Pour moi, les deux "bonnes" solutions sont :

version: "2"
services:

    ouroboros:
        image: pyouroboros/ouroboros
        container_name: ouroboros
        network_mode: bridge
        environment:
            - CLEANUP=true
            - SELF_UPDATE=true
            - LOG_LEVEL=debug
            - LABEL_ENABLE=true
            - LABELS_ONLY=true
            - CRON="0 * * * *"
            - TZ=Europe/Madrid
        labels:
            - "com.ouroboros.enable=true"
        volumes:
            - "/var/run/docker.sock:/var/run/docker.sock"
        restart: unless-stopped

et t'assurer que les autres containers (jackett, influxdb, telegraf, grafana) ont bien le label "com.ouroboros.enable=true".

Ou bien :

version: "2"
services:

    ouroboros:
        image: pyouroboros/ouroboros
        container_name: ouroboros
        network_mode: bridge
        environment:
            - CLEANUP=true
            - SELF_UPDATE=true
            - LOG_LEVEL=debug
            - CRON="0 * * * *"
            - TZ=Europe/Madrid
            - MONITOR="jackett influxdb grafana telegraf"
        labels:
            - "com.ouroboros.enable=true"
        volumes:
            - "/var/run/docker.sock:/var/run/docker.sock"
        restart: unless-stopped

Pour le coup je me dis qu'ajouter le label à ouroboros lui-même ne doit pas être utile, car SELF_UPDATE va gérer l'auto màj.
Ça peut être utile si un autre container ouroboros devait mettre à jour celui-ci, cas peu probable... 😛

Modifié le 1 août 2019 par shadowking

[Superthx]

Ok, c'est parfait. Merci encore..........

[.Shad.]

De rien !

[Superthx]

Le 28/07/2019 à 15:31, shadowking a dit :

Notes :
- Il n'est pas possible d'ajouter un label à un container déjà existant. Il faut le recréer et insérer le label dans le script de création du container. Si vous savez les recréer facilement (peu de paramètres à entrer, vous avez monté assez de volumes pour assurer la persistance des données, ou si vous utilisez docker-compose) alors je préconise la méthode des labels, dans le cas contraire préférez MONITOR ou IGNORE suivant l'envie.
- Une variable d'environnement non précisée dans un script est considérée comme false ou vide. Si par exemple vous utilisez la variable MONITOR, aucun besoin de préciser LABEL_ENABLE=false, c'est sous-entendu. Inversement, si vous utilisez la méthode des labels, implicitement ça signifie MONITOR=" ".

Je me demande si cette option sous portainer permet de rajouter le label :

 

[.Shad.]

Tout à fait.

[.Shad.]

Attention, pour ceux qui ont mis à jour le paquet Docker dernièrement (et docker-compose par la même occasion), ouroboros risque de poser problème.

La faute à Synology, leur version de docker-compose ne prend pas en compte les variables d'environnement à la création d'un container. Donc pour un container créé avant la mise à jour, aucun souci tant que vous n'y touchez pas.

Mais si ouroboros le recrée parce qu'une nouvelle version est disponible, il ne fonctionnera plus s'il a des variables d'environnement.

Pour l'instant, le mieux à faire :

- Ne pas mettre à jour
- Rollback à la version 17.05
- Stopper le container Ouroboros

Synology est au courant du bug et s'applique à déployer un correctif d'ici peu.

Modifié le 4 septembre 2019 par shadowking

[mister_sam]

Le soucis a été corrigé depuis septembre ?

je n'ai pas l'impression 🙄

[.Shad.]

Hello,

Chez moi ça remarche déjà depuis quelques temps, j'ai vérifié sur mon container telegraf, il a été créé à l'heure correspondant au cronjob d'ouroboros.

Ma version de docker :

Il se peut cela dit qu'il faille recréer les containers après la dernière màj.

[LeMorse]

Toujours super détaillé ! Merci 😉

[Darkomen78]

Salut, cette méthode est toujours d'actualité ? Je vais peut-être mettre les pieds dans le plat (je débute plus ou moins dans le monde Docker) mais pyouroboros à l'air d'être abandonné 

Citation

 ouroboros is no longer in development.

alors que watchtower à été mis à jour récemment (4jours) et la dernière release est du 1er juin.

Donc au final pour mettre à jour mes container, vaut mieux que je me penche sur watchtower non ? 

[.Shad.]

Salut,

Oui en effet pyouroboros n'est plus en développement, en revanche comme le disent ses devs dans leur message sur la page Github il fait le job, et perso je l'utilise toujours sans la moindre erreurs sur 3 machines différentes.
Mais tu peux aussi tout à fait t'orienter vers watchtower dont le développement a récemment repris (attention par contre j'avais lu sur un forum qu'il y avait a contrario de pyouroboros pas mal de petits bugs).

J'ajouterai que ce guide te sera quand même utile parce que tu peux transposer la logique de l'un à l'autre, pyouroboros étant à la base un fork de watchtower il en a repris la structure, et le nouveau watchtower reprend cette même logique.

Modifié le 25 juillet 2020 par .Shad.

[Darkomen78]

Merci pour la réponse. Je me tâte encore à mettre en place une mise à jour automatique de mes containers.

Au final dans ceux que j'utilisent, ceux qui sont mis à jour le plus souvent ont déjà un système interne de mise à jour (Homebridge, PiHole, Controler Unifi) et les autres sont rarement voir presque jamais mis à jour (Mumble, Sonarr, NZBget, Bazarr).

 

 

[oracle7]

@.Shad.

Bonjour,

Avant d'installer le conteneur ouroboros, pour ma compréhension j'aurais deux questions :

1. Soit :
   1. dans le fichier docker-compose.yml d'ouroboros, on ajoute dans la partie "environnement:" une ligne du type " - MONITOR="grafana influxdb telegraf" " avec " - LABEL_ENABLE=false " (ou non définie),
      OU bien
   2. Soit dans le fichier docker-compose.yml de chaque conteneur que j'utilise (ex : influxdb, graphana, telegraf), on ajoute dans la partie "labels:" une ligne du type " -   "com.ouroboros.enable=true" " .
      
      Ces ajouts de lignes sont exclusif l'un de l'autre. J'ai bon ?
       
2. Pour le réseau à utiliser avec ouroboros, est-ce que je peux utiliser le même que celui défini pour mon monitoring global, ce qui me permettrait d'affecter une @IP spécifique au conteneur "ouroboros" ?

 

Ce qui donnerait pour le fichier docker-compose/yml de outoboros :

version: "2.1"
services:

    ouroboros:
        image: pyouroboros/ouroboros:latest
        container_name: ouroboros
        network_mode: bridge
        environment:
            - CLEANUP=true
            - SELF_UPDATE=true
            - LOG_LEVEL=debug
            - CRON="30 1 * * *"
            - TZ=Europe/Paris
            - MONITOR="influxdb grafana telegraf"
        labels:
            -   "com.ouroboros.enable=true"
        volumes:
            -   "/var/run/docker.sock:/var/run/docker.sock"
        mac_address: d2:ca:ab:cd:00:05
        networks:
            monitoring:
                ipv4_address: 172.20.0.5
        restart: unless-stopped

Cordialement

oracle7😉

Modifié le 29 septembre 2020 par oracle7

[.Shad.]

Salut,

Personnellement j'utilise la méthode 1.2 plutôt, ainsi je n'ai rien à ajouter à ouroboros quand je crée un nouveau conteneur.

Pour info j'ai switché vers watchtower qui est nouveau activement développé, mais c'est peu ou prou la même méthode que pour ouroboros :

version: '2.1'
services:

   ouroboros:
      image: containrrr/watchtower
      container_name: watchtower
      hostname: watchtower
      network_mode: bridge
      environment:
         - WATCHTOWER_NOTIFICATIONS=email
         - WATCHTOWER_NOTIFICATION_EMAIL_FROM=XXX
         - WATCHTOWER_NOTIFICATION_EMAIL_TO=XXX
         - WATCHTOWER_NOTIFICATION_EMAIL_SERVER=XXX
         - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=XXX
         - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=XXX
         - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=XXX
         - WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG=[DS918+]
         - WATCHTOWER_CLEANUP=true
         - WATCHTOWER_DEBUG=true
         - WATCHTOWER_LABEL_ENABLE=true
         - WATCHTOWER_TIMEOUT=30s
         - WATCHTOWER_SCHEDULE=0 0 5 * * 6
         - TZ=Europe/Brussels
      labels:
         - "com.centurylinklabs.watchtower.enable=true"
      volumes:
         - /var/run/docker.sock:/var/run/docker.sock
         - ./config.json:/root/.docker/config.json
      restart: unless-stopped

 

[oracle7]

@.Shad.

Bonjour,

Merci de ta réponse.

Je ne comprend pas : dans ton fichier docker-compose.yml ci-dessus, le service s'appelle "ouroboros" et le  hostename "watchtower" ? le service ne devrait-il pas aussi s'appeler "watchtower" ?

Sinon tu n'as pas répondu à ma question vis à vis du réseau à utiliser (point 2).

Cordialement

oracle7😉

[.Shad.]

Ah ouais une coquille de ma part ! Merci de l'avoir vue, comme tu vois c'était tellement semblable que je suis reparti du même fichier, et y a eu un oubli au passage.
Tu peux le mettre sur le réseau que tu veux, l'idéal étant d'éviter d'exposer des conteneurs entre eux si ce n'est pas utile.
Attention par contre, dans le fichier docker-compose que j'ai fourni, j'utilise le paramètre :

network_mode: bridge

Ce qui veut dire que j'utilise le bridge par défaut, donc dans la plage 172.17.0.0, et le conteneur prend par défaut la prochaine IP libre.
Dans ce cas-là il ne faut pas utiliser le paramètre networks.
Ou alors inversement, tu supprimes network_mode: bridge et tu laisses bien le paramètre networks et les options que tu y adjoins.

Quand tu mets des conteneurs dans un même réseau bridge personnalisé, tous les conteneurs exposent tous leurs ports entre eux.
Pas forcément raccord avec la philosophie d'isolation de Docker. 😉 

[Invité]

J'utilise également watchtower !

La notification via Discord ou Gotify est très pratique !

[oracle7]

@.Shad.

Bonsoir,

OK merci pour la précision du réseau.

Il y a 17 heures, .Shad. a dit :

Quand tu mets des conteneurs dans un même réseau bridge personnalisé, tous les conteneurs exposent tous leurs ports entre eux.
Pas forcément raccord avec la philosophie d'isolation de Docker.

Ok je comprend bien mais quel serait le risque de partager quand même le réseau du monitoring avec whatchtower ?

Avec les options WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER et  WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD on inscrit en clair son login/MdP de messagerie. C'est pas terrible du point de vue sécurité ! N'y-a-t-il pas moyen de masquer ces derniers ?

Je vois que dans la partie "volumes:" on monte un fichier config.json.

• Est-ce que avec ce fichier config.json (renseigné manuellement comme décrit dans la doc watchtower au chapitre "Private registries") cela peux le faire ?
• Si oui dans ce cas je ne vois pas bien où il faut placer ce fichier config.json ?
• Directement dans "/volume1/watchtower/" ?
• Du coup comment on renseigne les dites options suscitées ?

Edit : Pour faire suite à mes questions précédentes, après avoir fouillé un peu plus la doc, est-ce que l'on renseigne les options  comme ci-dessous (je suis pas du tout sûr de la syntaxe pour les variables REPO_xxxx) ? :
 

Citation

 

environnement:

    -  WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=REPO_USER

    -  WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=REPO_PASS

 

Cordialement

oracle7😉

Modifié le 30 septembre 2020 par oracle7

[.Shad.]

Il y a 17 heures, oracle7 a dit :

Ok je comprend bien mais quel serait le risque de partager quand même le réseau du monitoring avec whatchtower ?

Quel est l'intérêt ?
Si tu veux contrôler l'IP (pour quelle raison d'ailleurs pour ce conteneur ?), tu peux créer un réseau dans le docker-compose de watchtower où tu fixes son IP.
Je ne vois pas l'intérêt de l'ajouter au réseau de monitoring ?

Il y a 17 heures, oracle7 a dit :

Avec les options WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER et  WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD on inscrit en clair son login/MdP de messagerie. C'est pas terrible du point de vue sécurité ! N'y-a-t-il pas moyen de masquer ces derniers ?

Tu peux utiliser cette solution :

https://docs.docker.com/compose/environment-variables/#the-env-file

Il y a 17 heures, oracle7 a dit :

C'est pas terrible du point de vue sécurité !

Seulement si tu autorises les utilisateurs standards à accéder à ce dossier en lecture.

Il y a 17 heures, oracle7 a dit :

Est-ce que avec ce fichier config.json (renseigné manuellement comme décrit dans la doc watchtower au chapitre "Private registries") cela peux le faire ?

Pas compris la question, le fichier est juste là en cas de dépôt autre, comme des dépôts privés ou comme GitLab.
Vu que j'utilisais l'image d'un ami un temps, j'avais dû monter ce fichier.

Il y a 17 heures, oracle7 a dit :

Si oui dans ce cas je ne vois pas bien où il faut placer ce fichier config.json ?

Tu le places où tu veux, il faut juste que ça corresponde dans le conteneur à : /root/.docker/config.json

Il y a 17 heures, oracle7 a dit :

Du coup comment on renseigne les dites options suscitées ?

Dans le .env_file si tu veux faire mieux d'un point de vue sécurité, sinon dans les variables d'environnement comme je l'ai fait, voir plus avant.

Il y a 17 heures, oracle7 a dit :

environnement:

    -  WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=REPO_USER

    -  WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=REPO_PASS

Ce sont les identifiant et mot de passe de ton compte mail.

[oracle7]

@.Shad.

Bonjour,

Merci d'avoir pris le temps de me répondre.

Il y a 2 heures, .Shad. a dit :

Seulement si tu autorises les utilisateurs standards à accéder à ce dossier en lecture.

Donc pour faire simple si je laisse dans le fichier docker-compose.yml les options WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER et  WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD renseignées avec mon login/MdP en clair et que je restreint les droits en L/E/X (equiv chmod 0700) sur ce fichier, à mon utilisateur administrateur, cela est suffisant ?

Et si Oui, du coup est-ce qu'il faut préciser " user: "UID:GID" " dans le fichier docker-compose.yml ?

Cordialement

oracle7😉

 

 

[.Shad.]

il y a 28 minutes, oracle7 a dit :

Donc pour faire simple si je laisse dans le fichier docker-compose.yml les options WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER et  WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD renseignées avec mon login/MdP en clair et que je restreint les droits en L/E/X (equiv chmod 0700) sur ce fichier, à mon utilisateur administrateur, cela est suffisant ?

Pour moi oui, et tu n'as même pas besoin de la permission d'exécution, r/w suffit donc chmod 600 c'est bon. 👌

il y a 29 minutes, oracle7 a dit :

du coup est-ce qu'il faut préciser " user: "UID:GID" " dans le fichier docker-compose.yml ?

Je ne te le conseille pas, car tu joues avec des fichiers système (/var/run/docker.sock), même si, théoriquement :

si tu utilisais le groupe "docker" caché, ça pourrait le faire.
Mais pour moi il ne faut pas jouer avec ça quand on monte des fichiers système, je te conseille de laisser root/root (donc ne rien préciser dans le docker-compose).