محمد أحمد العيل

يُواجه الكثير من مستخدمي Linux الجدُد مشكلة العثور على الملفّات الّتي يبحثون عنها على أجهزتهم. يَعرض هذا الدّرس لكيفيّة استخدام أمر find، ممّا يُساعد في البحث عن الملفّات على Linux عن طريق مُرْشِحات Filters ومُعاملات عدّة. سنتطرّق أيضًا لأمر locate وهو طريقة أخرى للبحث عن الملفّات. البحث عن ملفّ باسمهالطّريقة البديهيّة للبحث عن الملفّات هي استخدام أسمائها. للعثور على ملفّ باسمه أدخِل الأمر التّالي: find -name query حيث query هي عبارة البحث، الّذي سيفرّق عند استخدام خيّار name- بين حالة الأحرف (كبيرة Upper case أو صغيرة Lower case). يعني هذا أنّ البحث عن file سيُعطي نتائج مختلفة عن البحث عن File. ملحوظة: عند عدم ذكر مجلّد للبحث فيه، فإنّ أمر find يبحث في مجلّد العمل. للبحث عن ملفّ باسمه دون أخذ حالة الأحرف في الحسبان نستخدِم خيّار iname-. find -iname queryإن كنت تريد العثور على كل الملفّات الّتي لا تُوافق نمطًا Pattern مُحدّدًا، يُمكنك عكس البحث باستخدام ! أو not-. في حال استخدام ! فيجب تخليصها Escape حتّى لا يُحاول سطرُ الأمر تفسيرها قبل بدْء عمل find. find -not -name query_to_avoidأو find \! -name query_to_avoidحيثُ query_to_avoid هي عبارة البحث الّتي نُريد تجنب وجودها في اسم الملفّ. العثور على ملفّ بنوعه Typeتوجد أيضًا إمكانيّة البحث عن ملفّات حسب نوعها. يُستخدَم خيّار type-. آليّة العمل هي كالتّالي: find -type type_descriptor queryحيث type_descriptor مُعطًى يصِف نوع الملفّ. يُمكن أن يأخذ هذا المُعطى القيّم التّاليّة: f: ملفّ عادي، d: مُجلّد، l: وصلة رمزيّة، c: جهاز مِحرفي Character device، b: جهاز كُتلي Block device. يبحث الأمر التّالي، مثلًا، عن كلّ الأجهزة المِحرفيّة الموجودة في النّظام: find / -type cمثال على النّتيجة: /dev/parport0 /dev/snd/seq /dev/snd/timer /dev/autofs /dev/cpu/microcode /dev/vcsa7 /dev/vcs7 /dev/vcsa6 /dev/vcs6 /dev/vcsa5 /dev/vcs5 /dev/vcsa4 . . . إذا أردنا البحث عن كلّ الملفّات ذات اللّاحقة conf. فيُمكننا ذلك باستخدام الأمر: find / -type f -name *.confملحوظة: في الأمر السّابق حدّدنا مكان البحث بالمجلّد الجذر /. إن أردنا أن يكون البحث مقتصِرًا على مجلّد معيَّن نُضيف مساره مباشرةً بعد الأمر. النّتيجة: /var/lib/ucf/cache/:etc:rsyslog.d:50-default.conf /usr/share/base-files/nsswitch.conf /usr/share/initramfs-tools/event-driven/upstart-jobs/mountall.conf /usr/share/rsyslog/50-default.conf /usr/share/adduser/adduser.conf /usr/share/davfs2/davfs2.conf /usr/share/debconf/debconf.conf /usr/share/doc/apt-utils/examples/apt-ftparchive.conf . . . ترشيح المُخرجات حسب التّاريخ والحجميُتيح أمر find ترشيح النّتائج حسب التاريخ والحجم. الحجميُستخدَم خيّار size- لترشيح نتائج البحث حسب الحجم. نُضيف لاحقة للقيمة المعطاة لتحديد الوحدة المُستخدَمة. في ما يلي بعض الخيّارات المُنتشرة: c: بايت Byte،k: كيلوبايت Kilobytes،M: ميغابايت Megabytes،G: غيغابايت Gigabytes،b: كتلة بحجم 512 بايت.للبحث عن كلّ الملفّات ذات الحجم المُساوي ل50 بايت بالضّبط: find / -size 50cللبحث عن الملفّات الّتي يقلّ حجمها عن 50 بايت نستخدم الصّيغة التّاليّة (لاحظ علامة - أمام 50c ): find / -size -50cبالنّسبة للملفّات ذات الحجم الأكبر من 700 ميغابايت فالأمر يكون على النّحو التّالي (لاحِظ علامة +): find / -size +700Mالتّاريخيُخزِّن لينوكس بياناتٍ عن تواريخ الوصول Access time، تواريخ التّعديل Modification وتواريخ التّبديل Change: تاريخ الوصول: آخر مرّة قُرئ من الملفّ أو كُتب فيه.تاريخ التّعديل: آخر مرّة عُدِّل فيها على محتوى الملفّ.تاريخ التّبديل: آخر مرّة غُيّرت فيها البيانات الوصفيّة Meta-data المُتعلّقة بوضع الملفّ ضمن نظام الملفّات.تُوفّر خيّارات atime ، -mtime-، وctime- إمكانيّة ترشيح نتائج البحث حسب هذه التّواريخ. ولتحديدٍ أدقّ نستخدم علامتيْ + و- الّلتان تعنيان على التّوالي قبل وبعد. تُمثّل قيمة هذه المعطيات عدد الأيّام التي نُريد البحث فيها. الأمر التّالي يبحث عن الملفّات الّتي عُدِّل على محتواها في آخر يوم: find / -mtime 1إن أردنا البحث عن الملفّات المقروءة في مدّة أقلّ من يوم ننفّذ الأمر التّالي (الملفّات المقروءة منذ يوم بالضّبط لن تظهر في النّتائج): find / -atime -1للبحث عن الملفّات الّتي غُيّر في بياناتها الوصفيّة قبل ثلاثة أيّام (الملفّات المُغيّر فيها قبل يوم أو اثنين لن تظهر في النّتائج): find / -ctime +3توجد أيضًا خيّارات بديلة للبحث حسب الدّقائق وليس الأيّام: find / -mmin -1يبحث الأمر أعلاه عن الملفّات الّتي عُدِّل على محتواها في آخر دقيقة. يُمكِن أيضًا أخذُ ملفّ آخر مرجعًا للمقارنة على أساسه. الأمر التّالي يبحث عن الملفّات الأجدد (خيّار newer-) من ملف باسم myfile. find / -newer myfileالبحث عن ملفّات باسم المالِك والأذون Permissionتوجد أيضًا إمكانيّة البحث عن الملفّات باسم مالكها أو مجموعة المستخدِمين الّتي ينتمي إليها المالك عن طريق الخيّارين user- وgroup- على التّوالي. الأمر التّالي يبحث عن الملفّات الّتي يملكهاالمستخدِم syslog: find / -user syslogبطريقة مُشابهة نبحث عن الملفّات الّتي ينتمي مالكها لمجموعة shadow: find / -group shadowبالنّسبة للبحث اعتمادًا على أذون الملفّات فالشّكل العام هوّ التّالي: find / -perm 644يبحث الأمر أعلاه عن الملفّات الّتي ضُبِطت أذونها على 644. إن أردنا البحث عن الملفّات بأذون تشمل على الأقل الأذون السّابقة ننفّذ الأمر التّالي (لاحِظ علامة - أمام الأذون): find / -perm -644سينتُج عن هذا الأمر عرضُ كلّ الملفّات الّتي لديها أذون 644 والملفّات ذات الأذون الإضافية. مثلًا، سيظهر ضمن النّتائج ملفّ بأذون 744. ترشيح المُخرجات حسب الموقع في نظام الملفّاتسننشئ في هذه الفقرة بنية مجلّدات ضمن مجلّد مؤقّت. ستشتمل هذه البنية على ثلاث مستويات، يوجد في المستوى الأوّل منها عشر مجلَّدات. سيحوي كلّ واحد من هذه المجلّدات (بما فيها المجلّد المؤقَّت الّذي سنسمّيه test) عشر ملفّات وعشر مجلّدات. أنشِئ بنية الملفّات هذه بتنفيذ الأوامر التّاليّة: cd mkdir -p ~/test/level1dir{1..10}/level2dir{1..10}/level3dir{1..10} touch ~/test/{file{1..10},level1dir{1..10}/{file{1..10},level2dir{1..10}/{file{1..10},level3dir{1..10}/file{1..10}}}} cd ~/testيمكنك التّأكّد من بنية المجلّدات باستخدام أوامر ls وcd. تأكّد من العودة إلى المجلّد test قبل تنفيذ الأوامر المقبلة. cd ~/testسنعمل على الحصول على ملفّات محدّدَة ضمن ينسة الملفّات هذه. فلنبدأ عن ملفّ باسمه: find -name file1النّتيجة: ./level1dir7/level2dir8/level3dir9/file1 ./level1dir7/level2dir8/level3dir3/file1 ./level1dir7/level2dir8/level3dir4/file1 ./level1dir7/level2dir8/level3dir1/file1 ./level1dir7/level2dir8/level3dir8/file1 ./level1dir7/level2dir8/level3dir7/file1 ./level1dir7/level2dir8/level3dir2/file1 ./level1dir7/level2dir8/level3dir6/file1 ./level1dir7/level2dir8/level3dir5/file1 ./level1dir7/level2dir8/file1 . . . توجد الكثير من النّتائج. فلنجرِّب عدَّ نتائج الأمر أعلاه: find -name file1 | wc -lالنّتيجة: 1111توجد - إذن - ملفّات عديدة. سنُحاول في ما يلي الاقتصار على بعضها. يُحدّد الأمر التّالي المستوى الأعلى الّذي يصله الأمر بحثًا عن الملفّات، وذلك انطلاقًا من مجلّد البحث. find -maxdepth num -name queryللبحث عن الملفّات باسم file1 الموجودة فقط في المجلّدات الّتي تبدأ أسماؤها بـlevel1 يُمكن تحديد المستوى الثّاني بوصفه العمقَ الأقصى (مجلّد البحث هو المستوى الأوّل، level1 هو المستوى الثّاني): find -maxdepth 2 -name file1النّتيجة: ./level1dir7/file1 ./level1dir1/file1 ./level1dir3/file1 ./level1dir8/file1 ./level1dir6/file1 ./file1 ./level1dir2/file1 ./level1dir9/file1 ./level1dir4/file1 ./level1dir5/file1 ./level1dir10/file1 قائمة أخفّ كثيرًا من قائمة الملفّات السّابقة. يُمكِن أيضًا تحديد مستوى أدنى بحيثُ تُتَجاهل المجلّدات الموجودة في مستوى لا يصِل للمستوى الأدنى المُحدَّد. find -mindepth num -name queryفي المثال التّالي نبحث عن ملفّات باسم file1 ضمن المستوى الرّابع وما يليه (المستوى الخامس، السّادس …إلخ). في بنية الملفّات الّتي أنشأناها يوجد آخر مجلّد ضمن المستوى الرّابع، وهو ما يعني أنّنا هنا نبحث عن ملفّات في المستوى الأخير من بنية المجلّدات المعنيّة. find -mindepth 4 -name file1النّتيجة: ./level1dir7/level2dir8/level3dir9/file1 ./level1dir7/level2dir8/level3dir3/file1 ./level1dir7/level2dir8/level3dir4/file1 ./level1dir7/level2dir8/level3dir1/file1 ./level1dir7/level2dir8/level3dir8/file1 ./level1dir7/level2dir8/level3dir7/file1 ./level1dir7/level2dir8/level3dir2/file1 . . . حصلنا مجدّدًا على الكثير من الملفّات (1000). يُمكن دمجُ خيّاريْ mindepth- وmaxdepth- لحَصر النّتائج ضمن مستويات معيَّنة. نحدّد في الأمر التّالي المستوى الأدنى mindepth- والمستوى الأقصى mindepth- للبحث عن الملفّات: find -mindepth 2 -maxdepth 3 -name file1النّتيجة: ./level1dir7/level2dir8/file1 ./level1dir7/level2dir5/file1 ./level1dir7/level2dir7/file1 ./level1dir7/level2dir2/file1 ./level1dir7/level2dir10/file1 ./level1dir7/level2dir6/file1 ./level1dir7/level2dir3/file1 ./level1dir7/level2dir4/file1 ./level1dir7/file1 . . .تنفيذ وتجميع أوامر find يُتيح أمر find إمكانيّة تنفيذ أوامر على نتائج البحث مباشرةً عن طريق مُعطَى exec-. آليّة العمل هي: find find_parameters -exec command_and_params {} \;حيثُ find_parameters تُمثّل خيّارات البحث وcommand_and_params الأمر المُراد تنفيذه على نتيجة البحث. علامة {} هي ماسك مكان Placeholder تحلّ محلَّ الملفّات المُطابقة لخيارات البحث. تُشير علامة ;\ إلى نهاية الأمر. يُمكن، على سبيل المثال، البحثُ عن ملفّات المجلَّدات السّابقة الّتي لديها أذون 644 وتعديلها إلى 664. cd ~/test find . -perm 644 -exec chmod 664 {} \;الأمر التّالي يُعدِّل أذون مجلَّد العمل (يُشار إليه بنقطة .): find . -perm 755 -exec chmod 700 {} \;إذا أردنا تجميع عدّة خيارات بحث فيُمكن استخدام أوامر and أو or لهذا الغرض. تعني and أنّ نتيجة البحث يجب أن تُطابق خيّارات البحث كلّها، أمّا or فتعني أنّ نتيجة البحث يكفي أن تُوافق أحد الخيارات. عند إضافة أكثر من خيار وعدم ذكر طريقة التّجميع (and أو or) فإنّ find تُطبّق and في هذه الحالة. find . -name file1 -or -name file9البحث عن ملفّات باستخدام locateأمر Locate هو طريقة بديلة وأسرع - في الغالب- للبحث عن الملفّات، حيثُ يمكنه البحث في كامل ملفّات النّظام بكلّ يُسر؛ إلّا أنّه يُقدِّم خيّارات أقّل من تلك الّتي يُوفّرها أمر find. قدتحتاج لتثبيت حزمة mlocate من أجل استخدام أمر locate: sudo apt-get update sudo apt-get install mlocateالسّبب وراء كون locate أسرَع من find هوّ أنّه يعتمد على قاعدة بيانات تخزّن بيانات الملفّات الموجودة في النّظام. تُحدَّث قاعدة البيانات هذه عادةً تلقائيًّا مرةً في اليوم، ولكن يُمكن أيضًا تحديثُها يدويًّا عن طريق الأمرupdatedb: sudo updatedbنفِّذ هذا الأمر الآن وتذكّر أنّ قاعدة بيانات locate يجب أن تكون مُحدَّثَة حتى تضمن ظهور الملفّات المنشأة أو المنقولة حديثًا في نتائج البحث. صيغة البحث عن ملفّات باستخدام locate هي التّاليّة: locate queryحيث query تُمثّل عبارة البحث. يُتيح أمر locate إمكانيّة ترشيح نتائج البحث. نستخدم خيّار b- سبيل المثال، للبحث عن الملفّات الّتي توجد عبارة البحث في أسمائها؛ بدلًا من البحث عن كلّ ملفّ توجد عبارة البحث في المسار المؤدّي إليه، الّذي هو الإعداد الافتراضي: locate -b queryيُعرَف اسم الملفّ بالاسم القاعدي Basename لتمييزه عن الاسم الكامل للملفّ الّذي يتضمّن مساره. يوجد أيضًا خيّار e- لقصر نتائج البحث على الملفّات الموجودة فعلًا على النّظام؛ أي تلك الّتي لم تُحذَف منذ آخر تحديث لقاعدة البيانات عبر الأمر updatedb. locate -e queryاستخدِم خيار S- لعرض إحصاءات عن المعلومات الّتي تُخزّنها قاعدة بيانات locate: locate -Sمثال على النّتيجة: Database /var/lib/mlocate/mlocate.db: 3,315 directories 37,228 files 1,504,439 bytes in file names 594,851 bytes used to store databaseخاتمةيُعدّ أمرا find وlocate طرقتيْن جيّدتَيْن للبحث عن الملفّات الموجودة على النِّظام. يرجع إليك قرار استخدام أيّ من الأداتيْن. يُمكن الرّفع من إمكانيّات الأداتيْن عبر تمرير مُخرجاتهما إلى أوامر أخرى مثل sort ،wc وgrep. ترجمة - وبتصرّف - لمقال How To Use Find and Locate to Search for Files on a Linux VPS.

تُمثِّل إضافة وحذف المستخدمين واحدةً من المهمَّات الأساسيّة الّتي يتوجَّب على كلّ مسؤول خواديم معرفةُ كيفيّة إجرائها. يوجد، افتراضًا، عند إنشاء خادوم جديد حسابُ مستخدِم واحدٌ فقط هو المستخدِم الجذر Root. يمنح حساب المستخدم الجذر الكثير من الإمكانيّات والمرونة، إلّا أنّه قد يكون في نفس الوقت مدمِّرًا وخطِرًا. من الجيّد في هذا الإطار إنشاء مستخدِم إضافيّ بامتيّازات Privileges محدودة لإجراء المهمّات الشّائعة. يجب أن تُنشئ حساباتٍ أخرى لكلّ شخص على نظامك بحيث يكون لدى كلّ مستخدم حساب مستقلّ، خاصّ به. ستبقى لدى المستخدم، إذا رأى مُدير النّظام ذلك مناسِبًا، إمكانيّة الحصول على الامتيّازات الإداريّة عندما يحتاجها، عبر آليّة تُسمَّى sudo. يشتمل هذا الدّليل على كيفيّة إنشاء حسابات للمستخدمين، منح امتيّازات sudo، وحذف المستخدمين. كيفيّة إضافة مستخدميُمكنك، عند التّسجيل بحساب المستخدم الجذر root، إنشاءُ مستخدمين جدد عبر تنفيذ الأمر التّالي (newuser هوّ اسم المستخدم): adduser newuserفي حال سجّلت الدّخول باسم مستخدم آخر، غير المستخدم الجذر، يملك امتيّازات sudo؛ أُنشِئ حسب الطّريقة المشروحة في درس الإعداد الابتدائي لخادوم أوبنتو 14.04 فيُمكنك إضافة مستخدم جديد عبر تنفيذ الأمر: sudo adduser newuserفي كلتا الحالتيْن ستُطرَح عليك مجموعة من الأسئلة. تتلخّص العمليّة في ما يلي: تعيين ثمّ تأكيد كلمة سرّ المستخدم الجديد.إدخال معلومات إضافيّة عن المستخدم الجديد. هذا الجزء اختيّاري ويُمكن تجاوزه بضغط زرّ Enter.أخيرًا سيُطرح عليك سؤال للتأكّد من المعلومات المُعطاة؛ ضغط زرّ Y يعني الموافقة.يُصبح الحساب الجديد، بعد إتمام هذه الخطوات، جاهِزًا للاستخدام؛ ويُمكن الدّخول إليه باستخدام كلمة السّر المعيّنة. في الفقرة التّاليّة سنشرح طريقة منح صلاحيّات إداريّة للمستخدم الجديد. منح امتيّازات Sudo لمستخدمإذا احتاج المستخدم الجديد لتنفيذ أوامر بامتيّازات إداريّة، فسيتوجّب علينا منحه امتيّاز الوصول إلى sudo. أمر visudo يؤدّي هذه المهمّة. يفتح visudo ملفّ الإعداد المناسب في المحرّر لديك. هذه هيّ الطّريقة الآمَن لإجراء هذه التّعديلات. نفّذ الأمر على النّحو التّالي، إذا سجّلت الدّخول بالمستخدم الجذر: visudoوعلى النّحو التّالي إن كنت سجّلت الدّخول بمستخدم آخر لديه صلاحيّات sudo: sudo visudoابحث عن سطر يأخذ الشّكل التّالي: root ALL=(ALL:ALL) ALLأضف أسفلَ هذا السّطر سطرًا جديدًا بنفس الصّيغة، مع إحلال اسم المستخدِم newuser مكان root. يُصبح الملفّ بالشّكل التّالي: root ALL=(ALL:ALL) ALL newuser ALL=(ALL:ALL) ALLيجب أن تضيف سطرًا جديدًا لكلّ مستخدم تُريد منحه كلّ صلاحيّات sudo. بعد الانتهاء من تحرير الملفّ يُمكنك حفظه ثم إغلاقه عبر الضّغط على زرّيْ CTRL وX في نفس الوقت. اضغط بعدها على زرّ Y ثمّ Enter للتّأكيد. يُمكن للمستخدم newuser الآن تنفيذ أوامر بصلاحيّات إداريّة. تُنفَّذ الأوامر عند تسجيل الدّخول بالحساب الجديد بنفس طريقة تنفيذها عند تسجيل الدّخول بالمستخدم العاديّ؛ فقط يُكتب اسم الأمر، ls على سبيل المثال: lsتُضاف sudo أمام نفس الأمر لتنفيذه بصلاحيّات إداريّة: sudo lsسيُطلب منك بعدها إدخال كلمة سرّ الحساب الّذي سجّلت به الدّخول. كيفيّة حذف مستخدمأحيانًا يُصبح وجود حساب مستخدِم غير ضروريّ؛ الأفضل في هذه الحالة حذف هذا الحساب. أمر deluser يحذف حساب المستخدم دون المساس بملفّاته. عند استخدام الحساب الجذر root (حيث newuser الحساب المُراد حذفُه): deluser newuserبالنّسبة لمستخدم آخر يملك امتيّازات sudo فإنّ الأمر يُصبح على النّحو التّالي: sudo deluser newuserأمّا إذا كان الهدف حذف حساب المستخدم وحذف ملفّاته فيجب إضافة خيّار remove-home-- فيُصبح : deluser --remove-home newuserأو (عند استخدام حساب آخر غير root): sudo deluser --remove-home newuserإذا كنت قد أعددت حساب المستخدم المحذوف ليحصُل على امتيّازات sudo فمن المستحسن تحرير ملفّ الإعداد مرةً أخرى وحذف السّطر الموافق لحساب المستخدم المعنيّ. visudoأو (عند استخدام حساب آخر غير root): sudo visudoيظهر ملفّ الإعداد: root ALL=(ALL:ALL) ALL newuser ALL=(ALL:ALL) ALL # احذف هذا السّطرسيمنع هذا الإجراء الاحترازيّ حصولَ حساب مستخدم يُنشأ مستقبلًا على امتيّازات sudo بطريقة غير مقصودة. خاتمةينبغي أن تكون لديك الآن معرفة جيّدة بكيفيّة إضافة وحذف المستخدمين في أوبنتو 14.04. تُمكِّن الإدارة الفعّالة للمستخدمين من الفصل بين حسابات هؤلاء، فلا يُمنح المستخدم سوى الامتيّازات الّتي يحتاجها لأداء عمله. للمزيد حول إعداد sudo راجع دليل تحرير ملفّ sudoers ترجمة بتصرّف لمقال How To Add and Delete Users on an Ubuntu 14.04 VPS

يُوفِّر Docker كل الدّوال (Functions) المطلوبة لبناء، رفع Upload، تنزيل Download، بدْء تشغيل وإيقاف الحاويّات؛ وهو مناسِب جدًّا لإدارة كل هذه العمليّات في بيئة من مُستضيف وحيد بعدد محدود من الحاويّات. رغم ذلك يلجأ كثيرون لاستخدام هذه المنصّة كأداة لبناء حاويّات تتوزَّع على عدّة مستضيفات مختلفة. تُمثِّل إدارة عناقيد من المُستضيفات Clustered hosts تحدِّيًّا جدّيًا يتطلّب مجموعةً مختلفة من الأدوات. سنعرِض في هذا المقال المُجدوِلاتِ Schedulers وأدواتِ التّنسيق Orchestration المُستَخدمةَ مع Docker. تُمثّل هذه الأدوات الواجهة الرّئيسة لإدارة الحاويّات والنّشر المُوزَّع. جدولة الحاويات، التنسيق وإدراة العنقودالقدرة على إدارة كل نظام مُستضيف وتفادي تعقيدات البنية التّحتيّة لبيئة العمل هي إحدى الوظائف الأكثر جاذبية عند التّطرق إلى توسّع Scaling التّطبيقات عبر عدة أنظمة مستضيفة. يظهر في هذا الإطار مُصطلح التّنسيق الّذي يشمل جدولة الحاويّات، وإدارة العنقود، وفي بعض الأحيان تجهيز وإعداد مُستضيفات جديدة. تُحيل الجدولة Scheduling عند الحديث عن النّظام البيئي لDocker إلى القدرة على رفع ملفّ يُعرِّف كيفيّة تشغيل حاويّة مُعيَّنة إلى النّظام المُستضيف؛ في حين نعني بالمُجدوِلات الأدواتِ المسؤولةَ عن التّدخّل في نِظام التّهيِئة الأوّليّة Init system لإدارة الخدمات حسب المطلوب. أمّا إدارة العنقود فتُشير إلى التّحكّم في مجموعة من المُستضيفات. يُمكِن أن تشمل هذه العمليّة إضافة أو إخراج مُستضيفات من العنقود، الحصول على معلومات عن حالة المُستضيفات أو الحاويّات، وبدْء تشغيل أو إيقاف العمليّات Processes. ترتبط إدارة العنقود بشكل وثيق مع الجدولة، إذ يجب أن تكون لدى المُجدوِل القدرةُ على الوصول إلى كل واحد من المستضيفات الموجودة في العنقود من أجل جدولة الخدمات. لهذا السبّب يغلُب استخدام نفس الأداة للتّنسيق والجدولة. من أجل إدارة وتشغيل الحاويّات على المُستضيفات المتواجدة على العنقود، يجب على المُجدوِل التّعاطي مع نظام التهيئة الأوّليّة لكلّ واحد من المُستضيفات. يجب على المُجدوِل في نفس الوقت، لتسهيل الإدارة، تقديمُ رؤية مُوَّحّدة لحالة الخدمات على كامل العنقود؛ ممّا يقوده إلى أن يعمل كنظام تهيئة أوليّة عابر للعنقود. لهذا السّبب تلجأ العديد من المُجدوِلات إلى أخذ صوّر طبق الأصل من بنية أوامر أنظمة التّهيئة الأوّليّة، ثمّ تعمل على تجريدها Abstract (إخفاء تعقيدات التّعامل مع بنية هذه الأنظمة). يُعتَبر اختيّارُ المُستضيف أحد أهمّ مسؤوليّات المُجدوِل، حيثُ إنه يتولّى تحديد المُستضيف الّذي ستعمل عليه الخدمة (الحاويّة) أوتوماتيكِيًّا بعدَ اتّخاذ المُدير قرار تنفيذها. يُمكِن للمُدير تحديد قيود على اختيّار المُستضيف، لكن في النّهاية المُجدوِل هو من سيُنفّذ هذه التّعليمات. كيف يتّخذ المُجدوِل قراراته؟تُعرِّف المجدوِلات عادةً سياسة افتراضيّة للجدولة. تُحدِّد هذه السّيّاسة كيف ستُنَفَّذ الخدمات في حال عدم وجود مُدخَلات من طرف المُدير. على سبيل يُمكن أن تكون السّيّاسة الافتراضيّة هيّ وضع الخدمات الجديدة على المُستضيفات الّتي يوجد بها أقلّ عدد من التّطبيقات النّشِطة. تُتيح المُجدوِلات إمكانيّة إعادة كتابة آليّاتِها، ممّا يسمح للمُديرين بتدقيق ضبط عمليّة الاختيّار لتستجيبَ لمُتطَلَّبات مُحدَّدة. على سبيل المثال، إذا وجَب تشغيل حاويّتَين على نفس المُستضيف لكونهما تعملان كوِحدة Unit، فيُمكِن إعلان هذا الغرض أثناء الجدولة. بالمِثل، يُمكِن فصلُ حاويَّتيْن بحيثُ لا تعملان على نفس المُستضيف، لأغراض تتعلّق بالتّوفّر العالي High availability لنظيرَيْن Instances من نفس الخدمة على سبيل المثال. قد تُمثَّل القيود الّتي يُمكِن لمُجدوِل أخذها في الحسبان، على هيأة بيانات وصفيّة Metadata مُوَّجَّهة لأغراض التّحكّم، فتُوضع لصائق Labels على المُستضيفات ليستعين بها المُجدوِل. يكون هذا ضروريًّا إذا كان المُستضيف يحوي تجزئةَ بيانات Data volume يحتاجها أحد التّطبيقات. تحتاج بعض الخدمات إلى أن تُنشَر على كلّ مُستضيف في العنقود، وهو ما تُتيحه المُجدوِلات. ما وظائف إدارة العنقود التي توفرها المُجدوِلات؟ترتبِط وظيفتا الجدولة وإدارة العنقود ارتباطًا وثيقًا لأنّ كلًّا منهما تتطلّب القدرة على العمل على مُستضيفات مُحدَّدة وعلى العنقود ككلّ. تُستخدَم برامج إدارة العناقيد لطلب معلومات عن أعضاء عنقود، إضافة أو حذف أعضاء، أو حتّى الاتّصال بمُستضيف مُعيَّن لإدارة أكثر تخصيصًا. يُمكِن أن تُضاف هذه الوظائف إلى المُجدوِل كما يُمكِن إدراجها ضمن مسؤوليّة برنامج مُستقلّ. ترتبِط إدارة العنقود في كثيرٍ من الحالات بأداة استكشاف الخدمة أو مخزن إعدادات بصيغة مفتاح-قيمة. يُفيد هذا الارتباط في توزيع المعلومات وحفظها عبرَ كامل العنقود، كما أنّ المنصّة في هذه الحالة جاهزة لوظيفتها الأوليّة. في هذه الحالة (ارتباط أداة الإدارة باستكشاف الخدمة ومخزن الإعدادات) يحتاج إجراء بعض مهامّ إدارة العنقود، إن لم تتوفّّر طُرُق Methods للتّخاطُب مع المُجدوِل، إلى تغيير قيّم موجودة في مخزن الإعدادات عن طريق واجهته لبرمجة التّطبيقات Application programming interface, API. على سبيل المثال: تُغَيَّر عضويّات العنقود عن طريق التّعديل على قيّم في مخزن الإعدادات. يُحتفَظ بالبيانات الوصفيّة المُتعلِّقة بالمُستضيفات في مخزن الإعدادات؛ حيثُ يُمكن استخدامها كما ذكرنا سابِقًا لاستهداف مستضيف أو مجموعة من المُستضيفات بقرارات جدولة. كيف تكون الجدولة في حالة تجميع الحاويّات؟يتوجّب في بعض الأحيان إدارة عدّة خدمات كما لو كانت تطبيقًا واحدًا، ففي بعض الحالات لا يُمكن حتى نشر خدمة دون نشر خدمة أخرى مُصاحِبة لها، لارتباط عملهما. تُوفّر عدّة مشاريع تنسيقًا متقدِّمًا يأخذ في الحسبان تجميع الحاويّات، ولهذه الوظيفة عدّة فوائد. تسمح إدارة الحاويّات على مجموعات للمُدير بالتّعامل مع تشكيلة من الحاويّات على أنّها تطبيق واحد. يُبسِّط تشغيلُ عدّة عناصر مُرتبِطة بإحكام إدارةَ التّطبيقات دون أن يكون ذلك على حساب فوائد تقسيمها إلى حاويّات لكلٍّ منها وظيفة منفصِلة؛ حيثُ يسمح للمُدير بالحفاظ على فوائد استخدام التّصميم خدَمي التّوجّه Service-oriented مع تقليل جهد الإدارة. يُمكِن أن يعنيَ تجميعُ التّطبيقات ببساطة جدولتَها وإتاحة إمكانيّة تشغيلها أو إيقافها معًا؛ كما أنّه قد يُشير إلى تصوّرات أكثر تعقيدًا مثل فصل كل مجموعة ضمن شبكة فرعيّة أو العمل على توسّع Scaling مجموعة من الحاويّات بدل العناية بالتّوسّع الفردي لكل واحدة منها. ماذا نعني بالتّجهيز Provisioning؟يرتبِط مفهوم التّجهيز بإدارة العناقيد. نعني بالتّجهيز مجموعة الآليّات الّتي تسمح بإضافة وإعداد مُستضيفات جديدة لتكون جاهزةً للعمل ضمن العنقود. في حالة نشر التّطبيقات عبر Docker فإنّ التّجهيز يعني إعداد Docker وضبطَ المُستضيف الجديد للالتحاق بعنقود موجود. تختلف طريقة التّجهيز بشكل كبير حسب الأدوات المُستخدَمة ونوعيّة المُستضيف، ولكن الهدف في الأخير هو نظام جديد جاهز للعمل. على سبيل المثال، إذا كان المُستضيف آلة تخيّليّة Virtual machine فإن أدواتٍ مثل Vagrant يُمكِن أن تُستخدَم لإعداد المستضيف الجديد. يسمح معظَم مزوّدي الخدمات السّحابية Cloud providers بإنشاء مُستضيفات جديدة اعتمادًا على واجهة تطبيقات برمجيّة API. على الجانب الآخر، يحتاج تجهيزُ عتاد خام (حاسوب بدون نظام تشغيل) لتدخّل يدوي أكثر؛ يُمكن اللّجوء إلى أدوات مثل Ansible، Puppet، Chef أو Salt من أجل الإعداد التّمهيدي للمُستضيف وتجهيزه بالمعلومات المطلوبة للاتّصال بالعنقود. يوجد خيارات للتّجهيز: إمّا أن يكون عمليّة يدويّة يُطلِقها المُدير، أو أن يكون جزْءًا من أدوات إدارة العنقود من أجل أتممة التوسّع Automation. يتطلّب الخيّارُ الأخير تعريفَ إجراء يطلُب مُستضيفات جديدة والشّروط الّتي يجب أن يحصُل حسبها الطّلب. على سبيل المثال، إذا كان تطبيقٌ يُعاني من الحِمل الزّائد على الخادوم، فيُمكِن ضبط مُستضيفات وإلحاقُها بالنِّظام لتتوسَّعَ الحاويّات أفقيًّا عبر البُنية التّحتيّة الجديدة، من أجل التّخفيف من الضّغط على الخادوم. ماهيّ المُجدوِلات الأكثر انتشارًا؟من بين المشاريع الأكثر شهرةً في الجدولة وإدارة العناقيد (الوظائف الأساسيّة): Fleet: أداة الجدولة وإدارة العناقيد ضمن توزيعة CoreOs. تقرأ Fleet معلومات الاتّصال لكل مُستضيف في العنقود من etcd ( أداة استكشاف خدمة وإعداد عموميّ مُوزَّع لكل من الحاويّات والأنظمة المُستضيفة، جزْء من توزيعة CoreOs) وتُوفِّر خدمة إدارة شبيهة بSystemd (نِظام تهيئة أوّليّة بدأت الكثير من توزيعات غنو/لينوكس اعتمادَه ليكون بديلًا عن أنظمة التّهيِئة الأوّليّة التّقليديّة). Marathon: وهو العنصُر المسؤول عن الجدولة وإدارة الخدمات في Mesosphere (نظام تشغيل مُوجَّه لإدارة مراكز البيانات Data centers). يعمل مع mesos (أداة لتجريد وإدارة جميع موارد العنقود) للتّحكّم في الخدمات الّتي تعمل لفترات زمنيّة طويلة. كما أنّه يُوفِّر واجهة ويب لإدارة الحاويّات. Swarm: أعلن مشروع Docker عن مُجدوِل Swarm في ديسمبر/كانون الأوّل سنة 2014، ويأمل في أن يُقدِّمَ مجدوِلًا جيّدًا يُمكنه تقسيم الحاويّات على المُستضيفات المُجهَّزَة على Docker، وذلك باستخدام نفس الصّيّاغة Syntax الّتي يستخدمها Docker. بالنّسبة للجدولة المُتقدّمة والتّحكّم في مجموعات الحاويّات، توجد المشاريع التّاليّة: kubernetes: مُجدوِل مُتقدّم من Google. يُتيح kubernetes تحكّمًا متقدّمًا في الحاويّات؛ حيث يُمكِن توصيف الحاويّات، تجميعها، وإعطاءُها شبكات فرعيّة مستقلّة للاتّصال. compose: مشروع تابِع لـ Docker، أُنشِئ لإضافة إمكانيّة إدارة مجموعات من الحاويّات باستخدام ملفّات إعداد تقريريّة Declarative. يستخدِم روابط Docker لمعرفة معلومات عن علاقات التّبعيّة بين الحاويّات. خلاصةتُمثِّل إدارة العناقيد والجدولة جزأين مهمَّيْن من إعداد وتنفيذ خدمات تعتمد على الحاويّات في بيئة مُوزَّعة مُكوَّنة من عدّة مُستضيفات، إذ تُوفِّران الوظائف الأساسيّة من أجل بدْء تشغيل الخدمات والتّحكّم فيها. يُمكِن عبر استخدام المُجدوِلات بفعاليّة إحداثُ تغييرات كبيرة على عمل التّطبيقات، بالقليل من الجُهد.

مقدّمةيكتسي التّواصل Communication والتّشبيك Networking أهميّةً بالغة عند بناء نُظُم موزَّعة تعمل عليها حاويّات Docker؛ حيثُ تعتمد بنية التّطبيقات الّتي تتبع التّصميم خَدَمي التّوجّه Service-oriented بشكل كبير على تواصُل المكوِّنات في ما بينها حتى تعمل كما يُرادُ لها. سنذكُر في هذا الدّرس أدواتِ وإستراتيجيّات التّشبيك المُتعدّدة المُستخدَمة لضبط الشّبكات الّتي تعمل عليها الحاويّات؛ وذلك من أجل الوصول إلى الوضعية المرغوبة للشّبكة. يُمكن في بعض الحالات الاعتماد على الحلول الّتي يُوفّرها Docker افتراضيًّا، إلّا أنّ في بعض الحالات تتطلّب الاستعانة ببعض المشاريع البديلة. الحل الافتراضي للتّشبيك على Dockerيقدّم Docker افتراضيًا العديد من الأدوات القاعديّة المطلوبة للتّواصل بين الحاويّات Container-to-container وبين الحاويّات والنِّظام المُستضيف Container-to-host. يضبُطُ Docker عند تشغيله واجهة وهميّة Virtual interface جديدة للشّبكة باسم docker0 على النّظام المُستضيف. تعمل هذه الواجهة كجسر Bridge يُمكّن Docker من إنشاء شبكة فرعيّة Subnet تستخدمها الحاويّات في ما بعد؛ إضافةً إلى عملها كنقطة وصل بين آلية التّشبيك في الحاويّة وتلك الموجودة في المُستضيف. تُنشَأ واجهة وهميّة عندما يبدأ Docker تشغيل حاوية جديدة، وتُمنح عنوان IP ضمن مجال الشّبكة الفرعيّة المذكورة سابقًا. يدخُل عنوان IP الواجهة الوهمية الجديدة في إطارالشّبكة الدّاخليّة للحاويّة ممّا يوفِّر مسارًا يُمكن للحاويّة الاتّصال عن طريقه بالجسر docker0 الموجود على المُستضيف. يضبُط Docker آليًّا قواعد Iptables للسّماح بإعادة التّوجيه Forwarding ويُعدّ آليّة ترجمة العناوين على الشّبكة Network address translation (أو NAT اختصارًا) للاستخدام عند تبادل البيانات بين docker0 والعالم الخارجي. 1- كيف تعرِض الحاويّات الخدماتِ للعملاء؟لا تحتاج الحاويّة لأي إعدادات إضافيّة للحصول على الخدمات المُقدَّمة من طرف الحاويّات المتواجدة على نفس المُستضيف، حيثُ إنّ المُستضيف سيُوجِّه الطّلبات الّتي تُرسَل من الواجهة docker0 وتتّجه إليها (كلّ من المصدَر والوِجهة يوجدان على نفس الشّبكة الفرعيّة) إلى المكان المُناسِب. يُمكن للحاويّات عرضُ expose منافذها Ports عبرَ المُستضيف لتلقي البيانات ينقلها هذا الأخير إليها من العالم الخارجي. يُمكن قرن Mapping منافذ الحاويّة المعروضة بمنفذ من النِّظام المستضيف (تُنقل البيانات المُتبادلَة عبر منفذ المُستضيف إلى منافذ الحاويّة المقرونة بها) إمّا باختيار منفَذ مُحدَّد؛ أو ترك هذه المهمّة لـ Docker، في هذه الحالة يختار Docker منفذًا عشوائيًا غير مُستعمل برقم عالٍ. يتولّى Docker في هذا الإطار إدارة قواعد التوّجيه وإعدادت iptables لإيصال البيانات إلى وجهتها الصّحيحة. 2- ما الفرق بين عرض ونشر منفَذ Publishing ؟يُمكِن عند إعداد صورة أو بدْء تشغيل حاويّة، الاختيارُ بين عرض أو نشر المنافذ. من المهمّ التّفريقُ بين الاثنين. يعني عرضُ منفَذ مّا إعلامَ Docker أنّ الحاويّة تستخدِم المنفَذ المذكور، ويُمكن بالتّالي استخدام هذا المنفذ لأغراض الرّبط Linking أو الاستكشاف. يُعطي فحصُ حاويّة - على سبيل المثال - معلوماتٍ عن المنافذ المعروضة، وعند ربط حاويّات فإنّ متغيّرات البيئة تُضبَط لمعرفة المنافِذ المعروضة في الحاويّة الأصليّة.يُمكن - في الإعداد الافتراضي - للنِّظام المُستضيف الوصولُ إلى الحاويّة؛ نفس الشّيء بالنّسبة للحاويّات الموجودة على نفس المُستضيف. تقتصِر فائدة عرض المنافِذ في هذه الحالة على توثيق استخدام المنفذ وجعل هذه المعلومة مُتاحةً للرّبط والتّعيين الآليّيْن. على الجانب الآخر، يؤدّي نشر منفذ إلى جعله متاحًا للعالم الخارجي عبر قرنه بواجهة المُستضيف. 3- ماهيّ روابِط Docker؟يُوفّر Docker آليةً لإعداد الاتّصالات بين الحاويّات، تُسَمّى "روابط Docker" . تحصُل حاويّة جديدة عندَ ربطها بأخرى موجودة على معلومات اتّصال الأخيرة عبر متغيّرات مُشترَكة في بيئة التّنفيذ. تُشكّل هذه الوسيلة طريقةً سهلة للتّأسيس لاتّصال بين حاويّتيْن عبر إعطاء الحاويّة الجديدة معلومات مُفصَّلة عن كيفية النفاذ إلى الحاوية المُصاحِبة. تُضبَط المتغيّرات المُشترَكة حسب المنافذ الّتي تعرضها الحاويّة بينما يضبط Docker عنوان IP الحاويّة ومعلومات اتّصال أخرى. مشاريع للرّفع من قدرات Docker في التّشبيكنموذج التّشبيك المُقدَّم أعلاه يُشكِّل نقطة بدْء جيّدة في بناء وربط الشّبكات. الاتّصال بين الحاويّات الموجودة على نفس المُستضيف يعمل بشكل مُباشر. بالنّسبة للاتّصال بين المُستضيفات فيعمل عن طريق الشّبكات العمومية Public networks ما دامت المنافذ مقرونة بشكل صحيح ومعلومات الاتّصال متوفّرة لدى الطّرف الآخر. على الرّغم من ما سبق، تتطلّب بعض التّطبيقات بيئات شبكيّة خاصّة (نظرًا لبعض الأهداف الأمنيّة أو الوظيفيّة) لا يستطيع نموذج التّشبيك الأصلي في Docker توفيرها. لهذا السّبب أُنشِئت مشاريع عديدة لزيادة قُدُرات Docker في الرّبط بين الشّبكات. 1- إنشاء شبكات فوقيّة Overlay لتجريد Abstract البنية التّحتيّةركّزت العديد من المشاريع على تحسين وظيفي يتمثّل في التأسيس لشبكات فوقيّة Overlay Networks؛ وهيّ عبارة عن شبكات افتراضيّة مبنيّة على اتّصالات موجودة مُسبَقًا. يُمكّن التّأسيس لشبكات فوقيّة من إنشاء بيئات تشبيك منتظِمة يُمكن التّنبّؤ بها، وتربط بين عدّة مستضيفات. يُساعد هذا الأمر في تسهيل ربط الحاويّات بالشّبكة دون الاهتمام بالمُستضيف الذي تعمل عليه هذه الحاويّات. يُمكِن استخدام هذه الطّريقة لبناء شبكة افتراضيّة واحدة تمتدّ على عدّة مُستضيفات، أو لبناء شبكات فرعيّة لكل مُستضيف اعتمادًا على نفس الشبكة الفوقيّة. تُتيح الشّبكات الفوقيّة أيضًا بناء نسيج عنقودي Fabric clusters. تعمل الحوسبة النسيجيّة Fabric computing (يُطلَق عليها أحيانًا الحوسبة التوحيديّة Unified computing) على توحيد عدّة مُستضيفات وإدارتها كما لو كانت كيانًا واحدًا بموارد أكبر. يسمح إنجاز مبدأ الحوسبة النسيجيّة للمُستخدِم النّهائي بإدارة العنقود كوحدة بدلًا من مستضيفات متفرّقة. يلعب ربطُ الشّبكات جزءًا كبيرًا من إنشاء عناقيد حسب هذا المبدأ. 2- الإعداد المتقدّم للتّشبيكتتولّى مشاريعُ أخرى الرّفع من قدرات Docker التّشبيكيّة عن طريق توفير مرونة أكبر. إعداد التّشبيك الأصلي في Docker يقوم بالوظيفة الّتي أُنشئ من أجلها، ولكنّه بسيط جدّا. على الرغم من أنّ الحواجز الوظيفيّة للإعداد الافتراضي للشّبكات في Docker قد تظهر عند تخصيص مُتطلَّبات التّشبيك في مستضيف واحد، إلّا أنّها تظهر بشكل أوضح عند التّعامل مع شبكات عابرة للمُستضيفات. يُلجأ - من أجل إضافة وظائف جديدة إلى "تطويع" تلك الموجودة مُسبَقًا. لا تُضيف هذه المشاريع إعدادات خارقة لكنّها تسمح بربط أجزاء في ما بينها لإنشاء تصوّرات أكثر تعقيدًا لعمل الشّبكات. تمتد الوظائف الّتي تُضيفها هذه المشاريع من مجرّد إنشاء وربط شبكات خاصّة بين بعض المستضيفات إلى ضبط جسور، شبكات محليّة افتراضيّة، تخصيص الشّبكات الفرعيّة والبوّابات Gateways. توجد مشاريع وأدوات أخرى تُستخدم كثيرًا في بيئات Docker لتوفير وظائف جديدة، وذلك رغم أنّها لم تُطوَّر خصّيصًا لـDocker. يتعلّق الأمر خصوصًا بتقنيّات وصلت لمرحلة النّضوج في إنشاء الشّبكات الخاصّة والأنفاق Tunnels الّتي تُستخدَم غالِبًا لتأمين التّواصل بين المستضيفات وعبر المُستضيفات. هل من مشاريع شائعة الاستخدام للتحسين من أداء الشّبكات في Docker؟توجد عدّة مشاريع تُركِّز على توفير شبكة فوقيّة لمستضيفات Docker. في ما يلي بعض أكثر هذه المشاريع شيوعًا: flannel: يُطوِّره فريق CoreOs. أُنشئ هذا المشروع أصلًا لإعطاء كل مُستضيف شبكة فرعيّة خاصّة به ضمنَ شبكة مُشترَكة؛ وهو شرط ضروري لعمل أداة التّنسيق kubernetes الّتي تُطوِّرها Google، لكنّه مفيد أيضًا في حالات أخرى. weave: تُنشئ أداة Wweave شبكة افتراضيّة تربط بين مختلف مُستضيفات Docker. يُسهّل هذا الأمر من توجيه بيانات التّطبيق، إذ أنّ الحاويّات تبدو كما لو كانت كلّها على نفس المُوزِّع Switch. بالنسبة للتّشبيك المتقدّم، تهدف المشاريع أدناه إلى توفير قدرات تطويع أكثر للشّبكة. pipework: يهدف هذا المشروع إلى سد الفجوة في آلية التّشبيك الأصليّة في Docker من حيث نقص الوظائف المتقدِّمة، في انتظار تطّورها حيثُ يُسهّل التحكّم في وضبطَ إعدادات متقدّمة للتّشبيك. الأداة التّاليّة هي مثال على اختيّار برمجيّات موجودة خارج النّظام البيئي لـDocker واستخدامها بإضافة وظائف جديدة إليه. tinc: عبارة عن برنامج لإنشاء شبكة افتراضيّة خاصّة Virtual private network (أو VPN اختصارًا) يعتمد على التّعميّة Encryption والأنفاق. تُقدّم هذه الأداة طريقة وسيلة صلبة لجعل استخدام الشّبكة الخاصّة شفّافًا بالنّسبة لأيّ تطبيق. خاتمةيعتمد نموذج Docker على توفير خدمات عبر عناصر داخليّة وأخرى خارجيّة، وهو ما يجعل من الاعتبارات المُتعلّقة بالشّبكة مهمّةً للغاية. يُوفّر Docker وظائف أساسيّة لإعداد الشّبكات مثل الواجهات الافتراضيّة، الشّبكات الفرعيّة، iptables وإدارة ترجمة العناوين على الشّبكة (NAT)؛ وهيّ الوظائف الّتي تُكمّلها مشاريع أخرى أُنشِئت لإتاحة إمكانية ضبط إعدادات أكثر تقدّمًا. سنتطرّق في الدّرس القادم لكيفيّة عمل المُجدوِلات Schedulers وأدوات التّنسيق orchestration المبنيّة على هذا الأساس بهدف إدارة عنقود حاويّات.

مقدِّمةيحتاج الكثيرُ من المستخدمين إلى نظام إدارة قواعد بيانات Database Managment System, DBMS مثل MySQL، إلّا أنّهم قد لا يكونون مرتاحين للتّفاعل مع النّظام من خلال سطر أوامر MySQL فقط. أُنشئ phpMyAdmin بحيث يتفاعل هؤلاء المستخدمون مع MySQL عن طريق واجهة ويب. سنعرض في هذا الدّرس لكيفيّة تثبيت وتأمين phpMyAdmin بحيث يُمكن استخدامُه بأمان من أجل إدارة قواعد بيانات MySQL على أوبنتو 14.04. المُتطلَّباتنفترض، قبل البدء مع خطوات هذا الدّرس، أنّك تتوفّر على المتطلَّبات التّاليّة: حساب بصلاحيّات sudo، غير حساب المستخدِم الجذر Root user كما هوّ موضَّح في الخطوات 1-4 من درس الإعداد الابتدائي لخادوم أوبنتو.حزم MySQL، Apache، Linux وPHP (المعروفة بLAMP) مُثَبَّتة ومُعدَّة. يُمكن مراجعة درس كيف تُثبِّت حِزم MySQL، Apache، Linux) LAMP وPHP) على Ubuntu 14.04 لهذا الغرض.بإكمال الخطوات أعلاه تكون مستعدا لمتابعة هذا الدّرس. الخطوة الأولى: ثبِّت phpMyAdminنبدأ بتنزيل وتثبيت phpMyAdmin من مستودعات أوبنتو عن طريق مدير الحزم apt: sudo apt-get update sudo apt-get install phpmyadminستُطرَح عليك بعضُ الأسئلة لإعداد التّثبيت بما يُناسِب: عند اختيار خادوم الويب اختَر apache2. ملحوظة: إن لم تضغط زر المسافة SPACE على لوحة المفاتيح لاختيّار Apache فلن ينقُل برنامج التّثبيت الملفّات الضّرورية أثناء التّثبيت. اختر زر SPACE على لوحة المفاتيح ثمّ زر TAB ثمّ زرّ ENTER لاختيّار Apache.اختَر نعم (YES) عند السّؤال إذا ما كنت تُريد استخدام dbconfig-common لضبط قاعدة البيانات.أدخِل كلمة سرّ مدير قاعدة البيانات عندما يُطلَب منك ذلك.سيُطلب منك أيضًا اختيّار وتأكيد كلمة سرّ تطبيق phpMyAdmin نفسِه.تُضيف عمليّة التّثبيت ملفّ إعداد phpMyAdmin إلى المُجلَّد /etc/apache2/conf-enabled/ حيثُ يقرؤه خادوم ويب Apache أوتوماتيكيًّا. كلّ ما علينا فعله يدويًّا هو تفعيل امتداد Extension يحمل الاسم php5-mcrypt (واجهة للتّعامل مع مكتبة mcrypt الّتي تضم خوارزميّات للتّعميّة Encryption) عن طريق تنفيذ الأمر: sudo php5enmod mcryptستحتاج لإعادة تشغيل Apache لكي يتعرَّف على الامتداد الجديد: sudo service apache2 restartيُمكنك بعدها الولوج إلى واجهة الويب عن طريق إدخال عنوان IP العمومي لخادومك أو اسم النّطاق في شريط العناوين بمتصفّح الويب متبوعًا ب phpmyadmin/ كما يلي: http://domain_name_or_IP/phpmyadminملحوظة: إن كنت تجرِّب التّثبيت على جهازك المحلّي فيُمكنك الوصول إلى واجهة phpmyadmin عن طريق إدخال العنوان التّالي في شريط العناوين بمتصفّح الويب http://127.0.0.1/phpmyadmin يُمكنك الآن الولوج إلى واجهة الويب عن طريق حساب المستخدم الجذر الّذي أعددته أثناء تثبيت MySQL. ستظهر عند تسجيل الدّخول واجهة المستخدِم والّتي تُشبه ما يلي: الخطوة الثّانيّة: تأمين phpMyAdminأكملنا الآن تثبيت phpMyAdmin وسجلنا الدّخول إلى واجهة المستخدِم، لكن بقي أمر آخر. يستهدِف الكثيرُ من المخترقين phpMyAdmin نظرًا لشهرته، في محاولةٍ منهم لنيل طريقة للاتّصال بقاعدة البيانات. نحتاج لتأمين التّطبيق للمساعدة في الحماية من الاستخدام غير المُصرَّح به. إحدى أسهل الطّرق لتأمين phpMyAdmin هيّ وضعُ بوّابة gateway أمام كامل التّطبيق. نستخدم الاستيثاق Authentication والتّصريح Authorization عن طريق ملفّات htaccess. المُضمَّنة في Apache. 1- إعداد Apache للسّماح بالتّجاوز Override في ملفّات htaccess.يجب علينا أوّلًا تفعيل استخدام التّجاوز في ملفّات htaccess. وذلك بالتّعديل على ملفّ إعداد خاصّ بـ phpMyAdmin في خادوم ويب Apache. يعني تفعيل التّجاوز أنه يُمكن تعريف ملفّ htaccess. لمجلَّد مُحدَّد بحيثُ تُنفَّذ تعليمات ملفّ htaccess. الموجود في المجلَّد بدلًا من ملفّ htaccess. العامّ لخادوم الويب. نُعدِّل على ملف إعداد phpMyAdmin الموجود في مجلّد Apache للإعدادات: sudo nano /etc/apache2/conf-available/phpmyadmin.confنُضيف تعليمة AllowOverride All داخل مقطع 2- أنشئ ملفّ htaccess.نبدأ الآن بعد أن فعَّلنا استخدامَ ملفّ htaccess. خاصّ بتطبيقنا، نبدأ بإنشاء هذا الملفّ من أجل إضافة إجراءات أمان إلى phpMyAdmin. يجب أن يُنشَأ ملفّ htaccess. داخل مجلَّد التّطبيق. الأمر التّالي يُنشئ ثمّ يفتح الملفّ (يتطلّب صلاحيّات المستخدم الجذر): sudo nano /usr/share/phpmyadmin/.htaccessنُضيف التّعليمات التّالية داخل هذا الملفّ: AuthType Basic AuthName "Restricted Files AuthUserFile /etc/phpmyadmin/.htpasswd Require valid-userفلنلقِ نظرة على دلالة كل واحدة من هذه التّعليمات: AuthType Basic: تُحدِّد AuthType نوع الاستيثاق الّذي سنطلُب وضعه. Basic تعني أنّنا سنستخدم الاستيثاق بكلمة سرّ عن طريق ملفّ يُسمّى ملفّ كلمة السّر.AuthName: هذه التّعليمة تُحدِّد الرّسالة الّتي تظهر في مربّع طلب كلمة السّر عند محاولة الوصول إلى التّطبيق. يجب أن تكون هذه الرّسالة عامّة بحيثُ لا تُعطي أيّ معلومات عن ما تحميه كلمة السّر.AuthUserFile: تُحدّد مكان حفظ ملفّ كلمة السّر المُستخدَمة للاستيثاق. يجب أن يُحفّظ الملفّ خارج المجلّدات الّتي يُقدّم منها خادوم الويب ملفّاتٍ للزوّار. سنُنشئ هذا الملفّ بعد قليل.Require valid-user: تُحدّد نوعيةَ المستخدمين المسموح لهم بالوصول إلى المجلَّد المحمي. هذه التّعلمية أساسيّة من أجل منع وصول المستخدمين غير المُصرَّح لهم بالدّخول إلى التّطبيق.احفَظ الملفّ (Ctrl + O) بعد التّعديل ثم أغلقه (Ctrl+ X). 3- أنشئ ملفّ htpasswd. للاستيثاقعيّنّا أثناء إنشاء ملفّ htaccess. في الفقرة السّابقة طريقة استيثاق تعتمد على ملفّ كلمة سرّ، عبرَ تعليمة AuthUserFile. نُنشئ الآن هذا الملفّ. سنحتاج إلى حزمة إضافيّة تعمل مع خادوم الويب لهذا الغرض، نُثبِّتها عبر الأمر: sudo apt-get install apache2-utilsسنحصُل بعد اكتمال التّثبيت على أداة كلمات السّر في Apache. الأمر التّالي يُنشئ ملفّ كلمة السّر في المسار الّذي عيّنّاه في ملفّ htaccess. ويُحدّد اسمَ مُستخدِم مرفقًا بهذا الملفّ: sudo htpasswd -c /etc/phpmyadmin/.htpasswd usernameسيُطلَب منك إعطاء ثمّ تأكيد كلمة سرّ المستخدِم الّذي تُنشئه (username في الأمر أعلاه).سيُنشأ بعدها ملفّ يحوي اسم المُستخدم وتلبيد Hash كلمة السّرّ (تُحفَظ كلمة السّرّ بعد تعميّتها Encryption). تُمكن إضافة مُستخدم جديد عن طريق الأمر أعلاه ولكن بدون خيار c- كما يلي: sudo htpasswd /etc/phpmyadmin/.htpasswd additionaluserعند محاولة الولوج الآن إلى phpMyAdmin فسيُطلَب منك إدخال اسم الحساب الجديد وكلمة السّر المُصاحبة له الّذيْن ضبطتهما للتّو. http://domain_name_or_IP/phpmyadmin بعدَ تخطي استيثاق Apache ستُنقَل إلى واجهة phpMyAdmin حيثُ يجب عليك إدخال اعتمادات واجهة الويب الخاصّة بـ phpMyAdmin. يُضيف هذا الإجراء طبقةً جديدة من الحماية تُساعِد في التّغلّب على أيّ نقاط ضعف قد تكون موجودة في phpMyAdmin. خاتمةيجب بعد إكمال هذه الخطوات أن تحصُل على تطبيق phpMyAdmin مضبوط وجاهز للعمل على خادوم أوبنتو 14.04. يُمكن مع phpMyAdmin إنشاء قواعد بيانات، مستخدمين، جداول… إلخ إضافةً إلى الإجراءات الاعتيّاديّة مثل حذف أو تعديل البُنيَات Structures والبيانات بكل سهولة. ترجمة - وبتصرّف - لمقال How To Install and Secure phpMyAdmin on Ubuntu 14.04.

مقدِّمةيُشكّل خادوم Nginx، السّريع والخفيف، بديلًا - في حالات عديدة - لخادوم Apache كثيرِ المُتطلّبات. كأيّ برنامج آخر، يحتاج Nginx إلى ضبطه من أجل الحصول على أداء أفضل. مُتطلَّبات الدّرسخادوم ويب Nginx مثُبَّت ومُعَدّ للعمل. فهم أساسيّات التّعامل مع Linux. ضبط متغيّرَيْ worker_processes و worker_connectionsأوّل متغيِّريْن يجب علينا ضبطُهما هما متغيّرا worker_processes و worker_connections. يجب أن نفهم ما الّذي يتحكّم فيه كل واحد من هذيْن المتغيّريْن، قبل الدّخول في تفاصيل إعداد كلّ واحد منهما. نبدأ بتعليمة worker_processes الّتي تُمثِّل العمود الفقري الصّلب بالنّسبة ل Nginx. تُعطي هذه التّعليمة عددَ العمليّات Processes الّتي يجب على Nginx إنشاؤُها بعد معرفته لعنوان IP والمنافِذ Ports الّتي سيشتغل عليها، وهيّ المسؤولة عن كل ما يُؤدّيه خادوم الويب. يُطلَق على كل واحدة من هذه العمليّات اسم Worker (العامِل). من المُستحسَن تشغيلُ عامل واحد على كل نواة Core من وحدة المُعالجة المركزيّة Central processing unit, CPU. لن ينتُج عن تشغيل أكثر من عامل على نواةٍ ضررٌ كبير على النِّظام لكنّه سيؤدّي إلى وجود العديد من العمليّات السّاكنة Idle processes غير الضّروريّة. ملحوظة: عمليّة ساكنة هي عمليّة لا تجد ما تفعله ولا تتولّى الإجابة عن أيّ طلب. يكفي، لمعرفة قيمة worker_processes الأمثل لإعدادك، إلقاءُ نظرة على عدد الأنويّة لديك. يُمكِنك عبر الأمر التّالي الحصول على هذه المعلومة: grep processor /proc/cpuinfo | wc -lفلنفترِض أنّ نتيجةَ تنفيذ الأمر هيّ 1. يعني هذا أنّه يوجد في النّظام لدينا نواةٌ واحدة. المُتغيّر الثّاني worker_connections يُعطي عددَ الاتّصالات الّتي يُمكن لعمليّات من نوع Worker الاستجابة لها في نفس الوقت. القيمة الافتراضيّة هي 768.في العادة، يُرسِل متصفّح الويب طلبيْن - على الأقل - في نفس الوقت إلى الخادوم، وهو ما يعني أنّ عدد العملاء الّذين يُمكِن الرّد عليهم في نفس الوقت يبلغ في أعلى تقدير نصفَ قيمةِ المُتغيِّر worker_connections. من أجل الرّفع من عدد العُملاء المُتّصلين في آنٍ معًا سنُعطي لهذا المُتغيِّر أعلى قيمة تسمح بها موارد الجهاز، والّتي يُمكِن معرفتها عن طريق الأمر: ulimit -nستتغيَّر النّتيجة حسب الجهاز والموارد المُتوفّرة له. نأخذ مثالًا بجهاز ذي إمكانيّات محدودة حيثُ تُساوي هذه القيمة 1024. نُحدِّث إعدادات Nginx عبر فتح ملفّ الإعداد nginx.conf وتحريره: sudo nano /etc/nginx/nginx.confنُعطي القيمة 1 لـ worker_processes والقيمة 1024 لـworker_connections: worker_processes 1; worker_connections 1024;يجب الانتباه هنا إلى أنّ عدد الاتّصالات الكلّي الّتي يقبله Nginx في نفس الوقت يُساوي جداءَ قيمتَيْ المُتغيّريْن worker_processes و worker_connections. أي، في حال التزمنا بالقاعدة السّابقة، عددَ الأنويّة مضروبًا بعدد الاتّصالات الّتي يُمكن لكل عامِل الاستجابة لها. في مثالنا هنا النّتيجة هيّ 1024 (حاصل ضرب 1024 ب 1). يوجد أيضًا مُتغيِّر keepalive_timeout والّذي يُمكن لقيمته أن تُقلِّلَ من عدد الاتّصالات الفعليّة (سنتطرّق لهذا المتغيِّر). الصُّّوَّانات Buffersيُمكِن أن ينتُج عن تعديل حجم الصِّوان (وهي منطقة تخزين مُؤقّت ضمن ذاكرة الوصول العشوائي RAM، تُستخدم لنقل البيانات بين العمليّات) تغيّرات مُعتبرة في الأداء. إذا كان حجم الصِّوان صغيرًا فإن Nginx سيحتاج إلى إنشاء ملفّ تخزين مؤقَّت Temporary file ممّا يُؤدّي إلى كثرة القراءة والكِتابة من القرص الصّلب. توجد بعض التّعليمات الّتي نحتاج لفهمها قبل إجراء أيّ تعديل. client_body_buffer_size: حجم صِوان العميل Client (وحدة الحجم في كامل ملف الإعداد هيّ البايت Byte، يُشير حرف K إلى كيلوبايت KB) أي حجم الجسم Body في طلب Http أثناء إجراء POST. تُستخدَم إجراءات POST أساسًا عند إرسال النّماذج client_header_buffer_size: مُشابهة للتّعليمة السّابقة، ولكن لحجم التّرويسة Header في طلب Http. حجم 1KB مناسِب - غالبًا - لهذه التّعليمة. client_max_body_size: الحجم الأقصى المسموح به لطلب العميل. إذا تجاوز طلب العميل هذا الحجم فإن خادوم ويب Nginx سيُجيب بخطأ 413 (محتوى الطّلب أكبر من المسموح به Request Entity Too Large). large_client_header_buffers: العدد الأعلى والحجم الأقصى للصُّوّان بالنّسبة للتّرويسات العريضة في طلب العميل. في حال كان سطر الطّلب أكبر من حجم الصِّوّان فإن خادوم الويب يُجيب بخطأ 414 (مسار URI للطّلب أطول من المسموح به Request URI too large). نفس الشّيء بالنّسبة للتّرويسة في الطّلب إذ لا يجوز أن تتجاوز حجم الصِّوان المسموح به في هذه التّعليمة وإلاّ فإنّ Nginx سيُجيب بخطأ 400 (طلب غير صالح Bad request). يُشير العدد في هذه التّعليمة إلى العدد الأعلى من الطّلبات ذات التّرويسة العريضة (أي ترويسة بحجم أكبر من المُحدَّد في client_header_buffer_size) المسموح بها. مثال على قِيّم للمتغيّرات السّابق ذكرها: client_body_buffer_size 10K; client_header_buffer_size 1k; client_max_body_size 8m; large_client_header_buffers 2 1k;المُهَل Timeoutsالمُهل هي مُتغيّرات أخرى تُوّثّر كثيرًا على أداء Nginx. تُحدّد تعليمتَا client_body_timeout و client_header_timeout المهلة الزّمنيّة (بالثّانيّة) الّتي ينتظرها الخادوم لتلقي محتوى أو ترويسة العميل على التّوالي بعدَ استلام الطّلب منه. إن لم يتلقَّ الخادوم واحدًا من الاثنيْن خلال هذه الفترة فسيُجيب بخطأ 408 (انتهَت مُهلة الطّلب Request time out). أمّا تعليمة keepalive_timeout فتُحدّد المهلة الزمنيّة لاتّصالات استمرار النّشاط Keep-alive connections. بعبارة أخرى، سيقطع Nginx الاتّصال بعد انقضاء هذه المُهلة بغض النّظر عمّا يُريد العميل. توجد أيضًا send_timeout والّتي تُعنى بالفترة الزّمنية بين عمليّتَيْ قراءة من طرف العميل. إنْ لم يُرسِل العميل أيّ طلب خلال هذه المهلة فسيقطع خادوم الويب الاتّصالَ به، دون اعتبار لقيمة التّعليمة السّابقة. مثال على قيّم لمتغيّرات المُهَل الزّمنيّة: client_body_timeout 12; client_header_timeout 12; keepalive_timeout 15; send_timeout 10; الضّغط Compression بواسطة Gzipيُمكِن لأداة الضّغط وفكّ الضّغط Gzip المُساعدة في تحسين أداء خادوم الويب عبر التّقليل من حجم البيانات المُتبادلة؛ لكن ينبغي الحذر من رفع قيمة مستوى الضّغط gzip_comp_level لمستوى عالٍ إذ يُمكن أن يُسبّب ذلك كثرة نشاط أنويّة المُعالج. لتفعيل الضّغط نُعطي القيمة on لتعليمة gzip. تعليمة gzip_min_length تُحدِّد الحجم الأدنى لتفعيل الضّغط، أي أنّ ملفًّا بحجم أقل من قيمة هذه التّعليمة لن يخضع للضّغط. يُمكِن تحديد صيّغ الملفّات الّتي يُطبَّق عليها الضّغط عبر التّعليمة gzip_type. توجد أيضًا تعليمة gzip_proxied لتعيين طريق التّعامل مع الطّلبات الواردة من عملاء يمرّون عبر وسيط Proxy. gzip on; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain application/x-javascript text/xml text/css application/xml; التّخزين المؤقت للملفات السّاكنة  Static File Cachingيُساهم طلب التّخزين المُوقّت من جانب العميل (المُتصفِّح) في التّقليل من تبادل البيانات والحفاظ على موارد الخادوم. يجب إدراج هذه التّعليمة على مُستوى كُتلة الخادوم Server block ضمن الملف الافتراضي لإعداد كُتلة خادوم Nginx، كما في المثال أدناه. عمل التّعليمة يتمثّل في إخبار العميل بالاحتفاظ بنسخة من الملفّ وعدم تنزيلها من الخادوم طوال مدّة محدّدَة (365 يومًا في المثال). إن احتاج العميل لأحد هذه الملفّات خلال هذه المدّة فسيلجأ للنّسخة الموجودة لديه ولن يتبادل بيانات مع الخادوم. تُذكَر في التّعليمة أنواع الملفّات الّتي يُطلَب من العميل تخزينها (أساسًا صوّر وملفاّت تنسيق css وjs). location ~* .(jpg|jpeg|png|gif|ico|css|js)$ { expires 365d; } تعطيل حفظ السّجلّات Loggingيحتفظ Nginx في الإعددات الافتراضية بكلّ طلب يصل إلى الخادوم ضمن ملفّ للسّجلّات Logs. يُمكنك إيقاف هذه الخاصيّة إذا كنتَ تستخدِم أداةً لتحليل المواقع عن طريق إعطاء القيمة off للتّعليمة access_log كما هوّ موضَّح أدناه: access_log off;أعِد تشغيل خادوم الويب بعد حفظ ملفّ الإعداد حتى تُؤخذ التّعديلات في الحسبان: sudo service nginx restartخاتمةخادوم ويب مضبوط جيّدًا هو خادوم مُعد ومُهيَّأ ليتصرّف حسب نوعيّة الطّلبات الّتي ترده. ينبغي الانتباه إلى أنّه لا توجد قيمة مُثلى لا ينبغي المساسُ بها لأيّ من المتغيّرات والتّعليمات المذكورة في هذا الدّليل. يجب ضبط الإعدادات حسب كلّ حالة وما يُناسبها. إذا أردتَ الاستمرار في طريق التّحسين فيُمكنك تجربة التّوسّع الأفقي Horizontal scaling وتوزيع الحِمل Load balancing. الإعدادات المذكورة في هذا الدّليل ليست سوى بداية في الطّريق إلى تحسينات أكبر. ترجمة – وبتصرّف – للمقال How To Optimize Nginx Configuration

ماهو SFTP؟بروتوكول نقل الملفّات File Transfer Protocol المعروف اختصارًا بـFTP هو طريقة شائعة لنقل الملفّات بين نظامَيْن متباعدَيْن. أمّا بروتوكول النّقل الآمن للملفّات SFTP (اختصار لـSecure File Transfer Protocol أو SSH File Transfer Protocol) فهو بروتوكول منفصِل يأتي مُحزّمًا ب SSH ويعمل بطريقة مشابهة لFTP ولكن عبر اتّصال مُؤمَّن. ميزة SFTP هي إمكانيّة الاستعانة باتّصال مُؤمَّن للتّنقل في نظامَي الملفّات، المحلّي والبعيد؛ زيادةً على إمكانيّة نقل الملفّات بين النّظامين. يُفضَّل غالبًا استخدامُ SFTP بدلًا من FTP نظرا لميزات الأمان المُضْمَرَة وقابليّة الاعتماد على اتّصال SSH. بروتوكول FTP غير آمن ويجدُر ألّا يُستخدم إلّا في حالات محدودة ضمن شبكات موثوقة.تُتيح عدّة أدوات SFTP عبر واجهة رسوميّة، إلّا أنّنا في هذا الدّليل سنعتمد على سطر الأوامر. كيف يُستخدَم SFTP للاتّصال؟يَستعمل SFTP افتراضيًّا بروتوكول َ SSH للاستيثاق Authentication وبدء اتّصال آمن. تتوفّر لهذا السّبب نفس طرق SSH للاستيثاق في SFTP. ننصح باستخدام مفاتيح SSH بدلًا من كلمات السّرّ، على الرغم من سهولة استخدام هذه الأخيرة. أنشئ مفاتيح SSH وانقُل المفتاح العموميّ إلى النّظام الّذي تُريد الولوج إليه. هذه الطّريقة آمَن وأكثر اقتصادًا، على الأمد البعيد، في الوقت اللّازم للولوج. إن لم تكُن أعددتَ خادومك لاستخدام مفاتيح SSH فهذا الدّليل يشرح لك كيفيّة ذلك. تعني قدرتك على الاتّصال بخادومك عن طريق SSH أنّ لديك كامل المتطلَّبات لاستخدام SFTP في إدارة الملفّات. نفِّذ الأمر التّالي لاختبار الولوج بSSH: ssh username@remote_hostname_or_IPنفّذ أمر الخروج بعد نجاح الولوج بSSH: exitالأمر التّالي يبدأ اتّصالَ SSH، ثم يفتح جلسة Session من SFTP عن طريق هذا الاتّصال: sftp username@remote_hostname_or_IPستتّصل بالخادوم البعيد وسيتحوّل سطرُ الأوامر إلى سطر أوامر SFTP. الحصول على المساعدة في SFTPأفضل وسيلة لمعرفة كيف يعمل SFTP هي استخدام أمر help الّذي يُعطي ملخَّصًا من توثيق المُساعدة في SFTP. يُمكن استخدامُ أي من الطّريقتَيْن التّاليتَيْن للحصول على المساعدة: helpأو ?ستظهر في النّتيجة جميع أوامر SFTP المُتاحة: Available commands: bye Quit sftp cd path Change remote directory to 'path' chgrp grp path Change group of file 'path' to 'grp' chmod mode path Change permissions of file 'path' to 'mode' chown own path Change owner of file 'path' to 'own' df [-hi] [path] Display statistics for current directory or filesystem containing 'path' exit Quit sftp get [-Ppr] remote [local] Download file help Display this help text lcd path Change local directory to 'path' . . .سنتطرّق في الفقرات المُقبلة لبعض هذه الأوامر. التّنقّل بين الملفّات باستخدام SFTPيُتيح SFTP أوامر للتّنقّل بين ملفّات النّظام البعيد. هذه الأوامر مُشابهة لأوامر Shell الّتي تؤدّي نفس الغرض. نُريد أوّلًا معرفةَ أين نوجَد ضمن نظام ملفّات الخادوم. نُنفّذ الأمر التّالي، مثل ما كنّا سنفعل لو أنّنا في جلسة Shell اعتيّاديّة: pwdالنّتيجة هيّ: Remote working directory: /home/demouserيُمكن عرض محتوى المُجلّد عبر أمر اعتيّاديّ آخر هوّ: lsالنّتيجة: Summary.txt info.html temp.txt testDirectoryيُرجى ملاحظة أنّ أوامر SFTP ليست أوامر Shell الاعتيّاديّة رغمَ الشّبه بينهما، كما أنّها ليست بنفس الغِنى الوظيفي؛ إلّا أنّها تُتيح بعض الخيّارات الهامّة: ls -la drwxr-xr-x 5 demouser demouser 4096 Aug 13 15:11 . drwxr-xr-x 3 root root 4096 Aug 13 15:02 .. -rw------- 1 demouser demouser 5 Aug 13 15:04 .bash_history -rw-r--r-- 1 demouser demouser 220 Aug 13 15:02 .bash_logout -rw-r--r-- 1 demouser demouser 3486 Aug 13 15:02 .bashrc drwx------ 2 demouser demouser 4096 Aug 13 15:04 .cache -rw-r--r-- 1 demouser demouser 675 Aug 13 15:02 .profile للدّخول إلى مجلَّد ننفِّذ الأمر cd: cd testDirectoryرأينا كيف يُمكننا التّنقّل في ملفّات الخادوم البعيد، ولكن ماذا إن أردنا الوصول إلى الملفّات الموجودة على الجهاز المحلّي؟ يُمكننا توجيه الأوامر إلى نظام الملفّات المحلّي عن طريق كتابة حرف l أمامها (l لـ local). توجد أوامر محليّة مكافئة للأوامر الّتي عرضناها سابقًا: lpwdالنّتيجة Local working directory: /Users/demouserولعرض محتوى المجلّد الحالي على النّظام المحلّي: llsالنّتيجة: Desktop local.txt test.html Documents analysis.rtf zebra.htmlيُمكن أيضًا تغيير المجلّد الّذي نُريد التّعامل معه على الجهاز المحلّي: lcd Desktopنقل الملفّات باستخدام SFTPلن يكون للتّنقّل في نظامَي ملفّات الخادوم البعيد والجهاز المحلّي كثيرُ فائدة إن لم نستطِع نقل الملفّات بين الاثنيْن. 1- نقل ملفّات من الخادوم إلى الجهاز المحلّينُنفّذ الأمر التّالي لتنزيل ملفّ من نظام الملفّات البعيد (حيثُ remoteFile اسم الملفّ): get remoteFile Fetching /home/demouser/remoteFile to remoteFile /home/demouser/remoteFile 100% 37KB 36.8KB/s 00:01 يبحث الأمر عن ملفّ باسم remoteFile في مجلّد العمل على الخادوم ثمّ يُنزّله إلى الجهاز المحلّي ويضعه في مجلّد العمل مع المُحافظة على الاسم. إن أردنا تغيير اسم الملفّ بعد تنزيله فيمكننا تعيين الاسم الجديد عبر ذكره بعد اسم الملف المُراد نقله (localFile في حالتنا): get remoteFile localFileتوجد خيّارات تعمل مع أمر get. يُمكن على سبيل المثال، نقلُ مجلَّد وكلّ محتوياتِه عبر تحديد خيّار التّكرار كما يلي:get -r someDirectoryللحفاظ على أذونات الملفّ وتاريخ الوصول إليه نستخدم الخيّار P- أو p-: get -Pr someDirectory2- نقل ملفّات من الجهاز المحلّي إلى الخادوممن السّهل نقلُ ملفّات إلى الخادوم، وذلك عن طريق أمر put المُشابه في طريقة عمله لأمر get الّذي تحدّثنا عنه في الفقرة السّابقة: put localFileالنّتيجة: Uploading localFile to /home/demouser/localFile localFile 100% 7607 7.4KB/s 00:00 لنقل مجلّد وكلّ محتوياتِه ننفّذ الأمر (نفس خيّارات get تعمل مع put): put -r localDirectoryأداة df من الأوامر المُفيدة أثناء تنزيل Download وتحميل Upload الملفّات. تُشبه في آليّة عملها أمر df الموجود ضمن أوامر Shell، حيثُ تسمح بالتّحقّق من أنّ لديك مساحة كافيّة في القرص الصّلب قبل نقل الملفّات: df -hمثال على نتيجة تنفيذ الأمر: Size Used Avail (root) %Capacity 19.9GB 1016MB 17.9GB 18.9GB 4%يُرجى ملاحظة أنّه لا توجد نسخة محليّة من هذا الأمر، لكن يُمكننا تجاوز هذا القُصور عن طريق استخدام الأمر !. يفتح أمر ! جلسة محليّة يُمكننا تنفيذ أي أمر Shell مُتوفّر على النّظام المحلّي داخلَها. لمعرفة مساحة القرص الصّلب المُتاحة نستخدم أمر df. ! df -hالنتيجة: Filesystem Size Used Avail Capacity Mounted on /dev/disk0s2 595Gi 52Gi 544Gi 9% / devfs 181Ki 181Ki 0Bi 100% /dev map -hosts 0Bi 0Bi 0Bi 100% /net map auto_home 0Bi 0Bi 0Bi 100% /home سيُنفّذ أي أمر مُتوفّر على النّظام المحلّي كما يجب؛ للرّجوع إلى سطر أوامر SFTP نُنفّذ الأمر: exitيجب أن يظهر لديك الآن سطرُ أوامر SFTP. التّعديل على خصائص الملفّات في SFTPيسمح SFTP بإجراء العمليّات الأساسيّة لصيّانة الملفّات. هذه العمليّات مُفيدة جدًّا عند العمل على بُنية نظام الملفّات. يُمكنك على سبيل المثال، تغييرُ مالك ملفّ موجود على النّظام البعيد كما يلي: chown userID fileلاحظ أنّ أمر chown في SFTP لا يقبل أسماء مستخدمين على عكس أمر chown في Shell؛ ولكنّه يطلُب بدلًا من ذلك معرّفات المُستخدمين، UIDs. للأسف لاتوجد طريقة سهلة لمعرفة معرّف المستخدم من سطر أوامر SFTP. الطّريقة التّالية تُفيد في تجاوز هذا القصور: get /etc/passwd !less passwd النّتيجة: root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh ...لاحِظ أنّنا أضفنا الأمر ! أمام أمر من النّظام المحلّي، بدلًا من تنفيذ أمر ! ثم الأمر المحلّي منفصلًا. يصلُح هذا الاختصار لكلّ الأوامر الموجودة في النّظام المحلّي وكان بإمكاننا استخدامُه مع أمر df في الفقرة السّابقة. توجد معرّفات المستخدِمين في العمود الثّالث من ملف /etc/passwd حيثُ يُفصَل بين عموديْن بعلامة :. بنفس الطّريقة يُمكننا تغيير المجموعة المالكة للملفّ: chgrp groupID fileمرةً أخرى، لا توجد طريقة سهلة لمعرفة معرّف المجموعة؛ ولكن يُمكننا اللّجوء إلى الأوامر التّاليّة: get /etc/group !less group مثال على النّتيجة: root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: . . . نبحث عن معرّف المجموعة groupID. في العمود الثّالث يوجد معرّف المجموعة الّتي يوجد اسمُها في العمود الأوّل. بالنّسبة لأمر chmod في SFTP فيعمَل بنفس طريقة عمله على Shell. chmod 777 publicFile Changing mode on /home/demouser/publicFile لا يوجد أمر في SFTP للتّحكّم في أذونات الملفّات على النّظام محلّي، لكن يُمكنك استخدام أمر umask محلّيًّا بحيثُ تحصُل الملفّات المنقولة إلى الخادوم على الأذونات المُناسبة. طريقة الاستخدام هيّ: lumask 022 Local umask: 022ستحصُل جميع الملفّات المُنزَّلة من الخادوم الآن على أذونات 644، ما لم يُستخدَم خيّار P-. تتوفّر في SFTP أيضًا إمكانيّة إنشاء مُجلّدات على كلّ من النّظاميْن المحلّي والبعيد؛ يُؤدّي أمرا lmkdir و mkdir على التّوالي هاتيْن المهمَّتيْن. يعمل الأمران بنفس طريقة عمل mkdir على Shell. تعمل بقيّة الأوامر على نظام ملفّات الخادوم فقط: ln rm rmdir تعمل هذه الأوامر بنفس كيفيّة عمل أوامر Shell الّتي تحمل نفس الاسم. إذا أردتَ تنفيذ هذه الأوامر على نظام الملفّات المحلّي فتذكّر أنّه بإمكانك الانتقال إلى جلسة Shell عن طريق أمر !. يُمكنك كذلك تنفيذ أمر واحد على النّظام المحلّي عبر وضع علامة ! أمامه، على سبيل المثال: !chmod 644 somefileاستخدم أحد الأمريْن exit أو bye لإنهاء جلسة SFTP. byeخاتمةSFTP مُفيدٌ جدًّا لكلّ مَن يُريد إدارة الخواديم ونقل الملفّات بينها. إن كنت تستخدم FTP أو SCP لنقل الملفّات فإنّ SFTP يُمثِّل أداةً يُمكنها الجمع بين نقاط القوّة في الاثنيْن. على الرّغم من أنّ SFTP لا يُناسب كلّ حالات الاستخدام إلّا أنّ مرونتَه تجعل منه أداةً يجب أن تتوفّر لدى كل مدير أنظمة. ترجمة - بتصرّف - لمقال How To Use SFTP to Securely Transfer Files with a Remote Server.

حِزم 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.

ماهو MySQL؟ MySQL هو برنامج لإدارة قواعد البيانات Database Management System, DBMS يُساعد مستخدميه في تخزين، تنظيم والعثور على البيانات. ينتشر استخدامُ MySQL في مواقع الويب نظرًا لميزاته والمرونة الّتي يُوفّرها. نهدِف في هذا الدّرس تقديم أساسيّات استخدام MySQL بطريقة مُيَسَّرة وسهلة. كيف يُثَبَّت برنامج MySQL على توزيعتيْ Ubuntu وCentOS؟ يُمكِن تنزيلُ وتثبيتُ MySQL سريعًا عبر برنامج إدارة الحزم الخاصّ بالتّوزيعة. 1- على Ubuntu: sudo apt-get install mysql-server 2- على CentOS: sudo yum install mysql-server /etc/init.d/mysqld start ملحوظة: أثناء تثبيت MySQL سيُطلب منك إدخال ثمّ تأكيد كلمة سرّ للمستخدِم الجذر Root user في MySQL (انتبه إلى أنّ المُستخدم الّذي نتحدّث عنه هنا ليس هو المستخدِم الجذر في الخادوم، بل مستخدم جذر آخر خاصّ بـMySQL). كيف يكون الاتصال بالصدفة Shell الخاصة بـ MySQL؟ يُمكن - بعد التّثبيت - الاتّصال بMySQL عن طريق صَدَفة ولوج خاصّة عبر تنفيذ الأمر التّالي: mysql -u root -p سيُطلب منك إدخال كلمة سر المُستخدم الجذر في MySQL. يُمكنك بعدها البدء في بناء قواعد بيانات في MySQL. ينبغي الانتباه للنّقطتيْن التّاليّتيْن: تنتهي كلّ أوامر MySQL بنقطة-فاصلة إنجليزيّة (;). إن لم تختِم جملةً من أوامر MySQL بنقطة-فاصلة فلن تُتنفّذ هذه الأوامر. تُكتَب أوامرُ MySQL بأحرف كبيرة Uppercase وأسماءُ كلّ من قواعد البيانات، المُستخدمين، الجداول Tables والنّصوص بأحرف صغيرة. هذه النّقطة ليست إجبارية؛ سطرُ أوامر MySQL لا يتأثّر بحالة الأحرف Case insensitive ولكن التّفريق المذكور يجعلُ من التّمييز بين الأوامر وغيرها أكثر سهولة. إنشاء وحذف قاعدة بيانات MySQL يُنظِّم MySQL معلوماتِه في قواعد بيانات تتضمّن كلّ واحدة منها جداول ببيانات مُحدَّدة. يُمكنك عرض قواعد البيانات الموجودة في MySQL عبر الأمر التّالي (يُنفَّذ في صَدَفة MySQL وليس سطر أوامر النّظام): SHOW DATABASES; يجب أن يبدو محتوى الشّاشة لديك مشابِهًا لما يلي: mysql> SHOW DATABASES; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test | +--------------------+ 4 rows in set (0.01 sec) من اليسير إنشاءُ قاعدة بيانات عن طريق الأمر التّالي(حيثُ database name يُمثّل اسمَ قاعدة البيانات): CREATE DATABASE database name; لإنشاء قاعدة بيانات باسم events مثلًا نُنفّذ الأمر: CREATE DATABASE events; نُعيد عرضَ قواعد البيانات الموجودة في MySQL: mysql> SHOW DATABASES; +--------------------+ | Database | +--------------------+ | information_schema | | events | | mysql | | performance_schema | | test | +--------------------+ 5 rows in set (0.00 sec) نُلاحِظ وجود قاعدة البيانات الّتي أنشأناها للتّو. تُستخدم غالبًا عبارة DROP لحذف الكائنات Objects في MySQL. إذا أردتَ حذفَ قاعدة بيانات فالأمر المناسب هو DROP DATABASE، كما يلي (حيثُ database name اسم قاعدة البيانات المُراد حذفُها): DROP DATABASE database name; استخدام قاعدة بـيانات في MySQL نبدأ بملْء قاعدة البيانات بعدَ إنشائها عبر إضافة معلومات إليها. أولّ خطوة هيّ إنشاء جدول جديد داخل قاعدة البيانات. يتوجّب أوّلًا فتح قاعدة البيانات المُراد استخدامُها عبر الأمر التّالي: USE events; يُمكن -كما فعلنا مع قواعد البيانات- عرضُ الجداول الموجودة في قاعدة البيانات الّتي نستخدمُها الآن: SHOW tables; تظهر، عندَ تنفيذ الأمر السّابق رسالة Empty set (مجموعة خاليّة) دلالةً على عدم وجود جداول في قاعدة البيانات. هذه النّتيجة طبيعيّة جدًّا نظرًا لجِدّة قاعدة البيانات. إنشاء جدول في قاعدة بيانات MySQL نفترِض أنّنا نُخطّط لحَدَث يجمع بعضَ الأصدقاء. سنستخدم MySQL لتتبّع تفاصيل هذا الحدث. نُنشئ جدولًا في MySQL لهذا الغرض (تذكّر أننا نستخدم قاعدة بيانات باسم events أي أنّ الجدول الّذي سنُنشئه سيكون ضمن قاعدة البيانات هذه): CREATE TABLE potluck (id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, name VARCHAR(20), food VARCHAR(30), confirmed CHAR(1), signup_date DATE); نفّذنا عبر الأمر أعلاه الإجراءات التّالية: إنشاء جدول باسم potluck ضمن قاعدة البيانات events. إنشاء خمسة أعمِدة ضمن الجدول potluck. هذه الأعمدة هيّ: id (المُعرِِّف)، name (الاسم)، food (الطّعام)، confirmed (حضور مؤكَّد) و signup date (تاريخ التّسجيل). تطبيق الأمر INT NOT NULL PRIMARY KEY AUTO_INCREMENT للعمود id من أجل إعطاء عدد صحيح (INT في الأمر) أتوماتيكيًّا لكل صف جديد. قصرُ العمود name على عدد محارِف لا يتجاوز العشرين (20)VARCHAR. نفس الشيء بالنّسبة للعمود food الّذي يُمثِّل متعلّقات الطّعام الّتي سيجلبها كل واحد من الأصدقاء. اسم الطّعام مُكوّن من محارِف لا يتجاوز عددها الثّلاثين (30)VARCHAR. تسجيل تأكيد الحضور عبر العمود confirmed المُكوّن من محرف واحد فقط (1)CHAR. عند تأكيد الحضور نكتب Y وإلّا N. حفظ تاريخ التّسجيل عبر العمود signup_date. يطلُب MySQL كتابة التّاريخ على الشّكل yyyy-mm-dd، حيثُ yyyy السّنة مكتوبة على 4 أرقام، وmm الشهر في رقمين وdd اليوم في رقميْن أيضًا. 01-01-2015 تاريخ بصيغة صحيحة. ملحوظة: كلّ من CHAR و VARCHAR يُستخدَم للدّلالة على أن العمود يحوي محارف مع تحديد طول المحتوى، ولكن طول المحتوى من نوع CHAR ثابت، أي أنّه يجب أن يكون مساويًّا للعدد بين قوسيْن؛ في حين أنّ طول المحتوى من نوع VARCHAR متغيِّر والعدد المُذكور هو الطّول الأقصى المسموح به. نُعيد عرض الجداول الموجودة في قاعدة البيانات events: mysql> SHOW TABLES; +------------------+ | Tables_in_events | +------------------+ | potluck | +------------------+ 1 row in set (0.01 sec) نُلاحِظ ظهور الجدول potluck. إن أردتَ عرض تنظيم الجدول potluck فالأمر DESCRIBE يؤدّي هذه الوظيفة: DESCRIBE potluck; انتبِه إلى أنّ أسماء الجداول وقواعد البيانات في MySQL حسّاسة لحالة الأحرف، رغم أنّ سطر الأوامر ليس كذلك. جدول باسم potluck ليس هو نفسُه جدول Potluck أو POTLUCK. mysql>DESCRIBE potluck; +-------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | name | varchar(20) | YES | | NULL | | | food | varchar(30) | YES | | NULL | | | confirmed | char(1) | YES | | NULL | | | signup_date | date | YES | | NULL | | +-------------+-------------+------+-----+---------+----------------+ 5 rows in set (0.01 sec) إضافة معلومات إلى جدول في MySQL لدينا الآن جدول لتنظيم معلومات الحدَث، بقي ملؤه بالبيانات اللّازمة. استخدِم الأمرَ التّالي لإضافة صف بيانات جديد: INSERT INTO `potluck` (`id`,`name`,`food`,`confirmed`,`signup_date`) VALUES (NULL, "John", "Casserole","Y", '2012-04-11'); يُضيف هذا الأمر مُشاركًا جديدًا في الحدث اسمُه John وسيأتي بطنجرة (Casserole)؛ سجّلَ بتاريخ 2012-04-11 وأكّد حضوره (Y). المُعرّف سيُملأ أوتوماتيكيًّا لذا وضعنا NULL مكان العمود الأول. ستظهر بعد تنفيذ الأمر رسالة شبيهة بالتّاليّة: Query OK, 1 row affected (0.07 sec) نُضيف مشاركين جددًا بتفاصيل مختلفة إلى جدول المُشاركين عبر الأوامر التّاليّة: INSERT INTO `potluck` (`id`,`name`,`food`,`confirmed`,`signup_date`) VALUES (NULL, "Sandy", "Key Lime Tarts","N", '2012-04-14'); INSERT INTO `potluck` (`id`,`name`,`food`,`confirmed`,`signup_date`) VALUES (NULL, "Tom", "BBQ","Y", '2012-04-18'); INSERT INTO `potluck` (`id`,`name`,`food`,`confirmed`,`signup_date`) VALUES (NULL, "Tina", "Salad","Y", '2012-04-10'); لعرض جميع البيانات الموجودة في الجدول نستخدم الأمر أدناه. علامة * تعني معلومات جميع الأعمدة. mysql> SELECT * FROM potluck; +----+-------+----------------+-----------+-------------+ | id | name | food | confirmed | signup_date | +----+-------+----------------+-----------+-------------+ | 1 | John | Casserole | Y | 2012-04-11 | | 2 | Sandy | Key Lime Tarts | N | 2012-04-14 | | 3 | Tom | BBQ | Y | 2012-04-18 | | 4 | Tina | Salad | Y | 2012-04-10 | +----+-------+----------------+-----------+-------------+ 4 rows in set (0.00 sec) إن أردنا الاقتصار على المعلومات الموجودة في بعض الأعمدة وليس كلّها نذكر الأعمدة المعنيّة هنا. مثلا إن أردنا فقط الأسماء والأطعمة ننفّذ الأمر: SELECT name, food FROM potluck; تحديث بيانات موجودة في جدول MySQL يُتيح MySQL إمكانيّة تغيير بيانات موجودة في جدول. في المثال السّابق أضفنا مشارِكةً باسم Sandy. هذم المُشارِكة لم تؤكّد الحضور (قيمة العمود confirmed هي N). أبلغتْنا الآن بأنّها تأكّدت من حضورها. لتحديث عمود confirmed بالنّسبة لـsandy نُنفذ الأمر: UPDATE `potluck` SET `confirmed` = 'Y' WHERE `potluck`.`name` ='Sandy'; يُفهم الأمر أعلاه كما يلي: حدّث بيانات الجدول potluck بضبط عمود confirmed على القيمة Y إذا كانت قيمة العمود name تُساوي Sandy. كما تُلاحظ يوجد شرط للتّحديث وهو الاسم = Sandy. يُمكن أيضًا استخدامُ هذا الأمر لإضافة بيانات إلى خليّة (تقاطع عمود وصفّ) حتى ولو كانت خاويّة. إضافة أوحذف عمود من جدول في MySQL أنشأنا جدولًا ببيانات مُفيدة، ولكن تنقُصُنا معلومة مهمّة: البريد الإلكتروني للمُشترك؛ لذا سنُضيف عمودًا جديدًا نُخزّن فيه هذه المعلومة. ALTER TABLE potluck ADD email VARCHAR(40); يقول هذا الأمر "غيّر الجدول potluck عن طريق إضافة عمود جديد باسم email لا يتجاوز المُحتوى فيه 40 محرفًا". يُضاف هذا العمود افتراضًا في آخر الجدول، إذا كنتَ تُريد وضعَه في مكان مُعيّن يُمكن ذلك كما يلي: ALTER TABLE potluck ADD email VARCHAR(40) AFTER name; أي أنّ العمود الجديد سيُضاف بعد (AFTER) العمود name. بالنّسبة لحذف عمود فهو مُشابه لإضافته: ALTER TABLE potluck DROP email; حذف صفّ من جدول يُمكن إن اقتضت الحاجة حذف صفوف من الجدول عبر الأمر التّالي: DELETE from [table name] where [column name]=[field text]; حيثُ [table name] اسم الجدوَل ، [column name] اسم العمود و[field text] هيّ قيمة العمود في الصّف. نفرض مثلًا أنّنا نُريد حذف Sandy من قائمة المُشاركين: mysql> DELETE from potluck where name='Sandy'; Query OK, 1 row affected (0.00 sec) أي احذَف الصّف الّذي تُساوي فيه قيمةُ عمود الاسم Sandy. في حال وجود أكثر من شخص بهذا الاسم فسيُحذف جميع هؤلاء الأشخاص. نُعيد عرض محتوى الجدول بعد تنفيذ أمر الحذف: mysql> SELECT * FROM potluck; +----+------+-----------+-----------+-------------+ | id | name | food | confirmed | signup_date | +----+------+-----------+-----------+-------------+ | 1 | John | Casserole | Y | 2012-04-11 | | 3 | Tom | BBQ | Y | 2012-04-18 | | 4 | Tina | Salad | Y | 2012-04-10 | +----+------+-----------+-----------+-------------+ 3 rows in set (0.00 sec) لاحِظ عدم تغيّر معرّف أي واحد من المُشتركين المتبقّين. ترجمة -وبتصرّف- للمقال A Basic MySQL Tutorial لصاحبته Etel Sverdlov.

حزم 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.

مقدّمةتُمثِّل الحاويّات حلًّا أنيقًا لمن يبحث عن تصميم ونشر تطبيقات تعمل على نطاق واسع. يُوفّر Docker التّقنيّة المسؤولة عن إعداد الحاويّات، وتُساعده مشاريع أخرى عديدة عبر تطوير الأدوات المطلوبة لتحضير النّشر في بيئة العمل وللتّواصل بين مختلف مكوّناته. استكشاف الخدمة Service discovery هي إحدى التّقنيّات المركزيّة الّتي تعتمد عليها العديد من بيئات Docker. تُمكّن هذه التّقنيّة التّطبيقاتِ أو العناصرَ المُكوّنةَ لها من معرفة معلومات عن بيئة عملها. يُستعان عادةً بمخازن تعتمد صيغة مفتاح-قيمة key-value لهذا الغرض. تُستخدَم هذه المخازن أيضًا لإملاء تفاصيل حول ضبط الإعدادات. يُتيح ضبطُ أداة استكشاف الخدمة الاحتفاظَ بإعداد تشغيل الحاويّة خارجها وهو ما يُساعد من إعادة استخدام نفس الحاويّة في عدّة بيئات عبر إنشاء صورة منها. يهدف هذا المقال إلى عرض فوائد استخدام آليّة استكشاف الخدمة في بيئة عنقوديّة Clustered من مستضيفات Docker. سنُركّز على المفاهيم العامّة مع إعطاء أمثلة مُحدَّدة عندما يكون ذلك مناسِبًا. استكشاف الخدمة ومخازن الإعداد العامّة Global Configuration Storesتقوم تقنيّة استكشاف الخدمة على فكرة أساسيّة تتمثّل في أنّه يجب أن تكون لدى أي نظير من التّطبيق Instance القُدرة على التّعرف برمجيًّا على تفاصيل البيئة التي يعمل فيها. هذا الأمر ضروري لتمكين "زرع" النّظير الجديد في بيئة التّطبيق دون الحاجة للتّدخل اليدوي. تُنَفَّذ أدوات استكشاف الخدمة في العادة على هيئة سجلّات تُخزّن معلوماتٍ عن التّطبيقات أو الخدمات العاملة حاليًّا ضمن بيئة العمل، ويُمكن الوصول إليها من جميع عناصر البيئة. تُوزَّع هذه السّجلّات بين عدّة مُستضيفات لجعلها قابلةً للتّوسّعScalable وقادرةً على العمل عند حصول أخطاء. يُمكِن استخدام منصّات استكشاف الخدمة لحفظ أيّ نوع من معلومات الإعداد، رغم أنّ الهدف الأوليّ من إنشائها هو تقديم بيانات الاتّصال لربط العناصِر في ما بينها. تستفيد العديد من عمليّات النّشر من هذه الميزة عن طريق حفظ بيانات الإعداد لدى أداة الاستكشاف؛ حيثُ إن الحاويّات تستطيع تغيير سلوكها اعتمادًا على ما تعثُر عليه من إعدادات، إذا كانت مضبوطةً للقيّام بذلك. كيف تعمل أداة استكشاف الخدمة؟تُوفِّر كل أداة استكشاف واجهةَ تطبيقات برمجيّة API يُمكن للعناصِر استخدامُها لضبط إعداداتها أو الحصول على بيانات. لهذا السّبب نجد أنّ كل تطبيق يُضمِّن عنوانَ استكشاف الخدمة مُباشرةً في المصدَر Source أو يُوفّره كخيّار أثناء التّشغيل. تُتيح أدوات استكشاف الخدمة الوصول إلى القيّم الّتي تحتفِظ بها عن طريق طلبات Http. تسجيلُ التّطبيق لنفسه لدى أداة الاستكشاف مباشرةً بعد بدْء عمله، هو أولى خطوات عمل خدمة الاستكشاف؛ فيُسجّل كل المعلومات الّتي ستحتاجها بقيّة العناصر عند محاولتها الاستفادة من الخدمة الّتي يُقدِّمها.يجب على قاعدة بيانات MySQL مثلًا، تسجيلُ عنوان IP ومنفَذ Port الوصول للبرنامج؛ يُمكن أن تُضيف أيضًا اسمَ المُستخدِم واعتمادات Credentials الحساب المطلوبة لتسجيل الدّخول. أول ما يقوم به تطبيق يُريد الاستفادة من خدمةٍ مّا عند بدْء تشغيله، هوّ طلب أداة الاستكشاف لإعطائه معلومات عن نقطة اتّصال مُعرَّفة مُسبَقًا للارتباط بالخدمة. يُمكنه بعد ذلك التّفاعل مع العناصِر الّتي يحتاجها وفقًا للمعلومات الّتي يعثُر عليها. مُوزِّع الحِمل Load balancer مثالٌ جيّد، حيثُ بإمكانه - عن طريق أداة الاستكشاف - العثور على معلومات عن كل الخواديم الخلفيّّة Backend servers حتّى يُوجِّهَ إليها حركة الاتّصالات حسب إعداداتِها والمعلومات الّتي تُغذّي بها (أي الخواديم) أداةَ الاستكشاف. ينتُج عن استخدام أداة استكشاف وضعُ تفاصيل الإعداد خارجَ إطار الحاويّة. يجعل هذا الأمر الحاويّات أكثر مرونة وأقل ارتهانًا لإعدادات مُعيَّنة؛ كما أنّه يُسهِّل على عناصِر التّطبيق التفاعلَ مع نظائر جديدة من نفس الخدمة متيحًا بذلك إمكانيّة الإعداد الدّيناميكي. كيف يُؤثِّر تخزين الإعدادات؟تُعدّ القُدرة على تخزين أي نوع من بيانات الإعداد، بما فيها بياناتٌ تطلُبها أجزاء التّطبيق أثناء تنفيذها، إحدى المزايا الأساسيّة في أي نظام عمومي موزَّع لاستكشاف الخدمة. يعني هذا أنّه بالإمكان وضع بيانات إعدادٍ أكثر خارج الحاويّة، ضمن بيئة تنفيذ أوسع. يجب أن تُصمّم التّطبيقات - حتّى تعمل هذه الطّريقة بشكل فعّال - بعدد معقول من الخيّارات الافتراضيّة Defaults على أن يكون من الممكن إبدالُها بقيّم أخرى يُتَحصَّل عليها من مخزن الإعدادات أثناء التّنفيذ. تجعل هذه الطّريقة من استخدام مخزن الإعداد مُماثِلًا لاستخدام خيّارات سطر الأوامر Command line flags (أو Command line options) مع فرق أنّ استخدام مخزن إعدادات متاح للعموم يسمح بإنشاء وتشغيل نظائر أخرى من نفس العُنصر دون جهدٍ زائد. كيف يُساعِد مخزن الإعدادات في إدارة العُنقود؟لا يظهر للوهلة الأولى، العونُ الّذي يُقدّمه مخزنٌ مُوزَّع للإعدادات يستخدم صيغة مفتاح-قيمة، في حفظ وإدارة عُضويّات Membership العنقود. مخازن الإعدادات هي في الواقع البيئة المُثلى لحفظ آثار عضويّات المُستضيفات ووضعها تحت تصرّف أدوات إدارة العنقود. في ما يلي بعض معلومات المُستضيفات الّتي يُمكن حفظها على شكل مفتاح-قيمة في مخازن إعدادات مُوزَّعة: عناوين IP المُستضيفات. معلومات الاتّصال بالمُستضيفات. بيانات وصفيّة Metadata ومُلصقات Labels يُمكِن التّحكم بها من أجل اتّخاذ قرارت تتعلّق بالجدولة Scheduling. الدّور Role داخل العنقود (في حال استخدام نموذج قائد/تابِع Leader/follower model). لن تضطّر في الظّروف الاعتياديّة إلى الاهتمام بهذه التّفاصيل عند استخدام أداةٍ لاستكشاف الخدمة؛ ولكنّها وسيلة تُوفّر لأدوات الإدارة إمكانية الاستعلام أو التّعديل على معلوماتٍ تتعلّق بالعنقود. ماذا عن التّعرّف على الإخفاق Failure detection أثناء التّنفيذ؟يُمكن وضع آليّة للتّعرّف على إخفاق التّطبيقات عبر عدّة وسائل. السّؤال الّذي يجب طرحُه هنا هل ستُحدَّث خدمة الاستكشاف عند توقّف تطبيق عن العمل لتعكس حالة التّطبيق من حيثُ إنه لم يعُد يعمل؟ هذا النّوع من المعلومات حيوي للتّقليل من إخفاق الخدمة. تُتيح العديدمن أدوات استكشاف الخدمة تعيينَ قيّم مع مهلة زمنيّة يُمكِن ضبطُها Configurable Timeout. في هذه الحالة يضبُط العنصُر قيمةً ويُرفق معها مهلة زمنيّة، ثم يُعلِم أداة الاستكشاف بانتِظام بوجوده وفي نفس الوقت يُعيد تعيين المُهلة. يُعتبر العُنصُر خارج الخدمة وتُسحب معلوماته من مخزن الإعدادات عند بلوغ المُهلة الزّمنيّة المُحدَّدَة دون أن يتّصل بأداة الاستكشاف لإعلامها بوجوده وإعادة تعيين المُهلة. يتغيَّر طول المُهلة حسب التّطبيق والمُدّة الّتي يحتاجها للتّعامل مع إخفاق أحد العناصِر المُكوّنة له. توجد طريقة أخرى تعتمد على إنشاء حاويّة مُساعدة مع كل عنصُر، تقتصر مهمّة الحاويّة المُساعِدة على التّحقق من سلامة العنصُر دورِيًّا ثمّ تحديث السّجل في حال توقّف العنصُر عن العمل. نقطة ضعف هذه الطّريقة هي الحاويّة المُساعدة الّتي يُمكن أن تتوقّف عن العمل وهو ما قد ينتُج عنه معلومات خاطئة في مخزن الإعدادات. تتغلّب بعض النُّظُم على هذه المسألة عن طريق إضافة إمكانيّة التحقّق من سلامة الحاويّة إلى أداة الاستكشاف. يُمكن لخدمة الاستكشاف بهذه الطّريقة فحصُ العناصِر المُسجَّلة لديها دوريًّا للتّأكد من حالتها. ماذا عن إعادة ضبط الخدمة عند التّعديل على بيانات الإعدادات؟تُمثّل إعادة الضّبط ديناميكيًّا إحدى التّحسينات الأساسيّة على نموذج استكشاف الخدمة الأصلي. تعني إعادةُ الضّبط ديناميكيًّا قدرةَ أداة الاستكشاف على التّفاعل مع التّغييرات في مخزن الإعداد وضبط عناصِر التّطبيق حسب التّعديلات الجديدة؛ عكسَ النّموذج الأصلي الذي يقتصِر تأثيره على الإعداد الابتدائي للعُنصُر(عند بدْء تشغيله). على سبيل المثال، حينَ يفحص مُوزِّع حِمل الخواديمَ الخلفية ويجد أنّ أحدها توقّف عن العمل؛ فإنّه سيحتاج لأخذ ذلك بالحُسبان من أجل تعديل إعداداتِه لتُناسِب الوضعيّة الجديدة. توجد عدّة مشاريع تُركِّز على موزّع الحِمل نظرًا لكونه أحد التّطبيقات الأكثر احتيّاجًا لهذه الخاصيّة. يتميّز HAProxy بأنّه أحد أكثر هذه المشاريع شُهرةً لما يتمتّع به من شعبيّة بين المُهتمّين بآليّات توزيع الحِمل، في حين أنّ مشاريع أخرى تتمتّع بمرونة أكبر حيثُ بالإمكان استخدامُها لإحداث تغييرات في كل أنواع البرامج. تستعلم هذه الأدوات بانتظام خدمةَ الاستكشاف بحثًا عن تغييرات، وفي حال وجودها تستخدم نظام قوالب لتوليد ملفّاتِ إعداد جديدةً تُدمِج القيّم الّتي أرسلتها خدمة الاستكشاف. في الأخير يُعاد تشغيل التّطبيق لأخذ التّغييرات الجديدة في الحسبان. يحتاج هذا النّوع من الإعداد الدّيناميكي إلى تخطيط أكبر أثناء عمليّة بناء التّطبيق إذ أنّ كل هذه الآليّات يجب أن تتواجد في الحاويّة الّتي تُمثّل العُنصر، وهو ما يجعل من الحاويّة مسؤولةً عن تعديل إعداداتِها. يُمثِّل استخراج القيّم المطلوبِ كتابتُها في سجلّ استكشاف الخدمة، وتصميم بنية بيانات Data structure تسهُل الاستفادة منها تحدِّيًا آخر في بناء نظام إعداد ديناميكي. مع ذلك يُمكن لهذا النّظام أن يُقدّم مرونةً كبيرةً في الإعداد. ماذا عن الأمان؟يطرح كثيرٌ من المبتدئين مسألة الأمان عند الحديث عن مخازن الإعدادات المتاحة للعموم. هل من المُناسِب حقًّا حفظُ بيانات الاتّصال في أماكن يُتاح الوصول إليها للعموم؟ تختلف الإجابة على هذا السؤال كثيرًا حسب ما تُريد حفظَه في مخزن الإعدادات وحسب عدد طبقات الأمان الّتي ترى أنّها مناسِبة لتأمين بياناتك. تسمح أغلب أدوات استكشاف الخدمة بتعميّة Encryption الاتّصالات عن طريق SSL/TLS. يكفي وضعُ بعض أدوات الاستكشاف الّتي لا تهتم كثيرًا بالخصوصيّة Privacy في شبكة خاصّة، لكن وجود تأمين إضافي سيُفيد على الأرجح الكثير من التّطبيقات. يكمُن أحد الحلول الأمنيّة في إتاحة الوصول العموميّ إلى أداة الاستكشاف ولكن تُعمَّى (تُشَفَّر) البيانات المكتوبة ضمن سجل الأداة بحيثُ يتوجَّب على أي تطبيق يُريد الاستفادة من معلومة متاحة في السّجلّ امتلاكُ المفتاح السّري الخاص بهذه المعلومة حتّى يستطيعَ فكّ تعميّة Decrypty البيانات. تلجأ أدوات أخرى إلى مُقاربة مختفلة أساسُها إدخال قوائم تحكّم في الوصول Access control lists (أو ACL اختصارًا) لتقسيم فضاء المفاتيح إلى عدّة مناطِق، تُعرّف كل واحدة منها مُتطلّبات مُحدَّدة ويُعتَمَد عليها لإدارة مُلكيّة وإمكانيّة الوصول إلى المعلومات. تُؤسّس هذه المُقاربة لطريقة بسيطة تُوفّر لبعض الأطراف إمكانيّة الحصول على معلومات بينما تُبقيها خارج مُتناوَل أطراف أخرى. يُمكن ضبط كل عنصُر ليُتاح له الوصول إلى المعلومات الّتي يحتاجها فقط. ما هيّ أدوات استكشاف الخدمة الأكثر انتِشارًا؟نعرِض في الفقرات التّاليّة لبعض المشاريع الّتي تعمل على تنفيذ المبادئ العامّة المذكورة في الفقرات السّابقة. من أكثر هذه المشاريع رواجًا: etcd: أنشأها مطوّرو توزيعة CoreOS لتوفير أداة استكشاف خدمة وإعداد عموميّ مُوزَّع لكل من الحاويّات والأنظمة المُستضيفة. تمتلك هذه الأداة واجهةَ تطبيقات برمجيّة API يُتوَصَّل إليها عن طريق Http إضافةً إلى سطر أوامر على كل مُستضيف. consul: تتميّز هذه الأداة بالخصائص المتقدّمة الّتي توفّرها، مثل التحقّق من صلاحيّة الإعداد، قوائم التّحكّم في الوصول ACL، إعداد HAProxy، ...إلخ zookeeper: وهيّ أداة أقدم من السّابقتيْن. تتميّز بمنصّة أكثر ثباتًا، وذلك على حساب نقص بعض الوظائف الحديثة. المشاريع التّاليّة تعمل على تمديد وظيفة الأداة القاعديّة لاستكشاف الخدمة: Crypt: يُعطي التّطبيقات إمكانيّة تعميّة المعلومات التّي تحتفِظ بها في مخزن الإعدادات عن طريق مفتاح تعميّة عمومي Public key. يُمكِن للتّطبيقات الّتي لديها مفتاح فك التّعميّة Decryption key فقط قراءةُ هذه المعلومات. Confd: ويهدِف إلى إضافة قابليّة إعادة الضّبط ديناميكيًّا والتّحكّم في التّطبيقات حسب التّغييرات في خدمة الاستكشاف. يتضمّن هذا المشروع عدّة وظائف أهمّها مراقبَة مخزن الإعدادات بحثًا عن تعديلات، ونظامًا للقوالب يُستخدم لإنشاء ملفّات إعداد جديدة اعتمادًا على المعلومات المُمجمَّعة وقابليّة إعادة تحميل التّطبيقات عند تغيير إعداداتِها. vulcand: يعمل Vulcand كموزِّع حِمل بين مجموعات من العناصِر. يتعرّف هذا المشروع على أداة etcd ويُمكنه العمل وفقًا للتّغيرات في مخزن الإعدادات. marathon: وهو في الأساس مُجدوِل Scheduler (المقال الأخير من هذه السّلسلة يتناول المُجدوِلات)، ولكنّه يُضمّن آليّة بسيطة لإعادة تحميل HAProxy عند التّغيير على خدمات يجب توزيع الحِمل بينها. frontrunner: يُلحق بmarathon لتقديم آليّة متقدّمة لتحديث HAProxy. synapse: يُضمِّن HAProxy لتوجيه تدفّق البيانات بين مختلف عناصِر التّطبيق. nerve: يُستخدَم بالتّوازي مع synapse للتحقّق من صلاحيّة الإعداد لكل واحد من نظائر العُنصُر. عند توقّف أحد العناصِر عن العمل يُعلِم nerve أداة synapse لأخذ ذلك بالحسبان. خاتمةيسمح استكشاف الخدمة والمخازن العموميّة للإعدادات لحاويّات Docker بالتكيّف مع البيئة المُحيطَة وتغيير سلوك العناصِر الموجودة فيها، وهي مُتطلَّبات أساسيّة لتوفير قابليّة التوسّع والانتشار بسهولة ودون تدخّل يديوي.   ترجمة -وبتصرّف- للمقال The Docker Ecosystem: Service Discovery and Distributed Configuration Stores

مقدِّمةتوجد دائمًا العديدُ من العوائق التي تقِف في طريقك أثناء الانتقال بين مختلف مراحل دورة التّطوير حتى الوصول إلى مرحلة الإنتاج. فإضافة إلى التّأكّد من سلامة عمل التّطبيق في بيئات مختلفة، فقد تُواجهك مشاكلَ مع تتبّع الاعتماديّات Dependencies، التوسّع Scaling، وتحديث كل واحد من العناصر المكوِّنة للتّطبيق دون أن يُؤثِّر ذلك على التطبيق ككلّ. يُحاول Docker التغلّب على العديد من هذه المشاكل عن طريق الحاويّات Containers وأسلوب التّصميم خَدَميّ التّوجّه Service-oriented الّذي يعتمده. تُقسَّم التّطبيقات إلى عناصِر وظيفيّة، تُحَزَّم منفردةً مع كامل اعتماديّاتها، يُمكن إدارتُها ونشرُها بسهولة على مِعماريّات Architectures مُتباينة. تمنح هذه الطّريقة أيضًا سهولةً أكبر أثناء التّوسّع أو التّحديث. نستعرِض في هذا المقال فوائدَ استخدام الحاويّات، وكيفَ يُساعد Docker في حلّ بعض المشاكل المذكورة أعلاه. Docker هو العنصر المركزي في النّشر المُوزَّع للحاويّات، حيثُ يوفِّر سهولةً في الإدارة وقابليةً للتّوسّع. تاريخ مُختصَر لإعداد الحاويّات على Linuxتدعمُ بعض أنظمة التّشغيل الشّبيهة بيونيكس Unix-like OS تقنيّات إعداد الحاويّات منذُ أكثر من عقد من الزّمن، فمفهومَا الحاويّة Container والعزل Isolation ليسَا جديديْن في عالم الحواسيب. على سبيل المثال، أُضيفَت بيئة LXC، التّي شكّلت قاعدةً لتقنيات تاليّة في إعداد الحاويّات، إلى النّواة Kernel في العام 2008. مَزَجت LXC بين استخدام مجموعات التّحكم Control groups (تسمح بعزل وتتبّع استخدام موارد الجهاز، يُشار إليها بـ cgroups اختصارًا) الموجودة في النّواة وفضاءات الأسماء Namespaces (عزل المجموعات بحيثُ لا تشعُر كل مجموعة بوجود أخرى) لإجراء عمليّة عزل بسيطة. قُدِّم Docker في ما بعد بوصفه طريقةً لتبسيط الأدوات المطلوبة لإنشاء وإدارة الحاويّات، فاستخدَم أوّلًا LXC كتعريف Driver للتّنفيذ، قبل أن ينتقل إلى استخدام مكتبة Library تُدعَى libcontainer أُعدَّت خصّيصًا لهذا الغرض. لم يُضِف Docker العديد من الأفكار غير الموجودة أصلًا، إلّا أنّه جعل إنجازَ هذه الأفكار متاحًا لشريحة أكبر من المُطوِّرين ومديري الأنظمة عن طريق تبسيط العمليّة وتوحيدها عبر نفس الواجهة وهوّ ما أدّى إلى تحفيز الاهتمام بإعداد الحاويّات على Linux بين المطوِّرين. تجدُر الإشارة إلى أنّه رغم تركيزنا هنا على حاويّات Docker التّي أوصلتْها شعبيّتُها المتناميّة إلى مرتبة المعيار Standard، إلّا أنّ بعضَ ما سنذكُره ينطبِق على الحاويّات بشكل عامّ. ما الّذي تُضيفه الحاويّات؟تأتي الحاويّات بالعديد من الفوائد الّتي تجذِب إليها كلًّا من المطوِّرين، مديري الأنظِمة، وفِرق العمليّات. في ما يلي بعضٌ من هذه الفوائد. 1- عزل نظام التّشغيل المُستضيف عن التّطبيق الموجود في الحاويّةتهدِف الحاويّات إلى أن تكون معياريّةً بالكامل؛ يعني هذا أنّ الحاويّة تتّصل بالمستضيف وبكل ما يوجد خارج الحاويّة عن طريق واجهات مُعرَّفة. يجب ألّا ينشغل تطبيقٌ يعمل عبر حاويّة بمعرفة تفاصيل موارد المُستضيف أو معماريّته. يُسهِّل هذا الأمر من افتراضات المطوِّر عن بيئة عمل التّطبيق. بالمثل، يتعامل المُستضيف مع كلّ حاويّة على أنّها صندوق أسود؛ فلا يهتمّ بتفاصيل التّطبيق الموجود بداخلها. 2- سهولة التّوسّعوهوّ أحد فوائد عزل المُستضيف عن التّطبيق. يُصبِح التوسّع سهلًا للغاية عند استخدام أسلوب تصميم جيّد أثناء تطوير التّطبيق. يُشكّل التّصميم خدميّ-التّوجّه (سنناقشه لاحقًا) عند دمجه بإعداد الحاويّات؛ اللّبنة الأساسيّة لسهولة التّوسّع . يُمكن -مثلًا - لنظام مُكوَّن من عدّة حاويّات أنشأه مطوّر على حاسوبه الشّخصي أن يتوسَّع أفقيًّا ضمن منطقة الإدراج Staging أو الاختبار Testing، وعند نقل الحاويّات إلى بيئة الإنتاج يستمرّ في التّوسّع مجدّدًا. ملحوظة: المقصود بالتّوسّع الأفقي Horizontal scaling هو استعمال عدّة خواديم وتشغليها بحيث تظهر وكأنّها خادوم واحد، أما التّوسّع العمودي Vertical scaling فيُقصَد به إضافة موارد جديدة لنفس الجهاز (زيادة حجم ذاكرة الوصول العشوائي RAM على سبيل المثال). لا يحتاج التّوسّع الأفقي في الغالب لإعادة تشغيل الجهاز أو الخادوم. 3- إدارة سهلة لاعتماديّات وإصدارات التّطبيقتُمكِّن الحاويّات المُبرمجين من تجميع تطبيق - أو عنصُر منه - مع كامل اعتماديّاته والتّعامل معه كوحدة مستقلّة. لا يهتمّ النّظام المُستضيف بالاعتماديّات الخاصّة بتطبيق معيَّن، فكل المطلوب منه هوّ أن تكون لديه القدرة على تشغيل حاويّات Docker. تجعل هذه الطّريقة من إدارة الاعتماديّات أمرًا سهلًا؛ كما أنّها تُسهّل من إدارة إصدارات البرنامج Versions، فالأنظمة المُستضيفة وفرق العمليّات ليست مسؤولة عن إدارة الاعتماديّات المطلوبة من طرف التّطبيق، فكل ما يحتاجه التّطبيق - إذا استثنينا علاقته بالحاويّات الأخرى - موجود داخل الحاويّة. 4- بيئات تنفيذ Execution معزولة وخفيفة جدَّاعلى الرّغم من أن الحاويّات لا توفّر نفس المستوى من العزل الّذي توفّره الحوسبة التّخيّلية Virtualization إلّا أنّها تفضُلُها من ناحية خفّة بيئة التّنفيذ. تُعزَل الحاويّات على مستوى العمليّات Process Level وتشترك في نواة المُستضيف. يعني هذا أنّ الحاويّة لا تتضّمّن نظامَ تشغيل كاملًا وهو ما يؤدّي إلى بدْء تشغيل يكاد يكون لحظيًا. يُمكن للمطوّرين تشغيل مئات الحاويّات على حواسيبهم الشّخصيّة دون أيّة مشاكل. 5- طبقات مُشتركة Shared layeringجانب آخر تتجلّى فيه خفة الحاويّات هو تقاسمُها لنفس الطّبقات الأساسيّة. يعني اشتراكُ عدّة حاويّات في نفس الطّبقة، الحدَّ من الاستنساخ/التّضاعف Duplication؛ أي استخدامًا أقلّ لمساحة القرص الصّلب والموارِد بشكل عامّ عند إنشاء حاويّات جديدة. 6- قابليّة التّجميع والتّنبّؤ Composability and Predictabilityتُعرِّف ملفّات Docker بالضّبط الإجراءاتِ المطلوبةَ لإنشاء صورة جديدة من حاويّة، وهو ما يُمكِّن من كتابة بيئة التّنفيذ كما لو كنتَ تكتب أسطُرًا برمجية وحفظها عن طريق نظام لإدارة الإصدارات Version Control System (أو VSC اختصارًا) إذا رغبتَ في ذلك. يُنتِج نفس ملف Docker عند إنشائه في نفس البيئة، يُنتِج دائمًا صورةً لنفس الحاويّة. استخدام ملفّات Dockerfiles لعمليّات البناء المُتكرّرة المُتماثِلةيُمكن بناء صوّر Images من حاويّات Docker بطريقة تفاعليّة ولكن من الأفضل غالبًا وضع خطوات الإعداد بعد الانتهاء من تحديدها في ملف Dockerfiles. ملفّات Dockerfiles هيّ ملفّات بناء بسيطة تُعرِّف آليةَ بناء حاويّة انطلاقًا من نقطة بدْء معروفة. استخدام هذه الملفّات بسيطٌ جدًّا ولديها العديد من الفوائد، نذكر منها: سهولة إدارة الإصدارات: يُمكِن حفظ ملفّات Dockerfiles ضمن برنامج لإدارة الإصدارات لتتبّع التّغييرات والتّراجع عن أي أخطاء عند اكتشافها. قابليّة التّنبّؤ: بناء الحاويّات انطلاقًا من ملفات Dockerfiles يُساعِد في التّقليل من الأخطاء البشريّة أثناء عمليّة إنشاء الحاويّات. قابليّة المُحاسبة Accountability: من الجيّد عند التّخطيط لمشاركة صوّر الحاويّات، توفيرُ ملف Dockerfile المُستخدَم لإنشاء الحاويّة لاستخدامه كوسيلة للتّدقيق في عمليّة البناء، حيثُ يُمكن النّظر إليه باعتباره سجِلًّا للأوامر التي نُفِّذَت لإنشاء الحاويّة. المرونة Flexibility: يسمح إنشاءُ حاويّات انطلاقًا من ملفّات Dockerfiles بتجاوز الخيّارات الافتراضيّة المُعطاة في عمليّات البناء التّفاعليّة. يعني هذا أنّك عند استخدام Dockerfiles لن تحتاج لتغيير كل الإعدادت الافتراضيّة الّتي لا تُناسِب احتيّاجاتِك. من هذا المُنطَلَق فإن ملفّات Dockerfiles أداة رائعة لأتمتة Automate إنشاء الحاويّات والتّأسيس للعمليّات المتكرّرة. بُنية التّطبيقات الّتي تعمل عبر الحاويّاتبُنية التّطبيق هيّ أحد أهم المشاغِل الّتي يجب أخذها بالاعتبار عند تصميم تطبيقات مُعدّة للنّشر عبر حاويّات.عمومًا، تعمل الّطبيقات المنشورة عبر حاويّات بشكل أفضل عند تنفيذ تصميم خَدَمي التّوجّه. تُقسِّم التّطبيقات الّتي تتبع تصميمًا خَدَمي التّوجّه وظيفتَها بين عدّة عناصر متمايِزة تتواصَل في ما بينها عبر واجهات مُعرَّفة جيّدًا. تُشجّع تقنيّة الحاويّات بذاتها هذا النّوع من التّصميم إذ أنّه يسمح لكلّ عنصُر بالتّوسّع والتّرقية بشكل منفصل عن بقيّة العناصِر. يجب أن تتوفّر الخصائص التّاليّة في التّطبيقات الّتي تتبع طريقة التّصميم خَدَمي التّوجّه: لا تعتمد على أي وظيفة خاصّة بنظام تشغيل مُستضيف مُحدّد. يُوفّر كل عنصُر واجهة تطبيقات برمجيّة API مُتجانِسة يُمكن للزّبائن عبرها الاتّصال بالخدمة. يجب أن تأخذ الخدمةُ متغيّراتِ البيئة Environmental variables الّتي تعمل بها أثناء الإعداد الابتدائي. يجب أن تُحفَظ بيانات التّطبيق خارج الحاويّة في تجزئات مُرَكَّبة Mounted volumes على النّظام أو في حاويّات خاصّة بالبيانات. تُمكِّن هذه الإستراتيجيّات من استبدال أي عنصُر أو تحديثه بشكلٍ مستقل شرطَ الحفاظ على واجهته البرمجيّة، كما أنّها تُساعد في التّركيز على التّوسّع الأفقي حيثُ يُوَّسَّع العنصُر الذي يُعرقل أداء التّطبيق (نقطة ضعف).يُمكن لكل عنصر تعريفُ قيّم افتراضيّة يُمكن الإقلاع باستخدامها في فترة معقولة، بدلًا من برمجة قيّم خاصّة مباشرَةً في التّطبيق. يُمكن للعنصُر استخدامُ هذه القيّم في الحالات الطّارئة مع تفضيل قيّم يُمكن الحصول عليها عن طريق بيئة العمل. يُتَحصَّل على قيّم من بيئة العمل عادةً عن طريق أدوات مُساعدة على استكشاف الخدمة، يستطيع العُنصر إرسال استعلامات إليها أثناء بدْء التّشغيل. يُسهِّل إخراج بيانات الإعداد من الحاويّة ووضعُها في بيئة العمل من إجراء تعديلات على سلوك التّطبيق دون الحاجة لإعادة بناء الحاويّة، إضافةً إلى إمكانيّة التّأثير على نماذج عدّة من نفس العُنصُر عن طريق إعداد واحد. على العموم فإنّ أسلوب التّصميم خَدَمي التّوجّه يندمج جيّدًا مع إستراتيجيّات الإعداد عن طريق بيئة العمل، فكلّ منهما يسمح بعمليّات نشر مرنة وتوسّع أكثر مباشرة. استخدام سجلّ Docker Registry لإدارة الحاويّاتتحدّثنا عن الخطوة الأولى المُتمثِّلة في تقسيم التّطبيق إلى عناصر وظيفية مُعدَّة للتّواصل بشكل صحيح مع بقيّة الحاويات وقيّم الإعداد الموجودة في بيئة العمل. نأتي الآن للخطوة الثّانية وهي جعل صوّر الحاويّات مُتاحة عبر سجل. رفع صوّر الحاويّات إلى سجل يُعطي مستضيفات Docker إمكانيّة تنزيل هذه الصوّر بمجرَّد معرفة أسمائها ثم إنشاء حاويّات مُماثلة لها بعد ذلك (نظائر Instances). توجد العديد من سجلّات Docker متوفّرة لهذا الغرض؛ بعضُها عمومي يُمكن للجميع عرض واستخدام الصّوّر الموجودة فيها، والآخر خاص. يُمكن أيضًا إضافة وسوم Tags لتسهيل الوصول إلى وتحديث الحاويّات. خاتمةيضع Docker القواعدَ الأساسيّة اللّازمة للنّشر الموزَّع للحاويّات. يجعل عزل عناصر التّطبيق في حاويّات خاصّة بها من التّوسّع الأفقي عمليّةً سهلة تقتصِر على إطلاق نظائر جديدة لنفس العُنصُر أو إيقاف أخرى. يُوفِّر Docker الأدوات المطلوبة ليس فقط لبناء حاويّات بل أيضًا لإدارتها وتشاركها مع مستخدمين أو مُستضيفين جُدُد. في المقال التّالي من هذه السّلسلة سنتطرّق للكيفيّة الّتي تُساهِم بها استكشاف الخدمة ومخازن الإعداد المُوزَّعة عمومًا في نشر الحاويّات عبر عنقود من المُستضيفات. ترجمة -وبتصرّف- للمقال The Docker Ecosystem: An Overview of Containerization

وفّر Docker للعديد من المُطوّرين ومُدراء الأنظمة منصّة سهلة تسمح لهم ببناء ونشر تطبيقات قابلة للتّوسّع. سنستعرض في هذه السلسلة (Docker Ecosystem) كيف يوفّر Docker والمُكوّنات التّي صُمّمت للتكامل معه الأدوات اللازمة لتوفير تطبيقات مُوزّعة عالية التّوفر 1- مقدّمةيُطلَق مصطلح إعداد الحاويات Containerization على نشر وتوزيع التّطبيقات بشكل محمول ويُمكن التنبؤ به predictable. نلجأ - للحصول على هيئة النّشر والتّوزيع المذكورة آنِفًا - إلى تحزيم العناصِر واعتماديّاتِها في بيئة عمليّات قيّاسيّة، معزولة وخفيفة تُسمَّى حاويّة Container. تهتمّ الكثير من المنظَّمات الآن بتصميم تطبيقات وخدمات يسهُل توزيعها ونشرُها عبر نُظُم موّزَّعَة ممّا يُمكِّن من التّوسّع Scale بسهولة والتّغلّب على إخفاق التّطبيقات والأجهزة أثناء العمل. حفَّز Docker -الّذي هو منصّة لإعداد الحاويّات أُعِدَّ لتبسيط وتوحيد معايير النّشر في بيئات مختلفة- تبنّي هذا الأسلوب في تصميم وإدارة الخدمات؛ إذ أنّ الكثير من البرامج أُنشِئت لتتّخد من هذا الأسلوب في الإدارة المُوَزَّعة للحاويّات، قاعدةً تُبنى عليها. 2- إعداد حاويّات Dockerعلى الرّغم من وجود أنظمة أخرى لإعداد الحاويّات إلا أنّ Docker هو الأكثر استخداما هذه الأيّام نظرًا للبساطة الّتي يوفّرها في إنشاء وإدارة الحاويّات إضافةً إلى سهولة إدماجه في عدد من المشاريع مفتوحة المصدر. يُمكن، في الصّورة السّابقة، رؤية كيف ترتبط الحاويّات مع نظام التّشغيل المُستضيف (عَرض مُبسَّط). تعزِل الحاويّات كلّ تطبيق على حِدة مع استغلال موارد نظام التّشغيل الّتي يعمل Docker على تقديمها بطريقة مُجرّدة Abstracted (لا تظهر التّعقيداتُ المُصاحِبة لهذه الموارد للتّطبيقات، حيثُ يتولّى Docker التعاملَ معها). نرى في الجانب الأيمن أنّه يُمكن بناء الحاويّات اعتمادًا على طبقات Layers؛ بحيثُ تشترك عدّة حاويّات في الطّبقات الموجودة في الأساس وبالتّالي التّقليل من استخدام الموارد. المزايا الأساسيّة لـ Docker هيّ: التّخفيف من استخدام الموارد: تعمل الحاويّات على مستوى الـ Process وتستخدم نواة Kernel نظام التّشغيل المُستضيف ، بدلًا من الحوسبة التّخيّليّة Virtualization لكل نظام التّشغيل. قابليّة النّقل Portability: تُضَمَّن كلّ اعتماديّات التّطبيق داخل الحاويّة ممّا يسمح بتشغيل التّطبيق على أي مستضيف يعمل عليه Docker. إمكانية التّنبؤ Predictability: لا يهتمّ النّظام المُستضيف بما يجري داخل الحاويّة، كما أنّ الحاويّة لا تهتمّ بماهيّة نظام التّشغيل الذّي تعمل عليه، فالواجهات Interfaces معياريّة ويُمكن التّنبّؤ بالتّفاعلات بين العناصِر. من الأفضل، عند تصميم تطبيق يستخدم Docker، تقسيمُ وظائفه بين عدّة حاويّات. تُسمّى هذه الطّريقة ببُنية خَدَميّة التّوجّه Service-oriented architecture. يمنح هذا التّصميم سهولةً عند التّوسّع أو أثناء تحديث العناصِر المكوّنة للتّطبيق في المستقبل، كلٌّ على حِدَة. يُنظَر لهذه المرونة على أنّها أحد أهم أسباب اللّجوء إلى Docker للتّطوير والنّشر. 3- استكشاف الخدمة Service discovery ومخازن الإعداد العامّة Global Configuration Storesاستكشاف الخدمة هو أحد عناصرِ إستراتيجيّةٍ شاملة تهدِف إلى جعل نشر الحاويّات مرِنًا وقابِلًا للتّوسّع. يُمكِن للحاويّات عبر استكشاف الخدمة العثورُ على معلومات عن بيئةٍ مّا، دون الحاجة للتّدخّل البشري. يُمكِن للحاويّات مثلًا العثورُ على معلومات الاتّصال بالعناصر الّتي يجب عليها الاتّصال بها، كما يُمكنها تسجيل أنفسها لتعرف بقيّةُ الأدوات أنها مُتاحة. تعمل هذه الأدوات عادةً على شكل مخازن إعدادات عامّة موزَّعة، يُمكِن عبرها ضبطُ خيارات إعدادٍ للخدمات العامِلة ضمن البنية التّحتيّة التّي تشغِّلها. يوجد في الصّورة أعلاه مثال لتطبيق يُسجِّل معلومات الاتّصال به عن طريق نظام استكشاف الخدمة، ممّا يُتيح لبقيّة التّطبيقات إمكانيةَ إرسال استعلامات إلى خدمة الاستكشاف للعثور على طريقة الاتّصال بالتّطبيق المذكور. تُنجَز هذه الأدوات عادةً على شكل مخازن ذات صيغة مفتاح-قيمة Key-value (جدول من عموديْن، في الأوّل يوجد مفتاح وفي الثّاني قيمة لهذا المفتاح) موّزعة بين عدّة مستضيفات ضمن بيئة عنقوديّة Clustered. تُوفِّر المخازن المذكورة واجهةَ تطبيقات برمجيّة Application programming interface, API يُتوَصَّل إليها عبر ابروتوكول HTTP لقراءة وضبط القِيّم. تُضيف بعض المخازن إجراءاتٍ أمنيةً مثل تعميّة (تشفير) Encryption المُدخَلات وآليّات التّحكّم في الوصول Access control. المخازن المُوَزَّعة أساسيّة لإدارة عنقود من مستضيفات Docker زيادةً على وظيفتها الأولى التّي هيّ توفير تفاصيل الإعداد الذّاتي للحاويّات الجديدة. في ما يلي بعض مسؤوليّات مخازن استكشاف الخدمة: السّماح للتّطبيقات بالحصول على البيانات المطلوبة للاتّصال بالخدمات التّي تعتمد عليها. السّماح للتّطبيقات بتسجيل بيانات الاتّصال بها، وهو ما يُمكّن من القيام بالمسؤوليّة السّابقة. توفير مساحةٍ يُمكن للجميع الوصولُ إليها لتخزين بيانات ضبط الإعدادات. تخزين معلومات الأعضاء في العنقود حسب حاجة برنامج إدارة العنقود. في ما يلي أدوات شهيرة لاستكشاف الخدمة مع بعض المشروعات المتعلِّقة بها: etcd: استكشاف الخدمة. مخزن مُوزَّع يستخدم صيغة مفتاح-قيمة. consul: استكشاف الخدمة. مخزن مُوزَّع يستخدم صيغة مفتاح-قيمة. zookeeper: استكشاف الخدمة. مخزن مُوزَّع يستخدم صيغة مفتاح-قيمة. crypt: مشروع لتعميّة المُدخلات في أداة etcd. confd: تُراقِب مخازن تستخدم صيغة مفتاح-قيمة بحثًا عن تغييرات ثم تعمَد إلى إعداد الخدمات بالقيّم الجديدة. 4- أدوات التّشبيك Networkingتستجيب التّطبيقات التّي تعمل ضمن حاويّات إلى تصميم خَدَميّ التوجّه يُشجّع على تقسيم الوظائف بين عدّة عناصِر أقلَّ تعقيدًا. يُتيح هذا الأسلوب في التّصميم سهولةً في الإدارة والتّوسّع، ولكنّه يتطلّب تأمينًا وثباتًا أكثر في تشبيك مختلف العناصر مع بعضها. يُوفِّر Docker في هذا الإطار البُنية الأساسيّة لتأمين التّواصل بين الحاويّات Container-to-container وبين الحاويّات والمُستضيف Container-to-host. يُتيح Docker افتراضيًا آليّتيْن لربط الحاويّات معًا. الأولى هي عرض منافذ Ports الحاويّة، عبر النظام المُستضيف للتوجيه Routing إلى الخارج، وذلك بشكل اختياري. يُمكِن تعيين منفذ من الحاويّة إلى منفذ في النّظام المُستضيف أو السّماح لDocker باختيّار منفذ عالٍ (منفذ ذو رقم أعلى) غير مُستخدَم. هذه طريقة عامّة تعمل في أغلب الحالات لتوفير الولوج إلى الحاويّة. الطّريقة الثّانيّة هيّ السّماح للحاويّات بالتّواصل عن طريق "روابط" Docker. تحصُل الحاويّات في هذه الحالة على معلومات عن الحاويّة الموجودة على الطّرف الآخر من الرابط؛ ممّا يسمح لها بالاتصال مباشرة إذا كانت مضبوطة للإنصات لمعلومات الطّرف الآخر. تُتاح عبر هذه الطّريقة إمكانيّةُ الاتّصال بين حاويّات موجودة على نفس المُستضيف دون الحاجة لمعرفة منفَذ أو عنوان الخدمة سَلفًا. تُناسِب البُنيةُ الأساسيّة للتّشبيك التي يوفّرها Docker المستضيفات المنفردة أو البيئات المُدارَة بشكل مُباشر. غير أنّ النِّظام البيئي لـDocker أنتجَ مشاريع عديدة تُرَكِّز على زيادة وظائف التّشبيك لصالح المُتعاملين والمُطوِّرين. يُمكن الحصول عبر الأدوات الإضافيّة، من بين أمور أخرى، على: تعديل آلية التّشبيك لإنشاء فضاء عناوين سهل ومُوحَّد بين عدّة مستضيفات. شبكات افتراضيّة خاصّة Virtual private networks لتأمين الاتّصالات بين مختلف المُكوِّنات. تعيين شبكات فرعيّة Sub networks حسب المُستضيف أو حسب التّطبيق. التّأسيس لواجهات اتّصال عبر شبكات محليّة افتراضيّة من النّوع الثّاني (VLAN 2/Macvlan). إعداد وتخصيص عناوين MAC وبوّابات Gateways، ..إلخ للحاويّات. المشاريع التّالية تعمَل على التّحسين من إدارة الشّبكات في Docker: flannel: إضافة طبقة فوقَ آليّة التّشبيك للحصول على شبكات فرعيّة مستقلَّة لكل مُستضيف. weave: جعل كل الحاويّات ضمن نفس الشّبكة عبر إعادة تمثيل بنية التّشبيك. pipework: مجموعة أدوات للإعداد المتقدِّم للشّبكات. 5- الجدولة Scheduling، إدارة العنقود والتّنسيق Orchestrationالمُجدوِل Scheduler هوالآخر عنصر مطلوب لبناء بيئة عنقوديّة للحاويّات. تتولّى المُجدوِلات بدْء تشغيل الحاويّات على المُستضيفات المُتاحة. تُوضِّح الصورة أعلاه نموذجًا مبسَّطًا لاتخاذ قرار الجدولة. يأتي الطّلب للمُجدوِل عبر واجهة تطبيقات برمجية API أو عن طريق أداة إدارة؛ يُقدِّر المُجدوِل بعدها شروط الطّلب وحالة المُستضيفات المُتاحة. يسحب المُجدوِل في المثال معلومات عن كثافة وتمركز الحاويات من مخزن مُوزَّع للبيانات واستكشاف الخدمة (كما تطرَّقنا له سابقًا)، ممّا يُمكّنه من اختيار المُستضيف الأقل انشغالًا للتّطبيق الجديد. تقع عمليّة اختيار المُستضيف في قلب مهام المُجدوِل، وتوجد لديه عادةً دوّال Functions لأتمَمة Automate هذه العمليّة مع ترك خيّار يُمكّن المُدير من تحديد بعض القيود. من الأمثلة على هذه القيود: جدولة الحاويّة للعمل على نفس المُستضيف الذي تعمل عليه حاويّة أخرى مُعطاة. التّأكّد من عدم وضع حاويّة على مُستضيف تعمل عليه حاويّة أخرى مُعطاة. وضع حاويّة على مُستضيف يتطابق مع بيانات وصفيّة Metadata أو علامة مُعطاة. وضع الحاويّة على المُستضيف الأقل نشاطًا. تشغيل الحاويّة على جميع المُستضيفات المُكوِّنة للعنقود. يهتم المُجدوِل بتحميل الحاويّات إلى المستضيفات المناسِبة إضافةً إلى بدْء تشغيلها، إيقافها وإدارة دورة حياة العمليّة ككلّ. تُضمَّن عادةً وظائفُ إدارة العنقود إلى المُجدوِل نظرًا لضرورة تفاعله مع كل مستضيف من المجموعة المكوِّنة للعنقود، وهو ما يُعطي للمُجدوِل القدرةَ على الحصول على معلومات عن مكوّنات العنقود والقدرة على إجراء مهام إداريّة. يُشير التّنسيق في هذا الإطار إلى المُزاوجة بين جدولة الحاويّات وإدارة المُستضيفات. المشاريع التالية من الأشهر في تقديم أدواتٍ للجدولة والإدارة: fleet: أداة للجدولة وإدارة العناقيد. marathon: مُجدوِل ومُدير خدمات. Swarm: مُجدوِل ومُدير خدمات. mesos: خدمة لإسناد وتوطيد موارد المُستضيف لاستغلالها من طرف المُجدوِل. kubernetes: مُجدوِل متقدِّم يستطيع إدارة الحاويّات على شكل مجموعات. compose: أداة تنسيق لإنشاء مجموعات حاويّات. خاتمةيُقدّم Docker عبر المشاريع الدّاعمة له أدواتٍ لإدارة البرامج، التصميم، وإستراتيجيةً للنشر تُعطي المرونة في التوسّع الشّامل. بعد النّظرة العامة التي قدّمتْها الفقرات السّابقة يُمكن الانتقال إلى دراسة وفهم القدرات التي توفرها الأدوات الدّاخلة في النِّظام البيئي المُحيط بDocker ثم تنفيذ ونشر تطبيقات مُعقَّدة ومرنة كفاية لتعمَل على نُظُم تشغيل مختلفة. ترجمة -وبتصرّف- للمقال:The Docker Ecosystem: An Introduction to Common Components

مقدِّمة نظام أسماء النطاقات Domain Name System، أو DNS اختصارًا، جزء متكامل من آلية ربط مختلف الأنظِمة التي تعمل على شبكة الإنترنت. ستحتاج الحواسيب والأشخاص الذين يستعملونها - في غياب نظام DNS - إلى استخدام العناوين المكوَّنة من أرقام، المعروفة باسم عناوين IP (بالإنجليزية IP Addresses). يُسبِّب الاعتمادُ على عناوين IP - وحدَها - للتواصل على الإنترنت العديد من المشاكل. أولها المُشكل البديهي المتمثِّل في العدد الكبير من الأرقام المُعقَّدة المطلوبة لإجراء المهامّ، مهما كانت بساطتها. ينضاف إلى ذلك مشكلُ نقل موقع إلكتروني إلى مقدِّم استضافة Hosting provider جديد، أو تبديل مكان تواجد خواديمك إلى موقع مُغايِِر؛ سيتوجَّب عليك في الحالتين إعلامُ كل واحد من زبنائك بالموقع الجديد. تمتلك خواديم DNS - وهي الحواسيب التي تشكِّل معًا النظام الذي يمكِّننا من استخدام أسماء للعنونة - القدرة على تأديّة وظائف عديدة تُساهِم كل واحدة منها في إمكانية النفاذ إلى خواديمك بأسماء بدلَ أرقام. تحدّثنا في مقال سابق عن مفاهيم ومُصطلَحات نظام أسماء النّطاقات الأساسية؛ نفترض هنا معرفة هذه المُصطلحات والمفاهيم. سنناقش في هذا المقال بعض أنواع إعدادات خواديم DNS: ميزات وحالات استخدام وخصائص كل واحد منها. مسار استعلام DNS path query - DNS أول ما يتوجّب على برنامج عميل Client يرغب في الوصول إلى خادوم عن طريق اسم النطاق القيامُ به، هو ترجمة اسم النّطاق إلى عنوان يُمكن توجيه الاستعلامات إليه. هذه المعلومة مطلوبة حتى يتسنى للعميل إرسال معلومات إلى الخادوم أو استقبالها منه. تحتفِظ بعض البرامج، كما هي حال أغلب متصفِّحات الوب، بنسخ مخبَّأةCache من الاستعلامات الأخيرة. تفتّش هذه التطبيقات بدءًا في النُّسخ المخبَّأة لديها بحثًا عن عنوان IP النطاق؛ فإن لم تجِد الإجابة التي تبحث عنها تلجأ إلى أداة الحلّ Resolver الموجودة في نظام التّشغيل. يُقصَد بأداة الحلّ أي عنصر يوجد في جانب العميل ويُشارِك في استعلام DNS. تقوم مكتبة الحلّ Resolving library بهذا الدّور في نظام التشغيل الذي يستخدمها للبحث عن إجابة لاستعلامات DNS. فنيَّا مكتبة الحلّ هي مجموعة من الدّوال Functions للترجمة بين أسماء النّطاقات وعناوين IP. أداة الحل في نظام التشغيل هي العامل المحفِّز لعملية البحث عن عنوان IP؛ فكل ما تقوم به هو النّظر في بضع ملفات موجودة على نظام التشغيل (مثل etc/hosts/ في نظام غنو/لينوكس) أو تحويل الطّلب إلى أداة حلّ أخرى. يمر الاستعلام من البرنامج العميل إلى أداة الحلّ الموجودة في نظام التشغيل؛ التي تُرسلها إلى خادوم أسماء ليبحثَ عن عنوان IP المطلوب. يُسمَّى خادوم الأسماء في هذه الحالة خادوم DNS تكراري، Recursive DNS server. خادوم DNS تكراري هو خادوم مضبوط لمواصلة إرسال طلبات إلى خواديم DNS الأخرى بحثا عن العنوان الذي يُحيل إليه اسم النّطاق حتى يجد الإجابة. بعد عملية البحث يُحوِّل الخادوم التكراري الإجابة - أو رسالة الخطأ في حال تعذر الحصول على عنوان IP - إلى العميل (أداة الحلّ في نظام التّشغيل التي بدورها تمرِّرها إلى البرنامج). تحتفظ الخواديم التكرارية هي الأخرى - غالبًا - بنُسخ مخبَّأة من الاستعلامات. تبدأ هذه الخواديم عند وصول استعلام جديد بالبحث أولا في النسخ المُخبَّأة لديها، فإن لم توجد الإجابة في تلك النُّسخ؛ تنظُر إذا ما كانت تعرِف عنوان IP النطاق الأعلى لاسم النطاق قيدَ البحث. على سبيل المثال: إذا كان الاستعلام يتعلَّق بالنطاق www.example.com ولم يجد الخادوم التكراري نسخة مخبّأة بالنتيجة؛ فالخطوة الموالية هي العثور على خواديم أسماء النّطاق example.com، وفي حالة عدم معرفتها يبحث عن خواديم النطاق العلوي Top-level domain - TLD، أي com في هذا المثال. المبدأ هو أن يُرسِل الخادوم التكراري الاستعلام إلى خادوم الأسماء الأكثر تحديدا من بين خواديم الأسماء التي يعرفها للحصول على معلومات عن النّطاق. يحدُث ألا يعرف الخادوم التكراري عنوانَ أي من عناصر اسم النّطاق، في هذه الحالة يتوجّب عليه البدء من أعلى التسلسل الهرمي بإرسال استعلام إلى خواديم الجذر Root servers. تعرِف خواديم الجذر عناوين كل خواديم الأسماء التي تُدير النطاقات العلوية (TLD) مثل com. و net. و org. وغيرها. يُجيب الخادوم الجذر عند تلقي الاستعلام عن www.example.com بعنوان IP خواديم أسماء النطاق العلوي com. يستمر الخادوم التكراري في تتبع إحالات كل خادوم أسماء عن أجزاء اسم النّطاق التي تقع تحت سُلطته حتى يصِل إلى خادوم الأسماء الذي يعرف الإجابة الكاملة، ثم يحتفظ بنسخة مُخبَّأة من هذه الإجابة ويُرسِلها إلى العميل. رأينا في المثال السابق أنه توجد أنواع عديدة من الخواديم يقوم كل منها بدورِ مُختلِف. سنتعرف في الفقرات المُقبلة على خصائص كل واحد من أنواع خواديم DNS. الفروق الوظيفية Functional differences تختلف خواديم DNS في الوظائف التي تؤديها؛ فأغلب الخواديم التي تدخل في إطار نظام أسماء النطاقات تتخصّص في وظائف محدَّدة. يعتمِد نوع خادوم DNS الذي تستخدمه على حاجاتك وطبيعة المشاكل التي تريد إيجاد حلول لها. الخواديم المُقتصِرة على منطقة السلطة Authoritative-Only DNS Servers خادوم مقتصِر على منطقة السلطة هو خادوم يُجيب فقط عن الاستعلامات حول النطاقات التي هو مسؤول عنها. تتميّز الخواديم المُقتصِرة على السلطة بالسرعة والقدرة على التعامل مع العديد من الاستعلامات بكفاءة، يُساعدها في ذلك أنها لا تتدخّل في الإجابة على طلبات تتعلَّق بنطاقات خارجَ سُلطتها. لدى الخواديم المُقتصِرة على منطقة السلطة الخصائص التالية: سريعة جدًّا في الإجابة على استعلامات عن نطاقات تقع ضمن سُلطتها. يمتلك هذا النوع من الخواديم كل المعلومات عن النطاق الذي هو مسؤول عنه، كما أن لديه معلومات الإحالة إلى خواديم أسماء أخرى إذا كان لديها تفويض بالسلطة على موارد (نطاقات فرعية أو مُستضيفات) تابعة للنطاق. لا تُجيب على الاستعلامات التكرارية. التّعريف الّدقيق لخادوم مقتصر على منطقة السلطة هو أنه خادوم لا يتعامل مع الاستعلامات التكرارية. تعني هذه الخاصية أن الخادوم المُقتصِر على السّلطة لا يقوم أبدًا بدور عميل في نظام DNS. الاستعلامات التي تصِل إلى هذا الخادوم تأتي في الغالب من خادوم أسماء حالّ Resolving name server تلقى إحالة إلى الخادوم المُقتصر على السّلطة، وهو ما يعني أن هذا الأخير إما لديه الإجابة الكاملة أو لديه إحالة إلى خادوم أسماء مُفوَّض من طرفه بإدارة بعض موارد النّطاق. لا يحتفظ بأي نُسَخ مخبَّأة. توجد كل المعلومات التي يحتاجها الخادوم المُقتصِر على السّلطة في نظام الملفّات لديه، وبما أنه لا يُرسِل استعلامات إلى خواديم أخرى فهذا يعني أنه لا يوجد لديه داعٍ لحفظ نُسخ مخبَّأة. خادوم DNS مُخبِّئ Caching DNS Server يتعامل خادوم DNS المخبِّئ مع الاستعلامات التكرارية التي يُرسلها العملاء. الخواديم التي تتّصل بها أداة الحلّ الموجودة في نظام التشغيل هي في العادة خواديم DNS مُخبِّئة. تتميّزالخواديم المُخبِّئة بقدرتها على الإجابة على طلبات العملاء التّكرارية. تُعتَبر الخواديم المُقتصِرة على منطقة السلطة، من وجهة نظر معلومات نطاق محدَّد، مثالية؛ إلا أن الخواديم المخبِّئة أكثر فائدة من وجهة نظر العميل الذي قد يكون مجرَّد واجهة رسومية بسيطة، تتيح له الخواديم المُخبِّئة الوصول إلى كامل نظام DNS. تقوم الخواديم المخبِّئة بالاحتفاظ بنسخ من الإجابات على الاستعلامات الأخيرة لتقديمها عند الحاجة مقلّلةً بذلك من عدد الطّلبات التي ترسلها إلى خواديم الأسماء الأخرى، وهو ما يُساعد في تحسين الأداء ويُتيح لها الوصول إلى قاعدة عريضة من معلومات نظام DNS (كل معلومات DNS المتوفِّرة بشكل مفتوح) مع القدرة على الاستجابة السّريعة للطّلبات التي مرّت بها حديثًا. لدى الخواديم المُخبِّئة الخصائص التاليّة: إمكانية الوصول إلى كل معلومات نظام DNS المُتاحة للعموم؛ إذ أن الخواديم المُخبِّئة تستطيع الحصول على كل معلومات النّطاقات الموجودة لدى خواديم الأسماء المرتبِطة بالترتيب الهرمي لنظام DNS التي يُتاح الوصول إليها بشكل عام. تعرف الخواديم المُخبِّئة عناوين خواديم الجذر وتستطيع تتبّع الإحالات بذكاء أثناء حصولها على البيانات. القدرة على التّدرج في إرسال البيانات إلى العملاء محدودي الموارد (الذاكرة Memory، المُعالِج Processor، ..إلخ). تقوم أغلب نُظُم التّشغيل الحديثة بتوكيل عملية تعيين أسماء النطاقات إلى خواديم تكرارية مُتفرِّغة لهذا الغرض، وذلك عن طريق مكتبة الحلّ. كل ما تقوم به مكتبة الحلّ هو إرسال استعلام ثم انتظار الحصول على إجابة كاملة. لدى الخادوم المُخبِّئ الإمكانات اللازمة بالضبط لتلبية طلب هذه المكتبات. يعني قبول الخواديم المُخبّئة للاستعلامات التكرارية أنها تضمن إما إرسال إجابة إلى العميل أو إبلاغه برسالة خطأ. تحتفظ بنسخ من البيانات المطلوبة في الاستعلامات الأخيرة. تُنشئ هذه الخواديم نسخ من بيانات DNS الأخيرة التي حصلت عليها أثناء البحث عن استعلامات العملاء. تعتمد سرعة الحصول على إجابة من طرف خادوم مخبّئ على عوامل أهمها عدد عملاء الخادوم، وسعة ذاكرة التخبئة Cache memory وقيمة TTL الموجودة في سجلاّت خادوم اسم النطاق المطلوب. خادوم إعادة التوجيه Forwarding DNS Server يُشكِّل خادوم إعادة التوجيه بديلًا عن إنشاء نُسَخ مخبَّأة على الحواسيب العميلة. تُضيف هذه المقاربة حلقةً جديدة في مسار استعلام DNS عن طريق تشغيل خادوم إعادة توجيه تتلخَّص مهمته في تمرير كل استعلامات DNS إلى خادوم لديه القدرة على التعامل مع الطلبات التكرارية (خادوم مُخبِّئ على سبيل المثال). تُعطي هذه الطّريقة ميزة الحصول على نُسخ مخبَّأة يُمكن الوصول إليها من الشبكة المحلية Local network دون الحاجة لعمل الاستعلامات التكرارية (قد تستأثر الاستعلامات التكرارية بمواردة مُعتبرة في الخواديم التي لديها حركة اتصالات فائقة). لدى خواديم إعادة التوجيه الخصائص التالية: القدرة على الإجابة على الاستعلامات التكرارية دون أن يكون هو نفسه من يتتبع إحالاتِها. الخاصية الأساسية في خادوم إعادة التوجيه هي أنه يمرِّر الطلبات إلى عميل آخر يقوم بالبحث عن الإجابة عنها. يُمكن لخادوم إعادة التوجيه منح قيمة مُضافة كبيرة بموارد محدودة، وذلك اعتمادًا على النُّسخ المخبَّأة التي يحتفظ بها. توفير تخبِئة بالقرب من الشبكة المحلية. يستطيع خادوم إعادة التوجيه طلب خواديم DNS تكرارية متاحة للعموم وهو ما يُغنيك إن لم تكن لديك القدرة على إنشاء وصيانة وتأمين خدمة DNS كاملة. إتاحة تخبئة قريبة من الشبكة المحلية تعني التقليل من الوقت اللازم للإجابة على الاستعلامات. زيادة المرونة عن طريق تعريف فضاء محلي لأسماء النطاقات. يستطيع خادوم إعادة التوجيه إضافة شروط على وجهة الاستعلامات وذلك للتأكد من أن الطلبات المحلية تُوجَّه إلى خواديم خاصة بينما تُرسل الطّلبات الخارجية إلى خواديم DNS عامّة. الحلول التجميعية تطرّقنا في الفقرات السّابقة إلى خواديم DNS مُصمَّمة لتلبية حاجات محدَّدة. في بعض الأحيان يكون مُفيدًا إعدادُ خادوم DNS بطريقة تسمح له بدمج ميزات كل نوع من الخواديم معًا. يُمكن على سبيل المثال إعداد خادوم للعمل كمخبِّئ بالنسبة لعدد محدّد من عملاء الشبكة المحلية في حين أنه يتعامل مع بقية العملاء بوصفه خادوما يقتصِر على منطقة السلطة. هذا الإعداد شائع جدًا إذ يسمح لك بالإجابة عن الاستعلامات الخارجية المتعلّقة بنطاقك وفي نفس الوقت يمكن للحواسيب على الشبكة المحلية اللجوء لنفس الخادوم لحل الاستعلامات التكرارية. تُصَمَّم أغلب برمجيات DNS لإنجاز وظيفة معيَّنة. توجد رغم ذلك تطبيقات تتمتع بالمرونة للعمل على دمج عدة وظائف. Bind أحد هذه التّطبيقات. يؤدي توفير عدة خدمات (وظائف) DNS على نفس الخادوم عادةً إلى تدهور في الأداء، لكن الأمر يختلف بالنسبة للمؤسسات ذات البنية التحتية الصغيرة التي يكون فيها تحمل إدارة وصيانة خادوم "كل في واحد" أكثر جدوائية. الفروقات الارتباطية Relational Differences من المهم الانتباه للفروق في العلاقة بين الخواديم. فبالرغم أن أغلب الفروق بين إعدادات الخواديم هي فروق وظيفية إلا أن الاختلافات في طبيعة العلاقة بين الخواديم مهمة جدًّا هي الأخرى. الخواديم الرئيسة والخواديم التابعة Primary and Slave Servers تعمَد الكثير من أنظمة DNS المسؤولة عن نطاق معيَّن إلى تضمين نُظُم احتياطية مكوَّنة من عدة خواديم لضمان الوصول إلى الخدمات التي توفّرها. تأتي العلاقة بين الخواديم في هذه النّظم على عدّة أشكال، لكن الخادوم - في الغالب - إما أن يكون رئيسًا Primary أو تابِعًا Slave. لدى كل من الخادوم الرئيس والتابع السّلطة على النطاق المسؤول عنه ولا يوجد فرق منه هذه الناحية. الفرق الوحيد بين خادوم أسماء رئيس وآخر تابِع هو المكان الذي يقرأ منه ملفات النطاق: يقرأ الخادوم الرئيس ملفات النطاق من القرص الصّلب لديه. يُضيف مديرو النُّظُم ملفات النطاق إلى نظام الملفات الموجود على الخادوم الرئيس. عند تحرير أو نقل ملفات النطاق فإن ذلك يتم على مستوى الخادوم الرئيس. يستقبل الخادوم التابِع ملفات النطاق من أحد الخواديم الرئيسة ثمّ يحفظ نسخًا منها لديه في ذاكرة التخبِئة. في حال إعادة تشغيل الخادوم الرئيس فإنه يتحقق من كون ملفات النطاق محدَّثَة Up-to-date ويقوم بتحديث معلوماته من الخادوم الرئيس إن تطلّب الأمر ذلك. ليسَ مفروضًا على الخادوم أن يكون رئيسًا (أو تابِعًا) في جميع نطاقات سُلطته. يُخصَّص وضع الخادوم (رئيس أو تابِع) لكل واحد من النطاقات التي هو مسؤول عنها دون أن يُؤثِّر ذلك على وضعه بالنسبة لبقية النطاقات؛ أي أنه يُمكن أن يكون رئيسًا بالنسبة لبعض النطاقات وتابِعا بالنسبة لنطاقات أخرى. يوجد عادةً خادوما أسماء لكل نطاق في نظام DNS. في حال كان النطاق يُوجه إلى نطاقات عامة على شبكة الإنترنت فيتوجّب أن يكون لديه في هذه الحالة خادوما أسماء على الأقل. تمتلك بعض النطاقات عدة خواديم أسماء لتوزيع الحِمل Load بينها. الخواديم العامّة والخواديم الخاصّة Public vs Private Servers تستخدم المؤسسات نظام DNS في شبكاتها الدّاخلية والخارجية على السّواء، وتختلف البيانات المُرسلة بشدّة في الحالتين. يُمكن لمنظّمةٍ ما مثلًا توفير خادوم مُقتصر على نطاق السّلطة يتعامل مع استعلامات DNS عامّة (خارجية)، وفي نفس الوقت تستعمل خادوما منفصِلًا (خاصا) يحوي معلومات النّطاق التي يوفّرها الخادوم العام إضافةً إلى معلومات إضافية عن مستضيفات وخدمات موجّهة لمستخدمي الشّبكة المحليّة، مثل أن يكون الخادوم مخبِّئا ويتعامل مع الاستعلامات التكرارية ولكن فقط عندما تكون آتية من الشبكة المحلية. ذكرنا أثناء الحديث عن الحلول التجميعية أنه يُمكن لخادوم واحد التّعامل مع وظائف عديدة مع التفريق بين الخدمات الموجَّهة للعموم والأخرى الموجَّهة لمستخدمي الشّبكة الدّاخلية. هذه المُقاربة واردة؛ إلا أن توزيع العمل بين خادومين منفصليْن - عامّ وخاص - لا يعلمُ أي منهما شيئا عن الآخر يخفِّف حِمل العمل كما أنه أفضَل من وجهة نظر أمنية حيثُ لا وجود لسجلّات records عن الجزء الخاص لدى الخادوم العام. يعني هذا أن الخادوم العام لا يملك في ملفات النّطاق لديه أي سجلات من نوع NS عن خواديم الأسماء الخاصّة بالشبكة الدّاخلية. بالحديث عن الأمان توجد بعض الاعتبارات التي ينبغي أخذها في الحسبان. العلاقة من نوع رئيس-تابِع هي الطّريقة السّهلة لتشارك بيانات النّطاق بين الخواديم العامّة والخاصّة، ولكنّ ذلك قد يُسرِّب معلومات عن بنية الشّبكة الداخليّة ويجعلها مُتاحةً للجميع. من الجيّد في هذا الإطار حذف أي مرجِع للخادوم الخاصّ من ملفّات إعداد الخادوم العامّ. يشمل هذا الأمر، إضافةً إلى إبقاء الخادوميْن منفصليْن كما ذكرنا سابِقًا، مسح أي تفاصيل عن نقل أو إشعار أو إعدادات الخادوم الرئيس؛ بحيثُ تبقى خواديم أسماء الشّبكة الداخلية محميةً حتى في حال تعرّض الخواديم العامّة للاختراق. خاتمة تُدرك الآن وجود قدر لا بأس به من المرونة في خيارات إعداد DNS. يعتمد الخيار المُناسِب على حاجات مؤسستك: هل تمنح الأولوية لإعداد نظام DNS سريع لعدد محدّد من العملاء (خواديم مخبّئة أو خواديم إعادة التوجيه)، أم لتوفير خدمة تعيين نطاقاتك على الإنترنت بأكملها (خواديم مُقتصِرة على السّلطة). المقاربات التجميعية شائعة ويجب أخذ طريقتَي عمل DNS السّالفتي الذِّكر بالحسبان. سنوضّح لك في المقالات اللّاحقة كيف تبدأ مع بعض هذه الإعدادات؛ حيثُ سنقوم أولا بضبط خادوم ليعمل إما كمخبِّئ أو لإعادة التوجيه، ثم نأتي بعد ذلك لإعداد خادومَيْ DNS يقتصران على نطاق السلطة. ترجمة -وبتصرّف- للمقال: A Comparison of DNS Server Types: How To Choose the Right DNS Configuration

توجد بعض الإعدادات التي يجب إجراؤها في البداية كجزء من عملية التثبيت الأولية عند إنشاء خادوم جديد. تؤدي هذه الخطوات إلى تعزيز أمان وقابلية استخدام 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، ...إلخ) وإرسال الطّلبات لهذا المُحتوى إلى خواديم التخبئة. بالنسبة لبقية الطّلبات فإنه يُرسِلها إلى خواديم التطبيق. عند طلب محتوى ديناميكي فإن ما يحدُث هو التّالي: يطلُب المستخدِم محتوى ديناميكيا من http://example.com، يتلقى مُوزّع الحِمل الطّلب.يُمرِّر موزِّع الحِمل الطّلب إلى المُنتهي الخلفي للتطبيق Application Backend.يجلب المُنتهي الخلفي المحتوى المطلوب من قاعدة البيانات ويُرسِله إلى موزِّع الحِمل.يُمرِّر موزّع الحمل المحتوى المطلوب إلى المستخدِم.بالنسبة للمحتوى السّاكن فإن الخطوات تكون كالتالي: يتعرّف موزِّع الحِمل على المحتوى السّاكِن ثم يتحقق من وجود المحتوى المطلوب لدى خادوم التخبِئة (إصابة التخبِئة) أو عدمه (تفويت التخبِئة Cache-miss).في حال إصابة التخبِئة: يُرسِل خادوم التخبِئة المحتوى المطلوب إلى موزِّع الحِمل؛ نُكمِل مع الخطوة 6. في حال تفويت التخبِئة يعيد خادوم التخبِئة الطّلب إلى موزِّع الحِمل.يُمرِّر موزِّع الحِمل الطّلب إلى المُنتهي الخلفي للتطبيق.يجلب المُنتهي الخلفي المحتوى المطلوب من قاعدة البيانات ويُرسِله إلى موزِّع الحِمل.يُمرِّر موزِّع الحِمل الطّلب إلى خادوم التخبِئة الذي يحتفِظ بنسخة من الطّلب والإجابة ثم يُعيده إلى موزِّع الحِمل.يُمرِّر موزّع الحمل المحتوى إلى المستخدِم.تُوفّر بيئة العمل أعلاه كل فوائد الإعدادات المذكورة في هذا الشّرح من ناحية الثبات والأداء، ولكنْ لديها نقطتا ضعف: موزِّع الحمل وقاعدة البيانات الرئيسة. خاتمةينبغي أن تكون لديك الآن، بعد التعرّف على بعض الإعدادات الأساسية للخواديم، رؤيةٌ جيّدة تُمكِّنك من معرفة أي إعداد أنسب لتطبيقاتِك. تذكّر عند العمل على الرّفع من مستوى بيئة عملك أنْ تتدرّج في إدخال التحسينات بحيث لا تُدخِل الكثير من التعقيدات في فترة قصيرة. ترجمة -وبتصرّف- للمقال: 5 Common Server Setups For Your Web Application

مقدِّمةيحدُث، مع ازدياد استخدام التطبيق أو موقع الويب الخاص بك، أن يتجاوز الضغط الناتج عن هذا النمو قدرةَ الإعداد الحالي على الاستجابة. في حال كنتَ تستضيف خادوم الويب والنهاية الخلفيةBackend لقاعدة البيانات على نفس الخادوم الافتراضي الخاص Virtual private server, VPS فمن الجيد فصلُ هاتين الوظيفتيْن بحيثُ تنمو كل منهما على جهاز خاص بها. سنناقِش في هذا المقال كيفية إعداد خادوم قاعدة بيانات بعيد Remote database server يتّصل به خادوم الويب للحصول على محتوى ديناميكي. سنأخذ ووردبريس مثالا للعمل عليه. سيكون Nginx خادومَ الويب، وسنُعدّه للاتصال بقاعدة بيانات MySQL توجد على حاسوب منفصِل. تجري جميع هذه الإعدادات على خادوم افتراضي خاص يعمل بتوزيعة Ubuntu 12.04. تثبيت MySQL على خادوم قاعدة البياناتنبدأ بإعداد خادوم افتراضي خاص ليعمل كخادوم MySQL. يُساعِد وجود خادوم قاعدة البيانات على جهاز منفصِل في سهولة التوسّع عند الوصول إلى الحد الأعلى الذي يسمح به إعدادٌ من جهاز واحد، كما أنه يضع أساسا يُمكن استخدامه في ما بعد للجوء إلى توزيع الحِمل Load balancing من أجل توسيع بيئة العمل. سنحتاج لتثبيت بعض الحِزم Packages على خادوم قاعدة البيانات قبل بدْء العمل. هذه الحِزم هي نفسها المستخدَمة في تثبيت حِزم LEMP اعتيادية ولكن لن نُثبِّتَها كلَّها هنا (البقية ستتواجد على الخادوم الآخر). ابدأ بتحديث النسخ المخبَّأة من الحِزم على النظام لديك، وتثبيت خادوم MySQL: sudo apt-get update sudo apt-get install mysql-server سيُطلب منك أثناء تثبيت خادوم MySQL إدخالُ كلمة سر لحساب مُدير قاعدة البيانات (الحساب الجذرRoot user) ثم تأكيدُها. ستحتاج بعد الانتهاء من تثبيت الحزمة إلى تنفيذ أمر تثبيت قاعدة البيانات والذي سيُنشئ بنية المجلَّدات الضرورية: sudo mysql_install_db نأتي بعد التثبيت إلى خطوة الرفع من مستوى الأمان عن طريق سكريبت يطلُب تعطيل بعض إعدادات MySQL الافتراضية غير الآمنة: sudo mysql_secure_installationأدخِل كلمة سر مدير قاعدة بيانات MySQL (ضُبِطت أعلاه). سيطلُب منك ما إذا كنت تريد تغيير كلمة السّر، أدخِل N إن لم ترغَب في ذلك. بالنسبة لبقية الأسئلة اضغط زر Enter لترك الخيارات الافتراضية، وهو ما سينتُج عنه حذف بعض قواعد البيانات التجريبية وقفل الولوج Access. إعداد MySQL للسماح للولوج عن بعدفي هذه الفقرة سنضبُط قاعدة البيانات بحيث تسمح بالاتصالات القادمة من حواسيب أخرى. افتح ملف إعداد MySQL الرئيس بصلاحيات الجذر في محرّر نصوص (Nano في هذا المثال): sudo nano /etc/mysql/my.cnf يُقسَّم هذا الملف إلى مقاطِع مُعرَّفة بكلمات بين معكوفَيْن ([ و ]). اعثُر على المقطَع المعرَّف ب mysqld (لاحِظ حرف d في آخر الكلمة): [mysqld] ابحَث في هذا المقطَع من الملف (بينَه وبين المُعرِّف الموالي) عن مُعطى Parameter باسم bind-address. يُخبِر هذا المُعطى قاعدةَ البيانات بعناوين الشبكة التي تستمع للاتصالات القادمة عبرها. الإعداد الحالي هو الإنصات للاتصالات القادمة من الحاسوب المحلي Local host فقط. سنحتاج لتغيير هذا الإعداد والإشارة إلى عنوان IP خارجي يُمكن الاتصال عن طريقه بالخادوم الآخر. استخدِم عنوان IP الخاص لخادومك إن كنتَ تستضيف الخواديم ضمن شبكة داخلية Private network. إن لم تكن لديك شبكة داخلية استخدم عنوان IP العمومي. bind-address = your_database_IP احفظ الملف (Ctrl + O ثم زر Enter) ثم أغلقه بعد الانتهاء من تحريره (Ctrl + x). نُعيد تشغيل قاعدة البيانات لأخذ التغييرات بالاعتبار: sudo service mysql restart إعداد اعتماداتCredentials ووردبريس وقاعدة البياناتضبطنا في الخطوة السّابقة إعدادات الاتصال عبر عناوين خارجية؛ سنُكمل هذا الإعداد بإنشاء قاعدة بيانات ومستخدِم للأجهزة المتصلة عن بعد. فعلى الرغم من أننا أعددنا خادوم MySQL للإنصات للاتصالات القادمة من عنوان خارجي يُمكن لبقية الأجهزة الاتصال عبره، إلا أنه حتى اللحظة لاتوجد أي قاعدة بيانات للاتصال بها. سنغتنم هذه الفرصة أيضًا لاعتماد صلاحيات Privileges تختلف حسب الجهة التي يتصل منها المستخدِم. يُمكن مثلا أن نُنشئ مستخدمَيْن باسم "user" ولكن كل منهما مرتبط بمستضيف Host مختلف. يعني هذا أنه يُمكننا إنشاء مستخدِم مرتبط بخادوم قاعدة البيانات نفسه وتكون لديه صلاحيات واسعة ثم نستعمل نفس اسم المستخدم على خادوم الويب ونعطيه فقط الصلاحيات التي يحتاجها ووردبريس. سيمنحنا هذا الإعداد القدرة على القيام بالأعمال الإدارية التي تتطلب صلاحيات واسعة عند الولوج إلى خادوم قاعدة البيانات وفي نفس الوقت نعطي لخادوم الويب الحد الأدنى من الصّلاحيات التي يحتاجها. تُعتبَر هذه السياسة جيدة من ناحية أمنية حيثُ تحمي جزئيًا خادوم قاعدة البيانات في حال تعرض خادوم الويب للاختراق. للبدء في الإعداد نتّصل بخادوم قاعدة بيانات MySQL باستعمال الحساب الجذر وكلمة سر المدير عبر الأمر: mysql -u root -p سيُطلَب منك إدخال كلمة سر المدير بعد تنفيذ هذا الأمر. بعد الولوج نُنشئ قاعدة البيانات التي سيتّصل بها ووردبريس. اخترنا إعطاء اسم wordpress لقاعدة البيانات ليسهُل علينا التعرف عليها لاحقا: CREATE DATABASE wordpress; الآن سننشئ مستخدِما جديدا لديه كامل الصلاحيات على قاعدة البيانات wordpress. سنسميه wordpressuser ثم نحدّد الجهات التي يُمكن منها استعمال هذا المُستخدِم بحيث يقتصر استعماله على الاتصالات من الخادوم نفسه عن طريق استخدام localhost أثناء تنفيذ الأمر، كما يلي: CREATE USER 'wordpressuser'@'localhost' IDENTIFIED BY 'password'; في الأمر السّابق أنشأنا مستخدِما باسم wordpressuser مع كلمة السر password (اكتب كلمة سر خاصة بك مكانها) وحصرنا الجهات التي يُمكنه الاتصال منها بالمستضيف المحلي (localhost)، أي خادوم قاعدة البيانات نفسِه. نُكمل بإعطاء هذا المستخدِم كامل الصّلاحيات على قاعدة البيانات wordpress: GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpressuser'@'localhost'; يُمكن للمستخدم wordpressuser أن يُجري أي عملية على قاعدة البيانات wordpress بشرطِ أن يكون متصلا من خادوم قاعدة البيانات. فلننشئ الآن الحساب المرافق الذي ستستخدمه الاتصالات القادمة من خادوم الويب. سنحتاج لعنوان IP خادوم الويب للقيام بهذا الأمر. يُمكننا اختيار أي اسم نراه مناسبا للمستخدِم، لكن من أجل الحفاظ على تجانس التجربة سنختار نفس الاسم أعلاه، مع تغيير اسم المُستضيف. انتبه إلى أنه ينبغي استخدام نفس عناوين الشبكة التي استخدمتَها في ملف my.conf أثناء إعداد MySQL للسماح للولوج عن بعد. يعني هذا أنك يجب أن تستخدم عنوان IP خاص إذا كانت لديك شبكة داخلية أو عنوان IP عمومي في الحالة المغايِرة، مع التوافق مع إعدادات الملف المذكور سابقا. CREATE USER 'wordpressuser'@'web_server_IP' IDENTIFIED BY 'password'; يُنشِئ هذا الأمر مستخدِما باسم wordpressuser مع كلمة السر password وحصرنا الجهات التي يُمكنه الاتصال منها بخادوم الويب (حيثُ web_server_IP عنوان IP خادوم الويب). الهدف هو أن تقتصر صلاحيات هذا المستخدم على صلاحيات يحتاجها ووردبريس للعمل وهي القراءة من قاعدة البيانات (SELECT) ، وحذف سطر من جدول (DELETE)، وإضافة سطر إلى جدول (INSERT) وتحديث البيانات الموجودة سلفا (UPDATE؛ ولكن ليس بإمكاننا تفعيل هذا الإعداد الآن. السبب أن هذه الصلاحيات لا تكفي للقيام ببعض العمليات، مثل تثبيت ووردبريس. وهو ما يعني أننا سنُفعِّل مؤقتا صلاحيات أوسع لهذا المستخدِم ثم نعود لنزعها منه وترك الصلاحيات الأربع التي ذكرناها سابقا فقط، وذلك بعد اكتمال التثبيت. للمعلومة، الأمر المُستَخدم لتأمين الحساب والحد من صلاحياته هو التالي (سنعود له في ما بعد): GRANT SELECT,DELETE,INSERT,UPDATE ON wordpress.* TO 'wordpressuser'@'web_server_ip'; قبل ذلك سننمح هذا المُستخدِم - مؤقتا - كامل الصلاحيات، وهو ما يجعله مطابِقا للمستخدِم السابق: GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpressuser'@'web_server_ip'; سنعود لتغيير هذا الإعداد بعد تثبيت وضبط ووردبريس. إن كنتَ تستخدِم هذا الدّرس لمعرفة كيفية الفصل بين خادوم قادة البيانات وخادوم الويب ولا تحتاج لتثبيت ووردبريس؛ فيُمكنك تفعيل التقييدات على حساب المستخدِم الآن. يعتمِد الأمر على تطبيقك والصلاحيات الدنيا التي يُمكِنه العمل بها. نحفظ التغييرات التي أجريناها على الصّلاحيات بكتابتها على القرص الصّلب: FLUSH PRIVILEGES; يُمكن الآن الخروج من سطر أوامر MySQL عن طريق تنفيذ الأمر: exit اختبِر الاتصالات المحلية والبعيدةسنتأكد قبل المواصلة مع بقية الخطوات من إمكانية الاتصال باستخدام الحساب wordpressuser على كل من خادوم قاعدة البيانات وخادوم الويب. جرِّب أولا الاتصال من الجهاز الذي توجد به قاعدة البيانات باستخدام الحساب الجديد: mysql -u wordpressuser -p ثم أدخِل كلمة السر التي أعددتها أثناء إنشاء الحساب. عند الولوج إلى سطر أوامر MySQL بعد تنفيذ الأمر أعلاه فإن الاتصال تم بنجاح. يُمكنك الخروج عبر الأمر: exit سجِّل الدخول إلى خادوم الويب لتجربة الاتصال عن بُعد. ستحتاج لتثبيت بعض الأدوات على خادوم الويب حتى يُمكنك الولوج إلى قاعدة البيانات عن بعد. حدِّث النسخ المخبَّأة من الحزم ثم ثبّت أدوات عميل MySQL Client: sudo apt-get update sudo apt-get install mysql-client يُمكننا بعد اكتمال التثبيت تجربة الاتصال بخادوم قاعدة البيانات: mysql -u wordpressuser -h database_server_IP -p مُجدّدا، تأكد من استخدام نفس عناوين الشبكة التي استخدمتها أثناء إعداد خادوم قاعدة البيانات. أدخِل كلمة السر عندما تُطلَب منك. ينبغي أن يظهر سطر أوامر MySQL، وهو ما يدل على نجاح الاختبار؛ يُمكنك بعدها الخروج من سطر أوامر MySQL. للمزيد من التحقق يُمكنك تجربة الاتصال من خادوم ثالث للتأكد من عدم سماح خادوم قاعدة البيانات لك بالولوج. يعني هذا أنك تحققتَ من الولوج من الجهاز المحلي (خادوم قاعدة البيانات) ومن خادوم الويب، لكن لا يُسمَح بالولوج من خادوم آخر. نُجرّب الولوج إلى قاعدة البيانات من خادوم غير مُصرَّح له بالدخول عن طريق عنوان IP: mysql -u wordpressuser -h database_server_IP -p لن يُسمَح لك بالدخول، بدلا من ذلك تظهر رسالة خطأ كالتالي: ERROR 1130 (HY000): Host '11.111.111.111' is not allowed to connect to this MySQL server يعني هذا أن الجهاز الذي تُريد الاتصال منه لا يُسمح له بالولوج إلى قاعدة البيانات، وهو بالضبط ما نريده. إعداد خادوم الويبنحتاج الآن بعد التأكد من إمكانية الاتصال من خادوم الويب إلى تثبيت البرامج الضرورية لهذا الخادوم ليقوم بعمله (تقديم صفحات الويب). سنضبُط كلًّا من Nginx وPHP وبقية العناصر الضرورية لخادوم الويب. حدّثنا قبل قليل النسخ المخبّأة من الحزم على أوبنتو، وهو ما يعني أنه يُمكننا تثبيت الحزم التي نحتاجها مباشرة: sudo apt-get install nginx php5-fpm php5-mysql بعد انتهاء تثبيت جميع الحزم، يمكن الانتقال إلى إعداد البرامج. إعداد PHPنبدأ بالأسهل، إعداد PHP. افتَح ملف إعداد PHP حيثُ سنضبُط بعض القيم المتعلقة بphp-fpm، وهو المُكوِّن المسؤول عن تقديم المحتوى الديناميكي في PHP: sudo nano /etc/php5/fpm/php.ini ابحَث عن مُعطى Parameter باسم cgi.fix_pathinfo. غالب الظن أنه سيكون مسبوقا بعلامة ";" (دلالةً على أن السّطر تعليق، أي أنه لا يُؤخذ في الاعتبار) وقيمته تساوي "1". سننزع علامة التعليق ونُعطيه القيمة "0". فيُصبِح السطر كالتالي: cgi.fix_pathinfo=0 هذا الإجراء أمني، حيثُ أخبرنا PHP بهذه الطريقة ألا يُحاول تخمين الملف الذي يبحث عنه المستخدِم إن لم يجد تطابقا تاما مع طلبه. يُمكِن لمستخدم سيء النية أن يستغل عدم ضبط هذا الإعداد لمحاولة تنفيذ سكربتات لا ترغب في تنفيذها على الخادوم. احفَظ ثم أغلِق الملف. ننتقل الآن إلى إعداد الطريقة التي يتواصل بها المعالج (Processor) الخاص بPHP مع خادوم الويب: sudo nano /etc/php5/fpm/pool.d/www.conf ابحَث عن تعليمة Directive الاستماع، التي تأتي افتراضيا مضبوطة على 127.0.0.1:9000. بدلا من منفذ Port، سنستخدم مقبس Unix Socket ، Unix. listen = /var/run/php5-fpm.sock احفَظ ثم أغلِق الملف بعد الانتهاء من تحريره. نُعيد تشغيل معالج PHP لاعتماد القِيم الجديدة: sudo service php5-fpm restart إعداد Nginx ننتقل بعد إعداد PHP إلى إعداد خادوم ويب Nginx. نبدأ بنسخ ملف المستضيفات الافتراضية Virtual hosts الموجود سلفًا إلى ملف جديد سنعمل عليه، ونمنحه اسم نطاق الموقع. اخترنا "example.com" مثالاً للتوضيح هنا:sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com الآن افتَح الملف الجديد: sudo nano /etc/nginx/sites-available/example.com سنُعدّل الجزء الخاص بالخادوم داخل الملف (الأسطُر الموجودة بين الأقواس المعكوفة الموجودة بعد كلمة server). ابدأ بتعليق تعليمة الإنصات للمنفَذ رقم 80. سنغيِّر أيضًا المجلّد الجذر ونطلُب من Nginx تقديم ملف (فهرس) PHP بشكل افتراضي: server { listen 80; root /var/www/example.com; index index.php index.hmtl index.htm; نأتي الآن لتعليمة server_name التي سنُعدّلها حتى تستخدم اسم النطاق الذي نريد. تأكّد من ضبط تعليمة try_files بشكل صحيح (تمرير الطّلبات إلى PHP في حال عدم عثور خادوم ويب Nginx على الملف المطلوب) وكذلك من ضبط صفحات الخطأ. server { listen 80; root /var/www/example.com; index index.php index.hmtl index.htm; server_name example.com; location / { try_files $uri $uri/ /index.php?q=$uri&$args; } error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/www; } نحتاج قبل الانتهاء من إعداد Nginx لضبط معالجة PHP عن طريق استعمال جزء location لمُطابقة جميع طلبات PHP. في حال تعثر الحصول على الملف المطلوب نُجيب مباشرة بخطأ 404. نستخدم هنا أيضًا نفس المقبس الذي استخدمناه في PHP. server { listen 80; root /var/www/example.com; index index.php index.hmtl index.htm; server_name example.com; location / { try_files $uri $uri/ /index.php?q=$uri&$args; } error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/www; } location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; } } بهذا ننتهي من إعداد الجزء المتعلّق بالخادوم. احفَظ ثم أغلق الملف. تبّقى لنا حذف رابط ملف الإعداد الافتراضي ثم ربط المجلّد المفعَّل حيثُ توجد ملفات الموقع بملف إعدادات الخادوم الذي ضبطناه للتو: sudo rm /etc/nginx/sites-enabled/default sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/ أعد تشغيل Nginx لأخذ التعديلات بالاعتبار: sudo service nginx restart ثبِّت ووردبريسبعد إعداد كل من خادوم الويب ومُعالج PHP إضافة لخادوم قاعدة البيانات نأتي لتثبيت تطبيق يعمل على خادوم الويب ويتّصل بقاعدة البيانات. سنثبت ووردبريس لتجربة الإعدادات التي ذكرناها سابقا. نزِّل آخر إصدار من ووردبريس (4.1.1 أثناء كتابة هذه السّطور) إلى مجلّدك الشخصي: cd ~ wget https://ar.wordpress.org/wordpress-4.1.1-ar.tar.gz استخرِج المفات عن طريق الأمر التالي الذي سينتُج عنه إنشاء مجلَّد باسم "wordpress" داخل مجلّدك الشخصي: tar xzvf latest.tar.gz يأتي مع ووردبريس مثال لملف الإعداد ولكنه غير جاهز للاستعمال، سنُعيد تسميَّته حتى يُقرأ بشكل صحيح ثم نفتحه بمحرّر نصوص للتعديل عليه: cp ~/wordpress/wp-config-sample.php ~/wordpress/wp-config.php nano ~/wordpress/wp-config.php أدخِل القيم الصحيحة للتعليمات التالية، تذكَّر أن تستخدِم نفس عنوان IP الذي استخدمتَه أثناء تجرية الاتصال بقاعدة البيانات. /** اسم قاعدة بيانات ووردبريس */ define('DB_NAME', 'wordpress'); /** اسم المستخدم لقاعدة البيانات */ define('DB_USER', 'wordpressuser'); /** كلمة المرور لقاعدة البيانات */ define('DB_PASSWORD', 'password'); /** عنوان خادوم قاعدة البيانات */ define('DB_HOST', 'database_server_ip'); احفَظ الملف بعد الانتهاء من تحريره ثم أغلقه. هذا هو الجزء الوحيد من الإعداد الذي يربط بشكل واضح بين خادوم الويب وخادوم قاعدة البيانات. الآن سننشئ بنية المجلَّد التي أدرجناها خلال إعداد خادوم Nginx، في الجزء المعلَّم ب server في ملف الإعداد، حيثُ استخدمنا "exemaple.com" كمثال توضيحي؛ استخدِم اسم النطاق الذي اخترتَه خلال إعداد Nginx: sudo mkdir -p /var/www/example.com تم ننسَخ الملفات والمجلَّدات الموجودة داخل مجلّد ووردبريس (wordpress/~) إلى المجلّد الجذر الذي أنشأناه للتّو: sudo cp -r ~/wordpress/* /var/www/example.com كل الملفات الآن في المكان الذي يجب أن تكون فيه، تبقى لنا فقط تغيير أذونات Permissions ومُلكية المجلّد. ننتقل إلى مبدأ المستند Document root في خادوم الويب (المجلّد الأعلى مستوًى Top-level directory الذي سيبحث فيه خادوم الويب عن محتوى الموقع): cd /var/www/example.com سنجعل من حساب خادوم الويب واسمُه www-data، مالكَ جميع الملفات في هذا المجلّد: sudo chown -R www-data:www-data * سنحتاج لإذن الكتابة في ملفات الموقع حتى يُمكننا التعديل عليها. لذا سنُضيف الحساب العادي غير الجذر إلى مجموعة Group خادوم الويب ثم نُعطي لهذه المجموعة إذن التعديل على الملفات الموجودة في هذا المجلَّد: sudo usermod -a -G www-data your_user sudo chmod -R g+rw /var/www/example.com إعداد الموقع عبر واجهة الويبكل ما تحتاجه الآن هو استكمال التثبيت عن طريق واجهة الويب. استخدِم المتصفّح للدخول إلى اسم نطاق الموقع (يُمكن أيضا استخدام عنوان IP العمومي): http://example.com يجب أن تظهر شاشة تثبيت ووردبريس والتي يجب أن تملأ حقول النموذج الموجود فيها بالمعلومات الضرورية: استخدِم الحساب الذي أنشأتَه على ووردبريس أثناء ضبط إعداداته للولوج إلى لوحة التحكم: ستُنقَل بعدها إلى لوحة تحكم ووردبريس حيثُ يمكنك البدء في إعداد موقعك. قيّد أذون الولوج عن بعد إلى قاعدة البياناتنعود الآن بعد الانتهاء من تثبيت ووردبريس إلى استرجاع بعض الأذونات التي منحناها لمستخدِم قاعدة البيانات البعيد. لن يحتاج ووردبريس لصلاحيات إدارية إلا عند التحديث أو أثناء تثبيت الإضافات. انتبِه لهذا الأمر في حال واجهتك رسالة خطأ عند إجراء بعض العمليات الإدارية بعد تقييد أذون الولوج عن بعد إلى قاعدة البيانات. انتبه أيضًا إلى أن بعض الإضافات تطلُب أذونا إضافية وابحث في كل إضافة للتأكد من ما تحتاجه مع اختيار الإضافات التي تطلُب أقل قدر من الصّلاحيات. ادخُل على خادوم قاعدة البيانات ثم إلى MySQL باستخدام الحساب الجذر : mysql -u root -p سيُطلب منك إدخال كلمة السر. نفّذ الأمر التالي لإظهار أذون المستخدِم البعيد: show grants for 'wordpressuser'@'web_server_IP'; +---------------------------------------------------------------------------------------------------------------------------+ | Grants for wordpressuser@xxx.xxx.xxx.xxx | +---------------------------------------------------------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'wordpressuser'@'xxx.xxx.xxx.xxx' IDENTIFIED BY PASSWORD '*5FD2B7524254B7F81B32873B1EA6D681503A5CA9' | | GRANT ALL PRIVILEGES ON `wordpress`.* TO 'wordpressuser'@'xx.xxx.xxx.xxx' | +---------------------------------------------------------------------------------------------------------------------------+ 2 rows in set (0.00 sec) لا يعني إذن الاستعمال Usage في السّطر الأول أي صلاحيات فعلية، لذا لن نهتمّ به هنا. الصّلاحيات الموجودة في السّطر الثاني هي التي أعددناها في خطوة سابقة من هذا الدّليل حيثُ أعطينا المستخدِم wordpressuser كامل الصلاحيات (ALL PRIVILEGES في الجدول أعلاه) على قاعدة البيانات wordpress عند الاتصال عن بعد بخادوم قاعدة البيانات. تتكون عملية تقييد الصّلاحيات من خطوتين. أولا ننزع كل الصّلاحيات الممنوحة حاليا للمستخدِم، وذلك عبر الأمر: REVOKE ALL PRIVILEGES on wordpress.* FROM 'wordpressuser'@'web_server_IP'; عند طلب إظهار صلاحيّات المستخدِم الحالية سنُلاحظ اختفاء السّطر الثاني: show grants for 'wordpressuser'@'web_server_IP'; +---------------------------------------------------------------------------------------------------------------------------+ | Grants for wordpressuser@xxx.xxx.xxx.xxx | +---------------------------------------------------------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'wordpressuser'@'xxx.xxx.xxx.xxx' IDENTIFIED BY PASSWORD '*5FD2B7524254B7F81B32873B1EA6D681503A5CA9' | +---------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) ثانيا، نُحدّد الصلاحيات التي نرغب في منحها لحساب المستخدِم، وهي كما ذكرنا سالفا القراءة من قاعدة البيانات (SELECT) ، وحذف سطر من جدول (DELETE)، وإضافة سطر إلى جدول (INSERT) وتحديث البيانات الموجودة (UPDATE): GRANT SELECT,DELETE,INSERT,UPDATE ON wordpress.* TO 'wordpressuser'@'web_server_ip'; تحقّق مجدّدا بعد تنفيذ الأمر السابق من صلاحيات المستخدِم وستلحَظ الصّلاحيات الجديدة. بقي أن نطلُب من MySQL أخذ التغييرات التي أجريناها في الاعتبار عن طريق الأمر: FLUSH PRIVILEGES; للخروج من سطر أوامر MySQL: exit خاتمةينبغي أن يكون لديك بعد متابعة هذا الدرس فهمٌ جيّد لكيفية جعل تطبيقك يتفاعل مع قاعدة بيانات بعيدة. رأينا في الإعدادات أعلاه خطوات خاصة بووردبريس ولكن هذا لا يمنع من فهم الفكرة العامة لإعداد MySQL وضبط صلاحيات المستخدمين ثم تطبيقها حسب حاجة التطبيق الذي تُريد التعامل معه. ترجمة -وبتصرّف- للمقال: How To Set Up a Remote Database to Optimize Site Performance with MySQL

يُعتبَر خادوم ويب Apache الوسيلة الأكثر شعبيةً لتقديم المحتوى على شبكة الإنترنت، حيثُ يستعمله أكثر من نصف مواقع الويب على الشبكة لقدرته الفائقة ومرونته العالية. يُقسِّم خادوم Apache وظائفَه والعناصر التي تُكوِّنه إلى عدة وحدات يُمكِن تخصيصها وإعدادُها بشكل مستقل. تُسمَّى الوحدة الأساسية - التي تُمثِّل نطاقًا Domain أو موقع ويب - مُستضيفًا افتراضيًا Virtual host. تُتيح المُستضيفات الافتراضية إمكانية استضافة عدة نطاقات أو مواقع ويب على نفس العنوان باستخدام آليةٍ للمطابقة بين مُستضيف افتراضي وموقع ويب. تُناسِب هذه الطّريقة أي شخص يُريد استضافة عدة مواقع على نفس الخادوم الافتراضي الخاص Virtual private server, VPS. يُوجِّه كل واحد من النطاقات المضبوطة الزائرَ إلى مجلَّد مُحدَّد توجد به معلومات الموقع المطلوب دون أن يُشيرَ أبدًا إلى أن مواقع أخرى تُدار على نفس الخادوم. يُمكِن بطريقة المستضيفات الافتراضية ضبط عدد غير محدود من المواقع على نفس الخادوم ما دام يتحمّل عبئ الحِمل Load الذي تُمثِّله هذه المواقع. سنعرِض في هذا المقال طريقة إعداد مستضيفات افتراضية على خادوم ويب Apache يعمل على خادوم افتراضي خاص مع توزيعة أوبنتو 14.04. ستتعلَّم كيف تُقدِّم محتوى مختلِفا لزوّار متعدِّدين حسب النطاق الذي يطلبونه. المتطلباتقبل البدء في هذا الدّرس يجب إنشاء مستخدم آخر غير المستخدِم الجذر Root user كما هو موضَّح في الخطوات من 1 إلى 4 من الدرس الإعداد الابتدائي لخادوم أوبنتو. ستحتاج أيضًا إلى تثبيت خادوم ويب Apache لمتابعة الخطوات المذكروة في هذا الدّرس. إن لم تكُن ثبَّت البرنامج حتى الآن يُمكنك ذلك باستخدام أداة apt-get كما يلي: sudo apt-get update sudo apt-get install apache2بعد استكمال هذه الخطوات يُمكننا البدء. سنُنشئ خلال هذا الدرس مستضيفَيْن افتراضييْن، واحد للنطاق example.com والآخر لـ test.com. أثناء إعداد مستضيفاتك الافتراضية استخدِم النطاقات الخاصّة بك مكان المثاليْن المذكوريْن هنا. سنُريك خلال هذا الدّرس كيف تُحرِّر ملف المستضيفات على جهازك الشخصي Local hosts file لاختبار إعداداتك إن كنتَ تستخدم نطاقات وهمية. ستتمكَّن بهذه الطريقة من تجربة الإعدادات من جهازك الشخصي رغم أن المحتوى لن يكون مُتاحا لزوّار آخرين عبر النطاق الوهمي. الخطوة الأولى - أنشئ بنية المجلد Directory structureأول خطوة نقوم بها هي إنشاء بنية المجلَّد الذي سيحوي بيانات الموقِع الذي ننوي تقديمه إلى الزّوّار. يُعرَّف مبدأ المستند Document root بأنه المجلّد الأعلى مستوًى Top-level directory الذي سيبحث فيه خادوم وب Apache عن محتوى الموقع. بالنسبة لمثالنا سننشئ مبدأ مستند (مجلَّد) داخل المسار var/www/ لكلٍّ من المستضيفين الافتراضيّين الذين نعدهما. داخل كل من المجلَّدين نُنشئ مجلَّدًا باسم public_html، وهو المجلَّد الذي سيحوي ملفات الموقع وهو ما يمنح بعض المرونة في الاستضافة. لتطبيق ما ورد في الفقرة أعلاه نُنفِّذ الأوامر التالية: sudo mkdir -p /var/www/example.com/public_html sudo mkdir -p /var/www/test.com/public_htmlفي الأمرين السابقين يظهر كل من النطاقين الذين نريد تقديمهما من خادومنا الافتراضي الخاص باللون الأحمر. الخطوة الثانية - امنح الأذونات Permissionsأنشأنا في الخطوة الأولى بنية المجلَّدات، لكن هذه المجلَّدات مملوكة من المستخدِم الجذر، نظرا لاستخدام sudo أمام أمر إنشاء المجلّد. إن أردنا إعطاء المستخدِم العادي القدرة على تحرير الملفات الموجودة في مجلَّد الوب فبإمكاننا تغيير مُلكية هذه المجلّدات عن طريق الأمر: sudo chown -R $USER:$USER /var/www/example.com/public_html sudo chown -R $USER:$USER /var/www/test.com/public_htmlعند تنفيذ الأمر - بالضغط على زر Enter - فإن المتغيّر USER$ سيُبدَل بقيمته وهي اسم المستخدِم الحالي. ينتج عن الأمر تغيير ملكية المجلَّد public_html الذي يتضمّن محتوى الموقِع فيُصبِح المستخدم الحالي هو المالك بدلا من المستخدِم الجذر. سيتوجّب علينا أيضًا تغيير الأذونات قليلًا للتأكد من أنّ إذن القراءة متاح من مجلّد الويب العام (var/www/) وكل الملفات الموجودة داخله أو داخل المجلّدات المتفرّعة منه حتى يُقدَّم المحتوى بشكل صحيح: sudo chmod -R 755 /var/wwwلدى خادوم الويب الآن الأذونات التي يحتاجها لتقديم المحتوى، ولدى المستخدم أيضا القدرة على إنشاء وتحرير المجلَّدات التي يحتاجها. الخطوة الثالثة - أنشئ صفحات تجريبية Demo pages لكل مستضيف افتراضيفي هذه الخطوة سننشئ محتوى لتقديمه. الهدف من إنشاء المحتوى في هذه الخطوة توضيحي، لذا ستكون الصفحات بسيطة جدا: index.html لكل موقع. سنبدأ بـ example.com. نستطيع إنشاء وتحرير ملف index.html عن طريق محرِّر nano عبر الأمر التالي: nano /var/www/example.com/public_html/index.htmlأضف مستنَد HTML بسيطًا يُبرز اسم الموقع. يظهر الملف بالشكل التالي: <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title> Example.com أهلًا بك في موقع</title> </head> <body dir="rtl"> <h1>هنيئا لك! المُستضيف الافتراضي Example.com يعمل بشكل صحيح</h1> </body> </html>احفظ الملف (Ctrl+O ثم زر Enter) ثم أغلقه بعد الانتهاء من تحريره (Ctrl+x). ننسخ الملف ليكون أساس الموقع الثاني عبر الأمر : cp /var/www/example.com/public_html/index.html /var/www/test.com/public_html/index.htmlيُمكِن بعدها فتح الملف وتحرير المعلومات لتُناسب الموقع الثاني: nano /var/www/test.com/public_html/index.html<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title> Test.com أهلًا بك في موقع</title> </head> <body dir="rtl"> <h1>هنيئا لك! المُستضيف الافتراضي Test.com يعمل بشكل صحيح</h1> </body> </html>احفظ الملف ثم أغلقه. لدينا الآن الصفحات الضرورية لاختبار إعداد المستضيف الافتراضي. الخطوة الرابعة - أنشئ ملفات مستضيفات افتراضية جديدةتُحدِّد ملفات المستضيفات الافتراضية إعدادات هذه المستضيفات كما أنها تُملي على خادوم ويب Apache الكيفية التي سيُجيب بها على طلبات النطاقات المختلفة. يأتي خادوم Apache بملف ابتدائي اسمه 000-default.conf لإعداد المستضيفات الافتراضية. يُمكننا استخدام هذا الملف للبدء، لذا سننسخ هذا الملف لإعداد المستضيفات الافتراضية الخاصة بنطاقاتنا. سنبدأ بإعداد أحد النطاقات ثم ننسخه إلى النطاق الثاني مع القيام بالتعديلات اللازمة. يجب - في الإعداد المبدئي لأوبنتو - أن ينتهي ملف المستضيف الافتراضي بالامتداد conf. أنشئ ملف المستضيف الافتراضي الأول. ابدأ بنسخ ملف النطاق الأول: sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/example.com.confافتَح الملف الجديد في المحرِّر بامتيازات المستخدِم الجذر : sudo nano /etc/apache2/sites-available/example.com.confسيبدو الملف بالشكل التّالي (حُذِفت التعليقات لجعل الملف أسهل للقراءة): <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>احفظ الملف ثم أغلقه بعد الانتهاء من تحريره. الخطوة الخامسة - فعل ملفات المستضيفات الافتراضية الجديدةبعد إنشاء ملفات إعداد المستضيفات الافتراضية نأتي لخطوة التفعيل؛ يوفِّر خادوم Apache بعض الأدوات لهذا الغرض. لتفعيل الموقعيْن نستخدم أداة a2ensite كما يلي: sudo a2ensite example.com.conf sudo a2ensite test.com.confثم نعيد تشغيل Apache لأخذ التغييرات بالاعتبار: sudo service apache2 restartأثناء إعادة تشغيل خادوم الوب قد تظهر رسالة كالتالية: * Restarting web server apache2 AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this messageلا يُمثِّل هذا التحذير أي خطر وليس له تأثير على موقعك. الخطوة السادسة - اضبط ملف المستضيفات المحلي (خطوة اختيارية)إن لم تتوفّر لديك أسماء نطاقات حقيقية لتجربة الخطوات المذكورة في هذا الدّرس يُمكنك اختيار نطاقات وهمية والتجربة بها على جهاز ك المحلي (الشخصي) عن طريق التعديل المؤقَّت على ملف المستضيفات المحلي. ستُوَجَّه كل طلبات النطاقات المضبوطة بهذه الطريقة إلى خادومك الافتراضي الخاص، تماما كما كان سيفعل نظام أسماء النِّطاقات Domain Name System, DNS لو استخدمتَ أسماء نطاقات مُسَجَّلة. ينبغي الانتباه أن هذه الطريقة ستعمل من جهازك الشخصي فقط وتقتصر على اختبار الإعدادات. تأكَّد من القيام بالخطوات التالية على جهازك المحلي وليس على خادومك الافتﻻاضي الخاص. ستحتاج لمعرفة كلمة سر اسم المستخدِم الجذر أو أن تكون ضمن مجموعة المديرين على نظام التشغيل. الأمر التالي يفتح ملف المستضيفات للتحرير على أنظمة Linux و Mac: sudo nano /etc/hostsبالنسبة لمستخدمي Windows توجد تعليمات التعديل على ملف المستضيفات هنا. ستحتاج لعنوان IP العمومي لخادومك الافتراضي الخاص والنطاق الذي تُريد استخدامه للوصول إلى الخادوم الافتراضي. يتكوَّن سطر ملف الإعداد من عنوان IP متبوعًا باسم النطاق. باعتبار أن 111.111.111.111 هو عنوان IP الخادوم نُضيف الأسطر التالية في أسفل ملف المستضيفات: 127.0.0.1 localhost 127.0.1.1 guest-desktop 111.111.111.111 example.com 111.111.111.111 test.comبهذه الطّريقة ستُوجَّه كل استعلامات الجهاز المحلي التي تطلُب النِّطاقين example.com أو test.com إلى الخادوم على العنوان 111.111.111.111، وهو ما يُساعدنا على اختبار إعدادات خادوم الوب إن لم نكن مالِكي النطاقيْن المذكوريْن. احفَظ الملف ثم أغلِقه. الخطوة السابعة - اختبر النتائجيُمكنك بعد الانتهاء من ضبط المُستضيفات الافتراضية اختبار الإعدادت بالذهاب إلى النطاقات المضبوطة عبر متصفِّح الوب: http://example.comيجب أن تكون النتيجة كما في الصّورة: الشيء بالنسبة للموقع الآخر: http://test.comستظهر الصّفحة التي أنشأتَها في الملف الثاني: يدل ظهور الصفحتين بشكل صحيح أن إعداد مستضيفيْن افتراضيّيْن على نفس الخادوم جرى بطريقة جيّدة. لا تنسَ حذف الأسطر الإضافية من ملف المستضيفات المحلي بعد التأكد من إعداد المستضيفات الافتراضية على الخادوم. أُضيفت هذه الأسطُر للاختبار فقط ومن الأحسن حذفها بعد انتهائه. ستحتاج إلى شراء وإعداد نطاقات إن احتجتَ دائما إلى خادومك عن طريق أسماء نطاقات. خاتمةستحصُل بعد متابعة هذا الدّرس على خادوم ويب واحد يتعامل مع نطاقيْن منفصلين. يُمكنك زيادة عدد النطاقات باتّباع الخطوات المذكورة أعلاه لإنشاء مستضيفات افتراضية جديدة. لا توجد تقييد على عدد النطاقات التي يُمكِن لـApache التعامل معها، أضِف ما تُريد من النطاقات ما دام الخادوم يستطيع تحمّلَها. ترجمة -وبتصرّف- للمقال How To Set Up Apache Virtual Hosts on Ubuntu 14.04 LTS لصاحبه Justin Ellingwood.