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

الواجهات

الواجهات هي نقاط الاتّصال بالنّسبة لحاسوبك. تُربَط كلّ واجهة بجهاز طرفيّ ملموس أو افتراضيّ.

توجد عادةً واجهة شبكة قابلة للإعداد لكلّ بطاقة Ethernet أو بطاقة شبكة لا سلكيّة على الخادوم. تُعرَّف واجهة شبكة افتراضيّة تُسمّى loopback (الاسترجاع) أو localhost (المستضيف المحلّي) لكلّ بطاقة شبكة. تُستخدَم هذه الواجهة لتوصيل العمليّات أو التّطبيقات العاملة على نفس الجهاز في ما بينها. تظهر هذه الواجهة في العديد من الأدوات باسم lo.

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

على سبيل المثال، يضبُط مزّودو الخدمات السّحابيّة Cloud services الخواديم الخاصّة الافتراضيّة Virtual private server, VPS للعمل بواجهتيْ شبكة (إضافة إلى الواجهة المحليّة lo): الأولى باسم eth0 مضبوطة لمعالجة البيانات القادمة من الإنترنت، والثّانيّة eth1 للاتّصال بالشّبكة الخاصّة بمزوّد الخدمة.

البروتوكولات

يعمل ربط الشّبكات عن طريق تركيب مجموعة من البروتوكولات فوق بعضها. بهذه الطّريقة يُمكن إرسال قطعة بيانات باستخدام بروتوكولات مختلفة يغلّف كلٌّ منها الآخر.

سنعرض لبعض البروتوكولات شائعة الاستخدام مع محاولة شرح الفروق في ما بينها إضافةً إلى السّيّاق والمستوى الّذي تتدخّل فيه.

نبدأ بالبروتوكولات الّتي تعمل في الطّبقات الدّنيا من الشّبكة ونصعد إلى البروتوكولات الأكثر تجريدًا (الطّبقات العليا).

1- التّحكّم في الوصول إلى الوسائط Media Access Control, MAC

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

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

2- بروتوكول الإنترنت Internet protocol, IP

وهو أحد البروتوكولات الأساسيّة الّتي تعمل عليها شبكة الإنترنت. يعمل بروتوكول الإنترنت مع عناوين IP، وهي فريدة في كلّ شبكة، ممّا يسمح للأجهزة بالتّواصل في ما بينها عبر الشّبكة. يُنفَّذ ابروتكول الإنترنت على مستوى طبقة التّوصيل ضمن نموذج TCP/IP.

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

يُنفَّذ ابرتوكول IP عمليًّا بصيّغ عديدة أشهرها اليوم هو الإصدار الرّابع من البروتوكول IPv4، إلاّ أنّ الإصدار السّادس IPv6 يزداد شعبيةً يومًا بعد يوم نظرًا للشّح المتزايد في عناوين الإصدار الرابع المتوفّرة، والتّحسينات المُضافة إلى إمكانيّات البروتوكول.

3- بروتوكول رسائل التّحكّم في الإنترنت Internet control message protocol, ICMP

يُستخدَم لإرسال رسائل بين الأجهزة الطّرفيّة للإشعار بحالتها من حيث التّوفّر ووجود أخطاء وطبيعتها. تُستخدَم حزم ICMP في أدوات تشخيص الشّبكة مثل traceroute وping.

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

4- بروتوكول التّحكّم في الإرسال Transmission control protocol, TCP

يُؤسّس بروتوكول TCP لاتّصالات موثوقة ويعمل في طبقة النّقل من نموذج TCP/IP.

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

يُنشئ بروتوكول TCP، قبل البدء بنقل البيانات، اتّصالًا عبر آليّة تُعرَف بالمصافحة الثّلاثية Three-way handshake. تمكّن هذه الآلية طرفيْ الاتّصال من الإقرار باستلام الطّلبات والاتّفاق على طريقة لضمان موثوقيّة البيانات. بعد اكتمال نقل البيانات يُنهى الاتّصال عبر آليّة مشابهة تُدعَى المصافحة الرّباعيّة.

تعتمد الكثير من استخدامات الإنترنت على بروتوكول TCP. نذكر منها الويب WWW، نقل الملفّات عبر FTP، والبريد الإلكتروني. يُمكن القول دون كثير من المجازفة أنّ الإنترنت الّتي نعرفها اليوم لم تكن لتوجد لولا ابروتوكول TCP.

5- بروتوكول مخطَّط بيانات المستخدِم User datagram protocol, UDP

يعمل مثل TCP في طبقة النّقل. الفرق الأساسيّ بين الاثنين أنّ UDP ،على العكس من TCP، لا يضمن موثوقيّة النّقل؛ فلا يتأكّد من استلام الطّرف الآخر في الاتّصال للبيانات. قد يبدو من الوهلة الأولى ألّا فائدة من بروتوكول UDP، فهو لا يوفّر آليّة لضمان الموثوقيّة؛ إلّا أنّه مهمّ جدًّا لتأديّة بعض الوظائف.

بروتوكول UDP أسرع بكثير من TCP، فهو لا يحتاج للانتظار للتّأكّد من استلام حزمة البيانات، وإعادة إرسالها في حال عدم الاستلام. كما أنّه لا يؤسّس لاتّصال مع وِجهة البيانات بل يكتفي بإلقائها إليه ولا يهتمّ هل يقبلها أم لا. تُفيد سهولة المعاملة الّتي يعرّفها UDP في التّواصل غير المعقَّد مثل طلب موارد على الشّبكة. لا يحتفظ ابروتوكول بمعلومات عن حالة الاتّصال ممّا يجعل منه خيّارًا مناسبًا لإرسال البيانات من جهاز واحد إلى عملاء عديدين في الوقت الحقيقي Real time clients. تجعل هذه الميزات من UDP الخيّار الأمثل لبرامج VoIP (الصّوت عبر ابروتوكول الإنترنت، Voice over IP)، الألعاب، والتّطبيقات الأخرى الّتي لا تحتمل الانتظار.

6- بروتوكول نقل النّصوص التّشعبيّة Hypertext transfer protocol, HTTP

يعرَّف هذا البروتوكول على مستوى طبقة التّطبيق، ويكوّن الأساس للتّواصل عبر الويب. يعرّف HTTP دوالّ مختلفة لإخبار النّظام البعيد مالّذي يطلُبه المستخدِم. نذكر منها على سبيل المثال POST، GET و DELETE الّتي تتعامل كلّها مع البيانات المطلوبة ولكنّ بطُرق مختلفة.

7- بروتوكول نقل الملفّات File transfer protocol

يعمل على مستوى طبقة التّطبيق، ويوفّر طريقة لنقل ملفّات كاملة من مستضيف إلى آخر. يجب الانتباه إلى أنّ بروتوكول FTP غير آمن ويجب ألّا يُستخدَم في أي شبكة معروضة للعموم إلّا إذا كان على خادوم لا يقبل سوى تنزيل الملفّات.

8- نظام أسماء النّطاقات Domain name system, DNS

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

9- بروتوكول الصّدفة الآمنة Secure Shell, SSH

يعمل بروتوكول SSH على مستوى طبقة التّطبيق ويُستخدَم للتّواصل مع خادوم بعيد بطريقة آمنة تُعمّي Encrypt البيانات. تعتمد تقنيّات عديدة على SSH نظرًا لتوفّره على التّعميّة من طرف إلى طرف End-to-end وشيوع استخدامه.

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

خاتمة

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

ترجمة بتصرّف لمقال An Introduction to Networking Terminology, Interfaces, and Protocols.

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

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

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

مصطلحات الشّبكات

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

• اتّصال Connection: يُحيل الاتّصال، ضمن مجال الشّبكات، إلى أجزاء مترابطة من المعلومات تُنقَل عبر الشّبكة. يُستنتج من ذلك أنّ الاتّصال عمومًا يُنشَأ قبل الشّروع في نقل البيانات (باتّباع إجراءات مُعرَّفة في ابروتوكول)، ثمّ يُفكَّك - أي الاتّصال - بعد الانتهاء من نقل البيانات.

• حزمة Packet: وهي الوحدة الصّغرى المنقولة عبر الشّبكة. تغلّف الحزمُ قطعَ البيانات لنقلها من طرف إلى آخر أثناء التّواصل عبر الشّبكة.

لدى الحزمة ترويسة Header تحوي معلومات عن الحزمة؛ منها: المصدَر والوِجهة، الختم الزّمنيّ Timestamp، القفزات Hops (أجزاء المسار بين المصدَر والوِجهة)،… إلخ. بينما يحوي الجزء الأكبر من الحزمة البيانات الفعلية المنقولة، ويُسمَّى أحيانًا بالمتن Body أو الحمولة Payload.

• واجهة شبكة Network interface: يُمكن أن تُحيل واجهة شبكة إلى أيّ نوع من الرّبط بين البرمجيّات Software والعتاد Hardware. على سبيل المثال، إذا كانت لدى الخادوم بطاقتا شبكة، فيُمكن التّحكّم في كلّ واحدة منهما وإعدادها بشكل مستقلّ عن طريق إعداد الواجهة المرتبطة بها.

يُمكن أن تكون واجهة الشّبكة مرتبطة بجهاز طرفيّ Device ملموس، أو أن تكون تمثيلًا لواجهة افتراضيّة. الجهاز الطّرفي loopback (يُستخدم للتّخاطب بين البرامج الموجودة على نفس الجهاز) مثال على الواجهات الافتراضيّة.

• شبكة منطقة محليّة Local area network,LAN: يُطلَق عليها أحيانًا الشّبكة المحليّة. تُشير إلى شبكة - أو جزء من شبكة - لا يُتاح لعموم المستخدمين عبر الإنترنت الوصول إليها. الشّبكة الموجودة في المنزل أو المكتب مثال على الشّبكات المحليّة.

• شبكة واسعة Wide area network, WAN: وتعني شبكة أكثر اتّساعًا بكثير من شبكة محليّة. يُستخدَم مصطلح الشّبكة الواسعة أحيانًا للدّلالة على شبكة الإنترنت ككلّ، رغم أنّه يُشير في الأصل إلى الشّبكات الواسعة والمتفرّقة عمومًا.

إذا وُصِفت واجهة بأنّها متّصلة بشبكة واسعة (WAN) فالمقصود - عادةً - هو أنّها متّصلة بالإنترنت.

• ابروتوكول Protocol: البروتوكول هو مجموعة من القواعد والمعايير Standards الّتي تعرّف لغةً يُمكن للأجهزة الطّرفيّة استخدامُها للتّخاطب. تُستخدَم ابروتوكولات عديدة في ربط الشّبكات، وتُنفَّذ عادةً على هيئة طبقات مختلفة.

أمثلة على ابروتوكولات المستويات الدّنيا: IP، UDP ، TCP وICMP. الأمثلة التّاليّة هي لتطبيقات مبنيّة على طبقات من البروتكولات الأدنى مستوى: HTTP (للوصول إلى صفحات الويب)، TLS/SSL، SSH وFTP.

• منفذ Port: المنفذ هو عنوان ضمن الجهاز يُمكن ربطه ببرنامج محدّد. المنفذ ليس واجهة ملموسة أو موقِعًا، بل هو طريقة تجعل من الجهاز (الخادوم) قادرًا على التّواصل باستخدام أكثر من تطبيق.

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

• ترجمة عناوين الشّبكة Network address translation, NAT: وهي طريقة لإرسال الطّلبات القادمة إلى خادوم توجيه Routing إلى الأجهزة الطّرفيّة المُناسبة أو إلى الخواديم داخل الشّبكة المحليّة الّتي لديها معلومات عن وِجهة الطّلبات. تُستخدم ترجمة عناوين الشّبكة في الشّبكات المحليّة لتوجيه طلبات قادمة على نفس عنوان IP إلى الخواديم الخلفيّة المناسبة.

• الشّبكات الخاصّة الافتراضيّة Virtual private network, VPN: الشّبكات الخاصّة الافتراضيّة هي طريقة لتوصيل شبكات محليّة مختلفة عبر الإنترنت، مع الحفاظ على الخصوصيّة. تُستخدم هذه الطّريقة لتوصيل أنظمة متباعدة كما لو كانت في نفس الشّبكة المحليّة، لأسباب أمنيّة غالبًا.

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

طبقات الشّبكة

تُقدّم الشّبكات غالبًا وفق بنيتها الأفقيّة، بين المستضيفات Hosts؛ إلّا أنّ تنفيذ الشّبكة يتمّ وفقا لطبقات على مستوى حاسوب أو حواسيب عدّة.

يعني عملُ الشّبكات على طبقات وجودَ تقنيّات متعدّدة تُبنى كلّ واحدة منها فوق الأخرى من أجل أن يعمل التّواصل بطريقة سلِسة. تُجرِّد Abstract كلُّ طبقة البياناتِ الخامّ القادمة من الطّبقة الأدنى، تجرّدها أكثر وتجعل من التّعامل معها أسهل بالنّسبة للتّطبيقات والمستخدمين. يُساعد تنظيم الشّبكة على طبقات في تسهيل استخدام الطّبقات الدّنيا بطرُق جديدة دون بذل الجهد في تطوير ابروتوكولات وتطبيقات تتعامل مع صيّغ البيانات الموجودة في هذه الطّبقات.

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

تبدأ البيانات رحلَتها، عند إرسالها من الجهاز، من قمّة كومة Stack الطّبقات متّجهة إلى الطّبقات الدّنيا. يحدُث نقل البيانات بين الأجهزة فعليًّا في المستوى الأدنى. تُعيد البيانات بعد النّقل رحلتها عبر طبقات الجهاز المستقبِل ولكن في الاتّجاه المعاكس: من الطبقة الدّنيا إلى القمّة.

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

1- نموذج OSI

نموذج OSI (اختصار ل Open Systems Interconnect: شبكة وصل الأنظمة المفتوحة) هو أحد الطُّرُق الأولى لوصف الطّبقات المختلفة في الشّبكة.

يُعرّف نموذج OSI سبعَ طبقات هي:

• التّطبيق Application: وهي الطّبقة الّتي يتفاعل معها المستخدمون وتطبيقات المستخدمين. يكثُر استخدام مصطلحات مثل توفّر الموارد Availability of resources، شركاء للتّخاطب معهم، مزامنة البيانات Data synchronization لوصف الاتّصال على هذا المستوى.

• التّقديم Presentation: طبقة التّقديم هي المسؤولة عن تعيين الموارد وتعريف السّيّاق Context. تُستخدم لترجمة بيانات المستويات الأدنى إلى صيغة يُمكن للتّطبيقات التّعامل معها.

• الجلسة Session: وهي مُداوِل Handler الاتّصال: تُنشئ، تُحافظ على، وتنهي الاتّصال بين المُتخاطبَيْن بطريقة مستمرّة.

• النّقل Transport: مسؤوليّتها إحالة اتّصال موثوق للطّبقات الموجودة فوقها (التّطبيق، التّقديم، والجلسة). تعني موثوقيّةُ الاتّصال في هذا الإطار القدرةَ على التّحقّق من وصول كلّ جزء من البيانات سليمًا إلى الطّرف الآخر من الاتّصال.

يُمكن لهذه الطّبقة إعادة إرسال البيانات المفقودة أو المشوَّهة كما أنّ بإمكانها إبلاغ الأجهزة البعيدة بتسلّم البيانات القادمة منها.

• الشّبكة Network: تُستخدَم هذه الطّبقة لتوجيه البيانات بين مختلف العُقَد Nodes الموجودة في الشّبكة. تسخدم طبقة الشّبكة عنواين لمعرفة الجهاز الّذي ستُرسَل إليه البيانات. يُمكن لهذه الطّبقة أيضًا تقسيمُ الرّسائل ذات الحجم الكبير إلى قطع أصغر تُجمَّع على الطّرف الآخر من الاتّصال - بعد استلامه لها - لإنشاء الرّسالة الأصليّة.

• وصلة البيانات Data link: تُنفَّذ هذه الطّبقة بحيث تُنشئ وتُحافظ على وصلات موثوقة بين مختلف العُقد والأجهزة الموجودة في الشّبكة باستخدام اتّصالات ملموسة.

• الاتّصال الملموس Physical: وهي الطّبقة المسؤولة عن معالجة الأجهزة الطّرفية الفعليّة المُستخدَمة للاتّصال. تستدعِي هذه الطّبقةُ البرنامجَ الّذي يُدير الاتّصالات الملموسة والعتاد (مثل Ethernet).

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

2- نموذج TCP/IP

يشيع استخدام تعبير حزمة ابروتوكلات الإنترنت Internet protocol suite للحديث عن هذا النّموذج الأسهل والأكثر تبنيًّا. يُعرِّف نموذجُ TCP/IP أربع طبقات، يتداخل بعضٌ منها مع طبقات نموذج OSI:

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

يوصف الاتّصال بأنّه يحدُث بين النّظراء Peers.

• النّقل: وهي الطّبقة المسؤولة عن الاتّصال بين العمليّات Processes. يستخدِم هذا المستوى من الشّبكة المنافذَ لعنونة مختلف الخدمات. يُمكن لطبقة النّقل إنشاء اتّصالات موثوقة أو غير موثوقة حسب نوعيّة البروتوكول المستخدَم.

• التّوصيل Internet: مسؤوليّتها نقل البيانات من عقدة على الشّبكة إلى أخرى. تعرف هذه الطّبقة طرفيْ الاتّصال ولكنّها لا تهتمّ بالاتّصال الفعليّ المُستخدَم للانتقال من طرف إلى آخر. تُعرَّف عناوين IP على هذا المستوى بوصفها طريقة للوصول إلى الأنظمة البعيدة.

• الوصلة Link: تُنفّذ طبقة الوصلة مخطَّط الشّبكة المحليّة الّذي يسمح لطبقة التّوصيل بتقديم واجهة بعناوين. تنشئ هذه الطّبقة الاتّصالات بين العقد المتجاورة بهدف إرسال البيانات بينها

نموذج TCP/IP أكثر تجريدًا وسلاسة من سابقه؛ ممّا جعله أكثر سهولةً للتّنفيذ وبالتّالي الطريقة الأكثر انتشارًا لتقسيم الطّبقات في الشّبكات.

HAProxy (والذي يرمز إلى الوسيط عالي التوفّر High Availability Proxy) هو عبارة عن تطبيق موزانة حملٍ مفتوح المصدر لبروتوكول TCP/HTTP يُمكن أن يتم تشغيله على أنظمة لينكس، Solaris وFreeBSD. يتم استخدامه بشكلٍ شائع لتحسين أداء ومرونة بيئة خادوم الويب عبر توزيع الحمل على خواديم أخرى متعددة (كمثال: خادوم للويب، خادوم للتطبيق، خادوم لقاعدة البيانات..). يتم استخدام HAProxy في العديد من البيئات عالية التوفّر مثل: GitHub، Imgur, Instagram و Twitter.

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

مصطلحات HAProxy

هناك العديد من المصطلحات والمفاهيم التي من المهمّ فهمها عند الحديث عن موازنة الحمل واستخدام الوسيط (Proxying)، سنتحدّث عن أهمّ هذه المصطلحات في الأقسام الفرعيّة التالية.

قبل أن نبدأ بالحديث عن الأنواع الأساسية لموازنة الحمل، سنتحدّث عن قوائم تحكّم الوصول (ACLs – Access Control Lists)، الواجهات الخلفيّة (backends) والواجهات الأماميّة (frontends).

قائمة تحكّم الوصول (ACL)

في ارتباطٍ وثيق مع مبدأ موازنة الحمل، يتم استخدام قوائم تحكّم الوصول (Access Control List) لاختبار بعض الشروط وتنفيذ بعض الأوامر (كمثال: اختيار خادومٍ معيّن، حظر طلبٍ ما..) بناءً على نتيجة الاختبار. يسمح استخدام قوائم تحكّم الوصول بعمليةِ إعادة توجيهٍ مرنة لتدفّق الشبكة (network traffic) بناءً على عدّة عوامل مثل مطابقة النمط (pattern matching) وعدد الاتصالات المُرسلة إلى الواجهة الخلفيّة.

مثال على ACL:

acl url_blog path_beg /blog

تكون قائمة تحكّم الوصول السابقة متطابقة في حال كان المسار الذي يطلبه المستخدم مبدوءًا بـ blog/. هذا يعني أنّ مسارًا مثل http://yourdomain.com/blog/blog-entry-1 مثلًا كان ليكون متطابقًا مع القائمة في حال تطبيقها. لدليلٍ تفصيلي حول كيفية استخدام ACL، راجع دليل إعداد HAProxy.

الواجهة الخلفيّة Backend

الواجهة الخلفيّة هي عبارة عن مجموعة خواديم تتلقى الطلبات (requests) الموجّهة إليها. يتمّ تعريف الواجهات الخلفيّة في قسم backend في ملفّ إعدادات HAProxy. في شكلها الأكثر بساطةً يمكننا تعريف الواجهة الخلفيّة عبر:

• خوارزميات موازنة الحمل التي يجب استخدامها.
• قائمة من الخواديم والمنافذ (Ports).

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

إليك مثالًا على إعدادات واجهتين خلفيّتين، web-backend وblog-backend مع خادومين اثنين لكلّ واحدٍ منهما، يعملان على المنفذ 80:

backend web-backend
  balance roundrobin
  server web1 web1.yourdomain.com:80 check
  server web2 web2.yourdomain.com:80 check

backend blog-backend
  balance roundrobin
  mode http
  server blog1 blog1.yourdomain.com:80 check
  server blog1 blog1.yourdomain.com:80 check

• يقوم السطر balance roundrobin بتحديد خوارزميّة موازنة الحمل التي سيتم استعمالها، والتي سنتحدث عنها في قسمٍ لاحق.
• يحدد سطر mode http أنّه سيتم استخدام الطبقة 7 كوسيط، سنشرح هذا الأمر أيضًا في قسمٍ لاحق.
• يقوم الخيار check في نهاية السطور المبدوءة بـserver بإخبار النظام بوجوب التحقق من حالة خواديم الواجهة الخلفيّة هذه في كلّ مرّة.

الواجهة الأماميّة Frontend

تقوم بالواجهة الأماميّة بتعريف كيفية إعادة توجيه الطلبات إلى الواجهات الخلفيّة backends. يتم تعريف الواجهات الأماميّة في قسم frontend في ملفّ إعدادات HAProxy. تتكون تعريفاتها من المكونات التالية:

• مجموعة من عناوين الـIP والمنافذ (مثل: 10.1.1.7:80، *:443، إلخ..).
• قوائم تحكّم الوصول ACLs.
• قواعد use_backend، والتي تعرّف أيًّا من الواجهات الخلفيّة يجب استخدامها اعتمادًا على ما إذا كانت قوائم تحكّم الوصول متطابقة معها في كلّ مرّة أم لا، و/أو قاعدة default_backend والتي تقوم بمعالجة الحالات الأخرى.

يمكن إعداد واجهةٍ أمامية تبعًا لأنواعٍ مختلفة من تدفّقات الشبكة، وهو ما سنشرحه في القسم التالي.

أنواع موازنة الحمل

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

موازنة الحمل المعدومة No Load Balancing

يمكن لبيئة تطبيق ويبٍ بسيطة لا تستعمل أيًّا من طرق موازنة الحمل أن تبدو بالشكل التالي:

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

موازنة الحمل عن طريق الطبقة 4 (Layer 4 Load Balancing)

أبسط طريقة لموازنة الحمل في تدفّق الشبكة على خادومين اثنين هو استخدام موازنة الحمل عن طريق الطبقة رقم 4 (وهي طبقة شفافة transport layer). موازنة الحمل باستخدام هذه الطريقة ستسبب في توجيه تدفّق الزوار بناءً على مدى عنوان الـIP والمنفذ (كمثال، إذا جاء طلبٌ للمسار http://yourdomain.com/anything، فإنّه سيتم توجيه التدفّق إلى خادوم الواجهة الخلفيّة الذي يعالج الطلبات لـyourdomain.com بالمنفذ 80). 

إليكَ رسمًا توضيحيًا لموازنة الحمل باستخدام الطبقة 4:

يقوم المستخدم بالوصول إلى مُوازِن الحمل (load balancer) والذي يقوم بدوره بتوجيه طلبات المستخدم إلى مجموعة web-backend لخواديم الواجهة الخلفيّة. عندما يتم اختيار خادوم واجهةٍ خلفيّة معيّن فإنّه يستجيب مباشرةً إلى طلبات المستخدم. بشكلٍ عام، يجب على جميع الخواديم في مجموعة web-backend أن تحتوي على نفس المحتوى والبيانات، وإلّا فإنّ المستخدم قد يتصفّح محتوىً مختلفًا بالمرّة. لاحظ أيضًا أن كُلًا من الخادومين يتصلان إلى نفس خادوم قاعدة البيانات.

موازنة الحمل عن طريق الطبقة 7 - Layer 7 Load Balancing

طريقةٌ أخرى أكثر تعقيدًا لتوزيع تدفّق الحمل القادم إلى الشبكة هي عبر استخدام الطبقة 7 (وهي طبقة تطبيق application layer) لموازنة الحمل. يسمح استخدام الطبقة 7 لمُوازِن الحمل بتوجيه الطلبات إلى خواديم الواجهة الخلفيّة المختلفة بناءً على المحتوى الذي يطلبه المستخدم. يسمح لك هذا النوع من موازنة الحمل بتشغيل أكثر من خادوم تطبيق ويب تحت نفس النطاق والمنفذ.

إليك رسمًا توضيحيًا لمثالٍ بسيط لموازنة الحمل باستخدام الطبقة 7:

في هذا المثال، إذا قام مستخدم بطلب yourdomain.com/blog فإنّه سيتم توجيهه إلى الواجهة الخلفيّة لـblog، والتي تتكون من مجموعة خواديم تشغّل تطبيق الويب الخاصّ بالمدوّنة. يتم توجيه الطلبات الأخرى إلى web-backend، والتي يمكن أن تكون عاملةً على تشغيل تطبيق ويب مختلف. كلٌّا الواجهتين الخلفيّتين تستعملان نفس خادوم قاعدة البيانات في هذا المثال.

يمكن لجزءٍ من مثالٍ على ملفّ إعدادات الواجهة الأماميّة أن يبدو هكذا:

frontend http
  bind *:80
  mode http

  acl url_blog path_beg /blog
  use_backend blog-backend if url_blog

  default_backend web-backend

• يقوم هذا المثال بإعداد واجهةٍ أمامية تدعى http، والتي ستقوم بمعالجة جميع الطلبات المتدفّقة إلى المنفذ 80.
• يقوم سطر acl url_blog_path_beg /blog بمطابقة ما إذا كان ما يطلبه الزائر يبدأ بـ blog/.
• يقوم سطر use_backend blog-backend if url_blog بجعل الخادوم يستخدم قوائم تحكّم الوصول ACL كوسيط لتوجيه التدفّق إلى blog-backend.
• يحدّد default_backend web-backend أنّه سيتم توجيه كل التدفّقات الأخرى إلى web-backend.

خوارزميات موازنة الحمل

تقوم خوارزميّة موازنة الحمل المستخدمة بتحديد أيٍّ من خواديم الواجهة الخلفيّة سيتم اختيارها عند بدء عملية موازنة الحمل. يوفّر HAProxy عدّة خيارات لهذه الخوارزميّات. بالإضافة إلى خوارزميّة موازنة الحمل فإنّه بالإمكان إسناد مُعامِل الـweight لتحديد الخواديم التي نريد استخدامها بشكلٍ أكبر من الأخرى.

بسبب أنّ HAProxy يوفّر العديد من خوارزميّات موازنة الحمل، فإننا سنتحدّث عن القليل منها فقط هنا. يمكنك مراجعة دليل إعداد HAProxy لقائمةً كاملة بالخوارزميات.

1-roundrobin

تقوم خوارزميّة round robin باختيار الخواديم بالتناوب، وهي الخوارزميّة الافتراضية المستعملة.

2-leastconn

تقوم هذه الخوارزميّة باختيار الخادوم الأقل استخدامًا حاليًا والذي يتصل به أقل عدد من الزوّار ليعالج الطلبات القادمة، هذه الخوارزميّة مستحسنة للجلسات (sessions) الطويلة. يتم أيضًا اختيار الخواديم الموجودة في نفس الواجهة الخلفيّة بالتناوب على طريقة round-robin.

3-Source

تقوم هذه الخوارزميّة باختيار الخادوم الذي يجب استعماله بناءً على عنوان الـIP الخاصّ بالمستخدم. يتم استخدام هذه الطريقة للتأكّد مما إذا كان المستخدم سيتصل بنفس الخادوم.

الجلسات الملتصقة Sticky Sessions

تتطلب بعض التطبيقات أن يقوم المستخدم بمتابعة الاتصال إلى نفس خادوم الواجهة الخلفيّة. يتم تحقيق هذه العمليّة عن طريق ما يعرف بالجلسات الملتصقة أو Sticky Sessions، عبر استخدام مُعامِل appsession في ملف إعدادات الواجهة الخلفيّة التي تحتاجه.

اختبار الحالة Health Check

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

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

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

حلولٌ أخرى

إذا كنتَ تشعر أنّ HAProxy معقّد جدًا مقارنةً باحتياجاتك، فإنّ الحلول التالية قد تناسبك:

• خواديم لينكس الافتراضية (LVS) – مُوَازِن حملٍ يستخدم الطبقة رقم 4 لموازنة الحمل، بسيط وسريع ومتوفّر في معظم توزيعات لينكس.
• Nginx – خادوم ويب سريع ومرن يُمكن أيضًا استخدامه كوسيط أو لغرض موازنة الحمل (راجع مقالتنا السابقة عن استخدام Nginx لموزانة الحمل). يتم استخدام Nginx عادةً بالتوازي مع HAProxy نظرًا لقدرته على إنشاء ذاكرة الخبيئة (caching) وإمكانيات الضغط العالية.

الخاتمة

الآن صرتَ تمتلك معرفةً أساسية حول موازنة الحمل وصرتَ تعرف بضع طرقٍ يستخدمها HAProxy لتلبية احتياجات موازنة الحمل الخاصّة بك، صار لديك قاعدةٌ صلبة لتستند عليها في البدء بتحسين أداء ومرونة بيئة خادوم الويب الخاصّ بك.

ترجمة -وبتصرّف- للمقال: An Introduction to HAProxy and Load Balancing Concepts.

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

الأهداف والمتطلبات

قبل أن تبدأ بهذا الدرس، يجب أن تقرأ درس إعداد خادوم Ubuntu 14.04 من الصفر. قراءة ذلك الدرس أولًا هو أمرٌ مهمّ بهدف إعداد حسابات المستخدمين، إعداد وضبط الصلاحيّات المرتبطة بـsudo وقفل اتصالات SSH للحصول على المزيد من الحماية.

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

إعداد جدار ناري بسيط

تقوم جدران الحماية بتوفير درجة حمايةٍ بسيطة لخادومك. هذه التطبيقات مسؤولة عن منع وصول التدفّقات (traffics) إلى كلّ المنافذ الموجودة في خادومك باستثناء تلك المنافذ/الخدمات التي قمتَ بالسماح لها بالوصول. تأتي توزيعة Ubuntu مع اداة تدعى UFW يُمكن استخدامها لإعداد سياسات (policies) الجدار الناري الخاصّ بك. استراتيجيّتنا البسيطة ستكون قفلَ كلّ شيءٍ لا نرى أنّه من الصواب تركه مفتوحًا.

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

يعمل عفريت SSH (يدعى SSH daemon) على المنفذ 22 افتراضيًا. يمكن لـufw أن يقوم بتطبيق القواعد التي تريدها على SSH طالما أنّك لم تقم بتغيير ذاك المنفذ. لذا إذا لم تكن قد عدّلت المنفذ الافتراضي لـSSH، فيمكنك السماح باستثنائه عبر:

sudo ufw allow ssh

إذا قمتَ بتعديل المنفذ الافتراضي الذي يعمل عليه عفريت SSH، فسيجب عليك السماح له بالوصول إلى الخادوم عبر تحديد رقم المنفذ الجديد مع بروتوكول TCP:

sudo ufw allow 4444/tcp

هذا هو أبسط إعدادٍ متوفّر للجدار الناري. سيسمح فقط بالوصول إلى منفذ SSH الخاصّ بخادومك وسيقوم بحجب كلّ الخدمات الأخرى ومنعها من الوصول إلى الخادوم. إذا كنتَ تريد السماح بوصول المزيد من الخدمات، فسيجب عليك فتح الجدار الناري لكلٍّ منفذٍ تريده بالتحديد.

إذا كنتَ تخطط لتشغيل خادوم ويب لبروتوكول HTTP، فستحتاج إلى السماح بالوصول للمنفذ 80:

sudo ufw allow 80/tcp

إذا كنتَ تريد تشغيل خادوم ويب مع تفعيل SSL/TLS، فيجب عليك السماح بمرور التدفّق عبر المنفذ 443 أيضًا:

sudo ufw allow 443/tcp

إذا كنتَ تحتاج إلى تفعيل بريد SMTP، فيجب أن يكون المنفذ 25 مفتوحًا أيضًا:

sudo ufw allow 25/tcp

بعد أن تنتهي من إضافة هذه الاستثناءات، يجب أن تقوم بمعاينة التغييرات التي قمتَ بها عن طريق:

sudo ufw show added

إذا كان كلّ شيءٍ يبدو جيّدًا، فيمكنك الآن تفعيل الجدار الناري عبر كتابة:

sudo ufw enable

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

تذكّر أنّه يجب عليك فتح أيّ منافذ إضافية لأيّ خدمات إضافية تحتاج الوصول عبر تلك المنافذ. للمزيد من المعلومات التفصيليّة، راجع مقالتنا حول إعداد جدار ufw الناري.

إعداد المناطق الزمنية ومزامنة بروتوكول وقت الشبكة

الخطوة التالية هي ضبط إعدادات التوطين (localization) لخادومك وإعداد مزامنة بروتوكول وقت الشبكة (NTP - Network Time Protocol).

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

إعداد المناطق الزمنية

ستكون خطوتنا الأولى هي إعداد المنطقة الزمنيّة الخاصّة بخادومنا. هذا الأمر سهل للغاية ويمكن فعله عبر إعادة إعداد حزمة tzdata:

sudo dpkg-reconfigure tzdata

سيتم عرض قائمة لك تحتوي مناطق العالم المتوفّرة، اختر المنطقة التي تعيش بها:

بعد اختيار منطقة معيّنة، ستكون قادرًا على اختيار منطقة زمنيّة معيّنة لضبطها في خادومك الشخصي عبر اختيار العاصمة أو المدينة التي تعيش بها:

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

Current default time zone: 'America/New_York'
Local time is now: Mon Nov 3 17:00:11 EST 2014.
Universal Time is now: Mon Nov 3 22:00:11 UTC 2014.

إعداد مزامنة NTP

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

لمزامنة NTP، سنستخدم خدمة تدعى ntp، والتي يمكننا تثبيتها من مستودعات Ubuntu الافتراضية:

sudo apt-get update
sudo apt-get install ntp

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

اضغط هنا إذا أردت تعلّم المزيد عن خواديم NTP.

إنشاء ملف Swap

يسمح إنشاء ملفّ "Swap" على خادوم لينكس للنظام بنقل المعلومات والبرامج الأقل استعمالًا حاليًا من الذاكرة العشوائية RAM إلى موقعٍ معيّن على القرص الصلب. الوصول إلى البيانات الموجودة على القرص الصلب هو أبطئ بكثير من عملية الوصول إليها لو كانت على الذاكرة العشوائية RAM، ولكنّ توفير قرص Swap قد يكون الأمر الفاصل بين بقاء تطبيقاتك العاملة حاليًا على قيد الحياة وبين تحطّمها (crash). هذا الأمر مفيد للغاية خاصةً في حال كنتَ تنوي استضاف قواعد بيانات على خادومك.

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

قم باقتطاع المساحة التي تريد تخصيصها لقرص الـSwap من نظام الملفّات الكلّي باستخدام أداة fallocate. كمثال، إذا احتجنا إلى عمل قرص Swap حجمه 4 جيجابايت، فيمكننا إنشاء ملفّ Swap بالمسار /swapfile عن طريق كتابة:

sudo fallocate -l 4G /swapfile

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

sudo chmod 600 /swapfile

نمتلكُ الآن ملفّ Swap مضبوطًا على الصلاحيّات الصحيحة. لإخبار نظامنا بتهيئة الملفّ وإعداده ليكون قرص Swap، فلنطبّق:

sudo mkswap /swapfile

يمكننا الآن أن نخبر نظامنا أن يستخدم الملفّ الجديد عن طريق تطبيق:

sudo swapon /swapfile

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

sudo sh -c 'echo "/swapfile none swap sw 0 0" >> /etc/fstab'

مع هذه الإضافة، يجب أن يكون نظامك قادرًا على استخدام ملفّ Swap تلقائيًا عند كل إقلاع.

أين الطريق من هنا؟

بدأتَ الآن بداية جيّدة في إعداد خادومك العامل بنظام لينكس. من هنا، هناك العديد من الأماكن التي يمكنك التوجّه إليها الآن. أولًا، قد تودّ أخذَ لقطةٍ احتياطية (snapshot) من خادومك بإعداداته الحاليّة.

خذّ لقطةٍ احتياطية من إعداداتك الحاليّة

إذا كنتَ مرتاحًا مع إعداداتك الحاليّة وكنتَ تودُّ استخدامها كقاعدةٍ أساسية في خواديمك المستقبليّة، فيمكنك أخذ لقطةٍ احتياطيّة لخادومك عبر لوحة تحكّم DigitalOcean.

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

sudo poweroff

الآن، في لوحة تحكّم DigitalOcean، يمكنك أخذ لقطةٍ احتياطية عبر زيارة لسان "Snapshots" الموجود في صفحة خادومك:

بعد أخذ اللقطة الاحتياطية التي تريدها، ستكون قادرًا على استعمال تلك الصورة كقاعدةٍ لعمليات تثبيت وإعداد خواديمك المستقبلية عبر اختيار تلك اللقطة الاحتياطية من لسان "My Snapshots" كنظام تشغيل أثناء عمليّة الإنشاء:

مصادر إضافيّة وخطواتٌ أخرى

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

• كيف تُثبّت حزم LEMP كـ: Linux, PHP, Nginx و MySQL على أوبونتو 14.04
• كيف تُثبّت حزم LAMP كـ: Linux, PHP, Apache و MySQL على أوبونتو 14.04
• تثبيت سكربت إدارة المحتوى ووردبريس على خادوم Apache
• تثبيت سكربت إدارة المحتوى ووردبريس على خادوم Nginx
• تثبيت سكربت إدارة المحتوى دروبال على خادوم Apache
• تثبيت Node.js
• تثبيت Ruby on Rails مع RVM
• تثبيت Laravel, إطار عمل PHP
• تثبيت Puppet لإدارة البنى التحتية

الخاتمة

بعد هذا الدرس، يجب أن تكون صرتَ تعرف كيفيّة إعداد بنيةٍ تحتية جيّدة لخواديمك الجديدة. لحسن الحظّ، لديك قائمة جيّدة بالأفكار التي يمكنك تطبيقها كخطوةٍ تالية. يمكنك تصفّح المقالات الموجودة بقسم DevOps بموقع أكاديمية حسوب لرؤية المزيد من الدروس التي يمكنك تطبيقها.

ترجمة -وبتصرّف- للمقال: Additional Recommended Steps for New Ubuntu 14.04 Servers.

حِزم LEMP هي مجموعة من البرامج يُمكِن استخدامُها لتقديم صفحات ويب ديناميكيّة وتطبيقات ويب. يُشير هذا الاختصار إلى بيئة تتكوَّن من نظام تشغيل Linux، وخادوم ويب Nginx؛ تُخزَّن البيانات في قاعدة بيانات MySQL ويتولّى PHP مُعالجةَ المحتوى الدّيناميكي.

سنشرح في هذا الدّرس كيفيّة تثبيت حزم LEMP على خادوم Ubuntu 14.04. يُمثِّل Ubuntu اللّبنة الأولى من حزمة LEMP في هذا الدّرس؛ سنشرح كيفيّة الحصول على بقيّة المُكوِّنات وتشغيلها.

المتطلبات

لإجراء الخطوات المذكورة في هذا الدّليل، يجب أن يكون لديك حساب عادي (غير الحساب الجذر Root user) بصلاحيّات sudo. يُمكنك معرفة كيف تضبُط حسابًا بهذه المواصفات في الخطوات من 1 إلى 4 من درس الإعداد الابتدائي لخادوم أوبنتو 14.04.

سجِّل الدّخول إلى خادومك عبر الحساب المذكور حتى تكون جاهزًا لتطبيق خطوات الشّرح.

الخطوة الأولى: ثبت خادوم ويب Nginx

لنكون قادرين على عرض صفحات ويب لزوّار موقعنا سنستخدم Nginx؛ وهو خادوم ويب حديث وفعّال. كلّ البرامج الّتي سنُثبِّتها موجودة في المُستودعات Repositories الرّسميّة لأوبنتو، لذا سنستعين ببرنامج apt لإدارة الحزم لإكمال عمليّة التّثبيت.

نبدأ أوّلًا بتحديث فهرس الحزم، ثمّ نُثبِّت خادوم الويب:

sudo apt-get update
sudo apt-get install nginx

في أوبنتو 14.04 يبدأ Nginx بالعمل فور تثبيته. يُمكِن التّأكّد من ذلك عبر إدخال اسم نطاق Domain name أو عنوان IP الخادوم العموميّ في شريط العنوان الموجود في مُتصفِّح الويب.

ملحوظة: إذا كنتَ تُجرِّب هذه الخطوات على جهازك الشّخصي (أو جهاز محلّي) فعنوان خادوم الويب هو 127.0.0.1 (أو localhost).

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

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

مثال على نتيجة تنفيذ الأمر أعلاه:

111.111.111.111
fe80::601:17ff:fe61:9801

يُمكن أيضًا تجربة الأمر:

curl http://icanhazip.com

النّتيجة:

111.111.111.111

جرّب الدّخول إلى العنوان الّذي حصلتَ عليه عن طريق إدخاله في شريط عنوان المتصفِّح:

http://server_domain_name_or_IP

يجب أن تظهر لديك صفحة الهبوط Landing page الافتراضيّة لـNginx:

إذا ظهرت لك هذه الصّفحة فمعناهُ أنّ Nginx ثُبِّت بنجاح.

الخطوة الثانية: ثبت MySQL لإدارة بيانات الموقع

نحتاج بعد تثبيت خادوم الويب إلى نِظامٍ لإدارة قواعد البيانات Database management system, DBMS من أجل حفظ وإدارة بيانات موقعنا. سنستخدم MySQL لهذا الغرض. لتثبيت MySQL نُنفِّذ الأمر:

sudo apt-get install mysql-server

سيُطلب منك إدخال كلمة سر لحساب المُستخدم الأعلى (الجذر Root) ضمن نظام MySQL.

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

نُواصِل مع MySQL عبر استكمال إعداداتِه.

أوّلًا، نُنفِّذ الأمر التّالي الّذي يطلُب من MySQL توليدَ بُنية المجلّدات الّتي يحتاجها من أجل حفظ قواعد البيانات:

sudo mysql_install_db

ثمّ ننتقل لإجراء بضعة إعدادات أمنيّة حيثُ سنُغيِّر قيّمًا افتراضيّة غير الآمنة، عبر تنفيذ سكربت "التثبيت الآمن":

sudo mysql_secure_installation

سيُطلَب منك إدخال كلمة سر حساب المُدير في MySQL (نفس كلمة السّر الّتي أدخلتها أثناء التّثبيت).

بعدها ستظهر رسالة تسألك إذا ما كنتَ تُريد تغيير كلمة سر المُدير في MySQL، إن لم تكن ترغب في ذلك أدخل حرف N ثمّ اضغط زر Enter. بقيّة الأسئلة تتعلّق بإزالة بعض الحسابات وقواعد البيانات المُعَدَّة للتّجربة؛ فقط اضغط Enter للإجابة عليها وستُحذَف الإعدادات الافتراضيّة غير الآمنة.

نظام إدارة قواعد البيانات MySQL جاهز الآن للعمل.

الخطوة الثالثة: ثبت PHP لمعالجة البيانات

ثبّتنا كلًّا من Nginx لتقديم صفحات الموقع وMySQL لتخزين وإدارة البيانات؛ بقيَ ربطُ الاثنيْن من أجل توليد محتوى ديناميكي. يُؤدّي PHP هذه الوظيفة.

لا يأتي خادوم ويب Nginx بمعالج PHP مُضَمَّن كما هي حال بعض خواديم الويب الأخرى، لذا سنحتاج إلى تثبيت php5-fpm (حيثُ fpm اختصار لـ fastCGI process manager، وهوّ مُكوِّن مسؤول عن تقديم المحتوى الديناميكي في PHP)، ثمّ نطلُب من Nginx تمريرَ طلبات PHP إلى هذا البرنامج لمُعالجتها.

يُمكِن تثبيت هذا العُنصُر وفي نفس الوقت نُثبِّت المكوِّن الّذي يسمح ل PHP بالتّواصُل مع النّهاية الخلفيّة Backend متمثّلةً في قاعدة البيانات؛ سيُنزِّل أمرُ التّثبيت كافّةَ الملفّات الضّروريّة:

sudo apt-get install php5-fpm php5-mysql

ضبط مُعالج PHP

ينتُج عن تنفيذ الأمر السّابق تثبيتُ العناصِر الضّروريّة لعمل PHP، لكن يتوجّب ضبطُ بعض الإعدادات من أجل أمان أكثر.

افتَح الملف الرّئيس لإعداد php5-fpm بصلاحيّات الجذر:

sudo nano /etc/php5/fpm/php.ini

نبحث عن مُعطى Parameter باسم cgi.fix_pathinfo. افتراضيًّا ستجد أنّه مسبوق بعلامة ";" (دلالةً على أن السّطر تعليق، أي أنه لا يُؤخذ في الاعتبار) بقيمة مُساويّة لـ"1". هذا الإعداد غير آمن بالمرة، فهو يطلب من PHP تخمينَ الملف الذي يبحث عنه المستخدِم وتنفيذه إن لم يجد تطابقا تامًّا مع طلبه. أي أنّ الإعداد يُتيح للمستخدمين إنشاءَ طلبات PHP بحيث تؤدّي إلى تنفيذ سكربتات لا يجوز السّماح لهم بتنفيذها. نُغيّر الإعداد عن طريق حذف علامة التّعليق (";") ثمّ تبديل قيمة المُعطى لتُصبح 0، كما يلي:

cgi.fix_pathinfo=0

احفظ الملف (Ctrl + O ثم زر Enter) ثم أغلقه بعد الانتهاء من تحريره (Ctrl + x).

نُعيد تشغيل مُعالج PHP لأخذ التّغييرات بالاعتبار:

sudo service php5-fpm restart

الخطوة الرابعة: اضبط Nginx على استخدام معالج PHP

جميع العناصِر مُثبَّتة الآن؛ تبقّى تعديلٌ واحدٌ وهو إعدادُ Nginx لاستخدام معالج PHP المُعدّ أعلاه للتّعامل مع المُحتوى الدّيناميكي.

يُضبط هذا الإعداد على مُستوى مُربّع الخادوم Server block (مُربّعات الخادوم مُشابهة لـلمُستضيفات الافتراضيّة Virtual hosts على خادوم ويب Apache ). افتَح الملف الافتراضي لإعداد مُربّع خادوم Nginx عبر تنفيذ الأمر:

sudo nano /etc/nginx/sites-available/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;
    }
}

سنُجري بضع تعديلات على هذا الملف.

نحتاج أوّلًا إلى إضافة خيّار index.php إلى تعليمة Directive الفهرس، ممّا يسمح بتقديم ملفّات فهارس PHP عند طلَب مُجلَّد. نحتاج أيضًا إلى تعديل تعليمة server_name حتّى تُشير إلى اسم نطاق الخادوم أو عنوانه العموميّ.

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

نفس الشّيْء بالنّسبة لمُعالج PHP، ننزع التّعليق عن أسطُر أخرى من ملفّ الإعداد. ثمّ أخيرًا نُضيف التّعليمة try_files للتّأكّد من أنّ Nginx لا يُمرّر طلباتٍ غير صالحة لمُعالج PHP.

تظهر التّغييرات في مُحتوى الملفّ أدناه باللّون الأحمر:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    root /usr/share/nginx/html;
    index index.php index.html index.htm;

    server_name server_domain_name_or_IP;

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

    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

يُمكِن حفظ الملف وغلقُه بعد إجراء التّعديلات.

أعِد تشغيل Nginx لأخذ التّغييرات في الاعتبار:

sudo service nginx restart

الخطوة الخامسة: أنشئ ملف PHP لاختبار الإعدادات

يُفترَض أن تكون حزم LEMP مُثبَّتة وجاهزة للعمل. سنتأكّد الآن أنّ خادوم ويب Nginx يتعامل مع ملفّات PHP ويُمرِّرها لمُعالج PHP.

نُنشئ عبر الأمر التّالي ملفَّ اختبار PHP في مَبدَأ المستند Document root:

sudo nano /usr/share/nginx/html/info.php

يُمكِن أن نُضيف الأسطُر التّالية؛ وهي شفرة برمجيّة Code صالحة في لغة PHP، ينتُج عنها عرض معلومات الخادوم على الصّفحة.

<?php

phpinfo();

?>

احفَظ الملفّ ثمّ أغلقه.

اذهب إلى متصفِّح الويب ثم اعرض للصّفحة عبر إدخال اسم نطاق أو عنوان الموقع (server_domain_name_or_IP) متبوعًا ب info.php/ كما يلي:

http://server_domain_name_or_IP/info.php

يجب أن تظهر لديك صفحة ويب تعرِض معلومات الخادوم، كما في الصّورة.

يدُلّ ظهور الصّفحة على نجاح إعداد Nginx للتّعامل مع ملفّات PHP.

من الأفضل حذفُ ملفّ info.php بعد انتهاء الاختبار، إذ أنّه يُمكن أن يكشف عن إعدادات موقعك، الأمر الّذي قد يُساعِد من يُحاول الحُصول على وُصول غير مُرَخَّص. يُمكِنك دائمًا إنشاء هذا الملفّ عندما تُريد إجراء اختبارات. للحذف، نفّذ الأمر التّالي:

sudo rm /usr/share/nginx/html/info.php

خاتمة

يُمكِّن اتّباع الخطوات السّابقة من إعداد وضبط حزمة LEMP على خادوم أوبنتو 14.04. تُعطي هذه الحزمة قاعدة جيّدة ومرنة من أجل تقديم مُحتوى ديناميكي لزوّار موقعك.

ترجمة -وبتصرّف- للمقال How To Install Linux, nginx, MySQL, PHP (LEMP) stack on Ubuntu 14.04 لصاحبه Justin Ellingwood.

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

سنُثبِّت في هذا الدّليل حزم LAMP على خادوم Ubuntu 14.04، حيث يُمثِّل أوبنتو اللّبنة الأولى من الحزمة (نظام التّشغيل).

المتطلبات

يجب، من أجل مُتابعة خطوات هذا الدّرس، أن يكون لديك حساب عادي (غير الحساب الجذر Root user) بصلاحيّات sudo. يُمكنّك معرفة كيف تضبُط حسابًا بهذه المواصفات في الخطوات من 1 إلى 4 من درس الإعداد الابتدائي لخادوم أوبنتو 14.04.

الخطوة الأولى: ثبت Apache

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

يُمكن تثبيت خادوم ويب Apache بسهولة عن طريق مدير حزم Package manager أوبنتو، apt. نبدأ بتحديث فهرس الحزم ثمّ نُثبّت حزمة apache2 لنحصُل على خادوم ويب Apache:

sudo apt-get update
sudo apt-get install apache2

سيُطلب منك إدخال كلمة السّر من حين لآخر، نظرًا لاستخدام صلاحيّات الجذر (Root) عن طريق sudo.

ننتقل إلى مُتصفِّح الويب بعد انتهاء تنفيذ الأمر السّابق للتّأكد من تثبيت Apache. نُدخِل عنوان IP الخادوم العمومي أو اسم نطاق الموقع Domain name في شريط عنوان المُتصفّح:  

http://your_server_IP_address

ملحوظة: إذا كنتَ تُجرِّب هذه الخطوات على جهازك الشّخصي (أو جهاز محلّي) فعنوان خادوم الويب هو 127.0.0.1 (أو localhost).

ستظهر الصّفحة الافتراضيّة لخادوم ويب Apache، حيثُ توجد بعض معلومات الإعداد. شكل الصّفحة يبدو كالتّالي:

إن عُرضت الصّفحة أعلاه فتثبيتُ خادوم ويب Apache جرى كما يُرام.

كيف تجد عنوان IP العمومي لخادومك

ملحوظة: هذه الفقرة غير مُوَّجَّهة لمن يختبر التّثبيت على حاسوبه الشّخصي.

توجد عدّة طُرُق لمعرفة عنوان IP العمومي لخادوم على شبكة الإنترنت. عنوان IP العمومي للخادوم هو في العادة نفس العنوان الّي تتّصل به عن طريق SSH.

نفِّذ الأمر التّالي في سطر الأوامر:

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

ينتُج عن هذا الأمر سطر أو اثنان (واحد عنوان كما يُكتَب في الإصدار الرّابع IPv4 من بروتوكول IP، والآخر كما يُكتَب في الإصدار السّادس IPv6). في حال كانت النّتيجة سطرين فكلاهما صحيح ولكن من الممكن ألّا يستطيعَ حاسوبك الشّخصي التّعامل إلا مع واحد منهما؛ جرّب العنوانيْن حتى تحصُل على العنوان المُناسب.

توجد طريقة بديلة وهي استخدام خدمة عامّة للحصول على عنوان IP. للحصول على العنوان نتّصل بالخدمة ونطلُب منها إخبارنَا عن العنوان الّذي نتّصِل منه:

curl http://icanhazip.com

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

مهما اختلفت الطّريقة فالمهم هو الحصول على عنوان خادومك ثمّ إدخاله في شريط العناوين في المتصفّح للتّأكّد من تثبيت خادوم ويب Apache.

الخطوة الثانية: ثبت MySQL

يأتي الآن دورُ MySQL، بعد تثبيت MySQL. Apache هو نظام لإدارة قواعد البيانات DataBase Management System, DBMS؛ وهو برنامج مسؤول عن إدارة وتوفير الاتّصال بقاعدة البيانات الّتي تُخزَّن بها معلومات الموقع.

سنستخدم - كما في الخطوة السّابقة - مُديرَ حزم Apt، ولكن هذه المرّة سنُضيف بعض الحزم المُساعدة من أجل تمكين الاتّصال بين مختلف عناصِر البيئة الّتي نحن في طور إعدادها.

sudo apt-get install mysql-server php5-mysql

ملحوظة: لم ننُفِّذ أمر sudo apt-get update قبل أمر التّثبيت هذه المرّة. يعود السّبب في ذلك إلى أنّنا نفّذنا هذا الإجراء للتّو وهو ما يعني أنّ فهرس الحزم لدينا مُحدَّث up-to-date.

أثناء تثبيت MySQL سيطلُب منك الخادوم اختيّار كلمة سرّ للمُستخدِم root على MySQL. الحساب root هو حساب إداريّ يملك صلاحيّات واسعة على نظام قواعد البيانات؛ وهو يُشبه إلى حدٍّ مّا الحساب الجذر في خادوم أوبنتو نفسه (لكن انتبِه إلى أنّه حساب خاص بنظام MySQL لإدارة قواعد البيانات).

نحتاج بعد انتهاء التّثبيت إلى تنفيذ أوامر إضافيّة من أجل تأمين MySQL.

نطلُب أوّلا من MySQL إنشاءَ بُنية المجلّدات الخاصّة بقاعدة البيانات حيثُ سيُخزّن المعلومات. الأمر التّالي يُؤدّي هذه المهمّة:

sudo mysql_install_db

ثمّ نُنفّذ سكربت التّثبيت الآمن الّذي يحذِف بعض القيّم الافتراضيّة غير الآمنة ويمنع الوصول المُباشر لنظام إدارة قواعد البيانات:

sudo mysql_secure_installation

سيُطلب منك النّظام إدخال كلمة سرّ الحساب الجذر في MySQL؛ ثمّ يسألك ما إذا كنتَ تُريد تغييرها. أدخل حرف n (دلالةً على "no" أي "لا") إن لم تكن ترغبُ في ذلك.

بقيّة الأسئلة تتعلّق بإزالة بعض الحسابات وقواعد البيانات المُعَدَّة للتّجربة، تعطيل الدّخول عن بُعد للحساب الجذر، ثم تحميل الإعدادات الجديدة ليبدأ MySQL العمل بها مُباشرةً؛ فقط اضغط Enter للإجابة على هذه الأسئلة.

تحصُل بعدانتهاء هذه الخطوة على نظام قواعد بيانات مضبوط وجاهز للعمل.

الخطوة الثالثة: ثبت PHP

يتولّى PHP التّعاملَ مع البيانات لإظهار المُحتوى الدّيناميكي؛ حيث يُنفِّذ السكربتات، يتّصِل بقاعدة بيانات MySQL ويُمرّر المُحتوى - بعد معالجته - إلى خادوم الويب، الّذي يعرضه.

نستعين بمُدير الحزم apt مُجدّدًا لتثبيت PHP وبعض البرامج المُساعِدة الأخرى:

sudo apt-get install php5 libapache2-mod-php5 php5-mcrypt

ينبغي أن يكون الأمر السّابق كفيلًا بتثبيت PHP دون أيّة مشاكل. سنختبر نجاح التّثبيت بعد قليل.

يقضي الإعداد الافتراضي لخادوم ويب Apache بالبحث أوّلا عن ملفّ باسم index.html عند وصول طلب لعرض مُجلّد. سنُغيّر هذا الإعداد بحيثُ يبحث خادوم الويب أوّلًا عن ملفّ PHP باسم index.php. نفتح ملفّ dir.conf في المُحرّر بصلاحيّات المُستخدِم الجذر:

sudo nano /etc/apache2/mods-enabled/dir.conf

يُشبه مُحتوى الملفّ الشّكلَ التّالي:

<IfModule mod_dir.c>
  DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm
</IfModule>

ما نُريده هو تقديم ملف index.php المُعلَّم بالأحمر أعلاه إلى الوضعيّة الأولى، مباشرةً بعد تعليمة DirectoryIndex  هكذا:

<IfModule mod_dir.c>
  DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm
</IfModule>

احفَظ الملفّ بعد الانتهاء من تحريره عن طريق الضغط على الزّرّيْن CTRL+O ثم زرّ Enter في لوحة المفاتيح وأغلِقه بالضّغط على الزّرّيْن CTRL+X.

نعيد تشغيل Apache للعمَل بالإعدادات الجديدة:

sudo service apache2 restart

ثبت وحدات PHP Modules ،PHP

توجد بعض الوِحدات Modules الاختيّاريّة الّتي نستطيع تثبيتَها من أجل تحسين وظائف PHP.

ننفِّذ الأمر التّالي لعرض مكتبات Libraries ووِحدات PHP المُتاحة:

apt-cache search php5-

جميع ما يظهَر في النّتائج هيّ وحدات اختيّاريّة يُمكن تثبيتها إن أردت. تتضمّن كل نتيجة اسم الوحدة ووصفًا مُختَصرًا لها:

php5-cgi - server-side, HTML-embedded scripting language (CGI binary)
php5-cli - command-line interpreter for the php5 scripting language
php5-common - Common files for packages built from the php5 source
php5-curl - CURL module for php5
php5-dbg - Debug symbols for PHP5
php5-dev - Files for PHP5 module development
php5-gd - GD module for php5
. . .

إن أردت معلوماتٍ أكثرَ عن إحدى الوِحدَات يمكنك البحث على الشّبكة أو استخدام أمر الوصف المُطَوَّل للحزمة عبر تنفيذ الأمر (حيثُ package_name اسم الحزمة):

apt-cache show package_name

بالنّسبة لوحدة php5-cli على سبيل المثال:

apt-cache show php5-cli

ستجد أن هناك مخرجاتٍ عديدةً من بينها حقلٌ باسم Description-en يُقدّم شرحًا لوظيفة الوِحدة (بالإنجليزيّة غالبًا، إلّا إذا كان التّوثيق Documentation يتوفّر بلغة النّظام لديك).

. . .

SHA256: 91cfdbda65df65c9a4a5bd3478d6e7d3e92c53efcddf3436bbe9bbe27eca409d

Description-en: command-line interpreter for the php5 scripting language

This package provides the /usr/bin/php5 command interpreter, useful for testing PHP scripts from a shell or performing general shell scripting tasks.

.

The following extensions are built in: bcmath bz2 calendar Core ctype date dba dom ereg exif fileinfo filter ftp gettext hash iconv libxml mbstring mhash openssl pcntl pcre Phar posix Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tokenizer wddx xml xmlreader xmlwriter zip zlib.

.

PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.

Description-md5: f8450d3b28653dcf1a4615f3b1d4e347

Homepage: http://www.php.net/

. . .

إذا أردتَ تثبيت وِحدة من وِحدات PHP، بعد الحصول على المعلومات الكافيّة عن وظيفتها، فيُمكنك استخدامُ أمر apt-get install. بالعودة إلى مثال php5-cli فإنّ التّثبيت يكون كما يلي:

sudo apt-get install php5-cli

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

sudo apt-get install package1 package2

ينبغي أن تكون حزم LAMP، بالوصول إلى هذه النّقطة من الدّليل، مُثّبَّتةً ومضبوطةً. ننتقل إلى اختبار PHP.

الخطوة الرابعة: اختبر تعامل خادوم الويب مع ملفات PHP

سننشئ سكربت PHP مُيَسّرًا من أجل اختبار إعدادات PHP وخادوم الويب. الهدف هوّ أن يعثُر خادوم الويب على السكربت، الّذي سنُسمّيه info.php، ثمّ يعرض محتواه بشكل صحيح.

يجب أن يُحفَظ الملفّ في مجلّد خاصّ، يُسمّى جذر الويب Web root (في هذا المُجلَّد مباشرةً أو في أحد المجلّدات المتفرّعة عنه)، لكي يعثُر عليه خادوم ويب Apache .

يوجد جذر الويب في أوبنتو 14.04 على المسار /var/www/html/. نُنشئ ملفَّ اختبار الإعداد داخل هذا المسار عبر الأمر:

sudo nano /var/www/html/info.php

سيُفتح المحرّر وبداخله ملفّ فارغ، نُضيف إليه الشيفرة البرمجيّة التّاليّة:

<?php
  phpinfo();
?>

هذا كل ما في الأمر. احفظ الملفّ ثم أغلقه.

لاختبار إعداد خادوم الويب نفتح متصفّحَ ويب ثمّ نُدخل عنوان الصّفحة في شريط العنوان. يتكوّن عنوان الصّفحة من عنوان IP العمومي لخادوم الويب (أو اسم النّطاق) متبوعًا بمسار تواجد الصّفحة بالنّسبة لجذر الويب. صفحة الاختبار الّتي أعددناها موجودة في جذر الويب وهو ما يعني أنّ عنوان الوصول إليها هوّ التّالي (حيث your_server_IP_address هو عنوان IP أو اسم نطاق الموقع):

http://your_server_IP_address/info.php

يجب أن تظهر في المتصفّح صفحة الويب التّاليّة:

تُقدّم هذه الصّفحة معلوماتٍ عن الخادوم كما يراه PHP. بعض هذه المعلومات مهمّ لمعرفة إعدادات خادوم الويب ومُعالج PHP، كما أنّها تُساعِدك أثناء تنقيح Debugging السكربتات.

إذا ظهرت الصّفحة فهذا يعني أنّ PHP يعمل كما نُريد.

يُنصَح بحذف هذه الصّفحة بعد الانتهاء من الاختبار، حيث إنّها قد تُعطي معلوماتٍ عن خادومك لأشخاص لا يجدر بهم الحصول على هذه المعلومات، الأمر التّالي يؤدّي هذه المهمّة:

sudo rm /var/www/html/info.php

يُمكن دائمًا إنشاء صفحة الاختبار من أجل الوصول إلى المعلومات الّتي توفّرها، متى أردت ذلك.

خاتمة

باستكمال خطوات هذا الدّليل تكون قد وضعتَ الأساس لتثبيت، استعمال وإعداد العديد من أنواع مواقع وتطبيقات الويب.

ترجمة -وبتصرف- للمقال How To Install Linux, Apache, MySQL, PHP (LAMP) stack on Ubuntu 14.04 لصاحبه Justin Ellingwood.

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

الخطوة الأولى - الولوج Login إلى الحساب الجذر Root

يتوجّب عليك، للولوج إلى خادومك، معرفة عنوان IP العمومي Public IP Address إضافةً إلى كلمة سر حساب المستخدم الجذر. إن لم تكن قمتَ بالولوج إلى خادومك من قبل فبإمكانك الاطّلاع على الدرس أساسيات وخيارات الاتصال بخادوم عن بعد باستخدام SSH (البرنامج المسؤول عن الاتصال بالخادوم عن بعد)، الذي يُغطي هذه العملية بالتفصيل.

ابدأ بالاتصال بخادومك عن طريق الأمر التّالي (أبدِل الكلمة البارزة بعنوان IP خادومك العمومي):

ssh root@SERVER_IP_ADDRESS

أكمِل عملية الولوج بقبول التحذيرات حول موثوقية المستضيف Host authenticity في حال ظهورها، وإعطاء معلومات التحقق (كلمة السّر أو المفتاح السري). سيُطلب منك تبديل كلمة سر حساب المستخدِم الجذر إن كانت هذه أول مرة تلِج إلى الخادوم باستخدام كلمة السر.

حول المستخدم الجذر

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

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

الخطوة الثانية - إنشاء مستخدم جديد

بعد الولوج باستخدام الحساب الجذر تُصبِح على استعداد لإضافة الحساب الجديد الذي سنلِج باستخدامه من الآن فصاعدا.

يُنشئ المثال التالي مستخدما باسم "demo"، أبدِلهُ باسم المستخدم الذي تراه مناسِبا:

adduser demo

ستُطرَح عليك بعض الأسئلة، بدءًا بكلمة سرالحساب.

أدخِل كلمة سر قوية. يُمكنك تعبئة بقية المعلومات الإضافية حسب رغبتك. اضغط على زر Enter في لوحة المفاتيح لتجاوز أي حقل لا تودّ تعبئته.

الخطوة الثالثة - امتيازات الجذر

لدينا الآن حساب مستخدم جديد بامتيازات حساب عادي. سنحتاج في بعض الأحيان إلى القيام ببعض الأعمال الإدارية التي تتطلّب امتيازات الجذر. نستطيع إعداد "مستخدم أعلى" Super user لتجنب الخروج من الحساب العادي والولوج بالحساب الجذر أثناء القيام بالمهام الإدارية. المستخدم الأعلى هو مستخدم عادي ولكنه يستطيع الحصول على امتيازات المستخدم الجذر مؤقتا عن طريق كتابة sudo أمام الأوامر التي يطلب تنفيذها.

يتوجّب علينا إضافة المستخدم الجديد إلى مجموعة المستخدمين Users group sudo حتى يتسنى له الحصول على الامتيازات الإدارية. يُسمَح - في الإعداد الافتراضي لأوبنتو 14.04 - للمستخدمين الأعضاء في مجموعة sudo باستخدام أمر sudo.

نفّذ باستخدام الحساب الجذر، الأمر التالي لإضافة المستخدم الجديد إلى المجموعة sudo (أبدِل الكلمة البارزة بالاسم الذي اخترتَه للمستخدم الجديد):

gpasswd -a demo sudo 

يُمكِن للمستخدِم الجديد الآن تنفيذ أوامر بامتيازات المستخدِم الأعلى.

الخطوة الرابعة - إضافة الاستيثاق عن طريق المفتاح العمومي Public Key Authentication (يوصى بهذه الخطوة)

الخطوة التالية في تأمين خادومك هي إعداد مفتاح عمومي Public Key للمستخدم الجديد. هذا الإعداد سيرفع من أمان خادومك بطلب مفتاح SSH سري للولوج.

توليد زوج من المفاتيح

سيتوجّب عليك توليد زوج مفاتيح (مفتاح عمومي وآخر سرّي). إن كان لديك مفتاح عمومي ترغب في استخدامه تجاوز إلى خطوة نسخ المفتاح العمومي.

لتوليد زوج مفاتيح جديدة نفِّذ الأمر التالي على الطّرفيةTerminal محليًّا (على حاسوبك الشخصي):

ssh-keygen 

ستظهر لك مُخرجات شبيهة بما يلي (localuser هنا هو اسم المستخدم الذي يُنفِّذ الأمر):

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/localuser/.ssh/id_rsa): 

اضغط زر Enter على لوحة المفاتيح لقبول اسم ومسار حفظ الملف، أو أدخل مسارا لملف جديد.

سيُطلب منك بعدها إدخال عبارة سر Passphrase لتأمين المفتاح. عبارة السّر اختيارية ويُمكنك تجاوزها وتركها خاوية.

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

حصلنا الآن على مفتاح سري (id_rsa)، وآخر عمومي (id_rsa.pub) يوجدان في المجلَّد ssh. الموجود في المجلّد الشخصي للمستخدم localuser. تذكَّر أنه لا يجوز على الإطلاق مُشاركة المفتاح السري مع أي شخص لا يحق له الاتصال بخواديمك.

نسخ المفتاح العمومي

بعد توليد المفتاح العمومي محليًّا ننقلهُ إلى الخادوم.

استخدم الأمر التالي لإظهار مفتاحك العمومي (أبدِل مسار الملف في حال غيّرت مسار الحفظ أثناء توليد المفتاح)

cat ~/.ssh/id_rsa.pub 

سيظهر مفتاحك العمومي الذي يُشبه شكلُه التالي:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local 

حدّد المفتاح العمومي وانسخه إلى الحافِظة Clipboard.

إضافة المفتاح العمومي إلى المستخدم الجديد على الخادوم

يجب إضافة مفتاح SSH إلى ملف خاص يوجد بالمجلد الشخصي للمستخدِم على الخادوم حتى يتسنى له استعمالُه للاستيثاق.

استعمل الأمر التالي - على الخادوم - للانتقال من المستخدِم الجذر إلى المستخدِم الذي أنشأناه في الخطوات الأولى من هذا الدّليل (أبدِل demo باسم المستخدِم الذي اخترتَه):

su - demo

ستُنقَل بعدَ الولوج إلى الخادوم إلى ملف المستخدم الشخصي.

أنشئ مجلَّدا فرعيا جديدا في المجلّد الشخصي باسم ssh. (النقطة جزء من الاسم) مع تقييد الأذون Permissions عن طريق الأوامر التالية:

mkdir .ssh
chmod 700 .ssh 

سنُنشئ الآن ملفًا باسم authorized_keys مع فتحه عن طريق محرِّر نصوص. سنستخدِم محرِّر Nano للتعديل على الملف، كما في الأمر التالي:

nano .ssh/authorized_keys 

ثم نأتي لإدراج المفتاح العمومي في الملف عن طريق لصقه في المحرِّر.

اضغط على الزريْن CTRL و X معًا في لوحة المفاتيح للخروج من المحرِّر ثم زر Y لحفظ التغييرات وEnter لتأكيد اسم الملف.

نُقيّد الأذون على الملف authorized_keys عن طريق الأمر:

chmod 600 .ssh/authorized_keys 

للعودة إلى المستخدِم الجذر ننفِّذ الأمر التالي:

exit 

بإمكانك الآن الولوج إلى حساب المستخدم الجديد عن طريق SSH باستخدام المفتاح السري.

الخطوة الخامسة - إعداد SSH

يُمكننا، بعد أن أنشأنا حسابَ مستخدم جديدًا، زيادة تأمين الخادوم عن طريق تغيير إعداد SSH . نبدأ بفتح ملف الإعدادات بواسطة محرِّر نصوص مع استعمال المستخدِم الجذر:

nano /etc/ssh/sshd_config 

تغيير منفذ Port الاتصال عن طريق SSH (اختياري)

أولى التغييرات ستكون تعديل المنفذ الذي يستخدمه SSH للاتصال بالخادوم. ابحث عن السّطر التالي:

Port 22 

عند تغيير هذا الرقم إلى آخر بين 1025 و 65536 فإن خدمة SSH ستستخدم المنفذ الجديد للاتصال بالخادوم بدلا من المنفذ الافتراضي (22). يُحاول بعض المستخدمين غير المسموح لهم بالولوج استعمال منفذ SSH الافتراضي الوصول إلى الخادوم. تغيير المنفذ يعني إضافة خطوات جديدة أمام هذا النوع من المستخدمين لأنه يضطرهم إلى تجربة منافذ عديدة لمعرفة أيها يُستخدم من طرف SSH.

يجب عند تغيير منفذ SSH تذكر رقم المنفذ الجديد حتى يُمكن الاتصال عن بعد بالخادوم. سنُغيِّر منفذ SSH إلى 4444. يعني هذا أنه يتوجب إخبار الخادوم عند الاتصال برقم المنفذ المُستخدَم لكي لا يستخدم المنفذ الافتراضي، وهو ما سنشرحه لاحقا.

Port 4444 

تقييد ولوج المستخدم الجذر عبر SSH

بعد تغيير منفذ SSH نبحث عن السّطر التالي:

PermitRootLogin yes 

يُتيح هذا السطر إمكانية السماح للمستخدم الجذر أو منعه من الولوج عن طريق SSH. يُعتبَر هذا الإجراء أكثر أمانا حيثُ يمكن الولوج بالمستخدم العادي عن طريق SSH ثم استخدام صلاحيات المستخدم الجذر عن الحاجة.

نُغيّر السطر بإبدال yes ب no لمنع المستخدم الجذر من الولوج عن بعد.

PermitRootLogin no

يُنصَح دائما، من أجل أمان أكبر، بتقييد ولوج المستخدم الجذر عبر SSH.

بعد إنهاء التعديلات احفَظ الملف وأغلقه باستخدام الطريقة التي رأيناها سابقا (CTRL+X، ثم Y و ENTER بعد ذلك).

الخطوة السادسة - إعادة تحميل SSH

انتهينا الآن من تحرير الإعدادات. لأخذها في الاعتبار نُعيد تشغيل خدمة SSH عن طريق الأمر التالي:

service ssh restart 

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

يجب ذكر رقم منفذ الولوج إلى خادوم لا يستخدم المنفذ الافترضي للاتصال عن طريق SSH وذلك بإضافة العبارة "p 4444-" إلى أمر الاتصال حيثُ 4444 هو رقم المنفذ الجديد.

للولوج إلى الخادوم عن طريق المنفَذ الذي أعددناه في الخطوة السابقة نستخدم الأمر التالي (أبدِل SERVER_IP_ADDRESS بعنوان خادومك و demo باسم المستخدِم):

ssh -p 4444 demo@SERVER_IP_ADDRESS 

ملحوظة: لا تنسَ، إن كنت تستخدم برنامج PuTTY، تغيير إعداد المنفَذ في البرنامج حتى يتوافق مع الإعداد الحالي لخادومك.

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

sudo command_to_run 

حيثُ command_to_run هو الأمر المُراد تنفيذه.

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

exit 

ماذا بعد هذا الدرس؟

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

يُمكنك المُتابعة مع هذه السلسة بقراءة مقال خطوات إضافية موصى بها لخواديم أوبنتو 14.04 الجديدة الذي يشرح أمورا من قبيل تفعيل fail2ban للحد من فعاليّة هجمات القوة العمياء Brute force attacks، الإعدادات الأساسية للجدار الناري Firewall، بروتكول NTP وملفات الإبدال Swap. كما أنّ به روابطَ لشروح حول كيفية تثبيت وإعداد بعض تطبيقات الويب الشائعة.

مقالات مثل إعداد حِزم LAMP أو LEMP جيّدة لمن يُريد استكشاف المزيد.

ترجمة -وبتصرّف- للمقال: Initial Server Setup with Ubuntu 14.04 لصاحبه Justin Ellingwood.

مقدّمة

نظام أسماء الّنطاقات، بالإنجليزية Domain Name System ويُختصَر ب DNS، هو أحد أكثر مجالات إعداد المواقع والخواديم صعوبةً على المتعلمين. فهْم آلية عمل نظام أسماء النطاقات سيُساعدك في تشخيص مشاكل إعدادات النفاذ إلى مواقعك؛ كما أنه يمنحك فرصة التعمق في فهم كيف تجري الأمور خلف الكواليس.

سنتطرّق في هذا الدّليل إلى بعض المفاهيم الأساسية لنظام أسماء النّطاقات بحيثُ تُصبح جاهزا للعمل على إعدادات DNS لديك. يُفترَض - بعد قراءة هذا الدّليل - أن تكون لديك القدرة على إعداد اسم النطاق Domain name الذي تمتلكه على DigitalOcean أو ضبط خادومك الخاص لتشغيل DNS.

فلنبدأ بتعريف بعض المفاهيم الأساسية حول كيف يعمل النظام، قبل الشروع في إعداد خواديمك الخاصة لحل نطاقك أو ضبط نطاقاتنا في لوحة التحكّم.

مُصطلحات النطاق

يجب أولا البدء بتعريف المصطلحات التي سنستخدمها؛ فبالرغم من أن بعض المواضيع تبدو مألوفة في أُطُر مُغايِرة، إلا أن الكثير من العبارات المُستخدمة في إطار الحديث عن أسماء النطاقات ونظام DNS لا تظهر بكثرة أثناء التطرق لمجالات أخرى من الحوسبة.

فلنبدأ بالأبسط.

نظام أسماء النطاقات

نظام أسماء النطاقات المعروف اختصارًا ب"DNS" هو نظام التشبيك المُستخدَم لتحويل أسماء سهلة التذكّر إلى عناوين فريدة.

اسم النّطاق

اسم النّطاق هو الاسم سهل التذكر المستخدَم للرّبط بمورد على شبكة الإنترنت. على سبيل المثال، "google.com" اسمُ نطاق. سيقول بعض الأشخاص إن الجزء "google" هو اسم النطاق؛ ولكن يُمكننا على العموم الحديث على الصيغة المركّبة، أي "google.com" باعتبارها اسمَ النطاق.

المَسار "google.com" مرتبِط بالخواديم المملوكة لشركة Google. نظام أسماء النطاقات يُتيح لنا إمكانية الوصول إلى خواديم Google عند كتابة "google.com" في شريط عناوين المتصفّح.

عنوان IP

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

الإصدار الرّابع من عناوين IP - الأكثر استخدامًا والذي يُرمز له بIPv4 يُكتَب على شكل أربع مجموعات من الأعداد، تحوي كل مجموعة ثلاثة أرقام على الأكثر ويُفصَل بين المجموعات الأربع بنقطة. على سبيل المثال فإن "111.222.111.222" يمكن أن يكون عنوانَ IP صالحًا. نظام DNS يُترجِم اسمًا إلى هذا العنوان. بهذه الطّريقة لن تحتاج إلى حفظ مجموعة معقّدة من اﻷرقام لكل موقع توَدّ زيارته على الشبكة.

النطاق ذو المستوى العلوي Top-Level Domain

النطاق ذو المستوى العلوي (النطاق العلوي)، TLD اختصارًا، هو الجزء الأكثر شمولية من النطاق. النطاق العلوي هو القسم الموجود في أقصى يمين اسم النطاق (يُفصَل بين أجزاء اسم النطاق بنقطة). النطاقات العلوية المشهورة هي: "com"، و"net"، و"org"، و"gov"، و"edu"، و"io".

توجد النطاقات العلوية في أعلى التسلسل الهرمي لأسماء النطاقات؛ حيث تَمنح منظمة Internet Corporation for Assigned Names and Numbers (ICANN) - المختصّة بتوزيع عناوين IP وأسماء النطاقات - لبعض الجهات صلاحية التحكم بإدارة نطاقات علوية. يُمكن لهذه الجهات بعد ذلك توزيع أسماء نطاقات تابعة للنطاق العلوي الذي تديرُه، عن طريق مسجّل نطاقات Domain registrar عادةً.

المُضيف Host

لدى مالك النطاق القدرة على تعريف عدة مُضيفات داخل نطاقه. يُشير المُضيف إلى حاسوب أو خدمة مستقلة يُمكن الوصول إليها عن طريق النطاق. على سبيل المثال، يُتيح معظم أصحاب النطاقات إمكانية الوصول إلى خواديم الوب الخاصة بهم عن طريق النطاق "الحاسِر" example.com إضافة إلى تعريف المُضيف "www" (مثال: www.example.com).

يمكنك تعريف عدة مُضيفات أخرى داخل النطاق العام؛ فتَمنح الوصول إلى واجهة لبرمجة التطبيقات API عن طريق المُضيف "api" (api.example.com)، أو تعطِي إمكانية استخدام بروتوكول نقل الملفات FTP عن طريق تعريف مُضيف باسم "ftp" أو "files" (ftp.example.com أو files.example.com). لا يوجد تقييد على طول اسم المُضيف، التقييد الوحيد هو أن يكون فريدًا داخل النطاق.

النطاق الفرعي SubDomain

تحدثنا عن المُضيف في الفقرة السّابقة، في هذه الفقرة سنتطرّق لمفهوم ذي صلة به: النطاق الفرعي.

يعمل نظام DNS حسب تسلسل هرمي تتبع فيه عدة نطاقات للنطاقات العلوية. على سبيل المثال فإن النطاقين "google.com" و"ubuntu.com" يندرجان تحت النطاق العلوي "com". عند الحديث عن نطاق فرعي فالمقصود هو أي نطاق يُشكِّل جزءًا من نطاق أكبر. في المثال الذي ذكرناه يمكننا القول بأن "ubuntu.com" هو نطاق فرعي من "com". إجمالاً فإن"ubuntu.com" يُسمّى نطاقا، وبشكل أكثر تحديدًا فإن جزئية "ubuntu" تسمّى نطاقا من المستوى الثاني Second Level Domain، وتُختصَرب SLD.

إضافةً إلى ذلك، يمكن لكل نطاق التحكم في نطاقات تتبع له. هذه النطاقات هي ما يُطلق عليه نطاقات فرعية. على سبيل المثال يُمكنك إنشاء نطاق فرعي لقسم التاريخ في مدرستك www.history.school.edu. جزئية "history" هي النطاق الفرعي (على اعتبار أن school.edu هو النطاق التابع للمدرسة).

الفرق بين المُضيف والنطاق الفرعي هو أن المُضيف يُعرّف حاسوبًا أو خدمة، في حين أن النطاق الفرعي يُمدِّد النطاق الأب؛ أي أنه طريقة لتقسيم النطاق نفسِه.

يُمكن ملاحظة أن الجزء الموجود في أقصى يسارِ اسم النطاق، سواء تعلّق الأمر بمُضيف أو نطاق فرعي، هو الأكثر تحديدًا؛ هذه هي طريقة عمل نظام DNS: من الأكثر إلى الأقل تحديدًا، باتجاه القراءة من اليسار إلى اليمين.

اسم النطاق المعرَّف بالكامل Fully Qualified Domain Name

اسم نطاق معرَّف بالكامل، FQDN اختصارًا، هو ما يُطلق عليه اسم نطاق مُطلَق. في نظام DNS يُمكن إعطاء اسم نطاق بالنسبة إلى نطاق آخر، وهو ما قد يؤدي إلى بعض الالتباس. اسم النطاق المعرَّف بالكامل FQDN هو اسم مُطلق يحدّد النطاق انطلاقًا من أصل نظام أسماء النطاقات.

يعني هذا أن FQDN يُحدد أسماء كل النطاقات التي يتفرّع منها النطاق بما فيها النطاق العلوي TLD. ينتهي اسمُ النطاق المعرَّف بالكامل بنقطة تُشير إلى النقطة الأعلى في التسلسل الهرمي لنظام DNS. النطاق ".mail.google.com" هو نطاق معرَّف بالكامل. النقطة الأخيرة غير ضرورية في بعض البرمجيات التي تتعامل مع FQDN؛ ولكنها مطلوبة للتوافق مع معايير ICANN.

خادوم الأسماء Name server

خادوم الأسماء هو حاسوب مخصَّص لترجمة أسماء النطاقات إلى عناوين IP. تقوم هذه الخواديم بالجزء الأكبر من العمل في نظام DNS. بما أن مجموع عمليات الترجمة من أسماء نطاقات إلى عناوين IP أكثر بكثير من أن يقوم به خادوم أسماء واحد فإن كل واحد من هذه الخواديم يُمكن أن يُعيد توجيه الطّلبات التي تصله إلى خواديم أخرى أو أن يُفوِّض إدارة مجموعة من النطاقات الفرعية التي هو مسؤول عنها.

خواديم الأسماء يمكن أن تكون "ذات سلطة" Authoritative، بمعنى أنها تعطي إجابات عن نطاقات تقع ضمن مسؤوليتها. ما عدا ذلك فإنها تُشير إلى خواديم أخرى أو تُجيب بنسخ تخبِّئها من بيانات خواديم أسماء أخرى.

ملف النطاق Zone file

ملف النطاق هو ملف نصي بسيط يحوي الترجمات بين أسماء النطاقات وعناوين IP؛ هذه هي الوسيلة التي يعرِف عن طريقها نظام DNS أي عنوان IP يجب الاتصال به عند طلب اسم نطاق معيَّن.

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

السّجلّات Records

يُخزّن ملف النطاق المعلومات ضمن سجلات. في شكله الأبسط، السجل هو ترجمة وحيدة لمورِد (مضيف أو نطاق فرعي) واسْم. يُمكن أن يكون السّجل ترجمة لاسم نطاق إلى عنوان IP، أو تعريفًا لخواديم الأسماء المسؤولة عن نطاق، أو تعيينًا لخواديم بريد النطاق، ... إلخ.

كيف يعمل نظام أسماء النّطاقات

بعد الاطّلاع على بعض المُصطلحات المستخدمة في نظام DNS، سنتطرّق للسؤال: كيف يعمل فعلًا نظام DNS؟

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

خواديم الجذرRoot servers

نظام DNS - كما ذكرنا سابِقًا - مُصمّم ليعمل حسب تسلسل هرمي. في أعلى هذا التسلسل يوجد ما يُعرف بخواديم الجذر. تُشغَّل هذه الخواديم من طرف عدّة منظمات، بتفويض من ICANN.

يعمل في الوقت الحالي 13 خادومًا جذرًا.. من ناحية ثانية ونظرًا للعدد الهائل من طلبات ترجمات النطاقات في كل دقيقة، فإن كل واحد من هذه الخواديم معكوس mirrored (جميع العمليات والبيانات مكرّرة على خواديم أخرى).يشترك كل خادوم جذرفي نفس عنوان IP مع خواديمه المعكوسة. عند طلب أحد خواديم الجذر يُمرَّر الطّلب إلى مرآة Mirrorخادوم الجذر الأقرب من المُرِسل.

ما العمل الذي تقوم به خواديم الجذر؟ تتعامل خواديم الجذر مع طلبات المعلومات عن نطاقات المستوى العلوي، فعند وصول طلب لا يُمكن لخادوم أسماء من مستوى أدنى التعامل معه؛ يُرسَل طلب إلى خادوم جذر للاستفسار عن النطاق.

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

في المحصّلة: عند إرسال طلب لعنوان "www.wikipedia.org" إلى خادوم جذر فإنه سيُجيب بعدم توفر نتائج في سجلاته تُوافق "www.wikipedia.org" وذلك بعد بحث في ملفات النطاق التي يحتفظ بها؛ ولكنه سيجد سجلًا للنطاق العلوي "org" ويُعطي لمُرسِل الطّلب عنوانَ خادوم الأسماء المسؤول عن عناوين "org".

خواديم النّطاقات العليا TLD Servers

بعدها يقوم مُرسِل الطّلب بتوجيه طلب جديد إلى عنوان خادوم الأسماء الذي زوّده به الخادوم الجذر. خادوم الأسماء هذا هو المسؤول عن النطاق العلوي الموجود في الطّلب. يقوم المرسِل بعدها ببعث طلب إلى خادوم الأسماء المسؤول عن النطاق العلوي "org" لسؤاله ما هو عنوان "www.wikipedia.org". يجيب خادوم الأسماء - بعد بحث عن "www.wikipedia.org" في ملفات النطاق الخاصة به - بعدم وجود هذا النطاق في ملفاته. غير أنه يعثر على السجل الذي يحوي اسم الخادوم المسؤول عن النطاق "wikipedia.org". لقد اقتربنا كثيرًا من الإجابة التي نبحث عنها.

خواديم الأسماء على مستوى النّطاق Domain-Level name server

حصل مُرسِل الطّلب الآن على عنوان IP الخاص بخادوم الأسماء المسؤول عن معرفة العنوان الفعلي للهدف. من جديد، يبعث مُرسِل الطلب إلى خادوم الأسماء لسؤاله إن كان يستطيع ترجمة "www.wikipedia.org" إلى عنوان IP.

يبحث خادوم الأسماء على مستوى النطاق في ملفات النطاق لديه ويعثر على ملف نطاق يتعلق ب"wikipedia.org". داخل هذا الملف يوجد سجل عن مُضيف باسم "www". في هذا السّجل يوجد عنوان IP الذي يقع عليه المضيف. يبعث خادوم الأسماء بالإجابة النهائية إلى مُرسِل الطلب.

ما هو خادوم الأسماء الحالّ Resolving name server؟

في السيناريو أعلاه تحدثنا عن "مُرسِل طلب". ما المقصود ب"مرسِل الطلب" في هذه الحالة؟

مرسِل الطّلب هو في الغالب ما نسميه "خادوم أسماء حالّ" Resolving name server. خادوم أسماء حالّ هو خادوم مُعَد لإرسال الطّلبات إلى خواديم أسماء أخرى؛ أي أنه في الأساس وسيط يلجأ إليه المستخدِم. هذا الوسيط يُخبِّئ نتائجَ طلبات سابقة لتحسين سرعة الإجابة، كما أنه يعرف عناوين خواديم الجذر مما يمكّنه من "حل" resolving الطّلبات التي ليست لديه معرفة بنتائجها.

يوجد لدى المستخدم غالبًا عدة خواديم أسماء حالّة مضبوطة، آليًا أو يدويًا، في نظام التشغيل لديه. يوفّر مزوّدو خدمة الإنترنت Internet Service Profider, ISP عادة خواديم أسماء حالّة. بعض المنظمات الأخرى تقوم بنفس الشيء. Google على سبيل المثال تُقدّم خواديم DNS حالّة يُمكنك إرسال الطلبات إليها.

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

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

ملفّات النطاق

تطرّقنا في آلية العمل المذكورة أعلاه إلى "ملفات النطاق" و"السجلّات".

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

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

يصف ملف النطاق "منطقة" من نظام DNS؛ أي مجموعة فرعية من كامل نظام الأسماء DNS، ويُستخدم عادةً لضبط نطاق واحد فقط حيث يمكن أن يحوي مجموعة من السجلّات تعرّف بمواقع موارد النطاق محل التعريف. يعرّف المُعطى Parameter $ORIGIN افتراضيًا المُستوى الأعلى لسلطة ملف النطاق.

لنأخذ مثالًا لملف نطاق مُستخدَم لإعداد النطاق "example.com". في هذا المثال ORIGIN$ سيكون مضبوطًا على ".example.com". هذا الإعداد إما أن يكون في أعلى ملف النّطاق أو في ملف إعداد خادوم DNS الذي يُحيل إلى ملف النطاق. في كلتا الحالتين فالمُعطى يصف المنطقة التي ستكون لديه السلطة عليها.

بشكل مشابِه، المُعطى TTL$ يضبط "عُمر" Time to live المعلومة التي يوفرها ملف النطاق. هذا المُعطى هو مؤقِّت يُمكن لخادوم أسماء يستعمل التخبئة Caching الاستعانة به للإجابة على طلبات سبق له الحصول على نتائجها دون إعادة البحث وذلك حتى انقضاء قيمة TTL.

أنواع السجلّات

يمكن أن توجد عدة أنواع من السجلّات في ملف النّطاق. في ما يلي سنستعرض بعض الأنواع الشّائعة (أو الإلزامية).

سجلاّت بداية السّلطة Start of Authority

سجل بداية السلطة، SOA اختصارًا، هو سجل إلزامي في كل ملفات النطاق. يجب أن يكون أولَ سجل فعلي في الملف (يُمكن لكل من ORIGIN$ و TTL$ أن يسبقه في الملف)، كما أنه الأكثر تعقيدًا.

يأخذ سجل SOA الشكل التالي:

domain.com. IN SOA ns1.domain.com. admin.domain.com. (

12083 ; serial number

3h ; refresh interval

30m ; retry interval

3w ; expiry period

1h ; negative TTL

) 

فلنشرح دلالة كل جزء من السجل:

• .domain.com: هذا هو المستوى الأعلى في النطاق (جذر النطاق). يعني هذا الجزء أن الملف يتعلق بالنطاق .domain.com؛ قد تجد مكانه علامة @ التي هي مجرَّد ماسك مكان Placeholder يحل محل محتوى المُعطَى ORIGIN$ الذي تحدّثنا عنه سابقًا.
• IN SOA: تعني IN هنا إنترنت (ستتكرّر في عدة سجلّات)، أما SOA فيُشير لنوعية السجل (بداية سلطة).
• .ns1.domain.com: هنا نعرِّف خادوم الأسماء الرئيس الأولي للنطاق. خواديم الأسماء إما أن تكون رئيسة Master أو تابِعة Slave. إذا كان نظام DNS معدًّا ليعمل ديناميكا (تحديث السجلات يتم دون تدخل يدوي)- كما هي الحال هنا - فيجب أن يوجد خادوم "رئيس أولي" Primary master. في حال عدم ضبط DNS للعمل بشكل ديناميكي فهذا الخادوم هو أحد خواديم الأسماء الرئيسة.
• .admin.domain.com: عنوان البريد الإلكتروني للمسؤول عن النطاق. هنا أُبدِلت علامة "@" بنقطة في العنوان البريدي (admin@domain.com). إذا كان العنوان البريدي يحوي نقطة فيجب إبدالها ب"\" (your.name@domain.com تُصبح your\name.domain.com).
• 12083: هذا هو الرقم التسلسلي Serial number لملف النطاق. يجب زيادة هذا الرقم في كل مرّة يُعدَّل فيها على ملف النطاق حتى ينتشر ملف النطاق بشكل صحيح، حيثُ إن الخواديم التابعة تتحقق ما إذا كان الرقم التسلسلي الموجود في ملف النطاق لدى الخادوم الرئيس أكبرَ من الرّقم التسلسلي الموجود لديها. إن كان الأمر كذلك فإنها تطلب ملف النطاق الجديد وإلا تستمر في استخدام الملف الموجود لديها.
• 3h: فترة التجديد Refresh interval باالنسبة للنطاق (3 ساعات في المثال)، أي المدة الزمنية التي يقضيها الخادوم التابِع قبل إرسال استفسار إلى الخادوم الرّئيس عن تغييرات على ملف النطاق.
• 30m: فترة إعادة المحاولة Retry interval باالنسبة للنطاق (30 دقيقة في المثال هنا). في حال عدم قدرة الخادوم التابع على الاتصال بالخادوم الرئيس عند انقضاء فترة التجديد فإنه ينتظر مدةً مساوية لفترة إعادة المحاولة قبل إعادة محاولة الاتصال.
• 3w: مدة انتهاء الصلاحية Expiry period. إن لم يستطع الخادوم التابِع الاتصال بالخادوم الرئيس خلال هذه المدة (في المثال هنا 3 أسابيع) فإنه يتوقّف عن إرسال إجابات تتعلَّق بهذا النطاق.
• 1h: عمر المعلومة السّالب Negative TTL. مُماثل لمعطى TTL$ الذي تحدّثنا عنه مع فرق أنه يُلجأ إليه في حال عدم وجود المعلومة المبحوث عنها. بمعنى أخر: عند وصول طلب عن عنوان اسم غير موجود في الملف لدى الخادزم والإجابة أنه غير موجود فإن أي طلب عن الاسم مجدّدا سيُرد عليه بأنه غير موجود وذلك مدة ساعة (في المثال هنا) قبل البحث عنه مرة أخرى.

ملحوظة: النص الموجود بعد النقطة-الفاصلة ";" على نفس السطر تعليق ولا يدخُل في إطار الإعدادات.

سجلات A و AAAA

يستعمل السّجلّان A و AAAA لتعيين مضيف إلى عنوان IP. يُستخدَم السجل "A" لتعيين مضيف إلى عنوان IP من الإصدار الرابع IPv4 بينما يُستخدَم السجل "AAAA" لتعيين مضيف إلى عنوان IP من الإصدار السّادس IPv6.

تأتي الهيئة العامة لهذه السجلات على الشكل التالي:

host IN A IPv4_address
host IN AAAA IPv6_address 

رأينا أن السجل SOA يستدعي خادومًا رئيسًا أوليًا باسم "ns1.domain.com"؛ سيتوجّب علينا إذن تعيين عنوان IP ل"ns1.domain.com" نظرًا لأنه يقع ضمن النطاق الذي يُعرِّفه هذا الملف.

يأخذ هذا السجل الشكل التالي:

ns1 IN A 111.222.111.222 

لاحِظ أنه لا يتوجَّب علينا هنا ذكر اسم النطاق كامِلًا، يكفينا ذكر اسم المُضيف فقط دون اسم النّطاق المعرَّف بالكامل (FQDN) وسيُكمل خادوم الأسماء الباقي عن طريق قيمة المُعطى ORIGIN$. مع ذلك يُمكننا استخدام FQDN إذا ارتأينا أن لذلك دلالة أكبر:

ns1.domain.com. IN A 111.222.111.222 

في الغالب هذا هو المكان الذي سنعرّف فيه خادوم الوب "www":

www IN A 222.222.222.222 

ستوجب علينا أيضًا ذكر العنوان الذي يُحيل إليه النطاق الأصلي، كما يلي:

domain.com. IN A 222.222.222.222 

كما يُمكن استخدم علامة "@" لتحل محل اسم النطاق الأصلي (domain.com):

@ IN A 222.222.222.222 

يوجد أيضًا خيار "*" لتعيين أي شيء يقع في النطاق - ولم يُذكَر تعريفه في الملف - إلى عنوان IP محدّد (خادوم الوب في مثالنا هنا):

* IN A 222.222.222.222 

كل ما ذُكِر في الفقرات السابقة يعمل بالنسبة للإصدار السادس من عناوين IP (IPv6) مع إبدال A بAAAA.

سجلّات CNAME

السجلّات من نوع CNAME تُعرِّف كُنية Alias للاسم المُتعارَف عليه Canonical name لخادومك (الأسماء المُعرَّفة في سجلات A أو AAAA). على سبيل المثال، يُمكّننا سجل A من تعريف مُضيف باسم "server1" ثم استخدام كُنية "www" للإحالة لهذا المُضيف:

server1 IN A 111.111.111.111
www IN CNAME server1 

من الجيّد الانتباه إلى أن استخدام الكُنيات يؤدي إلى التقليل من الأداء نظرًا لأنها تحتاج إلى استعلام إضافي إلى الخادوم. يُمكِن الحصول على نفس النتيجة - في الغالب - عن طريق إضافة سجلات من نوع A أو AAAA. الحالة التي يُنصَح فيها بسجل من نوع CNAME هي إتاحة كُنية لمورِد خارج النطاق الحالي.

سجلّات MX

تُستَخدم سجلّات MX (اختصار ل Mail eXchange، تبادُل البريد) لتعريف تعاملات البريد الإلكتروني داخل النّطاق. يُساعد هذا الأمر على وصول الرسائل إلى خادوم البريد بشكل صحيح.

عكسَ الأنواع اﻷخرى، لا تُعيِّن السجلّات من نوع MX غالبًا مُضيفًا إلى شيء آخر (عنوان IP أو سجل). السّبب أن تعريفها ينطبق على كامل النّطاق. على هذا الأساس تأخذ غالبًا الشكل التالي:

IN MX 10 mail.domain.com. 

لاحِظ ألّا وجودَ لاسم مضيف في بداية السّجل.

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

يجب أن يُشير سجل MX - في الحالة العامة - إلى مضيف مُعرَّف عن طريق سجل A أو AAAA، لا سجل CNAME.

إذا كان لدينا خادوما بريد فإن تعريف السجلاّت سيكون على النحو التالي:

IN MX 10 mail1.domain.com.

IN MX 50 mail2.domain.com.

mail1 IN A 111.111.111.111

mail2 IN A 222.222.222.222

في هذا المثال، المُضيف "mail1" هو المُفضَّل كخادوم لتبادل البريد الإلكتروني.

الكتابة التالية مكافئة للكتابة السّابقة :

IN MX 10 mail1

IN MX 50 mail2

mail1 IN A 111.111.111.111

mail2 IN A 222.222.222.222 

سجلّات NS

تُعرِّف السجلّات من نوع NS (اختصار لName Server، خادوم الأسماء) خواديم الأسماء المُستخدمة في النطاق.

قد تطرح السؤال "إذا كان ملف النطاق موجودًا على خادوم الأسماء فلماذا يحتاج الخادوم لتعريف نفسه؟". أحد العناصر المهمة وراء نجاح نظام DNS هو المستويات المتعدّدة للتخبئة في هذا النظام. بالنسبة لتعريف خادوم الأسماء في ملف النطاق فأحد الأسباب هو أن هذا الملف قد يكون معروضًا من نسخة مخبَّأة موجودة على خادوم أسماء آخر. توجد أسباب أخرى لتعريف خادوم الأسماء في ملف النطاق الموجود عليه ولكن نكتفي بالسبب المذكور دون الدّخول في التفاصيل.

مثل السجلّات من نوع MX، ينطبق تعريف سجلّات NS على كامل النّطاق، لذا لا تظهر أسماء مضيفات في هذا السجّل. الشكل العام لسجل NS هو كالتالي:

IN NS ns1.domain.com.
IN NS ns2.domain.com. 

ينبغي وجود خادومَيْ أسماء على الأقل معرَّفيْن في كل ملف نطاق حتى يعمل النظام بشكل صحيح في حال حصول مشكل مع أحد الخادوميْن. تعتبرأغلب برامج خواديم DNS ملف النطاق غيرَ صالح إذا كان يعرف خادوم أسماء واحدًا فقط.

كالعادة، ضمِّن تعيين المضيفات عبر سجلّات A أو AAAA:

IN NS ns1.domain.com.

IN NS ns2.domain.com.

ns1 IN A 111.222.111.111

ns2 IN A 123.211.111.233 

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

خاتمة

من المفروض أن يكون لديك الآن إدراك جيّد لكيفية عمل نظام DNS. على الرّغم من أن الفكرة العامة للنظام سهلة الفهم نسبيا لمن ألِف طريقة عمله، إلا أنها تبقى أمرًا يواجه مديرو الأنظمة - من غير ذوي الخبرة - بعضَ الصّعوبة في تنفيذه.

ترجمة -وبتصرّف- للمقال: An Introduction to DNS Terminology, Components, and Concepts

مقدِّمة

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

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

كل بيئة العمل على نفس الخادوم

في هذا الإعداد توجد جميع مكوّنات بيئة العمل على خادوم واحد. إذا أخذنا مثال تطبيق ويب بهذا الإعداد، فإن خادوم الويب، وخادوم التطبيق وخادوم قاعدة البيانات توجد كلّها على نفس الخادوم. أحد أكثر هذا الإعداد شيوعا هو تنصيب حِزم LAMP: نظام تشغيل Linux، وخادوم ويب Apache، وقاعدة بيانات MySQL ولغة البرمجة PHP؛ الجميع على نفس الخادوم.

حالات الاستخدام

• مناسِب لتنصيب تطبيق بشكل سريع، فهو أبسط إعداد ممكن. ولكن يعيبُه محدودية قابليته للتمدّد وعدم عزل مكوّّنات بيئة العمل عن بعضها.

الإيجابيات

• البساطة

السّلبيات

• يتزاحم كل من التطبيق وقاعدة البيانات - في هذا الإعداد - على نفس الموارد (وحدة المُعالجة CPU، والذاكرة Memory، وحدات الإدخال والإخراج I/O، ...إلخ) مما يتسبب في رداءة الأداء. علاوةً على ذلك يصعُب تحديد مصدَر رداءة الأداء، هل هو التطبيق أم قاعدة البيانات.
• صعوبة التمدّد أفقيا Horizontal scaling.

ملحوظة: المقصود بالتمدّد الأفقي هو استعمال عدة خواديم وتشغليها بحيث تظهر وكأنها خادوم واحد، أما التمدّد العمودي Vertical scaling فيُقصَد به إضافة موارد جديدة لنفس الجهاز (زيادة حجم ذاكرة الوصول العشوائي RAM على سبيل المثال). لا يحتاج التمدّد الأفقي في الغالب لإعادة تشغيل الجهاز أو الخادوم.

خادوم قاعدة بيانات منفصِل

يُمكِن فصل نظام إدارة قواعد البيانات (Database management system, DBMS) عن بقية بيئة العمل، وذلك للحد من التزاحم على الموارد بين التطبيق وقاعدة البيانات. إضافة إلى ذلك، فإن نقل خادوم قاعدة البيانات من الشبكة العمومية أو من المنطقة منزوعة السّلاح DMZ (طريقة لتمكين المستخدمين في الشبكة الخارجية من الوصول إلى بعض الخدمات الموجودة في الشبكة المحلية) يزيدُ من أمان بيئة العمل.

حالات الاستخدام

• مناسِب لتنصيب تطبيق بشكل سريع مع التخلص من تنازع الموارد بين التطبيق وقاعدة البيانات.

الإيجابيات

• لا وجود لتنازع الموارد (وحدة المُعالجة، والذاكرة، وحدات الإدخال والإخراج I/O، ...إلخ) بين مستوى التطبيق ومستوى قاعدة البيانات
• يُمكِن تمديد أي من المستوَييْن (التطبيق وقاعدة البيانات) أفقيًّا حسب الحاجة وبشكل مستقِل عن الآخر.
• زيادة الأمان بنقل قاعدة البيانات من المنطقة منزوعة السّلاح (حسب إعدادات الشبكة).

السّلبيات

• أكثر صعوبة - بقليل - من إعداد بخادوم واحد.
• قد تظهر بعض المشاكل في الأداء إذا كان زمن الوصول Latency بين الخادومين مُعتَبرا (في حال تواجد الخادومين في مكانيْن منفصليْن جغرافيا على سبيل المثال) أو إذا كان عرض الموجة Bandwidth لا يُناسِب حجم البيانات المتبادلة.

دروس متعلِّقة

• كيفية إعداد قاعدة بيانات عن بُعد لتحسين أداء موقع يستخدِم MySQL (المقال الثّالث في هذا المشروع).

موزِّع حِمل Load Balancer (وسيط عكسي Reverse proxy)

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

• أمثلة على برامج تعمل كوسيط عكسي لتوزيع الحِمل (Load balanicig): Varnish و Nginx وHAProxy.

حالات الاستخدام

• بيئات العمل التي تتطلَّب التمدّد أفقيًّا.

الإيجابيات

• سهولة إضافة خواديم جديدة (التمدّد الأفقي).
• يُساعِد على التصدي للهجمات المُوَزَّعة لحجب الخدمة (Distributed Denial Of Service, DDOS).

السّلبيات

• قد يُصبِح موزع الحِمل نفسه عقبة في وجه الأداء إن لم يمتلِك الموارد الكافية أو إن أُعِدَّ بطريقة غير جيّدة.
• تُضيف وجود موزِّع حِمل اعتبارات جديدة ربّما تزيد من التعقيد، مثل الانتقال من اتصال معمّى Encrypted إلى آخر غير معمَّى أو التعامُل مع التطبيقات التي تتطلّب جلسات متماسِكة Sticky sessions (في الجلسات المُتماسِكة تُربَط الاستعلامات القادِمة من جلسة المستخدِم بنفس الخادوم، ممّا يعني أن حِمل الاستعلامات القادِمة من هذا المُستخدِم لا يُوزَّع بين الخواديم).

مسرِّع HTTP (وسيط عكسي مُخبِّئ Caching Reverse Proxy)

يُلجَأ لمسرِّع HTTP (يُسمَّى أيضًا وسيطا عكسيا مُخبئا لطلبات HTTP) للتقليل من المدة اللازمة لتقديم المُحتوى إلى المستخدِم عبر مجموعة متنوِّعة من التقنيات. التقنية الرئيسة هي الاحتفاظ في الذّاكرة بإجابات الاستعلامات المُتلقاة من خادوم ويب أو تطبيق؛ مما ينتُج عنهُ سُرعة حصول الطّلبات المُحتفَظ بها (المُخبَّأة Cached) على الإجابة، مع التّقليل من التفاعل غير الضّروري مع خادوم الويب أو التّطبيق.

• أمثلة على برامج تستطيع العمَل مسرّعاتHTTP:برنامج Varnish، وSquid وNginx.

حالات الاستخدام

• مُناسِب لتطبيقات الويب الديناميكية ذات المحتوى الضخم أو التي تقرأ من ملفات مُشترَكة عديدة.

الإيجابيات

• الرّفع من الأداء بالتقليل من حِمل العمل على وحدة المُعالجة في خادوم الويب واللجوء إلى التخبئة والضغط Compression.
• بالإمكان استخدامُه كموزِّع حِمل (وسيط عكسي).
• تُساعِد بعض برامج التخبِئة في الحد من الهجمات المُوَزَّعة لحجب الخدمة.

السلبيات

• يحتاج إلى ضبط المُسرِّع بطريقة تضمن الحصول على أفضَل أداء.
• يقِل الأداء في حال انخفاض نسبة إصابة التخبِئة Cache-hit، أي نسبة الطّلبات المُحتفَظ بإجاباتِها في ذاكرة التخبِئة.

مُضاعفة قاعدة البيانات بهيئة رئيس-تابِع Master-Slave

تُستخدم مُضاعفة قاعدة البيانات بهيئة رئيس-تابِع لتحسين أداء قواعد البيانات التي تُجري عمليات قراءة كثيرة مقارنة بغمليات الكتابة، كما هو الحال في نُظم إدارة المُحتوى Content managment systems, CMS. يوجد في هذه الحالة قاعدة بيانات رئيسة واحدة إضافةً لقاعدة بيانات تابِعة أو أكثر. عند تحديث قاعِدة البيانات يُرسَل الطّلب إلى قاعدة البيانات الرئيسة، أما عند القراءة فإنه بالإمكان توزيع الطّلب بين قواعد البيانات التابعة.

حالات الاستخدام

• هذا الإعداد جيّد لتحسين أداء جانب قاعدة البيانات من التّطبيق.
• في الشكل أدناه مثال على مُضاعفة قاعدة البيانات بهيئة رئيس-تابِع يوجد به قاعدة بيانات تابِعة واحدة:

الإيجابيات

• يزيد من الأداء في القراءة من قاعدة البيانات عن طريق توزيع العملية بين مختَلف التوابع.
• يُمكن أن يُحسِّن من الأداء في الكتابة بحصر قاعدة البيانات الرئيسة في الكتابة فقط، فلا يستغرق الخادوم الرئيس أي وقت في الإجابة على طلبات القراءة.

السلبيات

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

مثال: تجميع المفاهيم

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

سنفترض أنّ موزّع الحمل مضبوط للتعرّف على المحتوى السّاكن (مثل الصوّر، وملفات CSS و Javascript، ...إلخ) وإرسال الطّلبات لهذا المُحتوى إلى خواديم التخبئة. بالنسبة لبقية الطّلبات فإنه يُرسِلها إلى خواديم التطبيق.

عند طلب محتوى ديناميكي فإن ما يحدُث هو التّالي:

1. يطلُب المستخدِم محتوى ديناميكيا من http://example.com، يتلقى مُوزّع الحِمل الطّلب.
2. يُمرِّر موزِّع الحِمل الطّلب إلى المُنتهي الخلفي للتطبيق Application Backend.
3. يجلب المُنتهي الخلفي المحتوى المطلوب من قاعدة البيانات ويُرسِله إلى موزِّع الحِمل.
4. يُمرِّر موزّع الحمل المحتوى المطلوب إلى المستخدِم.

بالنسبة للمحتوى السّاكن فإن الخطوات تكون كالتالي:

1. يتعرّف موزِّع الحِمل على المحتوى السّاكِن ثم يتحقق من وجود المحتوى المطلوب لدى خادوم التخبِئة (إصابة التخبِئة) أو عدمه (تفويت التخبِئة Cache-miss).
2. في حال إصابة التخبِئة: يُرسِل خادوم التخبِئة المحتوى المطلوب إلى موزِّع الحِمل؛ نُكمِل مع الخطوة 6. في حال تفويت التخبِئة يعيد خادوم التخبِئة الطّلب إلى موزِّع الحِمل.
3. يُمرِّر موزِّع الحِمل الطّلب إلى المُنتهي الخلفي للتطبيق.
4. يجلب المُنتهي الخلفي المحتوى المطلوب من قاعدة البيانات ويُرسِله إلى موزِّع الحِمل.
5. يُمرِّر موزِّع الحِمل الطّلب إلى خادوم التخبِئة الذي يحتفِظ بنسخة من الطّلب والإجابة ثم يُعيده إلى موزِّع الحِمل.
6. يُمرِّر موزّع الحمل المحتوى إلى المستخدِم.

تُوفّر بيئة العمل أعلاه كل فوائد الإعدادات المذكورة في هذا الشّرح من ناحية الثبات والأداء، ولكنْ لديها نقطتا ضعف: موزِّع الحمل وقاعدة البيانات الرئيسة.

خاتمة

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

ترجمة -وبتصرّف- للمقال: 5 Common Server Setups For Your Web Application