تشريح خادم ويب في الإنتاج — العمليات والملفات والإعداد المُحمَّل فعلًا

الهدف

معرفة كيف يعالج nginx وApache الاتصالات، وأين يوجد كل ملف إعداد، واستخراج الإعداد المُحمَّل فعلًا قبل لمس أي شيء.

أهم النقاط

• يعمل nginx بـ عملية رئيسية (master process) تقرأ الإعداد وتفتح المنافذ، وعمليات عاملة (workers) تعالج كلٌّ منها آلاف الاتصالات بالتوازي.
• يختار Apache 2.4 وحدة MPM: إمّا event (عمليات + خيوط تنفيذ، وهو الخيار الحديث) أو prefork (عملية لكل اتصال، ولا يُستعمل إلا مع mod_php القديم).
• الملف الذي تعدّله ليس بالضرورة هو الذي يعمل: فتعليمات include وروابط sites-enabled والقيم الافتراضية للتوزيعة كلها تُضاف إليه.
• nginx -T يعرض الإعداد المُحمَّل كاملًا بما فيه الملفات المُضمَّنة؛ و**apachectl -S** يسرد المضيفات الافتراضية (virtual hosts) النشطة فعلًا.
• نختبر دائمًا (nginx -t، apachectl configtest) ثم نعيد التحميل (reload)، ولا نعيد التشغيل.

1. ما يحدث عندما يتصل عميل

                 ┌───────────────────────────────┐
navigateur ───►  │ processus maître (root)        │  lit nginx.conf, ouvre 80/443
                 │   ├─ worker 1 (www-data)        │  ← accepte et traite les connexions
                 │   ├─ worker 2 (www-data)        │
                 │   └─ worker N (= nb de cœurs)   │
                 └───────────────────────────────┘

لا يتوقّف عامل nginx أبدًا عند عميل بطيء: بل ينتقل إلى التالي ويعود حين تصل البيانات. ولهذا يستطيع خادم nginx صغير أن يحافظ على عشرات الآلاف من الاتصالات المفتوحة.

ps -o pid,user,cmd -C nginx
#    PID USER     CMD
#    812 root     nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
#    813 www-data nginx: worker process
#    814 www-data nginx: worker process

أما Apache مع وحدة MPM event فيبدو هكذا: بضع عمليات، في كلٍّ منها عشرات الخيوط، وخيط « مُنصِت » يحتفظ باتصالات keep-alive الخاملة دون أن يشغل خيط عمل.

apachectl -V | grep -i mpm         # Server MPM:     event
apachectl -M | grep mpm            # mpm_event_module (shared)

2. أين توجد الملفات

في Debian وUbuntu يحتوي nginx.conf على هذين السطرين: وهما وحدهما يقرّران أي المواقع تُحمَّل.

include /etc/nginx/conf.d/*.conf;      # الملفات ذات الامتداد .conf فقط
include /etc/nginx/sites-enabled/*;    # كل ما في المجلد

النتيجة المباشرة: ملف ancien.conf.bak في conf.d/ لا يُحمَّل، أما ملف ancien.bak في sites-enabled/ فيُحمَّل.

3. قراءة الإعداد المُحمَّل فعلًا

nginx -t                                   # هل الصياغة سليمة؟ (يقرأ كل تعليمات include)
nginx -T | less                            # كل شيء، ملفًا ملفًا (# configuration file …)
nginx -T 2>/dev/null | grep -n 'server_name'   # أي الأسماء تُخدَم، وفي أي ملف
nginx -T 2>/dev/null | grep -E '^# configuration file'   # قائمة الملفات المقروءة

apachectl configtest                       # Syntax OK
apachectl -S                               # المضيفات الافتراضية منفذًا منفذًا، والموقع الافتراضي
apachectl -t -D DUMP_INCLUDES              # الملفات المُضمَّنة

مثال على مخرجات apachectl -S:

VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server www.masterlinux.lab (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost www.masterlinux.lab (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost intranet.masterlinux.lab (/etc/apache2/sites-enabled/intranet.conf:1)

4. الاختبار، وإعادة التحميل، دون قطع الخدمة

nginx -t && systemctl reload nginx          # تعيد العملية الرئيسية القراءة وتطلق عمليات عاملة جديدة،
                                            # وتُنهي القديمة طلباتها ثم تتوقف
apachectl configtest && systemctl reload apache2   # (httpd على Rocky): إعادة تشغيل « لطيفة »

الأمر restart يقطع كل الاتصالات الجارية، أما reload فلا يقطعها. وإذا كان الإعداد الجديد خاطئًا، يُبقي reload الإعداد القديم في الخدمة: ولهذا نختبر قبل ذلك.

5. حالة واقعية: « صحّحتُ، لكن لا شيء يتغيّر »

في وكالة MasterLinux بفاس، صحّح تقنيٌّ client_max_body_size في /etc/nginx/sites-available/intranet… لكن على نسخة intranet.old، لأن رابط sites-enabled كان يشير إلى الملف الآخر. ضاعت ساعة كاملة. والعادة التي كانت ستحلّ المشكلة في 10 ثوانٍ:

nginx -T 2>/dev/null | grep -n -B2 -A2 client_max_body_size
ls -l /etc/nginx/sites-enabled/

أخطاء شائعة

• تعديل الملف الخطأ: تحقّق دائمًا بـ nginx -T أو apachectl -S ممّا هو مُحمَّل.
• ترك نسخ احتياطية في sites-enabled/: الملف site.bak يُحمَّل هناك ويُنشئ تكرارات لـ server_name.
• restart بدل reload: يقطع التنزيلات واتصالات WebSocket الجارية.
• إعادة التحميل دون اختبار: في Apache قد يمنع خطأ صياغة الخدمة من الإقلاع عند التشغيل التالي للنظام.

المختبر

nginx غير مثبّت في آلة المختبر: ستعمل مباشرة على شجرة /etc/nginx مُعَدّة مسبقًا، كأنك تقرأ إعداد خادم مجهول. ستقوم بما يلي:

1. إيجاد الملف الذي يخدم المتجر؛
2. تعطيل موقع بطريقة نظيفة دون فقدان إعداده؛
3. إعادة بناء ما سيعرضه nginx -T يدويًا، مع احترام قواعد التضمين.

اختبار قصير

1. أي عملية في nginx تفتح المنفذين 80 و443، وتحت أي مستخدم تعمل العمليات العاملة في Debian؟
2. هل يُحمَّل ملف test.conf.old في conf.d/؟ وماذا عن test.old في sites-enabled/؟
3. أي أمر يعرض إعداد nginx المُحمَّل فعلًا كاملًا؟
4. ما الفرق بين reload وrestart بالنسبة إلى العملاء المتصلين؟
5. أي MPM في Apache يُفضَّل مع PHP-FPM؟