s6 overlay

جدول المحتويات

• بداية سريعة
• التوافق مع الإصدار 2
• الأهداف
• سمات
• طريقة دوكر؟
• المراحل الأولية
• تثبيت
• الاستخدام
  • باستخدام CMD
  • كتابة سكريبت الخدمة
  • ضبط رمز الخروج الخاص بالحاوية على رمز الخروج الخاص بخدمتك الرئيسية
  • إصلاح الملكية والأذونات
  • تنفيذ مهام التهيئة والإنهاء
  • كتابة نص نهائي اختياري
  • التسجيل
  • إسقاط الامتيازات
  • نظام الملفات الجذر للقراءة فقط
  • بيئة الحاويات
  • تخصيص سلوك s6-overlay
  • سجل النظام
• أداء
• التحقق من التنزيلات
• ملحوظات
• الإصدارات
  • ما هي البنية التي يجب استخدامها وفقًا لـ TARGETARCH الخاص بك
• المساهمة
• بناء التراكب بنفسك
• ترقية الملاحظات

تراكب S6

s6-overlay عبارة عن مجموعة من البرامج النصية والأدوات المساعدة سهلة التثبيت (فقط قم باستخراج كرة قطران أو اثنتين!) مما يسمح لك باستخدام صور Docker الموجودة أثناء استخدام s6 كمعرف pid 1 للحاوية الخاصة بك ومشرف العمليات لخدماتك.

بداية سريعة

أنشئ ملف Dockerfile التالي وجربه:

 # Use your favorite image
FROM ubuntu
ARG S6_OVERLAY_VERSION=3.2.0.2

RUN apt-get update && apt-get install -y nginx xz-utils
RUN echo "daemon off;" >> /etc/nginx/nginx.conf
CMD ["/usr/sbin/nginx"]

ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz
ENTRYPOINT ["/init"]

 docker-host $ docker build -t demo .
docker-host $ docker run --name s6demo -d -p 80:80 demo
docker-host $ docker top s6demo acxf
PID                 TTY                 STAT                TIME                COMMAND
11735               ?                   Ss                  0:00                _ s6-svscan
11772               ?                   S                   0:00                _ s6-supervise
11773               ?                   Ss                  0:00                | _ s6-linux-init-s
11771               ?                   Ss                  0:00                _ rc.init
11812               ?                   S                   0:00                | _ nginx
11814               ?                   S                   0:00                | _ nginx
11816               ?                   S                   0:00                | _ nginx
11813               ?                   S                   0:00                | _ nginx
11815               ?                   S                   0:00                | _ nginx
11779               ?                   S                   0:00                _ s6-supervise
11785               ?                   Ss                  0:00                | _ s6-ipcserverd
11778               ?                   S                   0:00                _ s6-supervise
docker-host $ curl --head http://127.0.0.1/
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Mon, 17 Jan 2022 13:33:58 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 17 Jan 2022 13:32:11 GMT
Connection: keep-alive
ETag: "61e56fdb-264"
Accept-Ranges: bytes

التوافق مع الإصدار 2

إذا كنت تقوم بالترحيل من إصدار سابق من s6-overlay ( v2 ) إلى الإصدار الجديد ( v3 )، فقد تحتاج إلى إجراء بعض التغييرات على خدماتك أو طريقة استخدامك لـ s6-overlay حتى يعمل كل شيء بسلاسة. يحاول هذا المستند أن يكون دقيقًا بشأن كيفية عمل الإصدار 3، ولكن لدينا صفحة منفصلة تدرج الاختلافات الرئيسية والأشياء التي من المحتمل أن تلاحظها. يرجى قراءتها إذا كنت في هذا الموقف!

الأهداف

المشروع له الأهداف التالية:

• تكون قابلة للاستخدام فوق أي صورة Docker
• اجعل من السهل إنشاء صور جديدة تعمل مثل أي صور أخرى
• قم بتزويد المستخدمين بتثبيت s6 جاهز للاستخدام والذي سيمنحهم رقم تعريف ثابت 1، وتسلسل بدء وتسلسل إيقاف تشغيل سريع ومنظم، وقوة الإشراف على العملية والسجلات التي يتم تدويرها تلقائيًا.

سمات

• عملية init بسيطة تسمح للمستخدم النهائي بتنفيذ مهام مثل التهيئة ( cont-init.d ) والإنهاء ( cont-finish.d ) وخدماته الخاصة مع التبعيات بينهما
• يوفر تراكب s6 وظيفة PID 1 المناسبة
  • لن يكون لديك أبدًا عمليات زومبي معلقة في حاويتك، بل سيتم تنظيفها بشكل صحيح.
• عمليات متعددة في حاوية واحدة
• قادر على العمل في "The Docker Way"
• يمكن استخدامه مع جميع الصور الأساسية - Ubuntu، وCentOS، وFedora، وAlpine، وBusybox...
• يتم توزيعها على شكل عدد صغير من ملفات .tar.xz اعتمادًا على الوظيفة التي تحتاجها بالضبط - للحفاظ على عدد طبقات صورتك صغيرًا.
• مجموعة كاملة من الأدوات المساعدة المضمنة في s6 و s6-portable-utils . وهي تتضمن أدوات مساعدة سهلة الاستخدام وقابلة للتركيب مما يجعل حياتنا أسهل بكثير.
• يتم تدوير السجل خارج الصندوق من خلال logutil-service التي تستخدم s6-log أسفل الغطاء.
• بعض الدعم لتوجيهات USER الخاصة بـ Docker، لتشغيل شجرة العملية بأكملها كمستخدم محدد. غير متوافق مع جميع الميزات، التفاصيل في قسم الملاحظات.

طريقة دوكر؟

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

السبب الآخر الذي يجعل مؤلفي الصور يخجلون من مشرفي العمليات هو أنهم يعتقدون أنه يجب على مشرف العملية إعادة تشغيل الخدمات الفاشلة، مما يعني أن حاوية Docker لن تموت أبدًا.

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

سياستنا هي أنه إذا فشل "الشيء"، فيجب أن تفشل الحاوية أيضًا. نقوم بذلك عن طريق تحديد العمليات التي يمكن إعادة تشغيلها، والعمليات التي يجب أن تؤدي إلى إسقاط الحاوية. على سبيل المثال، إذا فشل cron أو syslog ، فمن المرجح أن تقوم حاويتك بإعادة تشغيلها دون أي آثار سيئة، ولكن إذا فشل ejabberd ، فيجب أن تخرج الحاوية حتى يتمكن مسؤول النظام من اتخاذ الإجراء اللازم.

تفسيرنا لـ "The Docker Way" هو كالتالي:

• يجب أن تفعل الحاويات شيئًا واحدًا
• يجب أن تتوقف الحاويات عندما يتوقف هذا الشيء

ونظام init الخاص بنا مصمم للقيام بذلك بالضبط. سوف تتصرف صورك مثل صور Docker الأخرى وتتناسب مع النظام البيئي الحالي للصور.

راجع "كتابة نص نهائي اختياري" ضمن قسم الاستخدام للحصول على تفاصيل حول إيقاف "الشيء".

المراحل الأولية

يعد تراكب init الخاص بنا مخصصًا بشكل صحيح للتشغيل بشكل مناسب في البيئات المعبأة في حاويات. يشرح هذا القسم بإيجاز كيفية عمل المراحل، ولكن إذا كنت تريد معرفة كيفية عمل نظام init الكامل، فيمكنك قراءة هذه المقالة: كيفية تشغيل s6-svscan كعملية 1

1. المرحلة 1 : الغرض منها هو إعداد الصورة لتنفيذ شجرة الإشراف التي ستتعامل مع جميع الخدمات المساعدة، وإطلاق المرحلة 2. المرحلة 1 هي حيث يحدث كل السحر الأسود، وجميع تفاصيل إعداد الحاوية التي نتعامل معها من أجلك حتى لا تضطر إلى الاهتمام بهم.
2. المرحلة 2 : هذا هو المكان الذي من المفترض أن يتم فيه تنفيذ معظم الملفات المقدمة من المستخدم النهائي:
   1. قم بتنفيذ البرامج النصية القديمة لمستخدم Oneshot الموجودة في /etc/cont-init.d .
   2. تشغيل خدمات المستخدم s6-rc المعلنة في /etc/s6-overlay/s6-rc.d ، باتباع التبعيات
   3. انسخ خدمات المستخدم القديمة ( /etc/services.d ) إلى دليل مؤقت واطلب من s6 تشغيلها (والإشراف عليها).
3. المرحلة 3 : هذه هي مرحلة الاغلاق. عندما يُفترض أن تخرج الحاوية، فإنها:
   1. أرسل إشارة TERM إلى جميع الخدمات القديمة طويلة المدى، وانتظر حتى يتم الخروج إذا لزم الأمر.
   2. قم بإسقاط خدمات المستخدم s6-rc بطريقة منظمة.
   3. قم بتشغيل أي نصوص نهائية موجودة في /etc/cont-finish.d .
   4. أرسل لجميع العمليات المتبقية إشارة TERM . لا ينبغي أن يكون هناك أي عمليات متبقية على أي حال.
   5. النوم لفترة سماح صغيرة، للسماح للعمليات الضالة بالخروج بشكل نظيف.
   6. إرسال كافة العمليات إشارة KILL . ثم تخرج الحاوية.

تثبيت

يأتي s6-overlay كمجموعة من كرات القطران التي يمكنك استخراجها على صورتك. كرات القطران التي تحتاجها هي وظيفة الصورة التي تستخدمها؛ سيحتاج معظم الأشخاص إلى الأولين، أما الآخران فهما إضافات يمكنك استخدامها حسب راحتك.

1. s6-overlay-noarch.tar.xz : تحتوي كرة القطران هذه على البرامج النصية التي تنفذ التراكب. نحن نسميها "noarch" لأنها مستقلة عن الهندسة المعمارية: فهي تحتوي فقط على نصوص برمجية وملفات نصية أخرى. كل من يريد تشغيل s6-overlay يحتاج إلى استخراج كرة القطران هذه.
2. s6-overlay-x86_64.tar.xz : استبدل x86_64 ببنية نظامك. تحتوي كرة القطران هذه على جميع الثنائيات الضرورية من النظام البيئي s6، وكلها مرتبطة بشكل ثابت وبعيدًا عن ثنائيات صورتك. ما لم تكن متأكدًا من أن صورتك تأتي بالفعل مع جميع الحزم التي توفر الثنائيات المستخدمة في التراكب، فستحتاج إلى استخراج كرة القطران هذه.
3. s6-overlay-symlinks-noarch.tar.xz : تحتوي كرة القطران هذه على روابط رمزية إلى نصوص s6-overlay بحيث يمكن الوصول إليها عبر /usr/bin . عادةً لا تكون هناك حاجة لذلك، حيث يمكن الوصول إلى جميع البرامج النصية عبر متغير بيئة PATH، ولكن إذا كان لديك نصوص مستخدم قديمة تحتوي على shebangs مثل #!/usr/bin/with-contenv ، فإن تثبيت هذه الارتباطات الرمزية سيجعلها تعمل.
4. s6-overlay-symlinks-arch.tar.xz : تحتوي كرة القطران هذه على روابط رمزية للثنائيات من نظام s6 البيئي الذي توفره كرة القطران الثانية، لتسهيل الوصول إليها عبر /usr/bin . عادةً لا تكون هناك حاجة لذلك، ولكن إذا كان لديك نصوص مستخدم قديمة تحتوي على shebangs مثل #!/usr/bin/execlineb ، فإن تثبيت هذه الارتباطات الرمزية سيجعلها تعمل.
5. syslogd-overlay-noarch.tar.xz : تحتوي كرة القطران هذه على تعريفات لخدمة syslogd . إذا كنت تقوم بتشغيل برامج خفية لا يمكنها تسجيل الدخول إلى stderr للاستفادة من البنية التحتية للتسجيل s6، ولكنك تستخدم الترميز الثابت باستخدام آلية syslog() القديمة، فيمكنك استخراج كرة القطران هذه، وستعمل حاويتك على تشغيل محاكاة خفيفة الوزن لبرنامج syslogd ، لذلك سيتم التقاط سجلات سجل النظام الخاصة بك وتخزينها على القرص.

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

 ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz

تأكد من الحفاظ على أذونات الملف عند الاستخراج (أي استخدام الخيار -p لـ tar .)

الاستخدام

يتم توزيع المشروع كمجموعة من ملفات .tar.xz القياسية، والتي تستخرجها من جذر صورتك. (تحتاج إلى حزمة xz-utils لـ tar لفهم ملفات .tar.xz ؛ وهي متوفرة في كل توزيعة، ولكن ليس دائمًا في صور الحاوية الافتراضية، لذلك قد تحتاج إلى apt install xz-utils أو apk add xz ، أو مكافئ، قبل أن تتمكن من توسيع الأرشيفات.)

بعد ذلك، قم بتعيين ENTRYPOINT الخاص بك على /init .

في الوقت الحالي، نوصي باستخدام توجيه Docker's ADD بدلاً من تشغيل wget أو curl في توجيه RUN - يستطيع Docker التعامل مع عنوان URL https عند استخدام ADD ، في حين أن صورتك الأساسية قد لا تكون قادرة على استخدام https، أو ربما لا تحتوي حتى على wget أو curl مثبتة على الإطلاق.

ومن هناك، لديك خياران:

• إذا كنت تريد خروج الحاوية عند خروج البرنامج: قم بتشغيل البرنامج باعتباره CMD الخاص بالصورة.
• إذا كنت تريد تشغيل الحاوية حتى يُطلب منها الخروج، وأن يتم الإشراف على برنامجك بواسطة s6: فاكتب نصًا برمجيًا للخدمة لبرنامجك.

باستخدام CMD

يعد استخدام CMD طريقة ملائمة للاستفادة من التراكب. يمكن تقديم CMD الخاص بك في وقت الإنشاء في ملف Dockerfile، أو في وقت التشغيل في سطر الأوامر، وفي كلتا الحالتين فلا بأس. سيتم تشغيله كعملية عادية في البيئة التي تم إعدادها بواسطة s6؛ عندما تفشل أو تخرج، ستغلق الحاوية بشكل نظيف وتخرج. يمكنك تشغيل البرامج التفاعلية بهذه الطريقة: فقط CMD هو الذي سيتلقى الأمر التفاعلي الخاص بك، ولن تتأثر عمليات الدعم.

على سبيل المثال:

 FROM busybox
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz
ENTRYPOINT ["/init"]

 docker-host $ docker build -t s6demo .
docker-host $ docker run -ti s6demo /bin/sh
/package/admin/s6-overlay/libexec/preinit: notice: /var/run is not a symlink to /run, fixing it
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
/ # ps
PID   USER     TIME  COMMAND
    1 root      0:00 /package/admin/s6/command/s6-svscan -d4 -- /run/service
   17 root      0:00 {rc.init} /bin/sh -e /run/s6/basedir/scripts/rc.init top /bin/sh
   18 root      0:00 s6-supervise s6-linux-init-shutdownd
   20 root      0:00 /package/admin/s6-linux-init/command/s6-linux-init-shutdownd -c /run/s6/basedir -g 3000 -C -B
   24 root      0:00 s6-supervise s6rc-fdholder
   25 root      0:00 s6-supervise s6rc-oneshot-runner
   31 root      0:00 /package/admin/s6/command/s6-ipcserverd -1 -- /package/admin/s6/command/s6-ipcserver-access -v0 -E -l0 -i data/rules -- /packa
   58 root      0:00 /bin/sh
   66 root      0:00 ps
/ # exit
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
docker-host $

كتابة سكريبت الخدمة

الطريقة الأخرى لاستخدام الحاوية ذات s6-overlay هي جعل خدماتك خاضعة للإشراف. يمكنك الإشراف على أي عدد من الخدمات؛ عادةً ما تكون مجرد خدمات دعم للبرنامج الخفي الرئيسي الذي تقوم بتشغيله كـ CMD، ولكن إذا كان هذا هو ما تريده، فلا شيء يمنعك من الحصول على CMD فارغ وتشغيل البرنامج الخفي الرئيسي كخدمة خاضعة للإشراف أيضًا. في هذه الحالة، سيتم إعادة تشغيل البرنامج الخفي بواسطة s6 عند خروجه؛ لن تتوقف الحاوية إلا عندما تطلب منها ذلك، إما عبر أمر docker stop ، أو من داخل الحاوية باستخدام الأمر /run/s6/basedir/bin/halt .

هناك طريقتان لتقديم خدمة خاضعة للإشراف. الطريقة القديمة، التي لا تزال مدعومة، هي إنشاء دليل خدمة "s6 خالص". قم بإنشاء دليل باسم الخدمة الخاصة بك في /etc/services.d ووضع ملف run قابل للتنفيذ فيه؛ هذا هو الملف الذي ستضع فيه تنفيذ العملية طويلة الأمد. للحصول على تفاصيل حول الإشراف على أدلة الخدمة، وكيف يمكنك تكوين كيفية تعامل s6 مع البرنامج الخفي الخاص بك، يمكنك إلقاء نظرة على وثائق Servicedir. مثال بسيط سيبدو كما يلي:

/etc/services.d/myapp/run :

 #!/command/execlineb -P
nginx -g "daemon off;"

الطريقة الجديدة هي إنشاء دليل تعريف مصدر s6-rc في الدليل /etc/s6-overlay/s6-rc.d ، وإضافة اسم هذا الدليل إلى حزمة user ، أي إنشاء ملف فارغ بنفس الاسم في الدليل /etc/s6-overlay/s6-rc.d/user/contents.d . تم وصف تنسيق دليل تعريف المصدر في هذه الصفحة. لاحظ أنه يمكنك تحديد longruns ، أي البرامج التي سيتم الإشراف عليها بواسطة s6 تمامًا كما هو الحال مع طريقة /etc/services.d ، ولكن يمكنك أيضًا تعريف oneshots ، أي البرامج التي سيتم تشغيلها مرة واحدة ثم الخروج. من المحتمل أن تكون خدمتك الرئيسية طويلة المدى وليست دفعة واحدة : ربما تحتاج إلى برنامج خفي للبقاء فيه.

تتمثل ميزة هذا التنسيق الجديد في أنه يسمح لك بتحديد التبعيات بين الخدمات: إذا كانت B تعتمد على A ، فسيبدأ A أولاً، ثم سيبدأ B عندما يكون A جاهزًا، وعندما يُطلب من الحاوية الخروج، سيتوقف B أولا ثم أ . إذا كانت لديك بنية معقدة حيث تعتمد العمليات المختلفة على بعضها البعض، أو ببساطة حيث يتعين عليك مزج اللقطات الواحدة والمسافات الطويلة بترتيب دقيق، فقد يكون هذا مناسبًا لك.

يمكن إعادة كتابة المثال أعلاه بهذه الطريقة:

/etc/s6-overlay/s6-rc.d/myapp/type :

 longrun

/etc/s6-overlay/s6-rc.d/myapp/run :

 #!/command/execlineb -P
nginx -g "daemon off;"

/etc/s6-overlay/s6-rc.d/user/contents.d/myapp : ملف فارغ. (يؤدي هذا إلى إضافة myapp إلى مجموعة الخدمات التي سيبدأها s6-rc عند تشغيل الحاوية.)

/etc/s6-overlay/s6-rc.d/myapp/dependencies.d/base : ملف فارغ. (هذا يخبر s6-rc ببدء تشغيل myapp فقط عندما تكون جميع الخدمات الأساسية جاهزة: فهو يمنع حالات السباق.)

نحن نشجعك على التبديل إلى التنسيق الجديد، ولكن إذا لم تكن بحاجة إلى فوائده، فيمكنك الالتزام بأدلة الخدمة المنتظمة في /etc/services.d ، فستعمل أيضًا.

ضبط رمز الخروج الخاص بالحاوية على رمز الخروج الخاص بخدمتك الرئيسية

إذا قمت بتشغيل خدمتك الرئيسية كـ CMD، فلن يكون لديك ما تفعله: عند خروج CMD الخاص بك، أو عند تشغيل docker stop ، ستخرج الحاوية بشكل طبيعي بنفس رمز الخروج الخاص بخدمتك. (ومع ذلك، كن على علم أنه في حالة docker stop ، ستحصل خدمتك على SIGTERM، وفي هذه الحالة سيعتمد رمز الخروج بالكامل على كيفية تعامل خدمتك معه - فقد يحجزه ويخرج من 0، ويحجزه ويخرج من شيء آخر ، أو لا تحبسه وتسمح للقذيفة بالخروج من الكود الخاص بها - عادةً 130.)

إذا قمت بتشغيل خدمتك الرئيسية كخدمة خاضعة للإشراف، فستختلف الأمور، وستحتاج إلى إخبار الحاوية بالرمز الذي تريد الخروج به عندما ترسل إليها أمر docker stop . للقيام بذلك، تحتاج إلى كتابة نص finish :

• إذا كانت خدمتك خدمة قديمة في /etc/services.d ، فأنت بحاجة إلى برنامج نصي قابل للتنفيذ /etc/services.d/myapp/finish .
• إذا كانت خدمتك هي s6-rc، فأنت بحاجة إلى ملف /etc/s6-overlay/s6-rc.d/myapp/finish يحتوي على البرنامج النصي الخاص بك (قد يكون الملف قابلاً للتنفيذ أو لا).

سيتم تشغيل البرنامج النصي finish هذا عند خروج الخدمة، وسيأخذ وسيطتين:

• ستكون الوسيطة الأولى هي رمز الخروج لخدمتك، أو 256 إذا توقفت خدمتك بسبب إشارة لم يتم التقاطها.
• الوسيطة الثانية تكون ذات معنى فقط إذا تم إيقاف خدمتك بسبب إشارة لم يتم التقاطها، وتحتوي على عدد الإشارة المذكورة.

في البرنامج النصي finish ، تحتاج إلى كتابة رمز الخروج من الحاوية الذي تريده إلى الملف /run/s6-linux-init-container-results/exitcode - وهذا كل شيء.

على سبيل المثال، يمكن أن يكون نص finish لخدمة myapp أعلاه شيئًا مثل هذا:

 #! /bin/sh

if test " $1 " -eq 256 ; then
  e= $(( 128 + $2 ))
else
  e= " $1 "
fi

echo " $e " > /run/s6-linux-init-container-results/exitcode

عند إرسال أمر docker stop إلى حاويتك، سيتم إيقاف خدمة myapp وسيتم تشغيل هذا البرنامج النصي؛ سيكتب إما رمز الخروج الخاص بـ myapp (إذا التقط myapp إشارة TERM) أو 130 (إذا لم يلتقط myapp إشارة TERM) إلى ملف /run/s6-linux-init-container-results/exitcode الخاص، والذي سوف سيتم قراءتها بواسطة s6-overlay في نهاية إجراء إيقاف تشغيل الحاوية، وستخرج الحاوية الخاصة بك بهذه القيمة.

إصلاح الملكية والأذونات

يصف هذا القسم وظيفة من إصدارات s6-overlay التي تسبق الإصدار v3. لا يزال Fix-attrs مدعومًا في الإصدار 3، ولكن تم إهماله لعدة أسباب: أحدها هو أنه ليس من الجيد بشكل عام تغيير الملكية ديناميكيًا عندما يكون من الممكن القيام بذلك بشكل ثابت. سبب آخر هو أنه لا يعمل مع حاويات المستخدم. بدلاً من إصلاح attrs، نوصيك الآن بالاهتمام بالملكية والأذونات على عمليات تحميل المضيف دون اتصال بالإنترنت، قبل تشغيل الحاوية . يجب أن يتم ذلك في ملف Dockerfile الخاص بك، عندما يكون لديك جميع المعلومات المطلوبة.

ومع ذلك، إليك ما كتبناه للإصدارات السابقة وما زال ساريًا حتى اليوم (ولكن يرجى التوقف عن الاعتماد عليه):

في بعض الأحيان يكون من المثير للاهتمام إصلاح الملكية والأذونات قبل المتابعة لأنه، على سبيل المثال، قمت بتثبيت/تعيين مجلد مضيف داخل الحاوية الخاصة بك. يوفر التراكب الخاص بنا طريقة لمعالجة هذه المشكلة باستخدام الملفات الموجودة في /etc/fix-attrs.d . هذا هو تنسيق النمط متبوعًا بملفات Fix-attrs:

 path recurse account fmode dmode

• path : ملف أو مسار دير.
• recurse : (اضبط على true أو false ) إذا تم العثور على مجلد، قم بالتكرار خلال جميع الملفات والمجلدات التي تحتوي عليه.
• account : الحساب المستهدف. من الممكن أن يتم استخدام uid:gid بشكل افتراضي إذا لم يتم العثور على الحساب. على سبيل المثال، nobody,32768:32768 سيحاول استخدام حساب nobody أولاً، ثم الرجوع إلى uid 32768 بدلاً من ذلك. على سبيل المثال، إذا كان الحساب daemon هو UID=2 و GID=2 ، فهذه هي القيم المحتملة لحقل account :
  • daemon: UID=2 GID=2
  • daemon,3:4: UID=2 GID=2
  • 2:2,3:4: UID=2 GID=2
  • daemon:11111,3:4: UID=2 GID=11111
  • 11111:daemon,3:4: UID=11111 GID=2
  • daemon:daemon,3:4: UID=2 GID=2
  • daemon:unexisting,3:4: UID=2 GID=4
  • unexisting:daemon,3:4: UID=3 GID=2
  • 11111:11111,3:4: UID=11111 GID=11111
• fmode : وضع الملف المستهدف. على سبيل المثال 0644 .
• dmode : وضع الهدف/المجلد. على سبيل المثال 0755 .

هنا لديك بعض الأمثلة العملية:

/etc/fix-attrs.d/01-mysql-data-dir :

 /var/lib/mysql true mysql 0600 0700

/etc/fix-attrs.d/02-mysql-log-dirs :

 /var/log/mysql-error-logs true nobody,32768:32768 0644 2700
/var/log/mysql-general-logs true nobody,32768:32768 0644 2700
/var/log/mysql-slow-query-logs true nobody,32768:32768 0644 2700

تنفيذ مهام التهيئة والإنهاء

وهذه هي الطريقة القديمة للقيام بذلك:

بعد إصلاح السمات (من خلال /etc/fix-attrs.d/ ) وقبل بدء الخدمات المقدمة من المستخدم (من خلال s6-rc أو /etc/services.d ) سيقوم التراكب الخاص بنا بتنفيذ جميع البرامج النصية الموجودة في /etc/cont-init.d ، على سبيل المثال:

/etc/cont-init.d/02-confd-onetime :

 #!/command/execlineb -P

with-contenv
s6-envuidgid nginx
multisubstitute
{
  import -u -D0 UID
  import -u -D0 GID
  import -u CONFD_PREFIX
  define CONFD_CHECK_CMD "/usr/sbin/nginx -t -c {{ .src }}"
}
confd --onetime --prefix="${CONFD_PREFIX}" --tmpl-uid="${UID}" --tmpl-gid="${GID}" --tmpl-src="/etc/nginx/nginx.conf.tmpl" --tmpl-dest="/etc/nginx/nginx.conf" --tmpl-check-cmd="${CONFD_CHECK_CMD}" etcd

ولا تزال هذه الطريقة مدعومة. ومع ذلك، توجد الآن طريقة أكثر عمومية وفعالية للقيام بذلك: كتابة مهام التهيئة والانتهاء في Oneshot كخدمات s6-rc، عن طريق إضافة أدلة تعريف الخدمة في /etc/s6-overlay/s6-rc.d ، مما يجعلها جزءًا من حزمة user (لذلك يتم تشغيلها فعليًا عند تشغيل الحاوية)، وجعلها تعتمد على الحزمة base (لذلك يتم تشغيلها فقط بعد base ).

يمكن العثور على كافة المعلومات حول s6-rc هنا.

عند بدء تشغيل الحاوية، يتم تنفيذ العمليات بالترتيب التالي:

• (مهمل) يتم إجراء إصلاح السمات وفقًا للملفات الموجودة في /etc/fix-attrs.d .
• (قديم) يتم تشغيل البرامج النصية للتهيئة لمرة واحدة في /etc/cont-init.d بشكل تسلسلي.
• يتم بدء الخدمات في حزمة user بواسطة s6-rc، بترتيب محدد حسب التبعيات. يمكن أن تكون الخدمات عبارة عن Oneshots (مهام التهيئة) أو longruns (برامج شيطانية سيتم تشغيلها طوال عمر الحاوية). إذا كانت الخدمات تعتمد على base ، فمن المضمون أن تبدأ عند هذه النقطة وليس قبل ذلك؛ إذا لم يحدث ذلك، فمن المحتمل أن تكون قد بدأت مبكرًا، مما قد يتسبب في حدوث حالات سباق - لذا يوصى بجعلها تعتمد دائمًا على base .
• (قديم) يتم بدء تشغيل الخدمات طويلة المدى في /etc/services.d .
• يتم بدء الخدمات في حزمة user2 ذات التبعية الصحيحة. (معظم الأشخاص لا يحتاجون إلى استخدام هذا؛ إذا لم تكن متأكدًا، فالتزم بحزمة user .)

عندما يتم إيقاف الحاوية، إما لأن المسؤول أرسل أمر إيقاف أو بسبب خروج CMD، يتم تنفيذ العمليات بترتيب عكسي:

• تم إيقاف الخدمات الموجودة في حزمة user2 ذات التبعية الصحيحة.
• (قديم) تم إيقاف الخدمات طويلة المدى في /etc/services.d .
• يتم إيقاف كافة خدمات s6-rc، بترتيب محدد حسب التبعيات. بالنسبة إلى Oneshots، فهذا يعني أنه تم تنفيذ البرنامج النصي down في دليل تعريف المصدر؛ هذه هي الطريقة التي يمكن بها لـ s6-rc أداء مهام الإنهاء.
• (قديم) يتم تشغيل البرامج النصية النهائية للقطة واحدة في /etc/cont-finish.d بالتسلسل.

الهدف من حزمة user2 هو السماح لخدمات المستخدم المعلنة فيها بالبدء بعد الخدمات /etc/services.d ؛ ولكن للقيام بذلك، تحتاج كل خدمة في user2 إلى الإعلان عن تبعيتها legacy-services . بمعنى آخر، لكي تبدأ خدمة foobar متأخرًا، تحتاج إلى:

• قم بتعريفه في /etc/s6-overlay/s6-rc.d/foobar مثل أي خدمة s6-rc أخرى.
• أضف ملف /etc/s6-overlay/s6-rc.d/foobar/dependencies.d/legacy-services
• أضف ملف /etc/s6-overlay/s6-rc.d/user2/contents.d/foobar .

سيضمن ذلك أن foobar سيبدأ بعد كل شيء في /etc/services.d .

كتابة نص نهائي اختياري

افتراضيًا، سيتم إعادة تشغيل الخدمات التي تم إنشاؤها في /etc/services.d تلقائيًا. إذا كان من المفترض أن تقوم إحدى الخدمات بإسقاط الحاوية، فمن المحتمل أن تقوم بتشغيلها كملف CMD بدلاً من ذلك؛ ولكن إذا كنت تفضل تشغيلها كخدمة خاضعة للإشراف، فسوف تحتاج إلى كتابة نص finish ، والذي سيتم تشغيله عندما تكون الخدمة معطلة؛ لإيقاف الحاوية، يجب استدعاء الأمر /run/s6/basedir/bin/halt . فيما يلي مثال لإنهاء البرنامج النصي:

/etc/services.d/myapp/finish :

 #!/command/execlineb -S0

foreground { redirfd -w 1 /run/s6-linux-init-container-results/exitcode echo 0 }
/run/s6/basedir/bin/halt

يكتب السطر الأول من البرنامج النصي 0 إلى الملف /run/s6-linux-init-container-results/exitcode . السطر الثاني يوقف الحاوية. عند إيقاف الحاوية عبر تشغيل الأمر /run/s6/basedir/bin/halt من داخل الحاوية، تتم قراءة /run/s6-linux-init-container-results/exitcode واستخدام محتوياته كرمز خروج لـ أمر docker run الذي أطلق الحاوية. إذا كان الملف غير موجود، أو إذا تم إيقاف الحاوية بسبب docker stop أو لسبب آخر، فإن رمز الخروج يكون افتراضيًا 0.

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

/etc/services.d/myapp/finish :

 #!/command/execlineb -S1
if { eltest ${1} -ne 0 -a ${1} -ne 256 }
/run/s6/basedir/bin/halt

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

التسجيل

يمكن أن يكون لكل خدمة مسجل خاص بها. المسجل عبارة عن خدمة s6 تقرأ تلقائيًا من السجل القياسي لخدمتك، وتسجل البيانات في ملف يتم تدويره تلقائيًا في المكان الذي تريده. لاحظ أن الشياطين عادةً ما تسجل الدخول إلى stderr، وليس stdout، لذا ربما ينبغي عليك بدء تشغيل البرنامج النصي لخدمتك باستخدام exec 2>&1 في shell، أو باستخدام fdmove -c 2 1 في execline، حتى تتمكن من التقاط stderr .

يوفر s6-overlay أداة مساعدة تسمى logutil-service وهي عبارة عن غلاف لبرنامج s6-log . يقوم هذا المساعد بما يلي:

• اقرأ كيف ينبغي لـ s6-log متابعة قراءة البرنامج النصي للتسجيل الموجود في S6_LOGGING_SCRIPT
• إسقاط الامتيازات للمستخدم nobody (الإعداد الافتراضي هو 65534:65534 إذا لم يكن موجودًا)
• تنظيف كافة متغيرات البيئات
• تنفيذ في سجل s6.

سيتم بعد ذلك تشغيل s6-log إلى الأبد، وقراءة البيانات من خدمتك وكتابتها في الدليل الذي حددته لـ logutil-service .

يرجى الملاحظة:

• نظرًا لأنه يتم إسقاط الامتيازات تلقائيًا، ليست هناك حاجة لتبديل المستخدمين باستخدام s6-setuidgid
• يجب عليك التأكد من مجلد السجل إما:
  • موجود، ويمكن الكتابة من قبل المستخدم nobody
  • غير موجود، ولكن المجلد الأصلي قابل للكتابة من قبل nobody مستخدم.

يمكنك إنشاء مجلدات السجل في البرامج النصية cont-init.d ، أو في صورة s6-rc oneshots. فيما يلي مثال على خدمة مسجلة تم تنفيذها بواسطة myapp بالطريقة القديمة:

/etc/cont-init.d/myapp-log-prepare :

 #! /bin/sh -e
mkdir -p /var/log/myapp
chown nobody:nogroup /var/log/myapp
chmod 02755 /var/log/myapp

/etc/services.d/myapp/run :

 #! /bin/sh
exec 2>&1
exec mydaemon-in-the-foreground-and-logging-to-stderr

/etc/services.d/myapp/log/run :

 #! /bin/sh
exec logutil-service /var/log/myapp

وهنا نفس الخدمة، myapp، المطبقة في s6-rc.

/etc/s6-overlay/s6-rc.d/myapp-log-prepare/dependencies.d/base : ملف فارغ

/etc/s6-overlay/s6-rc.d/myapp-log-prepare/type :

 oneshot

/etc/s6-overlay/s6-rc.d/myapp-log-prepare/up :

 if { mkdir -p /var/log/myapp }
if { chown nobody:nogroup /var/log/myapp }
chmod 02755 /var/log/myapp

(انقر هنا للحصول على شرح لبناء الجملة الغريب أو إذا كنت لا تفهم سبب عدم عمل ملف `up` الخاص بك.)

(بداية قسم التفصيل)

لذا، فإن الملفات up down خاصة: فهي ليست نصوص برمجية، ولكنها أسطر أوامر مفردة يتم تفسيرها بواسطة execlineb. لا داعي للقلق بشأن الإكسيلين؛ يجب أن تتذكر فقط أن الملف up يحتوي على سطر أوامر واحد. لذا، إذا كنت بحاجة إلى برنامج نصي يحتوي على عدة تعليمات، فإليك كيفية القيام بذلك:

• اكتب السيناريو الخاص بك باللغة التي تختارها، وفي المكان الذي تختاره
• اجعلها قابلة للتنفيذ
• استدعاء هذا البرنامج النصي في الملف up .

إليك كيفية متابعة كتابة الملف up لـ myapp-log-prepare :

/etc/s6-overlay/s6-rc.d/myapp-log-prepare/up :

 /etc/s6-overlay/scripts/myapp-log-prepare

/etc/s6-overlay/scripts/myapp-log-prepare : (يجب أن يكون قابلاً للتنفيذ)

 #! /bin/sh -e
mkdir -p /var/log/myapp
chown nobody:nogroup /var/log/myapp
chmod 02755 /var/log/myapp

موقع البرنامج النصي الفعلي عشوائي، فهو يحتاج فقط إلى مطابقة ما تكتبه في الملف up .

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

(في نهاية القسم التفصيلي، انقر فوق المثلث أعلاه مرة أخرى لطيه.)

/etc/s6-overlay/s6-rc.d/myapp/dependencies.d/base : ملف فارغ

/etc/s6-overlay/s6-rc.d/myapp-log/dependencies.d/myapp-log-prepare : ملف فارغ

/etc/s6-overlay/s6-rc.d/myapp/type :

 longrun

/etc/s6-overlay/s6-rc.d/myapp/run :

 #! /bin/sh
exec 2>&1
exec mydaemon-in-the-foreground-and-logging-to-stderr

/etc/s6-overlay/s6-rc.d/myapp/producer-for :

 myapp-log

/etc/s6-overlay/s6-rc.d/myapp-log/type :

 longrun

/etc/s6-overlay/s6-rc.d/myapp-log/run :

 #! /bin/sh
exec logutil-service /var/log/myapp

/etc/s6-overlay/s6-rc.d/myapp-log/consumer-for :

 myapp

/etc/s6-overlay/s6-rc.d/myapp-log/pipeline-name :

 myapp-pipeline

/etc/s6-overlay/s6-rc.d/user/contents.d/myapp-pipeline : ملف فارغ

هذا كثير من الملفات! ملخص ما يعنيه كل ذلك هو:

• myapp-log-prepare عبارة عن عملية واحدة لإعداد دليل التسجيل. إنها تبعية لـ myapp-log، لذا سيتم تشغيلها قبل myapp-log.
• myapp هو منتج لـ myapp-log وmyapp-log هو مستهلك لـ myapp، لذا فإن ما يكتبه myapp في stdout الخاص به سينتقل إلى stdin الخاص بـ myapp-log. كلاهما طويل المدى، أي الشياطين التي سيتم الإشراف عليها بواسطة s6.
• myapp | myapp-log يتم إعطاء خط أنابيب myapp | myapp-log اسمًا، myapp-pipeline ، ويتم الإعلان عن هذا الاسم كجزء من حزمة user ، لذلك سيتم تشغيله عندما تبدأ الحاوية.
• يعتمد كل من myapp-log-prepare و myapp-log و myapp على الحزمة base ، مما يعني أنه سيتم تشغيلها فقط عندما يكون النظام جاهزًا بالفعل لبدء تشغيلها.

إنه ينجز بالفعل نفس الأشياء مثل الطريقة /etc/cont-init.d plus /etc/services.d ، ولكنه أكثر نظافة في الأسفل، ويمكنه التعامل مع الرسوم البيانية التبعية الأكثر تعقيدًا، لذا كلما سنحت لك الفرصة، نوصي تتعرف على طريقة s6-rc للإعلان عن خدماتك وأجهزة تسجيل البيانات الخاصة بك. يمكن العثور هنا على البنية الكاملة لدليل تعريف الخدمة، بما في ذلك الإعلان عما إذا كانت الخدمة الخاصة بك طويلة المدى أم دفعة واحدة، والإعلان عن خطوط الأنابيب، وإضافة المهلات الخاصة بالخدمة إذا كنت في حاجة إليها، وما إلى ذلك.

إسقاط الامتيازات

عندما يتعلق الأمر بتنفيذ خدمة، بغض النظر عما إذا كانت خدمة أو أداة تسجيل، فإن الممارسة الجيدة هي إسقاط الامتيازات قبل تنفيذها. يتضمن s6 بالفعل أدوات مساعدة للقيام بهذا النوع من الأشياء بالضبط:

في execline :

 #!/command/execlineb -P
s6-setuidgid daemon
myservice

في sh :

 #! /bin/sh
exec s6-setuidgid daemon myservice

إذا كنت تريد معرفة المزيد عن هذه الأدوات المساعدة، فيرجى إلقاء نظرة على: s6-setuidgid و s6-envuidgid و s6-applyuidgid .

بيئة الحاويات

إذا كنت تريد أن يشتمل البرنامج النصي المخصص لديك على بيئات حاوية متاحة: يمكنك استخدام المساعد with-contenv ، والذي سيدفع كل تلك البيئات إلى بيئة التنفيذ الخاصة بك، على سبيل المثال:

/etc/cont-init.d/01-contenv-example :

 #! /command/with-contenv sh
env

سيقوم هذا البرنامج النصي بإخراج محتويات بيئة الحاوية الخاصة بك.

نظام الملفات الجذر للقراءة فقط

تسمح الإصدارات الحديثة من Docker بتشغيل الحاويات باستخدام نظام ملفات جذر للقراءة فقط. إذا كانت حاويتك في مثل هذه الحالة، فيجب عليك تعيين S6_READ_ONLY_ROOT=1 لإبلاغ s6-overlay بأنها لا يجب أن تحاول الكتابة إلى مناطق معينة - بدلاً من ذلك، ستقوم بإجراء نسخ في tmpfs مثبت على /run .

لاحظ أن s6-overlay يفترض أن:

• /run موجود وقابل للكتابة. إذا لم يكن كذلك، فسوف يحاول تحميل tmpfs هناك.
• /var/run هو رابط رمزي لـ /run للتوافق مع الإصدارات السابقة. إذا لم يكن الأمر كذلك، فإنه سيجعل الأمر كذلك.

بشكل عام، يجب أن توفر إعدادات عامل الإرساء الافتراضية بالفعل tmpfs مناسبًا في /run .

تخصيص سلوك تراكب s6

من الممكن بطريقة ما تعديل سلوك s6-overlay من خلال توفير مجموعة محددة مسبقًا من متغيرات البيئة لسياق التنفيذ:

• PATH (افتراضي = /command:/usr/bin:/bin ): هذا هو PATH الافتراضي الذي ستحتوي عليه جميع الخدمات الموجودة في الحاوية، بما في ذلك CMD. قم بتعيين هذا المتغير إذا كان لديك الكثير من الخدمات التي تعتمد على الثنائيات المخزنة في دليل آخر، على سبيل المثال /usr/sbin . لاحظ أنه سيتم دائمًا إضافة /command و /usr/bin و /bin إلى هذا المسار إذا لم يكونوا موجودين بالفعل في المسار الذي قدمته.
• S6_KEEP_ENV (افتراضي = 0): إذا تم تعيينه، فلن تتم إعادة تعيين البيئة وسترى شجرة الإشراف بأكملها المجموعة الأصلية من env vars. إنه يتحول with-contenv إلى nop.
• S6_LOGGING (الافتراضي = 0):
  • 0 : إخراج كل شيء إلى stdout/stderr.
  • 1 : يستخدم مسجل catch-all داخلي ويستمر في كل شيء عليه، وهو موجود في /var/log/s6-uncaught-logs . أي شيء يتم تشغيله كملف CMD لا يزال يتم إخراجه إلى stdout/stderr.
  • 2 : يستخدم مسجل catch-all الداخلي ويستمر في كل شيء عليه، بما في ذلك مخرجات CMD . لم يتم كتابة أي شيء على الإطلاق إلى stdout/stderr.
• S6_CATCHALL_USER (افتراضي = root): إذا تم تعيينه، وإذا كان S6_LOGGING يساوي 1 أو 2، فسيتم تشغيل مسجل استقبال الرسائل الخاطئة باعتباره هذا المستخدم، والذي يجب تعريفه في /etc/passwd الخاص بصورتك. كل جزء من فصل الامتيازات يساعد قليلاً في الأمان.
• S6_BEHAVIOUR_IF_STAGE2_FAILS (افتراضي = 0): يحدد ما يجب أن تفعله الحاوية في حالة فشل أحد البرامج النصية للخدمة. وهذا يشمل:
  • إذا فشل أي شيء في fix-attrs
  • في حالة فشل أي نمط قديم /etc/cont-init.d أو نمط جديد s6-rc oneshot
  • إذا تم وضع علامة على أي نمط قديم /etc/services.d أو s6-rc longrun ذو النمط الجديد على أنه يتوقع إشعار الاستعداد، وفشل في أن يصبح جاهزًا في الوقت المخصص (راجع S6_CMD_WAIT_FOR_SERVICES_MAXTIME أدناه). القيم الصالحة لـ S6_BEHAVIOUR_IF_STAGE2_FAILS هي التالية:
  • 0 : تابع بصمت حتى لو فشل البرنامج النصي.
  • 1 : تابع ولكن حذر مع ظهور رسالة خطأ مزعجة.
  • 2 : أوقف الحاوية.
• S6_KILL_FINISH_MAXTIME (افتراضي = 5000): كم من الوقت (بالملي ثانية) يجب أن ينتظر النظام، في وقت إيقاف التشغيل، حتى ينتهي البرنامج النصي في /etc/cont-finish.d بشكل طبيعي. بعد هذه المدة، سيتم إرسال البرنامج النصي SIGKILL. ضع في اعتبارك أن البرامج النصية الموجودة في /etc/cont.finish.d يتم تشغيلها بشكل تسلسلي، ومن المحتمل أن ينتظر تسلسل إيقاف التشغيل S6_KILL_FINISH_MAXTIME مللي ثانية لكل برنامج نصي.
• S6_SERVICES_READYTIME (افتراضي = 50): مع الخدمات المعلنة في /etc/services.d ، توجد حالة سباق لا يمكن تجنبها بين لحظة بدء الخدمات واللحظة التي يمكن فيها اختبار جاهزيتها. ولتجنب هذا السباق، ننام قليلاً من الوقت، افتراضياً 50 مللي ثانية، قبل اختبار الاستعداد. إذا كان جهازك بطيئًا أو مشغولًا جدًا، فقد تظهر لك أخطاء تبدو مثل s6-svwait: fatal: unable to s6_svstatus_read: No such file or directory . في هذه الحالة، يجب عليك زيادة وقت النوم، من خلال الإعلان عنه (بالملي ثانية) في المتغير S6_SERVICES_READYTIME . لاحظ أن الأمر يتعلق فقط /etc/services.d ؛ s6-rc محصن ضد حالة السباق.
• S6_SERVICES_GRACETIME (افتراضي = 3000): المدة (بالملي ثانية) التي يجب أن ينتظرها s6 ، في وقت إيقاف التشغيل، حتى تموت الخدمات المُعلن عنها في /etc/services.d قبل متابعة بقية عملية إيقاف التشغيل.
• S6_KILL_GRACETIME (افتراضي = 3000): كم من الوقت (بالمللي ثانية) يجب أن ينتظر s6 ، في نهاية إجراء إيقاف التشغيل عندما تتلقى جميع العمليات إشارة TERM، حتى تموت قبل إرسال إشارة KILL للتأكد من أنها ميتة .
• S6_LOGGING_SCRIPT (افتراضي = "n20 s1000000 T"): تحدد هذه البيئة ما سيتم تسجيله وكيف، افتراضيًا، سيسبق كل سطر مع ISO8601، ويتم تدويره عندما يصل ملف التسجيل الحالي إلى 1 ميجابايت ويتم أرشفته، على الأكثر، بـ 20 ملفًا.
• S6_CMD_ARG0 (افتراضي = غير محدد): سيتم إضافة قيمة env var هذه إلى أي وسيطات CMD تم تمريرها بواسطة عامل الإرساء. استخدمه إذا كنت تقوم بترحيل صورة موجودة إلى s6-overlay وتريد أن تجعلها بديلاً منسدلًا: سيساعدك تعيين هذا المتغير على قيمة ENTRYPOINT المستخدمة مسبقًا في عملية النقل.
• S6_CMD_USE_TERMINAL (افتراضي = 0): قم بتعيين هذه القيمة على 1 إذا كان لديك CMD يحتاج إلى محطة طرفية لمخرجاته (عادةً عند تشغيل الحاوية الخاصة بك باستخدام docker run -it )، وقمت بتعيين S6_LOGGING على قيمة غير صفرية. سيؤدي هذا الإعداد إلى إخراج CMD فعليًا إلى جهازك الطرفي؛ العيب هو أنه لن يتم تسجيل مخرجاته. افتراضيًا (عندما يكون هذا المتغير 0 أو لم يتم تعيينه)، يتم تسجيل stdout وstderr الخاصين بـ CMD عندما تكون S6_LOGGING غير صفرية، مما يعني أنهما ينتقلان إلى أنبوب حتى لو كنت تقوم بتشغيله في محطة تفاعلية.
• S6_FIX_ATTRS_HIDDEN (افتراضي = 0): يتحكم في كيفية معالجة البرامج النصية fix-attrs.d للملفات والأدلة.
  • 0 : يتم استبعاد الملفات والأدلة المخفية.
  • 1 : تتم معالجة كافة الملفات والدلائل.
• S6_CMD_WAIT_FOR_SERVICES (افتراضي = 0): بشكل افتراضي، عند بدء تشغيل الحاوية، سيتم بدء الخدمات في /etc/services.d وسيستمر التنفيذ لبدء حزمة user2 وCMD، إذا تم تحديد أي منها. إذا كان S6_CMD_WAIT_FOR_SERVICES غير صفري ، فإن تسلسل بدء الحاوية سوف تنتظر حتى تكون الخدمات في /etc/services.d جاهزة قبل المتابعة مع بقية التسلسل. لاحظ أن هذا أمر مهم فقط إذا كانت الخدمات في /etc/services.d إخطار استعدادها لـ S6.
• S6_CMD_WAIT_FOR_SERVICES_MAXTIME (افتراضي = 0 ، أي لانهائي): الحد الأقصى للوقت (بالمللي ثانية) يمكن أن تستغرق الخدمات لتقديمها قبل الإجراءات إلى تنفيذ CMD. اضبط هذا المتغير على قيمة موجبة إذا كان لديك خدمات يمكن أن تمنع إلى أجل غير مسمى وتفضل أن تفشل الحاوية إذا لم يكن كل شيء بعد وقت معين. لاحظ أن هذه القيمة تتضمن أيضًا الوقت المناسب لإعداد تهيئة الحاوية القديمة ( /etc/cont-init.d ) والخدمات ( /etc/services.d ) ، لذا ضع ذلك في الاعتبار عند حساب قيمة مناسبة. في إصدارات S6-Overlay تصل إلى 3.1.6.2 ، كان التخلف عن السداد 5000 (خمس ثوان) ، لكنه تسبب في حالات فشل في الحاويات غير مرغوب فيها أكثر من حل المشكل ضروري لجميع الخدمات التي سيتم طرحها.
• S6_READ_ONLY_ROOT (افتراضي = 0): عند التشغيل في حاوية يكون نظام ملفات الجذر قارئًا فقط ، قم بتعيين هذا ENV إلى 1 لإبلاغ Init Sgate 2 بأنه يجب أن ينسخ نصوص التهيئة التي يقدمها المستخدم من /etc إلى /run/s6/etc قبل ذلك يحاول تغيير الأذونات ، وما إلى ذلك ، انظر نظام ملفات الجذر للقراءة فقط لمزيد من المعلومات.
• S6_SYNC_DISKS (افتراضي = 0): اضبط هذا ENV على 1 لإبلاغ المرحلة 3 في البداية بأنه يجب أن يحاول مزامنة أنظمة الملفات قبل إيقاف الحاوية. ملاحظة: من المحتمل أن يؤدي ذلك إلى مزامنة جميع أنظمة الملفات على المضيف.
• S6_STAGE2_HOOK (افتراضي = لا شيء): إذا كان هذا المتغير موجودًا ، فسيتم تفسير محتوياته على أنها مقتطفات قذيفة سيتم تشغيلها في المرحلة المبكرة 2 ، قبل بدء الخدمات. يمكن استخدام ذلك ، على سبيل المثال ، لتصحيح قاعدة بيانات الخدمة ديناميكيًا في وقت التشغيل مباشرة قبل تجميعها وتشغيلها. يمكن أن تمنع القيمة الخاطئة أن تمنع الحاوية الخاصة بك من التشغيل أو تعرض أمانك للخطر ، لذا استخدم هذا فقط إذا كنت تعرف بالضبط ما تفعله. عندما تكون في شك ، اترك هذا المتغير غير محدد.
• S6_VERBOSITY (افتراضي = 2): يتحكم في فعل S6-RC ، وأدوات أخرى محتملة ، في وقت بدء الحاوية ووقت التوقف. الافتراضي ، 2 ، عادة ما يكون مطوّلًا: سيدرج عمليات بدء الخدمة وإيقاف الخدمة. يمكنك جعل الحاوية أكثر هدوءًا عن طريق تقليل هذا الرقم: 1 سوف يطبع التحذيرات والأخطاء فقط ، وسيقوم 0 بطباعة الأخطاء فقط. يمكنك أيضًا جعل الحاوية أكثر مطوّلة ، أي معلومات تتبع الطباعة ومعلومات التصحيح ، من خلال زيادة هذا الرقم حتى 5 ، ولكن سيصبح الإخراج سريعًا للغاية ، ويجب ألا يحتاج معظم الناس إلى ذلك.
• S6_CMD_RECEIVE_SIGNALS (افتراضي = 0): يقرر ما إذا كان ينبغي إرسال الإشارات المرسلة إلى الحاوية إلى حاوية الحاوية 1 أو إلى CMD. بشكل افتراضي ، عند أداء docker stop على سبيل المثال ، سيتم إرسال إشارة مصطلح إلى الحاوية PID 1 ، والتي ستؤدي إلى تسلسل إيقاف الحاوية الكامل - ولكن إذا كان CMD موجودًا ، فسيكون من بين آخر العمليات التي يتم قتلها ، فقط عندما ينخفض ​​كل شيء آخر ، تكون الحاوية على وشك الخروج. إذا كان هذا المتغير 1 أو أكثر ، يتم تحويل الإشارات من PID 1 إلى CMD ، مما يعني أن docker stop سترسل sigterm إلى CMD بدلاً من ذلك ، وستؤدي الحاوية إلى تشغيل إجراء إيقاف التشغيل الخاص بها فقط عند وفاة CMD. لاحظ أنه يتم تحويل SIGTERM ، SIGQUIT ، SIGINT ، SIGUSR1 ، SIGUSR2 ، SIGPWR و SIGWINCH ؛ يتم تجاهل الإشارات الأخرى إما أو لا يمكن تحويلها بالضرورة من قبل PID 1. "ر تعيين هذا المتغير. ولكن يجب أن يكون ذلك جيدًا لأنه في هذه الحالة لديك بالفعل طرق تفاعلية لإيقاف CMD.

سجل النظام

إذا كان البرامج التي تعمل في الحاوية الخاصة بك تتطلب syslog ، فقم باستخراج syslogd-overlay-noarch.tar.xz tarball: سيعطيك ذلك مضاهاة syslogd صغيرة. سيتم العثور على سجلات تحت مختلف الدلائل الفرعية من /var/log/syslogd ، على سبيل المثال ، سيتم العثور على رسائل في /var/log/syslogd/messages/ directory ، وأحدث السجلات المتوفرة في /var/log/syslogd/messages/current