Shinyproxy: Passar credenciais SQL em tempo de execução com o aplicativo Glossproxy.yml

Criado em 27 out. 2020  ·  5Comentários  ·  Fonte: openanalytics/shinyproxy

Oi,

Eu tenho um aplicativo Glossproxy funcionando com autenticação ldap. No entanto, para recuperar dados do banco de dados SQL, agora uso (não recomendado) uma cadeia de conexões codificada no meu código R com as credenciais mencionadas aqui (eu uso um usuário de serviço porque meus usuários finais não têm permissão para consultar o banco de dados):

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

Tentei substituir essa string de conexão por uma variável de ambiente, que passo do meu host linux para o contêiner. O código R agora mudou para:

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

Isso funciona bem ao executar o contêiner fora do ShinyProxy e, portanto, ao passar as variáveis ​​ambientais no tempo de execução com o seguinte comando docker:

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

A variável de ambiente também é encontrada ao entrar no contêiner em execução e digitar 'env'.

No entanto, ao usar ShinyProxy, não está claro para mim como configurar isso no arquivo de configuração yaml e no comando bash em tempo de execução. Como defino o parâmetro container-env-file para o app container? E como passo a instrução --env-file .env.list em tempo de execução para que seja coletada nos contêineres vinculados?

Meu aplicativo yaml agora se parece com isto (eu deixei intencionalmente a configuração do ldap em branco):

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

Em seguida, executo o seguinte comando para iniciar o contêiner 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

Um problema relacionado é encontrado aqui , mas este usa um Docker compose.yml. É possível configurar coisas sem um Docker Compose? O que estou perdendo?

Qualquer ajuda bem-vinda!

question
Fonte
picture Bertusian

Comentários muito úteis

Vou tentar explicar mais claramente: você tem um sistema host e 2 contêineres: um externo onde o Glossproxy está rodando e um interno com o seu aplicativo.
Ao executar docker run --env-file ... em seu sistema host, você torna as variáveis ​​de ambiente desse arquivo no sistema host disponíveis para o contêiner externo como env vars. Agora você pode passá-los para o contêiner interno usando a variável container-env .
Alternativamente, você pode montar a pasta host com seu arquivo em seu contêiner externo e, em seguida, tornar os env vars desse arquivo disponíveis em seu contêiner interno usando a variável container-env-file .

Um exemplo de comando para a 2ª alternativa pode 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

assumindo que seu arquivo .env.list está localizado em / home / envs / em seu host - você o disponibiliza no contêiner externo em /tmp/envs/env.list com montagem de volume - agora você pode usar container-env-file: /tmp/envs/.env.list em seu application.yml

Um exemplo para a 1ª alternativa é usar seu comando original e, em seguida, em application.yaml, use container-env com algo como:

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

onde VAR1 e VAR2 são env vars definidos no arquivo no host e, portanto, disponíveis como env vars no contêiner externo, e aqui você os passa para o contêiner interno como VAR11 e VAR22 (por exemplo, você pode, é claro, usar os mesmos nomes também )

picture mnazarov em 28 out. 2020
👍3

Todos 5 comentários

Olá @Bertusian ,
Acho que o problema é que você está executando o próprio Glossproxy em um contêiner, então você precisa disponibilizar o seu arquivo .env.list dentro desse contêiner (por montagem de volume), ou alternativamente usar container-env com env vars que você passa via arquivo em seu comando docker run. Além disso, acredito que container-env-file espera um caminho absoluto.

mnazarov picture mnazarov em 27 out. 2020

Olá @ mnazarov.

Na verdade, estou executando o brightproxy em um contêiner. Você pode eventualmente fornecer um exemplo do comando runtime para lançar o contêiner brilhante (com o volume .env.list montado), e ele é então capturado pelo contêiner R-app? Pensei que o .env.list foi disponibilizado adicionando --env-file ~ / .env.list (que funcionou ao executar o contêiner sem brilhanteproxy).
E ainda preciso adaptar o application.yml? Ainda não está muito claro para mim. Grato por qualquer ajuda ou um exemplo ...

Bertusian picture Bertusian em 27 out. 2020

Vou tentar explicar mais claramente: você tem um sistema host e 2 contêineres: um externo onde o Glossproxy está rodando e um interno com o seu aplicativo.
Ao executar docker run --env-file ... em seu sistema host, você torna as variáveis ​​de ambiente desse arquivo no sistema host disponíveis para o contêiner externo como env vars. Agora você pode passá-los para o contêiner interno usando a variável container-env .
Alternativamente, você pode montar a pasta host com seu arquivo em seu contêiner externo e, em seguida, tornar os env vars desse arquivo disponíveis em seu contêiner interno usando a variável container-env-file .

Um exemplo de comando para a 2ª alternativa pode 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

assumindo que seu arquivo .env.list está localizado em / home / envs / em seu host - você o disponibiliza no contêiner externo em /tmp/envs/env.list com montagem de volume - agora você pode usar container-env-file: /tmp/envs/.env.list em seu application.yml

Um exemplo para a 1ª alternativa é usar seu comando original e, em seguida, em application.yaml, use container-env com algo como:

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

onde VAR1 e VAR2 são env vars definidos no arquivo no host e, portanto, disponíveis como env vars no contêiner externo, e aqui você os passa para o contêiner interno como VAR11 e VAR22 (por exemplo, você pode, é claro, usar os mesmos nomes também )

mnazarov picture mnazarov em 28 out. 2020
👍3

OH MEU DEUS. Isso é ótimo! Agora funciona. Não tentei a primeira sugestão (mas tentarei depois), mas sua segunda solução acertou direto! Eu sabia que estava perto, mas não conseguia encontrar.

Muito obrigado!!

Ótimas coisas que vocês estão fazendo com o ShinyProxy.

Bertusian picture Bertusian em 28 out. 2020
👍2

Estou feliz que funcionou!

mnazarov picture mnazarov em 28 out. 2020
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

fmmattioni picture fmmattioni  ·  3Comentários
lucius-verus-fan picture lucius-verus-fan  ·  8Comentários
jat255 picture jat255  ·  3Comentários
xtrasimplicity picture xtrasimplicity  ·  5Comentários
chienyuchuan picture chienyuchuan  ·  8Comentários