やあ、
LDAP認証を使用して動作するshinyproxyアプリがあります。 ただし、SQLデータベースからデータを取得するために、ここに記載されている資格情報を使用してRコードでハードコードされた接続文字列を使用します(エンドユーザーにはデータベースをクエリする権限がないため、サービスユーザーを使用します)。
con <- DBI::dbConnect(odbc::odbc(), encoding = "latin1", .connection_string = 'Driver={Driver};Server=Server;Database=dbb;UID=UID;PWD=PWD')
この接続文字列を、Linuxホストからコンテナに渡す環境変数に置き換えようとしました。 Rコードは次のように変更されました。
connString <- Sys.getenv("CONNSTRING")
connString <- sub("\\\\","\\", connString)
con <- DBI::dbConnect(odbc::odbc(), encoding = "latin1", .connection_string = connString)
これは、ShinyProxyの外部でコンテナーを実行する場合、つまり実行時に次のdockerコマンドを使用して環境変数を渡すことにより、正常に機能します。
docker run -it --env-file .env.list app123
環境変数は、実行中のコンテナーに入って「env」と入力したときにも検出されます。
ただし、ShinyProxyを使用する場合、yaml構成ファイルと実行時のbashコマンドでこれを構成する方法がわかりません。 アプリコンテナのパラメータcontainer-env-fileを定義するにはどうすればよいですか? また、実行時にステートメント--env-file .env.listを渡して、リンクされたコンテナーで取得されるようにするにはどうすればよいですか?
私のアプリケーションyamlは次のようになります(意図的にldap configを空白のままにしました):
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
次に、次のコマンドを実行して、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
関連する問題はここにありますが、これはDockercompose.ymlを使用しています。 Docker Composeなしで設定することは可能ですか? 何が足りないのですか?
どんな助けでも親切に感謝します!
こんにちは@Bertusian 、
問題は、shinyproxy自体をコンテナーで実行していることだと思います。そのため、 .env.list
ファイルをそのコンテナー内で(ボリュームマウントによって)使用できるようにするか、代わりにenvでcontainer-env
を使用する必要があります。 dockerrunコマンドでファイルを介して渡す変数。 さらに、 container-env-file
は絶対パスを期待していると思います。
こんにちは@mnazarov。
確かに、私はコンテナでshinyproxyを実行しています。 最終的に、shinyproxyコンテナー(.env.listボリュームがマウントされている)を起動するためのランタイムコマンドの例を提供できますか?それはR-appコンテナーによってキャプチャされますか? --env-file〜 / .env.list(shinyproxyなしでコンテナーを実行したときに機能します)を追加することで、.env.listが使用可能になると思いました。
そして、私はまだapplication.ymlを適応させる必要がありますか? まだ私にはあまり明確ではありません。 どんな援助や例にも感謝します...
より明確に説明しようと思います。ホストシステムと2つのコンテナーがあります。1つはshinyproxyが実行されている外側で、もう1つはアプリの内側です。
ホストシステムでdocker run --env-file ...
を実行することにより、ホストシステム上のそのファイルの環境変数を環境変数として外部コンテナーで使用できるようにします。 これで、 container-env
変数を使用して、それらをさらに内部コンテナーに渡すことができます。
または、ファイルを含むホストフォルダーを外部コンテナーにマウントし、 container-env-file
変数を使用して、そのファイルのenv変数を内部コンテナーで使用できるようにすることもできます。
2番目の選択肢のコマンドの例は、次のようになります。
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
.env.listファイルがホストの/ home / envs /にあると仮定すると、ボリュームマウントを使用して/tmp/envs/env.listの下の外部コンテナーで使用できるようになります。これでcontainer-env-file: /tmp/envs/.env.list
使用できます。あなたのapplication.ymlで
最初の選択肢の例は、元のコマンドを使用してから、application.yamlでcontainer-env
を次のように使用することです。
container-env:
VAR11: "${VAR1}"
VAR22: "${VAR2}"
ここで、VAR1とVAR2は、ホスト上のファイルで定義されているenv varであるため、外部コンテナーでenv varとして使用できます。ここで、これらをVAR11とVAR22として内部コンテナーに渡します(たとえば、もちろん同じ名前を使用することもできます)。 )
ああ、神様。 これは素晴らしい! 今では動作します。 私は最初の提案を試していませんが(後で行います)、2番目の解決策はそれをまっすぐに行いました! 近くにいることはわかっていましたが、見つかりませんでした。
どうもありがとうございます!!
皆さんがShinyProxyでやっている素晴らしいこと。
私はそれがうまくいったことをうれしく思います!
最も参考になるコメント
より明確に説明しようと思います。ホストシステムと2つのコンテナーがあります。1つはshinyproxyが実行されている外側で、もう1つはアプリの内側です。
ホストシステムで
docker run --env-file ...
を実行することにより、ホストシステム上のそのファイルの環境変数を環境変数として外部コンテナーで使用できるようにします。 これで、container-env
変数を使用して、それらをさらに内部コンテナーに渡すことができます。または、ファイルを含むホストフォルダーを外部コンテナーにマウントし、
container-env-file
変数を使用して、そのファイルのenv変数を内部コンテナーで使用できるようにすることもできます。2番目の選択肢のコマンドの例は、次のようになります。
.env.listファイルがホストの/ home / envs /にあると仮定すると、ボリュームマウントを使用して/tmp/envs/env.listの下の外部コンテナーで使用できるようになります。これで
container-env-file: /tmp/envs/.env.list
使用できます。あなたのapplication.ymlで最初の選択肢の例は、元のコマンドを使用してから、application.yamlで
container-env
を次のように使用することです。ここで、VAR1とVAR2は、ホスト上のファイルで定義されているenv varであるため、外部コンテナーでenv varとして使用できます。ここで、これらをVAR11とVAR22として内部コンテナーに渡します(たとえば、もちろん同じ名前を使用することもできます)。 )