.Shad.

Je ne connais pas Lightroom mais ça me semble peu probable que ça puisse saturer un réseau gigabit.

Si tu arrives à saturation de ta bande passante, oui, mais improbable en Gigabit pour une utilisation domestique. Le 2ème port peut servir par exemple à avoir une autre configuration de pare-feu, et desservir une installation IoT. C'est surtout utile en entreprise ou si un nombre d'utilisateurs locaux conséquent sollicitent simultanément le NAS.

Bienvenue !

Nginx est certainement le plus documenté. Personnellement j'utilise HAProxy, moins terre-à-terre que Nginx, et qui permet beaucoup de choses. Traefik permet de créer spontanément une entrée de proxy inversé à chaque nouveau backend. Il faut pour cela ajouter des labels Traefik à la création du conteneur. L'inconvénient du coup c'est que ça ne marche que pour les conteneurs.

Oui telegraf peut faire du "polling" sur des périphériques distants via SNMP. Telegraf est surtout intéressant pour l'export d'information (output plugins), car il prend en charge une multitude de base de données et d'aggrégateur.

La même config ? Sur un dédié tu veux dire ? Le problème avec le SMTP OVH je n'ai jamais réussi à le résoudre, je suis passé par un compte Gmail dédié également.

Dans ton premier post, la redirection semble se faire sur les deux protocoles TCP et UDP. Dans ta dernière impression d'écran, je ne vois qu'UDP. Hormis ce détail ça a l'air bon, après pour être honnête j'avais aussi des soucis inexpliqués d'upload faible, je suis déjà plus d'un an passé sur Deluge et qBittorrent successivement via Docker, c'est le jour et la nuit. De tes posts (je ne vois rien dans ta signature), tu as l'air d'avoir un DS1819+, si c'est le cas tu peux bénéficier du paquet Docker. Si ça t'intéresse j'ai fait un tutoriel pour Docker si tu n'y connais rien : PS : SI tu ne fais qu'autoriser des ports sur ton pare-feu, et que tu ne refuses rien, c'est comme si tu n'en avais pas. Il te manque une règle Refuser - Tous - Tous en dernière ligne (attention que c'est séquentiel, donc il faut bien que ce soit la dernière règle, sinon tu bloques tout ce qui est en-dessous).

Ca veut dire configurer le pare-feu de la manière la plus restrictive que possible. Si tu n'y accèdes que depuis des IP fixes, tu peux limiter à ces IP là, tu peux aussi imposer des limites depuis l'emplacement, par exemple ne limiter qu'à la France. Voir tutoriel sur la sécurisation du NAS.

En effet, Drive fonctionne très bien par le port 6690 en externe, n'autoriser son fonctionnement que par le VPN me semble contre-productif au regard du principe même de l'application (synchronisation continue).

Salut est-ce que le port 16881 est bien ouvert dans le pare-feu du NAS ? Est-ce que la redirection du port se fait bien vers l'IP du NAS depuis ta box ? Est-ce que tu as essayé de voir si le port était ouvert (portion udp seulement) avec un site comme canyouseeme ou équivalent ?

Bienvenue !

@oracle7 : c'est bien ce que je dis, ce n'est pas possible avec l'outil intégré à DSM pour générer les certificats LE. Les seuls wildcard qu'on peut générer directement dans l'interface sont ceux liés aux domaines Synology. ^^

Aux dernières nouvelles, pour un certificat wildcard ce n'est pas possible. Pour un certificat via validation http normalement aucun problème. Ça faisait référence à la remarque de @oracle7 qui dit y arriver.

N'empêche c'était surpuissant pour l'époque ! Je suis assez étonné.

Si tu es connecté en root (sinon rajouter en début de ligne) : synoservice –-stop pkgctl-tvheadend Attention de vérifier les majuscules pour tvheadend, sous Linux ça a son importance. puis : synoservice –-start pkgctl-tvheadend -l /chemindulog /chemindulog doit être le chemin absolu vers l'emplacement de ton choix. Si tu veux le consulter depuis le dossier home d'un utilisateur autre que root, tu peux par exemple indiquer : /volume1/homes/utilisateur/tvheadend.log Remplacer "utilisateur" par un nom d'utilisateur existant.

Bienvenue !

@oracle7 : Aux dernières nouvelles, l'outil de DSM ne permet de le faire que pour les noms de domaine Synology. Et plusieurs ont essayé depuis la màj. On parle bien dans DSM, c'est faisable pour n'importe quel domaine en dehors. Tu peux confirmer ton information ?

Sympa la cadeau 😛 Bienvenue !

Bonjour, merci de passer par la case présentation avant tout, ça aide, par exemple, à connaître ton modèle de NAS et on pourra t'aiguiller. Il y a une section dédiée à ça sur le forum. 🙂

J'ai trouvé ça : https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide#alternative-and-recommended-method-that-fully-integrates-with-synology-nas-system-certificate-management Le vrai problème ici c'est la dernière étape, à savoir l'import dans DSM, et la prise en compte par les applications Syno ET celles du proxy inversé du nouveau certificat. Comme toujours, malheureusement, ce sont les modèles "+" qui permettent de rendre les choses très simples, vous pouvez tout combiner en une seule image Docker : linuxserver/letsencrypt. Pour ceux qui le peuvent, je vous invite vraiment à déporter la gestion de vos certificats. PS : Il y a toute une discussion entre @unPixel et @PPJP au sujet d'un script de renouvellement automatique de certificat wildcard :

C'est l'intérêt d'utiliser un modèle "+" qui permet de faire tourner des applications autres que celles compilées pour DSM 😕 Si tu tapes la commande suivante une fois connecté en root sur ton NAS : synoservice --list tu peux voir la liste des applications, ça devrait se présenter sous la forme pkgctl-... De là, il doit y avoir moyen de faire un script capable de lancer le package avec les arguments qui vont bien.

Bonjour, Déterrage de compétition, mais je rencontre le même problème, j'ai atteint la limite de 10 Mo de fichiers image et texte, et ne peut plus rien héberger sur le forum. Est-ce que cette limite est relevable ou est-ce que je dois supprimer des pièces jointes sur mes réponses ? Merci !

1. Préambule Ce guide a pour but de permettre à tout un chacun de centraliser la gestion de ses conteneurs sur une seule et même instance Docker, et ce de manière sécurisée. Sur une distribution Linux classique ou même Windows il est possible d'exposer une instance Docker via TCP, donc la rendre accessible sur un port de la machine hôte, 2375 en non-sécurisé, 2376 par TLS. De manière générale c'est quelque chose qu'on évite, car Docker possède des privilèges élevés sur sa machine hôte, c'est donc une source de contamination potentiellement dévastatrice. En prenant soin de placer un certain nombre de garde-fous, et en maîtrisant les points de sécurisation abordés dans les tutoriels références du forum (en premier lieu celui sur la sécurisation), l'idée devient tout à fait envisageable. Il y a deux avantages majeurs à cette méthode : - Elle est applicable à n'importe quelle machine, votre NAS, un PC sous Linux, un micro-processeur type Raspberry, un VPS, un serveur dédié, etc... - Elle permet de s'affranchir des limitations de certains OS, typiquement DSM. On peut tout à fait exposer par TCP l'instance Docker d'un NAS Syno sans passer par un proxy sauf qu'à chaque redémarrage les modifications sont effacées et il faudra de nouveau modifier la ligne de commande de démarrage du démon Docker. Un script pourrait sûrement tout à fait se charger de la tâche, reste que l'on touche à des fichiers systèmes sensibles, je suis partisan du fait de garder un DSM "stock" pour éviter des problèmes lors des mises à jour et des incompatibilités/bugs qui en découlent fréquemment. 2. Prérequis Savoir protéger ses périphériques (pare-feu) Savoir établir une connexion suffisamment sécurisée entre deux machines Savoir rediriger un port Avoir des bases concernant Docker (voir tutoriel introductif) Savoir se connecter en SSH à un périphérique Avoir défini un nom de domaine entièrement qualifié (FQDN en anglais - Fully Qualified Domain Name) pour l'instance Docker cible Difficulté : Moyenne 3. Sécurisation Pour garantir un certain degré de sécurité, l'idée va être d'exposer le socket Docker via un proxy, ce qui sera réalisé par un conteneur sur l'hôte cible, avec lequel nous établirons une connexion TLS depuis l'instance centralisatrice. Sa localisation peut être quelconque : sur le même réseau local, accessible à distance par HTTPS ou encore par VPN. Le choix de la solution et la sécurisation de l'environnement sont à votre discrétion et découlent des pré-requis stipulés ci-dessus. 4. Portainer Pour faciliter la visualisation de mes instances Docker (ou environment) et mes conteneurs, j'utilise l'application Portainer sur la machine qui va servir de centre névralgique pour toutes mes instances. Elle a l'avantage de fournir une interface claire, efficace et intuitive. (Notons qu'il est tout à fait possible de s'en passer et de se cantonner à de la ligne de commande, voir documentation Docker dont le lien est donné plus loin). Un fichier docker-compose.yml adapté aux NAS pour Portainer : version: '2.1' services: portainer: image: portainer/portainer-ce container_name: portainer network_mode: bridge volumes: - /volume1/docker/portainer/data:/data - /var/run/docker.sock:/var/run/docker.sock ports: - 9000:9000 restart: unless-stopped Puis on se place dans le dossier où se trouve le fichier docker-compose.yml précédent et on tape la commande suivante : docker-compose up -d Ou on passe par lignes de commande : docker create \ --name=portainer \ --net=bridge \ --restart=unless-stopped \ -v /volume1/docker/portainer/data:/data \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9000:9000 \ portainer/portainer-ce Puis on tape : docker start portainer Remarque : /volume1/docker/portainer/data est un emplacement adapté pour un NAS Synology, il faudra auparavant créer le dossier portainer et data dans le dossier partagé docker dans File Station. La première fois qu'on se connecte (via http://IP:9000), on est amené à choisir un login et un mot de passe admin. Ce faisant on arrive sur un écran demandant de choisir l'environment qu'on souhaite configurer, il faut choisir local et valider successivement les écrans. On arrive rapidement à un écran de la sorte : Je ne rentre pas dans le détail de l'utilisation de Portainer, on trouve des tutoriels relativement bien faits sur Youtube et Google, et c'est de toute façon assez simple à prendre en main : - https://www.youtube.com/watch?v=GNG6PDFxQyQ (à 1:36 on parle précisément de ce qu'on cherche à faire dans ce guide) - https://domopi.eu/ameliorer-la-gestion-de-vos-containers-docker-avec-portainer/ 5. Méthodes au choix Plusieurs méthodes sont disponibles : 5-A. Portainer-agent Avantage : - Facile et rapide à mettre en place Inconvénients : - Utilisation de certificats client/serveur auto-signés - Fonctionne uniquement avec Portainer Utilisation recommandée : réseau local ou VPN Pour le mettre en place sur le serveur distant qu'on souhaite superviser via notre instance centralisatrice, on passera par Docker-compose ou par lignes de commande : Par docker-compose : version: '2.1' services: portainer-agent: image: portainer/agent container_name: portainer-agent network_mode: bridge volumes: - /var/lib/docker/volumes:/var/lib/docker/volumes - /var/run/docker.sock:/var/run/docker.sock ports: - 9001:9001 restart: unless-stopped Puis : docker-compose up -d Par lignes de commande : docker create \ --name=portainer-agent \ --net=bridge \ --restart=unless-stopped \ -v /var/lib/docker/volumes:/var/lib/docker/volumes \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9001:9001 \ portainer/agent Puis : docker start portainer-agent Remarques : On monte le dossier contenant les volumes Docker, dont le principe est repris dans le tutoriel introductif. Cela permettra de parcourir ces dossiers depuis l'interface Portainer, très pratique pour aller télécharger certains fichiers internes au conteneur (logs, fichiers de configuration, etc...) : On remplace /var/lib/docker/volumes:/var/lib/docker/volumes par /volume1/@docker/volumes:/var/lib/docker/volumes si l'agent est installé sur un NAS Synology. On remplace /var/lib/docker/volumes:/var/lib/docker/volumes par /volume1/.@plugins/AppCentral/docker-ce/docker_lib/volumes:/var/lib/docker/volumes si l'agent est installé sur un NAS Asustor (merci à @MilesTEG1) On expose le port 9001 du conteneur sur le port 9001 de l'hôte (ou un autre port quelconque non utilisé). Si la machine cliente est derrière un routeur, on pense à faire la redirection du port 9001 vers celle-ci. Et que son pare-feu autorise les connexions ce port. Rendez-vous au paragraphe 6-A pour l'ajout de notre agent dans l'interface Portainer. 5-B. Portainer Edge agent A venir. 5-C. Liaison TLS + Proxy 5-C-1. Préambule Avantage : - Sécurisé par certificat client/serveur auto-signé (mais généré par vous-même donc auto-signé). - Utilisable dans toutes les utilisations envisageables d'une liaison TLS entre un serveur et un client, pas seulement dans le cadre de Docker. Inconvénients : - Plus long à mettre en place Utilisation recommandée : réseau local / VPN ou serveur distant Ici je vais prendre l'exemple d'un VPS OVH entrée de gamme. 5-C-2. Préparation La première étape consiste à se connecter en SSH avec l'utilisateur de notre choix sur la cible (le VPS en l'occurence pour moi) et de définir la variable HOST avec le FQDN de notre machine. Dans mon cas, j'utilise le nom de domaine que j'ai défini dans ma zone DNS OVH via un enregistrement A vers l'IP fixe de mon VPS. De manière générale, le FQDN peut être local ou externe, peu importe, car c'est un certificat auto-signé que nous allons générer pour l'atteindre, le tout étant que la résolution du FQDN soit adaptée à l'environnement (je ne peux pas utiliser vps.local si je passe par une résolution externe). Cela peut donc se faire comme moi avec un FQDN externe, si vous souhaitez gérer l'instance Docker d'un raspberry de votre réseau local, il peut s'agir de son enregistrement A correspondant dans votre serveur DNS local, ou simplement ce que vous avez renseigné dans le fichier /etc/hosts de votre instance centralisatrice. Pour l'exemple : HOST=target.ndd.tld En tapant : echo $HOST On doit obtenir le FQDN défini ci-avant. 5-C-3. Certificat serveur On va créer un dossier docker_tls dans le /home de notre utilisateur et on commence à suivre (pas bêtement, mais presque) les consignes de la documentation Docker, les étapes étant parfaitement décrites, je ménage vos touches Alt+Tab ou vous évite un torticolis si vous êtes en double écran en recopiant les étapes ici. 😉 Si vous souhaitez plus de détail sur l'explication de chaque étape, Rendez-vous sur la page. mkdir docker_tls cd docker_tls Puis on poursuit avec les commandes fournies par le guide : openssl genrsa -aes256 -out ca-key.pem 4096 openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem openssl genrsa -out server-key.pem 4096 openssl req -subj "/CN=$HOST" -sha256 -new -key server-key.pem -out server.csr [[[ ATTENTION : Il se peut que vous obteniez l'erreur suivante : Il suffit dans ce cas-là de créer le fichier manquant : touch .rnd et de recommencer ]]] Arrive le passage le plus subtil, il va falloir définir les IP et les FQDN capables d'accéder à cette instance, ça se présente sous cette forme : echo subjectAltName = DNS:,IP: >> extfile.cnf Évidemment, il va falloir renseigner les valeurs de manière exhaustive, sous peine de devoir recommencer depuis cette étape. Ce passage permet de renforcer la sécurisation également, car tout nom de domaine (et donc IP associée) et IP non déclarés se verront refuser l'accès au socket (Connection refused sur Portainer). Il faudra au minimum ajouter $HOST (que l'hôte puisse accéder à sa propre instance, ça ne mange pas de pain), la boucle locale 127.0.0.1, et le FQDN et/ou l'IP de notre instance centralisatrice. Un exemple, où j'autorise en plus par exemple : - l'IP fixe publique de mon instance centralisatrice 51.25.152.236 (fictive) (en cas d'un problème de résolution DNS, je peux toujours y accéder) - l'enregistrement A qui lui est associé central.ndd.tld (ça peut également être mon dynhost pour les IP dynamiques) - l'IP privée de mon instance centralisatrice lorsque connectée au serveur VPN de mon VPS 10.0.0.2 echo subjectAltName = DNS:$HOST,DNS:central.ndd.tld,IP:51.25.152.236,IP:10.0.0.2,IP:127.0.0.1 >> extfile.cnf On poursuit : echo extendedKeyUsage = serverAuth >> extfile.cnf openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf . 5-C-4. Certificat client Par facilité, on va rester sur la machine hôte et créer les certificats et la clé privée client. openssl genrsa -out key.pem 4096 openssl req -subj '/CN=client' -new -key key.pem -out client.csr echo extendedKeyUsage = clientAuth > extfile-client.cnf openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile-client.cnf rm -v client.csr server.csr extfile.cnf extfile-client.cnf chmod -v 0400 ca-key.pem key.pem server-key.pem chmod -v 0444 ca.pem server-cert.pem cert.pem 5-C-5. Récapitulatif Si tout s'est bien déroulé, un petit ls -lt devrait donner ceci : 5-C-6. Proxy Il nous faut maintenant créer le conteneur servant de proxy, dont voici la page GitHub de l'image. Un modèle de fichier docker-compose : version: '2.1' services: docker-socket-proxy: image: sjawhar/docker-socket-proxy container_name: docker-socket-proxy network_mode: bridge volumes: - /path/to/the/server/certs:/run/secrets:ro - /var/run/docker.sock:/var/run/docker.sock:ro ports: - 2376:2376 restart: unless-stopped Puis : docker-compose up -d Ou par lignes de commande : docker create \ --name=docker-socket-proxy \ --net=bridge \ --restart=unless-stopped \ -v /path/to/the/server/certs:/run/secrets:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ -p 2376:2376 \ sjawhar/docker-socket-proxy Puis : docker start docker-socket-proxy Remarques : - /path/to/the/server/certs représente le dossier dans lequel vous allez placer vos certificats, cela dépend de l'OS de la machine cliente. Sur une distribution Linux classique, ça peut être dans le /home d'un utilisateur, dans /root ou partout ailleurs. Parmi les huit fichiers restants, trois nous intéressent pour ce conteneur : ca.pem, server-key.pem, server-cert.pem Ces trois fichiers doivent se trouver dans le chemin que vous aurez choisi pour /path/to/the/server/certs, pour ma part j'ai créé un sous-dossier certs dans le dossier du conteneur et je les y ai copiés. Le port 2376 est à ouvrir (et rediriger si besoin) sur la machine cible, évidemment. Et que le pare-feu de la machine, s'il y en a un, autorise les connexions sur ce port. Une fois le conteneur démarré, si tout va bien les logs du conteneur n'affichent rien, on le vérifie en tapant : docker logs docker-socket-proxy 6. Ajout de l'environment sur Portainer 6-A. Portainer agent On va ajouter l'agent en cliquant simplement dans Environment dans le menu latéral, puis + Add environment. On sélectionne Agent, puis on complète de cette manière : L'IP 192.168.1.50 est un exemple évidemment, on pense à préciser le port. On peut éventuellement ajouter des tags pour trier facilement les environments (utile si on supervise beaucoup de machines). Si vous cliquez sur Home dans le menu latéral, vous voyez maintenant votre instance distante avec le statut Up. 6-B. Proxy On commence par rapatrier les trois fichiers utiles pour le client : ca.pem (le même que pour le serveur), cert.pem et key.pem. La sélection des fichiers se fera par une fenêtre de parcours, comme sur une interface graphique classique Linux ou Windows. Pour ceux que ça n'aide pas, j'ai utilisé scp et ai mis les fichiers sur mon bureau Linux (attention à la majuscule, c'est -P, pas -p) scp -P <port-SSH> ca.pem cert.pem key.pem toto@central.ndd.tld:~/Bureau Pour Windows, vous pouvez récupérer les fichiers avec WinSCP par exemple via connexion SSH. Le serveur est maintenant accessible, il ne reste plus qu'à se connecter à Portainer et ajouter l'environment. Dans le menu déroulant de gauche, on clique sur Environment, puis + Add environment. Puis on complète de la sorte, en adaptant évidemment à ses propres données : On notera la sélection des certificats et de la clé en bas de la page. On clique ensuite sur "Add environment". Si vous cliquez sur Home dans le menu latéral, vous voyez maintenant votre instance distante avec le statut Up. 7. Utilisation de Github comme source des fichiers compose Il est possible de créer un dépôt personnel sur Github (ou tout autre logiciel git-compatible type Gitea, etc... notamment auto-hébergé 😉) afin d'y stocker ses fichiers compose, au lieu de les stocker sur la machine cible ou en utilisant les outils de Portainer. L'avantage est d'avoir accès depuis n'importe où, avec le niveau de sécurité que l'on a établi pour sa connexion à Github (2FA par exemple), à l'ensemble des fichiers de configuration de ses applications. Mieux, si on modifie un fichier, Portainer le détectera ou en sera informé et recréera le conteneur avec ses nouveaux paramètres. Pour cela, on va devoir dans un premier temps créer un token d'accès à Github pour Portainer. 7-A. Génération d'un personal acces token Tout d'abord, il faut créer un compte Github. Une fois ceci fait, on clique sur son portrait, puis Settings : Puis Developer settings tout en bas du menu à la gauche de l'écran -> Personal access tokens -> Generate new token : Ce sont, de mes tests, les permissions minimales à accorder via ce token à Portainer pour pull correctement les fichiers lors du déploiement de la pile (stack). On clique ensuite sur Generate token. ON NOTE BIEN LE TOKEN, SI ON LE PERD IL N'Y A AUCUN MOYEN DE LE RECUPERER. Il faudra alors en recréer un. On va maintenant créer un dépôt pour stocker nos fichiers. 7-B. Création d'un dépôt On clique sur son portrait puis Your repositories. Puis New. Voici un exemple de dépôt : On clique sur Create repository. On arrive sur notre dépôt, vide de tout fichier sauf du README qui contient la description entrée ci-avant. On pourra évidemment en faire une documentation si on en éprouve le besoin. On va maintenant changer le nom de la branche principale, pour qu'il corresponde à celui pré-établi par Portainer lors de la création d'une pile git. On clique sur branch : Puis, on clique sur l'icône en forme de crayon tout à droite de la ligne de la branche "main". On la renomme en master et on valide. On revient sur la page d'accueil du dépôt en cliquant sur Code. On va maintenant pouvoir ajouter ou créer nos premiers fichiers. 7-C. Création & ajout d'un fichier compose On a plusieurs possibilités : On clique sur Add file (voir impression d'écran ci-avant) : On télécharge sur le dépôt un fichier compose existant via Upload files. On crée un nouveau fichier en cliquant sur Create new file. On utilise git depuis sa machine pour alimenter son dépôt (non traîté). On va ajouter un fichier docker-compose existant depuis mon PC. On clique sur Upload files, on peut déposer le fichier à la volée ou parcourir l'arborescence, puis on clique sur Commit changes. Une fois le fichier ajouté, il est à la racine du dépôt. Si on souhaite créer une arborescence, il n'y a pas de fonction créer un dossier dans Github. Pour ce faire il faut éditer le fichier en question, en cliquant sur le fichier nouvellement ajouté puis la même icône crayon en haut à droite du cadre contenant le code du fichier. Si vous regardez en haut de l'impression d'écran, j'ai créé un chemin synology/docker-compose_exemple.yml Pour cela, j'ai simplement ajouté synology/ devant le nom du fichier compose, Github reconnaît une arborescence dès qu'on ajouté un /. Je conseille également de renommer les fichiers docker-compose.yml en ajoutant l'application en question, ce sera nécessaire pour dissocier les fichiers les uns des autres. Remarques : Vous noterez que j'ai déposé le fichier compose de Portainer, c'est purement pour l'exemple. C'est évidemment le seul fichier compose qu'on ne pourra pas exploiter via Portainer. 😉 Il n'y a pas d'adaptation spécifique à faire au niveau du contenu des fichiers compose par rapport à ce que vous avez l'habitude de faire directement via Portainer à la création d'une pile ou en ligne de commande. Et maintenant direction Portainer ! 7-D. Création de la pile Dans Portainer, on sélectionne l'environnement où l'on souhaite déployer la pile, puis on clique sur Add stack. On lui donne un nom, puis on choisit l'option Git repository. On complète de la façon suivante : Repository URL : On y met l'adresse de notre dépôt, concaténé à partir du nom d'utilisateur Github et du nom du dépôt, à c/c depuis Github. Repository reference : c'est la raison pour laquelle je vous ai fait changer le nom de la branche, Portainer propose master par défaut. Compose path : le chemin du fichier compose sur le dépôt. Il est possible de le c/c directement depuis le fichier en question : Authentication : Vu qu'on est sur un dépôt privé, il faut s'authentifer, c'est ici qu'on entre notre nom d'utilisateur Github ainsi que le PAT (Personal access token) généré précédemment. Automatic updates : Gros intérêt de ce procédé, les conteneurs sont dynamiquement liés à leurs fichiers de configuration sur Github. Deux moyens de procéder : Polling : Par défaut, toutes les 5 minutes, Portainer ira vérifier si le fichier a changé, si oui, il recréer le conteneur. Méthode la plus simple et recommandée Webhook : C'est Github qui signalera à Portainer que le fichier a changé. Quand vous utilisez cette option, Portainer crée un lien vers son API, lien à renseigner dans Github. Cette méthode a plusieurs implications. Il faut que les IP suivantes puissent accéder à votre instance Portainer (donc attention au pare-feu et au géo-blocage) : - 192.30.252.0/22 - 185.199.108.0/22 - 140.82.112.0/20 - 143.55.64.0/20 - 2a0a:a440::/29 - 2606:50c0::/32 De plus, il faut aller renseigner le lien vers Portainer dans Github, pour cela on va sur notre dépôt : On clique sur Add webhook puis : On entre l'URL fournie par Portainer, pas besoin d'ajouter de secret. Si on utilise un proxy inversé ou le port sécurisé de Portainer, on laisse activée la vérification SSL. Des tests que j'avais faits, seuls les commit comments ont besoin d'être cochés. Si ça ne fonctionne pas, choisissez Send me everything et éventuellement procédez par élimination pour trouver les événements nécessaires. Je recommande la méthode du polling, pas de problème d'accès car la requête part de Portainer. Il ne vous reste plus qu'à déployer les piles. 🙂 7-E. Variables d'environnement Il est possible, comme avec les outils natifs Portainer, de spécifier la valeur de variables d'environnement lors du déploiement de la pile. Par exemple, dans le fichier compose : environment: - MYSQL_ROOT_PASSWORD = ${MYSQL_ROOT_PASSWORD} Au moment du déploiement : Pour les férus de sécurité uniquement. 😉 MàJ : 11/11/2022

Moi sinon je vends mon corps pour une IP fixe en Belgique, c'est +30€ par mois sur un abonnement à un prix déjà indécent de base 😄

Il faut remplacer "log_a_analyser", par nom d'un log, par exemple syslog.log, ou ceux que je t'ai conseillés. 🤔