5.3دوكر (Docker) لـ Node.js
الأساسي في 30 ثانية
- نهاية « يعمل على جهازي » : الحاوية (container) تحمل التطبيق مع بيئته وتدور متماثلة في كل مكان.
- الصورة ← الحاوية : ملف Dockerfile يصف الوصفة، وdocker build يجمّد الصورة، وdocker run يشغّل الحاوية.
- Compose للحزمة : التطبيق + القاعدة + التخزين المؤقت موصوفة في ملف وتُشغَّل معا — انضمام بأمر واحد.
حالة مصغرة متسلسلة — ساليم يحوْسِب في الجزائر
واجهة ساليم تدور تماما على جهازه في الجزائر — لكنها تتعطل عند زميلته (إصدار Node مختلف، ومتغير ناقص). يكتب Dockerfile : صورة قاعدة Node، واعتماديات مثبتة في الصورة، وأمر بدء. ثم ملف Compose مع قاعدة البيانات : تشغيل واحد يصعد بالحزمة كلها. تتمة الحالات 5.1-5.2 — يجعل ساليم تطبيقه قابلا لإعادة الإنتاج في كل مكان.
تتمة الحالات 5.1-5.2 — يمر ساليم من « عندي يعمل » إلى « متماثل في كل مكان ».
1. الحوسبة بالحاويات : الصورة والحاوية
يحل دوكر مشكلة « يعمل على جهازي » بتغليف التطبيق مع كل بيئته (إصدار Node، والاعتماديات، والإعداد) في حاوية (container) معزولة ومحمولة، تدور متماثلة في كل مكان : الجهاز، والزميلة، والخادم، والسحابة. المفاهيم : الصورة (نموذج مجمَّد للتطبيق + البيئة، يعرّفه Dockerfile — الوصفة : صورة قاعدة Node، ونسخ الشيفرة، وتثبيت الاعتماديات، وأمر البدء) والحاوية (نسخة مشغَّلة من صورة). نبني (docker build)، ونشغّل (docker run). وملف .dockerignore يستبعد الزائد من الصورة (node_modules — فالاعتماديات تُثبَّت داخل الصورة). لم يعد ساليم يجادل في الإصدارات : فالبيئة تسافر مع الشيفرة.
المنعكس : كل ما يخص جهازكم وغائب عن الصورة هو تعطّل مستقبلي في مكان آخر — فيجب أن تحوي الصورة كل شيء.
2. دوكر Compose والفوائد
لحزمة واقعية (تطبيق + قاعدة + تخزين مؤقت)، يعرّف دوكر Compose (docker-compose.yml) عدة حاويات وعلاقاتها، مشغَّلة معا بأمر واحد (docker compose up). ملف واحد يصف الحزمة كلها، قابلة لإعادة الإنتاج متماثلة — ويصير الانضمام بديهيا : مطور جديد يشغّل أمرا فيحصل على البيئة كلها. الفوائد : قابلية إعادة الإنتاج (متماثلة في كل مكان)، والعزل (لا تعارض بين التطبيقات والإصدارات)، وقابلية النقل (كل مضيف دوكر)، وسهولة النشر (النشر = تشغيل الحاوية — انظر 5.4). يضيف ساليم القاعدة إلى Compose : فتبدأ زميلته في دقائق.
دوكر معيار التطوير الحديث ومهارة عابرة (DevOps) : تكفي الأساسيات للبدء، ويأتي التنسيق المتقدم حسب الحاجات.
3. المقدار المناسب للمطور
لا حاجة لأن تصيروا خبراء بنية تحتية : استهدفوا الأساسيات المفيدة — كتابة Dockerfile بسيط، والبناء والتشغيل، وتنسيق التطبيق + القاعدة مع Compose، واستبعاد الزائد عبر .dockerignore. أتقنوا Node أولا (صميم مهنتكم)، وأضيفوا دوكر عندما تعملون مع فريق، أو تجهّزون نشرا، أو تديرون عدة خدمات. مما يُتجنَّب : تضمين node_modules في الصورة، واستهداف التنسيق المتقدم قبل الأساسيات، أو حوسبة سكربت تعلُّم صغير جدا دون حاجة حقيقية. يُبقي ساليم Dockerfile خاصته مقروءا : ست تعليمات مفهومة خير من وصفة منسوخة.
الملمح الجيد : مطور يعرف أساسيات التشغيل — مستقل، قادر لا على الترميز فقط بل على التسليم.
هل تعلم ؟
الصورة نفسها، والسلوك نفسه — في كل مكان.
🔎 مثال ملموس — ملف Dockerfile الخاص بساليم
وصفة الصورة، مقروءة في ستة أسطر.
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "app.js"]
# ملف .dockerignore : استبعاد node_modules
# docker compose up ← التطبيق + القاعدة معاالقراءة : لكل تعليمة دور — القاعدة، والاعتماديات، والشيفرة، والبدء.
الدرس : ملف Dockerfile مفهوم خير من وصفة منسوخة.
مفردات القسم
- دوكر
- أداة تغلّف التطبيق مع بيئته في حاوية محمولة.
مثال بسيط: واجهة ساليم تدور متماثلة في الجزائر وعند زميلته.
ما ليس كذلك: مجرّد مثبّت Node على كل جهاز.
رد فعل: هل ما زال تطبيقي معتمدا على جهازي ؟
- الصورة
- نموذج مجمَّد للتطبيق + البيئة، مبني من Dockerfile.
مثال بسيط: يبني ساليم صورة مُصدَرة من كل تسليم.
ما ليس كذلك: الحاوية المشغَّلة نفسها.
رد فعل: هل أستطيع إعادة بناء هذه الصورة متماثلة ؟
- Dockerfile
- وصفة بناء الصورة (القاعدة، والشيفرة، والاعتماديات، والبدء).
مثال بسيط: ست تعليمات مقروءة لواجهة ساليم.
ما ليس كذلك: سكربت يثبّت Node يدويا على خادم.
رد فعل: هل كل تعليمة مفهومة، لا منسوخة ؟
- الحاوية
- نسخة مشغَّلة من صورة، معزولة ومحمولة.
مثال بسيط: يشغّل ساليم حاوية متماثلة في التطوير والاستقبال.
ما ليس كذلك: الصورة المجمَّدة نفسها.
رد فعل: هل يشغّل التطوير والإنتاج الصورة نفسها ؟
- دوكر Compose
- ملف يصف عدة حاويات مشغَّلة معا.
مثال بسيط: تطبيق ساليم + قاعدته يُبدآن بأمر واحد.
ما ليس كذلك: التنسيق المتقدم من نوع Kubernetes.
رد فعل: هل يبدأ مطور جديد بأمر واحد ؟
في التطبيق — حوسبة تطبيق Node بالحاويات
- اكتبوا Dockerfile : انطلاقا من صورة Node، وانسخوا الشيفرة، وثبّتوا الاعتماديات (npm install)، وحددوا أمر البدء. وأضيفوا .dockerignore (node_modules…).
- ابنوا الصورة (`docker build`) وشغّلوا حاوية (`docker run`) ؛ وتحققوا من أن التطبيق يدور في الحاوية.
- نسّقوا مع دوكر Compose : ملف docker-compose.yml يعرّف تطبيق Node وقاعدته، مشغَّلين معا (`docker compose up`).
- قدّروا الفوائد : قابلية إعادة الإنتاج (متماثل في كل مكان)، والعزل، والانضمام (يكفي `docker compose up` واحد للبيئة كلها).
نص جاهز للقول — اقتراح دوكر على الفريق
« واجهتنا تعمل على جهازي لا في مكان آخر : فهي مشكلة بيئة، لا شيفرة. أقترح Dockerfile بسيطا — ست تعليمات — مع Compose للقاعدة. سيشغّل كل واحد الصورة نفسها، وسيبدأ الوافد الجديد بأمر واحد. نُبقي ذلك مقروءا ونتجنب التنسيق المتقدم حاليا. »
يُقال في اجتماع الفريق لاعتماد الحوسبة بالحاويات دون استهداف خبرة DevOps.
نموذج للنسخ واللصق — Dockerfile عام لـ Node
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "app.js"]
# .dockerignore :
# node_modules
# npm-debug.log
# .gitفردي / ميزانية صغيرة
ساليم وحده : يكفي Dockerfile بسيط دون Compose — فالصورة تجمّد البيئة أصلا.
شركة صغيرة جدا / فريق مصغر
Compose للتطبيق + القاعدة : كل زميل يبدأ الحزمة الكاملة دون تثبيت يدوي.
شركة صغيرة ومتوسطة في الجزائر
يشارك ساليم الصورة مع الفريق في الجزائر : يختبر الجميع النسخة نفسها، وانتهت فوارق الأجهزة.
فريق يبدأ
ثنائي : أحدهما يكتب Dockerfile، والآخر يراجعه سطرا سطرا ؛ والبناء مُختبَر على جهازين قبل الاعتماد.
✓ ممارسات جيدة
- أتقنوا Node أولا، ثم تعلموا أساسيات دوكر.
- أضيفوا .dockerignore (استبعاد node_modules).
- استعملوا دوكر Compose لتنسيق التطبيق + القاعدة (انضمام سريع).
✗ أخطاء شائعة
- تضمين node_modules في الصورة (ثبّتوها في الصورة عبر npm install).
- الرغبة في إتقان التنسيق المتقدم قبل الأساسيات.
- حوسبة سكربت تعلُّم صغير جدا دون حاجة حقيقية.
النقاط الأساسية
- دوكر (Docker) يغلّف التطبيق مع بيئته في حاوية (container) معزولة ومحمولة، تدور متماثلة في كل مكان — نهاية « يعمل على جهازي ».
- الصورة (نموذج مجمَّد، يعرّفه Dockerfile) ← الحاوية (نسخة). `docker build` / `docker run`. و .dockerignore يستبعد node_modules.
- دوكر Compose يعرّف عدة حاويات (التطبيق + القاعدة + التخزين) مشغَّلة معا (`docker compose up`) — يصف الحزمة كلها، قابلة لإعادة الإنتاج.
- الفوائد : قابلية إعادة الإنتاج، والعزل، وقابلية النقل، وسهولة النشر، وانضمام سريع. معيار حديث (عابر نحو DevOps).
تحدي 48 ساعة — طبّق غدا
اكتبوا Dockerfile تطبيقكم (النموذج أعلاه) وشغّلوه في حاوية : هل يجيب متماثلا كما على جهازكم ؟
- أستطيع شرح الصورة مقابل الحاوية في جملة واحدة.
- ملف Dockerfile خاصتي يبني صورة تدور.
- أعرف لماذا لا تظهر فيه node_modules.
أسئلة شائعة
ماذا يقدم دوكر عمليا، وهل هو ضروري لمطور Node ؟
يقدم دوكر أساسا قابلية إعادة الإنتاج : نهاية « يعمل على جهازي » (الحاوية تحمل كل شيء، فتدور متماثلة في كل مكان). وأيضا : العزل (عدة تطبيقات / إصدارات دون تعارض)، وقابلية النقل (كل مضيف دوكر)، وسهولة النشر (النشر = تشغيل الحاوية)، وانضمام سريع (أمر docker compose up واحد يصعد بالحزمة كلها). لتعلم Node أو المشاريع الفردية الصغيرة، ليس صارما. وللتطوير المهني، مع فريق أو مع نشر، صار شبه لا غنى عنه — وعابر. أتقنوا Node أولا، ثم أساسيات دوكر.
دوكر، والنشر، و CI/CD... هل يجب أن أصير خبير DevOps زيادة على مطور ؟
لا، ليس خبيرا — لكن معرفة الأساسيات تنفع كثيرا : الاستقلالية (وضع عمله في الإنتاج)، وقابلية التوظيف (عروض تطلب دوكر / النشر / CI-CD)، وتعاون أفضل (تطبيقات سهلة النشر)، ورؤية كاملة للدورة. استهدفوا الأساسيات : الحوسبة و Compose (لا التنسيق المتقدم)، والنشر على منصة بسيطة، وخط أنابيب CI/CD بسيط، والأسرار والإعداد في متغيرات البيئة، ومفاهيم السجلات / المراقبة / HTTPS. الملمح الجيد : مطور يعرف أساسيات التشغيل — قادر لا على الترميز فقط بل على التسليم.
أي مشكلة يحلها دوكر أساسا ؟