مشروع مصغر: تشغيل منصة WordPress كاملة مع قاعدة بياناتها بضغطة زر

تشغيل منصة WordPress مع قاعدة بياناتها يدوياً على خادم جديد يبدو بسيطاً في البداية، لكنه يتحول بسرعة إلى سلسلة طويلة من المهام: تثبيت الحزم، تجهيز PHP، ضبط MySQL أو MariaDB، إنشاء المستخدمين، ثم معالجة مشاكل الشبكة والصلاحيات. هنا تظهر قيمة الأتمتة الحقيقية التي تشرح جوهر ما هو DevOps؟ ولماذا تدفع الشركات ثروات لمهندسي الأتمتة السحابية؟.

في هذا المشروع المصغر سنبني منصة كاملة تعتمد على Docker Compose لتشغيل خدمتين مترابطتين: تطبيق WordPress وقاعدة بيانات MariaDB. الهدف ليس مجرد “التشغيل”، بل الوصول إلى بنية قابلة لإعادة الاستخدام، سهلة النقل، مناسبة للاختبار المحلي أو السيرفرات الصغيرة أو بيئات Staging.

لماذا هذا النموذج مهم هندسياً؟

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

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

المعمارية المختصرة للمشروع

سنعتمد على ثلاث طبقات منطقية:

• خدمة wordpress لتقديم التطبيق عبر المنفذ 8080.
• خدمة db المعتمدة على MariaDB.
• وحدات تخزين دائمة Volumes لحماية البيانات والملفات.

هذه الفكرة ترتبط مباشرة بمقال التخزين الدائم (Docker Volumes): كيف نمنع ضياع قواعد البيانات عند توقف الحاوية؟، لأن إيقاف الحاوية أو حذفها دون تخزين دائم قد يعني خسارة قاعدة الموقع بالكامل.

المتطلبات الأساسية قبل التنفيذ

قبل تشغيل المشروع، تأكد من تثبيت Docker Engine وDocker Compose. إذا كنت ما زلت في مرحلة الإعداد الأولي فارجع إلى تثبيت Docker وإعداد بيئة العمل على Linux و Windows.

أنشئ مجلداً جديداً للمشروع وليكن باسم wordpress-stack، ثم أضف داخله ملف docker-compose.yml.

ملف التشغيل المركزي

بدلاً من تشغيل كل حاوية يدوياً بأوامر منفصلة، سنضع التوصيف الكامل داخل ملف واحد. إن لم تكن معتاداً على كتابة هذا النوع من الملفات، يفيدك الرجوع إلى كتابة أول ملف docker-compose.yml خطوة بخطوة.

version: "3.9"

services:
  db:
    image: mariadb:11
    container_name: wordpress_db
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wp_user
      MARIADB_PASSWORD: change_this_app_password
      MARIADB_ROOT_PASSWORD: change_this_root_password
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - wp_net

  wordpress:
    image: wordpress:latest
    container_name: wordpress_app
    depends_on:
      - db
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: change_this_app_password
    volumes:
      - wp_data:/var/www/html
    networks:
      - wp_net

volumes:
  db_data:
  wp_data:

networks:
  wp_net:
    driver: bridge

كيف نقرأ هذا الملف كمهندس بنية تحتية؟

• الحاوية db تستخدم صورة جاهزة من MariaDB.
• الحاوية wordpress تتصل بقاعدة البيانات عبر اسم الخدمة db داخل الشبكة الداخلية.
• القيم الموجودة تحت environment تمثل طبقة الربط الديناميكي بين الخدمتين.
• المجلدان db_data وwp_data يوفران الاستمرارية.

هذا الربط الآلي بين التطبيق وقاعدة البيانات يطابق ما شرحناه في ربط حاوية خادم (Backend) بحاوية قاعدة بيانات (MySQL/PostgreSQL) آلياً، كما يعتمد ضمنياً على مفهوم إدارة الشبكات (Docker Networks): كيف تتحدث الحاويات مع بعضها بأمان؟.

تشغيل المنصة فعلياً بضغطة زر

بعد حفظ الملف، انتقل إلى المجلد نفسه ثم نفّذ الأوامر التالية:

docker compose up -d
docker compose ps
docker compose logs -f

الأمر الأول يبني البنية ويشغلها في الخلفية، والثاني يتحقق من حالة الخدمات، أما الثالث فيعرض السجلات الحية لتسهيل التشخيص. بعد نجاح التشغيل افتح المتصفح على العنوان http://localhost:8080 أو عنوان الخادم إن كنت تعمل على آلة سحابية.

تحسين الأمان وعدم تخزين الأسرار داخل الملف

في البيئات الحقيقية لا يجب ترك كلمات المرور صريحة داخل ملف التكوين. الأفضل نقلها إلى ملف .env أو استخدام آلية أسرار أكثر تقدماً. ولتوسيع هذا المفهوم، راجع تمرير المتغيرات البيئية (Environment Variables) للحاويات بشكل آمن.

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

كيف نطوّر هذا المشروع إلى بيئة احترافية؟

المشروع الحالي ممتاز كبداية، لكنه في الإنتاج يحتاج إلى طبقات إضافية. من أهم التحسينات الممكنة إضافة Reverse Proxy مثل Nginx، وتفعيل شهادات TLS، وربط المشروع بخط نشر مستمر CI/CD عبر GitHub Actions أو Jenkins.

كذلك يمكن فصل بيئة الاختبار عن الإنتاج، واستخدام صور مخصصة بدلاً من الصور القياسية عندما تحتاج إلى إضافات Plugins أو تعديلات نظامية. وإذا أردت تقليل الاستهلاك وتحسين سرعة السحب، ففهم بناء الصور الخفيفة يصبح مهماً كما في تقليل حجم الحاويات: بناء صور دوكر خفيفة جداً وسريعة (Alpine Linux).

في بيئة الإنتاج، لا تعتمد على docker compose down -v إلا وأنت مدرك تماماً للعواقب، لأن هذا الأمر قد يحذف وحدات التخزين المرتبطة بالمشروع ويؤدي إلى فقدان بيانات الموقع وقاعدة البيانات بشكل كامل.

فحص الأعطال الشائعة بسرعة

إذا لم تعمل المنصة من أول مرة، فغالباً تكون المشكلة في واحدة من النقاط التالية:

1. تعارض المنفذ 8080 مع خدمة أخرى على الخادم.
2. خطأ في كلمة المرور بين خدمتي wordpress وdb.
3. عدم اكتمال تهيئة قاعدة البيانات عند أول إقلاع.
4. صلاحيات تخزين غير سليمة على المضيف في بعض البيئات.

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

الخلاصة

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

الأهم من ذلك أن هذا النموذج لا يخدم فقط موقعاً بسيطاً، بل يرسخ طريقة تفكير DevOps الحقيقية: اجعل البنية قابلة للوصف، قابلة للتشغيل آلياً، سهلة المراجعة، وقابلة للتوسعة نحو CI/CD والإنتاج السحابي لاحقاً.