"إذا أراد العامل أن يؤدي عمله بشكل جيد، فعليه أولاً أن يشحذ أدواته." - كونفوشيوس، "مختارات كونفوشيوس. لو لينجونج"
الصفحة الأمامية > برمجة > طريقة أنيقة لإصلاح معرفات المستخدمين في حاويات عامل الإرساء باستخدام docker_userid_fixer

طريقة أنيقة لإصلاح معرفات المستخدمين في حاويات عامل الإرساء باستخدام docker_userid_fixer

تم النشر بتاريخ 2024-11-01
تصفح:631

an elegant way to fix user IDs in docker containers using docker_userid_fixer

ما هو الأمر؟

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

حاويات عامل الإرساء كبيئات التنفيذ

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

تختلف الحاويات كبيئات التنفيذ تمامًا:

  • بدلاً من وضع التطبيق في حاوية، فإن نظام بناء التطبيق هو الذي يتم وضعه في حاوية.
    • يمكن أن يكون مترجمًا، أو IDE، أو محرك كمبيوتر محمول، أو نظام نشر Quarto...
  • الأهداف هي:
    • أن يكون لديك معيار، بيئة سهلة التثبيت والمشاركة
      • تخيل بيئة بناء معقدة، مع إصدارات ثابتة من R وpython ومليارات من الحزم الخارجية. قد يكون تثبيت كل شيء بالإصدارات الصحيحة مهمة صعبة للغاية وتستغرق وقتًا طويلاً. من خلال مشاركة صورة عامل إرساء تحتوي على كل شيء تم تثبيته وتكوينه مسبقًا، يعد ذلك بمثابة توفير حقيقي للوقت.
    • للحصول على بيئة قابلة للتكرار.
      • باستخدامه، يمكنك إعادة إنتاج بعض نتائج التحليل، نظرًا لأنك تستخدم نفس البيئة الخاضعة للرقابة
      • يمكنك أيضًا إعادة إنتاج الأخطاء بسهولة، وهي الخطوة الأولى لإصلاحها

ولكن، من أجل استخدام بيئات التنفيذ هذه، يجب أن تتمتع هذه الحاويات بإمكانية الوصول إلى النظام المضيف، وخاصة إلى نظام ملفات المستخدم المضيف.

حاويات عامل الإرساء ونظام الملفات المضيف

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

لذلك يمكنك ربط مجلد المشروع الخاص بك (في نظام الملفات المضيف) باستخدام خيار docker run --volume. ومن ثم يمكن الوصول إلى ملفاتك من داخل حاوية عامل الإرساء.

التحدي الآن هو أذونات الملف. لنفترض أن المستخدم المضيف لديه معرف المستخدم

1001، ولنفترض أن المستخدم الذي يمتلك عملية Rsudio في الحاوية هو إما 0 (الجذر)، أو 1002.

إذا كان مستخدم الحاوية هو

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

الآن إذا كان معرف مستخدم الحاوية هو

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

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

حل مشكلة مالك الملف الجزء 1: خيار docker run --user

لأننا لا نستطيع أن نعرف مسبقًا ما هو معرف المستخدم المضيف (هنا

1001)، لا يمكننا التهيئة المسبقة معرف المستخدم لمستخدم حاوية عامل الإرساء.
يوفر

docker run الآن خيار --user الذي يمكّن من إنشاء مستخدم زائف مع بعض معرف المستخدم المقدم في وقت التشغيل. على سبيل المثال، سيقوم docker run --user 1001 ... بإنشاء حاوية عامل إرساء تعمل بالعمليات
ينتمي إلى مستخدم بمعرف المستخدم
1001.

إذن ما الذي لا نزال نناقشه في هذه المشكلة؟ لم يتم حلها؟

إليك بعض المراوغات حول هذا المستخدم الذي تم إنشاؤه ديناميكيًا:

    إنه مستخدم زائف
  • لا يحتوي على دليل رئيسي (/home/xxx)
  • لا يظهر في /etc/passwd
  • لا يمكن تكوينه مسبقًا، على سبيل المثال. مع ملف تعريف bash، وبعض متغيرات env، والإعدادات الافتراضية للتطبيق، وما إلى ذلك...
يمكننا التغلب على هذه المشكلات، ولكن قد يكون الأمر مملاً ومحبطًا.

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

حل مشكلة مالك الملف الجزء 2: أدخل docker_userid_fixer

docker_userid_fixer هي أداة مساعدة مفتوحة المصدر مخصصة للاستخدام كنقطة دخول لعامل الإرساء

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

معرف المستخدم

الخاص به ديناميكيًا:
نقطة الدخول ["/usr/local/bin/docker_userid_fixer"،"user1"]

ENTRYPOINT ["/usr/local/bin/docker_userid_fixer","user1"]

المستخدم
    الهدف
  • ، هو المستخدم المطلوب لـ docker_userid_fixer، هنا user1 المستخدم
  • المطلوب
  • ، هو المستخدم الذي يتم توفيره بواسطة تشغيل عامل الإرساء، أي المستخدم الذي يمتلك (مبدئيًا) العملية الأولى (PID 1)
  • ثم، عند إنشاء وقت تشغيل الحاوية، هناك خياران:

إما أن يتطابق معرف المستخدم
  • المطلوب (بالفعل) مع معرف المستخدم الهدف، فلا يجب تغيير أي شيء أو لا. على سبيل المثال، معرف المستخدم
  • المطلوب
  • هو 1001، ومعرف المستخدم الهدف هو 100. بعد ذلك، سيقوم docker_userid_fixer بإصلاح معرف المستخدم target user user1 من 1000 إلى 1001، مباشرة في العملية الرئيسية للحاوية.
  • لذا فإن هذا يحل مشكلتنا عمليًا:

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

يمكنك العثور على تعليمات حول الإعداد هنا.

ولكن الأمر يتلخص في:

    إنشاء أو تنزيل الملف القابل للتنفيذ الصغير (17 كيلو بايت)
  • انسخها إلى صورة عامل الإرساء الخاص بك
  • جعله قابلاً للتنفيذ كجذر setuid
  • قم بتكوينها كنقطة الدخول الخاصة بك
  • التفاصيل الدموية

لقد وضعت بعض الملاحظات القصيرة https://github.com/kforner/docker_userid_fixer#how-it-works

ولكن سأحاول إعادة الصياغة.


جوهر التنفيذ هو

جذر setuid

لـ docker_userid_fixer القابل للتنفيذ في الحاوية. نحتاج إلى أذونات الجذر لتغيير معرف المستخدم، وهذا الإعداد يمكّن هذا التنفيذ المميز فقط لـ برنامج docker_userid_fixer، وذلك لفترة قصيرة جدًا.

بمجرد تعديل معرف المستخدم إذا لزم الأمر، سيقوم docker_userid_fixer بتبديل العملية الرئيسية

إلى المستخدم المطلوب (ومعرف المستخدم!).


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

بيان الافراج تم إعادة نشر هذه المقالة على: https://dev.to/kforner/an-elegant-way-to-fix-user-ids-in-docker-containers-using-dockeruseridfixer-3c9i إذا كان هناك أي انتهاك، يرجى الاتصال بـ Study_golang @163.com حذف
أحدث البرنامج التعليمي أكثر>

تنصل: جميع الموارد المقدمة هي جزئيًا من الإنترنت. إذا كان هناك أي انتهاك لحقوق الطبع والنشر الخاصة بك أو الحقوق والمصالح الأخرى، فيرجى توضيح الأسباب التفصيلية وتقديم دليل على حقوق الطبع والنشر أو الحقوق والمصالح ثم إرسالها إلى البريد الإلكتروني: [email protected]. سوف نتعامل مع الأمر لك في أقرب وقت ممكن.

Copyright© 2022 湘ICP备2022001581号-3