Shinyproxy: تمرير بيانات اعتماد SQL في وقت التشغيل باستخدام تطبيق shinyproxy.yml

تم إنشاؤها على ٢٧ أكتوبر ٢٠٢٠ · 5تعليقات · مصدر: openanalytics/shinyproxy

أهلا،

لدي تطبيق shinyproxy يعمل مع مصادقة ldap. ومع ذلك ، لاسترداد البيانات من قاعدة بيانات 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 في وقت التشغيل. كيف يمكنني تحديد ملف الحاوية- env-الملف لحاوية التطبيق؟ وكيف يمكنني تمرير العبارة - env-file .env.list في وقت التشغيل بحيث يتم التقاطها في الحاويات المرتبطة؟

يبدو تطبيقي yaml الآن على هذا النحو (تركت عن قصد تهيئة ldap فارغة):

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

تم العثور على مشكلة ذات صلة هنا ، ولكن هذه المشكلة تستخدم Docker compose.yml. هل من الممكن تكوين الأشياء بدون Docker Compose؟ ماذا ينقصني؟

نقدر أي مساعدة تتكرم!

question

مصدر

Bertusian

التعليق الأكثر فائدة

سأحاول أن أشرح بشكل أكثر وضوحًا: لديك نظام مضيف وحاويتان: أحدهما خارجي حيث يعمل shinyproxy والآخر داخلي مع تطبيقك.
من خلال تشغيل docker run --env-file ... على نظامك المضيف ، فإنك تجعل متغيرات البيئة من هذا الملف على النظام المضيف متاحة للحاوية الخارجية كمتغيرات env. يمكنك الآن تمريرها إلى الحاوية الداخلية باستخدام متغير container-env .
بدلاً من ذلك ، يمكنك تحميل مجلد المضيف مع ملفك في الحاوية الخارجية ، ومن ثم يمكنك إتاحة متغيرات البيئة من هذا الملف في الحاوية الداخلية باستخدام متغير container-env-file .

قد يكون أحد الأمثلة على الأمر البديل الثاني بعض الشيء مثل:

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 في التطبيق الخاص بك. iMl

مثال على البديل الأول هو استخدام الأمر الأصلي الخاص بك ، ثم في التطبيق. yaml استخدم container-env مع شيء مثل:

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

حيث VAR1 و VAR2 عبارة عن متغيرات env معرَّفة في الملف على المضيف ، وبالتالي فهي متوفرة كمتغيرات env في الحاوية الخارجية ، وهنا تقوم بتمريرها إلى الحاوية الداخلية مثل VAR11 و VAR22 (على سبيل المثال ، يمكنك بالطبع استخدام نفس الأسماء أيضًا )

mnazarov في ٢٨ أكتوبر ٢٠٢٠

👍3

ال 5 كومينتر

مرحبًا Bertusian ،
أعتقد أن المشكلة تكمن في أنك تقوم بتشغيل shinyproxy نفسه في حاوية ، لذا فأنت بحاجة إلى إتاحة ملف .env.list داخل تلك الحاوية (من خلال تركيبه على الحجم) ، أو بدلاً من ذلك استخدم container-env مع env vars التي تقوم بتمريرها عبر ملف في أمر تشغيل عامل الإرساء. بالإضافة إلى ذلك ، أعتقد أن container-env-file يتوقع مسارًا مطلقًا.

mnazarov في ٢٧ أكتوبر ٢٠٢٠

مرحبا @ mnazarov.

في الواقع ، أنا أقوم بتشغيل shinyproxy في حاوية. هل يمكنك في النهاية تقديم مثال لأمر وقت التشغيل لإطلاق حاوية shinyproxy (مع تحميل مجلد env.list) ، وهل تم التقاطها بعد ذلك بواسطة حاوية R-app؟ اعتقدت أنه تم توفير قائمة env.list عن طريق إضافة --env-file ~ / .env.list (التي نجحت عند تشغيل الحاوية بدون shinyproxy).
وهل ما زلت بحاجة إلى تعديل application.yml؟ لا يزال غير واضح جدا بالنسبة لي. ممتن لأي مساعدة أو مثال ...

Bertusian في ٢٧ أكتوبر ٢٠٢٠

قد يكون أحد الأمثلة على الأمر البديل الثاني بعض الشيء مثل:

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

مثال على البديل الأول هو استخدام الأمر الأصلي الخاص بك ، ثم في التطبيق. yaml استخدم container-env مع شيء مثل:

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

mnazarov في ٢٨ أكتوبر ٢٠٢٠

👍3

يا إلهي. هذا عظيم! الآن يعمل. لم أجرب الاقتراح الأول (لكنني سأفعله لاحقًا) ، لكن حلك الثاني قام به بطريقة مباشرة! كنت أعلم أنني كنت قريبًا ، لكن لم أتمكن من العثور عليه.

شكرا جزيلا!!

أشياء رائعة يفعلونها مع ShinyProxy.

Bertusian في ٢٨ أكتوبر ٢٠٢٠

👍2

أنا سعيد لأنه نجح!

mnazarov في ٢٨ أكتوبر ٢٠٢٠

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات