Shinyproxy: Pasar credenciales SQL en tiempo de ejecución con la aplicación shinyproxy.yml

Creado en 27 oct. 2020  ·  5Comentarios  ·  Fuente: openanalytics/shinyproxy

Hola,

Tengo una aplicación shinyproxy que funciona con autenticación ldap. Sin embargo, para recuperar datos de la base de datos SQL, ahora uso (no recomendado) una cadena de conexión codificada en mi código R con las credenciales mencionadas aquí (uso un usuario de servicio porque mis usuarios finales no tienen permisos para consultar la base de datos):

con <- DBI::dbConnect(odbc::odbc(), encoding = "latin1", .connection_string = 'Driver={Driver};Server=Server;Database=dbb;UID=UID;PWD=PWD') 

Intenté reemplazar esta cadena de conexión con una variable de entorno, que paso de mi host Linux al contenedor. El código R ahora cambió a:

connString <- Sys.getenv("CONNSTRING")
connString <- sub("\\\\","\\", connString)
con <- DBI::dbConnect(odbc::odbc(), encoding = "latin1", .connection_string = connString)

Esto funciona bien cuando se ejecuta el contenedor fuera de ShinyProxy y, por lo tanto, al pasar las variables ambientales en tiempo de ejecución con el siguiente comando de la ventana acoplable:

docker run -it --env-file .env.list app123 

La variable de entorno también se encuentra al ingresar al contenedor en ejecución y escribir 'env'.

Sin embargo, cuando uso ShinyProxy, no me queda claro cómo configurar esto en el archivo de configuración yaml y en el comando bash en tiempo de ejecución. ¿Cómo defino el parámetro container-env-file para el contenedor de la aplicación? ¿Y cómo paso la declaración --env-file .env.list en tiempo de ejecución para que se recoja en los contenedores vinculados?

Mi aplicación yaml se ve ahora así (intencionalmente dejé la configuración de LDAP en blanco):

proxy:
  port: 8080
  authentication: ldap
  admin-groups: admins
  ldap:
    url: url
    manager-dn: manager-dn
    manager-password: manager-password
    user-search-base: user-search-base
    user-search-filter: user-search-filter
    group-search-filter:  group-search-filter
    group-search-base: group-search-base  
  docker:
      internal-networking: true
  specs:
  - id: 01_ok
    display-name: dashboard
    description: Dashboard 
    container-cmd: ["R", "-e", "shiny::runApp('/root/R')"]
    container-image: hberten/app123
    container-env-file: .env.list
    container-network: shineyproxyn-net
    access-groups: [GG_APP_ShinyProxy]

logging:
  file:
    shinyproxy.log

Luego ejecuto el siguiente comando para iniciar el contenedor ShinyProxy:

sudo docker run -d --env-file ~/.env.list -v /var/run/docker.sock:/var/run/docker.sock --net shineyproxyn-net -p 8080:8080 hberten/shinyproxy

Aquí se encuentra un problema relacionado, pero este usa un Docker compose.yml. ¿Es posible configurar cosas sin Docker Compose? ¿Qué me estoy perdiendo?

¡Cualquier ayuda apreciada amablemente!

question

Comentario más útil

Intentaré explicarlo con más claridad: tienes un sistema host y 2 contenedores: uno externo donde se ejecuta shinyproxy y otro interno con tu aplicación.
Al ejecutar docker run --env-file ... en su sistema host, hace que las variables de entorno de ese archivo en el sistema host estén disponibles para el contenedor externo como env vars. Ahora puede pasarlos al contenedor interno usando la variable container-env .
Alternativamente, puede montar la carpeta de host con su archivo en su contenedor externo, y luego puede hacer que las variables env de ese archivo estén disponibles en su contenedor interno usando container-env-file variable.

Un comando de ejemplo para la segunda alternativa puede ser algo como:

sudo docker run -d -v /home/envs:/tmp/envs -v /var/run/docker.sock:/var/run/docker.sock --net shineyproxyn-net -p 8080:8080 hberten/shinyproxy

asumiendo que su archivo .env.list está ubicado en / home / envs / en su host - lo hace disponible en el contenedor externo bajo /tmp/envs/env.list con montaje de volumen - ahora puede usar container-env-file: /tmp/envs/.env.list en su application.yml

Un ejemplo de la primera alternativa es usar su comando original, y luego en application.yaml use container-env con algo como:

container-env:
  VAR11: "${VAR1}"
  VAR22: "${VAR2}"

donde VAR1 y VAR2 son env vars definidas en el archivo en el host y, por lo tanto, están disponibles como env vars en el contenedor externo, y aquí las pasa al contenedor interno como VAR11 y VAR22 (por ejemplo, por supuesto, también puede usar los mismos nombres )

Todos 5 comentarios

Hola @Bertusian ,
Creo que el problema es que está ejecutando shinyproxy en un contenedor, por lo que debe hacer que su archivo .env.list esté disponible dentro de ese contenedor (por volumen de montaje), o alternativamente usar container-env con env vars que pasa a través de un archivo en su comando docker run. Además, creo que container-env-file espera una ruta absoluta.

Hola @ mnazarov.

De hecho, estoy ejecutando shinyproxy en un contenedor. ¿Puede eventualmente proporcionar un ejemplo del comando en tiempo de ejecución para iniciar el contenedor shinyproxy (con el volumen .env.list montado), y luego es capturado por el contenedor R-app? Pensé que .env.list estaba disponible agregando --env-file ~ / .env.list (que funcionaba cuando se ejecutaba el contenedor sin shinyproxy).
¿Y todavía necesito adaptar el archivo application.yml? Todavía no me queda muy claro. Agradecido por cualquier ayuda o ejemplo ...

Intentaré explicarlo con más claridad: tienes un sistema host y 2 contenedores: uno externo donde se ejecuta shinyproxy y otro interno con tu aplicación.
Al ejecutar docker run --env-file ... en su sistema host, hace que las variables de entorno de ese archivo en el sistema host estén disponibles para el contenedor externo como env vars. Ahora puede pasarlos al contenedor interno usando la variable container-env .
Alternativamente, puede montar la carpeta de host con su archivo en su contenedor externo, y luego puede hacer que las variables env de ese archivo estén disponibles en su contenedor interno usando container-env-file variable.

Un comando de ejemplo para la segunda alternativa puede ser algo como:

sudo docker run -d -v /home/envs:/tmp/envs -v /var/run/docker.sock:/var/run/docker.sock --net shineyproxyn-net -p 8080:8080 hberten/shinyproxy

asumiendo que su archivo .env.list está ubicado en / home / envs / en su host - lo hace disponible en el contenedor externo bajo /tmp/envs/env.list con montaje de volumen - ahora puede usar container-env-file: /tmp/envs/.env.list en su application.yml

Un ejemplo de la primera alternativa es usar su comando original, y luego en application.yaml use container-env con algo como:

container-env:
  VAR11: "${VAR1}"
  VAR22: "${VAR2}"

donde VAR1 y VAR2 son env vars definidas en el archivo en el host y, por lo tanto, están disponibles como env vars en el contenedor externo, y aquí las pasa al contenedor interno como VAR11 y VAR22 (por ejemplo, por supuesto, también puede usar los mismos nombres )

DIOS MÍO. ¡Esto es genial! Ahora funciona. No he probado la primera sugerencia (pero lo haré más adelante), ¡pero su segunda solución lo hizo de manera directa! Sabía que estaba cerca, pero no pude encontrarlo.

¡¡Muchísimas gracias!!

Grandes cosas que están haciendo con ShinyProxy.

¡Me alegro de que haya funcionado!

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

dylancis picture dylancis  ·  3Comentarios

fmmattioni picture fmmattioni  ·  3Comentarios

algo-se picture algo-se  ·  6Comentarios

Emelieh21 picture Emelieh21  ·  5Comentarios

thomas-chauvet picture thomas-chauvet  ·  5Comentarios