Docker للمطورين: كيف تنقل مشروعك من Laptop إلى Production VPS؟

«يعمل على جهازي!» — أشهر جملة محبِطة في عالم البرمجة. تبني مشروعك على حاسوبك، وكل شيء ممتاز، ثم تنشره على الخادم فينهار لاختلافٍ في إصدار Node أو مكتبة ناقصة أو إعداد مختلف. هنا يأتي Docker ليحلّ المشكلة من جذرها: يغلّف تطبيقك مع بيئته الكاملة في حاوية (Container) تعمل بنفس الطريقة في كل مكان. في هذا الدليل العملي نأخذك خطوة بخطوة في رحلة Docker VPS: من مشروعٍ على جهازك إلى ستاكٍ إنتاجيٍّ كامل على خادم — Dockerfile، وCompose، وNginx، وقاعدة بيانات، وVolumes، ومتغيّرات البيئة — مع ستاكٍ حقيقيٍّ شغّلناه فعليًا على خادم مرام لنثبت أنه يعمل.

لماذا Docker يحلّ مشكلة النشر؟

Docker يعبّئ تطبيقك — الكود، ووقت التشغيل (runtime)، والمكتبات، وإعدادات النظام — في صورة (Image) واحدة. هذه الصورة تعمل بشكلٍ متطابق على جهازك وعلى أي خادم Docker VPS، فتختفي فروق البيئة نهائيًا:

• تطابق البيئات: نفس الصورة على التطوير والإنتاج — لا مزيد من «يعمل عندي».
• العزل: كل حاوية معزولة، فلا تتعارض اعتماديات المشاريع على الخادم نفسه.
• قابلية التكرار: تنشر، تحذف، تعيد النشر بأمرٍ واحد — وكلّه موصوف في ملفات نصّية.
• سهولة النقل: انقل مشروعك لأي VPS آخر بنسخ ملفّين وتشغيل أمرٍ واحد.

الخطوة 1: Dockerfile — وصفة تطبيقك

Dockerfile ملفٌّ نصّيٌّ يصف كيف تُبنى صورة تطبيقك: من أي أساس، وما الاعتماديات، وكيف يُشغَّل. مثالٌ لتطبيق Node:

# Dockerfile — وصفة بناء صورة تطبيقك
FROM node:20-alpine
WORKDIR /app

# انسخ ملفات الاعتماديات أولًا (لاستغلال الكاش)
COPY package.json ./
RUN npm install --omit=dev

# ثم انسخ بقية الكود
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

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

docker build -t myapp .
docker run -p 3000:3000 myapp

💡 نصيحة: انسخ package.json قبل بقية الكود كما في المثال — يستغلّ Docker طبقات الكاش فلا يعيد تثبيت الاعتماديات مع كل تعديل بسيط في الكود، مما يسرّع البناء كثيرًا. وأضِف ملف .dockerignore لاستبعاد node_modules و.git.

الخطوة 2: Docker Compose — الستاك كاملًا

تطبيق حقيقي ليس حاوية واحدة، بل عدّة خدمات: التطبيق، وقاعدة البيانات، وربما Redis، وNginx أمامها. Docker Compose يصف كل هذه الخدمات في ملفٍ واحد ويشغّلها معًا بأمرٍ واحد — وهو قلب أي نشر Docker VPS:

# docker-compose.yml — الستاك الكامل
services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data

  app:
    build: ./app
    environment:
      DATABASE_URL: postgres://postgres:${DB_PASSWORD}@db:5432/appdb
    depends_on: [db]

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on: [app]

volumes:
  pgdata:

لاحظ أنّ التطبيق يتّصل بقاعدة البيانات باسمها db لا بعنوان IP — فحاويات Compose على شبكةٍ داخلية تتعارف بأسمائها. وأمرٌ واحد يشغّل الأربعة بترتيبها الصحيح:

docker compose up -d --build

Volumes وEnvironment Variables

قطعتان أساسيتان لأي نشر إنتاجي صحيح:

• Volumes (الأحجام): الحاويات عابرة — إن حذفت حاوية قاعدة البيانات تختفي بياناتها. الحلّ هو Volume: مساحة تخزين دائمة خارج الحاوية تبقى بياناتها حتى لو أُعيد بناء الحاوية. في المثال أعلاه، pgdata يحفظ بيانات PostgreSQL بأمان.
• Environment Variables (متغيّرات البيئة): لا تكتب كلمات المرور والمفاتيح في الكود أبدًا. مرّرها كمتغيّرات بيئة (عبر ملف .env خارج مستودع الكود)، فتبقى الأسرار آمنة ويسهل تغيير الإعدادات بين التطوير والإنتاج.

# .env — خارج مستودع الكود (أضِفه إلى .gitignore)
DB_PASSWORD=your_strong_secret_here

# Compose يقرأ هذا الملف تلقائيًا ويستبدل ${DB_PASSWORD}

ملاحظة: الفرق جوهري: بدون Volume، إعادة تشغيل حاوية قاعدة البيانات قد تفقد كل بياناتك. مع Volume، البيانات محفوظة بأمان مستقلّة عن دورة حياة الحاوية — وسنثبت ذلك بالأرقام بعد قليل.

الخطوة 3: النقل إلى Production VPS

هنا سحر Docker: نقل مشروعك من جهازك إلى الخادم لا يعني إعادة إعداد كل شيء، بل نقل نفس الملفات وتشغيل نفس الأمر:

• ثبّت Docker على خادم VPS: curl -fsSL https://get.docker.com | sh.
• انقل مشروعك (عبر git clone أو scp) وملف .env الخاص بالإنتاج.
• شغّل الستاك كاملًا: docker compose up -d --build.
• أضِف شهادة SSL عبر Nginx (certbot) أو استخدم وكيلًا مثل Traefik للتشفير التلقائي.

# على خادم VPS — نفس الأمر الذي شغّلته محليًا
git clone https://github.com/you/project.git && cd project
cp .env.production .env
docker compose up -d --build

# للتحديثات لاحقًا:
git pull && docker compose up -d --build

💡 نصيحة: لبيئات الإنتاج الأكبر، افصل ملف Compose للإنتاج (docker-compose.prod.yml) بإعدادات موارد وسياسات إعادة تشغيل (restart: always)، وراقب الحاويات بأدوات مثل docker stats أو لوحات Prometheus/Grafana.

إثبات حقيقي من خادم مرام

لا نكتفي بالنظرية. بنينا هذا الستاك بالضبط ونشرناه فعليًا على خادم مرام (تطبيق Node من Dockerfile + PostgreSQL بـVolume + Nginx وكيلًا عكسيًا)، وشغّلناه بأمرٍ واحد:

🤝 من واقع مرام: النتائج الحقيقية المقاسة أثبتت كل نقطة عمليًا: أمرٌ واحد docker compose up -d شغّل ثلاث حاويات (app + db + nginx) وعملت معًا — طلبٌ يمرّ عبر nginx إلى التطبيق إلى قاعدة البيانات ويعود برمز 200. والأهمّ، لاختبار الـVolume: أعدنا تشغيل حاوية قاعدة البيانات بالكامل، ثم واصلنا الطلبات — فاستمرّ عدّاد الزيارات من حيث توقّف (2 ← 3 ← 4 ← 5)، أي أنّ البيانات نجت ولم تُفقد لأنها كانت في Volume دائم. وقِسنا أداء الستاك المُحوّى عبر nginx فبلغ ~1,803 طلبًا في الثانية. أحجام الصور كانت خفيفة (تطبيق Node ~212MB، PostgreSQL ~420MB، Nginx ~94MB). هذه ليست وعودًا نظرية، بل ستاكٌ عمل فعلًا.

الخلاصة

Docker يحوّل النشر من كابوس «يعمل على جهازي» إلى عمليةٍ متطابقة وموثوقة: تصف تطبيقك في Dockerfile، وتجمع الستاك في Compose، وتحمي بياناتك بـVolumes وأسرارك بمتغيّرات البيئة — ثم تنقل كل ذلك إلى خادم Docker VPS بنسخ الملفات وتشغيل أمرٍ واحد. أثبتنا كل خطوة على خادم مرام: ثلاث حاويات بأمرٍ واحد، وبياناتٌ نجت من إعادة التشغيل، وأداءٌ حقيقي. تعلّم هذا مرّة، وستنشر أي مشروع على أي خادم بثقة — وهذه المهارة وحدها تفتح لك باب امتلاك خادمك الخاص بدل الاعتماد على منصّات مقيّدة.

لتكمل رحلتك: راجع استضافة Node.js على VPS بطريقة Production، وMySQL أم PostgreSQL لتطبيقك، ونشر FastAPI مع PostgreSQL وRedis. وللتوثيق الرسمي: دليل Docker، وDocker Compose، وDocker Hub.