تناول الجزء الأوّل من هذا الدّليل الخوارزميّة الّتي يتبعها خادوم ويب Nginx لاختيّار كتلة Server للإجابة على طلب العميل. سنتحدَّث في هذا المقال عن كتل Location وكيف يقرّر Nginx الكتلة الّتي ستُجيب على الطّلب.

تحليل كُتَل Location

توجد لدى Nginx آليّة لتقرير كتلة Location (الموقع) الّتي ستتولّى التّعامل مع الطّلب. تُشبه هذه الخوارزميّة في عملها خوارزميّة اختيّار كتلة Server المشروحة في الجزء الأوّل من هذا الدّليل.

1- صيّاغة Syntax كتلة Location

نبدأ، قبل شرح خوارزميّة اختيّار كتلة Location الّتي ستتولّى الإجابة على الطّلب، بشرح الصّيّاغة الّتي يستخدمها Nginx في تعريفات كتل الموقع. تُستخدَم كُتل Location الّتي تقبع ضمن كتلة Server (أو ضمن كتلة Location أخرى)، لتقرير كيف يُتعامل مع المعرّفات الكليّة للموارد Universal Resource Identifier, URI (الجزء الّذي يأتي بعد اسم النّطاق أو عنوان IP/المنفذ).

تأخذ كتلة Location عمومًا الهيئة التّاليّة:

location optional_modifier location_match {

    . . .

}

تُحدّد تعليمة location_match مالّذي سيُقارن به معرّف المورد الموجود في الطّلب. يُحيل optional_modifier إلى مُغيِّر اختيّاري يؤثّر على الطّريقة الّتي يبحث بها Nginx عن تطابق في كتلة Location. نميّز الحالات التّاليّة، حسب قيمة optional_modifier:

• لا يوجد متغيّر: إن لم تُذكَر قيمة للمغيِّر الاختيّاريّ فإنّ الموقع سيُحلّل حسب التّطابق المُبدَأ Prefix match. يعني هذا أنّ الموقع سيُقارَن ببداية معرّف المورِد (URI) في الطّلب، بحثًا عن تطابقات.
• =: إذا استُخدمت علامة التّساوي فإنّ الكُتلة لن تُأخذ في الحسبان إلّا إذا كانت مطابقة تمامًا لمعرّف المورِد في الطّلب.
• ~: في هذه الحالة يُستخدَم تعبير نمطيّ Regular expression يتأثّر بحالة الأحرف (كبيرة Upper case أو صغيرة Lower case).
• *~: تختلف عن الحالة السّابقة في أنّ التّعبير النّمطيّ لا يتأثر بحالة الأحرف.
• ~^: تُشير هذه القيمة إلى أنّه إن اختيرت هذه الكتلة في بوصفها أفضل تطابق دون الاعتماد على التّعابير النّمطيّة فإنّ هذه الأخيرة (أي التّعابير النّمطيّة) لن تُأخَذ بالحسبان.

2- أمثلة توضّح صيّاغة كتلة Location

كتلة Location التّاليّة مثال على التّطابق المُبدَأ. ستُختار هذه الكتلة للإجابة على الطّلبات الّتي تتضمّن معرّفات الموارِد مثل site/page1/index.html/، site/ أو site/index.html/ (كلّها تبدأ ب site/):

location /site {

    . . .

}

لتوضيح التّطابق التّام نأخذ الكتلة التّاليّة الّتي ستُستخدَم للإجابة على الطّالبات ذات معرّف المورد page1/. لن تُختار هذه كتلة Location هذه للإجابة على طلب بمعرّف مورد page1/index.html/. انتبه إلى أنّه في حال اختيّار هذه الكتلة وكان الطّلب يُنفَّذ باستخدام صفحة فهرس (Index page) فإنّه ستُجرى إعادة توجيه داخليّة Internal redirect إلى كتلة موقع أخرى تكون هيّ المُداول Handler الفعليّ للطّلب:

location = /page1 {

    . . .

}

في الإعداد أدناه تعبيرٌ نمطيّ يتأثّر بحالة الأحرف. يُمكن أن تُستخدَم كتلة الموقع في هذا المثال للتّعامل مع الطّلبات على tortoise.jpg/ ولكنّها لا يُمكن أن تلبّي الطّلبات على FLOWER.PNG/.

location ~ \.(jpe?g|png|gif|ico)$ {

    . . .

}

المثال التّالي لا يختلف عن المثال السّابق سوى في المغيّر الاختيّاريّ (~*) حيثُ إنّ التّعبير النّمطي هنا لا يتأثّر بحالة الأحرف؛ لذا يُمكن استخدام الكتلة للإجابة على كلّ من tortoise.jpg/ و FLOWER.PNG/.

location ~* \.(jpe?g|png|gif|ico)$ {

    . . .

}

المثال الأخير للحالة الّتي تمنع فيها كتلة Location البحث عن تطابق عبر التّعابير النّمطيّة. تُحدّد الكتلة التّالية على أنّها أفضل تطابق لا يعتمد على التّعابير النّمطيّة للطّلبات على costumes/ninja.html/.

location ^~ /costumes {

    . . .

}

رأينا أنّ المغيّرات تُحدّد كيف يجب أن تُفسَّر كتلة Location؛ إلّا أنّها لا تخبرنا عن ماهيّة الخوارزميّة الّتي يستخدمها Nginx لتقرير كتلة الموقع الّتي سيُرسِل إليها الطّلب، وهو ما سنتعرّض لها في الفقرات التّاليّة.

3- كيف يختار Nginx كتلة Location الّتي ستتعامل مع الطّلبات؟

يستخدم Nginx آليّةً لاختيّار كتلة الموقِع الّتي ستُجيب على الطّلبات مُشابهةً لكيفيّة اختيّاره لكتلة الخادوم.فهم الإجراءات الّتي يتبعها Nginx لاختيّار الكتلة المناسبة أساسيّ جدًّا لتكون قادرًا على إعداد Nginx بوثوق ودقّة.

يُقارن Nginx بين معرّف المورد في الطّلب وكتلة Location، مع احتساب المغيّرات الّتي ذكرناه في الفقرة السّابقة، من أجل تحديد أنسب كتلة موقع للإجابة على الطّلب؛ وفقًا للخوارزميّة التّاليّة:

• يبدأ Nginx بالتحقّق من كلّ المواقع الّتي لا تستعمل تعابير نمطيّة؛ فيُقارن كلّ كتلة موقع بمعرّف مورد الطّلب كاملًا.

• يبحث Nginx أوّلًا عن تطابق كامل. إن وُجدت كتلة Location تستخدم المغيِّر = وتُطابق تمامًا معرّف المورد في الطّلب؛ فإنّ كتلة الخادوم هذه سيقع عليها الاختيّار فورًا.

• إن لم يعثُر على تطابق كامل (باستخدام المغيّر =)، ينتقل Nginx إلى تقويم السّابقات (Prefixes) غير المُطابقة تمامًا؛ فيبحث عن أطول تطابق في الموقع مع معرّف المورد ثمّ يقوّمه بالطّريقة التّاليّة:

  • إذا كانت كتلة الموقع الّتي يوجد بها أطول تطابق تستخدِم المغيّر ~^ فسيُنهي Nginx فورًا بحثَه ويختار هذه الكتلة للإجابة على الطّلب.

  • إن لم تكُن الكتلة الّتي يوجد بها أطول تطابق تستخدِم المغيّر ~^ فسيحتفظ بها Nginx دون أن يُنهي البحث، بحيث يُمكن له اختيّارها عند الحاجة.

• ينتقل Nginx، بعد تحديد الكتلة ذات التّطابق الأطول والاحتفاظ بها، إلى تقويم كتل المواقع الّتي تستخدِم التّعابير النّمطيّة، سواء كانت تتأثّر بحالة الأحرف أم لا. يُقوِّم Nginx التّعابير النمطيّة بالتّسلسل، ويختار فورًا أوّل كتلة موقع يُوافق تعبيرها النّمطيّ معرّفَ مورد الطّلب.

• إن لم يعثُر خادوم الويب على موقع ذي تعبير نمطيّ يُوافق معرّف المورد المطلوب فإنّه يختار الكتلة المُحتفَظ بها سابقًا للإجابة على الطّلب.

من المهمّ هنا أن نفهم أنّ Nginx، مبدئيًّا، يُفضّل كتل الموقع الّتي تُطابق الطّلب عبر تعابير نمطيّة؛ إلّا أنّه يبدأ بالبحث عن تطابق في كتل المواقع الّتي لا تستعمل تعابير نمطيّة، وهو ما يسمح لمسؤول خادوم الويب بتجاوز ميل Nginx إلى تفضيل التّعابير النّمطيّة عبر تحديد المغيِّرات = و~^.

من المهمّ أيضًا الانتباه إلى أنّ الاختيّار في كتل المواقع الّتي تستخدِم التّطابق المُبدَأ يكون حسب التّطابق الأطول والأكثر تحديدًا غالبًا. في حين أنّ تقويم التّعابير النمطيّة (وبالتّالي الاختيّار) يتوقّف فور الحصور على تطابق وهو ما يعني أنّ ترتيب كتل المواقع الّتي تستخدم التّعابير النّمطيّة له تأثير كبير على الاختيّار.

4- متى يتجاوز تقويم كتلة الموقع إلى مواقع أخرى؟

عند اختيّار كتلة Location للإجابة على طلب فإنّ التّعامل معه، ابتداءً من هذه النّقطة، يحدُث بالكامل ضمن إطار الكتلة المُختارة. فقط هذه الكتلة والتّعليمات المتفرّعة عنها هي من يُحدّد كيف يُتعامل مع الطّلب، دون تدخّل من كتل Location من نفس المستوى في البنية الشّجريّة.

تسمح هذه القاعدة العامّة بتصميم كتل Location يُمكن التّنبّؤ بعملها. على الرّغم من ذلك، يجب الانتباه إلى وجود حالات تتسبّب تعليمات داخل الكتلة المُختارة في البحث من جديد عن موقع. يُمكن لهذا الاستثناء من القاعدة العامّة “كتلة موقع واحدة فقط” أن يُحدِث تأثيرات على كيفيّة الإجابة على الطّلب، بحيث يُخالف التّوقّعات الّتي كانت عندك أثناء تصميم كتل المواقع.

في ما يلي بعض التّعليمات الّتي قد تؤدّي إلى إعادة توجيه من داخل الكتلة المختارة:

• index
• try_files
• rewrite
• serror_page

نعرض باختصار لكلّ واحدة من هذه التّعليمات.

تتسبّب تعليمة index دائمًا في إعادة توجيه إن استُخدِمت للتّعامل مع الطّلب. يُستخدَم التّطابق التّام غالبًا لتسريع اختيّار كتلة الموقع عبر إنهاء الخوارزميّة فور حدوث هذا التّطابق. مع ذلك، إن استخدمت التّطابق التّامّ في حال الطّلب على مجلَّد فإنّه توجد إمكانيّة كبيرة لإعادة توجيه الطّلب إلى موقع آخر للإجابة الفعليّة عليه.

تُطابق أوّل كتلة في المثال التّالي معرّف المورد exact/، إلّا أنّ تعليمة index الّتي ترثها هذه الكتلة تتسبّب في إعادة توجيه إلى الكتلة الثّانيّة:

index index.html;

location = /exact {

    . . .

}

location / {

    . . .

}

إذا احتجت أن يبقى تنفيذ الطّلب داخل الكتلة الأولى، في المثال أعلاه؛ فسيتطلّب ذلك منك استخدام وسيلة أخرى لتلبيّة الطّلب على المجلّد.

يُمكنك مثلًا استخدامُ فهرس غير صالح لهذه الكتلة ثمّ تفعيل تعليمة autoindex:

location = /exact {
    index nothing_will_match;
    autoindex on;
}

location  / {

    . . .

}

هذه إحدى الوسائل لمنع index من تبديل السّيّاق، ولكنّها وسيلة غير ناجعة في أغلب الإعدادات. يُستخدَم التّطابق التّامّ في المجلّدات كثيرًا في بعض الأمور مثل إعادة كتابة الطّلب Request rewriting (الّذي ينتُج عنه البحث من جديد عن الموقع).

قد تتسبّب تعليمة try_files هي الأخرى في إعادة تقويم عمليّة اختيّار الموقع. تطلُب هذه التّعليمة من Nginx التحقّق من وجود مجموعة مسمّاة من الملفّات أو المجلّدات؛ قد يكون المُعطى الأخير لتعليمة try_files معرّفَ مورد يُعيد Nginx التّوجيه إليه.

فلنأخذ الإعداد التّالي مثالًا للشّرح:

root /var/www/main;
location / {
    try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
    root /var/www/another;
}

سيختار Nginx الكتلة الأولى، في المثال أعلاه، في حال الطّلب على blahblah/. تبحث الكتلة عن ملفّ blahblah في المجلّد var/www/main/، وإن لم تعثُر عليه تبحث عن ملفّ blahblah.html؛ فإن لم تجد هذا الأخير تبحث عن مجلَّد blahblah/ ضمن var/www/main/. إذا فشلت كلّ هذه المحاولات يُعيد Nginx توجيه الطّلب إلى fallback/index.html/ وهو ما يتسبّب في استدعاء كتلة موقع الأخرى، الثّانيّة في المثال. في المحصّلة فإنّ الملفّ var/www/another/fallback/index.html/ سيكون الإجابة على الطّلب.

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

نُعيد استخدام المثال الأخير مع إضافة تعليمة rewrite للكتلة الأولى؛ يُمكن أن نلاحظ أنّ الطّلب يُمرَّر في بعض الحالات ماباشرةً إلى كتلة Location الثّانيّة دون تنفيذ تعليمة try_files:

root /var/www/main;
location / {
    rewrite ^/rewriteme/(.*)$ /$1 last;
    try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
    root /var/www/another;
}

تُجيب كتلة الموقع الأولى ابتداءً في المثال أعلاه على الطّلب rewriteme/hello/؛ ثمّ يأتي الطّلب لتعليمة rewrite الّتي تُعيد كتابته ليُصبح hello/ فيبدأ Nginx البحث من جديد عن موقع للإجابة على الطّلب ويعثُر من جديد على تطابق مع الكتلة الأولى ثمّ تُنفَّذ عليه تعليمة try_files وفقًا للآليّة المشروحة في مثال استخدام تعليمة try_files.

أمّا إذا كان الطّلب على rewriteme/fallback/hello/ فستُطابق كتلة الموقع الأولى الطّلب ثمّ تنفَّذ عليه تعليمة rewrite الّتي تعيد كتابته فيصبح fallback/hello/ ممّا ينتُج عنه مطابقة مع كتلة الموقع الثّانيّة وبالتّالي تُجيب الطّلب.

تحدُث حالة مُشابهة مع تعليمة return عند إرسال رمز الحالة Status code رقم 301 أو 302. الفرق في هذه الحالة هي أنّ النتيجة عبارة عن طلب جديد كلّيًّا على هيئة إعادة توجيه خارجيّة External redirect مرئيّة. نفس الشيء يُمكن أن يحدُث مع تعليمة rewrite عند استخدام عَلَميْ redirect و permanent. إلّا أنّ هذه الحالات يجب ألا تكون غير متوقّعة، فإعادة التّوجيه الخارجيّة المرئيّة ينتُج عنها دومًا طلب جديد.

ملحوظة 1: الفرق بين إعادة التّوجيه الدّاخليّة والخارجيّة هو أنّ الأولى لا تُنهي طلب العميل الحاليّ بل تُحيله إلى مسار آخر ضمن خادوم الويب؛ أمّا الخارجيّة فتُنهي طلب العميل مع إخباره بمعرّف المورد الجديد الّذي يجب عليه إرسال طلب آخر للحصول عليه.

ملحوظة 2: رموز الحالة هي أعداد يستخدمها بروتوكول HTTP ليُشعِر بالحالة الّتي انتهى عليها تنفيذ الطّلب. تُقسَّم إجابات HTTP إلى خمس مجموعات: إجابات بمعلومات، إجابات بنجاح الطّلب، إعادات توجيه، أخطاء من جانب العميل و أخطاء من جانب الخادوم.

يُمكن أن تؤدّي تعليمة error_page إلى إعادة توجيه داخليّة مشابهة لتلك الّتي تُنشئها تعليمة try_files. تُستخدَم تعليمة error_page لتحديد ما يجب أن يحدُث عند تلقّي رموز حالات معيَّنة. على الأرجح لن تُنفَّذ تعليمة error_page إذا كانت تعليمة try_filesمضبوطة، فهذه الأخيرة تتعامل مع كامل دورة حياة الطّلب.

فلنأخذ المثال التّاليّ:

root /var/www/main;

location / {
    error_page 404 /another/whoops.html;
}

location /another {
    root /var/www;
}

تستجيب الكتلة الأولى الّتي تقدّم ملفّات من المجلَّد var/www/main/ لجميع الطّلبات، ما عدا تلك الّتي تبدأ بanother/. إن لم يُعثَر على الملفّ المطلوب ضمن المجلَّد المذكور (رمز الحالة 404) فسيُعاد توجيه الطّلب إلى الملفّ another/whoops.html/ ممّا ينتُج عنه البحث عن كتلة موقع تتعامل مع الطّلب الجديد. يرسو البحث على كتلة الموقع الثّانيّة الّتي تُجيب بالملفّ var/www/another/whoops.html/.

يُساعد فهمُ الظّروف الّتي تؤثّر على Nginx وتجعله يبحث عن كتلة موقع جديدة تلبّي الطّلب على توقّع سلوك Nginx عند إنشاء طلبات.

خاتمة

يُسهّل فهمُ الإجراءات الّتي يتبعها Nginx في الاستجابة لطلبات العملاء كثيرًا من عمل مسؤول الموقع، فيمكنك معرفة كتلة الخادوم الّتي سيختارها Nginx للإجابة حسب كلّ طلب على حدة. كما ستكون لديك القدرة على معرفة كتلة الموقع الّتي سيختارها خادوم الويب اعتمادًا على معرّف المورد المذكور في الطّلب.

على العموم تُمكنّك معرفة الطّريقة الّتي يختار Nginx وفقها الكتل المختلفة من تتبّع السّيّاقات الّتي يطبّقها Nginx من أجل الإجابة على كلّ طلب.

ترجمة بتصرّف لمقال Understanding Nginx Server and Location Block Selection Algorithms.

يمكِن لـِ Nginx، أحد أكثر خواديم الويب انتشارًا؛ التّعاملُ بنجاح مع عملاء عدّة يتّصلون بالتّزامن، كما يُمكنه العمل بوصفه خادوم ويب، خادوم بريد أو وسيطًا عكسيًّا Reverse proxy.

سنتطرّق في هذا الدّليل إلى بعض كواليس الآليّة الّتي تحدّد كيف يتعامل Nginx مع طلبات العملاء Client requests. يُساعد فهمُ هذه الآليّة في معرفة كيف تعمل إعدادات الكتلة (Block configurations) في خادوم ويب Nginx وخصوصًا كتلتَيْ Server (الخادوم) وLocation (الموقع). كما أنّه يجعل من تعامل Nginx مع طلبات العملاء أكثر قابليّةً للتّوقّع والتخمين.

إعدادات كتلة Nginx

يقسّم Nginx إعداداتِ تقديم المحتوى إلى كُتل تنتظِم في بنية شجريّة Hierarchical. يبدأ Nginx عندما يتلقّى طلبًا إجراءاتِ تقرير كُتَل الإعداد الّتي يجب استخدامُها للتّعامل مع الطّلب. سنتحدّث في هذا الدّليل عن آليّة التّقرير هذه.

يتحدّث الجزء الأوّل من هذا الدّليل عن كتلة Server، أمّا الثّاني فيتناول كتلة Location.

تعرّف كتلة Server، وهي مجموعة فرعيّة من إعدادات Nginx، خادومًا افتراضيًّا يتعامل مع طلباتٍ من نوع محدَّد. يعرّف مدراء الخواديم عادةً كتلَ خادوم عدّة ثمّ يضبطونها للتّعامل مع الطّلبات حسب اسم النّطاق Domain name، أو المنفذ Port، أو عنوان IP الذي يأتي عبره الطّلب.

تقبع كتلة Location ضمن كتلة من نوع Server (كتلة خادوم)، وتُستخدَم لتعريف الكيفيّة الّتي سيتعامل بها خادوم ويب Nginx مع الطّلبات على موارد الخادوم والمعرّفات الكليّة لهذه الموارد Universal Resource Identifier, URI. يُمكن أن تُقسَّم مساحة المعرّفات الكليّة للموارد URIs بالطّريقة الّتي يراها المدير عن طريق استخدام كتل Location، فنموذج الكتل مرن للغاية.

كيف يقرّر Nginx كتلة Server الّتي ستتعامل مع الطّلب؟

يحتاج Nginx، ما دام يسمح بتعريف كُتَل Server عدّة تعمل على أنّها خواديم ويب افتراضيّة متفرّقة، يحتاج لوسيلة يعرف بها كتلة Server الّتي ستتولّى تلبيّة الطّلب.

يُعرّف خادوم ويب Nginx نظامَ فحص يُستخدَم للعثور على كتلة Server الأكثر مُطابقةً للطّلب. يهتم Nginx أثناء عمليّة الفحص بتعليمتَيْن Directives على مستوى كتلة الخادوم، وهما listen وserver_name.

1- تحليل تعليمة listen بحثًا عن تطابقات ممكنة

ينظُر Nginx أوّلًا إلى عنوان IP الطّلب ومنفَذه؛ ثمّ يبحث عن تطابق بين هاتين المعلومتيْن مع محتوى تعليمة listen في كلّ كتلة خادوم. يُنشئ Nginx إثر هذه الخطوة قائمةً بكُتل الخواديم الّتي يُمكن أن تلبّي الطّلب.

تعرّف تعليمة listen عنوان IP والمنفَذ الّذيْن ستُجيب كتلة الخادوم الطّلبات الآتيّة منهما. إذا لم تتضمّن كتلة الخادوم تعليمة listen فإنّ المعطيات 0.0.0.0:80 تُمنح للتّعليمة بشكل افتراضيّ (أو 0.0.0.0:8080 إذا كان مستخدم عاديّ غير المستخدم الجذر هو من يشغّل خادوم ويب Nginx). تسمح هذه المعطيات لكتلة الخادوم بالإجابة عن طلبات عبر المنفذ 80 على كلّ الواجهات Interfaces؛ إلّا أنّ المعطيات الافتراضيّة لا تمثّل ثقلًا كبيرًا في عمليّة اختيّار الخادوم.

يُمكن ضبطُ تعليمة listen:

• بذكر عنوان IP ومنفَذ.
• بذكر عنوان IP فقط؛ في هذه الحالة يُستخدم المنفذ الافتراضيّ 80.
• بذكر منفَذ فقط؛ في هذه الحالة تستجيب لأي طلب يأتي عبر هذا المنفذ على كلّ الواجهات.
• بتحديد مسار إلى مقبس يونكس Unix socket.

سيقتصر تأثير الخيّار الأخير - غالبًا - على الطّلبات الّتي تمرّر بين مجموعة خواديم.

يقرّر Nginx كتلة الخادوم الّتي سيُرسل إليها الطّلب اعتمادًا على خصوصيّة تعليمة listen وذلك وفقًا للقواعد التّاليّة:

• تُكمَّل الأجزاء غير المكتملة من تعليمة listen بالقيّم الافتراضيّة. الأمثلة التّاليّة توضّح كيف تُكمّل تعليمة listen:

  • كتلة خادوم لا توجد بها تعليمة listen ستستعمل القيمة 0.0.0.0:80.
  • كتلة خادوم مضبوطة على العنوان 111.111.111.111 ولا تعرّف منفذًا تستعمل القيمة 111.111.111.111:80.
  • كتلة خادوم مضبوطة على المنفذ 8888 دون عنوان IP، تستخدم القيمة 0.0.0.0:8888.

• يكوّن Nginx قائمة بكتل الخواديم الّتي تُطابق الطّلب، وبالتحديد عنوان IP والمنفذ. يعني هذا أنّ أيّة كتلة تستخدم عنوان 0.0.0.0 (مطابقة كلّ الواجهات) لن تُختار إن وُجدت كتلة تستخدم عناوين IP تُطابق الطّلب. في جميع الحالات يجب أن تُطابقَ الكتلة المنفذ بالضّبط.

• إذا وُجدت كتلة واحدة تُطابق الطّلب، ولم توجد أخرى بنفس المستوى من المُطابقة، فستُستخدَم للإجابة على الطّلب؛ أمّا إذا وُجدت عدّة كتل مع نفس المستوى من المطابقة فإنّ Nginx يبدأ بالنّظر في قيمة تعليمة server_name بالنّسبة لكلّ كتلة خادوم.

يجب الانتباه إلى أنّ Nginx لن ينظُر في قيمة تعليمة server_name إلّا إذا احتاج للتّفريق بين كتل خواديم لديها تعليمة listen بنفس المستوى من المطابقة للطّلب. على سبيل المثال؛ إذا كان example.com مُستضافًا على المنفذ 80 من 192.168.1.10 فـإنّ كتلة الخادوم الأولى فقط في المثال أدناه، هيّ من سيستجيب للطّلبات الموّجّهة إلى example.com، على الرّغم من أنّ تعليمة server_name في الكتلة الثّانيّة تحوي القيمة example.com.

server {
    listen 192.168.1.10;

    . . .

}

server {
    listen 80;
    server_name example.com;

    . . .

}

أمّا إذا وُجِدت أكثر من كتلة خادوم تُطابق بنفس المستوى من التّحديد الطّلب؛ فإنّ الخطوة التّاليّة هي فحص محتوى تعليمة server_name.

2- تحليل تعليمة server_name للاختيّار بين التّطابقات

الخطوة المواليّة، في حال وجود كتل خواديم عدّة بنفس المستوى من التّحديد توافق الطّلب، هي تحليل تعليمة server_name. يتحقّق Nginx من ترويسة Header في الطّلب تُسمّى Host (المستضيف). تحوي ترويسة Host اسم النّطاق أو عنوان IP الّذي يُريد العميل الوصول إليه.

يُحاول Nginx إيجاد كتلة الخادوم الأكثر مطابقةً لترويسة Host من بين كتل الخواديم المتبقيّة بعد تحليل تعليمة listen. يتبع Nginx الوصفة التّاليّة لإيجاد الكتلة المناسبة:

• يبحث خادوم الويب عن كتلة خادوم تكون قيمة تعليمة server_name مطابقةً تمامًا لترويسة Host الموجودة في الطّلب. إذا عثر على تعليمة server_name يتحقّق فيها الشّرط فإنّ الكتلة المرتبطة بها هي الّتي تُستخدَم. إذا كانت هناك عدّة تعليمات مطابقة فإنّ أوّل كتلة خادوم هيّ الّتي ستُختار.

• إن لم يعثُر على مطابقة تامّة يبحث Nginx عن كتلة خادوم تبدأ قيمة تعليمة server_name فيها بحرف بَدَل Wildcard (يُشار إليه بعلامة * في بداية الاسم) بحيث توافق التّعليمة ترويسة المستضيف في الطّلب. إذا عثر على تعليمة server_name يتحقّق فيها الشّرط فإنّ الكتلة المرتبطة بها هي الّتي تُستخدَم. أمّا إذا كانت هناك عدّة تعليمات فإنّ التّعليمة ذات التّطابق الأطول (عدد الأحرف) هيّ الّتي ستُختار.

• إن لم يُعثُر على مُطابقة باستخدام حرف بدل في بداية قيمة التّعليمة فإنّ Nginx يبحث عن تعليمة server_name تنتهي بحرف بدل (يُشار إليه بعلامة * في نهاية الاسم) بحيث توافق التّعليمة ترويسة المستضيف في الطّلب. إذا عثر على تعليمة server_name يتحقّق فيها الشّرط فإنّ الكتلة المرتبطة بها هي الّتي تُستخدَم. أمّا إذا كانت هناك عدّة تعليمات فإنّ التّعليمة ذات التّطابق الأطول (عدد الأحرف) هيّ الّتي ستُختار.

• إن لم يعثُر Nginx على مُطابقة باستخدام حرف بدل في نهاية قيمة التّعليمة فإنّه يبحث عن كتلة خادوم تعرّف تعليمة server_name عن طريق تعبير نمطيّ Regular expression (يُشار إليه بعلامة ~ قبل الاسم). يستخدِم Nginx أوّل كتلة خادوم يُوافق تعبير تعليمة server_name النّمطيّ فيها ترويسة المستضيف.

• إن لم يوجد تطابُق باستخدام التّعبير النّمطيّ يختار Nginx كتلة الخادوم الافتراضّية لعنوان IP والمنفَذ المستخدَم.

يوجد لكلّ ثنائيّ عنوان IP/منفذ كتلة خادوم مبدئيّة Default تُستخدَم إن لم تؤدِّ الآليّة الموصوفة أعلاه للعثور على كتلة خادوم. كتلة الثّنائيّ عنوان IP/منفذ المبدئيّة هيّ الكتلة الأولى في الإعداد أو تلك الّتي تحوي خيّار default_server ضمن تعليمة listen (يغلِب مفعول خيّار default_server، إذا كان موجودًا، مفعول الكتلة الأولى). لا يُمكن أن يوجد خيّار default_server في أكثر من مرّة بالنّسبة لكلّ عنوان IP/منفذ.

نشرح في الفقرة التّاليّة كلّ نقطة من آليّة العمل أعلاه.

3- أمثلة

إذا وجدت تعليمة server_name تُطابق تمامًا ترويسة المستضيف فسيقع على الكتلة المرتبطة بها الاختيّار للإجابة على الطّلب.

إذا كانت ترويسة Host الموجودة في الطّلب تحوي host1.example.com فإنّ الخادوم الثّاني في المثال أدناه هو الّذي سيقع عليه الاختيّار:

server {
    listen 80;
    server_name *.example.com;

    . . .

}

server {
    listen 80;
    server_name host1.example.com;

    . . .

}

إن لم يوجد تطابق كامل يبحثُ Nginx عن تعليمة server_name تبدأ بحرف بَدَل ويتحقّق من توافقها مع المستضيف في الطّلب. يختار خادوم الويب أطول قيمة في server_name من بين تلك الّتي تُطابق الطّلب.

في المثال التّالي يختار Nginx كتلة الخادوم الثّانيّة إذا كان العميل يطلُب المستضيف www.example.org:

server {
    listen 80;
    server_name www.example.*;

    . . .
}

server {
    listen 80;
    server_name *.example.org;

    . . .
}

server {
    listen 80;
    server_name *.org;

    . . .
}

ملحوظة: كلّ من الكتلة الثّانيّة والثّالثة توافق المستضيف في الطّلب (www.example.org)؛ إلّا أنّ قيمة server_name في الكتلة الثّانيّة أطول. تُقرأ قيمة الكتلة الثّانيّة في المثال أعلاه “جميع المستضيفات الّتي تنتهي بexample.org. أمّا الكتلة الثّالثّة فتقرأ قيمة server_name “جميع المستضيفات الّتي تنتهي بorg.. يُمكن ملاحظة أنّ قيمة server_name في كتلة الخادوم الثّانيّة أكثر تحديدًا.

إذا لم يجد Nginx كتلة الخادوم المناسبة في قيّم server_name الّتي تبدأ بحرف بدل، فإنّه يبحث في كتل الخادوم الّتي تنتهي قيّم server_name فيها بحرف بدل. مثل ما يحدُث في الحالة السّابقة، يختار خادوم الويب أطول قيمة في server_name من بين تلك الّتي تُطابق الطّلب.

إذا كان المستضيف المحدّد في الطّلب هو www.example.com فإنّ Nginx سيختار، في المثال التّالي، كتلة الخادوم الثّالثة.

server {
    listen 80;
    server_name host1.example.com;
    . . .
}

server {
    listen 80;
    server_name example.com;
    . . .
}

server {
    listen 80;
    server_name www.example.*;
    . . .
}

ملحوظة: تُقرأ قيمة server_name في كتلة الخادوم الثّالثة في المثال أعلاه “جميع المستضيفات الّتي تبدأ ب.www.example.

مجدّدًا، إذا لم يعثُر Nginx على تطابق باستخدام أحرف البدل في نهاية قيمة التّعليمة فإنّه سينتقل إلى محاولة مطابقة قيمة Host في ترويسة الطّلب بقيّم server_name المعرّفة بتعابير نمطيّة ويختار أوّل كتلة خادوم تُطابق فيها قيمة server_name قيمة Host.

إذا كانت قيمة Host هي www.example.com فإنّ Nginx سيختار، في المثال التّالي، كتلة الخادوم الثّالقة للإجابة على الطّلب:

server {
    listen 80;
    server_name example.com;

    . . .

}

server {
    listen 80;
    server_name ~^(www|host1).*\.example\.com$;

    . . .

}

server {
    listen 80;
    server_name ~^(subdomain|set|www|host1).*\.example\.com$;

    . . .

}

ملحوظة: يُقرأ التّعبير النّمطيّ أعلاه “يبدأ اسم المستضيف بإحدى الكلمات التّاليّة set، www، host1 أو subdomain؛ قد يتبعها حرف أو عدد غير محدّد من الحروف، ثمّ نقطة ثم كلمة example ثمّ نقطة ثمّ com.“. للمزيد حول التّعابير النّمطيّة راجع درس مقدمة في التعابير النمطية Regular Expressions.

إذا لم يتمكّن Nginx من العثور على أي تعليمة server_name مُطابقة لقيمة Host عبر الإجراءات السّابقة فإنّه يختار الخادوم المبدئي الموافق للثّنائي عنوان IP/المنفَذ الّذي أتى عليه الطّلب.

مقدِّمة

يُشكّل خادوم Nginx، السّريع والخفيف، بديلًا - في حالات عديدة - لخادوم Apache كثيرِ المُتطلّبات. كأيّ برنامج آخر، يحتاج Nginx إلى ضبطه من أجل الحصول على أداء أفضل.

مُتطلَّبات الدّرس

• خادوم ويب Nginx مثُبَّت ومُعَدّ للعمل.

• فهم أساسيّات التّعامل مع Linux.

ضبط متغيّرَيْ worker_processes و worker_connections

أوّل متغيِّريْن يجب علينا ضبطُهما هما متغيّرا worker_processes و worker_connections. يجب أن نفهم ما الّذي يتحكّم فيه كل واحد من هذيْن المتغيّريْن، قبل الدّخول في تفاصيل إعداد كلّ واحد منهما.

نبدأ بتعليمة worker_processes الّتي تُمثِّل العمود الفقري الصّلب بالنّسبة ل Nginx. تُعطي هذه التّعليمة عددَ العمليّات Processes الّتي يجب على Nginx إنشاؤُها بعد معرفته لعنوان IP والمنافِذ Ports الّتي سيشتغل عليها، وهيّ المسؤولة عن كل ما يُؤدّيه خادوم الويب. يُطلَق على كل واحدة من هذه العمليّات اسم Worker (العامِل). من المُستحسَن تشغيلُ عامل واحد على كل نواة Core من وحدة المُعالجة المركزيّة Central processing unit, CPU. لن ينتُج عن تشغيل أكثر من عامل على نواةٍ ضررٌ كبير على النِّظام لكنّه سيؤدّي إلى وجود العديد من العمليّات السّاكنة Idle processes غير الضّروريّة.

ملحوظة: عمليّة ساكنة هي عمليّة لا تجد ما تفعله ولا تتولّى الإجابة عن أيّ طلب.

يكفي، لمعرفة قيمة worker_processes الأمثل لإعدادك، إلقاءُ نظرة على عدد الأنويّة لديك. يُمكِنك عبر الأمر التّالي الحصول على هذه المعلومة:

grep processor /proc/cpuinfo | wc -l

فلنفترِض أنّ نتيجةَ تنفيذ الأمر هيّ 1. يعني هذا أنّه يوجد في النّظام لدينا نواةٌ واحدة.

المُتغيّر الثّاني worker_connections يُعطي عددَ الاتّصالات الّتي يُمكن لعمليّات من نوع Worker الاستجابة لها في نفس الوقت. القيمة الافتراضيّة هي 768.في العادة، يُرسِل متصفّح الويب طلبيْن - على الأقل - في نفس الوقت إلى الخادوم، وهو ما يعني أنّ عدد العملاء الّذين يُمكِن الرّد عليهم في نفس الوقت يبلغ في أعلى تقدير نصفَ قيمةِ المُتغيِّر worker_connections. من أجل الرّفع من عدد العُملاء المُتّصلين في آنٍ معًا سنُعطي لهذا المُتغيِّر أعلى قيمة تسمح بها موارد الجهاز، والّتي يُمكِن معرفتها عن طريق الأمر:

ulimit -n

ستتغيَّر النّتيجة حسب الجهاز والموارد المُتوفّرة له. نأخذ مثالًا بجهاز ذي إمكانيّات محدودة حيثُ تُساوي هذه القيمة 1024.

نُحدِّث إعدادات Nginx عبر فتح ملفّ الإعداد nginx.conf وتحريره:

sudo nano /etc/nginx/nginx.conf

نُعطي القيمة 1 لـ worker_processes والقيمة 1024 لـworker_connections:

worker_processes 1;
worker_connections 1024;

يجب الانتباه هنا إلى أنّ عدد الاتّصالات الكلّي الّتي يقبله Nginx في نفس الوقت يُساوي جداءَ قيمتَيْ المُتغيّريْن worker_processes و worker_connections. أي، في حال التزمنا بالقاعدة السّابقة، عددَ الأنويّة مضروبًا بعدد الاتّصالات الّتي يُمكن لكل عامِل الاستجابة لها. في مثالنا هنا النّتيجة هيّ 1024 (حاصل ضرب 1024 ب 1). يوجد أيضًا مُتغيِّر keepalive_timeout والّذي يُمكن لقيمته أن تُقلِّلَ من عدد الاتّصالات الفعليّة (سنتطرّق لهذا المتغيِّر).

الصُّّوَّانات Buffers

يُمكِن أن ينتُج عن تعديل حجم الصِّوان (وهي منطقة تخزين مُؤقّت ضمن ذاكرة الوصول العشوائي RAM، تُستخدم لنقل البيانات بين العمليّات) تغيّرات مُعتبرة في الأداء. إذا كان حجم الصِّوان صغيرًا فإن Nginx سيحتاج إلى إنشاء ملفّ تخزين مؤقَّت Temporary file ممّا يُؤدّي إلى كثرة القراءة والكِتابة من القرص الصّلب. توجد بعض التّعليمات الّتي نحتاج لفهمها قبل إجراء أيّ تعديل.

• client_body_buffer_size: حجم صِوان العميل Client (وحدة الحجم في كامل ملف الإعداد هيّ البايت Byte، يُشير حرف K إلى كيلوبايت KB) أي حجم الجسم Body في طلب Http أثناء إجراء POST. تُستخدَم إجراءات POST أساسًا عند إرسال النّماذج

• client_header_buffer_size: مُشابهة للتّعليمة السّابقة، ولكن لحجم التّرويسة Header في طلب Http. حجم 1KB مناسِب - غالبًا - لهذه التّعليمة.

• client_max_body_size: الحجم الأقصى المسموح به لطلب العميل. إذا تجاوز طلب العميل هذا الحجم فإن خادوم ويب Nginx سيُجيب بخطأ 413 (محتوى الطّلب أكبر من المسموح به Request Entity Too Large).

• large_client_header_buffers: العدد الأعلى والحجم الأقصى للصُّوّان بالنّسبة للتّرويسات العريضة في طلب العميل. في حال كان سطر الطّلب أكبر من حجم الصِّوّان فإن خادوم الويب يُجيب بخطأ 414 (مسار URI للطّلب أطول من المسموح به Request URI too large). نفس الشّيء بالنّسبة للتّرويسة في الطّلب إذ لا يجوز أن تتجاوز حجم الصِّوان المسموح به في هذه التّعليمة وإلاّ فإنّ Nginx سيُجيب بخطأ 400 (طلب غير صالح Bad request). يُشير العدد في هذه التّعليمة إلى العدد الأعلى من الطّلبات ذات التّرويسة العريضة (أي ترويسة بحجم أكبر من المُحدَّد في client_header_buffer_size) المسموح بها.

مثال على قِيّم للمتغيّرات السّابق ذكرها:

client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;

المُهَل Timeouts

المُهل هي مُتغيّرات أخرى تُوّثّر كثيرًا على أداء Nginx.

تُحدّد تعليمتَا client_body_timeout و client_header_timeout المهلة الزّمنيّة (بالثّانيّة) الّتي ينتظرها الخادوم لتلقي محتوى أو ترويسة العميل على التّوالي بعدَ استلام الطّلب منه. إن لم يتلقَّ الخادوم واحدًا من الاثنيْن خلال هذه الفترة فسيُجيب بخطأ 408 (انتهَت مُهلة الطّلب Request time out).

أمّا تعليمة keepalive_timeout فتُحدّد المهلة الزمنيّة لاتّصالات استمرار النّشاط Keep-alive connections. بعبارة أخرى، سيقطع Nginx الاتّصال بعد انقضاء هذه المُهلة بغض النّظر عمّا يُريد العميل.

توجد أيضًا send_timeout والّتي تُعنى بالفترة الزّمنية بين عمليّتَيْ قراءة من طرف العميل. إنْ لم يُرسِل العميل أيّ طلب خلال هذه المهلة فسيقطع خادوم الويب الاتّصالَ به، دون اعتبار لقيمة التّعليمة السّابقة.

مثال على قيّم لمتغيّرات المُهَل الزّمنيّة:

client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;

الضّغط Compression بواسطة Gzip

يُمكِن لأداة الضّغط وفكّ الضّغط Gzip المُساعدة في تحسين أداء خادوم الويب عبر التّقليل من حجم البيانات المُتبادلة؛ لكن ينبغي الحذر من رفع قيمة مستوى الضّغط gzip_comp_level لمستوى عالٍ إذ يُمكن أن يُسبّب ذلك كثرة نشاط أنويّة المُعالج.

لتفعيل الضّغط نُعطي القيمة on لتعليمة gzip. تعليمة gzip_min_length تُحدِّد الحجم الأدنى لتفعيل الضّغط، أي أنّ ملفًّا بحجم أقل من قيمة هذه التّعليمة لن يخضع للضّغط. يُمكِن تحديد صيّغ الملفّات الّتي يُطبَّق عليها الضّغط عبر التّعليمة gzip_type. توجد أيضًا تعليمة gzip_proxied لتعيين طريق التّعامل مع الطّلبات الواردة من عملاء يمرّون عبر وسيط Proxy.

gzip on;
gzip_comp_level 2;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/x-javascript text/xml text/css application/xml;

التّخزين المؤقت للملفات السّاكنة  Static File Caching

يُساهم طلب التّخزين المُوقّت من جانب العميل (المُتصفِّح) في التّقليل من تبادل البيانات والحفاظ على موارد الخادوم. يجب إدراج هذه التّعليمة على مُستوى كُتلة الخادوم Server block ضمن الملف الافتراضي لإعداد كُتلة خادوم Nginx، كما في المثال أدناه. عمل التّعليمة يتمثّل في إخبار العميل بالاحتفاظ بنسخة من الملفّ وعدم تنزيلها من الخادوم طوال مدّة محدّدَة (365 يومًا في المثال). إن احتاج العميل لأحد هذه الملفّات خلال هذه المدّة فسيلجأ للنّسخة الموجودة لديه ولن يتبادل بيانات مع الخادوم.

تُذكَر في التّعليمة أنواع الملفّات الّتي يُطلَب من العميل تخزينها (أساسًا صوّر وملفاّت تنسيق css وjs).

location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}

تعطيل حفظ السّجلّات Logging

يحتفظ Nginx في الإعددات الافتراضية بكلّ طلب يصل إلى الخادوم ضمن ملفّ للسّجلّات Logs. يُمكنك إيقاف هذه الخاصيّة إذا كنتَ تستخدِم أداةً لتحليل المواقع عن طريق إعطاء القيمة off للتّعليمة access_log كما هوّ موضَّح أدناه:

access_log off;

أعِد تشغيل خادوم الويب بعد حفظ ملفّ الإعداد حتى تُؤخذ التّعديلات في الحسبان:

sudo service nginx restart

خاتمة

خادوم ويب مضبوط جيّدًا هو خادوم مُعد ومُهيَّأ ليتصرّف حسب نوعيّة الطّلبات الّتي ترده. ينبغي الانتباه إلى أنّه لا توجد قيمة مُثلى لا ينبغي المساسُ بها لأيّ من المتغيّرات والتّعليمات المذكورة في هذا الدّليل. يجب ضبط الإعدادات حسب كلّ حالة وما يُناسبها.

إذا أردتَ الاستمرار في طريق التّحسين فيُمكنك تجربة التّوسّع الأفقي Horizontal scaling وتوزيع الحِمل Load balancing. الإعدادات المذكورة في هذا الدّليل ليست سوى بداية في الطّريق إلى تحسينات أكبر.

ترجمة – وبتصرّف – للمقال How To Optimize Nginx Configuration

ما هي موازنة الحمل (Load Balancing)

موازنة الحمل هي عبارة عن آلية لتوزيع التدفّق (traffic) على عدّة خواديم افتراضية خاصّة عبرَ تقسيم آلية المعالجة إلى عدّة أجهزة مما يضمن استقرارًا أفضل وتعاملًا أكثر سلاسة مع الأخطاء. خوارزمية Round Robin لموازنة الحمل ترسل الزوار إلى واحدٍ من مجموعة عناوين الـIP. تقوم خوارزمية Round Robin بشكلٍ أساسي بتوزيع حملِ الخادوم دون الحاجة إلى تضمين أي أمورٍ إضافية أخرى، آخذةً بعينِ الاعتبار بعض العوامل المهمة مثل سرعة استجابة الخادوم والمنطقة الجغرافية الخاصة بالزوار.

الإعداد

تتطلب الخطوات في هذا الدّرس وجود مستخدمٍ يمتلك صلاحيات الجذر على خادومك الافتراضي الخاص (VPS). يمكنك تعلم كيفية تثبيت واحد في دليل إدارة المستخدمين.

لكي تقوم بتثبيت موازنة الحمل الخاصة بـnginx فيجب بالطبع أن يكون nginx مثبتًا على خادومك الشخصي. يمكنك فعل ذلك بسرعة مع apt-get:

sudo apt-get install nginx

وحدة المنبع Upstream Module

بهدف تثبيت موازنة الحمل الخاصة بخوارزمية round robin, فإنّه يجب علينا استخدام وحدة المنبع (upstream module) الخاصة بـnginx. سنقوم بإدراج بعض التضبيطات في إعدادات nginx.

اذهب وافتح إعدادات موقعك (في مثالنا سنستخدم فقط إعدادات المضيف الوهمي الافتراضي):

sudo nano /etc/nginx/sites-available/default

سنحتاج إلى إضافة إعدادات موازنة الحمل إلى الملف. أولًا، سنحتاج إلى تضمين وحدة المنبع داخل الملف والتي تبدو هكذا:

upstream backend  {
  server backend1.example.com;
  server backend2.example.com;
  server backend3.example.com;
}

بعدها، يجب علينا الإشارة إلى الوحدة داخل الإعدادات بشكلٍ أوضح:

 server {
  location / {
    proxy_pass  http://backend;
  }
}

ثم لإعادة تشغيل nginx:

sudo service nginx restart

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

التوجيهات Directives

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

الوزن

من الطرق المستخدمة لبدء تخصيص المستخدمين إلى الخواديم بطريقة أكثر دقّةً هي تخصيص وزنٍ محدد لأجهزة محددة. Nginx يسمح لنا بإسناد رقمٍ يُحدد حجم التدفّق الذي يجب توجيهه إلى كلِّ خادوم.

يمكن لتثبيت حملٍ مُوازَن يتضمن وزن الخادوم أن يبدو هكذا:

upstream backend  {
  server backend1.example.com weight=1;
  server backend2.example.com weight=2;
  server backend3.example.com weight=4;
}

الوزن الافتراضي هو 1. مع وزنٍ بـ2 فإنَّ backend2.example سيتلقّى تدفّقًا أكبر بمرتين من backend1. بينما backend3 مع وزن 4 سيتعامل مع تدفّق أكبر بمرتين من التدفّق الذي يستقبله backend2 وأكبر بأربع مرات من التدفّق الذي يستقبله backend1.

التلّبيد (Hash)

تلّبيد عنوان الـIP يسمح للخواديم أن تستجيب للعملاء (clients) استنادًا إلى عناوين الـIP الخاصة بهم، حيث يتم إرسال الزوار مجددًا إلى نفس الخادوم الافتراضي الخاص في كلّ مرةٍ يزورون الموقع (باستثناء في حال كان الخادوم معطّلًا). إذا تم اكتشاف خادومٍ غير نشيط، فإنّه يتم تعليمه كخادومٍ معطّل. جميع عناوين الـIP التي كان من المفترض أن تقوم بالتوجيه إلى الخادوم المعطل ستقوم حينها تلقائيًا بالتوجيه إلى واحدٍ بديل.

الإعدادات التالية هي مثال على ذلك:

upstream backend {
  ip_hash;
  server   backend1.example.com;
  server   backend2.example.com;
  server   backend3.example.com  down;
 }

أقصى عدد لمرّات الفشل (Max Fails)

وفقَ إعدادات round robin الافتراضية، فإنّ nginx سيظلّ يرسل البيانات إلى الخواديم الوهمية الخاصّة، حتى لو كانت هذه الخواديم لا تستجيب. “العدد الأقصى لمرّات الفشل" يمكنه تلقائيًا أن يمنع حصولَ هذا عبر تعليم الخواديم التي لا تستجيب تلقائيًا بعد مرور وقتٍ معيّن.

هناك عاملان مرتبطان بالعدد الأقصى لمرّات الفشل: max_fails و fall_timeout. يشيرُ الأول إلى العدد الأقصى للمحاولات الفاشلة للاتصال بالخادوم التي يمكن عدّها قبل أن يتم تعليم الخادوم بأنّه غير نشيط. Fall_timeout يحدد طول المدة التي يتم اعتبار الخادوم فيها خارج العمل. بمجرد نفاذ الوقت، ستبدأ محاولات جديدة لإعادة الاتصال بالخادوم. القيمة الافتراضية لهذا المتغير هي 10 ثواني.

إعدادٌ بسيط سيبدو هكذا:

upstream backend  {
  server backend1.example.com max_fails=3  fail_timeout=15s;
  server backend2.example.com weight=2;
  server backend3.example.com weight=4;
}

كان هذا استعراضًا سريعًا لـ Round Robin load balancing. هناك عدّة طرق أخرى قد نتطرّق إليها لاحقًا في مقالات أخرى

ترجمة -وبتصرّف- للمقال: How To Set Up Nginx Load Balancing

لِمَاذا قد تودُّ تشغيل Nginx و Apache معًا

في الواقع يعتبر كلٌّ من nginx و apache عبارة عن خواديم ويب فعّالة للعمل. حاليًّا يحتل Apache المرتبة الأولى في مجال إدارة الخواديم منذ إطلاقه للعموم في 2006، nginx يصعد بقوة في شتّى أرجاء العالم وهو الآن يحتل المرتبة الثانية في خواديم الويب التي تدير المواقع النشطة. الأسباب وراء شعبية كلّ خادوم واضحة: قوة apache وسرعة nginx المعروفتان لدى الجميع. وعلى كلّ حال، فإن كلًّا من الخادومين يمتلكان نقاط ضعف – apache يستهلك الذاكرة بشراهة، بينما nginx -الذي يؤدي عملًا ممتازًا مع الملفات الثابتة(static files)- يحتاج مساعدة php-fpm أو وحدات مشابهة للتعامل مع المحتوى الديناميكي.

على كلّ حال، يمكن لأي شخص أن يدمج الخادومين للحصول على فعالية ممتازة، مع استخدام nginx كخادوم ويب للملفات الثابتة بالواجهة (front-end) و apache ليعالج العمليات بالخلفية (back-end).

التثبيت

لتطبيق الخطوات الموجودة في هذا الدّرس ستحتاج إلى امتلاك صلاحيات المستخدم الجذر root على خادومك الافتراضي الخاص.

لإنشاء مستخدم يمتلك صلاحيات الجذر، تابع الخطوتيّن الثالثة والرابعة من دليل تثبيت خادوم أوبونتو الشامل.

تثبيت nginx

لكي نبدأ العمل، سنحتاج إلى تثبيت وإعداد nginx الذي سيخدم واجهة موقعنا. يمكن تثبيته باستخدام apt-get عبر الأمر التالي:

sudo apt-get install nginx

بمجرد أن يتم التثبيت، يمكنك أن تبدأ بإعداد المضيف الوهمي (virtual host) لكي يتم تشغيله بواجهة الموقع.

هناك بضع تغييرات إضافية علينا عملها في الإعدادات.

إعداد nginx

افتح إعدادات nginx عن طريق الأمر:

sudo nano /etc/nginx/sites-available/example

الإعدادات التالية ستسمح لك باستخدام nginx كخادوم لواجهة الموقع. هذه الإعدادات مشابهة للإعدادات الافتراضية، تفاصيلها تجدها تحتها.

server {
        listen   80; 
        root /var/www/; 
        index index.php index.html index.htm;
        server_name example.com; 

        location / {
        try_files $uri $uri/ /index.php;
        }

        location ~ \.php$ {
        
        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $host;
        proxy_pass http://127.0.0.1:8080;

         }

         location ~ /\.ht {
                deny all;
        }
}

هذه هي التغييرات التي تم عملها على الإعدادات:

• مسار الجذر تم تغييره إلى مسار الويب الحالي.

• ملف index.php تم إضافته إلى سطر الفهرس.

• دالة try_files ستحاول القيام بتخديم الزوار مهما كانت الصفحات التي يطلبونها. إذا كان nginx غير قادرٍ على فعل ذلك، حينها يتم إرسال الملف إلى الوسيط (proxy).

• دالة proxy_pass تسمح لـ nginx أن يتعرف على مسار الخادوم الوسيط.

• "location ~ /\.ht {" تمنع الموقع من الوصول إلى جميع ملفات .htaccess إذا كان مسار الجذر الخاص بـ Apache يتعارض مع ذاك الخاص بـnginx.

هذه الإعدادات تقوم بإعداد نظامٍ صغير حيث يتم توجيه جميع الملفات التي نهايتها .php إلى خادوم apache ليعالجها بالخلفية والذي سيعمل على المنفذ 8080.

لتفعيل المضيف الوهمي:

sudo ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/example

بالإضافة إلى ذلك، علينا حذف إعداد nginx الافتراضي:

sudo rm /etc/nginx/sites-enabled/default

الخطوة التالية ستكون تثبيت وإعداد apache.

تثبيت Apache

بعد أنّ انتهينا من nginx، حان الوقت لتثبيت واجهة موقعنا الخلفية، apache:

sudo apt-get install apache2

بما أنه لم يتم تشغيل nginx بعد، فإنّ Apache سيعمل المنفذ 80.

إعداد Apache

سنحتاج إلى إعداد apache لجعله يدير الواجهة الخلفية لموقعنا، والذي كما قلنا سابقًا، سيعمل على المنفذ 8080. افتح ملف منافذ apache للبدأ في إعداده ليستخدم المنفذ الصحيح عبر الأمر:

sudo nano /etc/apache2/ports.conf

ابحث وغيّر السطور التّالية لجعل apache يعمل على المنفذ 8080 والقابل للوصول من المضيف المحلي (localhost) فقط:

NameVirtualHost 127.0.0.1:8080
Listen 127.0.0.1:8080

احفظ الملف واخرج.

بعد ذلك قمّ بإنشاء ملف مضيف وهمي عبر نسخ تخطيط الملف من ملف apache الافتراضي عبر الأمر:

sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/example
sudo nano /etc/apache2/sites-available/example

المشكلة الرئيسية التي يجب حلّها هنا هي أنه يجب أن يتم إعادة ضبط المضيف الوهمي مُجدّدًا لكي يعمل على المنفذ 8080 (عوضًا عن المنفذ الافتراضي الذي هو 80 والذي يعمل عليه nginx).

يجب أن يبدو السطر المطلوب هكذا:

<VirtualHost 127.0.0.1:8080>

تأكّد من أن مسار الجذر صحيح. احفظ الملف واخرج منه وقم بتفعيل المضيف الوهمي:

sudo a2ensite example

قبل البدء باختبار الأشياء، نحتاج إلى دعم apache بملحق php. ثبّته عبر الأمر:

sudo apt-get install php5

قم بإعادة تشغيل كلٍ من الخادومين للتأكد من عمل التغييرات:

sudo service apache2 restart
sudo service nginx restart

إنهاء العمليّة

لقد قمنا بإعداد خادومنا الشخصي الوهمي الخاص (VPS) ليتم تشغيل nginx في واجهة موقعنا وapache ليعالج الطلبات المتعلقة بـ php في الخلفية. الذهاب إلى نطاقنا الرئيسي (domain) الآن سيأخذنا إلى الصفحة الافتراضية لموقعنا.

يمكننا التحقق مما إذا كان يتم توجيه المعلومات إلى apache عبر تشغيل سكربت PHP شائع الاستخدام. اذهب وأنشء ملف php.info عبر:

sudo nano /var/www/info.php

والصق الشفرة التالية داخله:

<?
phpinfo( );
?>

احفظ الملف واخرج.

زيارة domain/info.php الخاص بك يجب أن يعرض لك شاشة معلومات php، وسيكون بمقدورك رؤية أنه قد تم معالجة الطلب بواسطة apache 

أخيرًا، يمكنك رؤية أيٍّ من المنافذ مفتوح وأيّ التطبيقات التي تعمل على كلّ واحدٍ منها عبر كتابة هذا الأمر:

sudo netstat -plunt

ترجمة -وبتصرّف- للمقال How To Configure Nginx as a Reverse Proxy for Apache لصاحبته Etel Sverdlov

Nginx عبارة عن مشروع مفتوح المصدر، له استخدامات مُختلفة قد يكون أهمها هو استخدامه كخادوم ويب. يُمكن اعتبار Nginx كمنافس قوي لخادوم apache رغم قُوة هذا الأخير. إليكم دليلا سريعا حول كيفية تنصيبه، إعداده واستخدامه كخادوم ويب محلي.

سأستعرض آلية تنصيب وإعداد nginx على نظام لينكس (توزيعة Archlinux) ويُمكنك تغيير مسارات الملفات لتتوافق مع مسارات الملفات على توزيعتك المُفضلة للوصول إلى نفس النتيجة.

بداية سنحتاج أولا إلى تنصيب nginx عبر الأمر التالي (وفي حال ما إذا كانت مشاريعك مكتوبة بلغة php فإنك ستحتاج أيضا إلى تنصيب php-fpm):

sudo pacman -S nginx php-fpm

على توزيعة ubuntu سيكون أمر التنصيب هو:

sudo apt-get install nginx php5-fpm

بعد الفراغ من التنصيب سنقوم بتفعيل الخادوم (وphp-fpm) وتشغيله بالأمرين التاليين:

sudo systemctl enable nginx php-fpm
sudo systemctl start nginx php-fpm

بعد قيامك بذلك ولو استعرضت عنوان localhost فستظهر لك صفحة تؤكد لك بأنه تم تنصيب الخادوم وتشغيله بنجاح.

الآن وبحكم أنك ستعمل على أكثر من مشروع ويب في آن واحد على جهازك المحلي سنقوم بإعداد الخادوم لتمكيننا من ذلك.

لنبدأ أولا بإلقاء نظرة على ملف nginx.conf الذي يتحكم في الخادوم. ستلاحظ الشفرة التالية المسؤولة عن إظهار صفحة البداية آنفة الذكر

server {
        listen       80;
        server_name  localhost;
        #charset koi8-r;
        #access_log  logs/host.access.log  main;
        location / {
            root   /usr/share/nginx/html;
            index  index.html index.htm;
        }

وكل ما نحتاجه هو إنشاء خادوم server جديد لكل مشروع تود العمل عليه، لكن ولإبقاء هذا الملف "نظيفا" ولتجنب حصول أية مشاكل بسبب تعديل غير مرغوب فيه سنقوم بإنشاء ملف مُنفصل لكل مشروع جديد.

اذهب إلى المُجلد الذي تم تنصيب nginx فيه (/etc/nginx/ ) وقم بإنشاء مُجلدي sites-available وsites-enabled إن لم يكونا موجودين من قبل.

لماذا سنحتاج إلى مُجلدين؟ سنضع في الأول المواقع (المشاريع) التي نعمل عليها و"سنضع" في الثاني المواقع (المشاريع) التي نود أن نقوم بتنفيذها. صحيح أن هذه الخُطوة قليلة أو ربما عديمة الفائدة على خادوم محلي، لكن من الأفضل أن تعود نفسك على ذلك قبل أن تقوم برفع مواقعك إلى خادوم فعلي.

سنقوم بإنشاء ملف إعدادات لكل مشروع جديد داخل مُجلد site-available ولنسمي كل ملف باسم المشروع متبوعا بـ .dev (يُمكنك تجاهل هذه اللاحقة إن أردت أو استخدام أي لاحقة أخرى) بعبارة أخرى لو كان المشروع الأول الذي نود أن نقوم بتشغيله عبر nginx هو myproject فسيكون اسم الملف هو myproject.dev

إليكم مثالا عن إعدادات phpmyadmin (بطبيعة الحال ستحتاج إلى تنصيبه أولا قبل أن تقوم بذلك):

server {
   listen 80;
   server_name phpmyadmin.dev;
   location / {
      root /usr/share/webapps/phpMyAdmin;
      index index.html index.htm index.php;
      try_files $uri $uri/ /index.php$is_args$args;
      autoindex on;
   }
   location ~ \.php$ {
      root /usr/share/webapps/phpMyAdmin;
      fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
      fastcgi_index index.php;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      include fastcgi_params;
   }
   #error_page 404 /404.html;
   # redirect server error pages to the static page /50x.html
   error_page 500 502 503 504 /50x.html;
   location = /50x.html {
      root /usr/share/nginx/html;
   }
}

في حال ما إذا كان مشروعك داخل مُجلد آخر فيكفي أن تغير قيمة root. لو كان مشروعك متواجدا داخل /srv/http/myproject فيكفي أن تغيير root لتصبح

root /usr/share/webapps/myproject;

ستحتاج أيضا إلى تغيير قيمة fastcgi_pass لتتوافق مع مسار php-fpm على نظامك، فلو كنت على توزيعة ubuntu مثلا فسيكون المسار unix:/var/run/php5-fpm.sock;

بطبيعة الحال يُمكنك إضافة، تعديل أو إزالة أية إعدادات أخرى حسب الحاجة كتفعيل أو تعديل مسار صفحة الخطأ error_page 404 أو تعطيل خاصية autoindex on; التي تسمح باستظهار مُحتوى المُجلدات التي لا تحتوي على ملفات index.

الآن وبعد أن أنشأنا على الأقل ملفي إعدادات (واحد للمشروع myproject وآخر لسكربت phpMyAdmin) سنحتاج أن نقوم بنقلهما إلى مُجلد sites-enabled، لكن لن نقوم بنسخهما بل يكفي أن نقوم بإنشاء رابط وهمي. بعبارة أخرى سنقوم بإنشاء رابط وهمي من مُجلد sites-enabled إلى ملفات الإعدادات الموجودة في مجلد sites-available وذلك على النحو التالي:

sudo ln -s /etc/nginx/sites-available/myproject.dev /etc/nginx/sites-enabled/myproject.dev
sudo ln -s /etc/nginx/sites-available/phpmyadmin.dev /etc/nginx/sites-enabled/phpmyadmin.dev

بقيت خُطوة أخيرة، وبحكم أننا سنتحكم في جميع مشاريعنا عبر ملفات فردية فإننا لن نحتاج بعد الآن إلى الإعدادات الموجودة في ملف nginx.conf. هذا من جهة، ومن جهة أخرى سنحتاج إلى تضمين هذه الملفات الفردية في الملف الرئيسي عبر الأمر:

include sites-enabled/*;

ليصبح الملف على النحو التالي:

#user html;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;

events {
   worker_connections 1024;
}
http {
   include mime.types;
   default_type application/octet-stream;
   #access_log logs/access.log main;
   sendfile on;
   #tcp_nopush on;
   #keepalive_timeout 0;
   keepalive_timeout 65;
   #gzip on;
   include sites-enabled/*;
}

الآن وبعد أن أنهينا إعداد ملفات الخواديم، سنحتاج إلى إعادة تشغيل nginx ليأخذ التغييرات في الحسبان عبر الأمر

sudo systemctl restart nginx

لكن كيف سنقوم باستعراض المشاريع على المُتصفح؟ بقيت خطوة أخيرة (ألم تقل في الخطوة السابقة أنها الخطوة الأخيرة؟؟:P) سنحتاج إلى تعديل ملف /etc/hosts وإضافة سطر لكل مشروع على النحو التالي:

127.0.0.1 myproject.dev localhost
127.0.0.1 phpmyadmin.dev localhost

الآن يكفي أن أكتب في خانة العناوين العنوان phpmyadmin.dev أو myproject.dev لأتمكن من استعراض المشروعين.

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

ملاحظة2: ستجد في الشفرات السابقة بعض الإعدادات المُعطلة (مسبوقة بمحرف #) تركت لتبيين بعض ما يُمكن إضافته للملف ابحث عن كل واحدة وفعلها حسب الحاجة.