البحث في الموقع

مقدمة تُعتبر خدمات تخزين البيانات المرنة والقابلة للتوسع حسب الحاجة، متطلب أساسي لأغلب التطبيقات والخدمات التي يتم تطويرها بالأدوات والتقنيات الحديثة. بغض النظر عن تخزين كميات قليلة أو كثيرة من الصور، الفيديوهات والنصوص الضخمة فإن مُطوري التطبيقات يحتاجون حلًا لتخزين واسترجاع المحتوى الخاص بالمستخدم، سجلات عمله، نسخه الاحتياطية وغيره من الأمور الأخرى. في ظل الأنظمة المنشورة المعقدة، وفي ظل الحاويات المختلفة والبيئات سريعة التغير والزوال، فإن زمن حفظ الملفات ببساطة في وحدة تخزين على خادوم واحد قد انتهى، حيث قام مزودو الخدمات السحابية بتطوير خدمات لتلبية حاجات التخزين في الأنظمة والتطبيقات الحديثة، وغالبًا تندرج خدمات التخزين السحابية تحت نوعين هما التخزين الكائني (Object Storage) والتخزين الكتلي (Block Storage). سنتناول هنا مميزات وسلبيات كل نوع. ما هو التخزين الكتلي؟ تعتبر خدمات التخزين الكتلي بسيطة ومألوفة نوعًا ما، حيث تُقدم هذه الخدمات خدمة التخزين العادية –كما في القرص الصلب– ولكن من خلال الشبكة. يقدم مزودو الخدمات السحابية الأدوات اللازمة التي تُتيح الحصول على جهاز تخزين كتلي بأي حجم وربطه بالآلة الافتراضية الخاصة بك، ومن هنا تستطيع التعامل مع الجهاز كقرص عادي، حيث تستطيع تهيئته، حفظ الملفات عليه، ربط أكثر من قرص بنظام RAID أو حتى إعداد قاعدة بيانات عليه للكتابة مباشرةً على الجهاز الكتلي. بالإضافة لما سبق، فإن أجهزة التخزين المرتبطة بشبكة غالبًا ما تتميز عن الأقراص الصلبة العادية بما يلي: تستطيع أخذ نسخة حية بسهولة للجهاز للأغراض الاحتياطية. من الممكن إعادة تغيير حجم جهاز التخزين الكتلي وتلبية الاحتياجات المتراكمة. تستطيع فك وربط الجهاز بين الآلات الوهمية بسهولة. ما ذكرناه من مميزات هي خصائص مرنة من الممكن أن تكون مفيدة غالبًا لأي تطبيق. فيما يلي نسرد بعضًا من مميزات وعيوب هذه التقنية. مميزات التخزين الكتلي: التخزين الكتلي شائع ومألوف، حيث أن المستخدمين والبرمجيات يفهمونه ويستطيعون التعامل مع ملفاته وأنظمته بشكل واسع. الأجهزة الكتلية مدعومة جيدًا. كل لغات البرمجة تستطيع قراءة وكتابة الملفات منها. صلاحيات وأذونات ملفات النظام في الأجهزة الكتلية مألوفة ومفهومة بشكل جيد. أجهزة التخزين الكتلي لديها وقت استجابة منخفض في عمليات الإدخال والإخراج، مما يجعلها مناسبة لقواعد البيانات. عيوب التخزين الكتلي: التخزين مرتبط بخادم واحد في نفس الوقت. تحتوي كتلة التخزين وملفات النظام على بيانات وصفية (metadata) قليلة عن المعلومات التي تُخزنها مثل تاريخ الإنشاء، المستخدم الذي تعود له البيانات وحجم هذه البيانات. أي معلومات إضافية عما تُخزنه وحدة التخزين الكتلي يجب أن يتم التعامل معها على مستوى التطبيق أو قاعدة البيانات مما يؤدي إلى زيادة الأعباء على المطور لمتابعة هذه المعلومات. يجب عليك أن تدفع مقابل حجم التخزين الذي حجزته حتى لو لم تقم بالاستفادة منه أو استخدامه. تستطيع أن تصل لخدمة التخزين الكتلي عبر خادومٍ واحد يعمل فقط. التخزين الكتلي يحتاج إلى اعدادات تنصيب وعمل أكثر (اختيار ملفات النظام، الأذونات، الإصدارات، النسخ الاحتياطية...وغيرها) مقارنة بالتخزين الكائني. بسبب سرعة عمليات الإدخال والإخراج في التخزين الكتلي ، فإنه يُعتبر خيارًا أفضل لتخزين البيانات في قواعد البيانات العادية. بالإضافة لذلك، فإن العديد من الأنظمة القديمة تتطلب وجود ملفات نظام عادية للتخزين مما يجعل التخزين الكتلي هو الحل في هذه الحالة. إذا لم يتوفر لدى مزود الخدمات السحابية خدمة التخزين الكتلي، تستطيع أن تقوم بتشغيل الخدمة الخاصة بك بنفسك باستخدام OpenStack Cinder، Ceph، أو خدمة iSCSI المُضمنة مع العديد من أجهزة NAS. ما هو التخزين الكائني؟ في عالم الحوسبة السحابية الحديث، يُعرف التخزين الكائني بأنه تخزين واسترجاع البيانات غير المُرتبة وفق بنية معينة (Unstructured) عبر استخدام الواجهة البرمجية ل HTTP. فبدلًا من تقسيم الملفات إلى كُتل متعددة وحفظها باستخدام نظام الملفات على وحدة التخزين، يتم التعامل مع الملفات ككائنات وتُحفظ على الشبكة. قد تكون هذه الكائنات عبارة عن صورة، سجلات، ملفات HTML أو أية كائنات ثنائية كبيرة بذاتها. تكون هذه الكائنات غير مرتبة وفق بنية معينة لأنها لا تحتاج لاتباع مُخطط أو تنسيق محدد. أصبح التخزين الكائني معروفًا بسبب قدرته الكبيرة على تبسيط تجربة المطور في بناء وتطوير خدمات التخزين، حيث تم تطوير مكتبات تدعم بناء الواجهات البرمجية (التي تحتوي طلبات (HTTP في أغلب لغات البرمجة. حفظ ملف ثنائي كبير أصبح أمرًا سهلًا باستخدام طلب HTTP PUT، وكذلك استرجاع الملف وبياناته الوصفية يتم عبر طلب GET عادي. علاوة على ذلك، فأغلب خدمات التخزين الكائني تستطيع مشاركة هذه الملفات مع المستخدمين الآخرين دون الحاجة لإعدادات خاصة على الخادم المُستضيف. بالإضافة لما سبق، لن تَدفع مقابل خدمة التخزين الكائني إلا مقابل المساحة التي تَستخدمها (بعض الخدمات تُدفع مقابل كل طلب HTTP أو حسب استهلاك النقل عبر النطاق) وهذا الأمر يُعد نعمةً لبعض المطورين الذين يحصلون على خدمة استضافة وتخزين عالمية مقابل تكلفة تتلاءم مع حجم الاستخدام. التخزين الكائني ليس الحل الجيد لكل الحالات. لنلقي نظرة على مميزات وعيوب هذه النوع. مميزات التخزين الكائني: واجهة برمجية بسيطة عبر HTTP تدعم أغلب المستخدمين بغض النظر عن نظام التشغيل المستخدم أو لغة البرمجة. تكلفة التخزين تُحدد مقابل ما يتم استخدامه من مساحة وليس ما يتم حجزه. لن تحتاج لحجز خادوم كامل للحصول على خدمة التخزين الكائني لملفاتك الساكنة. بعض مزودي خدمة التخزين الكائني تُقدم خاصية الدمج CDN المُضمنة، والتي تتيح تخبئة ملفاتك حتى يكون تنزيلها أسرع للمستخدمين. خاصية الأَصْدَرَة (Versioning) التي تتيح لك استرجاع النسخ القديمة من ملفاتك واستعادتها بعد التعديل عليها بشكل خاطئ. تتكيف خدمات التخزين الكائني مع احتياجات الاستخدام بدءًا من الاستخدام البسيط وحتى حالات الاستخدام المكثف دون أن يحتاج المطور لزيادة المصادر أو إعادة الهيكلة لمعالجة الحمل المطلوب. باستخدام خدمات التخزين الكائني لن تحتاج لمتابعة وإدارة وحدات التخزين أو أنظمة RAID لأنها من مسئولية مزود الخدمة. تستطيع حفظ بيانات وصفية بجانب البيانات الأصلية وذلك يُبسط لك هيكلة التطبيق الذي تعمل عليه. عيوب التخزين الكائني: لا تستطيع أن تستضيف قاعدة بيانات عادية على خدمة التخزين الكائني بسبب وقت الاستجابة العالي واللازم لقاعدة البيانات. باستخدام التخزين الكائني لا تستطيع التعديل على جزء من الكائن الذي تحفظه، حيث عليك قراءة أو كتابة الكائن كله في العملية الواحدة وهذا له آثار مترتبة على الأداء. فمثلًا، باستخدام نظام الملفات تستطيع بسهولة أن تُضيف سطر في نهاية ملف سجلات، ولكن في نظام التخزين الكائني يجب عليك قراءة الملف كاملا ثم التعديل عليه ثم إعادة كتابته وحفظه مرة أخرى، وهذا الأمر يجعل من التخزين الكائني خيارًا غير مثالي في حفظ البيانات التي تتغير بشكل مستمر. لا تستطع نُظم التشغيل تعيين كائن كمحرك أقراص بشكل سهل. يوجد بعض العملاء والمحولات التي تساعد في تنفيذ هذا الأمر، ولكن بشكل عام، استخدام الكائن وتصفحه ليس متاحًا بسهولة كما هو متاح لدى التنقل خلال المجلدات في نظام الملفات. بسبب هذه الخصائص، التخزين الكائني مفيد في استضافة الملفات الساكنة، حفظ محتوى المستخدم المتمثل مثلًا في الصور ولقطات الفيديو، حفظ ملفات النسخ الاحتياطي والسجلات. يوجد بعض حلول التخزين الكائني التي تتيح لك حفظ ملفاتك وبياناتك دون القلق على كيفية إدارة الأقراص أو خيارات التوسع. تستطيع مثلا أن تُجرب Minio، وهو خادوم مشهور مُطَوَّرْ باستخدام لغة Go ويقدم خدمة التخزين الكائني، أو تستطيع تجربة Ceph أو OpenStack Swift. خاتمة اختيار طريقة التخزين قد يكون قرارًا معقدًا للمطورين. ناقشنا مزايا وعيوب كلًا من التخزين الكتلي والتخزين الكائني. على الأرجح أن أي تطبيق معقد وذو كفاءة سيحتاج لاستخدام كلا النوعين في التخزين لتلبية كافة الاحتياجات اللازمة للعمل. ترجمة -وبتصرّف- للمقال Object Storage vs. Block Storage Services لصاحبه Brian Boucheron

تناول الجزء الأوّل من هذا الدّليل الخوارزميّة الّتي يتبعها خادوم ويب 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 يُمكن التّنبّؤ بعملها. على الرّغم من ذلك، يجب الانتباه إلى وجود حالات تتسبّب تعليمات داخل الكتلة المُختارة في البحث من جديد عن موقع. يُمكن لهذا الاستثناء من القاعدة العامّة “كتلة موقع واحدة فقط” أن يُحدِث تأثيرات على كيفيّة الإجابة على الطّلب، بحيث يُخالف التّوقّعات الّتي كانت عندك أثناء تصميم كتل المواقع. في ما يلي بعض التّعليمات الّتي قد تؤدّي إلى إعادة توجيه من داخل الكتلة المختارة: indextry_filesrewriteserror_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/المنفَذ الّذي أتى عليه الطّلب.