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 containers Docker


Messages recommandés

Le but de ce tutoriel est de mettre en place une application, ouroboros (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.
C'est un dérivé de v2tec/watchtower qui n'est maintenant plus mis à jour depuis près d'un an.

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

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 Synology

Je pondérerai le volet concernant la sécurité, si vous avez bien respecté les conseils de sécurité développés sur 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 pyouroboros/ouroboros

Il ne reste plus qu'à créer le container, mais il est avant tout intéressant de voir les fonctionnalités que l'application propose sur le wiki, et en particulier sur cette page.

CONFIGURATION

I/ Fréquence de mise à jour

- INTERVAL [entier] : Définit un intervalle de mise à jour en secondes, avec un minimum de 30 secondes si aucun autre paramètre n'influe sur la périodicité des vérifications n'est défini.
Ex : INTERVAL=300
- CRON [expression cron] : Le plus intéressant pour des particuliers je trouve, cela permet de définir très précisément un intervalle non régulier : tous les x jours, tous les mardi, 3 fois par jour le mercredi et le vendredi, à telle heure, x fois par mois, etc... Il existe un site très pratique, crontab.guru, qui permet de comprendre rapidement comment cela fonctionne, et d'avoir une traduction littérale de l'expression cron.

Ex : CRON="0 5 * * *"

II/ Tri des containers

On ne souhaite pas spécialement mettre à jour tous ses containers automatiquement, certains sont gérés par des scripts de mise à jour (Bitwarden), d'autres sont peu maintenus, et il est plus risqué de mettre à jour aveuglément ce type d'images que celles issues d'organismes reconnus (linuxserver par exemple). Plusieurs méthodes de tri sont proposées :

- MONITOR [chaîne] : On liste le nom des containers (pas des images) que l'on souhaite mettre à jour. On sépare le nom de chaque container par un espace, le tout entre crochets. Voir le wiki pour plus d'infos.
Ex MONITOR="nginx telegraf portainer"
- IGNORE [chaîne] : On liste le nom des containers qu'on ne veut pas mettre à jour. Même structure que pour MONITOR.
Ex IGNORE=[nginx telegraf portainer]

- 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. 
Ex : LABEL_ENABLE=true
- LABELS_ONLY [booléen : true ou false] : Étroitement associé à la variable ci-avant, ce paramètre est assez explicite, il désactive tout autre critère de sélection que celui des labels. Doit obligatoirement être accompagné de LABEL_ENABLE pour être pris en compte.

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

III/ Gestion des images

- CLEANUP [booléen : true ou false] : Supprime la version précédente de l'image quand une plus récente a été téléchargée et qu'un nouveau container a été créé.
- SELF_UPDATE [booléen : true ou false] : Ouroboros peut se mettre automatiquement à jour, s'il détecte une version plus récente, il finit la mise à jour des autres containers, puis se met tout seul à jour, et change son nom en ouroboros-updated. A la mise à jour suivante, il reprendra le nom ouroboros, et ainsi de suite... Pour que cette option fonctionne, il faut impérativement que le nom du container à la création soit ouroboros ou bien ouroboros-updated.

IV/ Autres

- LOG_LEVEL [debuf, info, warn, error, critical] : Permet de définir le niveau de détail des logs consultables dans l'interface Synology ou via la commande docker logs container. A titre personnel, je trouve le niveau debug adapté à mon utilisation très basique.
Ex : LOG_LEVEL=debug
- TZ [Timezone] : 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 est également possible de mettre à jour une instance docker située sur une autre machine, pour peu que son port tcp soit exposé sur le réseau (DOCKER_SOCKET), d'exporter des données vers InfluxDB ou Prometheus (voir partie DATA EXPORT du wiki), ou encore de se connecter à des dépôts privés (voir variables REPO_USER et REPO_PASS sur le wiki).

Le wiki est très complet, je n'ai pas tout essayé mais si une option vous intéresse et que vous ne comprenez pas comment l'ajouter, n'hésitez pas à demander sur le fil de discussion, on jettera un oeil ensemble... 😉 

CRÉATION DU CONTAINER

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

a) Via SSH en ligne de commande

Voici un exemple de configuration (méthode label) :

docker create --name=ouroboros --restart=unless-stopped --label "com.ouroboros.enable=true" -e CLEANUP=true -e SELF_UPDATE=true -e LOG_LEVEL=debug -e LABEL_ENABLE=true -e LABELS_ONLY=true -e CRON="0 5 * * *" -e TZ=Europe/Brussels -v /var/run/docker.sock:/var/run/docker.sock pyouroboros/ouroboros

Notes :
- La mise à jour se fera uniquement pour les containers ayant été créés avec le label com.ouroboros.enable ayant la valeur true.
- La mise à jour se fera tous les jours à 5h du matin.

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

docker start ouroboros

b) Via SSH par docker-compose

Script précédent écrit au format docker-compose docker-compose.yml
Pour l'exécuter, on se place dans le dossier où se trouve le .yml, et on l'exécute en tapant :

docker-compose up -d

NOTES

La page du wiki, linkée en début de tutoriel, est très bien faite, et reprend de manière exhaustive la liste des variables d'environnement disponibles.

MàJ : 31/07/19

Modifié par shadowking
Ajout précisions
Lien à poster
Partager sur d’autres sites
  • Réponses 107
  • 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 ?

@.Shad. Alors là "chapeau bas", MERCI Beaucoup voilà une excellente suggestion qui résout finalement le problème. Juste un truc : on récupère dans le log un Warning pour la connexion http qu

Super ! Etrange que cela est besoin d'etre renseigné comme ceci chez toi et pas chez moi ! Pour ton https://gotify.ndd.tld , je suppose qu'il ne te reste qu'a modifier le reverse pour qu'il ne po

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

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.