.Shad.

Chez OVH il suffit de créer une entrée dans l'onglet Dynhost avec l'adresse IP WAN actuelle chez toi, et ton nom de domaine. OVH a un robot qui se charge de vérifier si ton IP change et modifie l'enregistrement. Essaie ainsi, heureusement que le proxy inversé n'est pas réserver aux détenteurs d'IP fixe...

Tu as une IP fixe ou une IP dynamique ?

Je suis preneur d'une réponse aussi... La température des disques varie elle, mais jamais du CPU...

Oui il existe des dashboard déjà configurées, sinon si tu crées un nouveau graphique tu vas voir dans la liste des "measurements" l'ajout de nouveaux enregistrements : docker, docker_container_cpu, etc...

On parle de l'instance telegraf du NAS ou celle d'un périphérique externe ? EDIT : Ok 😉

Je ne sais pas si c'est rassurant en cas de défaillance d'un des disques...

Tout à fait.

De rien !

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

Hello, Le wiki donne plus d'infos à ce sujet, à titre d'exemple : 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.

Dans les faits, le container mssql utilise bien moins de mémoire qu'à mes premières versions. Je dépasse rarement 200 Mo de mémoire vive. Et puis l'idée de soutenir le projet Bitwarden me plaît assez, j'ai souscrit à l'offre premium et j'ai fait une organisation avec ma famille, honnêtement je ne pourrais plus m'en passer...

Pour la dernière mise à jour, la 1.31.1, il faut créer le dossier .../bwdata/logs/events sinon l'installation plante.

Bienvenue !

@seb_74 Moi je te dis de le cocher si tu te connectes en HTTPS (port 7001 et option HTTPS cochée) et de le décocher si tu te connectes en HTTP (port 7000, option HTTPS décochée). Au vu de ta réponse je ne suis pas sûr que ce soit ce que tu fais. 😉

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

Ajout de la partie concernant le monitoring d'un raspberry.

Il y a toujours l'option d'installer Docker manuellement sur ton DS216se, mais le packagé n'étant "officiellement" pas compatible, Synology n'offrira pas de support pour cette application. Mais ça te permettrait de t'affranchir de toutes les limitations dues à la version de DSM d'un autre côté. Et comme le dit Zeus, le portail d'applications doit pouvoir fournir tout ce dont tu as besoin. Tu peux même depuis quelques mises à jour ajouter des en-têtes personnalisés pour chaque entrée.

Si tu y accèdes depuis ton smartphone en 4G c'est que nécessairement le port 5001 est redirigé. As-tu vérifié que la configuration du routeur n'est pas activée sur le NAS et qu'elle n'a pas automatiquement ouvert les portes dont elle estime avoir besoin ? Sur ta box, ça devrait être renseigné sous l'appellation uPnP pour peu que l'information ait été séparée des ports redirigés manuellement.

J'ai ajouté la partie pour monitorer docker. Tuto pour ajout du Raspberry en cours de rédaction...

Et tu as bien cliqué sur la roue crantée en bas à gauche, et coché Vérifier le certificat quand tu actives l'HTTPS ?

Est-ce que la connexion via le port HTTP (7000) et pas HTTPS fonctionne ? (Penser à décocher HTTPS dans DS File)

Le fait d'avoir un routeur et un modem qui ne sont pas en bridge veut dire que tu as un double NAT, donc que les redirections de port doivent être faites deux fois. A moins de vouloir avoir deux réseaux différents, et que les périphériques reliés à la box n'aient aucun intérêt à communiquer avec ce qui se trouve derrière le routeur, c'est juste plus de chipotage. Je suis par contre surpris que tu aies désactivé le serveur DHCP de ta box, quid de l'IP de ta BBox TV (qui est quoi au passage, un décodeur ?). A moins que tu puisses fixer l'IP de celle-ci ?

Lance un transfert de fichier volumineux entre ton NAS et un ordinateur, histoire de voir les débits.

Bloquer port 80 en destination, ça bloquera toutes les requêtes qui arriveront sur le port 80 du NAS. Bloquer port 80 en source, si par exemple ton routeur t'envoie une requête par ce port, ça la bloquera.

Comment te connectes-tu à DS Video ? Quickconnect ? Nom de domaine acheté ?