Shinyproxy: Transmission des informations d'identification SQL au moment de l'exécution avec l'application shinyproxy.yml

Créé le 27 oct. 2020 · 5Commentaires · Source: openanalytics/shinyproxy

Salut,

J'ai une application shinyproxy fonctionnelle avec authentification LDAP. Cependant, pour récupérer les données de la base de données SQL, j'utilise maintenant (non recommandé) une chaîne de connexion codée en dur dans mon code R avec les informations d'identification mentionnées ici (j'utilise un utilisateur de service car mes utilisateurs finaux n'ont pas l'autorisation d'interroger la base de données):

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

J'ai essayé de remplacer cette chaîne de connexion par une variable d'environnement, que je transmets de mon hôte Linux au conteneur. Le code R est maintenant changé en :

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

Cela fonctionne bien lors de l'exécution du conteneur en dehors de ShinyProxy, et donc en passant les variables d'environnement lors de l'exécution avec la commande docker suivante :

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

La variable d'environnement est également trouvée lors de la saisie du conteneur en cours d'exécution et de la saisie de « env ».

Cependant, lors de l'utilisation de ShinyProxy, je ne sais pas comment configurer cela dans le fichier de configuration yaml et dans la commande bash au moment de l'exécution. Comment définir le paramètre container-env-file pour le conteneur d'applications ? Et comment passer l'instruction --env-file .env.list au moment de l'exécution afin qu'elle soit récupérée dans les conteneurs liés ?

Mon application yaml ressemble maintenant à ceci (j'ai intentionnellement laissé la configuration LDAP vide):

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

J'exécute ensuite la commande suivante pour démarrer le conteneur 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

Un problème connexe se trouve ici , mais celui-ci utilise un Docker compose.yml. Est-il possible de configurer des choses sans Docker Compose ? Qu'est-ce que je rate?

Toute aide gentiment appréciée!

question

Source

Bertusian

Commentaire le plus utile

Je vais essayer d'expliquer plus clairement : vous avez un système hôte et 2 conteneurs : un externe où s'exécute shinyproxy et un interne avec votre application.
En exécutant docker run --env-file ... sur votre système hôte, vous rendez les variables d'environnement de ce fichier sur le système hôte disponibles pour le conteneur externe en tant que vars env. Vous pouvez maintenant les transmettre davantage au conteneur interne à l'aide container-env variable
Alternativement, vous pouvez monter le dossier hôte avec votre fichier dans votre conteneur externe, puis vous pouvez rendre les variables d'environnement de ce fichier disponibles dans votre conteneur interne en utilisant la variable container-env-file .

Un exemple de commande pour la 2ème alternative peut être quelque chose comme :

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

en supposant que votre fichier .env.list se trouve dans /home/envs/ sur votre hôte - vous le rendez disponible dans le conteneur externe sous /tmp/envs/env.list avec le montage de volume - vous pouvez maintenant utiliser container-env-file: /tmp/envs/.env.list dans votre application.yml

Un exemple pour la 1ère alternative consiste à utiliser votre commande d'origine, puis dans le fichier application.yaml, utilisez container-env avec quelque chose comme :

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

où VAR1 et VAR2 sont des vars env définies dans le fichier sur l'hôte et donc disponibles en tant que vars env dans le conteneur externe, et ici vous les transmettez au conteneur interne en tant que VAR11 et VAR22 (par exemple, vous pouvez bien sûr utiliser les mêmes noms aussi )

mnazarov le 28 oct. 2020

👍3

Tous les 5 commentaires

Salut @Bertusian ,
Je pense que le problème est que vous exécutez shinyproxy lui-même dans un conteneur, vous devez donc rendre votre fichier .env.list disponible à l'intérieur de ce conteneur (en le montant en volume), ou bien utiliser container-env avec env vars que vous passez via un fichier dans votre commande docker run. De plus, je pense que container-env-file attend un chemin absolu.

mnazarov le 27 oct. 2020

Salut @ mnazarov.

En effet, j'exécute shinyproxy dans un conteneur. Pouvez-vous éventuellement fournir un exemple de la commande d'exécution pour lancer le conteneur shinyproxy (avec le volume .env.list monté), et est-elle ensuite capturée par le conteneur R-app ? Je pensais que le .env.list était disponible en ajoutant --env-file ~/.env.list (qui fonctionnait lors de l'exécution du conteneur sans shinyproxy).
Et dois-je encore adapter le fichier application.yml ? Toujours pas très clair pour moi. Reconnaissant pour toute aide ou exemple...

Bertusian le 27 oct. 2020

Un exemple de commande pour la 2ème alternative peut être quelque chose comme :

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

Un exemple pour la 1ère alternative consiste à utiliser votre commande d'origine, puis dans le fichier application.yaml, utilisez container-env avec quelque chose comme :

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

mnazarov le 28 oct. 2020

👍3

OMG. C'est bien! Maintenant ça marche. Je n'ai pas essayé la première suggestion (mais je le ferai plus tard), mais votre deuxième solution l'a fait directement ! Je savais que j'étais proche, mais je ne pouvais pas le trouver.

Merci beaucoup!!

Des trucs formidables que vous faites avec ShinyProxy.

Bertusian le 28 oct. 2020

👍2

Je suis content que ça marche !

mnazarov le 28 oct. 2020

Cette page vous a été utile?

0 / 5 - 0 notes