Especificar contenedor en ejecución en la página de respaldo desde variables de entorno en archivo yml

[neounix (Dark Matter)]

Plugin propuesto: discourse-container-names.git

¿Qué te gustaría que se hiciera?

Me gustaría un plugin sencillo que muestre el/los nombre(s) del contenedor en la página de copias de seguridad, de la siguiente manera (ejemplo):

El nombre del contenedor debe provenir de las variables de entorno en el archivo yml, como se muestra a continuación:

Notas de la aplicación:

1. El nombre del contenedor debe obtenerse de las variables de entorno mostradas en la imagen anterior (no de docker ps, por ejemplo).

2. En el caso de que haya un contenedor de datos y un contenedor de aplicación, sería ideal mostrar también el nombre del contenedor de datos:

• Contenedor: app #ejemplo básico de nombre independiente
• Contenedores: socket-only, data #ejemplo básico de configuración con dos contenedores

3. La razón de esto es que ejecutamos múltiples contenedores de aplicación y quiero saber siempre qué contenedor se está ejecutando al ver las páginas de administración, y en particular la página de copias de seguridad (según la primera imagen).

¿Cuándo lo necesitas listo?

En cualquier momento. Sin prisa. Parece un plugin muy sencillo para expertos en plugins de Discourse. Es simplemente algo “agradable de tener” para la página de copias de seguridad de administración y no tengo la motivación para escribirlo yo mismo, así que estoy encantado de pagar una tarifa razonable a alguien que lo haga.

¿Cuál es tu presupuesto, en dólares estadounidenses, que puedes ofrecer por esta tarea?

Siéntete libre de enviarme un mensaje privado.

El plugin debe estar disponible gratuitamente para toda la comunidad de Discourse, por si hay otros administradores de sistemas de Discourse que ejecutan múltiples contenedores y desean ver el nombre del contenedor en ejecución actual en la página de copias de seguridad del panel de administración; o para cualquier persona que quiera ver el nombre de su contenedor en ejecución (incluso si está en modo independiente) en la página de copias de seguridad.

[RGJ (Richard - Communiteq)]

¡Gran idea! ¿Qué tal si también añadimos el ID real del contenedor?

Se puede obtener desde dentro del contenedor de la siguiente manera:
cat /proc/self/cgroup|grep "systemd:/docker"| awk -F/ '{print $3}'|cut -c1-12

[neounix (Dark Matter)]

Gracias, pero tener una utilidad de línea de comandos dependiente de la plataforma dentro del plugin para obtener la información no funciona (como se requiere) para mí (obtener el ID de Docker desde el comando a continuación no funciona en nuestra configuración de Ubuntu 18.04):

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

#. (sin resultados)

incluso esto no da resultados:

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

#  (sin resultados)

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

Esto significa que la información (la cadena que especifica el nombre del contenedor en ejecución) debería derivarse de una variable de entorno en el archivo yml. Esto asegura que la información sea neutral a la plataforma y funcione cuando se ejecutan múltiples contenedores.

Por ejemplo, ejecutamos varias aplicaciones Discourse y otros contenedores al mismo tiempo, por lo que usar comandos de docker-cli no proporcionará la información exacta que necesitamos (el nombre del contenedor en ejecución en la web “en ese momento”, que está determinado por la configuración del proxy inverso, no por Docker).

Seleccionamos qué contenedor mostrar cambiando el nombre del socket unix (o el puerto expuesto del contenedor) en la configuración del proxy inverso, por lo que cambiamos de contenedor en menos de un segundo con tiempo de inactividad cero. Esto significa que el nombre del contenedor debe (necesariamente) provenir de una variable de entorno en el archivo yml para ser 100% confiable y preciso.

Por lo tanto, mi requisito es que la cadena (nombre del contenedor, ID del contenedor, etc.) provenga únicamente de variables de entorno en el archivo yml.

Para cualquiera que prefiera el ID del contenedor, podría agregarlo a su variable de entorno de la siguiente manera (por ejemplo):

DISCOURSE_APP_CONTAINER_NAME = 'socket-only (63c52bc571b5)'

o incluso:

DISCOURSE_APP_CONTAINER_NAME = '63c52bc571b5'
DISCOURSE_DATA_CONTAINER_NAME = 'ca7b55fc5a0c'

y según mi publicación original (la forma en que queremos usarlo):

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

El identificador de cadena (token) que se usará (nombre, ID del contenedor o ambos) dependerá de los requisitos del administrador del sistema (o del negocio).

Por eso fue específico al indicar que la información debe estar codificada en el archivo yml principal de la aplicación como una variable de entorno (no desde comandos de CLI como docker ps u otros comandos del sistema operativo dependientes de la plataforma).

Espero que esto aclare más mi requisito.

Quiero que esto sea neutral a la plataforma y a la configuración, y no dependa de comandos de CLI ni de comandos del sistema. Ejecutamos Docker para muchas otras aplicaciones y no solo para Discourse en nuestros servidores (incluidas Discourse, aplicaciones LAMP en contenedores, registros privados de Docker y más, como se puede ver en la salida de ejemplo de docker ps anterior.).

[RGJ (Richard - Communiteq)]

@neounix

utilidad de línea de comandos dependiente de la plataforma

¡Tienes toda la razón!

[neounix (Dark Matter)]

@RGJ

¡Tienes toda la razón!

Hola @RGJ,

Solo un pensamiento adicional:

El caso extremo en el que codificar los identificadores del contenedor (ya sea el ID del contenedor, el nombre o ambos) como variables de entorno en YAML puede no funcionar, es con Docker Swarm o Kubernetes (por ejemplo); porque cuando los contenedores son dinámicos según la carga y/o los fallos, codificar las variables de entorno en YAML no funcionará (lo asumo, pero aún no lo he hecho para hablar con autoridad sobre el tema); pero estoy dispuesto a optar por el “enfoque simple” por ahora (variables de entorno en YAML).

En cualquier caso, aún no he implementado Discourse con Swarm o Kubernetes, así que mi plan era cruzar ese puente cuando llegue el momento

He pensado mucho en esto, y por eso he decidido que la mejor ruta en este momento es optar por las variables de entorno de Discourse codificadas en los archivos YAML.

Debería ser una tarea relativamente sencilla tomar estas variables de entorno, como configuraciones del sitio, y mostrarlas en la página de copias de seguridad de administración según mi rápido boceto: