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

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

هذا الموقف، يا جماعة، هو المدخل المثالي لعالم الحاويات (Containers). وقتها مسكت أحمد وحكيتله: “يا حبيبنا، المشكلة مش في كودك، المشكلة في البيئة. شو رأيك لو في طريقة نغلّف فيها الكود وكل شي بيحتاجه عشان يشتغل، ونبعتهم سوا كأنهم صندوق واحد مغلق؟”. من هنا بدأت رحلتنا مع Docker و Kubernetes، الأدوات اللي غيرت طريقة بناء ونشر التطبيقات بالكامل.

ما هو Docker؟ ولماذا صرنا لا نستغنى عنه؟

ببساطة، Docker هو أداة تسمح لك بـ “حزم” تطبيقك مع كل ما يلزمه للعمل – من مكتبات، وإعدادات، وحتى أجزاء من نظام التشغيل – في وحدة واحدة مستقلة تسمى “الحاوية” (Container). هذه الحاوية تعمل بنفس الطريقة تماماً على أي جهاز مثبت عليه Docker، سواء كان جهازك الشخصي، جهاز زميلك، أو سيرفر في السحابة.

الفرق الجوهري: الآلات الافتراضية (VMs) مقابل الحاويات (Containers)

قبل Docker، كنا نستخدم الآلات الافتراضية (Virtual Machines) لحل مشكلة البيئات المختلفة. لكن الفرق بينهم شاسع:

• الآلة الافتراضية (VM): تخيل أنك تبني بيت كامل بكل غرفه ومرافقه (نظام تشغيل كامل) فقط لتسكن فيه شخص واحد (تطبيقك). هذا يستهلك الكثير من الموارد (مساحة، رام، معالج) وبطيء في التشغيل.
• الحاوية (Container): تخيل أنك تسكن في شقة داخل عمارة كبيرة. كل الشقق (الحاويات) تشترك في البنية التحتية الأساسية للعمارة (نواة نظام التشغيل المضيف)، لكن كل شقة معزولة تماماً عن الأخرى. هذا يجعلها خفيفة جداً، سريعة، وتستهلك موارد أقل بكثير.

صورة Docker (Image) مقابل الحاوية (Container)

هناك مصطلحان أساسيان يجب أن تفهمهما جيداً:

• الصورة (Image): هي القالب أو المخطط الأساسي. إنها ملف للقراءة فقط يحتوي على كل التعليمات اللازمة لتشغيل تطبيقك. يمكنك تشبيهها بالـ “وصفة” لطبخة معينة.
• الحاوية (Container): هي نسخة حية وقيد التشغيل من الصورة. هي “الطبخة” الفعلية التي تم إعدادها بناءً على الوصفة. يمكنك إنشاء عدد لا نهائي من الحاويات من نفس الصورة.

لنبدأ التطبيق العملي: بناء أول حاوية لتطبيق Node.js

الكلام النظري جميل، لكن التطبيق العملي هو الأهم. لنقم ببناء ونشر تطبيق Node.js بسيط مع قاعدة بيانات MongoDB.

الخطوة 1: تجهيز تطبيق Node.js بسيط

أنشئ مجلداً جديداً وبداخله ملفين:

ملف package.json:

{
  "name": "node-mongo-app",
  "version": "1.0.0",
  "description": "Simple Node.js app with MongoDB",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.2",
    "mongoose": "^7.5.0"
  }
}

ملف server.js:

const express = require('express');
const mongoose = require('mongoose');

const app = express();
const PORT = 3000;

// استبدل 'mongodb' باسم الخدمة في Docker Compose لاحقاً
const MONGO_URI = process.env.MONGO_URI || 'mongodb://localhost:27017/testdb';

mongoose.connect(MONGO_URI)
  .then(() => console.log('MongoDB Connected!'))
  .catch(err => console.error(err));

app.get('/', (req, res) => {
  res.send('

مرحباً من تطبيق Node.js داخل حاوية Docker!

الإصدار 1.0

');
});

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

الخطوة 2: كتابة الـ Dockerfile (الوصفة السحرية)

في نفس المجلد، أنشئ ملفاً جديداً باسم Dockerfile (بدون أي امتداد) وضع فيه المحتوى التالي:

# 1. اختر الصورة الأساسية التي ستبني عليها
FROM node:18-alpine

# 2. حدد مجلد العمل داخل الحاوية
WORKDIR /usr/src/app

# 3. انسخ ملفات package.json و package-lock.json
COPY package*.json ./

# 4. قم بتثبيت الاعتماديات (dependencies)
RUN npm install

# 5. انسخ باقي ملفات الكود إلى مجلد العمل
COPY . .

# 6. عرّف المنفذ الذي سيعمل عليه التطبيق داخل الحاوية
EXPOSE 3000

# 7. الأمر الذي سيتم تنفيذه عند تشغيل الحاوية
CMD [ "npm", "start" ]

نصيحة من أبو عمر: استخدام node:18-alpine كصورة أساسية فكرة ممتازة لأنها نسخة خفيفة جداً من لينكس، مما يجعل حجم صورتك النهائية أصغر بكثير.

الخطوة 3: بناء الصورة وتشغيل الحاوية

الآن، افتح الطرفية (Terminal) في مجلد المشروع ونفذ الأوامر التالية:

1. بناء الصورة:

docker build -t my-node-app .

2. تشغيل الحاوية: (هذا الأمر لن يعمل بشكل كامل لأننا لم نربط قاعدة البيانات بعد، لكنه يوضح الفكرة)

# هذا الأمر سيربط المنفذ 3000 على جهازك بالمنفذ 3000 داخل الحاوية
docker run -p 3000:3000 my-node-app

عندما يكبر التطبيق: Docker Compose لإدارة الخدمات المتعددة

تطبيقنا يحتاج إلى قاعدة بيانات MongoDB. تشغيل كل خدمة في حاوية منفصلة أمر جيد، لكن كيف نجعلها تتواصل مع بعضها؟ هنا يأتي دور Docker Compose.

ملف docker-compose.yml: قائد الأوركسترا الصغير

أنشئ ملفاً جديداً باسم docker-compose.yml:

version: '3.8'

services:
  # خدمة تطبيق Node.js
  app:
    build: . # ابني الصورة من الـ Dockerfile الموجود في هذا المجلد
    ports:
      - "3000:3000" # اربط منفذ جهازك 3000 بمنفذ الحاوية 3000
    environment:
      # مرر متغير البيئة الذي يحتوي على رابط قاعدة البيانات
      - MONGO_URI=mongodb://db:27017/testdb
    depends_on:
      - db # لا تشغل هذه الخدمة إلا بعد أن تعمل خدمة 'db'

  # خدمة قاعدة البيانات MongoDB
  db:
    image: mongo:latest # استخدم صورة جاهزة من Docker Hub
    ports:
      - "27017:27017"
    volumes:
      - mongo-data:/data/db # للحفاظ على البيانات حتى لو حذفت الحاوية

volumes:
  mongo-data:

لاحظ كيف أننا في MONGO_URI استخدمنا mongodb://db بدلاً من localhost. لأن Docker Compose ينشئ شبكة داخلية خاصة، وتصبح أسماء الخدمات (app, db) هي أسماء المضيف (hostnames) التي يمكن للحاويات استخدامها للتواصل.

تشغيل كل شيء بأمر واحد

الآن، وبكل بساطة، نفذ هذا الأمر:

docker-compose up

سترى كيف يقوم Docker Compose ببناء صورة تطبيقك، تحميل صورة MongoDB، وتشغيل الحاويتين وربطهما معاً. الآن إذا فتحت المتصفح على http://localhost:3000، سترى رسالة الترحيب، وإذا نظرت إلى سجلات الطرفية، سترى رسالة “MongoDB Connected!”.

من إدارة الحاويات إلى تنسيقها: مرحباً Kubernetes (K8s)

Docker و Docker Compose رائعان للتطوير المحلي وللتطبيقات البسيطة. لكن عندما تنتقل إلى بيئة الإنتاج الحقيقية، مع عشرات أو مئات الحاويات الموزعة على عدة سيرفرات، ستحتاج إلى “قائد أوركسترا” حقيقي. هذا القائد هو Kubernetes.

ما هو Kubernetes (K8s) ولماذا هو ضروري؟

Kubernetes (يُختصر بـ K8s) هو نظام مفتوح المصدر لتنسيق الحاويات (Container Orchestration). وظيفته هي أتمتة نشر التطبيقات وتوسيعها وإدارتها. فكر فيه كالعقل المدبر الذي يضمن أن تطبيقك يعمل دائماً بكفاءة عالية. من أهم مزاياه:

• المراقبة والإصلاح الذاتي (Self-healing): إذا تعطلت إحدى الحاويات، يقوم K8s بإعادة تشغيلها تلقائياً.
• موازنة الأحمال (Load Balancing): يوزع الضغط على نسخ متعددة من تطبيقك.
• التوسع الأفقي (Horizontal Scaling): يمكنك زيادة أو تقليل عدد نسخ تطبيقك بأمر واحد.
• التحديثات بدون توقف (Rolling Updates): يسمح لك بتحديث تطبيقك لنسخة جديدة بدون أي انقطاع في الخدمة.

أهم مفاهيم Kubernetes للمبتدئين

• Pod: هو أصغر وحدة يمكن نشرها في K8s. يمكن أن يحتوي على حاوية واحدة أو أكثر. هو الغلاف الذي تعيش فيه حاوياتك.
• Deployment: هو المخطط الذي يصف الحالة المرغوبة لتطبيقك. أنت تخبره: “أريد 3 نسخ (Pods) من صورة تطبيقي هذه”، وهو يتكفل بالباقي.
• Service: يوفر عنوان شبكة ثابت ونقطة وصول واحدة لمجموعة من الـ Pods. بما أن الـ Pods قد تتعطل ويتم استبدالها (ويتغير عنوان IP الخاص بها)، فإن الـ Service يضمن أنك تستطيع الوصول لتطبيقك دائماً عبر عنوان ثابت.

تطبيقنا على Kubernetes: من المحلي إلى السحابة (بشكل مبسط)

لننشر تطبيقنا الذي بنيناه على بيئة Kubernetes محلية باستخدام أداة تسمى Minikube.

ملاحظة: ستحتاج إلى تثبيت Minikube و kubectl على جهازك. هذه الخطوة تتطلب بعض الإعدادات التي يمكنك البحث عنها حسب نظام التشغيل الخاص بك.

الخطوة 1: دفع الصورة إلى مستودع (Registry)

Kubernetes يحتاج لسحب صور التطبيقات من مستودع مركزي مثل Docker Hub. أولاً، سنقوم برفع صورتنا:

# (استبدل 'yourusername' باسم المستخدم الخاص بك في Docker Hub)
docker tag my-node-app yourusername/my-node-app:1.0
docker push yourusername/my-node-app:1.0

الخطوة 2: إنشاء ملفات النشر (Deployment & Service)

أنشئ ملفاً باسم k8s-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-node-app-deployment
spec:
  replicas: 2 # سنبدأ بنسختين من التطبيق
  selector:
    matchLabels:
      app: my-node-app
  template:
    metadata:
      labels:
        app: my-node-app
    spec:
      containers:
      - name: my-node-app-container
        image: yourusername/my-node-app:1.0 # الصورة التي رفعناها
        ports:
        - containerPort: 3000
        env:
        # في بيئة حقيقية، ستكون قاعدة البيانات خدمة أخرى في K8s
        - name: MONGO_URI
          value: "mongodb://mongo-service:27017/testdb"
---
apiVersion: v1
kind: Service
metadata:
  name: my-node-app-service
spec:
  selector:
    app: my-node-app
  ports:
    - protocol: TCP
      port: 80 # المنفذ الخارجي للخدمة
      targetPort: 3000 # منفذ الحاوية
  type: LoadBalancer # هذا النوع سيعطينا IP خارجي للوصول للتطبيق

ملاحظة: نشر MongoDB على K8s يتطلب مفهوماً إضافياً يسمى `StatefulSet` للحفاظ على البيانات، لكننا سنركز هنا على تطبيق Node.js للتبسيط.

الخطوة 3: تطبيق الإعدادات ورؤية السحر

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

# تطبيق الإعدادات من الملف
kubectl apply -f k8s-deployment.yaml

# التحقق من حالة الـ Pods
kubectl get pods

# التحقق من حالة الخدمة والحصول على الـ IP
kubectl get services

بعد فترة قصيرة، سترى أن لديك 2 Pods قيد التشغيل، وخدمة لها عنوان IP خارجي يمكنك الوصول إليه.

القوة الحقيقية لـ Kubernetes: التوسع والتحديثات السلسة

التوسع (Scaling)

هل زاد الضغط على تطبيقك؟ لا مشكلة. بأمر واحد بسيط، يمكنك زيادة عدد النسخ:

# زيادة عدد النسخ إلى 4
kubectl scale deployment my-node-app-deployment --replicas=4

سيقوم K8s فوراً بإنشاء 2 Pods جدد وتوزيع الحمل عليهم تلقائياً.

التحديث بدون توقف (Rolling Update)

لنفترض أنك قمت بتعديل على الكود (مثلاً، غيرت رسالة الترحيب إلى “الإصدار 2.0”)، وبنيت صورة جديدة ورفعتها باسم yourusername/my-node-app:2.0.

كل ما عليك فعله هو تحديث سطر الصورة في ملف k8s-deployment.yaml من `1.0` إلى `2.0` ثم إعادة تنفيذ أمر `apply`:

kubectl apply -f k8s-deployment.yaml

ما سيحدث الآن هو السحر بعينه. Kubernetes لن يوقف كل الـ Pods القديمة مرة واحدة، بل سيقوم بالآتي:

1. ينشئ Pod جديد بالصورة الجديدة (v2.0).
2. ينتظر حتى يصبح الـ Pod الجديد جاهزاً لاستقبال الطلبات.
3. يوقف أحد الـ Pods القديمة (v1.0).
4. يكرر هذه العملية حتى يتم استبدال جميع الـ Pods القديمة بالجديدة.

بهذه الطريقة، يتم تحديث تطبيقك بالكامل بدون أن يشعر المستخدم بأي انقطاع في الخدمة. هذا هو معنى “Zero-downtime deployment”.

خلاصة أبو عمر ونصيحة من القلب 🧡

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

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

نصيحتي الأخيرة لكم: لا تكتفوا بالقراءة. نزلوا Docker على أجهزتكم، جربوا Minikube، ابنوا الصور، اكسروا الأشياء وحاولوا تصلحوها. التجربة العملية هي أسرع وأفضل طريق للتعلم. كما نقول عندنا “التكرار بعلّم الشطّار”.

يلا يا جماعة، شدوا الهمة، والمستقبل في هذه التقنيات واعد جداً. بالتوفيق للجميع! 💪