Supervisor: طلب الميزة: تضمين متغيرات البيئة من ملف خارجي

إذا قمت بتشغيل برنامج Python النصي هذا تحت supervisord ، فسوف يتخلص من بيئته:

#!/usr/bin/env python -u
import os
print(os.environ)

ستلاحظ أن العمليات الفرعية ترث بيئة supervisord .

إذا كنت تريد متغيرات في بيئة جميع العمليات الفرعية ولكن لا تريد وضعها في supervisord.conf ، يمكنك وضعها في البيئة قبل بدء supervisord في البرنامج النصي الخاص بك:

export FOO=BAR
supervisord 

إذا كنت تريد متغيرات على أساس كل برنامج ، فيمكنك الحصول على supervisord لبدء برنامج نصي شل لتشغيل البرنامج الخاص بك. يقوم البرنامج النصي shell بتحميل المتغيرات في البيئة ثم تشغيل البرنامج.

لدينا قائمة بريدية نشطة حيث يمكنك طرح الأسئلة والحصول على نصائح لاستخدام المشرف.

حسنا، شكرا للمعلومات!

تضمين التغريدة
قد تكون مهتمًا أيضًا بـ envdir ، الذي يستدعي البرامج التي تستخدم env vars من دليل: https://github.com/jezdez/envdir

شكرا دانيال! إنها حقًا أداة ذكية.

آه ، سيكون من الجيد أن يكون لديك خيار للقيام بذلك ...

إذا كان لا بد لي من إنشاء برنامج نصي يقوم بتشغيل المشرف مع بعض متغيرات env ، فهذا يعني أنه لا يمكنني استخدام البرنامج النصي init الخاص بمشرف التوزيع الخاص بي.

surjikal قد يوفر البرنامج النصي الخاص بالتوزيعة

jvoorhis صحيح! يمتلك Gentoo هذا الشيء الرائع /etc/env.d الذي يتيح لي تعيين متغيرات البيئة على مستوى النظام. يعمل بشكل مثالي.

لقد عثرت على نص الحرف الأول في: / etc / default / supervisor

حالة الاستخدام:
خادم إنتاج به 10 عمليات أو نحو ذلك تم تكوينها تحت إشراف. تعتمد هذه العمليات على الإدخال / الإخراج من قاعدة بيانات بعيدة لإكمال المعاملات للمستخدمين. في الوقت الحالي ، تتطلب أي تغييرات في متغيرات البيئة خارج ملف التكوين إعادة تشغيل الخدمة ، مما قد يقطع أي عمليات قيد التشغيل تكون في منتصف المعاملات.

سيكون سؤالي في هذه الحالة ، هل ستكون ميزة "ملف متغير البيئة الخارجية" منطقية هنا ، بحيث يمكن تعريف المتغيرات وإعادة قراءتها داخل المشرف ، أم أن هذه مسألة تتعلق بكيفية اختيار العملية الفرعية لكيفية الإنهاء عند إرسال الإشارة ؟

كما هو مقترح أعلاه ، سيكون الحل البسيط هو التفاف الأمر الهدف مع برنامج نصي آخر يقوم بتحميل متغيرات البيئة من ملف.

يمكن أن يكون لديك برنامج نصي محلي (أو متحكم فيه المصدر) مثل:

run_with_env.sh

#!/bin/bash

ENV_FILE="$1"
CMD=${@:2}

set -o allexport
source $ENV_FILE
set +o allexport

$CMD

ثم اجعل أمر مشرفك مثل هذا:

command=run_with_env.sh envfile some-program param1 param2

مستوحاة من هذه الإجابة على SO 30969768/1629696

النص البديل رائع ، لكن هذا لا يزال يبدو وكأنه شيء يجب أن يتم تضمينه للتو. من المدهش أن هذا لا يزال يظهر بعد 4 سنوات.

لا يعمل الحل إذا كنت بحاجة إلى بدء عملية جديدة ، فلن يتم إنهاء العمليات التي تم إطلاقها من ملف bash.
لقد توقعت أن يدعم خيار التكوين environment= أيضًا الملفات ، وليس فقط K = V التي ليست مرنة جدًا.
أنا عالق حاليًا حيث لا يمكنني تكرار جميع متغيرات البيئة التي يزيد عددها عن 60 لملف الخطاف ، فهو ببساطة لا معنى له.

تضمين التغريدة
هل جربت killasgroup=true و stopasgroup=true ؟

mnaberez هل هناك أي فرصة لقبول العلاقات العامة لإضافة environment_file ؟ أو هل هناك أي فرصة لواجهة مكون إضافي يمكنها تحديث التكوين بعد القراءة الأولية (أو شيء مشابه).

@ jonathan-golorry killasgroup/stopasgroup لها جوانبها السلبية (أي أنها تقتل المجموعة بأكملها ؛)). من المحتمل أن يكون الحل الأفضل هو استخدام bash exec الذي سيحل محل عملية bash بالبرنامج الجديد.

mnaberez هل هناك أي فرصة لقبول العلاقات العامة لإضافة ملف البيئة؟

لا ، فإن كتابة نص برمجي قصير لتعيين متغيرات البيئة هو إلى حد كبير نفس مقدار العمل للمستخدم النهائي مثل كتابة ملف INI لمتغيرات البيئة ، فقط البرنامج النصي للصدفة هو أكثر قوة ويمكنه القيام بأشياء أخرى أيضًا.

بالإشارة إلى هذا التعليق ، استخدم exec لتشغيل الأمر كما هو مذكور بواسطة @ apollo13. سيؤدي ذلك إلى استبدال عملية bash بالبرنامج الجديد ، وسيصبح هذا البرنامج تابعًا مباشرًا لـ supervisord (يمكنك التحقق من ذلك باستخدام pstree أو ما شابه).

mnaberez حول PR # 934 نعم أفهم تمامًا أنه يمكننا التفاف العملية داخل برنامج نصي bash لتحميل ENV من ملف. لكن القيام بذلك يجعل إعدادنا يصبح مشعرًا. ألن يكون لطيفًا لو نقلنا الوظيفة إلى مشرف؟ على سبيل المثال:
[البرنامج: foo]
env_file = bar.env
الأمر = صحيح

nhamlh لقد قال بالفعل بوضوح إنه لا يريد دعمها. في هذا الوقت يبدو أنه مضيعة لوقتك ووقته للاستمرار في هذا المكان.

تضمين التغريدة

سيكون من الرائع أن يكون لديك مثال عملي بالكامل في هذا الموضوع. قد يكون الأمر واضحًا بالنسبة لك ، لكنه بالتأكيد ليس للجميع. وهذا الموضوع يأتي أولاً في Google.

شكرا على البرنامج الرائع واستمروا في العمل الجيد!

مرحبا،

في الأحد ، 30 يوليو 2017 ، الساعة 09:16 صباحًا ، كتب gabn88:

سيكون من الرائع أن يكون لديك مثال عملي بالكامل في هذا الموضوع. هو - هي
قد يكون واضحًا بالنسبة لك ، لكنه بالتأكيد ليس للجميع. وهذا
موضوع يأتي أولا في جوجل.

هذا المثال موجود بالفعل بالفعل (انظر بعض التعليقات أعلاه + my
اقتراح تعديل طفيف عبر exec):

#!/bin/bash

ENV_FILE="$1"
CMD=${@:2}

set -o allexport
source $ENV_FILE
set +o allexport

exec $CMD

الاتصال مع

command=run_with_env.sh envfile some-program param1 param2

لم تختبر ، يرجى المحاولة والإبلاغ مرة أخرى ؛ سوف أقوم بتحديث آخر
وفقا لذلك.

في الجمعة ، 4 آب (أغسطس) 2017 ، الساعة 07:49 صباحًا ، كتب نينو والكر:

اقرأ ال
الداخلية ،
ربما يكون البديل هو تنفيذ مكون إضافي يستمع إلى ملف
ProcessStarting state ، واجعل البرنامج المساعد يقوم بسحره لمعالجة ملف
ProcessConfig.

بناءً على فهمي لمستمعي الحدث (والذي أفترض أنك تقصده
plugins) كبرامج بحد ذاتها ولا يمكن تحديث الحالة فيها
عملية إتقان المشرف (إلا إذا كنت أفتقد طريقة للكتابة
الإضافات طوال الوقت - ولكن بعد ذلك لم ألق نظرة عن كثب).

كان الحل أن أضيف
. /etc/environment
كخط أخير إلى / etc / default / supervisor

يجب أن نكرر هذا ، النقاء رائع ، ولكن هناك استخدام عملي للبذر / المرور عبر تلك المتغيرات البيئية التي ستوفر لي الكثير من الصداع. فلدي العثور على الاختراق الآن.

شكرا مرة أخرى على البرنامج الرائع.

يمنحك نظام +1 Environment و / أو EnvironmentFile id أن ترى شيئًا مشابهًا هنا

mnaberez ، هل يمكنك إعادة فتح هذه المشكلة لأنها تبدو شائعة ، والحل البديل الحالي ليس مرضيًا حقًا ...

الحل من خلال tuuling هو الكمال IMHO

إلا أنه لا يعمل في الحالة التي تحتاج فيها إلى ملفات متغيرة env مختلفة لبرامج مختلفة ، وهو imo هو السبب الرئيسي للقيام بذلك. وإلا يمكنك وضعه في /etc/environment / /etc/default/supervisor أو شيء من هذا القبيل.

هذا ما فعلته ، كانت المشكلة أن المشرف بشكل افتراضي لم يدرجه.

أدرك أنني أتطرق إلى مشكلة مغلقة ، لكنني أدركت أنني سأضع هذا هنا لمساعدة أولئك الذين يصلون إلى هنا عبر Google (كما فعلت).

حالة الاستخدام الخاصة بي هي أنني أردت شيئًا أقوى قليلاً من التيني للتعامل مع جني الزومبي في Docker. على وجه التحديد ، تشغيل عملية GitHub runner المستضافة ذاتيًا والتي يمكنها الخروج وإعادة تشغيل نفسها أثناء التحديث - وهو أمر لا تستطيع tini التعامل معه.

بمعنى آخر ، أحتاج إلى أن يكون المشرف هو PID 1 ولديه بيئة سهلة التوصيل.

لقد جربت عدة حلول لتحميل ملف /etc/environment كبيئة عبر المشرف.

لقد جربت الحل tuuling المذكور في https://github.com/Supervisor/supervisor/issues/242#issuecomment -322421857 بدون حظ.

حاولت أيضًا:

command=/bin/bash -c 'source "$0" && exec "$@"' /etc/environment /home/runner/actions-runner/bin/runsvc.sh

كان بإمكاني تغليف البرنامج النصي للغلاف ، أو تعديل البرنامج النصي للغلاف. تكمن المشكلة في السابق في أن العداء يتوقف عن العمل ويعيد تشغيل نفسه أثناء التحديثات ، لذلك سأضطر إلى إعادة إنتاج معالجة الإشارة الضرورية في الغلاف الخاص بي. تتعلق مشكلة هذا الأخير أيضًا بإعادة بدء العمل ، ولكن هذه المرة فقط سأضطر إلى اكتشاف إعادة التشغيل ، وإعادة إدخال التغييرات التي أجريتها على البرنامج النصي قبل إعادة تشغيله.

لم ينجح أي من الحلول التي وجدتها باستثناء إضافة المتغيرات إلى supervisord.conf عبر خيار التكوين environment .

إليك القشرة السحرية ذات الأسطر الواحدة التي تدمج الملف /etc/environment في سطر واحد مفصول بفاصلات بقيم مقتبسة:

شيل النصي
القط / الخ / البيئة \
| sed -e 's / "// g' \
| awk -F = '{key = $ 1} {value = $ 2} BEGIN {printf "environment ="} NR> 1 {printf "،"} {printf key "= \ 42" value "\ 42"} END {printf " \ن"}' \

/etc/supervisor/conf.d/supervisord.conf
الأمر ` (that first sed` هو إزالة علامات الاقتباس - الملف مقتبس بشكل غير متسق - أمر awk يعيدها باستمرار)

يوجد خيار تكوين ملف البيئة المقترح في systemd لسبب ، وهو الحاجة إلى تحميل عدد كبير من المتغيرات بطريقة قابلة للتوصيل. ليس من قبيل الصدفة أن يستخدم غلاف تسجيل الدخول بيئة / etc / بيئة وأن هذا الملف قادر على القيام بواجب مزدوج في ملف وحدة systemd. يعد تحميل أزواج القيمة الرئيسية كمتغيرات بيئة عبر ملف بسيط نمطًا متكررًا في Docker و systemd و k8s وفي العديد من الأنظمة الأخرى. mnaberez أنا في حيرة من