قد يعمل مشروع على حاسوب المطوّر ثم يفشل على الخادم بسبب اختلاف إصدارات Node.js أو المكتبات أو إعدادات النظام. تساعد الحاويات على وصف بيئة تشغيل قابلة للتكرار، لكنها لا تصلح تلقائيًا كل مشكلة نشر ولا تجعل الصورة آمنة بمجرد بنائها.
ما ستخرج به من المقال
- التمييز بين image وcontainer.
- بناء صور صغيرة ومحددة الإصدارات.
- إدارة الإعدادات والأسرار خارج الصورة.
Image وContainer وDockerfile
الصورة Image قالب يضم التطبيق وملفات التشغيل؛ أما الحاوية فهي مثيل يعمل من الصورة. يصف Dockerfile خطوات البناء، وينتج البناء طبقات قابلة لإعادة الاستخدام. تعديل ملف داخل حاوية لا يعني بالضرورة تعديل الصورة الأصلية. اجعل Dockerfile بسيطًا ومفهومًا، وافصل أدوات البناء عن بيئة التشغيل عندما يفيد ذلك، ولا تضف أدوات تطوير وملفات مؤقتة إلى صورة الإنتاج دون حاجة.
ابنِ بصورة قابلة للتكرار
ابدأ بصورة أساس موثوقة وإصدار محدد يناسب المشروع، وثبّت الاعتمادات وفق lockfile باستخدام أمر مثل npm ci. أضف .dockerignore لمنع إرسال node_modules وملفات Git والأسرار وملفات البناء غير المطلوبة إلى سياق البناء. استخدم multi-stage builds إذا كنت تحتاج أدوات بناء لا تحتاجها الصورة النهائية، وشغّل التطبيق بمستخدم غير root متى كان ممكنًا.
الأسرار والشبكة والبيانات
لا تضمّن كلمات المرور أو مفاتيح API في Dockerfile أو الصورة. مرّر الإعدادات عبر متغيرات بيئة أو آلية أسرار مناسبة، وضع بيانات الحالة في تخزين يناسب العمر المتوقع للحاوية. راجع المنافذ المنشورة والمجلدات المشتركة وصلاحيات Linux وإمكانية الوصول إلى Docker daemon؛ الحاويات ليست حدًا سحريًا للأمن، ولا ينبغي نشر قاعدة البيانات على الإنترنت المفتوح دون ضوابط شبكية مناسبة.
اختبر دورة التشغيل والتحديث
اختبر بدء الحاوية وإيقافها والسجلات وفحوص الصحة والاتصال بالخدمات الأخرى. ترتيب بدء الحاويات لا يضمن وحده جاهزية قاعدة البيانات؛ استخدم health checks وإعادة المحاولة المحدودة. ضع tag مرتبطًا بإصدار أو commit معروف، ولا تعتمد على latest وحده لمعرفة ما يعمل في الإنتاج. وثّق طريقة البناء والتحديث والتراجع، واحتفظ بخطة نسخ احتياطية واسترجاع للبيانات التي لا يجوز فقدها.
Dockerfile مبسط لتطبيق Node.js
FROM node:22-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
FROM node:22-alpine AS runtime
ENV NODE_ENV=production
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]
افهم ما الذي يدخل إلى الصورة
يقرأ Dockerfile بوصفه وصفًا لبناء صورة، وليس قائمة أوامر تُنفّذ على جهاز المطوّر فقط. كل طبقة تمثل نتيجة خطوة بناء، ويمكن أن تؤثر طريقة ترتيب COPY ونسخ ملفات الاعتماديات في إعادة استخدام الـ cache. إذا نسخت كل ملفات المشروع قبل تثبيت الحزم، فقد يؤدي تعديل سطر في ملف عادي إلى إعادة تثبيت كل الحزم بلا داعٍ.
فصل مرحلة تثبيت الاعتماديات عن مرحلة التشغيل يساعد على بناء صورة أصغر، لكن الصورة النهائية يجب أن تحتوي كل ما يحتاجه التطبيق وقت التشغيل فقط. تأكد من أن مسارات النسخ وملف القفل صحيحان، وأن الأمر النهائي يبدأ الخادم بصورة متوقعة، وأن عملية التطبيق لا تحتاج ملفات التطوير التي حذفتها.
دراسة حالة مفصلة: من العرض إلى السبب الجذري
الحالة العملية هنا هي: تطبيق يعمل على جهاز المطور لكنه يفشل داخل الحاوية بسبب اعتماد أو متغير بيئة غير موجود في صورة التشغيل. لا يكفي أن نصلح العَرَض الظاهر؛ ينبغي رسم مسار البيانات أو الطلب من بدايته حتى النتيجة، ومعرفة أين نشأ الاختلاف. ابدأ بتسجيل ما حدث، وما المتوقع أن يحدث، والخطوة التي يمكن إثباتها بالقياس أو السجل أو الاختبار. بعد ذلك غيّر عاملًا واحدًا واضحًا، ثم أعد السيناريو نفسه للتحقق من أن السبب الجذري عولج. إذا تغيرت عدة مكونات دفعة واحدة، فسيصعب معرفة أيها أحدث الفرق.
اربط نتيجة الحالة بمبدأ المقال: Image وContainer وDockerfile وابنِ بصورة قابلة للتكرار. هذان المفهومان يحددان ما الذي يجب فحصه أولًا وما الذي يمكن تأجيله. سجّل أيضًا الحالات التي لم تختبرها، حتى لا يتحول نجاح سيناريو واحد إلى ادعاء بأن النظام كله خالٍ من المشكلة.
التعامل مع البيانات والأسرار
الحاوية ليست مكانًا مناسبًا لتخزين بيانات دائمة داخل طبقتها القابلة للاستبدال؛ عند حذف الحاوية قد تضيع التغييرات المحلية. استخدم volumes أو خدمة تخزين مناسبة للبيانات التي يجب أن تعيش بعد إعادة التشغيل. وبالمثل، لا تضع كلمات المرور ومفاتيح API داخل Dockerfile أو صورة منشورة، لأن الطبقات قد تحتفظ بها حتى لو حذفتها لاحقًا من آخر طبقة.
مرّر الإعدادات والأسرار وقت التشغيل عبر آلية إدارة أسرار مناسبة للبيئة، وقلّل الصلاحيات داخل الحاوية. استخدام مستخدم غير root، وصورة أساسية موثوقة ومحددة الإصدار، وتحديث الصور دوريًا يقلل مساحة الهجوم. هذه التدابير لا تغني عن حماية الخادم والمضيف وشبكة التشغيل.
من المثال إلى التنفيذ في مشروع حقيقي
ابدأ من المثال البرمجي المعروض في المقال: «Dockerfile مبسط لتطبيق Node.js». لا تنقله حرفيًا إلى الإنتاج قبل أن تحدد مدخلاته ومخرجاته وافتراضاته. اسأل ما الذي يحدث عند غياب قيمة، أو وصول بيانات غير متوقعة، أو تكرار الطلب، أو تأخر الاعتماد الخارجي. بعد ذلك نفّذ نسخة صغيرة داخل فرع مستقل وأضف اختبارًا للحالة الأساسية وآخر لحالة فشل.
استخدم هذه الخطوات كبداية: حدّد ملفات التشغيل والاعتمادات المطلوبة. ثم اكتب Dockerfile و.dockerignore. ثم ابنِ صورة بإصدار معروف وافحص حجمها.. اجعل كل خطوة قابلة للمراجعة، ولا تجمع إعدادات المشروع الحقيقية والأسرار داخل مثال تعليمي. إذا اختلفت بيئتك عن المثال، وثّق الاختلاف وعدّل التنفيذ بناءً على التوثيق الرسمي بدل نسخ الحل دون فهم.
تشخيص أعطال التشغيل الشائعة
إذا خرجت الحاوية مباشرة بعد البدء، افحص سجل العملية الأولى ورمز الخروج؛ Docker لا يبقي الحاوية حية لمجرد أن الصورة بُنيت بنجاح. إذا تعذر الاتصال بقاعدة البيانات، تحقق من اسم الخدمة والشبكة والمنفذ وبيانات الاتصال، ولا تفترض أن localhost داخل الحاوية يعني جهاز المضيف.
إذا كان التطبيق لا يجد ملفًا، قارن مسار WORKDIR بما نُسخ إلى الصورة، وافحص ما إذا كانت ملفات البناء أو الاعتماديات الضرورية حُذفت في المرحلة النهائية. أعد بناء الصورة مع إخراج تفاصيل كافية في التطوير، ثم قلّل السجلات الحساسة في الإنتاج. افحص الحجم ومحتويات الصورة بدل إضافة أدوات عشوائية إليها.
أسلوب تشخيص منهجي عند الفشل
عندما لا يعمل الحل، لا تبدأ بإضافة شرط آخر قبل تحديد دليل الفشل. دوّن المدخل، والنتيجة المتوقعة، والنتيجة الفعلية، والرسالة أو القياس الذي يدعم الاستنتاج. من الأخطاء المتكررة في هذا الموضوع: نسخ .env أو .git داخل الصورة.. تعامل مع هذه النقطة كفرضية للفحص، لا كتشخيص مسبق؛ فقد يكون سبب المشكلة في طبقة مجاورة أو في افتراض غير صحيح بالاختبار.
قسّم النظام إلى حدود واضحة: مدخلات، ومعالجة، واعتماد خارجي، ونتيجة. اختبر كل حد على حدة قدر الإمكان، ثم نفّذ سيناريو متكاملًا. إذا أصلحت المشكلة، أضف اختبارًا يمنع رجوعها أو ملاحظة تشغيلية تساعد على كشفها مبكرًا. الهدف أن يصبح التشخيص قابلًا للتكرار من عضو آخر بالفريق، لا أن يظل مرتبطًا بذاكرة الشخص الذي اكتشف العطل.
مقاييس الصحة والتحديث
استخدام حاويات لا يعني أن الخدمة أصبحت عالية التوافر تلقائيًا. حدد فحصًا مناسبًا للحيوية والجاهزية، وافصل بين عملية بدأت وبين تطبيق قادر فعليًا على تلقي الطلبات. يحتاج التطبيق وقتًا لإغلاق الاتصالات الجارية عند التوقف، لذلك عالج إشارات الإنهاء والإيقاف المنظم عند الإمكان.
ثبّت الإصدارات والصور قدر الإمكان، وأعد بناء الصور بصورة دورية للحصول على تحديثات الأمان. لا تعتمد على وسم متحرك مثل latest لإعادة بناء متوقعة. احفظ سجلًا يوضح نسخة الصورة المنشورة، وخطة تراجع إلى إصدار معروف، واختبر الترقية على بيئة مماثلة للإنتاج قبل تغيير خدمة يستخدمها العملاء.
اعتبارات متقدمة قبل اعتماد الحل
في المشروع الحقيقي، لا يُقيّم الحل على نجاح الحالة السعيدة فقط. راجع السلوك عند الحمل، وحالات الفشل، والتغييرات المستقبلية، والحدود الأمنية ذات الصلة. من المهم هنا أن افصل أسرار التشغيل عن الصورة، واستخدم مستخدمًا محدود الصلاحية، وتأكد من بقاء البيانات خارج دورة حياة الحاوية. لا تُعامل هذه النقاط كملحق لاحق؛ فقرار التصميم قد يصعب تغييره عندما تتراكم البيانات أو يعتمد عليه عملاء متعددون.
حدّد مقاييس أو اختبارات قبول قبل الدمج، ودوّن حدود الحل بوضوح. قد يكون الحل مناسبًا لموقع صغير لكنه يحتاج طابورًا أو cache أو بنية أكثر صرامة عند نمو الاستخدام. لا تضف تعقيدًا مسبقًا بلا دليل، لكن لا تتجاهل علامة واضحة على أن المتطلبات تتجاوز النسخة البسيطة. القرار الجيد يوازن البساطة الحالية مع كلفة التغيير المتوقعة ويحافظ على وضوح النظام للفريق.
معايير جاهزية صورة Docker
قبل اعتماد الصورة، تحقق من أن التطبيق يعمل بمستخدم محدود الصلاحية، وأنه لا يحمل ملفات اختبار أو بيانات تطوير أو أسرارًا، وأن حجمها مقبول، وأن الإعدادات تأتي من البيئة. جرّب بدء الحاوية وإيقافها وإعادة إنشائها، وتأكد من بقاء البيانات المطلوبة فقط في مكان دائم.
قارن نتيجة البناء على جهازين أو ضمن CI لضمان أن الاعتماديات تثبت من ملف القفل وأن الخطوات لا تتطلب حالة مخفية من جهاز المطوّر. الصورة الجيدة ليست أصغر صورة ممكنة فحسب؛ بل صورة يمكن إعادة بنائها وتحديثها وتشخيصها وتشغيلها بأمان.
تطبيق عملي ومعايير قبول
جرّب هذا التمرين على مشروع تجريبي أو فرع منفصل: ابنِ الصورة وشغّلها وأوقفها وأعد إنشائها، ثم تحقق من الملفات والأسرار والبيانات الدائمة. اكتب النتيجة التي تتوقعها قبل التنفيذ، وسجّل ما حدث بالفعل، ثم أصلح الفرق إن ظهر. جرّب كذلك حالة حدودية أو فشلًا مقصودًا بصورة آمنة. لا تستخدم بيانات حقيقية أو نظامًا إنتاجيًا لإحداث فشل تجريبي.
اعتبر المهمة مكتملة عندما تكون خطوات إعادة التجربة موثقة، والاختبار يثبت السلوك الأساسي وحالة الفشل، ولا توجد أسرار أو معلومات حساسة في السجل، ويستطيع مطور آخر فهم سبب الحل. إذا لم يتحقق هذا، فالمطلوب ليس إضافة مزيد من الكود مباشرة؛ أعد صياغة المشكلة ووضح الافتراض الذي لم يكن صحيحًا. هذه الطريقة تجعل المقال نقطة انطلاق لممارسة تقنية، لا مجرد قراءة نظرية.
أسئلة شائعة عن Docker
هل الحاوية آلة افتراضية؟ لا؛ هي عملية معزولة تستخدم نواة نظام المضيف، مع اختلاف نموذج العزل والتشغيل عن الآلة الافتراضية الكاملة.
هل البيانات تبقى بعد حذف الحاوية؟ فقط إذا خُزنت في volume أو خدمة تخزين دائمة مناسبة.
هل الصورة الصغيرة آمنة تلقائيًا؟ لا؛ الحجم عامل واحد، ويجب مراجعة المستخدم والصلاحيات والأسرار والتحديثات ومصدر الصورة.
خطة تطبيق عملية
- حدّد ملفات التشغيل والاعتمادات المطلوبة.
- اكتب Dockerfile و.dockerignore.
- ابنِ صورة بإصدار معروف وافحص حجمها.
- اختبر التشغيل والسجلات وإشارات الإنهاء.
- أدر الأسرار والبيانات خارج الصورة وخطة النشر.
أخطاء شائعة انتبه لها
- نسخ
.envأو.gitداخل الصورة. - تشغيل التطبيق كـ root دون سبب.
- الاعتماد على
latestدون تثبيت الإصدار المنشور.
الخلاصة
تكون الحاويات مفيدة عندما تجعل البيئة قابلة للتكرار وتسهّل نشر إصدار محدد. نجاحها يعتمد على بناء نظيف، وإدارة أسرار صحيحة، وصلاحيات محدودة، وخطة واضحة للبيانات والتحديث والرجوع.