لماذا تُنظم المركبة مع دوكر لنشرات الإنتاج

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

  • ضمان بدء العمل من خلال توجيهات التبعية (مثلاً، بعد شبكة الهدف، بعد الخدمة)
  • Unified logging via , making debugging straightforward
  • مراقبة الموارد على أساس جيد (وحدة البرامج القطرية، الذاكرة، I/O) باستخدام توجيهات الوحدات النظامية
  • إعادة التشغيل الآلي للفشل مع التأخيرات الميسرة والحدود القصوى للانفجار
  • دعم تنشيط التواريخ والبدء في الوقت المحدد

وبإغلاق كل حاوية من حاويات دوكر في ملف خدمة نظامي، تحصل أفرقة العمليات على وصلة وصل ثابتة لبدء ووقف ورصد الحاويات، مما يقلل الاعتماد على النصوص المخصصة والتدخل اليدوي.

إنشاء دائرة نظامية لحاويات (دوكر) الوحيدة

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

الخطوة 1: كتابة ملف وحدة الخدمات

(أ) إنشاء ملف اسمه [(FLT:2].

[Unit]
Description=My Application Container
After=network-online.target docker.service
Wants=network-online.target
Requires=docker.service

[Service]
Restart=always
RestartSec=10
StartLimitBurst=3
ExecStartPre=-/usr/bin/docker kill myapp
ExecStartPre=-/usr/bin/docker rm myapp
ExecStart=/usr/bin/docker run --rm --name myapp \
 -e DB_HOST=10.0.1.50 \
 -e DB_PORT=5432 \
 -v /data/myapp:/app/data \
 -p 8080:8080 \
 myregistry/myapp:latest
ExecStop=/usr/bin/docker stop -t 10 myapp
ExecStopPost=-/usr/bin/docker rm myapp

[Install]
WantedBy=multi-user.target

تفسير التوجيهات الرئيسية: ]

  • ] - يَكفلُ دوكر دايمون يَرْكضُ قبل بدء الحاوية.
  • ] ] - إذا توقف دوكر، تتوقف هذه الخدمة أيضا.
  • ] ] - ينظف أي حاوية بقايا من إحدى الطلقات السابقة (] prefix يعني الفشل هنا غير مميت.
  • ] ] - - - [لإزالة الحاوية تلقائياً عندما تتوقف.
  • ] ] - توقف الحاوية بشكل جيد مع انقطاع زمني (10 ثوان).
  • ] ] - يعيد شحن الحاوية بغض النظر عن رمز الخروج.
  • ] ] - الانتظار 10 ثوان قبل إعادة التشغيل.
  • ] ] - حدود إعادة توجيه ثلاث محاولات على فترات زمنية (العجز 10 ثوان) لتجنب حلقات استئناف العمل.

الخطوة 2: تمكين الخدمات وابدأها

sudo systemctl daemon-reload
sudo systemctl enable myapp.service
sudo systemctl start myapp.service

The tells systemd to re-read service files. creates the symlink so the service starts on boot.

إدارة الدائرة مع قيادة النظام الموحد

عندما تركض الخدمة، تتحكم بها تماما مثل أي خدمة أخرى للنظام

  • Start:]
  • Stop:]
  • Restart:]
  • Status:]
  • Logs:] (أقلمة حية)

أنماط التجمع المتقدمة

وكثيرا ما يتطلب نشر الإنتاج أكثر من مجرد .

اجتياز البيئة

ولا يوصى باستخدام الأسرار أو التشكيلات ذات الدوافع الصلبة في ملف الخدمات، بل يستخدم ملفاً بيئياً منفصلاً:

[Service]
EnvironmentFile=-/etc/myapp/env.conf
ExecStart=/usr/bin/docker run --rm --name myapp \
 --env-file /etc/myapp/env.conf \
 myregistry/myapp:latest

The prefix before the path means the service will start even if the file does not exist (useful during initial setup).

الربط الشبكي والموانئ

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

ExecStart=/usr/bin/docker run --rm --name web \
 --network=my-net \
 -p 443:443 \
 -v /etc/ssl/certs:/etc/ssl/certs:ro \
 myregistry/web:latest

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

ExecStartPre=/usr/bin/docker network create my-net

الأقاليم بين الحاويات

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

[Unit]
Description=Web App Container
After=network-online.target docker.service mydb.service
BindsTo=mydb.service

ties the web app’s life cycle to the database container – if the database stops, the web app is also stopped.

الفحص الصحي والارتداد

ويمكن إدماج عمليات الفحص الصحي في دوكر مع نظام لمنع توافر الخدمات قبل الأوان.

ExecStartPost=/usr/local/bin/wait-for-health.sh http://localhost:8080/health 30

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

حدود الموارد عن طريق النظام

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

[Service]
MemoryMax=512M
CPUQuota=50%

هذه الظروف تخلق حداً صعباً يُنفّذ النظام بشكل مستقل عن (دكر)

إدارة الحاويات المتعددة: نظام ضد شركة دوكر

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

[Unit]
Description=My Application Stack
After=network-online.target docker.service
Requires=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/myapp
ExecStart=/usr/local/bin/docker-compose up -d
ExecStop=/usr/local/bin/docker-compose down

[Install]
WantedBy=multi-user.target

وهذا النهج يعطيك بساطة مجموعة تحديد الخدمات إلى جانب إدارة دورة الحياة في النظام، ملاحظة أن ] يستخدم لأن ] يخرج فورا. يبقي الوحدة في حالة " نشطة " إلى أن يُدعى .

أيّ طريقة يجب أن تختارها؟

  • Individual systemd services] - best for legacy applications, services with strict startup ordering, or when you need per-container resource limits.
  • Docker Compose with systemd] — ideal for microservices stacks where dependencies are handled internally by Compose, and you want a single unit to manage the whole group.

المسائل المشتركة

حتى مع الضبط الدقيق، قد تواجهون مشاكل، و(بدون) يترددون على العيوب وحلولهم

الخدمة المتخلفة عن " الاتصال بين الدوكر دايمون "

وهذا يعني عادة أن الخدمة تبدأ قبل أن تكون مجموعة دولكر جاهزة، وضمان أن تضم وحدتك و.

مقطورة في لوب

If the container exits immediately, systemd will keep restarting it according to and . check container logs with . Increase (e.g., 30 seconds) and set to prevent a busy cycle.

الخدمة لا تتوقف بشكل نظيف

ويمكن أن يترك الحاوية قيد التشغيل، ويصدق على أن ] تستخدم الاسم الصحيح للحاويات بطريقة غير صحيحة.

البيئة غير المأهولة

إذا استخدمتم ، تأكدوا من وجود الملف ويمكن قراءته بالجذور.

الاعتبارات الأمنية

إدارة حاويات دوكر من خلال نظام يُثير بضعة نقاط أمنية:

  • (د) إدارة الخدمة النظامية دائماً كمستخدم غير مستعمل للجرائم إن أمكن (استخدام و]) التوجيهات، ولكن ضمان وصول المستخدم إلى جوربة الدوكر أو تشغيله بطريقة لا تترسخ.
  • تجنب استخدام في الوحدات النظامية ما لم يكن ذلك ضرورياً على الإطلاق.
  • Use read-only bind mounts (]) whenever the container does not need to write to the host.
  • Leverage systemd’s and to harden the unit against escapes.
[Service]
ProtectSystem=strict
ReadWritePaths=/var/log/myapp
PrivateTmp=true
User=myappuser

الموارد الخارجية

وللاطلاع على المزيد من القراءة، يرجى الرجوع إلى هذه المراجع الرسمية:

خاتمة

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

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