Bonjour,
Juste pour vous informer que le docker est prêt, j'aimerais bien avoir vos retours pour ceux qui vont le tester, merci.
Bonne journée.
l'output de log par défaut sur /var/log/infpyng.log n'est pas pratique pour les conteneurs. cela oblige a mapper ce ficher en dehors du conteneur ou de faire un "docker cp nomducontainer:/var/log/infpyng.log -' pour voir ce qui se passe.
Généralement on prefere stdout/stdin car la commande "docker logs .." permet d'afficher directement stdin/stdout.
En plus on peut spécifier un 'driver' (voir
https://docs.docker.com/config/containers/logging/configure/ ). par exemple je lance mes containers avec cet option:
(c'est un exemple avec Caddy)
docker run -d \
--name caddy\
--restart unless-stopped\
--mount /www/Caddyfile:/etc/Caddyfile \
--mount /www/www:/www \
--mount /www/caddy-logs:/logs \
-p 80:80 -p 443:443 \
--log-driver=journald \
--log-opt tag="{{.Name}}" \
abiosoft/caddy -agree -conf /etc/Caddyfile
les options --log-driver=journald et -log-opt tag permettent de rediriger le 'docker logs' sur le journal systemd de l'hote (donc journalctl) ce qui est pratique et centralise les logs de plusieurs containers.
Pour ce faire ton app devrait donc utiliser stdout (ou stderr) par défaut plutôt qu'un fichier de log (ou regarde le Dockerfile de nginx, par exemple,
https://github.com/nginxinc/docker-nginx/blob/master/stable/alpine/Dockerfile#L104 ligne 104 ils font un ln -s mais je ne trouve pas cela clean si on le choix)
nb: on parle de logs systeme (erreur de config par exemple) pas des traces applicatives (style log apache) qui peuvent générer beaucoup de lignes et sont mieux dans leur propre fichier de log. Dans ton cas, si le serveur Influxdb ne répond ca va dans /var/log/infpyng.log ce qui n'est pas bon dans un environnent Docker, ni meme en bare métal d'ailleurs cette erreur devrait aller le stderr de l'application.
Apres un bon container doit être "jetable" donc rien garder dedans. ni input (config, parametres) ni output (logs, etc) importants. On peut laisser une config par défaut si on veut mais si l'application nécessite que l'utilisateur spécifie toujours une config autant mettre ca en dehors du conteneur et générer une erreur si on ne précise pas la config. Le fichier hosts par exemple n'a pas lieu d'être dans le container.
Il faut voir un container comme un executable c'est plus simple a aborder comme ca.
Pour un usage propre, il faut donc 'monter' les 2 fichiers de config (ou le dossier 'config') et par défaut avoir les logs sur stdout/stderr et le traces applicatives dans un autre fichier.
Pour éviter des montages complexe, je conseillerais aussi de mettre des chemins courts dans le containers ou des volumes nommés. la les 2 fichiers de conf sont "/app/infpyng/config/config.toml" et "/app/infpyng/config/config.toml" ce qui est long pour rien.
utilise plutot /app/config.toml et /app/hosts.toml. bref met tout dans /app.
comme ca on peut lancer le conteneur ainsi:
docker run -d\
--name infpyng\
--restart unless-stopped\
--mount /chemin/hote/infpyng/config/config.toml:/app/config.toml\
--mount /chemin/hote/infpyng/config/hosts.toml:/app/hosts.toml\
--mount /chemin/hote/infpyng/infpyng.log:/var/log/infpyng.log \
--log-driver=journald \
--log-opt tag="{{.Name}}" \
oijkn/infpyng
en pratique /chemin/hote est un serveur nfs par exemple ou un chemin local backupé et protégé. (c'est l'endroit de persistence, tout le reste étant jetable et pouvant changer de machine).
Apres vu ton app n'est pas autonome et dépend d'InfluxDB, il serait peut-etre mieux de mettre la config InfluxDB non pas dans config.toml mais en paramètre ou variable d'environnement. ca permet de passer cela lors du "docker run ..." ou dans un compose file.
Je vais faire un compose file pour tester ton container car je n'utilise pas influxdb sur mes serveurs. je le posterais ici.
edit: quelques typos