Spécifier le conteneur en cours d'exécution sur la page de sauvegarde à partir des variables d'environnement dans le fichier yml

[neounix (Dark Matter)]

Plugin proposé : discourse-container-names.git

Que souhaitez-vous réaliser ?

Je souhaite un plugin simple qui affiche le(s) nom(s) du/des conteneur(s) sur la page des sauvegardes, comme suit (exemple) :

Le nom du conteneur doit provenir de variable(s) d’environnement dans le fichier yml, comme suit :

Notes d’application :

1. Le nom du conteneur doit provenir des variable(s) d’environnement telles qu’illustrées dans l’image ci-dessus (et non pas de la commande ```docker ps``, par exemple).

2. Dans le cas où il y a un conteneur de données et un conteneur d’application, il serait appréciable d’afficher également le nom du conteneur de données :

• Conteneur : app # exemple de nom autonome simple
• Conteneurs : socket-only, data # exemple de configuration simple à deux conteneurs

3. La raison en est que nous exécutons plusieurs conteneurs d’application, et je veux toujours savoir quel conteneur est en cours d’exécution lorsque je consulte les pages d’administration, en particulier la page des sauvegardes (comme montré sur la première image).

Quand avez-vous besoin que ce soit fait ?

À tout moment. Pas de précipitation. Cela semble être un plugin très simple pour les experts en plugins Discourse. C’est juste un « plus » pour la page de sauvegarde de l’administration, et je n’ai pas la motivation de l’écrire moi-même, donc je suis prêt à payer quelqu’un un montant raisonnable pour le faire !

Quel est votre budget, en $ USD, que vous pouvez offrir pour cette tâche ?

N’hésitez pas à m’envoyer un MP.

Le plugin doit être mis gratuitement à disposition de la communauté Discourse au sens large, au cas où d’autres administrateurs système Discourse exécuteraient plusieurs conteneurs et souhaiteraient voir le nom du conteneur actuellement en cours d’exécution sur la page des sauvegardes du panneau d’administration ; ou pour toute personne souhaitant voir le nom de son conteneur en cours d’exécution (même en mode autonome) sur la page des sauvegardes.

[RGJ (Richard - Communiteq)]

Excellente idée, pourquoi ne pas ajouter également l’ID réel du conteneur ?

Il peut être récupéré depuis l’intérieur du conteneur de cette manière :
cat /proc/self/cgroup|grep "systemd:/docker"| awk -F/ '{print $3}'|cut -c1-12

[neounix (Dark Matter)]

Merci, mais l’utilisation d’un utilitaire de ligne de commande dépendant de la plateforme dans le plugin pour obtenir ces informations ne fonctionne pas (comme requis) pour moi (l’obtention de l’ID Docker à partir de la commande ci-dessous ne fonctionne pas sur notre configuration Ubuntu 18.04) :

# cat /proc/self/cgroup|grep "systemd:/docker"| awk -F/ '{print $3}'|cut -c1-12

#. (aucun résultat)

même cela ne donne aucun résultat :

# cat /proc/self/cgroup|grep "systemd:/docker"

#  (aucun résultat)

FYI (de docker ps) :

CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS                  PORTS                               NAMES
63c52bc571b5        local_discourse/socket-only     "/sbin/boot"             28 minutes ago      Up 28 minutes                                               socket-only
631fbabedda9        local_discourse/socket-only2    "/sbin/boot"             26 hours ago        Up 26 hours                                                 socket-only2
123743e12208        mysql/mysql-server              "/entrypoint.sh mysq…"   2 days ago          Up 20 hours (healthy)   33060/tcp, 0.0.0.0:6603->3306/tcp   mysql-man
7a145366268c        registry.unix.com/unix:condor   "/run.sh"                6 days ago          Up 20 hours             3306/tcp, 0.0.0.0:8999->80/tcp      unix
3cc0c90c3e3a        registry:2                      "/entrypoint.sh /etc…"   7 days ago          Up 7 days               0.0.0.0:5000->5000/tcp              hubby
ca7b55fc5a0c        local_discourse/data            "/sbin/boot"             2 weeks ago         Up 8 days                                                   data

Cela signifie que l’information (la chaîne spécifiant le nom du conteneur en cours d’exécution) doit être dérivée d’une variable d’environnement dans le fichier yml, afin d’assurer que l’information est neutre vis-à-vis de la plateforme et fonctionne même lorsque de nombreux conteneurs sont en cours d’exécution.

Par exemple, nous exécutons plusieurs applications Discourse et d’autres conteneurs simultanément, donc l’utilisation de commandes docker-cli ne fournira pas les informations exactes dont nous avons besoin (le nom du conteneur en cours d’exécution sur le web “au moment présent”, qui est déterminé par la configuration du proxy inverse, et non par Docker).

Nous sélectionnons le conteneur à afficher en modifiant le nom du socket Unix (ou du port exposé du conteneur) dans la configuration du proxy inverse, ce qui nous permet de changer de conteneur en moins d’une seconde avec un temps d’arrêt nul. Cela signifie que le nom du conteneur doit (impérativement) provenir d’une variable d’environnement dans le fichier yml pour être 100 % fiable et précis.

D’où ma demande que la chaîne (nom du conteneur, ID du conteneur, etc.) provienne uniquement des variables d’environnement dans le fichier yml.

Pour ceux qui préfèrent l’ID du conteneur, ils pourraient l’ajouter à leur variable d’environnement comme ceci (par exemple) :

DISCOURSE_APP_CONTAINER_NAME = 'socket-only (63c52bc571b5)'

ou même :

DISCOURSE_APP_CONTAINER_NAME = '63c52bc571b5'
DISCOURSE_DATA_CONTAINER_NAME = 'ca7b55fc5a0c'

et selon mon message original (la façon dont nous souhaitons l’utiliser) :

DISCOURSE_APP_CONTAINER_NAME = 'socket-only'
DISCOURSE_DATA_CONTAINER_NAME = 'data'

Le choix de l’identifiant (nom, ID du conteneur, ou les deux) dépendra des exigences de l’administrateur système (ou de l’entreprise).

C’est pourquoi j’ai été spécifique en précisant que l’information doit être codée en dur dans le fichier yml principal de l’application sous forme de variable d’environnement (et non via des commandes CLI comme docker ps ou d’autres commandes OS dépendantes de la plateforme).

J’espère que cela rend ma demande plus claire.

Je veux que cela soit neutre vis-à-vis de la plateforme et de la configuration, et ne dépende pas des commandes CLI ou système. Nous exécutons Docker pour de nombreuses autres applications et pas seulement Discourse sur nos serveurs (y compris Discourse, des applications LAMP conteneurisées, des registres privés Docker et plus encore, comme vous pouvez le constater dans l’exemple de sortie docker ps ci-dessus.)

[RGJ (Richard - Communiteq)]

@neounix

utilitaire en ligne de commande dépendant de la plateforme

Vous avez tout à fait raison !

[neounix (Dark Matter)]

@RGJ

Vous avez tout à fait raison !

Bonjour @RGJ,

Juste une pensée complémentaire :

Le cas limite où le codage en dur des identifiants de conteneur (qu’il s’agisse de l’ID, du nom ou des deux) en tant que variables d’environnement YAML peut ne pas fonctionner, concerne Docker Swarm ou Kubernetes (par exemple) ; car lorsque les conteneurs sont dynamiques en fonction de la charge et/ou des pannes, le codage en dur des variables d’environnement dans les fichiers YAML ne fonctionnera pas (je suppose, mais je ne l’ai pas encore fait pour parler en toute autorité sur le sujet) ; mais je suis prêt à opter pour l’« approche simple » pour l’instant (variables d’environnement dans les fichiers YAML).

Quoi qu’il en soit, je n’ai pas encore déployé Discourse avec Swarm ou Kubernetes, donc mon intention était de franchir cette étape quand je serai confronté à la situation plus tard

J’y ai beaucoup réfléchi, et c’est pourquoi j’ai décidé que la meilleure voie à suivre à ce stade est d’utiliser les variables d’environnement de Discourse codées en dur dans les fichiers YAML.

Ce devrait être une tâche relativement simple de prendre ces variables d’environnement, en tant que paramètres du site, et de les afficher sur la page de sauvegarde de l’administration, selon ma petite maquette rapide :