This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

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


Messages recommandés

WATCHTOWER

logo.png?raw=true

 

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.

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.
Ces paramètres sont personnalisés par l'ajout de variables d'environnement à la création du conteneur.

CONFIGURATION

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

II/ Tri des conteneurs

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.

III/ Process

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

IV/ Autres

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

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 :

a) Via SSH en ligne de commande

Voici un exemple de configuration :

docker create --name=watchtower \
--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

b) Via SSH par docker-compose

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

version: '2.1'
services:

   watchtower:
      image: containrrr/watchtower
      container_name: watchtower
      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 lancer la création du conteneur, on se place (cd) dans le dossier où se trouve le fichier docker-compose.yml et on tape :

docker-compose up -d

RÉSULTAT

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 : 14/11/2020

Modifié par .Shad.
Corrections mineures
Lien à poster
Partager sur d’autres sites
  • Réponses 205
  • Created
  • Dernière réponse

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Et avec l'IP passerelle plutôt que l'IP locale ?

Refonte du tutoriel pour containrrr/watchtower, avec quelques explications supplémentaires. 😉 

Je clique sur le nom d'un conteneur, et cela ce trouve en haut de page   D'accord alors je n'est pas vraiment compris la question, si tu utilise la fonction compose de portai

Posted Images

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

Lien à poster
Partager sur d’autres sites

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é par shadowking
Lien à poster
Partager sur d’autres sites

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é par Superthx
Lien à poster
Partager sur d’autres sites

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é par shadowking
Lien à poster
Partager sur d’autres sites
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 :

730611112_Capturedcran2019-08-0119_40_23.thumb.png.81874c796c2d6f1e507b3e01545f76e7.png

 

Lien à poster
Partager sur d’autres sites
  • 1 month later...

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é par shadowking
Lien à poster
Partager sur d’autres sites
  • 2 months later...

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.

image.png.287e0bc08e0af2acc8a60e1a80da0654.png

Ma version de docker :

image.png.63c80524a091be177edaba9f3b7c15f0.png

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

Lien à poster
Partager sur d’autres sites
  • 6 months later...
  • 1 month later...

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 ? 

Lien à poster
Partager sur d’autres sites

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é par .Shad.
Lien à poster
Partager sur d’autres sites

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

 

 

Lien à poster
Partager sur d’autres sites
  • 2 months later...

@.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é par oracle7
Lien à poster
Partager sur d’autres sites

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

 

Lien à poster
Partager sur d’autres sites

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

Lien à poster
Partager sur d’autres sites

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

Lien à poster
Partager sur d’autres sites

@.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é par oracle7
Lien à poster
Partager sur d’autres sites
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.

Lien à poster
Partager sur d’autres sites

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

 

 

Lien à poster
Partager sur d’autres sites
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 :

watchtower-oracle.jpg

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

Lien à poster
Partager sur d’autres sites
  • .Shad. changed the title to [TUTO] Mise à jour automatique des images et conteneurs Docker

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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.