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

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

المتطلبات:

لإكمال هذا المقال بنجاح، ستحتاج إلى تجهيز بيئة العمل المكونة من:

• خادم أوبنتو 22.04 يحتوي على مستخدم غير جذري non-root user ذي صلاحيات sudo و مثبت عليه جدار حماية. يمكنك اعداده بالعودة إلى دليل إعداد الخادم الأولي

• تثبيت Nginx على خادمك. يمكنك الاستعانة بالمقال التالي لتثبيته على خادمك. أصبحت جاهزًا لبدء العمل بعد أن ثبّتَ Nginx على خادم أوبنتو 22.04.

فهم آلية عمل سجل الأخطاء Error_log

يستخدم خادم Nginx عدة سجلات للتحكم في سجلات النظام. ويسمى السجل المستخدم في الوحدة الأساسية بسجل الأخطاء أو Error_log

صياغة سجل الأخطاء Error_log

يُستخدم سجل الأخطاء Error_log لتسجيل رسائل الخطأ العادية. إن استخدمت خادم أباتشي Apache ستجد أن هذا السجل مشابه لسجل أخطاء أباتشي ErrorLog. يعتمد سجل الأخطاء Error_log على الصياغة التالية:

/etc/nginx/nginx.conf
error_log log_file log_level

يحدد log_file الملف الذي ستُحفظ فيه السجلات، أما log_level فيحدد أدنى مستوى تسجيل ترغب في تسجيله.

مستويات التسجيل

يمكن ضبط سجل الأخطاء Error_log لتسجيل معلومات وفق ما تحتاجه. أما مستوى التسجيل فهو أحد المستويات التالية:

• emerg: يظهر في حالات الطوارئ حيث يكون النظام في حالة غير مستقرة
• alert: يظهر في المواقف الخطيرة التي تتطلب اتخاذ إجراء فورًا
• crit: يظهر عند حدوث المشاكل المهمة التي تحتاج إلى معالجة
• error: يظهر عند حدوث خطأ ما وفشل عملية ما
• warn: يظهر عند حدوث أمر غير مألوف، لكنه لا يدعو للقلق
• notice: يظهر عند حدوث أمر عادي، لكن يجب التنبيه عليه
• info: رسالة توضيحية
• debug: معلومات عن تصحيح الأخطاء تفيد في تحديد مكان حدوث المشكلة

تعتبر المستويات الأعلى في القائمة السابقة ذات أولوية أعلى، فإذا حددت مستوىً ما، فإن السجل سيلتقط هذا المستوى، والمستويات الأعلى منه. على سبيل المثال، إذا حددت المستوى error فإن السجل سوف يجلب الرسائل التالية errorو crit و alert و emerg، وتجد مثالًا على هذا السجل في ملف الإعدادات الرئيسي.استخدم محرر النصوص الذي تفضله للوصول إلى ملف الإعدادات التالي، سوف نستخدم في مثالنا محرر النصوص نانو nano:

sudo nano /etc/nginx/nginx.conf

اذهب إلى أسفل الملف، إلى قسم إعدادات التسجيل Logging Settings # ولاحظ السجلات التالية:

/etc/nginx/nginx.conf
. . .
##
# Logging Settings
##

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
. . .

إن أردت بأن لا يسجل error_log شيئًا، فعليك إرسال خرجه إلى /dev/null:

. . .
/etc/nginx/nginx.conf
error_log /dev/null crit;
. . .

أما سجل access_log فسوف نناقشه في فقرة تالية.

فهم آلية عمل سجل HttpLogModule

يُعد سجل error_log جزءًا من الوحدة الأساسية core module، أما سجل access_log فيُعد جزءًا من وحدة HttpLogModule التي تزودنا بإمكانية تخصيص السجلات. كما توجد بضع سجلات أخرى في هذه الوحدة تساعد في إعداد السجلات المخصصة custom logs.

سجل log_format

يُستخدم سجل log_format لوصف التنسيق المستخدم في السجلات باستخدام النص العادي والمتغيرات. ثمة تنسيق جاهز يأتي مع Nginx ويسمى التنسيق المدمج combined، وهو تنسيق شائع مُستَخدم في عدة خوادم. إليك مثالًا على التنسيق المدمج إن لم يكن مُعَّرفًا مسبقًا واضطررت إلى تعريفه مع سجل log_format:

/etc/nginx/nginx.conf
log_format combined '$remote_addr - $remote_user [$time_local]  '
            '"$request" $status $body_bytes_sent '
            '"$http_referer" "$http_user_agent"';

لاحظ أن التعريف يتضمن عدة أسطر وينتهي عند الفاصلة المنقوطة (;). أما الأسطر التي تبدأ بالعلامة ($) فهي تعبر عن المتغيرات، وتُفسَر المحارف التالية - ، [ ، ] حرفيًا. أما الصياغة العامة للسجل فهي كالتالي:

/etc/nginx/nginx.conf
log_format format_name string_describing_formatting;

يمكنك استخدام المتغيرات التي تدعمها الوحدة الأساسية وذلك لصياغة سلاسل تسجيل logging strings خاصة.

فهم آلية عمل سجل access_log

يستخدم سجل access_log صياغة مشابهة لصياغة سجل الأخطاء Error_log، لكنه أكثر مرونة، ولذلك يستخدم لضبط التسجيل المخصص Custom logging. الصياغة العامة لسجل access_log هي كالتالي:

/etc/nginx/nginx.conf
access_log /path/to/log/location [ format_of_log buffer_size ];

إن القيمة الافتراضية لسجل access_log هي التنسيق المدمج combined الذي تحدثنا عنه سابقًا في سجل log_format، لكن يمكنك استخدام أي تنسيق معَرَّف في سجل log_format. قمة المخزّن المؤقت Buffer هي الحجم الأعظمي للبيانات التي يحتفظ بها خادم Nginx قبل أن ينقلها إلى السجل. ويمكنك أن تضغط حجم ملف السجل بواسطة إضافة المحدد gzip ضمن تعريف السجل، كما يلي:

/etc/nginx/nginx.conf
access_log /path/to/log/location format_of_log gzip;

وبخلاف سجل الأخطاء Error_log، إن لم تُرِد التسجيل فبإمكانك إلغاؤه من ملف الإعدادات كالتالي، ولا حاجة لإرساله إلى /dev/null:

/etc/nginx/nginx.conf
. . .
##
# Logging Settings
##

access_log off;
error_log /var/log/nginx/error.log;

. . .

تدوير السجلات

مع ازدياد ملفات السجل، يصبح من الضروري إدارة آليات التسجيل لتجنب امتلاء مساحة القرص، وتدوير السجلات Log rotation هي عملية تبديل ملفات السجل وأرشفة الملفات القديمة لمدة زمنية محددة.

لا يوفر Nginx أدوات لإدارة ملفات السجلات، لكنه يحتوي على آليات للمساعدة في تدوير السجلات.

تدوير السجلات يدويًا

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

mv /path/to/access.log /path/to/access.log.0

إن الأمر الذي يدوّر ملفات السجل هو التالي

kill -USR1 `cat /var/run/nginx.pid`

لا ينهي هذا الأمر عمليات خادم Nginx، لكنه يرسل لها إشارةً لتعيد تحميل ملفات السجل. سيؤدي هذا إلى تسجيل الطلبات الجديدة في ملف السجل المحدَّث:

kill -USR1 `cat /var/run/nginx.pid`

يخزّن خادم Nginx معرف العملية الرئيسة PID في الملف /var/run/nginx.pid الموجود أعلى ملف الإعدادات /etc/nginx/nginx.conf في السطر الذي يبدأ بكلمة pid:

sudo nano /etc/nginx/nginx.conf

/etc/nginx/nginx.conf
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
...

بعد تدوير السجلات، نفّذ الأمر sleep 1 كي تكتمل عملية النقل. كما يمكنك بعدها أن تضغط الملفات القديمة في ملف بصيغة .zip أو أن تجري العملية التي ترغب بها:

sleep 1
[ post-rotation processing of old log file ]

تدوير السجلات باستخدام برنامج logrotate

يُستخدم برنامج logrotate لتدوير السجلات، وهو برنامج يُنَزّل تلقائيًا على نظام أوبنتو، كما يوجد سكربت مخصص لبرنامج logrotate على خادم nginx العامل بنظام أوبنتو. استخدم محرر النصوص الذي تفضله للوصول إلى ملف الإعدادات التالي، سوف نستخدم في مثالنا محرر النصوص nano :

sudo nano /etc/logrotate.d/nginx

عليك تذكر أن السطر الأول من الملف يحدد الموقع الذي ستُطَبق فيه أوامر الأسطر اللاحقة، إن غيّرت موقع تسجيل الملفات في ملف إعدادات Nginx، أما بقية الملف فيُشير إلى أن السجلات ستُدَور يوميًا وسيُحتَفظ ب 52 سجل قديم. لاحظ أن قسم postrotate يحتوي على أمر مشابه لآليات التدوير اليدوية التي طبقناها سابقًا:

/etc/logrotate.d/nginx
. . .
postrotate
    [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
endscript
. . .

يوجه القسم السابق Nginx إلى إعادة تحميل ملفات السجل عند اكتمال التدوير.

خاتمة

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

ترجمة -وبتصرف- للمقال How To Configure Logging and Log Rotation in Nginx on an Ubuntu VPS لكاتبه Justin Ellingwood.

اقرأ أيضًا

• كيف تستعرض وتدير سجلات لينكس على أوبنتو وCentOS
• إدارة الحزم، أتمتة المهامّ ومراقبة السّجلات في Red Hat Enterprise Linux
• تثبيت وضبط خادم Nginx
• تثبيت خادم ويب Caddy على أوبنتو 16.04
• دليل إعداد خادم ويب محلي خطوة بخطوة

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

ستثبت وتضبط في هذه المقالة بعض المكونات على أوبنتو 18.04 لدعم وخدمة تطبيقات جانغو، وتجهّز قاعدة بيانات PostgreSQL بدلًا من قاعدة بيانات SQLite الافتراضية. بعد ذلك، ستضبط خادم تطبيقات غوني كورن للربط مع تطبيقاتك، ثم في الختام ستجهز إنجن إكس ليعمل مثل خادم وكيل لغوني كورن مما يعطيك وصولًا إلى مزاياه الأمنية ومزايا الأداء الخاصة التي يتصف بها لخدمة تطبيقاتك.

المتطلبات الأساسية

ستحتاج قبل المتابعة في هذه المقالة إلى خادم أوبنتو 18.04 مُعد وجاهز وإلى مستخدم غير جذر يتمتع بصلاحيات "sudo" مهيأة وإلى جدار ناري مُفعّل. راجع دليل إعداد خادم أوبنتو 18.04 مبدئي للبدء.

الخطوة الأولى - تثبيت الحزم البرمجية من مستودعات أوبنتو

ابدأ بتنزيل وتثبيت جميع العناصر التي تحتاجها من مستودعات أوبنتو. استخدم مدير حزم بايثون pip لتثبيت مكونات إضافية لاحقة.

حدّث في البداية دليل الحزم apt المحلي:

$ sudo apt update

ثم ثبّت الحزم بحسب إصدار بايثون الذي يستخدمه مشروعك، فإذا كنت تستخدم جانغو مع بايثون 3 فنفذ الأمر التالي:

$ sudo apt install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx curl

ننبه إلى أن جانغو 1.11 هو آخر إصدار من جانغو يدعم بايثون 2. لذلك، إذا كنت ستتفتح مشاريع جديدة، فننصحك باختيار بايثون 3، لكن إذا كنت ما تزال تريد استخدام بايثون 2 فنفّذ الأمر التالي:

$ sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl

سيثبت هذا pip وملفات تطوير بايثون اللازمة لبناء غوني كورن لاحقًا، وسيثبت أيضًا نظام قواعد بيانات Postgres والمكتبات اللازمة للتفاعل معها وخادم الويب إنجن إكس.

الخطوة الثانية - إنشاء قاعدة بيانات PostgreSQL ومستخدم لها

ستنشئ في هذه الخطوة قاعدة بيانات مع مستخدم قاعدة بيانات لتطبيق جانغو الخاص بك مع PostgreSQL -أو اختصارًا Postgres.

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

أُنشئ أثناء تثبيتك لنظام Postgres مستخدم نظام تشغيل اسمه "postgres" ليكون نظيرًا للمستخدم الإداري لنظام PostgreSQL الذي اسمه "postgres"، إذ ستحتاج لحساب هذا المستخدم لإنجاز المهام الإدارية. سجل الدخول إلى جلسة Postgres تفاعلية باستخدام sudo ومرّر اسم المستخدم مستعملًا الخيار u-:

$ sudo -u postgres psql

سيظهر لك محث PostgreSQL، إذ يمكنك إعداد متطلباتك. أنشئ أولًا قاعدة بيانات لمشروعك:

postgres=# CREATE DATABASE myproject;

ملاحظة: يجب أن تنتهي كل تعليمة Postgres بفاصلة منقوطة، لذا تأكد من أنك طبقت هذه القاعدة إذا واجهت أي مشاكل.

أنشئ مستخدم قاعدة بيانات مشروعك واختر كلمة مرور قوية:

postgres=# CREATE USER myprojectuser WITH PASSWORD 'password';

وسيكون الخرج على النحو التالي:

CREATE ROLE

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

بدايةً اضبط قيمة الترميز الافتراضي default encoding إلى "UTF-8" التي يتوقعها جانغو:

postgres=# ALTER ROLE myprojectuser SET client_encoding TO 'utf8';

وسيكون الخرج على النحو التالي:

ALTER ROLE

ثم حدّد مخطط عزل الإجراءات الافتراضي بالقيمة "read committed" لمنع عمليات القراءة من المعاملات التي لم تودع بعد uncommitted:

postgres=# ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';

وسيكون الخرج على النحو التالي:

ALTER ROLE

نظرًا لأن مشاريع جانغو ستُضبط على استخدام النطاق الزمني "UTC" افتراضيًّا، لذا حدد النطاق الزمني المناسب:

postgres=# ALTER ROLE myprojectuser SET timezone TO 'UTC';

وسيكون الخرج على النحو التالي:

ALTER ROLE

كل هذه طبعًا توصيات من مشروع جانغو.

الآن، اِمنح مستخدمك الجديد وصولًا إلى قاعدة بياناتك الجديدة ليتمكن من إدارتها:

postgres=# GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

وسيكون الخرج على النحو التالي:

GRANT

وبعد أن تنتهي، غادر محث PostgreSQL بتنفيذ الأمر التالي:

postgres=# \q

وبهذا يكون POstgreSQL الآن معدًّا بنجاح بحيث يمكن لجانغو الاتصال بمعلومات قاعدة البيانات وإدارتها.

الخطوة الثالثة - إنشاء بيئة بايثون افتراضية لمشروعك

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

ستحتاج لإنجاز ذلك إلى وصول إلى الأمر virtualenv الذي ينشئ البيئات الافتراضية. ابدأ بتثبيت هذا الأمر مستخدمًا pip، وإذا كنت تستخدم بايثون 3 فلا بُد من ترقية pip:

$ sudo -H pip3 install --upgrade pip

ثم ثبّت الحزمة:

$ sudo -H pip3 install virtualenv

إذا كنت تستخدم بايثون 2 فلا بُد من ترقية pip:

$ sudo -H pip install --upgrade pip

ثم ثبّت الحزمة:

$ sudo -H pip install virtualenv

مع تثبيت virtualenv، يمكنك البدء في تشكيل مشروعك. أنشئ أولًا المجلد الذي ستحفظ فيه ملفات مشروعك. سنسميه نحن هنا "myprojectdir" ويمكنك تسميته ما تشاء.

$ mkdir ~/myprojectdir

ثم انتقل إلى داخل المجلد:

$ cd ~/myprojectdir

ثم أنشئ بيئة بايثون الافتراضية داخل مجلد المشروع:

$ virtualenv myprojectenv

سينشئ هذا مجلدًا اسمه "myprojectenv" ضمن مجلد "myprojectdir"، وسيثبت داخله نسخةً محليةً من بايثون ونسخةً محليةً من pip. يمكنك استخدام هذا لتثبيت وضبط بيئة بايثون تعزل مشروعك عن بقية المشاريع.

لكن قبل تثبيت متطلبات بايثون لمشروعك ستحتاج إلى تفعيل البيئة الافتراضية:

$ source myprojectenv/bin/activate

يجب أن يتغير المحث الآن ليشير إلى أنك الآن تعمل ضمن بيئة بايثون افتراضية. سيبدو هذا مشابهًا لما يلي:

(myprojectenv)user@host:~/myprojectdir$

وهكذا بعد أن أصبحت بيئتك الافتراضية فعالة، ثبّت جانغو وغوني كورن وموائم PostgreSQL adaptor، اسمه psycopg2 بالنسخة المحلية من pip:

pip install django gunicorn psycopg2-binary

ملاحظة::عندما تُفعّل البيئة الافتراضية، أي عندما يُسبق المحث باسم المجلد "(myprojectenv)"، استخدم pip بدلًا من pip3 حتى لو كنت تستخدم بايثون 3. تُسمى نسخة الأداة للبيئة الافتراضية دائمًا باسم "pip"، بغض النظر عن نسخة بايثون.

الآن أصبح لديك كل البرمجيات اللازمة للبدء في مشروع جانغو.

الخطوة الرابعة - إنشاء وضبط مشروع جانغو جديد

بعد أن ثُبّتت مكونات بايثون، أصبح بإمكانك إنشاء ملفات مشروع جانغو الفعلية، وبما أن مجلد المشروع أصبح جاهزًا فيمكنك أن تطلب من جانغو أن يثبت الملف هنا، إذ سينشئ عندئذٍ مجلدًا في المستوى الثاني مع الشيفرة الفعلية وهذا أمرٌ طبيعي وسيضع سكريبت إدارة في هذا المجلد؛ وهذا مهمٌّ أنك تعرّف المجلد صراحةً بدلًا من السماح لجانغو باتخاذ قرارات متعلقة بمجلدك الحالي:

(myprojectenv) $ django-admin.py startproject myproject ~/myprojectdir

في هذه النقطة ستكون محتويات مجلد المشروع (في حالتنا هو "myprojectdir/~") هي:

• "myprojectdir/manage.py/~": سكريبت إدارة مشروع جانغو.
• "/myprojectdir/myproject/~": حزمة مشروع جانغو. سيحتوي هذا على الملفات: "init__.py__" و "settings.py" و "urls.py" و "wsgi.py".
• "/myprojectdir/myprojectenv/~": مجلد البيئة الافتراضية الذي أنشأته من قبل.

تتمثل المرحلة التالية في ضبط الإعدادات لملفات المشروع الجديدة. افتح ملف الإعدادات بمحرر النصوص المفضل لديك. سنستخدم نحن محرر النصوص نانو nano:

(myprojectenv) $ nano ~/myprojectdir/myproject/settings.py

اعثر أولًا على الموجّه ALLOWED_HOSTS الذي يعرّف قائمةً بعناوين الخوادم، أو أسماء النطاقات التي ستُستخدمُ للاتصال بنسخة جانغو، وسيظهر استثناء exception إذا وردت أي طلبات قادمة تحتوي على ترويسة Host غير مذكورة ضمن القائمة، ولذا يشدّد جانغو على تحديد هذا تفاديًا لصنف معين من الثغرات الأمنية.

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

. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']

ملاحظة: تأكد من تضمين "localhost" ضمن الخيارات، لأنك ستحيلُ proxying الاتصالات من خلال نسخة إنجن إكس محلية.

ثم أوجد القسمَ الذي يضبط الوصول إلى قاعدة البيانات، وهو يبدأ بالكلمة DATABASES.الضبط الموجود مسبقًا في الملف هو لقاعدة بيانات SQLite، ولكن نظرًا لأنك أنشأت قاعدة بيانات PostgreSQL لمشروعك فلا بُد من ضبط هذه الإعدادات.

حدّث الإعدادات بمعلومات قاعدة بيانات PostgreSQL، ثم أخبر جانغو أن يستخدم الملائم psycopg2 الذي ثبتته باستخدام pip. تحتاج أيضًا إلى التزويد باسم قاعدة البيانات واسم المستخدم لمستخدم قاعدة البيانات الذي أنشأته توًّا وكلمة المرور لمستخدم قاعدة البيانات والتحديد أيضًا بإمكانية العثور على قاعدة البيانات على الحاسوب المحلي، أما الإعداد PORT فيمكنك تركه سلسلةً فارغة:

. . .

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'myproject',
        'USER': 'myprojectuser',
        'PASSWORD': 'password',
        'HOST': 'localhost',
        'PORT': '',
    }
}

. . .

ثم اذهب إلى نهاية الملف وأضف إعدادًا يشير إلى المكان الذي ينبغي أن توضع فيه الملفات الساكنة؛ وهذا ضروري ليتمكن إنجن إكس من معالجة الطلبات لتلك العناصر. يخبر السطر التالي جانغو أن يضع تلك الملفات الساكنة في مجلدٍ اسمه "static" في مجلد المشروع الأساسي:

. . .

STATIC_URL = '/static/'
import os
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

احفظ الملف ثم أغلقه عندما تنتهي، وإذا كنت تستخدم محرر النصوص نانو يمكنك فعل ذلك بالضغط على المفتاحين "CTRL + X"، ثم المفتاح "Y و "ENTER".

الخطوة الخامسة - إكمال الإعداد المبدئي للمشروع

ستكون الخطوة التالية تهجير مخطط قاعدة البيانات المبدئي إلى قاعدة بيانات PostgreSQL باستخدام سكريبت الإدارة التالي:

(myprojectenv) $ ~/myprojectdir/manage.py makemigrations
(myprojectenv) $ ~/myprojectdir/manage.py migrate

أنشئ مستخدمًا إداريًّا للمشروع:

(myprojectenv) $ ~/myprojectdir/manage.py createsuperuser

سيطلب منك اسم مستخدم وبريد إلكتروني وكلمة مرور مع تأكيدها.

اجمع كل المحتوى الساكن في موقع المجلد الذي ضبطته بتنفيذ الأمر التالي:

(myprojectenv) $ ~/myprojectdir/manage.py collectstatic

عندئذ ستوضع الملفات الساكنة في مجلد اسمه "static" ضمن مجلد المشروع.

إذا اتبعت دليل إعداد الخادم المبدئي فيفترض أن لديك جدار ناري UFW يحمي خادمك، ولكي تختبر خادم التطوير، ينبغي عليك السماح بالوصول إلى المنفذ الذي ستستخدمه. في هذه الحالة أنشئ استثناءً للمنفذ "8000":

(myprojectenv) $ sudo ufw allow 8000

أخيرًا افحص مشروعك بتشغيل خادم تطوير جانغو من خلال الأمر التالي:

(myprojectenv) $ ~/myprojectdir/manage.py runserver 0.0.0.0:8000

في متصفح الويب استعرض اسم نطاق الخادم أو عنوان IP متبوعًا برقم المنفذ "8000:"، كما يلي:

http://server_domain_or_IP:8000

عندئذ ستظهر لك الصفحة التالية وهي صفحة دليل جانغو الافتراضية:

إذا ألحقت "admin/" بنهاية عنوان URL في شريط العنوان، فسيُطلب منك اسم المستخدم وكلمة المرور الذين أنشأتهما بالأمر createsuperuser:

يمكنك بعد الاستيثاق الوصول إلى واجهة جانغو الإدارية الافتراضية:

بعد الانتهاء من استكشاف الواجهة الظاهرة أمامك، اضغط على المفتاحين "CTRL + C" في نافذة الطرفية لإيقاف تشغيل خادم التطوير.

الخطوة السادسة - اختبار قدرة غوني كورن على خدمة المشروع

اختبر الخادم غوني كورن قبل مغادرة البيئة الافتراضية للتأكد من أن بإمكانه أن يخدم التطبيق، وذلك من خلال الانتقال أولًا إلى داخل مجلد مشروعك:

(myprojectenv) $ cd ~/myprojectdir

ثم شغّل gunicorn ليحمّل وحدة WSGI للمشروع:

(myprojectenv) $ gunicorn --bind 0.0.0.0:8000 myproject.wsgi

سيشغل هذا الأمر خادم غوني كورن على نفس الواجهة التي كان يعمل عليها خادم تطوير جانغو. يمكنك العودة واختبار التطبيق مجددًا.

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

لنلخص ما أنُجز، فقد مرّرتَ وحدةً إلى الخادم غوني كورن بتحديد مسار المجلد النسبي إلى ملف جانغو المسمى "wsgi.py" والذي يمثّل نقطة الدخول إلى تطبيقك باستخدام بنية وحدة بايثون. يُستخدم الخادم غوني كورن مثل واجهة لتطبيقك ويترجم طلبات العملاء من نوع HTTP إلى استدعاءات بايثون يمكن لتطبيقك معالجتها. أما داخل هذا الملف، فقد عُرّفت دالة application، التي تُستخدم للتواصل مع تطبيقك. وبإمكانك معرفة المزيد عن مواصفات WSGI إذا كنت مهتمًا بهذا الموضوع.

بعد أن تفرغ من الاختبار، اضغط على المفتاحين "CTRL + C" في نافذة الطرفية لإيقاف تشغيل الخادم غوني كورن، وبهذا تكون انتهيت من ضبط تطبيق جانغو وبإمكانك إلغاء تفعيل بيئتك الافتراضية:

(myprojectenv) $ deactivate

سيُحذف مؤشر البيئة الافتراضية في المحثّ الظاهر أمامك.

الخطوة السابعة - إنشاء مقبس systemd وملفات خدمة لخادم غوني كورن

الآن بعد أن اختبرت وتأكدت أن بإمكان الخادم غوني كورن التفاعل مع تطبيقك المنشأ بجانغو، يجب أن تنفذ طريقةً أقوى في تشغيل وإطفاء خادم التطبيقات. ستنشئ من أجل هذا خدمة systemd وملفات مقبس.

سينُشأ مقبس غوني كورن عند الإقلاع ويبدأ بالاستماع للاتصالات، وعندما يحدث اتصال ستشغِّل خدمة systemd تلقائيًّا عملية غوني كورن لمعالجة الاتصال.

ابدأ بإنشاء وفتح ملف مقبس systemd لخادم غوني كورن مع صلاحيات sudo في محرر النصوص المفضل لديك:

$ sudo nano /etc/systemd/system/gunicorn.socket

أنشئ داخل الملف القسم [Unit] لوصف المقبس والقسم [Socket] لتعريف موقع المقبس والقسم [Install] للتأكد من أن المقبس يُنشأ في الوقت المناسب:

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

احفظ الملف وأغلقه عندما تنتهي، ثم أنشئ وافتح ملف خدمة systemd من أجل غوني كورن مع صلاحيات sudo في محرر النصوص المفضّل لديك، ويجب أن يطابق اسم ملف الخدمة اسم ملف المقبس باستثناء الامتداد:

$ sudo nano /etc/systemd/system/gunicorn.service

ابدأ بالقسم [Unit] المُستَخدم لتحديد البيانات الوصفية metadata والاعتماديات. أضف وصفًا لخدمتك هنا وأخبر نظام التهيئة "init system" أن يشغّل الخدمة فقط بعد الوصول إلى مستوى التشبيك المستهدف networking target. نظرًا لأن خدمتك تعتمد على المقبس من ملف المقبس، فستحتاج إلى تضمين الموجّه Requires للإشارة إلى تلك العلاقة:

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

ثم أضف القسم [Service] وحدّد المستخدم والمجموعة اللذين تريد أن تعمل العملية تحتهما. زوّد ملكيتك للعملية من خلال حساب مستخدم نظامي لأنها تمتلك كل الملفات المرتبطة، ثم زوّد ملكية مجموعتك إلى مجموعة "www-data" ليتمكن الخادم إنجن إكس من التواصل مع خادم غوني كورن.

بعد ذلك، ارسم خطة المجلد العامل وحدّد الأمر الذي ستنفّذه لتشغيل العملية، وفي حالتنا هذه حدّد المسار الكامل للملف التنفيذي للخادم غوني كورن المثبت ضمن بيئتك الافتراضية، ثم اربط العملية بمقبس يونيكس Unix الذي أنشأته ضمن المجلد "run/" لكي تتمكن العملية من التواصل مع خادم إنجن إكس. سجّل كافة البيانات على أداة الخرج المعياري لكي تتمكن العملية journald من جمع سجلات الخادم غوني كورن. يمكنك أيضًا هنا تحديد أي إضافات اختيارية لخادم غوني كورن، إذ حدّدنا في مثالنا ثلاث عمليات عاملة على النحو التالي:

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          myproject.wsgi:application

أخيرًا، أضف القسم [Install] الذي سيخبر systemd بماذا ستربط هذه الخدمة إذا فعّلتها للعمل عند الإقلاع، إذ أن الأفضل أن تعمل هذه الخدمة عندما يكون نظام المستخدمين المتعددين النظامي يعمل على النحو الصحيح والمطلوب:

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          myproject.wsgi:application

[Install]
WantedBy=multi-user.target

وبهذا يكتمل ملف خدمة systemd، والآن احفظ الملف وأغلقه، ثم شغّل مقبس غوني كورن. سينشئ هذا ملف المقبس في المسار "run/gunicorn.sock/" الآن وكذلك عند الإقلاع:

$ sudo systemctl start gunicorn.socket

ثم فعّله بحيث تشغّل systemd تلقائيًا خدمة gunicorn.service عندما يحدث اتصال مع ذاك المقبس لتتولى معالجته:

$ sudo systemctl enable gunicorn.socket

يمكنك التحقق أن العملية نجحت من خلال التحقق من وجود ملف المقبس، وهذا موضوع الخطوة القادمة.

الخطوة الثامنة - التحقق من وجود ملف مقبس غوني كورن

افحص حالة العملية لتعرف ما إذا كانت قابلة للتشغيل:

$ sudo systemctl status gunicorn.socket

وسيكون الخرج على النحو التالي:

● gunicorn.socket - gunicorn socket
     Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor prese>
     Active: active (listening) since Thu 2021-12-02 19:58:48 UTC; 14s ago
   Triggers: ● gunicorn.service
     Listen: /run/gunicorn.sock (Stream)
      Tasks: 0 (limit: 1136)
     Memory: 0B
     CGroup: /system.slice/gunicorn.socket

Dec 02 19:58:48 gunicorn systemd[1]: Listening on gunicorn socket.

ثم تحقق من وجود الملف "gunicorn.sock" ضمن المجلد "run/":

$ file /run/gunicorn.sock

وسيكون الخرج على النحو التالي:

/run/gunicorn.sock: socket

إذا أشار الأمرsystemctl status إلى حدوث خطأ، أو إذا لم تجد الملف "gunicorn.sock" في المجلد فإن هذه إشارة أننا لم ننجح في إنشاء مقبس غوني كورن. تفقّد سجلات مقبس غوني كورن بتنفيذ الأمر التالي:

$ sudo journalctl -u gunicorn.socket

افحص الملف "etc/systemd/system/gunicorn.socket/" لإصلاح أي مشاكل قبل المتابعة.

الخطوة التاسعة - فحص تنشيط المقبس

إذا شغلت فقط الوحدة gunicorn.socket، لن تكون الخدمة gunicorn.service نشطةً لأن المقبس لن يكون قد استقبل أي اتصالات. لذلك افحص الحالة:

$ sudo systemctl status gunicorn

وسيكون الخرج على النحو التالي:

● gunicorn.service - gunicorn daemon
   Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

لفحص آلية تنشيط المقبس، أرسل اتصالًا إلى المقبس عبر curl:

$ curl --unix-socket /run/gunicorn.sock localhost

يفترض أن تتلقى خرج HTML من تطبيقك في الطرفية، وهذا يؤكد إقلاع خادم غوني كورن وأنه قادر على خدمة تطبيق جانغو الخاص بك. يمكنك التحقق من أن خدمة غوني كورن تعمل من خلال فحص الحالة مرة أخرى:

$ sudo systemctl status gunicorn

وسيكون الخرج على النحو التالي:

●  gunicorn.service - gunicorn daemon
   Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset
   Active: active (running) since Tue 2021-11-23 22:55:12 UTC; 11s ago
 Main PID: 11002 (gunicorn)
    Tasks: 4 (limit: 1151)
   CGroup: /system.slice/gunicorn.service
           ├─11002 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
           ├─11018 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
           ├─11020 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
           └─11022 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
. . .

إذا أشار الخرج من جرّاء تنفيذ curl أو الخرج من systemctl status إلى أن مشكلةً قد وقعت، افحص سجلات التفاصيل الإضافية:

$ sudo journalctl -u gunicorn

افحص الملف "etc/systemd/system/gunicorn.service/" بحثًا عن المشاكل، وإذا أجريت تغييرات على الملف "etc/systemd/system/gunicorn.service/"، فأعد تحميل العملية الخفية daemon لإعادة قراءة تعريف الخدمة:

$ sudo systemctl daemon-reload

ثم أعد تشغيل خدمة غوني كورن:

$ sudo systemctl restart gunicorn

إذا ظهرت أي مشاكل مثل هذه، فأصلحها قبل المتابعة.

الخطوة العاشرة - ضبط الخادم إنجن إكس لتمرير الخادم الوكيل إلى خادم غوني كورن

الآن بعد إعداد غوني كورن، ستضبط الخادم إنجن إكس لتمرير حركة البيانات في الشبكة إلى العملية. ابدأ بإنشاء وفتح كتلة خادم جديدة في مجلد إنجن إكس المسمى "sites-available" كما يلي:

$ sudo nano /etc/nginx/sites-available/myproject

افتح داخله كتلة خادم جديدة، وابدأ بتحديد أن هذه الكتلة ينبغي أن تستمع على المنفذ الطبيعي 80 وأن تستجيب لاسم نطاق خادمك أو عنوان IP الخاص به:

server {
    listen 80;
    server_name server_domain_or_IP;
}

ثم اطلب من الخادم إنجن إكس أن يتجاهل أي مشاكل متعلقة بإيجاد الأيقونة المفضلة favicon، وأخبره أيضًا أين يجد الأصول الساكنة التي جمعتها في مجلدك المسمى "myprojectdir/static/~". تمتلك جميع هذه الملفات سابقة URI معيارية بقيمة "static/"، لذا يمكنك إنشاء كتلة موقع لمطابقة تلك الطلبات:

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myprojectdir;
    }
}

أخيرًا، أنشئ كتلة location / {}‎ لمطابقة كافة الطلبات الأخرى، وضمّن داخلَ هذا الموقع الملفَّ المعياري "proxy_params" من تثبيت إنجن إكس، ثم حدّد حركة مرور بيانات الشبكة مباشرةً إلى مقبس غوني كورن:

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myprojectdir;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/run/gunicorn.sock;
    }
}

احفظ الملف وأغلقه عند الانتهاء.

يمكنك الآن تفعيل الملف بربطه مع المجلد "sites-enabled":

$ sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

أجرِ اختبارًا لتتأكد من خلو ضبط الخادم إنجن إكس من الأخطاء الكتابية:

$ sudo nginx -t

إذا لم تظهر أي أخطاء، فتابع وأعد تشغيل خادم إنجن إكس:

$ sudo systemctl restart nginx

ونظرًا لأنك لا تحتاج بعد الآن إلى وصول إلى خادم التطوير، اضبط إعدادات الجدار الناري بحذف قاعدة المنفذ المفتوح "8000":

$ sudo ufw delete allow 8000

ثم اسمح لبيانات الشبكة العادية بالمرور من المنفذين "80" و"443" مما سيسمح بحدوث اتصالات HTTP و HTTPS على التوالي، وذلك باستخدام الأمر التالي:

$ sudo ufw allow 'Nginx Full'

يُفترض أن يكون بمقدورك الآن الذهاب إلى نطاق خادمك أو عنوان IP الخاص به لمشاهدة تطبيقك.

ملاحظة: بعد الانتهاء من ضبط إنجن إكس ستكون الخطوة التالية هي تأمين بيانات الشبكة إلى الخادم باستخدام بروتوكول SSL/TLS، وهذا مهم لأنه بدونه ستُرسل جميع المعلومات بما فيها كلمات المرور عبر الشبكة بصيغة نصيّةٍ صرفة plain text.

إذا كان لديك اسم نطاق فأسرعُ طريقة للحصول على شهادة SSL لتأمين بيانات الشبكة هو استخدام Let's Encrypt. يمكنك إعداده من خلال متابعة دليلنا كيف تؤمن Let's Encrypt باستخدام إنجن إكس على نظام أبونتو 18.04. اتبع الدليل باستخدام كتلة خادم إنجن إكس التي أنشأتها في هذا الدليل.

إذا لم يكن لديك اسم نطاق، فلا يزال بإمكانك تأمين موقعك للاختبار والتعلم باستخدام self-signed SSL Certificate، ونشدّد على اتباع العملية باستخدام كتلة خادم إنجن إكس التي أنشأتها في هذه المقالة.

الخطوة الحادية عشرة - استكشاف المشاكل وإصلاحها في خادمي إنجن إكس وغوني كورن

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

يظهر الخادم إنجن إكس الصفحة الافتراضية بدلا من إظهار تطبيق جانغو

إذا كان إنجن إكس يعرض الصفحة الافتراضية بدلًا من إحالة الخادم الوكيل إلى تطبيقك، فذلك يعني غالبًا أنك بحاجة إلى ضبط server_name ضمن الملف "etc/nginx/sites-available/myproject/" ليشير إلى عنوان IP لخادمك، أو اسم نطاقه.

يستخدم إنجن إكس الموجه server_name ليحدد كتلة الخادم التي سيستخدمها للاستجابة للطلبات؛ فإذا كانت تظهر لك صفحة إنجن إكس الافتراضية ففي هذا دلالة على الخادم إنجن إكس لم يستطع مطابقة الطلب مع كتلة الخادم صراحةً لذا تراجع إلى الكتلة الافتراضية المعرّفة في الملف "etc/nginx/sites-available/default/".

يجب أن يكون الموجه server_name في كتلة خادم المشروع أكثر تحديدًا من الموجّه المُختار في كتلة الخادم الافتراضية.

يعرض الخادم إنجن إكس الخطأ 502 Bad Gateway بدلا من عرضه تطبيق جانغو

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

والمكان الأساسي الذي يجب أن تبحث فيه عن مزيد من المعلومات هو سجل أخطاء إنجن إكس؛ فهو يخبرنا عمومًا عن الظروف التي سببت الخطأ أثناء حدث الإحالة من الخادم الوكيل Proxying. تفقد سجل أخطاء الخادم إنجن إكس بالتعليمة التالية:

$ sudo tail -F /var/log/nginx/error.log

والآن أسس طلبًا آخرًا في متصفحك لتوليد خطأ جديد (حاول إنعاش refresh الصفحة). يُفترض أن تتلقى رسالة خطأ جديدة مسجلة في السجل. إذا قرأت الرسالة وفهمتها فستضيّق نطاق المشكلة.

ربما تتلقى رسالة تشبه ما يلي:

 connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)

التي تشير إلى أن إنجن إكس لم يستطع العثور على الملف "gunicorn.sock" في الموقع المُعطى. ينبغي مقارنة الموقع "proxy_pass" المعرف ضمن الملف "etc/nginx/sites-available/myproject/" مع الموقع الفعلي للملف "gunicorn.sock" الذي ولدته وحدة systemd المسماة "gunicorn.socket".

إذا لم تتمكن من العثور على الملف "gunicorn.sock" ضمن المجلد "run/"، فهذا يعني عمومًا أن ملف مقبس systemd لم يتمكن من إنشائه. عُد إلى القسم من مقالتنا هذه الذي يتكلم عن البحث عن ملف مقبس غوني كورن للسير وفق خطوات الإصلاح لمشكلات الخادم غوني كورن.

وقد تقرأ رسالةً أخرى تشبه التالية:

connect() to unix:/run/gunicorn.sock failed (13: Permission denied)

التي تشير هذه إلى أن الخادم إنجن إكس لم يتمكن من الاتصال بمقبس غوني كورن بسبب مشكلات تتعلق بالأذونات، ويُحتمل أن يحدث هذا عندما يُتبع الإجراء باستخدام المستخدم الجذر "root" بدلًا من المستخدم "sudo". وقد تدل الرسالة إلى أنه في الوقت الذي تستطيع systemd إنشاء ملف مقبس غوني كورن، لم يتمكن الخادم إنجن إكس من الوصول إليه.

يمكن لهذا أن يحدث إذا كانت هناك محدودية في الأذونات في أي نقطة بين المجلد الجذر والملف "gunicorn.sock"، ويمكنك استعراض الأذونات وقيم الملكية لملف المقبس وكل من المجلدات الآباء له بتمرير المسار المطلق إلى ملف المقبس الخاص بك إلى الأمر namei:

$ namei -l /run/gunicorn.sock

وسيكون الخرج على النحو التالي:

f: /run/gunicorn.sock
drwxr-xr-x root root /
drwxr-xr-x root root run
srw-rw-rw- root root gunicorn.sock

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

يملك ملف المقبس في هذا المثال وكل مجلد من المجلدات التي تؤدي إليه أذونات قراءة read وتنفيذ execute (ينتهي عمود الأذونات للمجلدات بالامتداد r-x بدلًا من ---). يجب أن تكون العملية إنجن إكس قادرة على الوصول إلى المقبس بنجاح.

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

جانغو يعرض الرسالة could not connect to server: Connection refused

من الرسائل التي يمكن أن تتلقاها عند محاولة الوصول إلى أجزاء من التطبيق في متصفح الويب هي:

OperationalError at /admin/login/
could not connect to server: Connection refused
    Is the server running on host "localhost" (127.0.0.1) and accepting
    TCP/IP connections on port 5432?

التي يشير هذا إلى أن جانغو لم يتمكن من الاتصال بقاعدة بيانات Postgres. لذا تأكد أن نسخة Postgres تعمل كما يلي:

$ sudo systemctl status postgresql

إذا لم تكن تعمل، فيمكنك تشغيلها وضبط إمكانية تشغيلها تلقائيًا عند الإقلاع (إذا لم تكن معدةً هكذا من قبل):

$ sudo systemctl start postgresql
$ sudo systemctl enable postgresql

إذا استمر الخلل، فتأكد أن إعدادات قاعدة البيانات المعرفة في الملف "myprojectdir/myproject/settings.py/~" صحيحة.

مزيد من استكشاف الأخطاء وإصلاحها

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

قد تساعدك السجلات التالية في عملك:

• فحص سجلات عملية إنجن إكس كما يلي:

sudo journalctl -u nginx

• فحص سجلات الوصول إلى إنجن إكس كما يلي:

sudo less /var/log/nginx/access.log

• فحص سجلات الخطأ لإنجن إكس كما يلي:

sudo less /var/log/nginx/error.log

• فحص سجلات تطبيق غوني كورن كما يلي:

sudo journalctl -u gunicorn

• فحص سجلات مقابس غوني كورن كما يلي:

sudo journalctl -u gunicorn.socket

ستحتاج غالبًا أثناء تحديثك للتهيئة أو التطبيق إلى إعادة تشغيل العمليات لضبط تغييراتك.

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

$ sudo systemctl restart gunicorn

إذا غيرت ملفات خدمة أو مقبس غوني كورن أعد تحميل العملية الخفية daemon وأعد تشغيل العملية بتنفيذ التعليمات التالية:

$ sudo systemctl daemon-reload
$ sudo systemctl restart gunicorn.socket gunicorn.service

إذا غيرت تهيئة كتلة خادم إنجن إكس، افحص الضبط ثم إنجن إكس بتنفيذ ما يلي:

$ sudo nginx -t && sudo systemctl restart nginx

هذه الأوامر مفيدة جدًا لتطبيق التغييرات أثناء الضبط.

خاتمة

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

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

ترجمة - وبتصرف - للمقالة How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu 18.04 لصاحبها Justin Ellingwood.

اقرأ أيضًا

• إعداد تطبيق ASGI Django للنشر مع Postgres وخادم Nginx مع Uvicorn
• إعداد تطبيق جانغو جاهز للنشر مع قاعدة بيانات Postgres وخادم Nginx و Gunicorn
• إنشاء تطبيق جانغو وتوصيله بقاعدة بيانات

رغم أنَّ حزمة LAMP، المكونة من لينكس Linux وأباتشي Apache وMySQL وPHP، تحظى بشعبية كبيرة في تشغيل ووردبريس، لكن يمكن استخدام Nginx -تلفظ إنجن إكس- أيضًا إذ يدعمه ووردبريس، وهو يُشغَّل بعض مواقع ووردبريس الكبيرة، مثل WordPress.com.

من المهم عند الحديث عن Nginx معرفة أنه توجد طرق متعددة لتطبيقه، ويمكن إعداده مثل وكيل عكسي أمام Apache، وهو إعداد قوي للغاية يسمح لك باستخدام جميع ميزات وقوة Apache مع الاستفادة من سرعة Nginx، ومعظم مواقع الويب التي تستخدم Nginx خادمًا -بناءًا على الإحصائيات التي جُمعت من ترويسات استجابة HTTP- هي في الواقع تعمل على Apache مع Nginx وكيلًا عكسيًا، حيث تعرض ترويسات استجابة HTTP إحصائيات استخدام Nginx وكيلًا عكسيًا وليس خادمًا.

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

• عند استخدام Nginx لا يوجد ملف تهيئة على مستوى الدليل، مثل الملف htaccess. الخاص بخادم Apache، أو ملفات web.config الخاصة بالخادم IIS، ويجب إجراء كامل التهيئة على مستوى الخادم من قبل المدير، ولا يمكن تعديل الإعدادات في ووردبريس كما هو الحال مع Apache أو IIS.
• تختلف الروابط الثابتة قليلاً عند تشغيل Nginx.
• لا يحتوي Nginx على صلاحيات من نوع htaccess.، ولا يمكن تعديل إعدادات الخادم تلقائيًا عبر ووردبريس، لذا لا يمكنه إنشاء قواعد إعادة الكتابة.
• سيضاف "index.php" إلى روابطك الثابتة دون تعديلات على تثبيتك الخاص، وتوجد طرق لتجاوز هذا باستخدام بعض الإضافات، أو إضافة شيفرة مخصصة إلى function.php لقالبك، أو بالطريقتين معًا.
• إذا أردت الحصول على بعض الإمكانيات المحدودة للملف htaccess.، فمن الممكن تقنيًا الإضافة عن طريق تثبيت ملحق htscanner PECL لـ PHP، إلا أن هذا ليس حلًا مثاليًا لذا تأكد من ذلك واختبره تمامًا قبل استخدامه المباشر على الموقع.

لن يغطي هذا الدليل كيفية تثبيت Nginx وإعداداته، لذلك يفترض أنك ثبّتت Nginx، وتعلم كيفية التعامل معه وتصحيح أخطائه.

الدعم العام ومتعدد المواقع

يجب ضبط الواجهة الخلفية php-cgi حتى يعمل ووردبريس مع Nginx، والخيارات المتاحة هي fastcgi أو php-fpm، ويُستخدَم php-fpm لأنه مضمَّن في إصدار PHP 5.3 وما بعده، لذا فتثبيته مباشر.

قُسمت إعدادت Nginx إلى خمسة ملفات مميزة، مع التعليق عليها لتسهيل فهمها، كما بذل المؤلف كل جهده في محاولة اتباع "أفضل الممارسات" لإعدادات nginx.

ملف بدء التشغيل الرئيسي (العام)

يكافئ هذا /etc/nginx/nginx.conf أو /etc/nginx/conf/nginx.conf عند استخدام لينكس Arch.

# Generic startup file.
user {user} {group};

#usually equal to number of CPUs you have. run command "grep processor /proc/cpuinfo | wc -l" to find it
worker_processes  auto;
worker_cpu_affinity auto;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

# Keeps the logs free of messages about not being able to bind().
#daemon     off;

events {
    worker_connections  1024;
}

http {
#   rewrite_log on;

    include mime.types;
    default_type       application/octet-stream;
    access_log         /var/log/nginx/access.log;
    sendfile           on;
#   tcp_nopush         on;
    keepalive_timeout  3;
#   tcp_nodelay        on;
#   gzip               on;
        #php max upload limit cannot be larger than this       
    client_max_body_size 13m;
    index              index.php index.html index.htm;

    # Upstream to abstract backend connection(s) for PHP.
    upstream php {
                #this should match value of "listen" directive in php-fpm pool
        server unix:/tmp/php-fpm.sock;
#       server 127.0.0.1:9000;
    }

    include sites-enabled/*;
}

يختلف هذا قليلًا عن ملفات nginx.conf القياسية، ويتبع هذا الإعداد طريقة Ubuntu/Debian لجعل المواقع المفعلة بأقصى درجة مرونة، باستخدام "sites-available" لتخزين الإعدادات، ثم الربط بملف الإعدادات من "sites-enabled".

حسب إعدادات الموقع

# Redirect everything to the main site. We use a separate server statement and NOT an if statement - see http://wiki.nginx.org/IfIsEvil

server {
        server_name  _;
        return 302 $scheme://example.com$request_uri;
}

server {
    server_name example.com;
    root /var/www/example.com;

    index index.php;

    include global/restrictions.conf;

    # Additional rules go here.

    # Only include one of the files below.
    include global/wordpress.conf;
#    include global/wordpress-ms-subdir.conf;
#    include global/wordpress-ms-subdomain.conf;
}

يسمح فصل أقسام الإعدادات إلى ملفات متعددة بإعادة استخدام نفس المنطق مرارًا وتكرارًا، ويُستخدم الدليل الفرعي "global" لإضافة صلاحيات إضافية للاستخدام للأغراض العامة، /etc/nginx/conf/global/ أو /etc/nginx/global/، بناءً على كيفية إعداد تثبيت nginx.

ملف القيود الشامل

# Global restrictions configuration file.
# Designed to be included in any server {} block.
location = /favicon.ico {
    log_not_found off;
    access_log off;
}

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}

# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~ /\. {
    deny all;
}

# Deny access to any files with a .php extension in the uploads directory
# Works in sub-directory installs and also in multisite network
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~* /(?:uploads|files)/.*\.php$ {
    deny all;
}

مبادئ ووردبريس العامة

للتثبيت في موقع مفرد إليك ملف global/wordpress.conf:

# WordPress single site rules.
# Designed to be included in any server {} block.
# Upstream to abstract backend connection(s) for php
upstream php {
        server unix:/tmp/php-cgi.socket;
        server 127.0.0.1:9000;
}

server {
        ## Your website name goes here.
        server_name domain.tld;
        ## Your only path reference.
        root /var/www/wordpress;
        ## This should be in your http block and if it is, it's not needed here.
        index index.php;

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }

        location / {
                # This is cool because no php is touched for static content.
                # include the "?$args" part so non-default permalinks doesn't break when using query string
                try_files $uri $uri/ /index.php?$args;
        }

        location ~ \.php$ {
                #NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
                include fastcgi.conf;
                fastcgi_intercept_errors on;
                fastcgi_pass php;
        }

        location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }
}

إليك مثالًا حديثًا عن Nginx

مبادئ الدليل الفرعي لووردبريس متعدد المواقع

لتثبيت الدليل الفرعي متعدد المواقع إليك ملف global/wordpress.conf:

# WordPress multisite subdirectory rules.
# Designed to be included in any server {} block.

map $uri $blogname{
    ~^(?P/[^/]+/)files/(.*)       $blogpath ;
}

map $blogname $blogid{
    default -999;

    #Ref: https://wordpress.org/extend/plugins/nginx-helper/
    #include /var/www/wordpress/wp-content/plugins/nginx-helper/map.conf ;
}

server {
    server_name example.com ;

    root /var/www/example.com/htdocs;
    index index.php;

    location ~ ^(/[^/]+/)?files/(.+) {
        try_files /wp-content/blogs.dir/$blogid/files/$2 /wp-includes/ms-files.php?file=$2 ;
        access_log off;     log_not_found off; expires max;
    }

    #avoid php readfile()
    location ^~ /blogs.dir {
        internal;
        alias /var/www/example.com/htdocs/wp-content/blogs.dir ;
        access_log off;     log_not_found off; expires max;
    }

    if (!-e $request_filename) {
        rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
        rewrite ^(/[^/]+)?(/wp-.*) $2 last;
        rewrite ^(/[^/]+)?(/.*\.php) $2 last;
    }

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

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_pass php;
    }

    #add some rules for static content expiry-headers here
}

يوفر NGINX توجيهين خاصين هما X-Accel-Redirect و map، ويمكن للمستخدم باستخدامهما إلغاء أداء خدمة الملفات الثابتة على شبكة ووردبريس متعددة المواقع.

مبادئ النطاق الفرعي لووردبريس متعدد المواقع

map $http_host $blogid {
    default       -999;

    #Ref: https://wordpress.org/extend/plugins/nginx-helper/
    #include /var/www/wordpress/wp-content/plugins/nginx-helper/map.conf ;

}

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

    root /var/www/example.com/htdocs;
    index index.php;

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

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_pass php;
    }

    #WPMU Files
        location ~ ^/files/(.*)$ {
                try_files /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1 ;
                access_log off; log_not_found off;      expires max;
        }

    #WPMU x-sendfile to avoid php readfile()
    location ^~ /blogs.dir {
        internal;
        alias /var/www/example.com/htdocs/wp-content/blogs.dir;
        access_log off;     log_not_found off;      expires max;
    }

    #add some rules for static content expiry-headers here
}

HTTPS في Nginx

يعد تفعيل HTTPS في Nginx أمرًا بسيطًا نسبيًا.

server {
    # listens both on IPv4 and IPv6 on 443 and enables HTTPS and HTTP/2 support.
    # HTTP/2 is available in nginx 1.9.5 and above.
    listen *:443 ssl http2;
    listen [::]:443 ssl http2;

    # indicate locations of SSL key files.
    ssl_certificate /srv/www/ssl/ssl.crt;
    ssl_certificate_key /srv/www/ssl/ssl.key;
    ssl_dhparam /srv/www/master/ssl/dhparam.pem;

    # indicate the server name
    server_name example.com *.example.com;

    # Enable HSTS. This forces SSL on clients that respect it, most modern browsers. The includeSubDomains flag is optional.
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    # Set caches, protocols, and accepted ciphers. This config will merit an A+ SSL Labs score as of Sept 2015.
    ssl_session_cache shared:SSL:20m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5';
}

تقدم Mozilla أداة إنشاء تكوين SSL ممتازةً أيضًا.

قواعد ذاكرة التخزين المؤقت الفائقة WP

# WP Super Cache rules.
# Designed to be included from a 'wordpress-ms-```' configuration file.

set $cache_uri $request_uri;

# POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
        set $cache_uri 'null cache';
}

if ($query_string != "") {
        set $cache_uri 'null cache';
}  

# Don't cache uris containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $cache_uri 'null cache';
}  

# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
        set $cache_uri 'null cache';
}

# START MOBILE
# Mobile browsers section to server them non-cached version. COMMENTED by default as most modern wordpress themes including twenty-eleven are responsive. Uncomment config lines in this section if you want to use a plugin like WP-Touch
# if ($http_x_wap_profile) {
#        set $cache_uri 'null cache';
#}

#if ($http_profile) {
#        set $cache_uri 'null cache';
#}

#if ($http_user_agent ~* (2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800)) {
 #       set $cache_uri 'null cache';
#}

#if ($http_user_agent ~* (w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-)) {
  #      set $cache_uri 'null cache';
#}
#END MOBILE

# Use cached or actual file if they exists, otherwise pass request to WordPress
location / {
        try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php?$args ;
}

التعديلات التجريبية

إذا كنت تستخدم HTTPS فقد تستخدم أحدث نسخة مطورة من WP Super Cache بنية دليل مختلفةً للتمييز بين HTTP وHTTPS، وقد يبدو سطر try_files كما يلي:

location / {
        try_files /wp-content/cache/supercache/$http_host/$cache_uri/index-https.html $uri $uri/ /index.php?$args ;
}

قواعد ذاكرة التخزين المؤقتة W3 Total Cache

تستخدم W3 Total Cache بنية دليل مختلفةً لذاكرة التخزين المؤقت على القرص اعتمادًا على تكوين ووردبريس، وتبقى عمليات التحقق من صحة ذاكرة التخزين المؤقت كما هو موضح أدناه:

#W3 TOTAL CACHE CHECK
set $cache_uri $request_uri;

# POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
        set $cache_uri 'null cache';
}  
if ($query_string != "") {
        set $cache_uri 'null cache';
}  

# Don't cache uris containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $cache_uri 'null cache';
}  

# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
        set $cache_uri 'null cache';
}
#ADD mobile rules from WP SUPER CACHE section above

#APPEND A CODE BLOCK FROM BELOW```

استخدم ما يلي لووردبريس العادي، بدون مواقع متعددة:

# Use cached or actual file if they exists, otherwise pass request to WordPress
location / {
        try_files /wp-content/w3tc/pgcache/$cache_uri/_index.html $uri $uri/ /index.php?$args ;
}

وللمواقع المتعددة مع الأدلة الفرعية استخدم:

if ( $request_uri ~* "^/([_0-9a-zA-Z-]+)/.*" ){
        set $blog $1;
}

set $blog "${blog}.";

if ( $blog = "blog." ){
        set $blog "";
}

# Use cached or actual file if they exists, otherwise pass request to WordPress
location / {
        try_files /wp-content/w3tc-$blog$host/pgcache$cache_uri/_index.html $uri $uri/ /index.php?$args ;
}

ولمواقع متعددة مع نطاقات فرعية أو تعيين النطاق استخدم:

location / {
        try_files /wp-content/w3tc-$host/pgcache/$cache_uri/_index.html $uri $uri/ /index.php?$args;
}

ملاحظات:

• يمكن لـ Nginx معالجة gzip وذاكرة التخزين المؤقت للمتصفح تلقائيًا، لذا من الأفضل ترك هذا الجزء لـ nginx.
• ستعمل قواعد W3 Total Cache Minify مع الإعدادات أعلاه دون أي مشاكل.

Nginx fastcgi_cache

يمكن لـ Nginx إجراء التخزين المؤقت من جانبه لتقليل الحمل على الخادم، وعندما تريد استخدام fastcgi_cache المدمج في Nginx، يفضل تشغيل nginx باستخدام وحدة fastcgi_cache_purge، وستساعد nginx على مسح ذاكرة التخزين المؤقت لصفحة ما عند تحريرها. ومن ناحية ووردبريس، ستحتاج إلى تثبيت إضافة مثل مساعد Nginx للاستفادة من ميزة fastcgi_cache_purge.

ستبدو الإعدادات كما يلي:

حدد منطقة ذاكرة التخزين المؤقت Nginx في كتلة {…}http، خارج كتلة {..}server:

#move next 3 lines to /etc/nginx/nginx.conf if you want to use fastcgi_cache across many sites
fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:500m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;

بالنسبة لإعدادات موقع ووردبريس في الكتلة {..}server أضف كتلة تحقق من ذاكرة التخزين المؤقت على النحو التالي:

#fastcgi_cache start
set $no_cache 0;

# POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
        set $no_cache 1;
}  
if ($query_string != "") {
        set $no_cache 1;
}  

# Don't cache uris containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $no_cache 1;
}  

# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
        set $no_cache 1;
}

ثم أجرِ تغييرات على كتلة معالجة PHP.

فقط أضف هذا إلى كتلة php التالية، لاحظ السطر fastcgi_cache_valid 200 60m، الذي يخبر nginx بالتخزين المؤقت للاستجابات 200 -أي الصفحات العادية- فقط، مما يعني أن صفحات إعادة التوجيه لا تخزَّن مؤقتًا، وهذا مهم للمواقع متعددة اللغات، وإذا لم ينفَّذ فسيخزن nginx عنوان url الرئيسي في لغة واحدة، بدلًا من إعادة توجيه المستخدمين إلى المحتوى الخاص بهم وفقًا للغتهم.

fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;

fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 60m;

بحيث يصبح مثل هذا:

location ~ [^/]\.php(/|$) {
    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    if (!-f $document_root$fastcgi_script_name) {
        return 404;
    }
    # This is a robust solution for path info security issue and works with "cgi.fix_pathinfo = 1" in /etc/php.ini (default)

    include fastcgi.conf;
    fastcgi_index index.php;
#    fastcgi_intercept_errors on;
    fastcgi_pass php;

    fastcgi_cache_bypass $no_cache;
    fastcgi_no_cache $no_cache;

    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 200 60m;
}

أخيرًا أضف موقعًا للمسح الشرطي:

location ~ /purge(/.*) {
        # Uncomment the following two lines to allow purge only from the webserver
        #allow 127.0.0.1;
    #deny all;

        fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}

إذا تلقيت خطأ "توجيه غير معروف fastcgicachepurge" فتحقق من أنَّ تثبيت Nginx يحتوي على وحدة fastcgicachepurge.

أداء أفضل للملفات الثابتة في المواقع المتعددة

يؤدي طلب ملف ثابت عند إعداد المواقع المتعددة إلى تشغيل php، أي الملف ms-files.php، ويمكنك الحصول على أداء أفضل بكثير باستخدام توجيه {..}Map في Nginx.

أضف ما يلي في إعدادات Nginx لموقعك فوق الكتلة {..}server:

map $http_host $blogid {
    default               0;

    example.com           1;
    site1.example.com     2;
    site1.com             2;
}

إنها مجرد قائمة بأسماء المواقع ومعرفات المدونات، ويمكنك استخدام مساعد Nginx للحصول على مثل هذه القائمة في أزواج تحوي أسماء المواقع ومعرفات المدونات، وستنشئ هذه الإضافة أيضًا ملف map.conf يمكنك تضمينه مباشرةً في قسم {..}map بالشكل التالي:

map $http_host $blogid {
    default               0;

    include /path/to/map.conf ;
}

بعد إنشاء قسم {..}map تحتاج إجراء تغيير واحد آخر في إعدادات Nginx لتعالج طلبات /files/ أولًا باستخدام {..}map في nginx:

location ~ ^/files/(.*)$ {
          try_files /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1 ;
          access_log off; log_not_found off; expires max;
 }

ملاحظات

انتبه إلى ما يلي:

• عند إنشاء موقع جديد أو حذفه أو تعيين نطاق إضافي لموقع موجود؛ سيحدّث مساعد Nginx ملف map.conf تلقائيًا، ولكنك ستحتاج إلى إعادة تحميل إعدادات Nginx يدويًا، ويمكنك ذلك في أي وقت لاحق، وحتى ذلك الحين ستقدَّم ملفات المواقع الجديدة فقط باستخدام php-fpm.
• لا تولد هذه الطريقة أي روابط رمزية symbolic links، لذلك لن تكون هناك مشكلات في عمليات الحذف العرضية أو البرامج النصية الاحتياطية التي تتبع روابط رمزية.
• يمكن توسيع هذا بشكل جيد للشبكات الكبيرة، وسيوجد فقط ملف map.conf واحد.

وفي ملاحظة أخيرة مهمة: يفترض هذا الإعداد بأكمله أن جذر الموقع هو المدونة، وأن جميع الملفات التي نرجع إليها موجودة في المضيف، وإذا وضعت المدونة في دليل فرعي مثل blog/، فسيتعين تعديل القواعد، ويمكن للمستخدم جعل ذلك ممكنًا، فمثلًا يمكنك استخدام التوجيه التالي في كتلة "server" الرئيسية، وتطبيقه تلقائيًا على قواعد WP العامة:

set $wp_subdir "/blog";

انتبه هنا، إذ يمكن أن يؤدي خطأ مطبعي في Global restrictions file إلى حدوث ثغرات، ولاختبار ما إذا كان دليل uploads محميًا حقًا أنشئ ملف PHP مع بعض المحتوى، على سبيل المثال:

<?php phpinfo(); ?>

ارفعه إلى الدليل uploads، أو أحد أدلته الفرعية، ثم حاول الوصول إليه (تنفيذه) من متصفحك.

للالطلاع أكثر، يمكنك زيارة الآتي:

• صفحة توثيق Nginx في ووردبريس
• مثال عن خادم Nginx
• مثال ثان عن خادم Nginx
• دروس مفصلة عن إدارة خادم الوب Nginx.

ترجمة -وبتصرف- للمقال Nginx من موقع wordpress.org.

اقرأ أيضًا

• تثبيت وضبط خادم Nginx.
• كيفيّة ضبط Nginx للعمل كخادم ويب وكوسيط عكسي لـ Apache على خادم Ubuntu 18.04.
• كيفية الاستفادة من التخزين المؤقت في المتصفح باستعمال وحدة header في خادوم Nginx في أوبنتو 16.04.
• كيفية تثبيت Nginx على أوبونتو 18.04.
• كيف تُرقِّي خادم Nginx موجود بدون قطع اتصالات العميل.

Nginx خادم ويب قوي ووكيل عكسي (reverse proxy) يُستخدم لتقديم العديد من المواقع الأكثر شهرةً في العالم. سنوضّح في هذا الدليل كيفية ترقية Nginx الموجود القابل للتنفيذ، بدون قطع اتصالات العميل.

المتطلبات الأساسية

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

إذا كنت تستخدم أبنتو 14.04، يمكنك تعلّم كيفية ضبط مستخدم بصلاحيات sudo هنا. يمكنك تثبيت Nginx باتّباع هذا الدليل.

إذا كنت تستخدم CentOS 7، يمكنك الحصول على ضبط المستخدم بصلاحيات sudo عبر هذا الدليل، متّبعًا هذا الدليل لتثبّت Nginx.

كيف تعمل الترقية

يعمل Nginx على إنشاء إجراء سيّد أو رئيسي (master process) عندما تبدأ الخدمة. ويشغّل الإجراء السيّد بدوره إجراء تابع (worker process) أو أكثر تتعامل مع اتصالات العميل الفعلية. تم تصميم Nginx لأداء إجراءات معينة عندما يتلقّى إشارات محددة من المدير. يمنحك الفرصة باستخدام هذه الإشارات لتقوم بترقيته أو ترقية إعداداته الموجودة بسهولة، بدون قطع اتصالات العميل.

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

ستُستخدم الإشارات التالية:

• USR2: تولّد هذه مجموعة جديدة من إجراءات السيد/التابع بدون التأثير على المجموعة القديمة.
• WINCH: تخبر هذه الإجراء السيد لـNginx أن يوقف أغراض التابع المرتبطة بأمان.
• HUP: تخبر هذه الإجراء السيد لـNginx أن يعيد قراءة ملفات إعداداته ويستبدل إجراءات التابع بتلك المرتبطة بالإعدادات الجديدة. إذا كان هناك سيد قديم وجديد قيد التشغيل، فإنَّ إرسال هذا إلى السيد القديم سيولّد توابعًا باستخدام إعداداتهم الأصليّة.
• QUIT: توقف هذه تشغيل السيّد وتوابعه بأمان.
• TERM: تهيئ هذه إيقاف تشغيل سريع للسيّد وتوابعه.
• KILL: توقف هذه السيّد وتوابعه بدون أيّ تنظيف.

إيجاد معرّفات إجراء Nginx

لإرسال إشارات إلى الإجراءات المختلفة، نحتاج إلى معرفة معرّف الإجراء (PID) المستهدف. هناك طريقتان سهلتان لإيجاد هذا. أولًا، يمكنك استخدام الأداة ps وثمّ grep لـNginx بين النتائج. هذا بسيط ويسمح لك برؤية إجراءات السيّد والتابع:

$ ps aux | grep nginx

output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    10847  0.0  0.1  47936  1908 ?        S    13:26   0:00 nginx: worker process
user     10961  0.0  0.0 112640   964 pts/0    S+   13:53   0:00 grep --color=auto nginx

يحتوي العمود الثاني على معرّفات الإجراءات المُختارة. المميز هو معرّف الإجراء. يوضّح العمود الأخير أنَّ النتيجة الأولى هي الإجراء السيّد لـNginx.

طريقة أخرى لإيجاد معرّف الإجراء السيّد لـNginx وهي طباعة محتويات ملف ‎/run/nginx.pid:

$ cat /run/nginx.pid

output
10846

إذا كان هناك إجراءين سيّد لـNginx قيد التشغيل، سينتقل الإجراء القديم إلى run/nginx.pid.oldbin/.

توليد مجموعة سيّد/توابع جديدة

الخطوة الأولى لتحديث ملفنا القابل للتنفيذ بأمان هي في الواقع تحديث ملفك الثنائي.قم بذلك باستخدام أيّ طريقة مناسبة لتثبيت Nginx لديك، سواء من خلال مدير الحزمة أو التثبيت المصدري.

بعد وضع الملف الثنائي الجديد في مكانه، يمكنك توليد مجموعة ثانية من إجراءات السيّد/التابع التي تستخدم الملف الجديد القابل للتنفيذ.

يمكنك القيام بذلك إمّا بإرسال إشارة USR2 مباشرةً إلى رقم المعرّف الذي استعلمت عنه (تأكّد هنا من استبدال معرّف الإجراء السيّد بمعرّف الإجراء السيّد الخاص بخادمك Nginx):

$ sudo kill -s USR2 10846

او يمكنك قراءة واستبدال القيمة المخزّنة في ملف PID مباشرةً باستخدام أمر كهذا:

$ sudo kill -s USR2 `cat /run/nginx.pid` 

إذا تفحّصت إجراءاتك الحاليّة، ستشاهد أنّ لديك الآن مجموعتان من إجراءات السيّد/التوابع لـNginx:

$ ps aux | grep nginx

output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    10847  0.0  0.1  47936  1908 ?        S    13:26   0:00 nginx: worker process
root     11003  0.0  0.3  47564  3132 ?        S    13:56   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    11004  0.0  0.1  47936  1912 ?        S    13:56   0:00 nginx: worker process
user     11031  0.0  0.0 112640   960 pts/0    S+   14:01   0:00 grep --color=auto nginx

يمكنك أيضًا أن تشاهد أنَّ ملف run/nginx.pid/ الأصلي قد انتقل إلى run/nginx.pid.oldbin/ ومعرّف الإجراء السيّد الجديد كُتبَ في الملف run/nginx.pid/:

$ tail -n +1 /run/nginx.pid* 

output
==> /run/nginx.pid <==
11003

==> /run/nginx.pid.oldbin <==
10846

يمكنك الآن إرسال إشارات إلى أيّ من الإجراءين السيّدين مستخدمًا المعرّفات الموجودة في هذه الملفات.

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

إيقاف تشغيل توابع السيّد الأول

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

أوقف توابع المجموعة الأصلية بإصدار إشارة WINCH إلى إجرائهم السيّد:

$ sudo kill -s WINCH `cat /run/nginx.pid.oldbin`

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

$ ps aux | grep nginx

output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root     11003  0.0  0.3  47564  3132 ?        S    13:56   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    11004  0.0  0.1  47936  1912 ?        S    13:56   0:00 nginx: worker process
user     11089  0.0  0.0 112640   964 pts/0    R+   14:13   0:00 grep --color=auto nginx

يتيح هذا لك مراجعة التوابع الجدد لأنّهم يقبلون الاتصالات بشكلٍ منفصل مع الحفاظ على قابلية العودة إلى الملف القديم القابل للتنفيذ إذا كان هناك خطأٌ ما.

تقييم النتيجة واتخاذ الخطوات التالية

عند هذه النقطة يجب اختبار النظام ومراجعته للتأكّد من عدم وجود بوادر مشاكل. يمكنك ترك الإعدادات في هذه الحالة طالما ترغب بالتأكّد من أنّ الملف الجديد القابل للتنفيذ لـNginx خالٍ من الأخطاء وقادر على التعامل مع حركة المرور الخاصة بك.

ستعتمد خطوتك التالية تمامًا على ما إذا كنت تواجه مشاكل.

إذا كانت الترقية ناجحة، أكمل الانتقال

إذا لم تواجه أيّ مشاكل مع توابع مجموعتك الجديدة، يمكنك إيقاف تشغيل الإجراء السيّد القديم بأمان. للقيام بذلك، فقط أرسل الإشارة QUIT إلى السيّد القديم:

sudo kill -s QUIT `cat /run/nginx.pid.oldbin`

سيُغلَق الإجراء السيّد القديم بأمان، تاركًا فقط مجموعتك الجديدة من السيّد/التوابع لـNginx. عند هذه النقطة، تكون قد حدّثت الملف الثنائي الموجود لـNginx بأمان بدون مقاطعة اتصالات العميل.

إذا واجهت مشاكل في التوابع الجديدة، عُد إلى الملف الثنائي القديم

إذا لاحظت وجود مشاكل في مجموعة التوابع الجديدة، يمكنك العودة إلى الملف الثنائي والإعدادات القديمة. وهذا ممكن خلال الجلسة نفسها.

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

$ sudo kill -s HUP `cat /run/nginx.pid.oldbin`

يجب أن تعود الآن ليكون لديك مجموعتين من إجراءات السيّد/التابع:

$ ps aux | grep nginx

output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root     11003  0.0  0.3  47564  3132 ?        S    13:56   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    11004  0.0  0.1  47936  1912 ?        S    13:56   0:00 nginx: worker process
nginx    19918  0.0  0.1  47936  1900 ?        S    14:47   0:00 nginx: worker process
user     19920  0.0  0.0 112640   964 pts/0    R+   14:48   0:00 grep --color=auto nginx

ترتبط التوابع الجديدة بالتابع القديم. عند هذه النقطة فإنَّ توابع المجموعتين سيقبلون اتصالات العميل. أوقف الآن الإجراء السيّد الجديد الذي يحوي أخطاء وتوابعه بإرسال إشارة QUIT:

$ sudo kill -s QUIT `cat /run/nginx.pid`

يجب أن تعود للسيّد والتوابع القديمين:

$ ps aux | grep nginx

output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    19918  0.0  0.1  47936  1900 ?        S    14:47   0:00 nginx: worker process
user     19935  0.0  0.0 112640   964 pts/0    R+   14:50   0:00 grep --color=auto nginx

سيستعيد السيّد الأصلي ملف run/nginx.pid/ لمعرّفه.

إذا لم يعمل ما سبق لأي سبب من الأسباب، يمكنك أن تحاول فقط إرسال إشارة TERM للسيّد الجديد للخادم، وهذا يجب أن تتهيأ عملية إيقاف التشغيل. ويجب أن يوقف هذا السيّد الجديد وأي تابع من توابعه أثناء البحث التلقائي عن السيّد القديم لبدء إجراءات التابع الخاص به. إذا كان هناك مشاكل خطيرة والتوابع بهم أخطاء ولم يتم إنهاؤهم، يمكنك إرسال إشارة KILL لكلٍّ منهم للتنظيف. يجب أن يكون هذا كحل أخير لأنّه سيؤدي إلى قطع الاتصالات.

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

خاتمة

يجب أن تكون الآن قادرًا على نقل أجهزتك بسلاسة من ملف ثنائي لـNginx إلى آخر. إنَّ قدرة Nginx على التعامل مع مجموعتي سيّد/توابع مع المحافظة على معلومات علاقاتهم تتيح لنا القدرة على ترقية برنامج الخادم بدون أن يصبح جهاز الخادم في وضع عدم الاتصال.

ترجمة -وبتصرف- للمقال How To Upgrade Nginx In-Place Without Dropping Client Connections لصاحبه Justin Ellingwood

Nginx هو أحد أشهر خوادم الويب عالميا وهو المسؤول عن استضافة بعض أكبر المواقع وأكثرها ازدحاما على الإنترنت. يُعد Nginx غالبا أفضل من Apache من ناحية ملاءمته للموارد، ويمكن استخدامه كخادم ويب أو وكيل عكسي (reverse proxy). في هذا المقال سنشرح كيفية تثبيت Nginx على خادم أوبونتو 18.04.

المتطلبات

قبل البدء، تحتاج لمستخدم عادي - غير مسؤول - بصلاحيات "sudo" معد على الخادم. يمكنك معرفة كيفية إعداد خادم عادي في مقال الإعداد الأولي لِخادم أوبونتو 18.04.

إن كان لديك حساب متاح، سجل الدخول إلى المستخدم غير المسؤول للبدء.

خطوة 1 - تثبيت Nginx

يمكنك تثبيت Nginx باستخدام مدير الحزم "apt" وذلك لأنه متاح في مخزن أوبونتو الافتراضي.

ولأنها أول مرة نَستخدم فيها نظام تحزيم "apt"، سنُحدِث الحزمة المحلية الرئيسية كي نحصل على قائمة بأحدث الحزم. ثم ننفذ أمر تثبيت nginx:

 $ sudo apt update

 $ sudo apt install nginx

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

خطوة 2 - إعداد جدار الحماية

قبل اختبار Nginx، يجب إعداد جدار الحماية كي يتيح الوصول للخدمة. يُسجل Nginx نفسه كخدمة في ufw أثناء التثبيت مما يجعل السماح بالدخول إلى Nginx أسهل.

أدرج إعدادت التطبيق التي تعلم ufw كيف تتعامل معها باستخدام الأمر:

 $ sudo ufw app list

يجب أن تحصل على قائمة بملفات تعريف التطبيق:

المخرجات:

Available applications:

  Nginx Full

  Nginx HTTP

  Nginx HTTPS

  OpenSSH

يوجد ثلاثة ملفات تعريف ل Nginx متاحة كما ترى:

• Nginx Full: يفتح هذا الملف كِلا المنافذ 80 (حركة مرور الويب العادية وغير المشفرة)، والمنفذ 443 (حركة المرور المشفرة TLS/SSL)
• Nginx HTTP: يفتح هذا الملف المنفذ 80 فقط (حركة مرور الويب العادية وغير المشفرة)
• Nginx HTTPS: يفتح هذا الملف المنفذ 443 فقط (حركة المرور المشفرة TLS/SSL)

يستحسن تفعيل الملف الأكثر صرامة والذي لا يزال يسمح بحركة المرور التي تم إعدادها. لأننا لم نقم بإعداد SSL للخادم بعد، نحتاج لتفعيل المنفذ 80 فقط.

يمكنك تفعيله باستخدام الأمر:

 $ sudo ufw allow 'Nginx HTTP'

للتحقق من التغييرات:

 $ sudo ufw status

يجب أن ترى أن حركة المرور باستخدام HTTP مفعلة كما في المخرجات:

المخرجات:

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
Nginx HTTP                 ALLOW       Anywhere                  
OpenSSH (v6)               ALLOW       Anywhere (v6)             
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

خطوة 3 - فحص خادم الويب

بعد انتهاء عملية التثبيت، سيُشغل أوبونتو Nginx. يجب أن يكون خادم الويب يعمل.

يمكننا التحقق من ذلك باستخدام نظام التهيئة systemd عن طريق الأمر:

 $ systemctl status nginx

المخرجات:

● nginx.service - A high performance web server and a reverse proxy server

   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)

   Active: active (running) since Fri 2018-04-20 16:08:19 UTC; 3 days ago

     Docs: man:nginx(8)

 Main PID: 2369 (nginx)

    Tasks: 2 (limit: 1153)

   CGroup: /system.slice/nginx.service

           ├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;

           └─2380 nginx: worker process

كما ترى في الأعلى، يظهر أن الخدمة بدأت بنجاح. لكن الطريقة المثلى لاختبار ذلك هو جلب صفحة من Nginx فعليا.

يمكنك الوصول إلى صفحة Nginx الرئيسية لتتأكد من أن التطبيق يعمل بطريقة صحيحة عن طريق الدخول إلى عنوان بروتوكول الإنترنت (IP) الخاص بالخادم. يمكنك الحصول عليه بعدة طرق.

جرب تنفيذ هذا الأمر على شاشة أوامر الخادم:

 $ ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//'

ستحصل على بعض الأسطر التي يمكنك تجريبها سطرًا تلو الآخر على متصفح الإنترنت لتتأكد إن كانت تعمل.

الطريقة الأخرى هي عبر تنفيذ الأمر التالي، والذي سيعطيك عنوان بروتوكول الإنترنت العام للخادم كما يُرى على المواقع الآخرى على الإنترنت:

 $ curl -4 icanhazip.com

عند حصولك على عنوان بروتوكول الإنترنت الخاص بالخادم، أدخله إلى شريط المتصفح:

 http://your_server_ip

يجب أن ترى الصفحة الرئيسية ل Nginx:

تُضمَّن هذه الصفحة مع Nginx لتأكيد أن Nginx يعمل بطريقة صحيحة.

خطوة 4 - إدارة عملية Nginx

الآن وبما أن خادم الويب أصبح يعمل بطريقة صحيحة، لنراجع بعض أوامر التحكم الأساسية.

لإيقاف خادم الويب نفذ الأمر:

 $ sudo systemctl stop nginx

لِتشغيل خادم الويب عندما يكون موقفا، نفذ الأمر:

 $ sudo systemctl start nginx

لِإيقاف وإعادة تشغيل الخدمة استخدم الأمر:

 $ sudo systemctl restart nginx

إن كنت تقوم بتعديل في إعدادت Nginx، فإنه يٌعيد التحميل بدون قطع اتصالاته. للقيام بذلك نفذ الأمر:

 $ sudo systemctl reload nginx

Nginx مٌعد ليبدأ تلقائيا مع بدء تشغيل الخادم. إن كنت لا تريد ذلك؛ يمكنك إلغاء تفعيل هذه الميزة باستخدام الأمر:

 $ sudo systemctl disable nginx

لإعادة تفعيل هذه الميزة:

 $ sudo systemctl enable nginx

خطوة 5 - إعداد أجزاء الخادم (Server Blocks) (إعداد مستحسن)

عند استخدام خادم Nginx، أجزاء الخادم (شبيهة بالمضيف الوهمي [virtual host] في Apache) تُستخدم لتغليف تفاصيل الإعدادات وتمكين استضافة أكثر من نطاق من خادم واحد. سنقوم بإعداد نطاق ونُسمية example.com، يمكنك استبدال هذا الاسم باسم النطاق الذي تريده. لدى Nginx جزء خادم مُفعَّل تلقائيا على أوبونتو ومُعَد لتشغيل الملفات في مجلد "‎/var/www/html". رغما من أن هذا يعمل بشكل جيد لموقع واحد؛ إلا أنه ليس عمليا إن كنت تستضيف عدة مواقع. عوضا عن التعديل على ‎/var/www/html؛ لنقم بإنشاء بينة هيكلية في ‎/var/www لموقع example.com ونترك ‎/var/www/html في مكانه كَمجلد رئيسي ليعمل في حال طلب أحد العملاء صفحة لا توافق بقية المواقع.

أنشئ مجلدا ل example.com كما يلي مستخدما -p لإنشاء أي مجلدات ضرورية أخرى:

 $ sudo mkdir -p /var/www/example.com/html

ثم قم بمنح ملكية الجلد باستخدام متغير البيئة ‎$USER:

 $ sudo chown -R $USER:$USER /var/www/example.com/html

يجب أن تكون صلاحيات جذور الويب صحيحة إن كنت لم تقم بتعديل قيمة umask يمكنك التأكد من ذلك باستخدام الأمر:

 $ sudo chmod -R 755 /var/www/example.com

قم بإنشاء صفحة كعينة index.html باستخدام الأمر nano على مُحررك المفضل:

 $ nano /var/www/example.com/html/index.html

بداخل هذه الصفحة، ضع عينة HTML التالية:

                /var/www/example.com/html/index.html

<html>
    <head>
        <title>Welcome to Example.com!</title>
    </head>
    <body>
        <h1>Success!  The example.com server block is working!</h1>
    </body>
</html>

بعد الانتهاء احفظ وأغلق الملف.

كي يقوم Nginx بمعالجة هذا المحتوى، فمن الضروري إنشاء جزء خادم (server block) بالموجهات الصحيحة. بدلا من القيام بذلك عبر تعديل ملفالإعداد الافتراضي مباشرة، لنُنشئ ملفًا جديدًا في ‎/etc/nginx/sites-available/example.com:

 $ sudo nano /etc/nginx/sites-available/example.com

قم بنسخ جزء الإعداد التالي الشبيه بالافتراضي لكنه محدث للمجلد واسم المجلد الجديد:

        /etc/nginx/sites-available/example.com

server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

لاحظ أننا قمنا بتحديث إعداد root للمجلد الجديد و server_name لاسم النطاق الجديد.

ثم نقوم بتفعيل الملف من خلال إنشاء رابط منه إلى مجلد sites-enabled والذي يقوم Nginx بالقراءة منه أثناء التشغيل:

 $ sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

الآن أصبح لدينا جزئي خادم مفعلين ومُعدين للاستجابة للطلبات وفقا لموجهي listen و server_name (يمكنك قراءة المزيد حول كيفية معالجة Nginx لهذه الموجهات في هذا المقال

• example.com: سيستجيب للطلب على example.com و www.example.com.
• default: سيستجيب لأي طلبات على المنفذ 80 والتي لا تطابق جزء آخر.

لتجنب مشكلة "hash bucket memory" التي قد تطرأ من إضافة أسماء خوادم إضافية، من الضروري تعديل قيمة واحدة في ملف ‎/etc/nginx/nginx.conf. افتح هذا الملف:

 $ sudo nano /etc/nginx/nginx.conf

ابحث عن الموجّه server_names_hash_bucket_size واحذف رمز # لإلغاء تعليق هذا السطر:

        /etc/nginx/nginx.conf

...
http {
    ...
    server_names_hash_bucket_size 64;
    ...
}
...

ثم نتحقق من عدم وجود من أي أخطاء في جمل ملفات Nginx:

 $ sudo nginx -t

احفظ وأغلق الملف بعد انتهائك.

إن لم يكن هناك أي أخطاء أعد تشغيل Nginx لتفعيل التغييرات:

 $ sudo systemctl restart nginx

يجب أن يقوم Nginx الآن بالاستجابة للطلبات على النطاق الجديد. للتحقق من ذلك، ادخل على http://example.com. هنا يجب أن ترى شيئا كالتالي:

خطوة 6 - التعرف على مجلدات وملفات Nginx المهمة

الآن، وبعد أن أصبحت تعرف كيف تُدير خدمة Nginx. يجب أن تأخذ لمحة سريعة حول بعض المجلدات والملفات المهمة.

المحتوى

• ‎/var/www/html: محتوى الويب الفعلي ل Nginx والذي يحتوي فقط على صفحة Nginx الافتراضية التي رأيناها سابقا. تُعرض هذه الصفحة من مجلد ‎/var/www/html. يمكن تغيير هذا الإعداد عن طريق ملف إعداد Nginx.

إعداد الخادم

• ‎/etc/nginx: مجلد إعداد Nginx والذي يحوي جميع ملفات التكوين.
• ‎/etc/nginx/nginx.conf: ملف تكوين Nginx الرئيسي. يمكن تعديل هذا الملف لتغيير الإعدادات العامة ل Nginx.
• ‎/etc/nginx/sites-available/‎: المجلد الذي يتم تخزين أجزاء الخادم فيه. لن يقوم Nginx باستخدام ملفات التكوين الموجودة في هذا المجلد إلا إذا تم ربطها لمجلد sites-enabled. بشكل عام، يتم تخزين ملفات إعداد أجزاء الخادم في هذا المجلد ثم تُفعّل بربطها بالمجلد الآخر.
• /etc/nginx/sites-enabled/: المجلد الذي يتم تخزين أجزاء الخادم لكل موقع (per-site server blocks) فيه. تُنشئ هذه المجلدات بربط ملفات التكوين الموجودة في مجلد sites-available.
• ‎/etc/nginx/snippets: يحتوي هذا المجلد على أجزاء التكوين التي يمكن تضمينها في أي مكان آخر في تكوين Nginx. أجزاء الإعداد المُكررة عن قصد تُعد بدائل جيدة لإعادة بناء أجزاء الأكواد البرمجية.

سجلات الخادم

• ‎/var/log/nginx/access.log: يتم تخزين كل طلب يصل إلى خادم الويب في ملف السجل هذا إلا إن كان Nginx مُعد لعدم القيام بذلك.
• ‎/var/log/nginx/error.log: يتم تسجيل أي خطأ في Nginx في هذا السجل.

الآن وبما أن خادم الويب أصبح مُعدًا لديك، فلديك عدة خيارات للمحتوى الذي يمكن أن يعالجه الخادم والتقنيات التي يمكن أن تستخدمها لتجربة أفضل.

الخلاصة

إن كنت تريد بناء حزمة تطبيق متكاملة، اطلع على هذا المقال عن كيفية إعداد حزمة LEMP على أوبونتو 18.04.

ترجمة -وبتصرف- للمقال How To Install Nginx on Ubuntu 18.04 لصاحبيه Justin Ellingwood و Kathleen Juell.

نشرح طريقة تثبيت وإعداد خادم Nginx على توزيعة أوبنتو، وسنستعمله لتخديم صفحات HTML الخاصة بنا.

لتثبيت خادم أباتشي راجع فيديو تثبيت وضبط خادم Apache في أكاديمية حسوب.

قسم خوادم الويب في أكاديمية حسوب غني بالمقالات المفيدة للتعامل معها.

مقدّمة

يُعتبر Apache و Nginx اثنين من أشهر خوادم الويب مفتوحة المصدر ويُستخدمان غالباً مع PHP. قد يكون من المفيد تشغيل كل منهما على نفس الجهاز الإفتراضي virtual machine عند استضافة مواقع ويب متعددة ذات متطلباتٍ متنوعة. إنّ الحل العام لتشغيل خوادم الويب على نظام واحد هو استخدام عناوين IP متعددة أو أرقام منافذ مختلفة.

بالإمكان ضبط الخوادم التي تملك كلّا من عناوين IPv4 و IPv6 لخدمة مواقع Apache على أحد البروتوكولين ومواقع Nginx على البروتوكول الآخر، ولكن عمليًا هذا غير مُطبّق حاليًا، نظرًا لأن تبنّي مزودي خدمات الإنترنت لـ IPv6 لا يزال غير شائع. حيث يعدّ وجود رقم منفذ مختلف مثل 81 أو 8080 لخادم الويب الثاني حلاً آخر، ولكن مشاركة عناوين URL بأرقام المنافذ (مثل http://example.com:81) ليس منطقيًّا أو مثاليًّا دائمًا.

سنتعلّم في هذه الدورة كيفيّة ضبط Nginx كخادم ويب وكذلك كوسيط عكسي Reverse Proxy لـ Apache - كل ذلك على خادم واحد.

قد تكون هنالك حاجة اعتمادًا على تطبيق الويب إلى تغييرات في الشفرة ليبقى Apache مُدركًا بالوسيط العكسي، وخاصّة عند ضبط مواقع SSL. سنتجنّب ذلك بتثبيت module وحدة Apache تسمى mod_rpaf والتي تُعيد كتابة متغيرات بيئة معيّنة بحيث يبدو أن Apache يتعامل مباشرة مع الطلبات من عملاء الويب.

ستُضاف أربعة أسماء نِطاقات domain names على خادم واحد. وسيُخدَّم اثنين منهما بواسطة Nginx هما:example.com (المُضيف الظاهري الافتراضي) و sample.org. والاثنين المتبقيين، foobar.net و test.io، سيُخدّمان من قبل Apache. سنُعدّ أيضًا Apache لخدمة تطبيقات PHP باستخدام PHP-FPM، والذي يقدّم أداء أفضل عبر mod_php.

المتطلبات المُسبقة

ستحتاج لإكمال هذه الدورة التعليميّة إلى ما يلي:

• خادم Ubuntu 18.04 جديد تم إعداده من خلال اتباع خطوات الإعداد الأولي للخادم في Ubuntu 18.4، مع مستخدم sudo عادي (non-root) و جدار ناري.
• ضبط أربعة أسماء نطاق مؤهلة بالكامل للإشارة لعنوان IP الخاص بخادمك. انظر الخطوة 3 من كيفية إعداد اسم مضيف فيDigitalOcean كمِثال لكيفية القيام بذلك. إذا كنت تستضيف DNS للنطاقات الخاصّة بك في مكان آخر، فعليك إنشاء سجلات A مناسبة هناك بدلاً من ذلك.

الخطوة 1 - تثبيت Apache و PHP-FPM

لنبدأ بتثبيت Apache و PHP-FPM. سنثبّت أيضًا بالإضافة إلى تثبيت Apache و PHP-FPM، وحدة PHP FastCGI Apache وهيlibapache2-mod-fastcgi، لدعم تطبيقات ويب FastCGI. أولاً، يجب تحديث قائمة الحزم package الخاصّة بك للتأكد من حصولك على أحدث الحزم.

$ sudo apt update

يجب بعد ذلك تثبيت حزم Apache و PHP-FPM:

$ sudo apt install apache2 php-fpm

يجب تنزيل وحدة FastCGI Apache من kernel.org وتثبيتها باستخدام الأمر dpkg لأنّها غير متوفرة في مستودع Ubuntu:

$ Wget https://mirrors.edge.kernel.org/ubuntu/pool/multiverse/liba/
libapache-mod-fastcgi/libapache2-mod-fastcgi_2.4.7~0910052141-1.2_amd64.deb
$ sudo dpkg -i libapache2-mod-fastcgi_2.4.7~0910052141-1.2_amd64.deb 

علينا بعد ذلك تغيير الضبط الافتراضي لخادم Apache من أجل استخدام PHP-FPM.

الخطوة 2 - ضبط Apache و PHP-FPM

سنغيّر في هذه الخطوة رقم منفذ Apache إلى 8080 وضبطه للعمل مع PHP-FPM باستخدام الوحدة mod_fastcgi. أعد تسمية ملف ضبط ports.conf لمخدم Apache:

$ sudo mv /etc/apache2/ports.conf /etc/apache2/ports.conf.default

أنشئ ملف ports.conf جديد مع تعيين المنفذ إلى 8080:

$ echo "Listen 8080" | sudo tee /etc/apache2/ports.conf

ملاحظة: تُضبط خوادم الويب بشكل عام للتنصت على المنفذ 127.0.0.1:8080 عند ضبط الوكيل العكسي، ولكن القيام بذلك سيؤدي إلى ضبط قيمة متغير بيئة (PHP (SERVER_ADDR إلى عنوان IP الاسترجاع بدلاً من عنوان الـ IP العام للخادم. هدفنا هو إعداد Apache بطريقة لا ترى مواقعه على الويب الوكيل العكسي أمامها. لذلك، سنضبطه للتنصت على المنفذ 8080 لجميع عناوين IP. سننشئ بعد ذلك ملف مضيف افتراضي لـ Apache. سيعدّ التوجيه في هذا الملف ليخدّم المواقع فقط على المنفذ 8080. عطّل المضيف الظاهري الافتراضي:

$ sudo a2dissite 000-default

ثم أنشئ ملف مضيف افتراضي جديد، باستخدام الموقع الافتراضي الموجود:

$ sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/001-default.conf

افتح الآن ملف الضبط الجديد:

$ sudo nano /etc/apache2/sites-available/001-default.conf

غيّرمنفذ التنصت إلى 8080: /etc/apache2/sites-available/000-default.conf

	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

احفظ الملف وقم بتنشيط ملف الضبط الجديد:

$ sudo a2ensite 001-default

ثم أعد تحميل Apache:

$  sudo systemctl reload apache2

تحقّق من أن Apache يتنصت الآن على 8080:

$ sudo netstat -tlpn

يجب أن يبدو الخرج output كالمثال التالي، حيث يتنصّت apache2 على المنفذ 8080:

output 

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address 	Foreign Address  	State	PID/Program name
tcp    	0  	0 0.0.0.0:22    	0.0.0.0:*        	LISTEN   1086/sshd
tcp6   	0  	0 :::8080       	:::*             	LISTEN   4678/apache2
tcp6   	0  	0 :::22         	:::*             	LISTEN   1086/sshd

يمكنك إعداد دعم PHP و FastCGI بمجرّد التحقق من أن Apache يتنصت على المنفذ الصحيح.

الخطوة 3 - ضبط Apache لاستخدام mod_fastcgi

يخدّم Apache صفحات PHP باستخدام mod_php افتراضيًا، ولكنه يتطلب إعدادًا إضافيًّا للعمل مع PHP-FPM. ملاحظة: إذا كنت تجرّب هذا الدرس على نسخة موجودة مسبقًا من LAMP مع mod_php، عطّله أولاً باستخدام sudo a2dismod php7.2. سنضيف كتلة ضبط لوحدة mod_fastcgi التي تعتمد على mod_action. يُعطّل mod_action بشكل افتراضي، لذلك نحتاج أولاً إلى تفعيله:

$ sudo a2enmod action

أعد تسمية ملف ضبط FastCGI الموجود:

$ sudo mv /etc/apache2/mods-enabled/fastcgi.conf/etc/apache2/mods
-enabled/fastcgi.conf.default

أنشئ ملف ضبط جديد:

$ sudo nano /etc/apache2/mods-enabled/fastcgi.conf

أضف التوجيهات التالية إلى الملف لتمرير طلبات ملفات php. إلى مقبس PHP-FPM UNIX:

/etc/apache2/mods-enabled/fastcgi.conf

  AddHandler fastcgi-script .fcgi
  FastCgiIpcDir /var/lib/apache2/fastcgi
  AddType application/x-httpd-fastphp .php
  Action application/x-httpd-fastphp /php-fcgi
  Alias /php-fcgi /usr/lib/cgi-bin/php-fcgi
  FastCgiExternalServer /usr/lib/cgi-bin/php-fcgi -socket /run/php/php7.2-fpm.sock -pass-header Authorization
  
	Require all granted
  

احفظ التغييرات واختبر الضبط:

$ sudo apachectl -t

إذا ظهرت عبارة Syntax OK، أعد تحميل Apache:

$ sudo systemctl reload apache2

إذا رأيت رسالة التحذير التالية، يمكنك تجاهلها الآن بشكل آمن. سنَضبط أسماء الخادم في وقت لاحق: 

Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message.

دعنا نتأكد الآن من أنّه بإمكاننا تخديم PHP من Apache.

الخطوة 4 - التحقق من عمل PHP

سَنتأكّد من أن PHP يعمل، وذلك من خلال إنشاء ملف ()phpinfo والوصول إليه من متصفح الويب. أنشئ الملف var/www/html/info.php/ والذي يحتوي على استدعاء للدّالة phpinfo:

$ echo "" | sudo tee /var/www/html/info.php

انتقل في المتصفح إلى http: // your_server_ip: 8080 / info.php لاستعراض هذا الملف. ستظهر لك قائمة إعدادات الضبط التي يستخدمها PHP. كما في الشكل التالي:

تحقّق من أن الخيار Server API يأخذ القيمة FPM/FastCGI وذلك في أعلى الصفحة كما في الصورة السابقة. سترى كذلك في أسفل الصفحة تقريبًا في القسم PHP Variables بأنّ قيمة SERVER_SOFTWARE هي Apache على Ubuntu. وهذا يؤكّد أنّ الوحدة mod_fastcgi مُفعّلة وأنّ Apache يستخدم PHP-FPM لمعالجة ملفات PHP.

الخطوة 5 - إنشاء مضيفات افتراضيّة لـ Apache

دعونا ننشئ ملفات المضيف الافتراضي لـ Apache للنطاقين foobar.net و test.io. سنقوم لعمل ذلك أولاً بإنشاء الأدلّة الجذر للمستند في كِلا الموقعين ووضع بعض الملفات الافتراضيّة في هذه الأدلة حتى نتمكن من اختبار الضبط لدينا بسهولة. أولاً، أنشئ الأدلّة الجذر للمستند:

$ sudo mkdir -v /var/www/foobar.net /var/www/test.io

أنشئ بعد ذلك ملف index لكل موقع:

$ echo "<h1 style='color: green;'>Foo Bar</h1>" | sudo tee /var/www/foobar.net/index.html
$ echo "<h1 style='color: red;'>Test IO</h1>" | sudo tee /var/www/test.io/index.html

" | sudo tee /var/www/test.io/index.html ثم أنشئ ملف ()phpinfo لكل موقع حتى نتمكن من اختبار فيما إذا ضُبط PHP بشكل صحيح.

$ echo "" | sudo tee /var/www/foobar.net/info.php         
$ echo "" | sudo tee /var/www/test.io/info.php

الآن أنشئ ملف المضيف الافتراضي للنطاق foobar.net:

$ sudo nano /etc/apache2/sites-available/foobar.net.conf

أضف الشفرة التالية إلى الملف لتعريف المضيف:

/etc/apache2/sites-available/foobar.net.conf
	
    	ServerName foobar.net
    	ServerAlias www.foobar.net
    	DocumentRoot /var/www/foobar.net
    	
        	AllowOverride All
    	

يتيح السطر AllowOverride All تفعيل دعم htaccess. احفظ وأغلق الملف. ثم أنشئ ملف ضبط مماثل لـ test.io. أولاً أنشئ الملف:

$ sudo nano /etc/apache2/sites-available/test.io.conf

ثم أضف الضبط إلى الملف:

	 /etc/apache2/sites-available/test.io.conf
 
        ServerName test.io
        ServerAlias www.test.io
        DocumentRoot /var/www/test.io
        
            AllowOverride All
        

احفظ الملف وإغلاق المحرّر. والآن بعد إعداد كل من مضيفي Apache الافتراضيين، فعّل المواقع باستخدام الأمر a2ensite. والذي يُنشئ رابط رمزي لمَلف المضيف الافتراضي في الدليل sites-enabled:

$ sudo a2ensite foobar.net
$ sudo a2ensite test.io

تحقّق من Apache للتأكّد من وجود أخطاء في الضبط مرّة أخرى:

$ sudo apachectl –t

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

$ sudo systemctl reload apache2

افتح http://foobar.net:8080 و http://test.io:8080 في متصفحك للتأكّد من عمل المواقع والتحقّق من أنّ كل موقع يعرض ملف index.html الخاص به. سترى النتائج التالية:

تأكّد أيضًا من أن PHP تعمل وذلك عن طريق الوصول إلى ملفات info.php لكل موقع. افتح http://foobar.net:8080/info.php و http://test.io:8080/info.php في متصفحك. سترى قائمة مواصفات ضبط PHP نفسها على كل موقع كما رأيت في الخطوة 4. لدينا الآن موقعين مُستضافين على Apache على المنفذ 8080. فلنَضبط بعد ذلك Nginx.

الخطوة 6 - تثبيت وضبط Nginx

سنقوم في هذه الخطوة بتثبيت Nginx وإعداد ضبط النطاقات example.com و sample.org كمضيفين افتراضيين لـ Nginx. ثبّت Nginx باستخدام مدير الحزم:

$ sudo apt install nginx

أزل الرابط الرمزي الافتراضي للمضيف الافتراضي حيث أننا لن نستخدمه بعد الآن:

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

سنُنشئ الموقع الافتراضي الخاص بنا فيما بعد (example.com). سنُنشئ الآن مضيفين افتراضيين لـ Nginx باستخدام نفس الإجرائيّة التي استخدمناها من أجل Apache. أنشئ أولاً الأدلّة للمستند الجذر لكل من موقعي الويب:

$ sudo mkdir -v /usr/share/nginx/example.com /usr/share/nginx/sample.org

سنحتفظ بمواقع الويب الخاصّة بـ Nginx في /usr/share/nginx، وهو المسار الافتراضي الذي سيختاره Nginx. يمكنك وضع هذه المواقع في /var/www/html مع مواقع Apache، لكن هذا الفصل بينها قد يساعدك على ربط المواقع بـ Nginx. كما فعلت مع مضيفي Apache الافتراضيين، أنشئ ملفات index و ()phpinfo من أجل الاختبار بعد اكتمال الإعداد:

$ echo "<h1 style='color: green;'>Example.com</h1>" | sudo tee /usr/share/nginx/example.com/index.html
$ echo "<h1 style='color: red;'>Sample.org</h1>" | sudo tee /usr/share/nginx/sample.org/index.html
$ echo "<?php phpinfo(); ?>" | sudo tee /usr/share/nginx/example.com/info.php
$ echo "<?php phpinfo(); ?>" | sudo tee /usr/share/nginx/sample.org/info.php

الآن أنشئ ملف مضيف افتراضي للنطاق example.com:

$ sudo nano /etc/nginx/sites-available/example.com

يستدعي Nginx كتل server {. . .} من ملف الضبط server blocks. أنشئ كتلة خادم من أجل المضيف الافتراضي الأساسي example.com. تجعل ضبط التوجيه default_server هذا المضيف كمضيف افتراضي افتراضي لمعالجة طلبات HTTP التي لا تتطابق مع أي مضيف افتراضي آخر.

/etc/nginx/sites-available/example.com
server {
	listen 80 default_server;
 
	root /usr/share/nginx/example.com;
	index index.php index.html index.htm;
 
	server_name example.com www.example.com;
	location / {
    	try_files $uri $uri/ /index.php;
	}
 
	location ~ \.php$ {
    	fastcgi_pass unix:/run/php/php7.2-fpm.sock;
    	include snippets/fastcgi-php.conf;
	}
}

احفظ وأغلق الملف. أنشئ الآن ملف مضيف Nginx افتراضي للنطاق الثاني، sample.org:

$ sudo nano etc/nginx/sites-available/sample.org

أضف ما يلي إلى الملف:

/etc/nginx/sites-available/sample.org
server {
    root /usr/share/nginx/sample.org;
    index index.php index.html index.htm;

    server_name sample.org www.sample.org;
    location / {
        try_files $uri $uri/ /index.php;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php7.2-fpm.sock;
        include snippets/fastcgi-php.conf;
    }
}

احفظ وأغلق الملف. ثم فعّل كِلا الموقعين من خلال إنشاء روابط رمزيّة للدّليل sites-enabled:

$ sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
$ sudo ln -s /etc/nginx/sites-available/sample.org /etc/nginx/sites-enabled/sample.org

اختبر بعد ذلك ضبط Nginx لضمان عدم وجود أخطاء في الضبط:

$ sudo nginx -t

ثم أعد تحميل Nginx إذا لم يكن هناك أخطاء:

$ sudo systemctl reload nginx

الآن قم بالوصول إلى ملف ()phpinfo الخاص بمُضيفي Nginx الافتراضيين من متصفح الويب من خلال زيارة http://sample.org/info.php و http://example.com/info.php. انظر مجدّدًا إلى الصورة في الأسفل إلى قسم المتغيرات PHP Variables.

يجب أن يحوي["SERVER_SOFTWARE"] على القيمة Nginx، مشيرًا إلى أنّ الملفات خُدّمت بشكل مباشر بواسطة Nginx. يجب أن يشير["DOCUMENT_ROOT"] إلى الدليل الذي أنشأته مُسبقًا في هذه الخطوة لكل موقع من مواقع Nginx. ثبّتنا في هذه المرحلة Nginx وأنشأنا مضيفين افتراضيين.سنقوم بعد ذلك بضبط Nginx على طلبات الوكيل المخصّصة للنطاقات المستضافة على Apache.

الخطوة 7 - ضبط Nginx لمضيفي Apache الافتراضيين

لنُنشئ مضيف Nginx افتراضي إضافي مع أسماء نطاقات متعددة في توجيهات server_name. سيتم توكيل طلبات هذه النطاقات إلى Apache. أنشئ ملف مضيف Nginx افتراضي جديد لإعادة توجيه الطلبات إلى Apache:

$ sudo nano /etc/nginx/sites-available/apache

أضف كتلة الشفرة التالية التي تحدد أسماء نطاقات كلاً من مضيفي Apache الاتراضيين وتوكل طلباتها إلى Apache. تذكّر استخدام عنوان IP العام في proxy_pass:

/etc/nginx/sites-available/apache
server {
    listen 80;
    server_name foobar.net www.foobar.net test.io www.test.io;

    location / {
        proxy_pass http://your_server_ip:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

قم بحفظ الملف وتفعيل هذا المضيف الافتراضي الجديد عن طريق إنشاء رابط رمزي:

$ sudo ln -s /etc/nginx/sites-available/apache /etc/nginx/sites-enabled/apache

اختبر الضبط للتأكد من عدم وجود أخطاء:

$ sudo nginx -t

إذا لم يكن هنالك أخطاء، أعد تحميل Nginx:

$ sudo systemctl reload nginx

افتح متصفحك وقم بالوصول إلى العنوان http://foobar.net/info.php. انتقل لأسفل إلى قسم PHP Variables وتحقق من القيم المعروضة كما في الصورة.

يؤكّد المتغيران ERVER_SOFTWARE و DOCUMENT_ROOT أنّ هذا الطلب عُولج بواسطة Apache. وأضيفت المتغيرات HTTP_X_REAL_IP و HTTP_X_FORWARDED_FOR بواسطة Nginx ويجب أن تُظهر عنوان IP العام للحاسب الذي تستخدمه للوصول إلى عنوان URL. لقد أعددنا Nginx بنجاح ليوكل بطلبات نطاقات محدّدة إلى Apache. بعد ذلك، لنقم بضبط Apache لضبط المتغير REMOTE_ADDR كما لو أنه يتعامل مع هذه الطلبات مباشرة.

الخطوة 8 - تثبيت وضبط mod_rpaf

سنُثبّت في هذه الخطوة وحدة Apache تسمى mod\_rpaf والتي تعيد كتابة قيم REMOTE_ADDR، HTTPS و HTTP_PORT استنادًا إلى القيم المقدّمة من قبل وسيط عكسي. وبدون هذه الوحدة، تتطلب بعض تطبيقات PHP تغييرات في الشفرة للعمل بسلاسة من خلفْ الخادم الوكيل. هذه الوحدة موجودة في مستودع Ubuntu باسم libapache2-mod-rpaf ولكنها قديمة ولا تدعم توجيهات ضبط معينة. سنقوم بدلاً من ذلك بتثبيتها من المصدر. تثبيت الحزم اللازمة لبناء الوحدة:

$ sudo apt install unzip build-essential apache2-dev

نزّل أحدث إصدار مستقر من GitHub:

$ wget https://github.com/gnif/mod_rpaf/archive/stable.zip

استخراج الملف الذي نزل:

$ unzip stable.zip

انتقل إلى المجلد الجديد الذي يحتوي على الملفات:

$ cd mod_rpaf-stable

ترجم Compile الوحدة ثم ثبّتها:

$ make
$ sudo make install

أنشئ بعد ذلك ملف في المجلد mods-available والذي سيُحمّل وحدة rpaf:

$ sudo nano /etc/apache2/mods-available/rpaf.load

أضف الشفرة التالية إلى الملف لتحميل الوحدة:

/etc/apache2/mods-available/rpaf.load
LoadModule rpaf_module /usr/lib/apache2/modules/mod_rpaf.so

احفظ الملف وأغلق المحرر. أنشئ ملف آخر في نفس الدليل وسمّه rpaf.conf والذي سوف يحتوي على توجيهات الضبط للوحدة mod_rpaf:

$ sudo nano /etc/apache2/mods-available/rpaf.conf

أضف كتلة الشفرة التالية لضبط mod_rpaf، مع التأكّد من تحديد عنوان IP الخاص بخادمك:

/etc/apache2/mods-available/rpaf.conf
   
        RPAF_Enable           On
        RPAF_Header           X-Real-Ip
        RPAF_ProxyIPs         your_server_ip 
        RPAF_SetHostName      On
        RPAF_SetHTTPS         On
        RPAF_SetPort          On
    

فيما يلي وصف موجز لكل توجيه. لمزيد من المعلومات، راجع ملف mod_rpaf README.

• RPAF_Header - الترويسة المراد استخدامها لعنوان IP الحقيقي للعميل.
• RPAF_ProxyIPs - عنوان IP للوكيل لضبط طلبات HTTP من أجله.
• RPAF_SetHostName - يقوم بتحديث اسم المضيف الافتراضي بحيث يعمل كل من ServerName و ServerAlias.
• RPAF_SetHTTPS - يضبط متغير بيئة HTTPS استنادًا إلى القيمة الموجودة في X-Forwarded-Proto.
• RPAF_SetPort - يضبط متغير بيئة SERVER_PORT. يكون مفيد عندما يكون Apache يعمل خلف وكيل SSL.

احفظ الملف rpaf.conf وقم بتفعيل الوحدة:

$ sudo a2enmod rpaf

يؤدي هذا إلى إنشاء روابط رمزيّة من الملفات rpaf.load و rpaf.conf في الدليل mods-enabled. الآن قم بإجراء اختبار الضبط:

$ sudo apachectl -t

أعد تحميل Apache إذا لم يكن هنالك أخطاء:

$ sudo systemctl reload apache2

قم بالوصول إلى الملف ()phpinfo في الصفحات http://foobar.net/info.php و http://test.io/info.php من متصفحك وتحقق من قسم PHP Variables. الآن سيكون المتغير REMOTE_ADDR هو أيضًا عنوان IP العام للحاسب المحلي لديك. الآن دعنا نعد تشفير TLS / SSL لكل موقع.

الخطوة 9 - إعداد مواقع HTTPS باستخدام Let's Encrypt (اختياري)

سنضبط في هذه الخطوة شهادات TLS / SSL لكل من النطاقات المُستضافة على Apache. سوف نحصل على الشهادات بواسطة [Let's Encrypt](https://letsencrypt.org]. يدعم Nginx إنهاء SSL، لذا من الممكن إعداد SSL بدون تعديل ملفات ضبط Apache. تَضمنْ الوحدة mod_rpaf أن يتم تعيين متغيرات البيئة المطلوبة على Apache لجعل التطبيقات تعمل بسلاسة خلفْ وكيل عكسي لـ SSL. أولاً سنفصل كتل الخادم {...}server من كِلا النطاقين بحيث يمكن أن يكون لكلٍ منهما شهادات SSL خاصّة به. افتح الملف etc/nginx/sites-available/apache/ في المحرّر الخاص بك:

$ sudo nano /etc/nginx/sites-available/apache

عدّل الملف بحيث يبدو مثل هذا، مع foobar.net و test.io في كتل الخادم الخاصّة بهم:

/etc/nginx/sites-available/apache
   server {
        listen 80;
        server_name foobar.net www.foobar.net;

        location / {
            proxy_pass http://your_server_ip:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
    server {
        listen 80;
        server_name test.io www.test.io;

        location / {
            proxy_pass http://your_server_ip:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }

سنستخدم Certbot لإنشاء شهادات TLS/SSL الخاصّة بنا. ستتولى إضافة Nginx plugin" Nginx" مُهمة إعادة ضبط Nginx وإعادة تحميل الضبط عند الضرورة. أولاً، أضف مستودع Certbot المرخّص:

$ sudo add-apt-repository ppa:certbot/certbot

اضغط على ENTER عند مطالبتك بتأكيد رغبتك في إضافة المستودع الجديد. ثم قم بتحديث قائمة الحزم للحصول على معلومات حزمة المستودع الجديدة:

$ sudo apt update

ثم ثبّت حزمة Nginx الخاصّة بـ Certbot باستخدام apt:

$ sudo apt install python-certbot-nginx

وبمجرّد تثبيته، استخدم أمر certbot لإنشاء الشهادات لـ foobar.net و www.foobar.net:

$ sudo certbot --nginx -d foobar.net -d www.foobar.net

يخبر هذا الأمر Certbot ليستخدم ملحق nginx، وباستخدم –d لتحديد الأسماء التي نودّ أن تكون الشهادة صالحة لها. إذا كانت هذه هي المرة الأولى التي تُشغّل فيها certbot، فسَتتم مطالبتك بإدخال عنوان بريد إلكتروني والموافقة على شروط الخدمة. سيتصل بعد القيام بذلك certbot بخادم Let's Encrypt، ثم يشغّل ردّا للتحقق من أنّك تتحكم في النطاق الذي تطلب الحصول على شهادة له. سَيسألك Certbot بعد ذلك عن الطريقة التي ترغب في ضبط إعدادات HTTPS الخاصّة بك:

Output
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-------------------------------------------------------------------------------
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

حدّد خيارك، ثم اضغط على ENTER. سيتم تحديث الضبط، وإعادة تحميل Nginx لتفعيل الإعدادات الجديدة. الآن، نفّذ الأمر للنطاق الثاني:

$ sudo certbot --nginx -d test.io -d www.test.io

انظر في قسم PHP Variables. تم تعيين المتغير SERVER_PORT على القيمة 443 وضبط HTTPS على القيمة on، كما لو أنّه تم الوصول إلى Apache مباشرةً عبر HTTPS. مع ضبط هذه المتغيرات، لن تحتاج تطبيقات PHP إلى إعداد خاص للعمل خلف وسيط عكسي. سنقوم الآن بتعطيل الوصول المباشر إلى Apache.

الخطوة 10 - حظر الوصول المباشر إلى Apache (اختياري)

بما أن Apache يستمع على المنفذ 8080 على عنوان IP العام، فإنّه بإمكان الجميع الوصول إليه. ويمكن حظره من خلال عمل الأمر IPtables التالي في مجموعة قواعد الجدار الناري.

$ sudo iptables -I INPUT -p tcp --dport 8080 ! -s your_server_ip -j REJECT --reject-with tcp-reset

تأكّد من استخدام عنوان IP لخَادمك مكان اللون الأحمر في المثال السابق. بمجرد حظر المنفذ 8080 في الجدار الناري، اختبر عدم إمكانية الوصول إلى Apache. افتح متصفح الويب الخاص بك وحاول الوصول إلى أحد أسماء نطاقات Apache على المنفذ 8080. على سبيل المثال: http://example.com:8080 يجب أن يعرض المتصفح رسالة خطأ "غير قادر على الاتصال" أو "صفحة الويب غير متوفرة". وبضبط خيار IPtables tcp-reset، لن يرى أحد أي اختلاف بين المنفذ 8080 والمنفذ الذي لا يحتوي أيّ خدمةٍ عليه. ملاحظة: عند إعادة تشغيل النظام وبشكل افتراضي لن تبقى قواعد IPtables كما حدّدناها. هناك طرق متعددة للحفاظ على قواعد IPtables، ولكن أسهلها هو استخدام iptables-persistent في مستودع Ubuntu. استكشف هذه المقالة لمعرفة المزيد حول كيفيّة ضبط IPTables. لنضبط الآن Nginx لخدمة ملفات ثابتة لمواقع Apache.

الخطوة 11 - تخديم الملفات الثابتة باستخدام Nginx (اختياري)

عندما يقدم وسيط Nginx طلبات لنطاقات Apache، فإنّه يرسل كل ملف طلب لهذا النطاق إلى Apache. Nginx أسرع من Apache في خدمة الملفات الثابتة مثل الصور، وجافا سكريبت وأوراق الأنماط. لذلك دعونا نضبط ملف مضيف apache افتراضي خاص بـ Nginx لتخديم الملفات الثابتة مباشرة ولكن مع إرسال طلبات PHP إلى Apache. افتح الملف etc/nginx/sites-available/apache/ في محرّرك الخاص:

$ sudo nano /etc/nginx/sites-available/apache

ستحتاج إلى إضافة موضعين location إضافيين لكل كتلة خادم، بالإضافة إلى تعديل أقسام location الموجودة. بالإضافة إلى ذلك، ستحتاج إلى إخبار Nginx بمكان تواجد الملفات الثابتة لكل موقع. إذا قرّرت عدم استخدام شهادات SSL و TLS، فعدّل ملفك بحيث يبدو كالتالي:

/etc/nginx/sites-available/apache
server {
    listen 80;
    server_name test.io www.test.io;
    root /var/www/test.io;
    index index.php index.htm index.html;

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

    location ~ \.php$ {
        proxy_pass http://your_server_ip:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

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

server {
    listen 80;
    server_name foobar.net www.foobar.net;
    root /var/www/foobar.net;
    index index.php index.htm index.html;

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

    location ~ \.php$ {
        proxy_pass http://your_ip_address:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

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

إذا كنت تريد بأن يكون HTTPS متوفرًا أيضًا، فاستخدم الضبط التالي بدلاً من ذلك:

server {
    listen 80;
    server_name test.io www.test.io;
    root /var/www/test.io;
    index index.php index.htm index.html;

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

    location ~ \.php$ {
        proxy_pass http://your_server_ip:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location ~ /\.ht {
        deny all;
    }

    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/test.io/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/test.io/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

server {
    listen 80;
    server_name foobar.net www.foobar.net;
    root /var/www/foobar.net;
    index index.php index.htm index.html;

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

    location ~ \.php$ {
        proxy_pass http://your_ip_address:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location ~ /\.ht {
        deny all;
    }

    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/foobar.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/foobar.net/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
{

إنّ التوجيه try_files يجعل Nginx يبحث عن الملفات في المستند الجذر ويقدّمها مباشرةً. إذا كان الملف له امتداد php.، سيتم تمرير الطلب إلى Apache. حتى إذا لم يُعثر على الملف في المستند الجذر، يُمرّر الطلب إلى Apache لتعمل ميزات التطبيق مثل permalinks بدون أخطاء. تحذير: إنّ التوجيه location ~ /\.ht مهم جداً؛ حيث يمنع Nginx من عرض محتويات ملفات الضبط Apache مثل htaccess. و htpasswd. التي تحتوي على معلومات حساسة. احفظ الملف وقم بإجراء اختبار الضبط:

$ sudo nginx -t

أعد تحميل Nginx إذا نجح الاختبار:

$ sudo service nginx reload

يمكنك للتحقّق من أن العمل تم بشكل صحيح فحص ملفات سجل Apache في var/log/apache2/ ومشاهدة طلبات GET لملفات info.php من test.io و foobar.net. استخدم الأمر tail لمشاهدة الأسطر القليلة الأخيرة من الملف، واستخدم رمز التبديل f- لمشاهدة الملف من أجل التغييرات:

$ sudo tail -f /var/log/apache2/other_vhosts_access.log

قم الآن بزيارة http://test.io/info.php في مستعرض الويب الخاص بك ثم انظر إلى خرج السجل. سترى أن Apache يجيب بالفعل:

Output
test.io:80 your_server_ip - - [01/Jul/2016:18:18:34 -0400] "GET /info.php HTTP/1.0" 200 20414 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36"

ثم قم بزيارة صفحة index.html لكل موقع ولن ترى أي إدخالات للسجّل من قبل Apache. لأن Nginx هو من يخدّمهم. عند الانتهاء من معاينة ملف السجل، اضغط على CTRL + C لإيقاف تعقبّه. باستخدام هذا الإعداد، لن يكون Apache قادرًا على تقييد الوصول إلى الملفّات الثابتة. وللتَحكم في الوصول إلى الملفّات الثابتة تحتاج إلى ضبط في ملف المضيف apache الافتراضي الخاص بـ Nginx، ولكن هذا خارج نطاق هذه الدورة التعليميّة.

الخلاصة

لديك الآن خادم Ubuntu مع Nginx يُخدّم example.com و sample.org، جنبًا إلى جنب مع Apache والذي يُخدّم foobar.net و test.io. على الرغم من أن Nginx يعمل كوكيل عكسي لـ Apache، إلا أن خدمة الوكيل في Nginx تتسم بالشفافية وتُظهر اتصالها بنطاقات Apache كما لو أنها مخدّمة مباشرةً من Apache. يمكنك استخدام هذه الطريقة لتخديم مواقع آمنة وثابتة.

ترجمة بتصرف للمقال How To Configure Nginx as a Web Server and Reverse Proxy for Apache on One Ubuntu 18.04 Server لصاحبه Jesin A.

ما هي Let’s Encrypt

هي هيئة شهادات مجانية تابعة لمجموعة أبحاث أمن الإنترنت-Internet Security Research Group (ISRG)، وتقدم هذه الهيئة طريقة سهلة ومؤتمتة للحصول على شهادات SSL/TLS مجانية لجعل الزيارات على خادم الويب مشفرة وعبر بروتوكول HTTPS. ومعظم خطوات الحصول على الشهادة وتثبيتها يمكن جعلها تتم تلقائيًا باستخدام أداة Certbot.
وهذه الأداة يمكن استخدامها حين يتسنى الاتصال بالخادم عبر SSH، أي حين يوجد دخول من الصدفة “Shell” على الخادم. وسنرى في هذا المقال كيف نستخدم Certbot للحصول على شهادة SSL مجانية ومن ثم استخدامها مع NGINX على خادم أوبنتو 16.04

تثبيت Certbot

سنضيف مستودع Certbot أولًا، لماذا؟ لأن مطوريه يقومون على صيانة وتحديث هذا المستودع بآخر إصدار من Certbot أولًا بأول، بشكل أسرع مما تفعله أوبنتو بالبرنامج في مستودعاتها، فأوبنتو تحتاج وقتًا لمراجعة كل برنامج يدخل مستودعاتها، خاصة إن كان في إصدار LTS مثل 16.04، وبالتالي فمن الطبيعي أن يتأخر كل برنامج قليلًا حتى يدخل تلك المستودعات.
والآن، لإضافة مستودع Certbot:

# add-apt-repository ppa:certbot/certbot

ثم نحدّث قائمة APT

# apt-get update

ونثبّت البرنامج

# apt-get install certbot

الحصول على الشهادة

هناك العديد من إضافات Certbot التي يمكن الحصول على شهادة SSL من خلالها، ويقوم مدير الخادم بتثبيتها وتهيئة الخادم بعد ذلك بنفسه. وسنستخدم إضافة Webroot في هذا المقال، وهي إضافة تصلح للحالات التي يمكن فيها تعديل المحتوى، ولسنا في حاجة لإيقاف الخادم أثناء عملية تصدير الشهادة.

تهيئة NGINX

تنشئ Webroot ملفًا مؤقتًا لكل نطاق في مجلد مخفي اسمه well-known، موجود في المجلد الجذر لـweb، وفي حالتنا فإن مجلد web موجود في var/www/html/.
تأكد أن Let’s Encrypt لديها صلاحية الوصول لهذا المجلد، من خلال تعديل تهيئة NGINX. ولفعل ذلك، نفذ هذا الأمر لفتح الملف الذي سنعدّل فيه (استبدل $EDITOR بمحرر نصي من تفضيلك):

# $EDITOR /etc/nginx/sites-available/default

ضع هذه الأسطر في قسم server داخل الملف:

 location ~ /.well-known {
    allow all;
 }

احفظ الملف واخرج، ثم تفقد تهيئة NGINX عبر الأمر التالي:

# nginx -t

ويجب أن ترى هذين السطرين -بفرض نجاح الأمر-:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

والآن أعد تشغيل NGINX:

# systemctl restart nginx

الحصول على الشهادة باستخدام Certbot

الخطوة التالية هي الحصول على شهادة جديدة باستخدام Certbot مع إضافة Webroot. وسنؤمّن في هذا الشرح (كمثال) نطاق www.example.com عبر الأمر التالي: (لا تنسى أنك يجب أن تحدد كل نطاق تريد تأمينه بهذه الشهادة).

# certbot certonly --webroot --webroot-path=/var/www/html -d www.example.com

سيسألك Certbot خلال العملية عن بريد إلكتروني صالح من أجل الإشعارات، وسيطلب منك مشاركته مع EFF، غير أن ذلك غير ضروري، وسيكون لديك الشهادةبعد الموافقة على شروط الخدمة.
وبعد انتهاء العملية، سيحتوى مجلد etc/letsencrypt/archive/ على الملفات التالية:

• chain.pem: شهادة السلسلة-Chain Certificate الخاصة بـLet’s Encrypt.
• cert.pem: شهادة النطاق.
• fullchain.pem: دمج للشهادتين السابقتين.
• privkey.pem: المفتاح الخاص للشهادة.

كما سينشئ Certbot روابط رمزية لآخر ملفات الشهادة في etc/letsencrypt/live/domain_name/، وهو المسار الذي سنستخدمه في تهيئة الخادم.

تهيئة SSL/TLS على NGINX

الخطوة التالية هي تهيئة الخادم، أنشئ قصاصة-snippet جديدة في etc/nginx/snippets، تلك القصاصة هي جزء من ملف تهيئة يمكن إدراجه في ملفات تهيئة المضيف الوهمي-virtual host. أنشئ ملف جديد (استخدم محررك النصي بدلًا من $EDITOR)

# $EDITOR /etc/nginx/snippets/secure-example.conf

محتويات هذا الملف ستكون الموجّهات التي تحدد مواقع الشهادة والمفتاح، الصق المحتوى التالي في الملف:

ssl_certificate /etc/letsencrypt/live/domain_name/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain_name/privkey.pem;

في مثالنا الذي نشرحه، سيكون domain_name هو example.com.

تعديل تهيئة NGINX

افتح الملف الافتراضي للمضيف الوهمي:

# $EDITOR /etc/nginx/sites-available/default

عدل محتواه كما يلي:

server {
 listen 80 default_server;
 listen [::]:80 default_server;
 server_name www.example.com
 return 301 https://$server_name$request_uri;

 # SSL configuration
 #
 listen 443 ssl default_server;
 listen [::]:443 ssl default_server;
 include snippets/secure-example.conf
 #
 # Note: You should disable gzip for SSL traffic.
 # See: https://bugs.debian.org/773332
…

كان هذا الكود من أجل تفعيل التشفير في NGINX، احفظ الملف واخرج ثم تأكد من ملف تهيئة NGINX:

# nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
أعد تشغيل NGINX:
# systemctl restart nginx

خاتمة

إن اتبعت الخطوات السابقة فيجب أن يكون لديك الآن خادم آمن مبني على NGINX، مع تشفير من Certbot وLet’s Encrypt. وهذه إعدادات أساسية قطعًا، فيمكنك استخدام معاملات-parameters كثيرة في NGINX لتعديل تهيئته وتخصيصه، حسب حاجة خادم الويب.

ترجمة -بتصرف- لمقال Encryption: How To Secure an NGINX web server on Ubuntu 16.04 لصاحبه Giuseppe Molica

تمهيد

كلما كانت صفحات الموقع أسرع تحميلًا كلما ازداد احتمال بقاء الزائر متصفحًا للموقع، وعندما تمتلئ صفحات مواقع الويب بالصور والمحتوى التفاعلي الظاهر عبر سكربتات تُحمَّل في الخلفية، فلن تكون عملية فتح «صفحة» ويب أمرًا هينًا، إذ تتضمن طلب ملفاتٍ عدِّة من خادوم الويب ملفًا ملفًا، وعملية تقليل تلك الطلبيات هي إحدى سُبُل تسريع موقعك.

يمكن فعل ذلك بطرائق عدِّة، لكن إحدى أهم الخطوات التي يجب إجراؤها هي ضبط التخزين المؤقت في المتصفح (browser caching)؛ وهذا يعني إخبار المتصفح بإمكانية استخدام نسخ محلية من الملفات التي حُمِّلَت في إحدى المرات بدلًا من طلبها من الخادوم مرارًا وتكرارًا؛ ولفعل ذلك يجب إضافة ترويسات لرد HTTP ‏(HTTP response headers) تخبر المتصفح بما عليك فعله.
هذا هو دور وحدة header (‏header module) في خادوم Nginx، التي يمكن استعمالها لإضافة الترويسات إلى رد HTTP، لكن دورها الأساسي يمكن في ضبط الترويسات المسؤولة عن التخزين المؤقت. سننظر في هذا الدرس إلى كيفية استخدام وحدة header لتطبيق الفكرة السابقة.

المتطلبات المسبقة

ستحتاج قبل إكمال قراءة هذا الدرس إلى ما يلي:
خادوم أوبنتو 16.04 (أو 14.04) مضبوطٌ كما في درس «الإعداد الابتدائي لخادوم أوبنتو 14.04»، بما في ذلك إعداد حساب مستخدم عادي لكنه يملك امتيازات الجذر (root) عبر الأداة sudo.
خدمة Nginx مثبّتة على خادومك باتباعك لهذا الدرس «تنصيب، إعداد واستخدام nginx كخادوم ويب».
سنحتاج بالإضافة إلى وحدة header إلى وحدة map التابعة لخادوم Nginx؛ لمزيدٍ من المعلومات حول وحدة map، فاقرأ درس كيفية استخدام وحدة map على خادوم أوبنتو 16.04.

الخطوة الأولى: إنشاء ملفات للتجربة

سنُنشِئ في هذه الخطوة عدِّة ملفات في مجلد Nginx، إذ سنستخدم هذه الملفات لاحقًا للتحقق من سلوك خادوم Nginx الافتراضي لاختبار أنَّ التخزين المؤقت في المتصفح يعمل عملًا صحيحًا.
لتقرير ما هو نوع الملفات المُخدَّمة عبر الشبكة، فلن يُحلِّل Nginx محتويات الملف لأن ذلك يستهلك وقتًا كثيرًا؛ وإنما سينظر إلى لاحقة (أو امتداد) الملف لتحديد ما هو نوع MIME التابع له، والذي سيُصرِّح عن الهدف أو الغاية من الملف.
ونتيجةً لهذا السلوك، فلن يكون لمحتوى الملفات الاختبارية أيّة أهمية؛ إذ سنستطيع خداع خادوم Nginx بتسمية الملفات تسميةً صحيحةً، فقد يظن خادوم Nginx أنَّ ملفًا فارغًا يُمثِّل صورةً وآخر يُمثِّل سكربت JavaScript.
لنُنشِئ ملفًا باسم test.html في مجلد Nginx الافتراضي عبر الأداة truncate (يمكنك استخدام أيّة أداة أو أمر آخر وليكن touch مثلًا). لاحقة الملف تُشير إلى أنَّه مستند HTML:

sudo truncate -s 1k /var/www/html/test.html

لنُنشِئ المزيد من الملفات الاختبارية بنفس الطريقة السابقة: صورة jpg وملف css وسكربت js:

sudo truncate -s 1k /var/www/html/test.jpg
sudo truncate -s 1k /var/www/html/test.css
sudo truncate -s 1k /var/www/html/test.js

الخطوة التالية هي التحقق من سلوك خادوم Nginx فيما يتعلق بإرسال ترويسات للتحكم بالتخزين المؤقت للمتصفح وذلك بتخديم الملفات التي أنشأناها أخيرًا مع الضبط الافتراضي له.

الخطوة الثانية: التحقق من السلوك الافتراضي لخادوم Nginx

يكون لجميع الملفات نفس سلوك التخزين المؤقت افتراضيًا. ولرؤية ذلك سنستخدم ملف HTML الذي أنشأناه في الخطوة الأولى، إلا أنَّك تستطيع إجراء هذا الاختبار على أيّ ملف من الملفات التي أنشأناها سابقًا.
لنتحقق من أنَّ الملف test.html يُخدَّم ومعه المعلومات التي لها علاقة بالمدة الواجب تخزين المتصفح للملف فيها مؤقتًا. سيؤدي الأمر الآتي إلى طلب الملف من خادوم Nginx المحلي ويُظهِر ترويسات رد HTTP:

curl -I http://localhost/test.html

يجب أن ترى عدِّة ترويسات HTTP:

HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:12:26 GMT
Content-Type: text/html
Content-Length: 1024
Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT
Connection: keep-alive
ETag: "57d40685-400"
Accept-Ranges: bytes

يمكنك أن تلاحظ السطر قبل الأخير الذي يبدأ بالكلمة ETag الذي يتضمن مُعرِّفًا فريدًا للنسخة الحالية من الملف المطلوب. فإذا حاولت تنفيذ أمر curl السابق أكثر من مرة فستجد نفس قيمة ETag.
أما عند استخدام متصفح ويب، فستُخزَّن قيمة ETag ثم تُرسَل إلى الخادوم عبر ترويسة If-None-Match عندما يريد المتصفح أن يطلب نفس الملف مرةً أخرى (عند تحديث الصفحة على سبيل المثال).
يمكنك محاكاة ذلك في سطر الأوامر بالأمر الآتي. احرص على تغيير قيمة الترويسة If-None-Match في الأمر لتُطابِق قيمة ETag في ناتج الأمر السابق:

curl -I -H 'If-None-Match: "57d40685-400"' http://localhost/test.html

ستجد أنَّ الرد أصبح مختلفًا الآن:

HTTP/1.1 304 Not Modified
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:20:31 GMT
Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT
Connection: keep-alive
ETag: "57d40685-400"

ردّ خادوم Nginx بحالة «‎304 Not Modified»، ولن يُرسِل الملف عبر الشبكة مجددًا، وإنما يخبر المتصفح أنَّه يستطيع إعادة استخدام الملف المُخزَّن محليًا والذي نزَّله سابقًا.
ما سبق مفيدٌ لأنه يُقلِّل من التراسل الشبكي، لكنه ليس مثاليًا لتحقيق أداءٍ عالٍ نتيجةٍ للتخزين المؤقت. المشكلة مع ترويسة ETag أنَّ المتصفح سيرسل الطلبية إلى الخادوم دائمًا ويسأله إن كان بإمكانه استخدام الملف المُخزَّن مؤقتًا، وحتى لو ردّ الخادوم على المتصفح بالإيجاب بحالة 304 بدلًا من إعادة إرسال الملف مجددًا، إلا أنَّ إرسال الطلبية واستلام الرد سيستهلك وقتًا.
سنستخدم في الخطوة التالية وحدة headers لإضافة معلومات للتحكم بالتخزين المؤقت. وهذا سيجعل المتصفح يُخزِّن الملفات محليًا دون أخذ إذن الخادوم أولًا.

الخطوة الثالثة: ضبط ترويستَي Cache-Control و Expires

إضافةً إلى ترويسة التحقق من تغيّر الملف (ETag)، هنالك ترويستان للتحكم بالتخزين المؤقت هما Cache-Control و Expires. ترويسة Cache-Control هي نسخةٌ أحدث، وفيها خياراتٌ أكثر مقارنةً بترويسة Expires وهي أفيد إن شئت التحكم بسلوك التخزين المؤقت تحكمًا دقيقًا.
إذا ضُبِطَت تلك الترويسات، فهي تخبر المتصفح أنَّ الملف المطلوب يمكن أن يُخزَّن محليًا لفترةٍ زمنيةٍ معيّنة (تستطيع أن تجعل صلاحيته «للأبد»!) دون طلبه مرةً أخرى. أما إن لم تُضبَط تلك الترويسات، فسيطلب المتصفحُ الملفَ دومًا من الخادوم، متوقعًا أن يحصل على الحالة «‎200 OK» أو «‎304 Not Modified».
يمكننا استخدام وحدة header لإرسال ترويسات HTTP آنفة الذكر. وحدة header هي وحدةٌ من أساس خادوم Nginx لذا لن تحتاج إلى تثبيت أيّ شيءٍ لاستخدامها.
لإضافة وحدة header، افتح ملف ضبط Nginx في محرر nano أو أيّ محررٍ نصيٍ تشاء:

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

اعثر على القسم المُعَنوَنَ server، والذي يبدو كما يلي:

. . .
# Default server configuration
#

server {
    listen 80 default_server;
    listen [::]:80 default_server;

. . .

أضف القسمَين الآتيين: أولهما قبل قسم server لتعريف المدة الزمنية لتخزين مختلف أنواع الملفات مؤقتًا، وثانيهما داخل كتلة server الذي يضبط ترويسات التخزين المؤقت ضبطًا سليمًا:

. . .
# Default server configuration
#

# Expires map
map $sent_http_content_type $expires {
    default                    off;
    text/html                  epoch;
    text/css                   max;
    application/javascript     max;
    ~image/                    max;
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    expires $expires;
. . .

القسم الموجود قبل قسم server هو قسم map الذي يربط بين أنواع الملفات ومدة التخزين المؤقت لهذا النوع من الملفات. استعملنا عدِّة خيارات ضبط فيه:
القيمة الافتراضية هي off، والتي لن تُضيف أيّة ترويسات للتحكم بالتخزين المؤقت، وهذا خيارٌ جيدٌ للمحتوى الذي لا يتطلب تخزينًا مؤقتًا.
لنوع text/html سنضبط القيمة إلى epoch وهي قيمةٌ خاصةٌ التي تعني عدم التخزين المؤقت نهائيًا، مما يجبر المتصفح على السؤال إن كانت الصفحة مُحدَّثة.
لنوع text/css و application/javascript -والتي هي ملفات الأنماط CSS وسكربتات JavaScript- سنضبط القيمة إلى max وهذا يعني أنَّ المتصفح سيُخزِّن هذه الملفات مؤقتًا أطول مدة يستطيعها، مما يُقلِّل عدد الطلبيات لوجود عدد كبير من هذه الملفات التي ترتبط بصفحة HTML.
آخر خيار لنوع ‎~image/‎ وهو تعبيرٌ نمطيٌ (regular expression) الذي يُطابِق جميع الملفات ذات النوع الذي يحتوي على العبارة image/‎ فيه (مثل image/jpg و image/png). وكما في ملفات CSS و JS، تتواجد عادةً صورٌ كثير في مواقع الويب، ومن الجيد تخزينها محليًا، لذا ضبطنا القيمة إلى max أيضًا.
التعليمة expires داخل قسم server (التي هي جزءٌ من وحدة headers) تضبط ترويسات التحكم بالتخزين المؤقت؛ حيث تستخدم القيمة المأخوذة من المتغير ‎$expires الذي يربط بين أنواع الملفات ومدة صلاحيتها. وبهذه الطريقة ستختلف الترويسات المُرسَلة اعتمادًا على نوع الملف.
احفظ الملف واخرج من المُحرِّر النصي، وأعد تشغيل خادوم Nginx لتفعيل الضبط الجديد:

sudo systemctl restart nginx

سنتحقق في الخطوة التالية من أنَّ الضبط الجديد يعمل عملًا سليمًا.

الخطوة الرابعة: اختبار التخزين المؤقت في المتصفح

لنُنفِّذ نفس الأمر الذي طلبنا فيه ملف HTML في القسم السابق:

curl -I http://localhost/test.html

سيكون الرد مختلفًا هذه المرة، إذ يجب أن ترى ترويستين جديدتين:

HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:48:53 GMT
Content-Type: text/html
Content-Length: 1024
Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT
Connection: keep-alive
ETag: "57d40685-400"
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Cache-Control: no-cache
Accept-Ranges: bytes

ترويسة Expires مرتبطة بتاريخٍ في الماضي وترويسة Cache-Control مضبوطةٌ إلى no-cache، مما يجعل المتصفح يسأل الخادوم إن توفرت نسخةٌ جديدةٌ من الملف (باستخدام ترويسة ETag كما سبق).
ستجد ردًا مختلفًا عندما تُجرِّب على صورة:

curl -I http://localhost/test.jpg

ناتج الأمر السابق:

HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:50:41 GMT
Content-Type: image/jpeg
Content-Length: 1024
Last-Modified: Sat, 10 Sep 2016 13:11:36 GMT
Connection: keep-alive
ETag: "57d40688-400"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes

ارتبطت الترويسة Expires في هذه المرة بتاريخٍ في المستقبل البعيد، واحتوت ترويسة Cache-Control على max-age التي تخبر المتصفح كم ثانية يجب أن يُبقي على الملف. وهذا يُخبِر المتصفح أن يُخزِّن الصورة المُنزَّلة مؤقتًا لأطول مدة ممكنة، وبالتالي إذا ظهرت الصورة مرةً أخرى فستُستعمَل النسخة المحلية ولن تُرسَل الطلبية إلى الخادوم بتاتًا.
يجب أن تكون النتيجة مشابهةً لملفَي test.js و test.css لأنهما ملفا JavaScript و CSS ويُضبَط لهما ترويسات التخزين المؤقت أيضًا، مَثَلُهُما كَمَثل الصور.
إن ظهر عندك مثلما عرضنا في أمثلتنا، فاعلم أنَّ ترويسات التحكم بالتخزين المؤقت قد ضُبِطَت ضبطًا صحيحًا وسيستفيد موقعك من ناحية الأداء، وسيقل الحِمل على خادومك نتيجةً لتخزين المتصفح للملفات محليًا وعدم طلبها من الخادوم. عليك الآن أن تُخصِّص إعدادات التخزين المؤقت اعتمادًا على محتوى موقعك، لكن قد تجد أنَّ الضبط الذي وفرناه في هذا الدرس مناسبًا لتبدأ منه.

الخلاصة

يمكن أن تُستعمَل وحدة headers لإضافة أي نوع من الترويسات إلى رد HTTP، لكن من أفضل تطبيقات هذه الوحدة هو ضبط ترويسات التحكم بالتخزين المؤقت. إذ سيساعد ذلك في تحسين أداء مواقع الويب المُستضافة على خادومك، خصوصًا في الشبكات ذات زمن التأخير المرتفع (نسبيًا) مثل شبكات الهواتف المحمولة. يمكن أن يؤدي ذلك إلى تحسين ظهور موقعك في محركات البحث التي تأخذ عامل سرعة الموقع بالحسبان. حيث يُعتَبَر ضبط ترويسات التخزين المؤقت من أبزر نصائح أدوات اختبار سرعة الصفحات من Google (أقصد Google PageSpeed).
لمزيدٍ من المعلومات التفصيلية عن وحدة headers، فارجع إلى توثيق Nginx الرسمي.
ترجمة -وبتصرّف- للمقال How to Implement Browser Caching with Nginx’s header Module on Ubuntu 16.04 لصاحبه Mateusz Papiernik.

سنتعلّم في هذا الدّرس كيفيّة استخدام HAProxy (والذي يرمز إلى الوسيط عالي التوفّر High Availability Proxy) كمُوازِن حمل عن طريق الطبقة السّابعة layer 7 load balancer من أجل تخديم تطبيقات متعدّدة من اسم مجال واحد Single Domain أو عنوان IP، بإمكان موازنة الحمل أن تزيد أداء، توفّر، ومرونة بيئتنا.

تكون موازنة الحمل والوسيط العكسي للطبقة 7 ملائمة لموقعك إن أردت أن تملك اسم نطاق واحد يقوم بتخديم تطبيقات متعدّدة، حيث يمكن تحليل طلبات http لتقرّر أي تطبيق ينبغي عليه أن يستقبل حركة مرور البيانات.

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

المتطلبات الأساسية

قبل متابعة هذا الدّرس ينبغي عليك أن تملك تطبيقين على الأقل يعملان على خادومين منفصلين، سنستخدم موقعًا ثابتًا مستضافًا على Nginx و ووردبريس كتطبيقين لدينا،

وبالإضافة للبيئة الحاليّة لديك سنقوم بإنشاء الخواديم التالية:

• haproxy-www: وهو خادوم HAProxy لأجل موازنة الحمل والوسيط العكسي
• wordpress-2: وهو خادوم الويب الثاني لووردبريس (تحتاجه فقط إن أردت موازنة حمل مكونات ووردبريس في بيئتك)
• web-2: خادوم ويب Nginx الثاني (تحتاجه فقط إن أردت موازنة حمل مكونات Nginx في بيئتك)

إن لم يسبق لك التّعامل مع المفاهيم أو المصطلحات الأساسيّة لموازنة الحمل، مثل موازنة الحمل عن طريق الطبقة 7 أو الواجهات الخلفيّة backends أو قوائم تحكّم الوصول ACLs فهذا هو الدّرس الذي يشرح الأساسيّات: مقدّمة إلى HAProxy ومبادئ موازنة الحمل (Load Balancing).

هدفنا

بنهاية هذا الدّرس نريد أن نحصل على بيئة تبدو كما يلي:

أي سيقوم المستخدمون لديك بالنفاذ لكلا تطبيقيك عبر http://example.com، وسيتم تمرير كل الطلبات التي تبدأ بـ http://example.com/wordpress إلى خواديم ووردبريس، ويتم تمرير جميع باقي الطلبات إلى خواديم Nginx الأساسيّة، لاحظ أنّه لا تحتاج بالضرورة لموازنة حمل تطبيقاتك حتى تظهر على مجال واحد، ولكن سنقوم بتغطية موازنة الحمل في هذا الدّرس.

تثبيت HAProxy

نقوم بإنشاء خادوم جديد مع الشّبكات الخاصّة، سنسمّيه في هذا الدّرس haproxy-www.

نقوم بتثبيت HAProxy على الخادوم haproxy-www باستخدام apt-get:

sudo apt-get update
sudo apt-get install haproxy

نحتاج لتمكين سكريبت التهيئة init script لـ HAProxy كي يبدأ ويتوقف HAProxy مع الخادوم لدينا:

sudo vi /etc/default/haproxy

نغيّر قيمة ENABLED إلى 1 لتمكين سكريبت التهيئة لـ HAProxy:

ENABLED=1

نقوم بالحفظ والخروج، سيبدأ ويتوقف HAProxy الآن مع خادومنا، نستطيع أيضًا الآن استخدام الأمر service للتحكّم بـ HAProxy، فلنتحقّق من أنّه قيد التشغيل:

user@haproxy-www:/etc/init.d$ sudo service haproxy status
haproxy not running.

نجد أنّه لا يعمل، لا مشكلة لأنّه يحتاج إلى إعداده قبل أن نتمكّن من استخدامه، فلنقم الآن بإعداد HAProxy لأجل بيئتنا.

إعداد HAProxy

يكون ملف إعدادات HAProxy مُقسّمًا إلى قسمين رئيسيين:

• العمومي Global: يقوم بتعيين المُعامِلات parameters على نطاق العمليّة
• الوسطاء Proxies: يتكون من المُعامِلات الافتراضيّة defaults، الاستماع listen، الواجهة الأماميّة frontend، والواجهة الخلفيّة backend.

مرّة أخرى إن لم يسبق لك أن سمعت عن مفاهيم أو المصطلحات الأساسيّة لموازنة الحمل، فقم بالرجوع إلى هذا الدّرس: مقدّمة إلى HAProxy ومبادئ موازنة الحمل (Load Balancing).

إعداد HAProxy: العمومي

يجب أن يتم ضبط إعدادات HAProxy على الخادوم haproxy-www.

في البداية لنقم بعمل نسخة من الملف haproxy.cfg الافتراضي:

cd /etc/haproxy; sudo cp haproxy.cfg haproxy.cfg.orig

نقوم الآن بفتح الملف haproxy.cfg باستخدام مُحرِّر نصوص:

sudo vi /etc/haproxy/haproxy.cfg

سنشاهد وجود قسمين معرّفين مسبقًا: global و defaults، سنلقي نظرة في البداية على بعض المعاملات القياسية default.

تحت القسم defaults نبحث عن الأسطر التالية:

mode http
option httplog

يقوم اختيار http كوضع بضبط HAProxy ليعمل كموازن حمل عن طريق الطبقة 7 (أو طبقة التطبيقات)، يعني هذا أنّ موازن الحمل سينظر إلى محتوى طلبات http ويقوم بتمريرها إلى الخادوم المناسب اعتمادًا على القواعد المعرّفة في الواجهة الأماميّة frontend، إن لم يكن هذا المفهوم مألوفًا لديك فمن فضلك اقرأ قسم أنواع موازنة الحمل في درس مقدّمة إلى HAProxy.

لا تقم بإغلاق ملف الإعدادات الآن، لأنّنا سنضيف إعدادات الوسيط.

إعداد HAProxy: الوسطاء

إعداد الواجهة الأماميّة

أول شيء نريد إضافته هو واجهة أماميّة frontend، ولأجل إعداد أساسي لوسيط عكسي وموازنة حمل عن طريق الطبقة 7 سنحتاج لتعريف قائمة تحكّم وصول ACL تُستخدَم لتوجيه حركة مرور بياناتنا إلى خواديم الواجهة الخلفيّة المناسبة، هنالك العديد من قوائم تحكّم الوصول التي يُمكن استخدامها في HAProxy، سنغطي فقط واحدة منها في هذا الدّرس (وهي path_beg)، ولأجل الحصول على قائمة كاملة من قوائم تحكّم الوصول في HAProxy قم بمراجعة التّوثيق الرسميّ: HAProxy ACLs.

نضيف واجهتنا الأماميّة www في نهاية الملف، تأكّد من أن تضع عنوان IP الخاص بخادوم haproxy-www لديك بدلًا من haproxy_www_public_IP:

frontend www
  bind haproxy_www_public_IP:80
  option http-server-close
  acl url_wordpress path_beg /wordpress
  use_backend wordpress-backend if url_wordpress
  default_backend web-backend

وهذا شرح لما يعنيه كل سطر من المقطع السابق المأخوذ من إعدادات الواجهة الأماميّة:

• frontend www: يُعيِّن واجهة أماميّة اسمها "www"، حيث سنستخدمها للتعامل مع حركة مرور بيانات www الواردة.
• bind haproxy_www_public_IP:80: ضع عنوان IP خادوم haproxy-www لديك بدلًا من haproxy_www_public_IP، يُخبر هذا السطر HAProxy أنّ هذه الواجهة الأماميّة ستتعامل مع حركة مرور بيانات الشبكة الواردة إلى عنوان IP هذا على هذا المنفذ.
• option http-server-close: يقوم بتمكين وضع إغلاق اتصال HTTP على الخادوم، ويحافظ على القدرة على دعم ترويسة HTTP keep-alive وتقنيّة HTTP pipelining على العميل (وهي تقنيّة لإرسال العديد من طلبات HTTP ضمن اتصال TCP وحيد بدون انتظار الموافقة لها)، يسمح هذا الخيار بأن يقوم HAProxy بمعالجة طلبات متعدّدة للعميل ضمن اتصال وحيد، والذي عادة ما يزيد من الأداء.
• acl url_wordpress path_beg /wordpress: يُعيِّن قائمة تحكّم وصول ACL تُدعى url_wordpress والتي تكون قيمتها صحيحة true إن كان مسار الطلب يبدأ بـ "wordpress/"، على سبيل المثال http://example.com/wordpress/hello-world.
• use_backend wordpress-backend if url_wordpress: يقوم بإعادة توجيه أي حركة مرور بيانات تتوافق مع قائمة تحكّم الوصول url_wordpress إلى wordpress-backend، والتي سنقوم بتعريفها قريبًا.
• default_backend web-backend: يُحدِّد أنّه أي حركة مرور بيانات لا تتوافق مع قاعدة use_backend سيتم تمريرها إلى web-backend، والتي سنقوم بتعريفها في الخطوة القادمة.

إعداد الواجهة الخلفية Backend

بعد أن تنتهي من إعداد الواجهة الأماميّة، قم الآن إضافة واجهتك الخلفيّة الأولى عن طريق إضافة الأسطر التالية، تأكّد من أن تضع عنوان IP المناسب بدلًا من web_1_private_IP:

backend web-backend
server web-1 web_1_private_IP:80 check

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

• backend web-backend: يُعيِّن واجهة خلفيّة تُدعى web-backend.
• server web-1 ... : يُعيِّن خادوم واجهة خلفيّة يُدعى web-1، مع عنوان IP الخاص (وهو الذي يجب أن تستبدله) والمنفذ الذي يستمع عليه، وهو 80 في هذه الحالة، يُخبِر الخيار check مُوازِن الحمل أن يُجري دوريًّا تحقّق من السّلامة على هذا الخادوم.

بعدها أضف الواجهة الخلفيّة لتطبيق ووردبريس لديك:

backend wordpress-backend
reqrep ^([^\ :]*)\ /wordpress/(.*) \1\ /\2
server wordpress-1 wordpress_1_private_IP:80 check

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

• backend wordpress-backend: يُعيِّن واجهة خلفيّة تُدعى wordpress-backend.
• reqrep ... : يعيد كتابة الطلبات من wordpress/ إلى / عند تمرير حركة مرور البيانات إلى خواديم ووردبريس، وهو ليس ضروريًّا إن كان تطبيق ووردبريس مُثبّتًا على جذر root الخادوم ولكن نحتاج إليه لقابلية النفاذ عبر wordpress/ على خادوم HAProxy.
• server wordpress-1 ... : يُعيِّن خادوم واجهة خلفيّة يُدعى wordpress-1، مع عنوان IP الخاص (وهو الذي يجب أن تستبدله) والمنفذ الذي يستمع عليه، وهو 80 في هذه الحالة، يُخبِر الخيار check مُوازِن الحمل أن يُجري دوريًّا تحقّق من السّلامة على هذا الخادوم.

إعدادات HAProxy: الإحصائيات Stats

إن أردت تمكين إحصائيّات HAProxy، والتي قد تكون مفيدة في تحديد كيفيّة تعامل HAProxy مع حركة مرور البيانات الواردة، ستحتاج إلى إضافة الأسطر التالية إلى إعداداتك:

listen stats :1936
  stats enable
  stats scope www
  stats scope web-backend
  stats scope wordpress-backend
  stats uri /
  stats realm Haproxy\ Statistics
  stats auth user:password

وهذا شرح لما تعنيه الأسطر غير البديهيّة من المقطع السابق المأخوذ من إعدادات listen stats:

• listen stats :1936: يقوم بإعداد صفحة إحصائيّات HAProxy لتكون قابلة للنفاذ على المنفذ 1936 (أي http://haproxy_www_public_IP:1936).
• stats scope ... : يجمع الإحصائيّات على الواجهة المُحدّدة سواء كانت أماميّة أو خلفيّة.
•  / stats uri: يُعيِّن رابط صفحة الإحصائيّات إلى / .
• stats realm Haproxy\ Statistics: يقوم بتمكين الإحصائيّات وتعيين اسم الاستيثاق realm Authentication (وهو استيثاق ذو نافذة منبثقة)، يُستخدَم بالترابط مع الخيار stats auth.
• stats auth haproxy:password: يُعيِّن اعتمادات credentials الاستيثاق لصفحة الإحصائيّات، قم بوضع اسم المستخدم وكلمة السّر الخاصّة بك.

الآن قم بالحفظ والإغلاق، عند تشغيل HAProxy تكون صفحة الإحصائيّات متوفّرة عبر الرابط http://haproxy_www_public_ip:1936/ حالما تبدأ خدمة HAProxy لديك، تكون HAProxy جاهزة الآن لتشغيلها ولكن فلنقم بتمكين التسجيل logging أولًا.

تمكين تسجيل HAProxy

إنّ تمكين التسجيل في HAProxy بسيط جدًّا، قم في البداية بتحرير الملف rsyslog.conf:

sudo vi /etc/rsyslog.conf

ثم ابحث عن السطرين التاليين وأزل التعليق عنهما لتمكين استقبال UDP syslog، يجب أن تبدو كما يلي عند الفراغ منها:

$ModLoad imudp
$UDPServerRun 514
$UDPServerAddress 127.0.0.1

الآن أعد تشغيل rsyslog لتمكين الإعدادات الجديدة:

sudo service rsyslog restart

تم تمكين تسجيل HAProxy الآن، سيتم إنشاء ملف السّجل في المسار var/log/haproxy.log/ بعد أن يتم تشغيل HAProxy.

تحديث إعدادات ووردبريس

الآن وقد تم تغيير رابط تطبيق ووردبريس فيجب علينا تحديث بعض الإعدادات في ووردبريس.

قم بتعديل الملف wp-config.php على أي خادوم ووردبريس، هذا الملف موجود في مكان تثبيت ووردبريس (في هذا الدّرس تم تثبيته على المسار var/www/example.com/ ولكن قد يكون مختلفًا لديك):

cd /var/www/example.com; sudo vi wp-config.php

ابحث عن السطر الموجود في بداية الملف الذي يحتوي على ('define('DB_NAME', 'wordpress وقم بإضافة الأسطر التالية فوقه مع استبدال http://haproxy_www_public_IP:

define('WP_SITEURL', 'http://haproxy_www_public_IP');
define('WP_HOME', 'http://haproxy_www_public_IP');

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

تشغيل HAProxy

قم بتشغيل HAProxy على الخادوم haproxy-www ليتم تطبيق تغييرات الإعدادات:

sudo service haproxy restart

إتمام الوسيط العكسي Reverse Proxy

أصبحت الآن تطبيقاتنا قابلة للوصول إليها عبر نفس المجال، example.com، عبر الوسيط العكسي للطبقة 7، ولكن لم يتم تطبيق موازنة الحمل عليها بعد، تبدو الآن البيئة لدينا كالمخطط التالي:

وفقًا للواجهة الأماميّة التي عرفناها سابقًا، هذا وصف حول كيفيّة تمرير HAProxy لحركة مرور البيانات:

• http://example.com/wordpress: سيتم إرسال أي طلب يبدأ بـ wordpress/ إلى wordpress-backend (والذي يتكون من الخادوم wordpress-1).
• http://example.com/: سيتم إرسال أيّة طلبات أخرى إلى web-backend (والذي يتكون من الخادوم web-1).

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

كيفية إضافة موازنة الحمل

موازنة حمل الخادوم web-1

لموازنة حمل خادوم ويب أساسي، كل ما تحتاج إليه هو إنشاء خادوم ويب جديد يمتلك إعدادات ومحتوى مطابق لخادوم الأصلي، سندعو هذا الخادوم الجديد: web-2.

لديك خياران عند إنشاء الخادوم الجديد:

1. إن كنت تملك خيار إنشاء خادوم جديد انطلاقًا من صورة web-1، فهذه هي الطريقة الأبسط لإنشاء web-2.
2. إنشاؤه من الصفر، تثبيت نفس البرمجيّات، إعداده بشكل مماثل، ومن ثمّ نسخ محتوى جذر خادوم Nginx من web-1 إلى web-2 باستخدام rsync (اقرأ درس كيف تستخدِم Rsync لمزامنة مجلّدات بين الجهاز المحلّي والخادوم).

ملاحظة: إن كل من الطريقتين السابقتين تقوم بإنشاء نسخة لمحتويات جذر الخادوم مرّة وحيدة، لذلك إن قمت بتحديث أي من الملفّات على أحد خواديمك، web-1 أو web-2، فتأكّد من مزامنة الملفّات مرّة أخرى.

بعد أن يتم إعداد خادوم ويب المماثل لديك، قم بإضافته إلى web-backend ضمن إعدادات HAProxy.

على الخادوم haproxy-www قم بتحرير الملف haproxy.cfg:

sudo vi /etc/haproxy/haproxy.cfg

ابحث عن القسم web-backend من الإعدادات:

backend web-backend
server web-1 web_1_private_IP:80 check

وبعدها أضف الخادوم web-2 في السطر التالي:

server web-2 web_2_private_IP:80 check

قم بحفظ وإغلاق الملف، وأعد تحميل HAProxy لتطبيق التغييرات:

sudo service haproxy reload

يمتلك web-backend الآن خادومين يتعاملان مع حركة مرور البيانات غير المرتبطة بووردبريس، أي تمّ إعداد موازنة الحمل عليه بنجاح.

موازنة حمل الخادوم wordpress-1

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

أكمل الخطوات الثلاث التالية لإنشاء خادوم ووردبريس الثاني wordpress-2:

1. إنشاء خادوم تطبيق ويب الثاني.
2. مزامنة ملفّات تطبيق الويب.
3. إنشاء مستخدم قاعدة بيانات جديد.

بعد أن تقوم بإنشاء الخادوم wordpress-2 مع إعداد قاعدة البيانات بشكل صحيح فكل ما تبقى عليك فعله هو إضافته إلى wordpress-backend ضمن إعدادات HAProxy.

على الخادوم haproxy-www قم بتحرير الملف haproxy.cfg:

sudo vi /etc/haproxy/haproxy.cfg

ابحث عن القسم wordpress-backend من الإعدادات:

backend wordpress-backend
server wordpress-1 wordpress_1_private_IP:80 check

وبعدها أضف الخادوم wordpress-2 في السطر التالي:

server wordpress-2 wordpress_2_private_IP:80 check

قم بحفظ وإغلاق الملف، وأعد تحميل HAProxy لتطبيق التغييرات:

sudo service haproxy reload

يمتلك web-backend الآن خادومين يتعاملان مع حركة مرور البيانات غير المرتبطة بووردبريس، أي تمّ إعداد موازنة الحمل عليه بنجاح.

الخاتمة

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

ترجمة -وبتصرّف- للمقال How To Use HAProxy As A Layer 7 Load Balancer For WordPress and Nginx On Ubuntu 14.04 لصاحبه Mitchell Anicas.

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

ويعتبر بروتوكول HTTP/2 الجديد نسبيًا أحد البروتوكولات التي يدعمها خادوم Nginx، الأمر الذي تم منذ أقل من عام مضى، وتعتبر الميّزة الرئيسية في HTTP/2 هي سرعة نقله العالية للمحتويات الغنيّة بالمعلومات في مواقع الويب.

سيساعد المقال على تثبيت وإعداد خادوم Nginx سريع وآمن مع دعم لبروتوكول HTTP/2.

المتطلبات الأولية

قبل أن نبدأ، سنحتاج للأمور التالية:

• نظام تشغيل Ubuntu 14.04،
• مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة الإعداد الابتدائي لخادوم أوبونتو 14.04 لمزيد من المعلومات،
• نطاق موقع، ويمكن شراء واحد من موقع Namecheap أو الحصول على واحد مجانًا من موقع Freenom،
• تأكّد من أنّ النطاق يشير إلى عنوان نظام التشغيل الذي ستستخدمه عبر الإنترنت، وستساعدك مقالة إعداد اسم مضيف مع DigitalOcean إن احتجت لمساعدة،
• شهادة SSL رقميّة، ويمكن إنشاء واحدة بشكل يدوي، أو الحصول على واحدة مجانًا من Let’s Encrypt، أو شراء واحدة من مزوّد آخر.

هذا كل شيء، فإن كانت لديك جميع المتطلبات المذكورة، فأنت جاهز للبدء.

الفرق ما بين HTTP 1.1 و HTTP/2

إن HTTP/2 هو الإصدار الجديد من بروتوكول نقل النصوص الفائقة HTTP، الذي يستخدم على الشبكة العنكبوتية لإيصال محتويات صفحات الويب من الخوادم إلى المتصفّحات، وهو أول تحديث ضخم طرأ على HTTPمنذ حوالي عقدين، حيث تم إطلاق الإصدار HTTP 1.1 عام 1999 حينما كانت الصفحات عبارة عن ملف HTML مستقل مع أنماط CSS ضمنيّة (أي مكتوبة ضمن مستند HTML وليست مستوردة من ملف خارجي).

لقد تغيّرت شبكة الإنترنت بشكل متسارع في السنوات الستة عشر الأخيرة، وأصبحنا الآن نواجه صعوبة مع المحدودية التي يفرضها HTTP 1.1، حيث يَحُدّ البروتوكول من سرعة النقل الممكنة لمعظم مواقع الويب الحديثة لأنه يقوم بتحميل أجزاء الصفحة وفق مبدأ الطابور queue (بمعنى أنه يجب أن ينتهي تحميل كل جزء قبل أن يبدأ تحميل الجزء التالي له)، ويحتاج موقع ويب حديث وسطيًّا حوالي 100 طلب ليتم تحميل الصفحة(كل طلب يمثّل صورة، ملف js، ملف css، إلخ).

يقوم بروتوكول HTTP/2 بحل هذه المشكلة لأنّه يقوم بتقديم تغييرات جذرية تتمثل في:

• تحميل جميع الطلبات على التوازي، وليس على التسلسل كما في مبدأ الطابور،
• ضغط ترويسة HTTP،
• نقل الصفحات عبر الشبكة بصيغة ثنائية binary، وليس كنصوص text، وهذا أكثر فعالية،
• قدرة الخادوم الآن على "دفع" البيانات قبل أن يطلبها المستخدم، مما سيحسّن من السرعة للمستخدمين الذين يعانون من بطء في الإرسال.

وعلى الرغم من أن بروتوكول HTTP/2 لا يتطلب التشفير، إلا أن مطوّري أشهر متصفّحين، Google Chrome و Mozilla Firefox، صرّحوا بأنه -لدواع أمنيّة- سيتم دعم بروتوكول HTTP/2 في اتصالات HTTPS الآمنة فقط، ولهذا السبب إن قررت تثبيت خواديم تدعم HTTP/2 فيجب عليك الانتقال إلى استخدام HTTPS.

الخطوة الأولى: تثبيت الإصدار الأخير من Nginx

تم طرح دعم HTTP/2 في إصدار Nginx 1.9.5، ولسوء الحظ فإنّ المستودع الافتراضي في نظام Ubuntu متأخر عن إدراج آخر إصدار ويقوم حاليًّا بتوفير الإصدار 1.4.6.

لكن لحسن الحظ فإن مطوّري Nginx لديهم مستودع apt خاص على نظام Ubuntu، حيث بالإمكان الحصول دومًا على آخر إصدار متوفّر.

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

$ wget -qO - http://nginx.org/keys/nginx_signing.key | sudo apt-key add -

بعد ذلك، سنقوم بإضافة المستودع إلى قائمة مصادر الحزم البرمجية، بتنفيذ الأمر التالي:

$ sudo echo -e "deb http://nginx.org/packages/mainline/ubuntu/ `lsb_release -cs` nginx\ndeb-src http://nginx.org/packages/mainline/ubuntu/ `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

الآن وبعد أن أصبح نظام الحزم (الذي يدعى apt في نظامي Ubuntu و Debian) يعلم عن توفّر المستودع الجديد، سنقوم بتحديث قائمة الحزم البرمجية المتوفّرة وأخيرًا سنقوم بتثبيت الإصدار الأخير من Nginx:

$ sudo apt-get update
$ sudo apt-get install nginx

ويمكن التحقق من رقم الإصدار بتنفيذ الأمر:

$ sudo nginx -v

حيث ينبغي أن يكون الخرج مشابهًا لـ nginx version: nginx/1.9.x.

سنقوم في الخطوات التالية بتغيير الإعدادات الافتراضية في Nginx ليقوم بتخديم موقع الويب الخاص بنا.

الخطوة الثانية: تغيير منفذ التنصّت الافتراضي

سنقوم أولًا بتغيير رقم المنفذ من 80 إلى 443، وذلك بفتح ملف الإعدادات:

$ sudo nano /etc/nginx/conf.d/default.conf

ملاحظة: في حال ظهر خطأ يخبرك بأنه لم يتم التعرّف على الأمر nano، فتأكّد من تثبيت محرر النصوص nano وحاول مجدّدًا.

ينبغي أن نخبر Nginx برقم المنفذ الذي يجب عليه تلقّي الاتصالات عبره، وهو المنفذ 80 افتراضيًا، المنفذ القياسي في بروتوكول HTTP. سنبحث في ملف الإعدادات عن السطر التالي:

listen 80;

سنقوم بتغيير المنفذ إلى 443 لأن HTTP/2 لن يعمل مع معظم المستخدمين إذا بقي يقوم بإرسال البيانات عبر المنفذ 80، كما أشرنا سابقًا إلى أنه مدعوم فقط عبر المنفذ 443 على متصفحات Chrome و Firefox.سنستبدل السطر السابق بـ:

listen 443 ssl http2;

لاحظ أننا أضفنا كلمة ssl و http2 في نهاية السطر، وتخبر هذه المتغيّرات Nginx بأن يستخدم بروتوكول HTTP/2 مع المتصفحات التي تدعم البروتوكول الجديد.

الخطوة الثالثة: تغيير اسم الخادوم

يأتي اسم الخادوم server_name بعد السطر السابق الذي يحوي على listen، وسنقوم بإعلام Nginx أيّ نطاق سيرتبط مع ملف الإعدادات. سنستبدل الاسم الافتراضي localhost الذي يعني بأن ملف الإعدادات مسؤول عن جميع الطلبات الواردة، وسنضع مكانه اسم النطاق الحقيقي، كـ example.com على سبيل المثال:

server_name example.com;

سنقوم الآن بحفظ التغييرات بالضغط على CTRL+O ومن ثم نضغط CTRL+X للخروج من محرر nano.

الخطوة الرابعة: إضافة المسار إلى شهادات SSL الأمنية

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

لنقم أولًا بإنشاء مجلّد لحفظ الشهادات الأمنية فيه داخل مجلد إعدادات Nginx:

$ sudo mkdir /etc/nginx/ssl

سنقوم الآن بنسخ ملف الشهادة وملف المفتاح الخاص private key إلى داخل المجلد الجديد، وبعد ذلك سنقوم بتغيير أسماء الملفات لتظهر بوضوح أي نطاق ترتبط معه (تساعد هذه الخطوة في المستقبل على توفير الوقت والجهد إن امتلكت أكثر من نطاق واحد). لا تنسى استبدال example.com باسم النطاق الخاص بك.

$ sudo cp /path/to/your/certificate.crt /etc/nginx/ssl/example.com.crt
$ sudo cp /path/to/your/private.key /etc/nginx/ssl/example.com.key

سنقوم بإضافة سطر جديد الآن إلى ملف الإعدادات ضمن كتلة server لتعريف مسارات الشهادة الرقمية مع مفتاحها الخاص

ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;

الخطوة الخامسة: تحويل جميع طلبات HTTP إلى HTTPS

ينبغي الآن أن نخبر Nginx بأننا نرغب بتوفير المحتوى عبر HTTPS فقط إن استلم طلب HTTP عوضًا عن ذلك.

سنقوم في نهاية ملف الإعدادات بإنشاء كتلة server جديدة لتحويل جميع طلبات HTTP إلى HTTPS، ومرة أخرى لا تنس استبدال النطاق باسم النطاق الخاص بك، ستكون الكتلة الجديدة على الشكل التالي:

server {
       listen         80;
       listen    [::]:80;
       server_name    example.com;
       return         301 https://$server_name$request_uri;
}

لاحظ في الكتلة السابقة كيف أنّ Nginx عند استلامه لطلبات HTTP تخص النطاق example.com عبر المنفذ 80، فإنّه سيقوم بتحويل الطلب إلى HTTPS على نفس المسار المطلوب، مستخدمّا التحويل من النمط301 (moved permanently).

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

server {
        listen 443 ssl http2 default_server;
        listen [::]:443 ssl http2 default_server;

        root /var/www/html;

        index index.html index.htm index.nginx-debian.html;

        server_name example.com;

        location / {
                try_files $uri $uri/ =404;
        }

        ssl_certificate /etc/nginx/ssl/example.com.crt;
        ssl_certificate_key /etc/nginx/ssl/example.com.key;
        ssl_dhparam /etc/nginx/ssl/dhparam.pem;
}


server {
       listen         80;
       listen    [::]:80;
       server_name    example.com;
       return         301 https://$server_name$request_uri;
}

سنقوم الآن بحفظ ملف الإعدادات بالضغط على CTRL+O ومن ثم الخروج من محرر nano بالضغط على CTRL+X.

الخطوة السادسة: تحميل ملف الإعدادات الجديد في ذاكرة Nginx

لتطبيق التغييرات التي قمنا بها، سنحتاج لإعادة تشغيل خادوم Nginx:

$ sudo service nginx restart

وللتحقق من أن كل شيء سار على ما يرام، سنقوم بفتح المتصفح واستعراض النطاق الذي أعددناه مع Nginx، فإن كانت الإعدادات صحيحة، يجب أن يتم تحويل الطلب إلى HTTPS بشكل تلقائي، وللتأكد مما إذا تم استخدام البروتوكول الجديد فسنقوم بفتح أدوات المطوّر (في متصفح كروم يمكن فتحها من خلال قائمة View > Developer > Developer Tools)، ومن ثم نعيد تحميل الصفحة من جديد (View > Reload This Page)، ثم من خلال لسان Network، سنضغط بالزر الأيمن للفأرة على سطر رأس الجدول ونختار Protocol. يجب الآن أن يظهر عمود جديد عنوانه Protocol ستتمكن من خلاله من رؤية أن البروتوكول المستخدم هو h2 (الذي يرمز إلى بروتوكول HTTP/2) في حال تم الإعداد بشكل صحيح.

إلى هنا سيكون Nginx قد أصبح قادرًا على تخديم المحتوى باستخدام بروتوكول HTTP/2، ولكن تبقى هناك بعض الأمور التي ينبغي إعدادها قبل استخدام الخادوم في بيئة التشغيل.

الخطوة السابعة: تحسين Nginx لتقديم أداء أفضل

سنقوم الآن بفتح ملف الإعدادات مجدّدًا لضبط إعدادات Nginx لتقديم أفضل أداء وحماية.

تفعيل Connection Credentials Caching

بالمقارنة مع HTTP، فإن HTTPS يتطلب وقتًا أطول نسبيًا لإنشاء اتصال ما بين الخادوم والمستخدم، ولتقليل الفرق في سرعة تحميل الصفحة، سنقوم بتفعيل ميّزة Connection Credentials Caching وهذا يعني بأنه عوضًا عن إنشاء جلسة عمل جديدة عند طلب كل صفحة، سيقوم الخادوم باستخدام نسخة خبء cache لمعلومات المصادقة.

لتفعيل الميّزة، سنقوم بإضافة السطرين التاليين إلى نهاية كتلة http في ملف الإعدادات:

ssl_session_cache shared:SSL:5m;
ssl_session_timeout 1h;

يقوم المتغيّر ssl_session_cache بتحديد حجم الخبء الذي سيحتوي على معلومات الجلسة، حيث يمكن لـ 1MB أن يقوم بتخزين معلومات 4000 جلسة عمل، وبالتالي ستكون القيمة الافتراضية 5MB أكثر من كافية لمعظم الحالات، ولكن إن كنت تتوقع أن يكون هناك حركة مرور كثيفة على الموقع، فيمكنك زيادة القيمة وفقًا لذلك.

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

تحسين باقات التشفير Cipher Suites

باقات التشفير هي مجموعة من خوارزميات التشفير التي تصف كيف ينبغي أن يتم تشفير البيانات المنقولة. يملك بروتوكول HTTP/2 قائمة كبيرة من خوارزميات التشفير القديمة وغير الآمنة التي يجب تجنّب استخدامها.

سنقوم باستخدام مجموعة تشفير معتمدة من قبل جهات عملاقة مثل CloudFlare. لا تسمح هذه المجموعات باستخدام خوارزمية MD5 في التشفير (التي تم إثبات أنها غير آمنة في عام 1996، وبالرغم من ذلك، فما تزال منتشرة حتى يومنا هذا).

سنقوم بإضافة السطرين التاليين بعد ssl_session_timeout:

ssl_prefer_server_ciphers on;
ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;

تفعيل ميزة (Strict Transport Security (HSTS

على الرغم من أنّا قمنا بتحويل جميع طلبات HTTP إلى HTTPS في إعدادات Nginx، فينبغي علينا أيضًا أن نقوم بتفعيل ميّزة Strict Transport Security لتجنّب الحاجة لإخبار Nginx بعملية التحويل بأنفسنا أساسًا.

عندما يصادف المتصفح ترويسة HSTS، فلن يحاول الاتصال بالخادوم عبر HTTP التقليدي مجدّدًا قبل مضي فترة من الوقت، ومهما حصل، سيعمل على تبادل البيانات عبر اتصالات HTTPS مشفّرة. تساعد هذه الترويسة على حمايتنا من هجمات تخفيض البروتوكول.

كل ما نحتاجه هو إضافة السطر التالي في ملف الإعدادات:

add_header Strict-Transport-Security "max-age=15768000" always;

يحدّد المتغير max-age القيمة التي يجب على المتصفح خلالها ألا يحاول التواصل مع الخادوم إلا عبر بروتوكول HTTPS، وهذه القيمة ممثّلة بالثواني وبالتالي فإن القيمة 15768000 تساوي 6 أشهر.

وبشكل افتراضي فإن هذه الترويسة لن يتم إضافتها إلى الطلبات الموجّهة للنطاقات الفرعية، فإن كنت تملك نطاقات فرعية وترغب أن يتم تطبيق HSTS عليها جميعًا فيجب إضافة المتغير includeSubDomains حينها إلى نهاية السطر على الشكل التالي:

add_header Strict-Transport-Security "max-age=15768000; includeSubDomains: always;";

لا تنس حفظ الملف الآن بالضغط على CTRL+O ومن ثم إغلاقه بالضغط على CTRL+X إن كنت تستخدم محرر nano.

الخطوة الثامنة: رفع حماية تبادل المفاتيح الأمنية

إن الخطوة الأولى في إنشاء اتصال آمن هو تبادل المفاتيح الخاصة بين الخادوم والعميل، وتكمن المشكلة في هذه العملية في أنّه حتى تلك اللحظة فالاتصال غير مشفّر بينهما وبالتالي فالبيانات المتبادلة يمكن التنصّت عليها من طرف ثالث. لهذا السبب، سنحتاج لاستخدام خوارزمية Diffie-Hellman-Merkle في تبادل المفاتيح.

يستخدم Nginx بشكل افتراضي مفتاح DHE) Ephemeral Diffie-Hellman) بطول 1024 بت، والذي يمكن فك تشفيره بسهولة نسبيًا، وللحصول على أمان أعلى فينبغي علينا إنشاء مفتاح DHE خاص أكثر أمنًا.

للقيام بذلك سنقوم بتنفيذ الأمر التالي في سطر الأوامر:

$ sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

تنبيه: يجب أن يتم إنشاء مُعاملات DH في المجلد الذي قمنا بتخزين الشهادات الأمنية فيه، وفي المقال قمنا بتخزين الشهادات في المسار /etc/nginx/ssl/. إن السبب وراء هذا هو أن Nginx يقوم دومًا بالبحث عن مفتاح DHE الخاص بالمستخدم في مجلد الشهادات الأمنية ويستخدمه إن وُجد.

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

ستأخذ عملية إنشاء المفتاح حوالي 5 دقائق، ويمكنك أثناء ذلك الاسترخاء وارتشاف بعض القهوة.

لتطبيق التغييرات التي قمنا بها على ملف الإعدادات، لا تنسى أن تقوم بإيقاف وإعادة تشغيل خادوم Nginx:

$ sudo service nginx restart

الخلاصة

أصبح اتصال SSL الخاص بك أكثر أمنًا وقابلًا للاستخدام لنقل المعلومات الحساسة، ولكن إن أردت اختبار قوته الأمنية فقم بزيارة Qualys SSL Lab وبتشغيل اختبار على خادومك، حيث ينبغي أن تحصل على نتيجة A+إن كان كلّ شيء معدّ بشكل صحيح.

هذا كلّ شيء، أصبح خادوم Nginx الخاص بك جاهزًا للاستخدام، وكما ترى فإن بروتوكول HTTP/2 هو حل رائع لتحسين سرعات نقل البيانات ومن السهل استخدامه كما أظهرنا في المقال.

ترجمة -وبتصرّف- للمقال How To Set Up Nginx with HTTP/2 Support on Ubuntu 14.04 لصاحبه Sergey Zhukaev.

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

يعدّ gzip من البرامج المشهورة المستخدمة في ضغط البيانات، وبالإمكان إعداد خادوم Nginx لاستخدام gzip لضغط الملفات التي يتم تخديمها من قبل الخادوم قبل إرسالها للمتصفحات والتي ستقوم بدورها بفك الضغط عن الملفّات (تدعم جميع المتصفحات المشهورة فك ضغط gzip ويفترض أن تدعم -معظم- المتصفحات عمومًا هذه العملية) دون أي خسارة في دقة البيانات بعد فك الضغط، مستفيدة بذلك من تخفيف حجم البيانات المتبادلة ما بين خادوم الويب والمتصفح.

ونظرًا لاختلاف الطرق التي تعمل بها خوارزميات الضغط عمومًا، وآلية عمل خوارزمية gzip خصوصًا، فإنّ بعض الملفات يمكن ضغطها بنسبة أكبر من بعضها الآخر. فعلى سبيل المثال، يتم ضغط الملفات النصيّة text بصورة جيّدة جدًا حيث قد تكون نتيجة الضغط أصغر بحوالي مرّتين من الحجم الأصلي. ومن ناحية أخرى، فالصور من نوع JPEG و PNG تأتي مضغوطة سلفًا بطبيعة الخوارزمية المنتجة لها وبالتالي لن نحصل على الكثير من الفائدة بعد تطبيق ضغط gzip عليها، وعلى اعتبار أن ضغط الملفّات يستهلك الكثير من مصادر الخادوم، فمن الأفضل أن يتم ضغط الملفّات التي تملك نسبة ضغط عالية.

سنناقش في المقال كيفية إعداد خادوم Nginx المثبت على نظام تشغيل Ubuntu 14.04 ليستخدم gzip في الضغط لتخفيف حجم المحتوى المرسل إلى متصفّحي الموقع.

المتطلبات الأولية

نحتاج الأمور التالية قبل المتابعة:

• نظام تشغيل Ubuntu 14.04،
• مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo، يمكن مراجعة الإعداد الابتدائي لخادوم أوبونتو 14.04 لمزيد من المعلومات،
• نسخة Nginx مثبّته على النظام، ويمكنك اتباع هذا المقال لتثبيت Nginx للقيام بذلك.

الخطوة الأولى: إنشاء ملفات تجريبية

سنقوم في هذه الخطوة بإنشاء عدّة ملفات تجريبية في الجذر الافتراضي للمواقع المدارة من Nginx لاختبار ضغط gzip.

ولتحديد الملف الذي سيتم تخديمه عبر الشبكة، يكتفي Nginx بالاعتماد على لاحقة الملف لتحديد نمط MIME الخاص به، عوضًا عن القيام بقراءة ترويسته وذلك بغية تنفيذ العملية بأسرع وقت ممكن. ونتيجة لهذا التصرّف فإن محتوى الملف لا يعود مهمًّا ويصبح من الممكن خداع Nginx بجعله يعتقد أن ملفًا فارغًا عبارة عن صورة، وملفًا آخر عبارة عن مستند css.

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

لنقم بإنشاء ملف بحجم 1 كيلوبايت وتسميته test.html في الجذر الرئيسي الافتراضي للمواقع المدارة من Nginx وذلك باستخدام أمر truncate عبر سطر الأوامر، كما في المثال التالي:

$ sudo truncate -s 1k /usr/share/nginx/html/test.html

لنقم بإنشاء المزيد من الملفّات التجريبية بنفس الطريقة: ملف صورة jpg، ملف css، وملف js.

$ sudo truncate -s 1k /usr/share/nginx/html/test.jpg
$ sudo truncate -s 1k /usr/share/nginx/html/test.css
$ sudo truncate -s 1k /usr/share/nginx/html/test.js

الخطوة الثانية: التحقق من التصرّف الافتراضي لـ Nginx

سنقوم الآن بالتحقق من كيفية تصرّف Nginx عند ضغط الملفات التي قمنا بإنشائها توًّا.

لنتحقق مما إذا سيتم تخديم ملف test.html بعد الضغط، سنقوم في الأمر التالي بطلب الملف من خادوم Nginx، ونخبره بأنّه لا مشكلة لدينا في الحصول على محتوى مضغوط باستخدام gzip وذلك بتمرير ترويسة HTTP مناسبة (Accept-Encoding: gzip).

$ curl -H "Accept-Encoding: gzip" -I http://localhost/test.html

سنحصل في جواب الخادوم على ما يشبه النص التالي:

HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 19 Jan 2016 20:04:12 GMT
Content-Type: text/html
Last-Modified: Tue, 04 Mar 2014 11:46:45 GMT
Connection: keep-alive
Content-Encoding: gzip

ويمكن في السطر الأخير ملاحظة وجود ترويسة (Content-Encoding: gzip) والتي تخبرنا بأن المحتوى الذي حصلنا عليه قد تم ضغطه باستخدام gzip، ولكن كيف حصل ذلك دون أن نقوم بتفعيل gzip أولًا في Nginx؟ إنّ السبب خلف هذا هو أن الضغط باستخدام gzip مفعّل بشكل تلقائي في نسخة Nginx على نظام Ubuntu 14.04 بإعداداته الافتراضية.

على الرغم من ذلك، فإن Nginx لن يقوم إلا بضغط ملفات HTML فقط، بينما يتم تخديم باقي أنواع الملفّات بدون ضغط، ويمكن التحقق من ذلك بطلب صورة بنفس الطريقة السابقة:

$ curl -H "Accept-Encoding: gzip" -I http://localhost/test.jpg

وسنحصل على رد مختلف قليلًا عن السابق:

HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 19 Jan 2016 20:10:34 GMT
Content-Type: image/jpeg
Content-Length: 0
Last-Modified: Tue, 19 Jan 2016 20:06:22 GMT
Connection: keep-alive
ETag: "569e973e-0"
Accept-Ranges: bytes

حيث نلاحظ عدم وجود ترويسة (Content-Encoding: gzip) وهذا يعني أن الملف تم إرساله لنا بدون ضغط.

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

HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 19 Jan 2016 20:20:33 GMT
Content-Type: text/css
Content-Length: 0
Last-Modified: Tue, 19 Jan 2016 20:20:33 GMT
Connection: keep-alive
ETag: "569e9a91-0"
Accept-Ranges: bytes

الخطوة الثالثة: تغيير إعدادات ضغط gzip في خادوم Nginx

سنقوم الآن بتغيّير إعدادات Nginx ليتم ضغط ملفّات من أنواع أخرى عدا عن HTML، والتي من الممكن الاستفادة من نسبة الضغط المطبّقة عليها.

سنقوم بفتح ملف إعدادات Nginx باستخدام محرر nano أو أي محرر آخر تفضّل استخدامه:

$ sudo nano /etc/nginx/nginx.conf

ومن ثم سنبحث عن كتلة إعدادات gzip التي ستبدو كما يلي:

. . .
##
# `gzip` Settings
#
#
gzip on;
gzip_disable "msie6";

# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
. . .

نلاحظ في الإعدادات السابقة أن الضغط بواسطة gzip مفعّل بشكل افتراضي بواسطة توجيه gzip on، بينما معظم الإعدادات الإضافية تم تعطيلها بإشارة التعليقات # في بداية السطر. سنقوم بإجراء بعض التعديلات على هذه الإعدادات مثل:

• تفعيل الإعدادات الإضافية من خلال حذف إشارة التعليقات # في بداية الأسطر،
• إضافة توجيه gzip_min_length 256; الذي يخبر Nginx ألّا يقوم بضغط الملفات التي يصغر حجمها عن 256 بايت، فهذا الحجم الصغير جدًا لن يحقق الفائدة المرجوّة بعد الضغط،
• ▪ إضافة توجيه gzip_types مع المزيد من أنماط الملفّات كخطوط الويب، الأيقونات والصور من نوع SVG.

بعد إجراء التعديلات المذكورة سيبدو مقطع الإعدادات الجديد على النحو التالي:

. . .
##
# `gzip` Settings
#
#
gzip on;
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon;
. . .

قم بحفظ الملف وإغلاقه وتطبيق التعديلات من خلال إعادة تشغيل خادوم Nginx باستخدام الأمر:

$ sudo service nginx restart

الخطوة الرابعة: التحقق من الإعدادات الجديدة

سنقوم الآن بالتحقق من أنّ الإعدادات التي قمنا بتغييرها وإضافتها تعمل على النحو المطلوب، ويمكن القيام بذلك من خلال إعادة تنفيذ الاختبارات المذكورة في الخطوة الثانية عبر استخدام أمر curl على كلّ من الملفّات التجريبية والتحقق من وجود ترويسة Content-Encoding: gzip في الخرج:

$ curl -H "Accept-Encoding: gzip" -I http://localhost/test.html
$ curl -H "Accept-Encoding: gzip" -I http://localhost/test.jpg
$ curl -H "Accept-Encoding: gzip" -I http://localhost/test.css
$ curl -H "Accept-Encoding: gzip" -I http://localhost/test.js

من المفترض الآن أن تكون جميع الملفّات مضغوطة وتظهر ترويسة Content-Encoding: gzip في الخرج، عدا ملف الصورة test.jpg، وتكون الإعدادات المطبّقة صحيحة والاختبار ناجحًا إن تحقق هذا.

الخلاصة

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

ترجمة -وبتصرّف- للمقال How To Add the gzip Module to Nginx on Ubuntu 14.04 لصاحبه Mateusz Papiernik.

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

سنشرح في هذا الدّرس كيف نحمي الممتلكات assets باستخدام كلمة سر على خادوم ويب Nginx يعمل على Ubuntu.

المتطلبات الأساسية

نحتاج للوصول إلى بيئة خادوم Ubuntu لكي نبدأ، نحتاج أيضًا لمستخدم غير جذري non-root مع صلاحيّات sudo من أجل تنفيذ مهام إداريّة administrative، لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04.

إن لم نقم مُسبقًا بتثبيت Nginx نستطيع تثبيته على جهازنا بكتابة ما يلي:

sudo apt-get update
sudo apt-get install nginx

إنشاء ملف كلمات السر

للبدء نحتاج لإنشاء الملف الذي سيحمل تركيبات أسماء المستخدمين وكلمات السّر، نستطيع فعل ذلك باستخدام أدوات OpenSSL المساعدة التي ربّما تكون متوفّرة مُسبقًا على خادومنا، وبشكلٍ بديل نستطيع استخدام الأداة المساعدة htpasswd المُصمّمة لهذا الغرض والمُضمّنة في الحِزمة apache2-utils (تستخدم ملفّات كلمات سر Nginx نفس الصّيغة التي تستخدمها Apache)، بإمكانك اختيار الطّريقة التي تفضّلها.

إنشاء ملف كلمات السر باستخدام أدوات OpenSSL المساعدة

إن كُنّا نملك OpenSSL مُثبتًا على خادومنا فبإمكاننا إنشاء ملف كلمات سر بدون أي حِزَم إضافيّة.

سنقوم بإنشاء ملف مخفي يُدعى htpasswd. في دليل الإعدادات etc/nginx/ لتخزين تركيبات أسماء المستخدمين وكلمات السّر.

نستطيع إضافة اسم مستخدم إلى هذا الملف باستخدام هذا الأمر، سنختار الاسم sammy ليكون اسم مستخدم لدينا، ولكن تستطيع استخدام أي اسم ترغب به:

sudo sh -c "echo -n 'sammy:' >> /etc/nginx/.htpasswd"

سنقوم بعد ذلك بإضافة كلمة سر مُشفّرة encrypted لاسم المستخدم بكتابة ما يلي:

sudo sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"

نستطيع إعادة هذه العمليّة من أجل أسماء مستخدمين آخرين، وبإمكاننا أن نرى كيف يتم تخزين أسماء المستخدمين وكلمات السّر المُشفّرة داخل الملف بكتابة ما يلي:

cat /etc/nginx/.htpasswd

sammy:$apr1$wI1/T0nB$jEKuTJHkTOOWkopnXqC1d1

إنشاء ملف كلمات السر باستخدام الأدوات المساعدة لـ Apache

في حين أنّ OpenSSL تستطيع تشفير كلمات السّر من أجل استيثاق Nginx، يجد معظم المستخدمين أنّه من الأسهل استخدام أداة مُساعِدة مبنيّة لهذا الغرض، تقوم الأداة المُساعِدة htpasswd الموجودة في الحزمة apache2-utils بتخديم هذا الأمر بشكل جيّد.

نُثبِّت الحِزمة apache2-utils على خادومنا بكتابة ما يلي:

sudo apt-get update
sudo apt-get install apache2-utils

والآن بعد أن أصبح بإمكاننا الوصول للأمر htpasswd نستطيع استخدامه لإنشاء ملف كلمات السّر الذي يستخدمه خادوم Nginx من أجل استيثاق المستخدمين، سنقوم بإنشاء ملف مخفي لهذا الغرض يُدعى htpasswd. بداخل دليل الإعدادات etc/nginx/.

عند استخدام هذه الأداة لأوّل مرّة نحتاج لإضافة الخيار c- لإنشاء الملف المُحدَّد، نقوم بتحديد اسم مستخدم (في هذا المثال sammy) في نهاية الأمر لإنشاء مُدخَل جديد بداخل الملف:

sudo htpasswd -c /etc/nginx/.htpasswd sammy

سيتم سؤالنا عن تزويد كلمة سر وتأكيدها للمستخدم.

نترك الوسيط c- لأي مستخدمين آخرين نرغب في إضافتهم:

sudo htpasswd /etc/nginx/.htpasswd another_user

إن قمنا بمشاهدة محتويات الملف نستطيع رؤية اسم المستخدم وكلمة السّر المُشفّرة لكل تسجيل record:

cat /etc/nginx/.htpasswd

sammy:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz.
another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.

إعداد استيثاق كلمة السر لخادوم Nginx

الآن وبعد أن أصبحنا نمتلك ملف لأسماء المستخدمين وكلمات السّر في صيغة يستطيع خادوم Nginx قراءتها، نحتاج لإعداد Nginx لكي يتفحّص هذا الملف قبل تخديم محتوانا المحمي.

نبدأ بفتح ملف إعدادات الحجب للخادوم والذي نرغب في إضافة تقييد restriction له، سنستخدم في مثالنا هذا ملف الخادوم الافتراضي default للحجب والمُثبَّت عبر حزمة Nginx في Ubuntu:

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

ينبغي أن يبدو المحتوى داخل الملف مُشابِهًا لما يلي بعد إزالة التّعليقات:

/etc/nginx/sites-enabled/default

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    root /usr/share/nginx/html;
    index index.html index.htm;

    server_name localhost;

    location / {
        try_files $uri $uri/ =404;
    }
}

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

نستخدم ضمن هذا الحجب على المكان الأمر التوجيهي auth_basic لتشغيل الاستيثاق واختيار اسم نطاق ليتم عرضه للمستخدم عند المطالبة بالاعتمادات credentials، سنستخدم الأمر التوجيهي auth_basic_user_file لكي يشير لخادوم Nginx إلى ملف كلمات السّر الذي أنشأناه:

/etc/nginx/sites-enabled/default

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    root /usr/share/nginx/html;
    index index.html index.htm;

    server_name localhost;

    location / {
        try_files $uri $uri/ =404;
        auth_basic "Restricted Content";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

بعد أن ننتهي نحفظ ونغلق الملف، نعيد تشغيل خادوم Nginx لتنفيذ سياسة policy كلمات السّر لدينا:

sudo service nginx restart

يجب أن يكون الدليل الذي حددناه محميًّا الآن بكلمة سر.

تأكيد استيثاق كلمة السر

للتأكّد من أنّ المحتوى محمي لدينا نُجرِّب النفاذ إلى المحتوى المُقيَّد من متصفّح إنترنت، يجب أن يتم عرض مُحث prompt لاسم المستخدم وكلمة السّر يُشبه ما يلي:

إن أدخلنا الاعتمادات الصحيحة سيتم السماح لنا بالنفاذ إلى المحتوى، وإن أدخلنا الاعتمادات الخاطئة أو ضغطنا على إلغاء Cancel سنشاهد صفحة الخطأ "Authorization Required":

الخاتمة

يجب أن يكون لدينا الآن كل ما نحتاجه لإعداد استيثاق أساسي لموقعنا، فلنضع في اعتبارنا أنّ حماية كلمة السّر يجب أن تكون جنبًا إلى جنب مع تشفير SSL كي لا يتم إرسال اعتماداتنا إلى الخادوم في شكل نص مُجرَّد plain text، يمكنك الإطلاع أيضا على كيفيّة إنشاء شهادة SSL موقّعة ذاتيًّا لاستخدامها مع Nginx.

ترجمة -وبتصرّف- للمقال: How To Set Up Password Authentication with Nginx on Ubuntu 14.04 لصاحبه Justin Ellingwood.

حقوق الصورة البارزة: Designed by Freepik.

من المهم عند العمل على خادوم ويب تنفيذ تدابير أمنيّة لحماية موقعنا ومستخدمينا، إنّ حماية مواقع الإنترنت والتّطبيقات لدينا باستخدام سياسات الجّدار النّاري firewall policies وتقييد الوصول إلى بعض المناطق باستخدام استيثاق كلمة السّر password authentication هو نقطة بدء رائعة لتأمين النظام لدينا، ومع ذلك من المُرجَّح أن يجذب أي طلب لكلمة السّر مُتاح للعوام محاولات القوة القاسية brute force من قبل المستخدمين والروبوتات bots الخبيثين.

يتمكّن إعداد fail2ban من المساعدة في الحد من هذه المشكلة، فعندما يفشل المستخدمون بالاستيثاق إلى خدمة ما بشكلٍ متكرّر (أو الانخراط في أي نشاط مشبوه آخر) تستطيع fail2ban أن تصدر حظرًا مؤقّتًا على عنوان IP المُهاجِم عن طريق التّعديل بشكل ديناميكي على سياسة الجّدار النّاري التي تعمل حاليًّا. تعمل كل "jail" تابعة لـ fail2ban عن طريق تفحّص السّجلّات المكتوبة من قبل خدمة ما بحثًا عن أنماط patterns تُشير إلى محاولات فاشلة بالاستيثاق. من السّهل إلى حدٍّ ما إعداد fail2ban لكي تراقب سجلّات Nginx باستخدام البعض من مُرشّحات filters الإعداد المُضمَّنة والبعض الآخر الذي سنقوم بكتابته بأنفسنا.

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

المتطلبات الأساسية

ينبغي قبل أن نبدأ أن نمتلك خادوم Ubuntu مع إعداد حساب غير جذري non-root، ويجب أن يكون هذا الحساب مُعدًّا بامتيازات sudo من أجل إصدار أوامر إداريّة administrative commands. لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04.

تثبيت Nginx وإعداد استيثاق كلمة السر

إن كنتَ مهتمًّا بحماية خادوم Nginx باستخدام fail2ban فمن الغالب أنك تملك مسبقًا خادومًا مُعدًّا وقيد التشغيل، وإن لم تكن كذلك تستطيع تثبيت Nginx من خلال مستودعات Ubuntu الافتراضيّة باستخدام apt.

فلنقم بتحديث دليل الحِزَم المحلّي وتثبيت Nginx بكتابة ما يلي:

sudo apt-get update

sudo apt-get install nginx

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

تثبيت Fail2Ban

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

sudo apt-get update

sudo apt-get install fail2ban

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

ضبط الإعدادات العامة داخل Fail2Ban

نحتاج لكي نبدأ إلى ضبط ملف الإعدادات الذي تستخدمه fail2ban لتحديد سجلّات التطبيقات التي يجب أن تراقبها والإجراءات التي يجب أن يتمّ اتخاذها عند إيجاد مُدخلات مُخالِفة، ومن الموارد الرئيسيّة التي يتم تزويدنا بها لهذا الأمر نجد الملف etc/fail2ban/jail.conf/.

ولإجراء التعديلات نحتاج إلى نسخ هذا الملف إلى etc/fail2ban/jail.local/، وهذا يمنع الكتابة فوق التغييرات التي أجريناها إن قام تحديث الحِزمة package بتزويدنا بملف جديد افتراضي:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

نقوم بفتح الملف الجديد المنسوخ حتى نستطيع إعداد مراقبة سجلّات Nginx لدينا:

sudo nano /etc/fail2ban/jail.local

تغيير الإعدادات الافتراضية

ينبغي أن نبدأ بتقييم المجموعة الافتراضيّة داخل الملف لنرى إن كانت تُلائِم احتياجاتنا، نستطيع إيجاد هذه المجموعة تحت قسم [DEFAULT] داخل الملف. تقوم هذه العناصر بتعيين السّياسة policy العامّة وبإمكاننا تجاوز أي منها في jails مُحدّدة.

ومن أوائل العناصر التي يجب أن ننظر إليها هي قائمة العُمَلاء Clients التي لا تخضع لسياسات fail2ban، ويتم تعيينها باستخدام الأمر التّوجيهي ignoreip، من الجّيد أحيانًا إضافة عنوان IP الخاص بنا أو بشبكتنا إلى قائمة الاستثناءات لتجنّب حظر أنفسنا، على الرّغم من أنّ هذا أقل من أن يكون مشكلة مع تسجيلات الدّخول إلى خادوم الويب إن كان بإمكاننا المحافظة على النفاذ للـ Shell، حيث أنّنا دائمًا نستطيع إلغاء الحظر يدويًّا. نستطيع إضافة عناوين IP أو شبكات إضافيّة بفصلها بمسافة Space إلى القائمة الحاليّة:

etc/fail2ban/jail.local/

[DEFAULT]

. . .
ignoreip = 127.0.0.1/8 your_home_IP

ومن العناصر الأخرى التي قد نرغب بضبطها نجد bantime والذي يتحكّم بعدد الثّواني التي سيتم خلالها حظر العضو المُخالِف، من المثالي تعيينه إلى مدّة طويلة كافية لتكون مُدمِّرة لجهود المستخدم الخبيث، وفي نفس الوقت قصيرة بما فيه الكفاية لتسمح للمستخدمين الشرعيّين لتصحيح أخطائهم، يتم تعيين هذه القيمة افتراضيًّا إلى 600 ثانية (10 دقائق)، قم بزيادتها أو إنقاصها على النحو الذي تراه مناسبًا:

etc/fail2ban/jail.local/

[DEFAULT]

. . .
bantime = 3600

يُحدّد العنصران التّاليان نطاق أسطر السّجلّات المستخدمة لتحديد العميل المُخالِف، يُحدِّد findtime المدّة الزمنية مُقدّرةً بالثواني ويُشير الأمر التّوجيهي maxretry إلى عدد المحاولات التي يتم التسامح معها خلال تلك المدّة، فإن قام العميل بعدد محاولات أكثر من maxretry خلال المدّة الزمنيّة المُحدّدة بواسطة findtime فسيتمّ حظره:

etc/fail2ban/jail.local/

[DEFAULT]

. . .
findtime = 3600 # These lines combine to ban clients that fail
maxretry = 6    # to authenticate 6 times within a half hour

إعداد تنبيهات البريد الإلكتروني (اختياري)

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

ويتوجّب علينا بعد الانتهاء من إعداد MTA أن نقوم بضبط بعض الإعدادات الإضافيّة داخل القسم [DEFAULT] من الملف etc/fail2ban/jail.local/. نبدأ بإعداد الأمر التّوجيهي mta، فإن قمنا بإعداد Postfix -كما هو واضح في الدّرس التعليمي المذكور بالأعلى- نُغيّر هذه القيمة إلى “mail”:

etc/fail2ban/jail.local/

[DEFAULT]

. . .
mta = mail

يجب أن نختار عنوان البريد الإلكتروني الذي سيتم إرسال التنبيهات إليه ونكتبه داخل الأمر التّوجيهي destemail، بإمكاننا استخدام الأمر التّوجيهي sendername لتعديل حقل المُرسِل Sender في تنبيهات البريد الإلكتروني:

etc/fail2ban/jail.local/

[DEFAULT]

. . .
destemail = youraccount@email.com
sendername = Fail2BanAlerts

إنّ الإجراء action -بحسب تعبير fail2ban- هو العمليّة التي تتلو فشل العميل بالاستيثاق مرات كثيرة، الإجراء الافتراضي (يُدعى action_) هو ببساطة حظر عنوان الـ IP من المنفذ port قيد الطلب، ويوجد على أيّة حال إجراءان آخران مُعدّان مُسبقًا يُمكن استخدامهما إن كنّا نملك إعداد بريد إلكتروني.

نستطيع استخدام الإجراء action_mw لحظر العميل وإرسال تنبيه بريد إلكتروني إلى الحساب المضبوط لدينا مع تقرير “whois” حول عنوان المُخالِف، بإمكاننا أيضًا استخدام الإجراء action_mwl والذي يقوم بنفس العمل ولكن يقوم بتضمين سطور سجلّات المُخالِف والتي قامت بإطلاق عمليّة الحظر:

etc/fail2ban/jail.local/

[DEFAULT]

. . .
action = %(action_mwl)s

إعداد Fail2Ban لمراقبة سجلات Nginx

بعد أن قمنا بضبط بعض إعدادات fail2ban العامّة في مكانها الصحيح نستطيع التركيز على تمكين بعض jails المرتبطة بـ Nginx والتي ستراقب سجلّات خادوم الويب لدينا بحثًا عن أنماط سلوك مُعيّن.

تتميّز كل jails داخل ملف الإعدادات بترويسة header تحتوي اسم الـ jail بين قوسين مربّعين (كل قسم يشير إلى إعدادات jail مُحدّدة ما عدا القسم [DEFAULT])، وافتراضيًّا نجد ssh] jail] هي الوحيدة المُمكّنة.

لتمكين مراقبة السّجلّات بحثًا عن محاولات تسجيل دخول Nginx سنقوم بتمكين [jail [nginx-http-auth، نُعدّل الأمر التّوجيهي enabled داخل هذا القسم بحيث يصبح true:

etc/fail2ban/jail.local/

[nginx-http-auth]

enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
. . .

إنّ jail السّابقة هي jail الوحيدة الخاصّة بـ Nginx التي يتم تضمينها مع حزمة fail2ban الخاصّة بـ Ubuntu. نستطيع على أيّة حال إنشاء jails الخاصّة بنا لإضافة وظائف إضافيّة، نجد في هذا الرابط بعض من تفاصيل تنفيذ jails الإضافيّة هنا وهنا.

بإمكاننا إنشاء nginx-noscript] jail] لحظر العملاء الذين يبحثون عن تنفيذ واستغلال Script على الموقع، إن لم نكن نستخدم PHP أو أي لغة برمجة أخرى بالتزامن مع خادوم الويب لدينا فبإمكاننا إضافة هذه الـ jail لحظر من يطلب هذا النوع من الموارد:

etc/fail2ban/jail.local/

[nginx-noscript]

enabled = true
port = http,https
filter = nginx-noscript
logpath = /var/log/nginx/access.log
maxretry = 6
. . .

نستطيع إضافة قسم يُدعى [nginx-badbots] لإيقاف بعض أنماط طلبات الروبوتات الخبيثة المعروفة:

etc/fail2ban/jail.local/

[nginx-badbots]

enabled = true
port = http,https
filter = nginx-badbots
logpath = /var/log/nginx/access.log
maxretry = 2

وإن لم نكن نستخدم Nginx لتزويدنا بالنفاذ إلى محتوى الويب داخل الدّليل الرئيسي Home directory للمستخدم فبإمكاننا حظر المستخدمين الذين يطلبون هذه الموارد بإضافة nginx-nohome] jail]:

etc/fail2ban/jail.local/

[nginx-nohome]

enabled = true
port = http,https
filter = nginx-nohome
logpath = /var/log/nginx/access.log
maxretry = 2

ينبغي علينا حظر العملاء الذين يحاولون استخدام خادوم Nginx لدينا كوسيط مفتوح open proxy، نستطيع إضافة nginx-noproxy] jail] لتتناسب مع هذه الطلبات:

etc/fail2ban/jail.local/

[nginx-noproxy]

enabled = true
port = http,https
filter = nginx-noproxy
logpath = /var/log/nginx/access.log
maxretry = 2

بعد أن ننتهي من التعديلات التي نرغب بها نحفظ الملف ونغلقه، يتوجّب علينا الآن إضافة المُرشّحات filters من أجل jails التي قمنا بإنشائها.

إضافة المرشحات من أجل Nginx Jails الإضافية

لقد قمنا بتحديث الملف etc/fail2ban/jail.local/ ببعض مواصفات jail الإضافيّة لتتناسب مع حظر مدى كبير من السّلوك السّيء، نحتاج لإنشاء ملفات ترشيح filter من أجل jails التي أنشأناها، حيث تُحدّد هذه الملفات الأنماط التي سنبحث عنها داخل سجلّات Nginx.

فلنبدأ بالانتقال إلى دليل المُرشّحات filters:

cd /etc/fail2ban/filter.d

نريد فعليًّا أن نبدأ بضبط مُرشِّح الاستيثاق المزوّد مُسبقًا مع Nginx لكي يتناسب مع أنماط فشل تسجيل الدّخول الموجودة في السّجلّات، نفتح الملف لتحريره:

sudo nano nginx-http-auth.conf

نُضيف نمط جديد تحت التّخصيص failregex، حيث يتناسب هذا النّمط مع الأسطر التي توافق عدم إدخال المستخدم لاسم مستخدم أو كلمة سر:

etc/fail2ban/filter.d/nginx-http-auth.conf/

[Definition]

failregex = ^ \[error\] \d+#\d+: \*\d+ user "\S+":? (password mismatch|was not found in ".*"), client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"\s*$
            ^ \[error\] \d+#\d+: \*\d+ no user/password was provided for basic authentication, client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"\s*$

ignoreregex =

بعد الانتهاء نقوم بحفظ وإغلاق الملف.

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

sudo cp apache-badbots.conf nginx-badbots.conf

ننشئ بعد ذلك مُرشّح من أجل nginx-noscript] jail]:

sudo nano nginx-noscript.conf

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

etc/fail2ban/filter.d/nginx-noscript.conf/

[Definition]

failregex = ^<HOST> -.*GET.*(\.php|\.asp|\.exe|\.pl|\.cgi|\.scgi)

ignoreregex =

نقوم بحفظ الملف وإغلاقه.

ننشئ بعد ذلك مُرشّحًا من أجل nginx-nohome] jail]:

sudo nano nginx-nohome.conf

نضع معلومات المرشّح التالية في الملف:

etc/fail2ban/filter.d/nginx-nohome.conf/

[Definition]

failregex = ^<HOST> -.*GET .*/~.*

ignoreregex =

بعد الانتهاء نقوم بحفظ وإغلاق الملف.

بإمكاننا أخيرًا إنشاء المرشّح من أجل nginx-noproxy] jail]:

sudo nano nginx-noproxy.conf

يتوافق تعريف المرشّح مع محاولات استخدام خادومنا كوسيط proxy:

etc/fail2ban/filter.d/nginx-noproxy.conf/

[Definition]

failregex = ^<HOST> -.*GET http.*

ignoreregex =

بعد الانتهاء نقوم بحفظ وإغلاق الملف.

تفعيل Nginx Jails لدينا

لكي يتم تنفيذ تغييراتنا على الإعدادات نحتاج إلى إعادة تشغيل خدمة fail2ban، نستطيع فعل ذلك بكتابة ما يلي:

sudo service fail2ban restart

ينبغي أن يتم إعادة تشغيل الخدمة وتنفيذ سياسات الحظر المختلفة التي قمنا بإعدادها.

الحصول على معلومات حول Jails التي تم تمكينها

نستطيع رؤية جميع jails التي تمّ تمكينها لدينا باستخدام الأمر fail2ban-client:

sudo fail2ban-client status

ينبغي أن نشاهد قائمة بكامل jails التي قمنا بتمكينها:

Status
|- Number of jail: 6
`- Jail list: nginx-noproxy, nginx-noscript, nginx-nohome, nginx-http-auth, nginx-badbots, ssh

نستطيع النظر إلى iptables لكي نرى أنّ fail2ban قامت بتعديل قواعد الجّدار النّاري لدينا لإنشاء إطار عمل لمنع العملاء، وحتى بدون قواعد الجّدار النّاري السابقة سيكون لدينا الآن إطار عمل مُمكّن يسمح لـ fail2ban بحظر العملاء انتقائيًّا عن طريق إضافتهم إلى سلاسل chains مبنيّة لهذا الغرض:

sudo iptables -S

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-nginx-badbots
-N fail2ban-nginx-http-auth
-N fail2ban-nginx-nohome
-N fail2ban-nginx-noproxy
-N fail2ban-nginx-noscript
-N fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-noproxy
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-nohome
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-badbots
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-noscript
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A fail2ban-nginx-badbots -j RETURN
-A fail2ban-nginx-http-auth -j RETURN
-A fail2ban-nginx-nohome -j RETURN
-A fail2ban-nginx-noproxy -j RETURN
-A fail2ban-nginx-noscript -j RETURN
-A fail2ban-ssh -j RETURN

وإن أردنا رؤية تفاصيل حظر مُطبَّق من قبل أي jail فمن الأسهل ربّما استخدام الأمر fail2ban-client مرة أخرى:

sudo fail2ban-client status nginx-http-auth

Status for the jail: nginx-http-auth

|- filter
|  |- File list:        /var/log/nginx/error.log
|  |- Currently failed: 0
|  `- Total failed:     0
`- action
   |- Currently banned: 0
   |  `- IP list:
   `- Total banned:     0

اختبار سياسات Fail2Ban

من الهام اختبار سياسات fail2ban لكي نتأكّد من أنها تقوم بحظر نقل البيانات كما هو متوقّع، على سبيل المثال نستطيع إعطاء بيانات خاطئة في مُحث prompt استيثاق Nginx عدّة مرات، وبعد أن نتجاوز الحدّ ينبغي أن يتم حظرنا وألا نكون قادرين على الوصول للموقع، وإن قمنا بإعداد تنبيهات البريد الإلكتروني فيجب أن نرى رسائل حول الحظر في البريد الإلكتروني الذي قمنا باختياره لاستقبال التّنبيهات.

عندما ننظر إلى الحالة باستخدام الأمر fail2ban-client سنشاهد أنّ عنوان IP الخاص بنا يتم حظره من الموقع:

sudo fail2ban-client status nginx-http-auth

Status for the jail: nginx-http-auth
|- filter
|  |- File list:        /var/log/nginx/error.log
|  |- Currently failed: 0
|  `- Total failed:     12
`- action
   |- Currently banned: 1
   |  `- IP list:       111.111.111.111
   `- Total banned:     1

وعندما نكون مقتنعين بأنّ قواعدنا تعمل بشكل صحيح نستطيع فك الحظر يدويًّا عن عنوان IP الخاص بنا عن طريق الأمر fail2ban-client بكتابة ما يلي:

sudo fail2ban-client set nginx-http-auth unbanip 111.111.111.111

نبغي أن نكون الآن قادرين على محاولة الاستيثاق مرة أخرى.

الخاتمة

إنّ إعداد fail2ban لحماية خادوم Nginx لدينا هو عمليّة سهلة إلى حدٍّ ما في أبسط الحالات، توفّر fail2ban على أيّة حال قدرًا كبيرًا من المرونة لبناء سياسات تُلائِم احتياجاتنا الأمنيّة، وبإلقاء نظرة على المتغيّرات والأنماط داخل الملف etc/fail2ban/jail.local/ والملفات التي يعتمد عليها داخل الدّليل etc/fail2ban/filter.d/ والدّليل etc/fail2ban/action.d/ نجد العديد من الأجزاء التي يمكننا تطويعها tweak وتغييرها لكي تلبّي احتياجاتنا، إنّ تعلّم أساسيّات كيفيّة حماية خادومنا باستخدام fail2ban يزوّدنا بقدرٍ كبير من الأمان وبأقل جهد.

إن كنت ترغب في تعلّم المزيد حول fail2ban قم بزيارة الروابط التالية:

• كيف تعمل Fail2Ban لحماية الخدمات على خادوم لينِكس.
• كيفيّة حماية SSH باستخدام Fail2Ban على Ubuntu 14.04.

ترجمة -وبتصرّف- لـ How To Protect an Nginx Server with Fail2Ban on Ubuntu 14.04 لصاحبه Justin Ellingwood.

يُعد إنجن إكس NginX خادوم ويب Web Server ذو أداء عالي وهو مسؤول عن معالجة العبء الواقع على بعض أكبر المواقع الإلكترونية Web Sites على الإنترنت Internet. وهو جيد خصوصًا في معالجة الكثير من الاتصالات المتزامنة concurrent ويتفوق في تخديم المحتوى الثابت static content.

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

فهم سياقات الإعدادات في Nginx

سيُغطي هذا الدليل البنية الأساسية الموجودة في ملف الإعدادات الرئيسي Nginx. قد يختلف مكان هذا الملف وفقًا للطريقة التي اتبعتها عند تثبيت البرمجية Software على الخادوم. إلا أنَّك سوف تجده في العديد من التوزيعات distributions على المسار التالي:

/etc/nginx/nginx.conf

إنّ لم يكن موجودًا فقد تجده على المسار:

/usr/local/nginx/conf/nginx.conf

أو المسار:

/usr/local/etc/nginx/nginx.conf

إنّ أحد أول الأمور التي ينبغي عليك ملاحظتها عندما تنظر إلى ملف الإعدادات الرئيسي هي أنَّه منظَّم في بنيةٍ من ثلاثة أقسام تعرّف بداية ونهاية كلٍ منها بالقوسين } و {. تسمى الأقسام المعرّفة باستخدام القوسين سياقات contexts وفقًا للغة Nginx، وذلك لأنها تحوي على إعداداتٍ مُفَصَّلة وموزعة بين تلك الأقسام وفقًا للمجال الذي يُعنى به كل قسم. يقدم هذا التقسيم بشكل أساسي بنيةً منظّمة وفق بعض الشروط المنطقية التي تقرّر فيما إن كان ينبغي تطبيق الإعدادات التي يحويها القسم أو لا.

وباعتبار أنه يمكن للسياقات أن تتداخل فيما بينها فإنNginx يقدم مستوًا من وراثة التعليمات directive inheritance. كقاعدةٍ عامة، إن كانت التعليمة صالحةً في عدّة مجالات scopes متدخلة فإنّ التصريح عنها في سياق أعلى boarder context سيُمرّر لأي سياقٍ أدنى (سياق ابن child context) كقيم افتراضية. يمكن للسياقات الأدنى أن يعيد تعريف override تلك القيم لاحقًا. جدير بالذكر أنّ عملية إعادة التعريف إلى أي مصفوفة-نوع array-type سينتج عنها استبدال القيم السابقة وليس إضافة append القيم الجديدة لها.

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

سنناقش فيما يلي أكثر السياقات شيوعًا والتي قد تصادفها عند استخدامك Nginx.

السياقات الأساسية

أول مجموعة سياقات سنشرحها هي السياقات الأساسية core contexts التي يستخدمها Nginx لإنشاء شجرة هرمية hierarchical tree وتوزيع الإعدادات - بحسب مهمّتها - في كتل Blocks منفصلة. تشكّل تلك السياقات البنية الأساسية لإعدادات Nginx.

السياق الأساسي

إن أكثر سياق عام هو السياق الأساسي Main Context، والذي يدعى أيضًا بالسياق العام Global Context. إذ أنه السياق الوحيد غير المحتوى ضمن كتل السياق القياسية والتي تبدو كما يلي:

# السياق الأساسي يوجد هنا، السياقات الأخرى تكون خارجا
. . .
context {
    . . .
}

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

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

إن بعض التفاصيل الشائعة والتي تُهيّئ في السياق الرئيسي هي المستخدم user والمجموعة group التي ستُشغّل العمليات العاملة worker processes باسمهما، بالإضافة لعدد العمليات العاملة والملف الذي سيحتفظ بمعرّف العملية الرئيسية PID. يمكن أيضًا أن يُضبط ملف الأخطاء الافتراضي لكامل التطبيق ضمن هذا المستوى (كما يمكن أن يُعاد تعريف الملف ضمن سياقات مخصّصة أكثر).

سياق الأحداث

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

سوف يبدو هذا السياق ضمن ملف الإعدادات كما يلي، خارج أقواس أي سياقٍ آخر:

# السياق الأساسي

events {
    # سياق الأحداث
    . . .
}

يستخدم Nginx وحدة معالجة اتصال مقادة بالأحداث event-based connection processing model لذلك فإن التعليمات المعرّفة داخل هذا السياق تحدّد كيف ينبغي على العمليات العاملة worker processes معالجة الاتصالات connections. تُستخدم التعليمات الموجودة هنا بشكل أساسي إما في اختيار الطريقة المستخدمة في معالجة الاتصال أو لتغيير كيفية تحقيق implement تلك الطرق methods.

عادةً ما تُختار طريقة معالجة الاتصال تلقائيًا بالاعتماد على أكثر الخيارات - التي توفّرها منصّة العمل platform - فاعليةً. بالنسبة لأنظمة لينكس Linux، فعادةً ما تكون طريقة epoll هي الخيار الأفضل.

هنالك عناصر أخرى يمكن ضبطها، كعدد الاتصالات التي يمكن لكل عملية عاملة أن تعالجها، وفيما إن كان على العملية أن تأخذ اتصالًا تلو الآخر أو أن تأخذ كل الاتصالات المنتظرة بعد أن يتم إعلامها بوجودها. وأيضًا فيما إن كان على العمليات العاملة أن تتناوب في الرد على الأحداث.

سياق HTTP

عند إعداد Nginx كخادوم ويب أو خادوم وكيل معكوس reverse proxy، فسيحتفظ سياق HTTP بغالبية الإعدادات. سيحتوي السياق على كل التعليمات والسياقات الأخرى الضرورية لتعريف كيفية معالجة البرنامج لاتصالات HTTP أو HTTPS.

يُعد سياق HTTP أخًا لسياق الأحداث - أي أنهما يقعان في نفس المستوى - إذ أن كلاهما يُعد ابنًا للسياق الرئيسي، لذلك ينبغي أن يُدرجا جنبًا إلى جنب بدلًا من أن يتداخلا:

# السياق الأساسي

events {
    # سياق الأحداث
    . . .
}

http {
    # سياق HTPP
    . . .
}

فيما تختص السياقات الدنيا lower contexts في كيفية معالجات الطلبات، فإن التعليمات في هذا المستوى تتحكم بالقيم الافتراضية لكل الخواديم الافتراضية المعرّفة داخله. هنالك عدد كبير من التعليمات القابلة للضبط configurable ضمن هذا السياق والسياقات المحتواة ضمنه، يعتمد ذلك على طريقة التوريث inheritance التي ترغب أن يتم العمل وفقها.

فيما يلي مجموعة من التعليمات التي يمكن أن تصادفها خلال ضبط إعدادات Nginx:

• تعليمات تتحكم بالمواقع الافتراضية لسجلات الوصول والأخطاء مثل (access_log و error_log).
• تعليمات تضبط عمليات القراءة والكتابة I/O غير المتزامنة asynchronous من وإلى الملفات مثل (aio و sendfile و directio)،
• تعليمات تضبط حالات الخادوم عندما تحدث الأخطاء مثل (error_page).
• تعليمات تضبط عملية الضغط compression مثل (gzip و gzip_disable).
• عمليات تحسّن fine-tune إعدادات اتصال TCP الحي TCP keep alive مثل (keepalive_disable و keepalive_requests و keepalive_timeout).
• القواعد rules التي يتبعها Nginx عندما يحاول تحسين optimize الحزم packets واستدعاءات النظام system calls مثل (sendfile و tcp_nodelay و tcp_nopush).
• تعليمات تضبط جذر المستندات document root وفهرس الملفات index files على مستوى التطبيق application-level مثل (root و index).
• تعليمات تهيّئ العديد من جداول المقابلة hash tables المستخدمة لتخزين أتماط مختلفة من البيانات مثل (*_hash_bucket_size و *_hash_max_size المستخدمتين مع server_names بالإضافة لـ types و variables).

سياق الخادوم

يُعرّف سياق الخادوم Server Context ضمن سياق HTTP، ويُعد ذلك أوّل مثال لنا عن السياقات المتداخلة. كما أنّه أوّل سياق مرّ معنا يمكن تعريفه عدّة مرات.

قد يبدو التنسيق العام لسياق الخادوم مشابهًا لما يأتي، تذكّر أنّ هذا السياق سيقع ضمن سياق HTTP:

# السياق الأساسي

http: {

    # سياق HTTP

    server {
    # سياق خادوم أول
    }

    server {
    # سياق خادوم ثاني
   }

}

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

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

• تعليمة التنصت listen: تُصمَّم كتلة الخادوم للرد على الطلبات الواردة من مصدر معرّف بثنائية عنوان الإنترنت IP / المنفذ Port. فإن ورد طلب request من مستخدم يطابق ذلك المصدر فمن المحتمل أن يتم اختيار تلك الكتلة لمعالجة الاتصال.
• تعليمة اسم الخادم server_name: هذه التعليمة هي المكوّن الآخر المستخدم في اختيار كتلة الخادوم التي ستقوم بالمعالجة. إن كان هنالك العديد من كتل الخادوم مزوّدةً بتعليمات تنصت مضبوطة بنفس القيم ويمكنها أن تعالج الطلب، فسيحلّل إنجن إكس ترويسة المُضيف Host header الخاصة بالطلب ويطابقها مع التعليمة.

يمكن للتعليمات الموجودة ضمن هذا السياق أن تعيد تعريف العديد من التعليمات المعرّفة في سياق HTTP بما فيها تعليمات التسجيل logging، وجذر المستندات، والضغط، وإلى ما هنالك. وبالإضافة إلى التعليمات المأخوذة من سياق HTTP، فبإمكاننا أيضًا إعداد ملفات لمحاولة الرد على الطلبات عبر تعليمة (try_files)، وإصدار أمر لإعادة التوجيه وإعادة الكتابة (return و rewrite)، وضبط المتحولات عبر تعليمة (set).

سياق الموقع

السياق التالي الذي ستتعرف عليه هو سياق الموقع location context وهو سياقٌ ستتعامل معه بشكل متكرّر. تتشارك سياقات الموقع العديد من الصفات مع سياقات الخادوم. فمثلًا، يمكن تعريف أكثر من سياق موقع، ويُستخدم كل منها لمعالجة نوع محدّد من طلبات المستخدم، ويتم اختيار كل موقع بناءًا على مطابقة تعريف الموقع مع طلب المستخدم باستخدام خوارزمية انتقاء.

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

تبدو الصيغة العامة كما يلي:

location match_modifier location_match {
    . . .
}

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

# السياق الأساسي

server {
    # سياق الخادوم

    location /match/criteria {
        # سياق موقع أول
    }

    location /other/criteria {
        # سياق موقع ثاني
 
        location nested_match {
            # موقع أول
        }
 
        location other_nested {
            # موقع ثاني
        }
    }
}

بينما يتم اختيار سياقات الخواديم وفقًا لثنائية عنوان IP / المنفذ المطلوبة ولاسم المضيف الموجود ضمن ترويسة المضيف، فإن كتل الموقع تقسّم معالجة الطلب ضمن كتلة الخادوم بالنظر إلى معرّف الموارد الموّحد URI الخاص بالطلب. إن معرّف URI الخاص بالطلب هو جزءٌ من الطلب يأتي بعد اسم النطاق domain name وثنائية عنوان IP / المنفذ.

لذلك فإن طلب المستخدم http://www.example.com/blog على المنفذ 80، يستخدم العنوان http www.example.com والمنفذ 80 لتحديد كتلة الخادوم التي سيتم اختيارها. بعد اختيار الخادوم، سيُطابق الجزء /blog (المُمثّل لمعرّف URI الخاص بالطلب) مع المواقع المعرّفة لتحديد السياق الإضافي الذي ينبغي استخدامه ليرد على الطلب.

إنّ العديد من التعليمات التي يمكن أن تراها في سياق الموقع متوفّرةٌ أيضًا في مستويات الآباء (المستويات الأعلى) parent levels. فيما يلي مجموعة جديدة من التعليمات المستخدمة ضمن هذا المستوى تسمح لك بالوصول إلى المواقع الواقعة خارج جذر المستندات (تعليمة alias)، وتحديد الموقع كموقع يمكن الوصول له من الداخل فقط (تعليمة internal)، وكوكيل لخواديم أو مواقع أخرى (باستخدام برتوكولات http، fastcgi، scgi، uwsgi)

سياقات أخرى

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

لكننا لن نناقش كل السياقات المتوفّرة، ولن نخوض بشرح السياقات الآتية بالتفصيل:

• split_clients أُعد هذا السياق لتقسيم المستخدمين اللذين يستقبلهم الخادوم إلى فئات categories عبر عنونتهم بمتحولات تعتمد على النسبة المئوية. يمكن أن يُستخدم ذلك لاحقًا للقيام باختبار A/B عبر توفير محتويات content مختلفة لمُضيفين hosts مختلفين.
• perl / perl_set يُهيّئ هذين السياقين معالجات بيرل Perl للموقع الذي تتواجد ضمنه. تستخدم هذه السياقات للمعالجة باستخدام بيرل فقط.
• map يُستخدم هذا السياق لضبط قيمة متحول بالاعتماد على قيمة متحول آخر. إذ أنه يوفّر جدول مقابلة mapping لقيم المتحوّل الأول حتى يحدّد القيمة التي ينبغي ضبط المتحول الثاني بها.
• geo يُستخدم هذا السياق - مثل السياق السابق - في تحديد جدول مقابلة. إلا أنّ هذا الجدول يستخدم خصيصًا لتصنيف عناوين IP. يضبط هذا السياق قيمة متحول وفقًا لعنوان IP المتّصل.
• types يُستخدم هذا السياق أيضًا لجداول المقابلة. إذ أنه يُستخدم لمقابلة أنماط وسائط الإنترنت MIME بامتدادات (لواحق) extensions  الملفات التي ينبغي ربطهم بها. يوفّر Nginx ذلك عادةً عبر ملف يُضمّن محتواه داخل ملف الإعدادات nginx.conf.
• charset_map يمثّل هذا السياق مثالًا آخر عن سياقات المقابلة، إذ أنه يُستخدم لإنشاء جدول مقابلة للتحويل conversion table من مجموعة محارف إلى مجموعة أُخرى. تضمّن كلا المجموعتين في ترويسة هذا السياق، ويضمّن جدول المقابلة في بنيته body.

إنّ السياق التالي ليس شائعًا بقدر السياقات التي شرحناها حتى الآن، إلا أنّ التعرّف عليه يبقى مفيدًا.

سياق مجموعة الخواديم العليا

يُستخدم سياق مجموعة الخواديم العليا upstream context لتعريف وإعداد الخواديم العليا upstream. يعرّف هذا السياق بشكل أساسي حوضًا pool معرّفًا باسم يحتوي على مجموعة الخواديم التي يستطيع Nginx أن يعمل كوكيل proxy عنها للطلبات. ستستخدم هذا السياق على الأرجح عندما تُعد وكلاءًا من مختلف الأنواع.

يجب وضع سياق مجموعة الخواديم العليا ضمن سياق HTTP، وخارج كلِّ سياقات الخواديم. تبدو الصيغة العامة له كما يلي:

# السياق الأساسي

http {
    # سياق HTTP

    upstream upstream_name {
        # سياق مجموعة الخواديم العليا
        server proxy_server1;
        server proxy_server2;
        . . .
    }

    server {
        # سياق خادوم
   }
}

يمكن فيما بعد أن تتم الإشارة إلى سياق مجموعة الخواديم العليا باسمه ضمن الخادوم أو كتل الموقع لتمرير طلبات ذات نوع محدّد لحوض الخواديم الذي تمّ تعريفه. ستستخدم عندها مجموعة الخواديم خوارزميةً لتحديد الخادوم الذي ينبغي أن يسلم الطلب له، تستخدم خوارزمية راوند روبن round-robin بشكل افتراضي. يسمح هذا السياق لـNginx أن يعمل على موازنة الحمل load balancing عندما يعمل كوكيل للطلبات.

سياق البريد

بالرغم من أن Nginx يُستخدم عادةً كخادوم ويب أو خادوم وكيل معكوس، إلا أنه يعمل كخادوم وكيل للبريد mail proxy server بأداءٍ عالي جدًا. يسمّى السياق المستخدم لهذا النوع من التعليمات بالبريد mail. يعرّف سياق البريد The mail context ضمن السياق العام، أو السياق الأساسي (خارج سياق HTTP).

الوظيفة الأساسية لسياق البريد هي توفير مجال لإعداد وكيل للبريد على الخادوم. يمكن لـNginx أن يعيد توجيه redirect طلبات المصادقة authentication لخادوم مصادقة خارجي authentication server. ويمكنه بعد ذلك أن يوفّر الوصول إلى خواديم البريد العاملة ببرتوكولات POP3 و IMAP لجلب بيانات البريد الفعلية. يمكن لسياق البريد أن يُعد أيضًا للاتصال بخادوم الترحيل العامل ببرتوكول SMTP (SMTP Relayhost) إن دعت الحاجة.

عمومًا، قد يبدو شكل سياق البريد مشابهًا لما يلي:

# السياق الأساسي

events {
    # سياق الأحداث
}

mail {
    # سياق البريد
}

السياق الشرطي

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

يُقدَّم السياق if في Nginx من قِبل وحدة إعادة الكتابة rewrite module وهي الغاية الأساسية من استخدام هذا السياق. باعتبار أنّ Nginx سيختبر حالات الطلب باستخدام العديد من التعليمات الأخرى المعمولة لهذا الغرض، فلا ينبغي استخدام تعليمة if في أغلب حالات التنفيذ الشرطي. تُعد هذه الملاحظة هامةً لدرجة أنّ مجتمع Nginx أنشأ صفحةً وسمّاها if الشريرة.

إنّ المشكلة الأساسية هي أنّ ترتيب المعالجة لدى Nginx قد يؤدي في كثير من الأحيان إلى نتائج غير متوقعة تظهر وكأنها تقلب معنى كتلة if رأسًا على عقب. تُعد تعليمتي إعادة التوجيه return وإعادة الكتابة rewrite التعليمتين الوحيدتين اللتين يعتبر استخدامهما آمنًا داخل هذه السياقات، إذ أنها أُنشئت لأجلهما. ضع في الحسبان أيضًا أنّه عند استخدام سياق if فإنّه يقدّم تعليمة try_files داخل نفس السياق بلا فائدة.

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

# السياق الأساسي

http {

    # سياق HTTP
    server {
        # سياق خادوم

        location location_match {
            # سياق موقع
            if (test_condition) {
                #  سياق شرطي if
            }
        }
    }
}

سياق تحديد الاستثناءات

يُستخدم سياق تحديد الاستثناءات Limit_except Context لتحديد استخدام طرق HTTP Methods محدّدة داخل سياق الموقع. فمثلًا، إن كان ينبغي لمجموعة محدّدة فقط من المستخدمين أن يصلوا إلى محتوى طريقة POST Method، أما البقيّة فينبغي أن يتمكّنوا من قراءة المحتوى، فيمكنك استخدام كتلة limit_except لتعريف تلك المتطلّبات.

سيبدو المثال السابق مشابهًا لما يلي:

. . .

# سياق موقع أو خادوم

location /restricted-write {
    # سياق موقع

    limit_except GET HEAD {
        # سياق تحديد الاستثناءات
        allow 192.168.1.1/24;
        deny all;
    }
}

ستطبق التعليمات الموجودة داخل السياق - والتي يقصد منها تقييد الوصول - عند مصادفة أيٍ من طرق HTTP باستثناء تلك المدرجة ضمن ترويسة السياق. إنّ نتيجة المثال السابق هي أنّه بإمكان أي مستخدم استخدام أفعال GET و HEAD، إلا أنّه يسمح فقط للمستخدمين المتصلين من الشبكة الفرعية subnet ذات العنوان 192.168.1.1/24 باستخدام طرق أخرى.

قواعد عامة حول السياقات ينبغي اتباعها

الآن وبعد أن أصبح لديك فكرة عن السياقات الشائعة التي يمكن أن تصادفها أثناء استعراضك لإعدادات إنجن إكس، فبإمكاننا شرح بعض القواعد المُثلى التي يمكن اتباعها عند التعامل مع سياقات Nginx.

تطبيق التعليمات في أعلى سياق متوفر

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

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

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

http {

    server {

        location / {
            root /var/www/html;
            . . .
        }

        location /another {
            root /var/www/html;
            . . .
        }
    }
}

يمكنك نقل الجذر خارج كتلة الخادوم، أو حتى لكتلة HTTP كما يلي:

http {

    root /var/www/html;

    server {

        location / {
            . . .
        }

        location /another {
            . . .
        }
    }
}

أغلب الأحيان، سيكون مستوى الخادوم ملائمًا أكثر، إلا أنّ التصريح declaring في مستوىً أعلى له محاسنه. إنّ ذلك لا يسمح بضبط التعليمة في أماكن أقل فحسب، وإنما سيسمح لك بتمرير القيمة الافتراضية لكل الأبناء، ما يمنع ظهور الحالات التي تصادف فيها خطأً لأنك نسيت تعليمةً ضمن مستوىً أدنى. يمكن أن يكون ذلك مشكلةً كبيرةً في الإعدادات الطويلة. إن التصريح في مستوىً عالي يوفّر لك قيمةً افتراضيةً صحيحة.

استخدام عدة سياقات أشقاء عوضا عن المنطق الشرطي If في المعالجة

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

أول مشكلة هي أنّ تعليمة if عادةً ما تعيد نتائج لا تتوافق مع توقعات مدير النظام administrator. مع أنّ المعالجة ستُؤدي دائمًا إلى نفس النتائج عند توفير نفس المُدخلات، إلا أنّ الطريقة التي يتبعها Nginx في تفسير البيئة يمكن أن تختلف كثيرًا عما هو متوقع ما ام تخضع لاختبارات مكثّفة.

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

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

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

الخلاصة

إلى هنا، ينبغي أن تكون قد حصلت على فهم جيّد لأكثر سياقات Nginx شيوعًا وللتعليمات التي تُنشئ الكتل التي تعرّف تلك السياقات.

تحقّق دائمًا من توثيق Nginx للحصول على معلومات حول أي السياقات هو الأنسب لوضع تعليمة ما بداخله ولتقييم الموقع الأكثر فاعلية. إنّ الحرص أثناء إنشاء الإعدادات لن يسهل من عملية الصيانة فحسب، بل أنه سيرفع الأداء أيضًا في أغلب الآحيان.

ترجمة -بتصرف- للمقال Understanding the Nginx Configuration File Structure and Configuration Contexts لكاتبه Justin Ellingwood.

TLS، أو حماية طبقة النقل (Transport Layer Security)، وسلفها SSL أو طبقة الحِزَم الآمنة (Secure Sockets Layer) هما عبارة عن بروتوكولات آمنة يتم إنشاؤها بهدف توجيه تدفّق البيانات العادية (traffic) ضمن طريق مشفّر وآمن أثناء تنقّلها، وقد قمنا سابقا بشرح كيفية إعداد SSL على خادوم Apache، سنقوم في هذا الدرس بشرح كيفية إعداده مع خادوم nginx.

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

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

المتطلبات

قبل أن تبدأ، يجب أن تهتم ببعض الإعدادات بالطبع.

سنستخدم مستخدمًا غير مستخدم الجذر مع صلاحيات sudo في هذا الدرس. يمكنك إعداد واحد عبر اتباع الخطوات المذكورة في درسنا حول إعداد خادوم أوبونتو 14.04 الابتدائي.

ستحتاج أيضًا إلى تثبيت خادوم Nginx. إذا كنت تريد إعداد خادوم LEMP كامل (Linux, Nginx, MySQL, PHP) فإنّه يمكنك مراجعة درسنا حول تثبيت LEMP على أوبونتو 14.04.

إذا كنت تريد خادوم Nginx فقط، فيمكنك تثبيته بواسطة:

sudo apt-get update
sudo apt-get install nginx

الخطوة الأولى: إنشاء شهادة SSL

فلنبدأ عبر إنشاء مسار فرعي ضمن مجلّد إعدادات خادوم Nginx لنضع ملفّات الشهادة التي سنقوم بإنشائها فيه:

sudo mkdir /etc/nginx/ssl

والآن وبعد أن قمنا بإنشاء ذلك المسار، يمكننا أن نقوم بإنشاء تلك الملفّات بأمر واحد وهو:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt

سيتم سؤالك عدّة أسئلة. قبل أن نتعرّف عليها، فلنتعرّف على ما يعنيه الأمر السابق:

• openssl: هذا هو الأمر الأساسي الذي يتم توفيره بواسطة OpenSSL لإنشاء وإدارة الشهادات، المفاتيح وطلبات التوقيع.. إلخ.
• req: يحدد هذا الأمر الفرعي أننا نريد استخدام إدارة طلبات توقيع الشهادة X.509. X.509 هو عبارة عن معيار بنية تحتية للمفتاح العمومي يحتاجه كلٌّ من SSL وTLS لإدار الشهادات. نريد أن نقوم بإنشاء شهادة X.509 جديدة، ولذلك فإننا سنستخدم هذا الأمر الفرعي.
• x509-: يقوم هذا أيضًا بتعديل الأمر السابق عبر إخبار الأداة أننا نريد إنشاء شهادة موقّعة ذاتيًا عوضًا عن إنشاء طلب توقيع شهادة، والذي كان ليحدث بالحالة العادية.
• nodes-: يخبر هذا الخيار OpenSSL بأننا لا نريد تأمين ملفّ المفتاح الخاصّ بنا بجملة مرور، لأنّ استخدام هذا الخيار سيعترض طريق خادوم nginx عندما يتم تشغيله تلقائيًا حيث أنّه يجب علينا إدخال جملة المرور في كلّ مرّة يبدأ فيها الخادوم وفي كلّ مرّة يتم فيها إعادة تشغيله.
• days 365-: يحدد هذا أنّ الشهادة التي سنقوم بإنشائها صالحة لمدّة 365 يومًا.
• newkey rsa:2048-: سينشئ هذا الخيار طلب الشهادة ومفتاحًا خاصًّا جديدًا في الوقت ذاته. هذا ضروري جدًا بما أننا لم نقم بإنشاء مفتاح خاصّ مسبقًا. يقوم rsa:2048 بإخبار OpenSSL بأن يقوم بتوليد مفتاح RSA بطول 2048 بت.
• keyout-: يسمّي هذا المُعامِل الملفّ الناتج لملفّ المفتاح الخاصّ الذي يتم إنشاؤه.
• out-: يسمّي هذا الخيار ملفّ الشهادة الناتج الذي نقوم بإنشائه.

كما وضّحنا أعلاه، ستقوم هذه الخيارات بإنشاء ملفّ مفتاح وشهادة. سيتم سؤالنا بضع أسئلة عن خادومنا بهدف تضمين المعلومات بشكل صحيح في تلك الشهادة.

قم بكتابة الأجوبة بشكل صحيح، أهمّ واحد منها هو جواب ذاك السؤال الذي يسألك عن:

"Common Name (e.g. server FQDN or YOUR name)". 

يجب أن تقوم بإدخال اسم نطاقك الذي تريد استخدامه مع خادومك، أو عنوان الـIP العام إذا كنتَ لا تمتلك نطاقًا بعد.

أجوبة الأسئلة ستبدو شيئًا كهذا:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []:your_domain.com
Email Address []:admin@your_domain.com

سيتم إنشاء الشهادة والمفتاح في مسار etc/nginx/ssl/.

الخطوة الثانية: إعداد Nginx ليستخدم SSL

الآن وبعد أن أصبح ملفّا الشهادة والمفتاح متوفّرين في مسار إعدادات Nginx، نحتاج الآن فقط إلى تعديل إعدادات خادوم Nginx الخاصّة بنا ليستفيد من التغييرات الجديدة. يمكنك تعلّم المزيد عن إعدادات خادوم Nginx من خلال قراءة تصنيف nginx على أكاديمية حسوب.

يستطيع الإصدار 0.7.14 والأعلى منه من Nginx (تأتي أوبونتو 14.04 بالإصدار 1.4.6) أن يقوم بتفعيل SSL في نفس كتلة الخادوم (Server Block) كتدفّق HTTP عادي. يسمح لنا هذا بإعداد الوصول إلى نفس الموقع بطريقةٍ مختصرة بشكل أكبر.

قد تبدو إعدادات الخادوم الخاصّة بك كالتالي:

server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        root /usr/share/nginx/html;
        index index.html index.htm;

        server_name your_domain.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

الشيء الوحيد الذي يجب علينا فعله لنجعل SSL تعمل على نفس الخادوم مع السماح باتصالات HTTP العادية هو إضافة السطور التالية:

server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        listen 443 ssl;

        root /usr/share/nginx/html;
        index index.html index.htm;

        server_name your_domain.com;
        ssl_certificate /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key /etc/nginx/ssl/nginx.key;

        location / {
                try_files $uri $uri/ =404;
        }
}

عندما تنتهي، احفظ الملفّ وأغلقه.

الآن ستحتاج إلى إعادة تشغيل خادوم Nginx فقط لكي تأخذ التغييرات مجراها:

sudo service nginx restart

سيقوم هذا بإعادة تحميل إعدادات موقعك، وسيصبح قادرًا على الاستجابة إلى كل من طلبات HTTP وHTTPS.

الخطوة الرابعة: اختبر إعداداتك

يجب الآن أن تعمل وظيفة SSL بشكلٍ جيّد معك، ولكن يجب علينا اختبارها لنتأكّد من ذلك.

أولًا، دعنا نتحقق أنّه ما يزال بإمكاننا الوصول إلى الموقع عبر بروتوكول HTTP العادي. في متصفّحك، قم بزيارة اسم نطاق الخادوم الخاصّ بك أو عنوان الـIP:

http://اسم_النطاق_أو_عنوان_الآي_بي

يجب أن ترى الموقع العادي. في حالتي، سأرى رسالة Nginx الافتراضية فقط:

إذا وصلت إلى هذه الصفحة، فهذا يعني أنّ خادومك ما يزال يخدم طلبات HTTP بشكل صحيح.

الآن يمكننا التحقق مما إذا كان خادومنا قادرًا على استخدام SSL للتواصل أم لا. قم بذلك عبر كتابة بروتوكول https عوضًا عن http:

https://اسم_النطاق_أو_عنوان_الآي_بي

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

هذه رسالة متوقّعة بمّا أنّ شهادتنا هي شهادة موقّعة ذاتيًا (self-signed). صحيح أّنّه لن يكون من الممكن استخدام شهادتنا للتحقق من هوية خادومنا، إلّا أنّ الخادوم سيزال قادرا على التواصل المشفّر.

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

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

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

الخاتمة

لقد قمتَ الآن بإعداد خادوم Nginx الخاصّ بك ليعالج كلًّا من طلبات HTTP وSSL. سيساعدك هذا على التواصل مع زوّارك بشكل أأمن بالإضافة إلى جعل الجهات الخارجية غير قادرة على قراءة تدفّق البيانات الخاصّ بك.

إذا كنتَ تخطط لإطلاق موقعٍ للعموم وتحتاج SSL، فإنّه يجب عليك شراء شهادة SSL من جهة شهادات موثوقة لموقعك لتجنّب ظهور رسالة التحذير الصفراء لزوّاك موقعك.

ترجمة -وبتصرف- للمقال: How To Create an SSL Certificate on Nginx for Ubuntu 14.04 لصاحبه: Justin Ellingwood.

حقوق الصورة البارزة: Designed by Freepik.

لقد أصبح Nginx أحد أكثر التطبيقات البرمجية المتوفرة لخواديم الويب Web Servers مرونةً وقوة. ولكن إذا ما نظرنا إليه من الناحية التصميمية فإنه يعد أولًا وقبل كل شيء خادومًا وسيطا Proxy Server. إن التركيز على أداء Nginx كوسيط يعني أنه ذو أداء عالي عندما يعمل على معالجة الطلبات بالتعاون مع خواديم أخرى.

يمكن لـ Nginx أن يلعب دور الوسيط باستخدام بروتوكولات Protocols http ,FastCGI ,uwsgi ,SCGI ,memcached. سنناقش في هذه المقالة استخدام FastCGI للقيام بالوساطة proxying، فهو يعد واحدًا من أكثر البرتوكولات التي تُستخدم لذلك الغرض.

لماذا نستخدم FastCGI للقيام بالوساطة؟

يستخدم FastCGI للقيام بالوساطة ضمن Nginx كي يترجم طلبات المستخدمين Clients لخادوم التطبيقات Application Server الذي لا يقوم بمعالجة طلبات المستخدمين مباشرةً أو الذي لا ينبغي له ذلك. إنّ FastCGI هو برتوكول مبني على برتوكول Common Gateway Interface الأقدم والذي يشار إليه اختصارًا CGI، وقد أُريد من بروتوكول FastCGI أن يحسّن أداء البروتوكول السابق عبر عدم معالجة كل طلب في عملية Process خاصة به. يُستخدم البرتوكول ليمثّل واجهة interface ذات فعالية أكبر مع الخواديم التي تعالج طلبات المحتوى الديناميكي.

إن معالجة PHP هي أحد حالات الاستخدام use-case الرئيسية لبرتوكول FastCGI ضمن Nginx. وعلى عكس أباتشي Apache، الذي يستطيع معالجة PHP مباشرةً باستخدام وحدة mod_php، فإنه ينبغي على Nginx الاعتماد على معالج PHP منفصل لمعالجة طلبات PHP. غالبًا ما تُنجز تلك المعالجة باستخدام php_fpm وهو معالج PHP قد اختبر بشكل كبير للعمل مع Nginx.

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

أسياسيات قيام FastCGI بالوساطة

عادةً ما تتضمن طلبات الوساطة proxying requests عنوان الخادوم الوسيط- Nginx في حالتنا- الذي يوجّه الطلبات من قبل المستخدمين إلى الخادوم الوسيط بينه (الخلفي) Backend Server. يستخدم Nginx التعليمة fastcgi_pass للتعريف عن الخادوم الفعلي الذي ستوجّه إليه الطلبات باستخدام برتوكول FastCGI. فمثلًا، لتوجيه أي طلب موافق للغة PHP إلى الخادوم الخلفي المخصص لمعالجة PHP باستخدام برتوكول FastCGI، فقد يبدو المقطع البرمجي للموقع Location Block مشابهًا لما يلي:

# server context

location ~ \.php$ {
   fastcgi_pass 127.0.0.1:9000;
}

. . .

في الواقع، لن يعمل المقطع السابق إذا ما تم تنفيذه على حاله لأنه يقدّم معلوماتٍ قليلةً جدًا. في كل مرّة يتم فيها إنشاء اتصال وسيط Proxy Connection فإنه يجب ترجمة الطلب الأصلي لضمان أن يتمكن الخادوم الخلفي من فهم الطلب المُدار Proxied request. وباعتبار أننا نغيّر البرتوكولات بتمرير الطلب عبر FastCGI فإن ذلك يتطلب بعض العمل الإضافي، سنصطلح في هذه المقالة على عملية تمرير الطلبات عبر FastCGI بتمرير FastCGI أي FastCGI pass.

إنّ القيام بالوساطة من بروتوكول Http وإليه http-to-http Proxying ينطوي بشكل رئيسي على زيادة حجم الترويسة Header ليضمن أن يمتلك الخادوم الخلفي المعلومات التي يحتاجها للرد على الخادوم الوسيط والذي ينوب بدوره عن المستخدم Client، أما FastCGI فهو برتوكول منفصل لا يستطيع قراءة ترويسات Http. مع أخذ ذلك بالحسبان فإن أية معلومات ذات صلة يجب أن تمرّر للخادوم الخلفي عبر وسيلة أخرى.

إن الطريقة الأساسية لتمرير المعلومات الإضافية عند استخدام برتوكول FastCGI هي باستخدام الإعدادات Parameters. حيث يجب أن يُهيّئ الخادوم الخلفي لقراءة تلك الإعدادات ومعالجتها والتصرّف وفقًا لقيمها. يستطيع Nginx أن يحدّد إعدادات FastCGI باستخدام التعليمة fastcgi_param.

إن الحد الأدنى للإعدادات الواجب ضبطها حتى يعمل FastCGI كوكيل PHP مشابهة لما يلي:

# server context

location ~ \.php$ {
   fastcgi_param REQUEST_METHOD $request_method;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   fastcgi_pass 127.0.0.1:9000;
}

. . .

لقد قمنا في الإعدادات السابقة بضبط إعدادات FastCGI وهما REQUEST_METHOD و SCRIPT_FILENAME. إن كل من الإعدادات السابقة ضرورية للخادوم الخلفي حتى يتمكن من فهم طبيعة الطلب. إذ أن الإعداد الأول يخبره بنوع العملية التي يجب أن يقوم بإنجازها، أما الإعداد الثاني فيخبر مجموعة الخواديم Upstream - التي تعالج طلبات الخادوم الوسيط- بالملف الذي يجب أن ينفّذه.

استخدمنا في المثال بعض المتغيرات variables في Nginx لضبط قيم تلك الإعدادات. سيحوي المتغير request_method$ على نوع الوظيفة http method التي طلبها المستخدم.

من ناحية أخرى فإن قيمة الإعداد SCRIPT_FILENAME هي عبارة عن دمج قيمتي المتغيرين document_root$ و fastcgi_script_name$. أما المتغير document_root$ فسيحوي على مسار المجلد الرئيسي والذي ضبط عبر التعليمة root. سيضبط المتغير fastcgi_script_name$ بمعرف الموارد الموحد URI المطلوب. إن انتهى  معرف URI للطلب request URI  بالرمز (/)، فستلحق قيمة التعليمة fastcgi_index في النهاية. إن هذا النوع من المرجعية الذاتية self-referential في تعريف الموقع ممكن لأننا نشغّل معالج FastCGI على نفس الجهاز الذي يشغّل Nginx. فلنلقي نظرة على مثال آخر:

# server context
root /var/www/html;

location /scripts {
   fastcgi_param REQUEST_METHOD $request_method;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   fastcgi_index index.php;
   fastcgi_pass unix:/var/run/php5-fpm.sock;
}

. . .

إن اختير الموقع location في المثال السابق ليعالج طلبًا في المسار: /scripts/test/ فإن قيمة المسار الوسيط SCRIPT_FILENAME ستنتج عن دمج قيم تعليمة root ومعرّف URI للطلب بالإضافة للتعليمة fastcgi_index. وبالتالي ستكون قيمة الإعداد في مثالنا هذا هي: var/www/html/scripts/test/index.php/

هنالك تعديل هام آخر قمنا به في الإعدادات السابقة، إذ أننا ضبطنا خادوم FastCGI الخلفي FastCGI backend ليستخدم مقبس يونيكس Unix Socket عوضًا عن مقبس شبكة Network socket. يمكن لـ Nginx أن يستخدم أيًا من الواجهتين Interface ليتصل مع مجموعة خواديم FastCGI Upstream. إن كان معالج FastCGI يعمل على نفس الخادوم فعادةً ما يُستحسن استخدام مقبس يونيكس من أجل الأمان.

شرح إعدادات FastCGI

هنالك قاعدة أساسية لكتابة نص برمجي (كود) Code قابل للصيانة وهي محاولة اتباع مبدأ DRY أي لا تكرر نفسك "Don’t Repeat Yourself". يساعد ذلك في تقليل الأخطاء بالإضافة لجعل الكود قابلًا لإعادة الاستخدام كما أنها تتيح تنظيمًا أفضل. إنّ أحد أكثر التوصيات الأساسية لإدارة Nginx هي أن تُضبط كل الأوامر في أوسع مجال ممكن لها، تطبّق تلك الأهداف الأساسية على إعداداتNginx أيضًا.

عند التعامل مع إعدادات الوسيط لـ FastCGI فسيتم تشارك الغالبية العظمى للإعدادات في معظم حالات الاستخدام. بسبب ذلك وبسبب الطريقة التي تعمل بها وحدة الوراثة inheritance التابعة لـ Nginx فإنه دائمًا ما يستحسن تعريف الوسطاء في مجال عام.

التصريح عن تفاصيل إعدادات FastCGI في السياقات الأم Parent Contexts

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

فمثلًا، يمكننا أن نعدّل على القسم العلوي من المقطع البرمجي السابق لجعله مفيدًا في عدة مواقع:

# server context
root /var/www/html;

fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;

location /scripts {
   fastcgi_pass unix:/var/run/php5-fpm.sock;
}

location ~ \.php$ {
   fastcgi_pass 127.0.0.1:9000;
}

. . .

إنّ كلًا من تصاريح fastcgi_param والتعليمة fastcgi_index في المثال السابق متوفرين لدى مقطعي الموقع location block الواردين لاحقًا. تلك هي إحدى الطرق لإزالة التكرار.

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

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

تورّث أي مصفوفة تعليمات إلى سياق أدنى، أو سياق ابن child context، بطريقة مختلفة عن بعض التعليمات الأخرى. ستورّث معلومات مصفوفة التعليمات إلى سياقات الأبناء فقط إن لم تكن موجودة في أي مكان ضمن سياق الابن. وذلك يعني أنك إن استخدمت تعليمة fastcgi_param ضمن موقعك فإنها ستمحي القيم الموروثة من السياق الأعلى تمامًا.

فمثلًا، يمكننا التعديل قليلًا على الإعدادات السابقة كما يلي:

# server context
root /var/www/html;

fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;

location /scripts {
   fastcgi_pass unix:/var/run/php5-fpm.sock;
}

location ~ \.php$ {
   fastcgi_param QUERY_STRING $query_string;
   fastcgi_pass 127.0.0.1:9000;
}

. . .

قد تعتقد للوهلة الأولى أنه ستتم وراثة الإعدادات REQUEST_METHOD و SCRIPT_FILENAME في مقطع لموقع ثانٍ، بالإضافة لتوفير الإعداد QUERY_STRING ضمن ذلك السياق المحدّد.

لكن ما يحدث في الحقيقة هو أنّ كل قيم fastcgi_param التابعة للأب ستُمحى ضمن السياق الثاني، وسيضبط الإعداد QUERY_STRING فقط. بينما ستبقى الإعدادات REQUEST_METHOD و SCRIPT_FILE دون ضبط.

ملاحظة حول القيم المتعدّدة للوسطاء ضمن نفس السياق

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

# server context

location ~ \.php$ {
   fastcgi_param REQUEST_METHOD $request_method;
   fastcgi_param SCRIPT_FILENAME $request_uri;

   fastcgi_param DOCUMENT_ROOT initial;
   fastcgi_param DOCUMENT_ROOT override;

   fastcgi_param TEST one;
   fastcgi_param TEST two;
   fastcgi_param TEST three;

   fastcgi_pass 127.0.0.1:9000;
}

. . .

في المثال السابق، قمنا بضبط الإعدادات TEST و DOCUMENT_ROOT عدّة مرات ضمن سياقٍ واحد. باعتبار أن fastcgi_param مصفوفة تعليمات فإن كلّ تصريح لاحق سيُضاف إلى سجلات Nginx الداخلية. سيحظى الإعداد TEST بعدة تصاريح ضمن المصفوفة يضبط من خلالها بالقيم one و two و three.

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

فمثلًا، إن استقبلت PHP-FPM الإعدادات السابقة فستفسر القيم النهائية لتحل محل أي قيم سابقة. بهذه الحالة سيُضبط الإعداد TEST بالقيمة three. وبالمثل سيضبط الإعداد DOCUMENT_ROOT بالقيمة override.

ولكن إن مُرّرت القيم السابقة لخادومٍ مثل FsgiWrap، فستفسَّر القيم بشكل مختلف كثيرًا. ففي البداية سيقوم بتمرير تمهيدي ليقرر أي القيم ينبغي استخدامها لتشغيل البريمج script. وسيستخدم القيمة initial للإعداد DOCUMENT_ROOT ليبحث عن البريمج. إلا أنه عندما سيمرّر القيم الفعلية للبريمج فسيمرر القيم الأخيرة كما يفعل PHP-FPM تمامًا.

إن التضارب inconsistency وعدم إمكانية التنبؤ unpredictability يعني أنك لا تستطيع، بل أنه لا ينبغي لك، أن تعتمد على الخادوم الخلفي لتفسير نيّتك بشكل صحيح إذا ما ضبطّت الإعدادات أكثر من مرّة واحدة. فالطريقة الوحيدة الآمنة هي بالتصريح عن كل إعداد مرّةً واحدة. يعني ذلك أيضًا أنه لا يوجد طريقة آمنة لإعادة تعريف overriding القيمة الافتراضية باستخدام تعليمة fastcgi_param.

طريقة تضمين إعدادات مكتوبة بملف منفصل ضمن ملف إعدادات FastCGI الأساسي

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

يعني ذلك أنه بإمكاننا الاحتفاظ بكل الإعدادات الشائعة في ملف واحد ومن ثمّ تضمينه في أي مكان ضمن إعداداتنا إن اقتضى الأمر. وباعتبار أن Nginx سيضع محتوى الملف حيثما وجدت تعليمة include فلن نكون قد ورثنا من سياق الأم إلى سياق الابن. سيمنع ذلك قيم fastcgi_param من أن تُمحى وسيمنحنا القدرة على ضبط إعدادات إضافية عند الحاجة.

يمكننا في البداية أن نضبط قيم إعدادات FastCGI الشائعة لدينا في ملف منفصل وتخزينه ضمن المسار الحاوي على ملف الإعدادات الأصلي، سنقوم بتسمية ذلك الملف fastcgi_common:

fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

يمكننا الآن أن نستورد محتوى الملف حيثما نريد استخدام قيم تلك الإعدادات:

# server context
root /var/www/html;

location /scripts {
   include fastcgi_common;

   fastcgi_index index.php;
   fastcgi_pass unix:/var/run/php5-fpm.sock;
}

location ~ \.php$ {
   include fastcgi_common;
   fastcgi_param QUERY_STRING $query_string;
   fastcgi_param CONTENT_TYPE $content_type;
   fastcgi_param CONTENT_LENGTH $content_length;

   fastcgi_index index.php;
   fastcgi_pass 127.0.0.1:9000;
}

. . .

لقد قمنا هنا بنقل قيم بعض الإعدادات الشائعة إلى ملف اسمه fastcgi_common والموجود في المسار الافتراضي الحاوي على إعدادات NGINX. ثمّ نستورد القيم المصرّح عنها في الملف عندما نحتاج لإدخالها. هنالك العديد من الأمور التي يجب ملاحظتها حول هذه الإعدادات:

أولًا، لم نضع في الملف الذي ننوي استيراده أي قيم قد نرغب بتخصيصها وفقًا لموقعه، بسبب مشكلة التفسير التي ذكرناها سابقًا والتي تحدث عندما نضبط عدة قيم لنفس الإعداد، ولأنه لا يمكن ضبط التعليمات التي ليست على شكل مصفوفة non-array directives إلا مرّةً واحدة خلال السياق، لذا نضع العناصر التي لن نرغب بتغييرها فقط في الملف المشترك. إنّ كلّ تعليمة (أو إعداد أساسي) قد نرغب بتخصيصه وفقًا لموقعه يجب ألا يضمّن في الملف المشترك.

الأمر الآخر الذي ربما قد لاحظته أننا قد ضبطنا بعض إعدادات FastCGI الإضافية في المقطع البرمجي للموقع الثاني. وتلك هي الإمكانية التي كنا نأمل الوصول إليها. تمكّنا من إضافة إعدادات fastcgi_param إضافية كلما اقتضت الحاجة ومن دون أن تُمسح القيم المشتركة.

استخدام الملف fastcgi_params أو الملف fastcgi.conf

بأخذ الاستراتيجية السابقة بالحسبان فإن مطوري Nginx والعديد من فرق تحزيم التوزيعات distribution packaging teams قد عملوا على توفير مجموعة من الإعدادات شائعة الاستخدام والتي يمكن أن تضمنها في مواقع تمرير FastCGI أي FastCGI pass location. تدعى تلك الإعدادات fastcgi_params أو fastcgi.conf.

إنّ هذين الملفين متشابهين كثيرًا ولكن مع وجود اختلاف وحيد ممثّل في تمرير قيم متعدّدة لإعداد واحد، وهي المشكلة التي ناقشناها سابقًا، لا يحتوي fastcgi_params على تصريح عن الإعداد SCRIPT_FILENAME على عكس الملف fastcgi.conf.

لقد أوجِد الملف fastcgi_params منذ وقتٍ أبعد. ثم ظهرت الحاجة لإنشاء ملف جديد عندما اتُّخذ قرارٌ لتوفير قيمةٍ افتراضية للإعداد SCRIPT_FILENAME وذلك حتى نتجنب تجزئة الإعدادات التي تعتمد على fastcgi_params، إن عدم فعل ذلك قد يؤدي إلى ضبط ذلك الإعداد في كل من الملف المشترك وموقع تمرير FastCGI.

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

إن كان كلا الملفين متوفرين لك، فقد يكون من الأفضل أن تضمّن الملف fastcgi.conf في معظم مواقع تمرير FastCGI، وذلك لأنه يتضمّن تصريحًا عن الإعداد SCRIPT_FILENAME. عادةً ما يُرغب بذلك إلا أنّ هنالك بعض الحالات التي قد ترغب فيها بتخصص هذه القيمة.

يمكن تضمين هذين الملفين عبر الإشارة إلى موقعهما بالنسبة إلى المجلد الجذر root الحاوي على إعدادات Nginx. إن مسار المجلد الجذر لإعداداتNginx يكون مشابهًا لما يلي: etc/nginx/ وذلك إن تم تثبيته باستخدام مدير الحزم package manager.

يمكنك تضمين الملفين كما يلي:

# server context

location ~ \.php$ {
   include fastcgi_params;
   # You would use "fastcgi_param SCRIPT_FILENAME . . ." here afterwards
   . . .
}

أو كما يلي:

# server context

location ~ \.php$ {
   include fastcgi.conf;
   . . .
}

تعليمات وإعدادات ومتغيرات FastCGI المهمّة

لقد قمنا في القسم السابق بضبط عدد لا بأس به من الإعدادات بهدف شرح مفاهيمٍ أخرى، وعادةً ما كنا نضبطها بمتغيرات Nginx. كما أننا قدمنا بعض تعليمات FastCGI من دون شرحٍ وفير. سنناقش في هذا القسم بعض التعليمات شائعة الضبط، وبعض الإعدادات التي قد تحتاج لتعديلها، بالإضافة لبعض المتغيرات التي قد تحوي معلوماتٍ تحتاجها.

تعليمات FastCGI الشائعة:

سنستعرض فيما يلي بعض أكثر التعليمات المفيدة للعمل مع تمريرات FastCGI:

• fastcgi_pass: هي التعليمة التي تقوم بعملية تمرير الطلبات الموجودة ضمن السياق الحالي إلى الخادوم الخلفي. تعرٍّف هذه التعليمة الموقع الذي يمكن الوصول عبره إلى معالج FastCGI.
• fastcgi_param: وهي مصفوفة التعليمات التي يمكن استخدامها لضبط قيم الإعدادات. غالبًا ما يقترن استخدام هذه التعليمة مع متغيرات Nginx لضبط وسطاء FastCGI بالقيم المحدّدة في الطلب.
• try_files: ليست تعليمةً خاصة بـ FastCGI، إلا أنها استخدامها شائع في موقع تمرير FastCGI، عادةً ما تستخدم كجزء من إجراء الطلب الوقائي للتأكد من وجود الملف المطلوب قبل تمريره إلى معالج FastCGI.
• include: مجدّدًا، ليست تعليمةً خاصة بـ FastCGI، إلا أنها تستخدم بكثافة عالية في سياقات تمرير FastCGI أي FastCGI pass contexts. غالبًا ما تستخدم لتضمين تفاصيل الإعدادات الشائعة والمشتركة بين عدّة مواقع.
• fastcgi_split_path_info: تستخدم هذه التعليمة لتعريف التعابير النمطية regular expression مع مجموعتي التقاط captured groups. تُستخدم المجموعة الأولى كقيمة للمتغير fastcgi_script_name$ بينما تستخدم المجموعة الثانية كقيمة للمتغير fastcgi_path_info$. عادةً ما تستخدم كلا المجموعتين لتحليل parse الطلب بشكل صحيح حتى يعرف المعالج أي الأجزاء المشكّلة للطلب تمثل الملفات الواجب تشغيلها وأي الأجزاء تمثل المعلومات الإضافية الواجب تمريرها إلى السكربت.
• fastcgi_index: تعرّف هذه التعليمة ملف الفهرسة index file الذي ينبغي الحاقه بقيمة الإعداد fastcgi_script_name$ والتي تنتهي بـ (/.عادةً ما يكون ذلك مفيدًا إن كان الإعداد SCRIPT_FILENAME مضبوطًا بقيمة document_root$fastcgi_script_name$ وكان مقطع الموقع معدّا لقبول الطلبات الحاوية على معلومات المسار الإضافية.
• fastcgi_intercept_errors: تعرّف هذه التعليمة فيما إذا كان ينبغي معالجة الأخطاء المتلقاة من خادوم FastCGI أو تمريرها مباشرةً إلى المستخدم.

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

المتغيرات شائعة الاستخدام مع FastCGI:

قبل أن نتمكن من الكلام عن الإعدادات التي ستستخدمها على الأرجح مع تمريرات FastCGI، علينا الكلام قليلًا عن بعض نتغيرات Nginx الشائعة والتي ستستفيد منها في ضبط تلك الإعدادات. تعرّف وحدة FastCGI الخاصة بـ Nginx بـ Nginx’s FastCGI module بعض تلك المتغيرات، إلا أن معظمها من الوحدة الأساسية Core module.

• query_string$ أو args$: هي القيم الممرّرة arguments في الطلب الأصلي للمستخدم.

• is_args$: ستساوي قيمتها “?” إن حوى الطلب على قيم ممرّرة وإلا فستُضبط قيمتها بسلسلة نصية فارغة. يفيد ذلك عند إنشاء إعدادات قد تأخذ قيمًا أو لا تأخذ.

• request_method$: يشير هذا المتغير إلى نوع الطلب request method المستخدم الأصلي. يمكن أن يفيد ذلك بتحديد فيما إذا كان ينبغي السماح لعملية operation ما في السياق الحالي أم لا.

• content_type$: يضبط هذا المتغير بقيمة الحقل content-type الموجود في ترويسة الطلب. يحتاج الوسيط إلى هذه المعلومات إن كان نوع الطلب المستخدم هو POST وذلك حتى يتمكن من معالجة المحتويات اللاحقة بشكل صحيح.

• content_length$: يضبط هذا المتغير قيمة الحقل Content-Length الموجود في ترويسة المستخدم. هذه المعلومات لازمة لأي طلب للمستخدم من النوع POST.

• fastcgi_script_name$: يحتوي هذا المتغير على ملف السكربت الذي يجب تشغيله. إن انتهى الطلب بـ (/) فستحلق قيمة التعليمة fastcgi_index إلى النهاية. وبحال استخدام التعليمة fast_split_path_info فستضبط قيمة هذا المتحول بالمجموعة اللاقطة الأولى المعرّفة من قبل التعليمة. ينبغي على قيمة هذا المتغير أن تشير إلى الملف الفعلي الذي يجب تشغيله.

• request_filename$: يحتوي هذا المتغير على مسار الملف المطلوب. يحصل المتغير على هذه القيمة بأخذ المسار الحالي لمجلد المستندات الأساسي document root، مع أخذ كل من التعليمتين root و alias بعين الاعتبار. بالإضافة لأخذ قيمة المتغير fastcgi_script_name$. تعد هذه الطريقة مرنةً للغاية لإسناد قيمة للإعداد SCRIPT_FILENAME.

• request_uri$: يحتوي هذا المتغير على الطلب كاملًا كما استُقبل من المستخدم، يتضمّن ذلك السكربت، أية معلومات مسار إضافية، بالإضافة إلى أي عبارة استعلام query string.

• fastcgi_path_info$: يحتوي هذا المتغير على معلومات المسار الإضافية التي قد تتوفّر بعد اسم السكربت في الطلب. وقد تحوي قيمته أحيانًا على موقعٍ آخر ينبغي على السكربت أن يعلم به حتى يتم تنفيذه. يحصل هذا المتغير على قيمته من مجموعة التعابير النمطية regex الثانية عند استخدام تعليمة fastcgi_split_path_info.

• document_root$: يحتوي هذا المتغير على المسار الحالي لمجلد المستندات الأساسي. وسيتم ضبطه تبعًا لتعليمتي root و alias.

• uri$: يحتوي هذا المتغير على قيمة URI الحالية بعد تسويتها normalization. وبما أن تعليمات معينة تقوم بإعادة الكتابة rewrite أو بإعادة التوجيه الداخلي internallly redirect يمكن أن تترك أثرًا على معرّف URI فإن هذا المتغير سيستخلّص تلك التعديلات.

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

إعدادات FastCGI الشائعة:

تمثّل إعدادات FastCGI المعلومات التي نرغب بجعلها متاحةً لمعالج FastCGI - الذي نرسل إليه الطلبات- على شكل أزواج مفتاح-قيمة key-value. لن تحتاج كلّ التطبيقات إلى نفس الإعدادات لذلك غالبًا ما ستحتاج لمراجعة توثيق التطبيق.

تُعد بعض تلك الإعدادات ضروريةً للمعالج حتى يتمكن من تحديد السكربت - الذي ينبغي تشغيله- بشكل صحيح. بينما أُتيح البعض الآخر للسكربت، إذ أنها قد تغيّر سلوكه إن كان معدًّا ليعتمد على مجموعةٍ من الإعدادات.

• QUERY_STRING: ينبغي أن يُضبط هذا الإعداد بأي عبارة استعلام مقدّمة من قِبل المستخدم. عادةً ما تكون على شكل أزواج مفتاح-قيمة مزوّدةً بعد إشارة "?"  في معرّف URI. عادةً ما يُضبط هذا الإعداد بقيمة أحد المتحولين query_string$ أو args$، إذ ينبغي عليهما أن يحويا على نفس البيانات.

• REQUEST_METHOD: يدّل هذا الإعداد معالجَ FastCGI على نوع الإجراء الذي طلبه المستخدم. وهو أحد الإعدادات القلائل التي يجب ضبطها حتى يتم التمرير بشكل صحيح.

• CONTENT_TYPE: إن ضُبط نوع الطلب في الإعداد السابق ليكون POST فيجب أن يُضبط هذا الإعداد. يشير هذا الإعداد إلى نوع البيانات التي ينبغي على معالج FastCGI توقعها. غالبًا ما يضبط هذا الإعداد بالمتغير content_type$ فقط، والذي يضبط بدوره وفقًا للمعلومات المأخودة من الطلب الأصلي.

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

• SCRIPT_NAME: يستخدم هذا الإعداد ليُشير إلى اسم السركبت الأساسي الذي يجب تشغيله. وهو إعداد هامٌ للغاية يمكن ضبطه بعدّة طرق وفقًا لاحتياجاتك. عادةً ما يُضبط بالمتغير fastcgi_script_name$ والذي يجب أن يكون معرّف URI للطلب، أو معرف URI للطلب متبوعًا بـ fastcgi_index إن انتهى المعرّف بـ (/)، أو المجموعة اللاقطة الأولى إن استُخدم fastcgi_fix_path_info.

• SCRIPT_FILENAME: يحدّد هذا الإعداد الموقع الفعلي على القرص للسكربت الذي يجب تشغيله. وبسبب ارتباطه مع الإعداد SCRIPT_NAME، تقترح بعض أدلة الاستخدام Guides أن تستعيض عن استخدامه بالمتغيرين document_root$fastcgi_script_name$. يتوفر بديلٌ آخر يملك العديد من المحاسن وهو استخدام request_filename$.

• REQUEST_URI: ينبغي أن تحوي على معرّف URI للطلب كاملًا ومن من دون تعديل، بالإضافة إلى السكربت الذي يجب تشغيله، ومعلومات المسار الإضافية، وأي قيمٍ ممرّرة. تفضّل بعض التطبيقات أن تحلّل تلك المعلومات بنفسها، ويقدم هذا الإعداد المعلومات اللازمة لهم للقيام بذلك.

• PATH_INFO: إن ضُبط cgi.fix_pathinfo بالقيمة “1” في ملف إعدادات PHP، فسيحوي هذا الإعداد على أية معلومات مسار إضافية additional path information مذكورة بعد اسم السكربت. عادةً ما يُستخدم هذا الإعداد لتعريف الملف الممرّر file argument والذي سيحدّد تصرُّف السكربت. قد يترتّب على ضبط cgi.fix_pathinfo بالقيمة "1" آثارٌ أمنية إن لم تكن طلبات السكربت قد فُحصت بوسائل أخرى (سنناقش ذلك لاحقًا). قد يُضبط هذا الإعداد أحيانًا بالمتغير fastcgi_path_info$ والذي يحوي على المجموعة اللاقطة لثانية من التعليمة fastcgi_split_path_info. وفي حالاتٍ أخرى، سيكون هنالك حاجةٌ لاستخدام متغير مؤقت، إذ أنه يمكن لمعالجةٍ أخرى أن تمسح تلك القيمة أحيانًا.

• PATH_TRANSLATED: يربط هذا الإعداد بين معلومات المسار المحتواة ضمن PATH_INFO والمسار الفعلي على نظام الملفات filesysem path. عادةً ما يُضبط هذا الإعداد بـ document_root$fastcgi_path_info$، ولكن أحيانًا يجب استبدال المتغير الأخير بالمتغير المؤقت الذي أشرنا إليه سابقًا.

التحقق من الطلبات قبل تمريرها إلى FastCGI    

إنّ أحد المواضيع بالغة الأهمية التي لم نغطها حتى الآن هو كيفية تمرير الطلبات الديناميكية للخادوم بشكلٍ آمن. إن تمرير كلّ الطلبات للخادوم الخلفي بغض النظر عن صحتها لا يسبب خفض فاعلية الخادوم فحسب، بل إنه خَطِرٌ أيضًا. إذ أنه من الممكن للمهاجمين إنشاء طلباتٍ خبيثة في محاولةٍ منهم لتشغيل نص برمجي ما. في الواقع، حتى نعالج هذا الخطأ علينا أن نضمن إرسال الطلبات الصالحة فقط لمعالج FastCGI، يمكننا القيام بذلك بعدة طرق وذلك تبعًا لاحتياجات إعدادنا الخاص وفيما إن كان معالج FastCGI يعمل على نفس النظام المشغِّل لـ Nginx أم لا.  

إحدى القواعد الأساسية التي يجب أن تحدد لنا كيفية ضبط الإعدادات، هي أنه علينا ألا نسمح بأي معالجة أو تفسير لملفات المستخدم. إذ أنه من السهل نسبيًا على المستخدمين المخادعين malicious users أن يضمّنوا نصًا برمجيًا صالحًا valid code في ملفاتٍ تبدو في الظاهر أنها ملفاتٍ غيرُ مؤذيةٍ كالصور. حالما يُرفع ملفٌ كهذا إلى الخادوم علينا أن نضمن ألا يجد طريقًا للوصول إلى معالج FastCGI.

إنّ المشكلة الأساسية التي نحاول حلها هنا هي في الواقع محدّدةٌ في مواصفات CGI specification. تتيح لك تلك المواصفات تحديد ملف السكربت الذي ترغب بتشغيله متبوعًا بمعلومات المسار الإضافية التي يمكن للسكربت أن يستخدمها. إن نموذج التنفيذ هذا يسمح للمستخدمين بطلب معرف URI قد يبدو كسكربت صالح legitimate، إلا أن الجزء الذي سيتم تنفيذه سيكون مذكورًا قبله في المسار.

فالنأخذ مثلًا طلبًا لـ: test.jpg/index.php/ إن كانت إعداداتك تمرّر ببساطة كل الطلبات التي تنتهي بـ .php إلى المعالج دون التحقق من مدى صحتها فسيتحقق المعالج، إن كان يحقّق المواصفات، من وجود ذلك الموقع وسينفذّه إن أمكن. أما إذا لم يجد الملف فسيتّبع المواصفات وسيحاول تنفيذ الملف test.jpg/ وسيعتبر أن index.php/ تمثّل معلومات المسار الإضافية الخاصة بالسكربت. كما ترى يمكن لذلك أن يسمح ببعض النتائج غير المرغوب بها إطلاقًا عندما يجتمع مع فكرة رفع المستخدم للملفات.

هنالك مجموعة من الطرق المختلفة لحل تلك المشكلة. أسهل تلك الطرق هو ببساطة تعطيل خاصية معالجة معلومات المسار من قِبَل المعالج، وذلك إن كان تطبيقك لا يعتمد على تلك المعلومات الإضافية. يمكن تعطيل تلك الخاصية لدى PHP-FPM من خلال الملف php.ini، فمثلًا إن كنت تستخدم نظام أوبونتو Ubuntu فيمكن تحرير الملف التالي:

sudo nano /etc/php5/fpm/php.ini

ببساطة، ابحث عن الخيار cgi.fix_pathinfo وألغِ تعليقه ثم اضبطه بالقيمة “0” لتعطّل هذه “الميزة” كما يلي:

cgi.fix_pathinfo=0

أعد تشغيل عملية PHP-FPM حتى تأخذ التعديلات حيّز التنفيذ:

sudo service php5-fpm restart

سيدفع ذلك PHP لتنفيذ الجزء الأخير من المسار فقط، وبالتالي ففي المثال السابق إن لم يكن الملف test.jpg/index.php/ موجودًا فسيصدر PHP خطأ عوضًا عن محاولة تنفيذ الملف test.jpg/ إذا كان معالج FastCGI يعمل على نفس الخادوم الذي يُشغل Nginx فلدينا خيارٌ آخر وهو ببساطةٍ التحقق من وجود الملفات على القرص قبل تمريرها إلى المعالج. فإذا لم يكن الملف التالي موجودًا test.jpg/index.php/ فسيصدر خطأ. أما إن كان موجودًا فسيُرسل إلى الخادوم الخلفي لتتم معالجته. سينتج عن ذلك عمليًا سلوكٌ يشبه إلى حد بعيد ما رأيناه سابقًا.

location ~ \.php$ {
       try_files $uri =404;
       . . .
}

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

location ^~ /uploads {

}

بإمكاننا إضافة أي نوع من معالجة ملفات PHP داخل المقطع البرمجي:

location ^~ /uploads {
   location ~* \.php$ { return 403; }
}

سيعمل الموقع الأم parent location على مطابقة أي طلب يبدأ بـ uploads/ وأيُّ طلب يتعامل مع ملفات PHP سيُرد عليه بالخطأ 403 عوضًا عن إرساله إلى الخادوم الخلفي.

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

فمثلًا، بإمكاننا إعداد مقطع لموقع يقوم باعتبار أن أول جزء مكون للمسار ينتهي ب .php هو السكربت الذي ينبغي تشغيله. ويعتبر الباقي معلومات المسار الإضافية. وذلك يعني أنه من أجل الطلب: test.jpg/index.php/ فسيتم إرسال كامل المسار إلى المعالج باعتباره اسم السكربت ولا يحوي معلومات مسار إضافية.

يمكن أن يكون الموقع كالآتي:

location ~ [^/]\.php(/|$) {

   fastcgi_split_path_info ^(.+?\.php)(.*)$;
   set $orig_path $fastcgi_path_info;

   try_files $fastcgi_script_name =404;

   fastcgi_pass unix:/var/run/php5-fpm.sock;
   fastcgi_index index.php;
   include fastcgi_params;

   fastcgi_param SCRIPT_FILENAME $request_filename;
   fastcgi_param PATH_INFO $orig_path;
   fastcgi_param PATH_TRANSLATED $document_root$orig_path;
}

ينبغي أن يعمل المقطع السابق عندما تكون قيمة cgi.fix_pathinfo في إعداد PHP مضبوطةً بالقيمة "1" حتى تسمح بمعلومات المسار الإضافية. وهنا، إن مقطع الموقع السابق لا يطابق الطلبات التي تنتهي بـ .php وحسب، بل تلك التي تنتهي بـ .php قبل إشارة "/" مباشرةً والتي تدل على مكون إضافي يتبع مسار المجلد directory.

تعرّف التعليمة fastcgi_split_path_info داخل المقطع مجموعتين لاقطتين captured group باستخدام التعابير النمطية. تطابق المجموعة الأولى الجزء الممتد من بداية عنوان URI وحتى أول ورود لـ .php ويضعه في المتغير fastcgi_script_name$. ومن ثم يضع أي معلومة مذكورة في الجزء الباقي، والممتد بدءًا من النقطة التي انتهى عندها الجزء الأول وحتى نهاية العنوان، في المجموعة اللاقطة الثانية والتي تخزّن في متغير يدعى fastcgi_path_info$.

نستخدم التعليمة set لنخزن القيمة المحفوظة في fastcgi_path_info$، حتى هذه النقطة، في متغير يدعى orig_path$. وذلك لأن قيمة المتغير fastcgi_path_info$ ستُمحى في لحظة عبر التعليمة try_files.

بإمكاننا التحقق من اسم السكربت الذي التقطناه سابقًا باستخدام التعليمة try_files. وهي عبارة عن عملية تطبّق على ملف file operation تتأكد من أنّ السكربت الذي نحاول تشغيله مخزن على القرص. ولكن لذلك تأثيرًا جانبيًا يتمثل في مسح قيمة المتحول fastcgi_path_info$.

بعد القيام بالتمرير التقليدي عبر FastCGI فإننا نضبط SCRIPT_FILENAME كما العادة. نضبط أيضًا الإعداد PATH_INFO بالقيمة التي المخزّنة في المتغير orig_path$. فبالرغم من أن قيمة fastcgi_path_info$ قد مُسحت، إلا أن قيمته الأصلية محفوظة في ذلك المتغير. كما أننا نضبط الوسيط PATH_TRANSLATED ليربط map بين معلومات المسار الإضافية والموقع الذي تُحفظ فيه على القرص، نقوم بذلك عبر دمج قيمتي المتغيرين document_root$ و orig_path$.

يسمح لنا ذلك ببناء طلباتٍ مثل: index.php/users/view/ بحيث يتمكن الملف: index.php/ من معالجة المعلومات المتعلقة بالمجلد: users/view/ وبنفس الوقت نتجنب المواقف التي سيُشغّل بها الطلب: test.jpg/index.php/ سيُضبط البريمج دائمًا بأقصر مكوّن ينتهي بـ .php، وبالتالي سنتجنب تلك المشكلة.

يمكننا أيضًا تحقيق ذلك باستخدام تعليمة alias إن احتجنا إلى تغيير موقع ملفات السكربتات. علينا فقط أن نأخذ ذلك بالحسبان في كل من ترويسة الموقع وتعريف fastcgi_split_path_info.

location ~ /test/.+[^/]\.php(/|$) {

   alias /var/www/html;

   fastcgi_split_path_info ^/test(.+?\.php)(.*)$;
   set $orig_path $fastcgi_path_info;

   try_files $fastcgi_script_name =404;

   fastcgi_pass unix:/var/run/php5-fpm.sock;
   fastcgi_index index.php;
   include fastcgi_params;

   fastcgi_param SCRIPT_FILENAME $request_filename;
   fastcgi_param PATH_INFO $orig_path;
   fastcgi_param PATH_TRANSLATED $document_root$orig_path;
}

سوف يسمح لك ذلك لتشغيل تطبيقاتك التي تستخدم الإعداد PATH_INFO بأمان. تذكّر أنه عليك تعديل الخيار cgi.fix_pathinfo في ملف php.ini وضبطه بالقيمة "1" حتى يعمل بشكل صحيح. قد يترتب عليك أيضًا أن تعطّل security.limit_extensions في الملف php-fpm.conf.

الخلاصة

نأمل أنك تملك الآن فهمًا أفضل لإمكانية قيام FastCGI بالوساطة عنNginx. تسمح هذه الإمكانية لـ Nginx باستخدام قوته في معالجة الاتصالات بسرعة وتحضير المحتوى الثابت static content، بينما تُحمّل مسؤولية المحتوى الديناميكي dynamic content لبرمجيات مناسبة لذلك. يسمح FastCGI لـ Nginx بالعمل مع عدد كبير من التطبيقات، عبر إعدادات آمنة وذات أداء.

ترجمة – وبتصرّف– للمقال Understanding and Implementing FastCGI Proxying in Nginx لمؤلفه Justin Ellingwood.