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

تحتاج خطط الاسترداد التي أعددناها في الجزء السابق إلى نظام للنسخ الاحتياطي. سنركز في هذا المقال على نظام النسخ الاحتياطي Bacula. يتيح Bacula تحكّمًا تامًا في ما تريد نسخه أو استعادته على المستوى الفردي للملفات؛ كما يسمح بجدولة النسخ الاحتياطي والاستعادة وفقا لما تراه أفضل بالنسبة لك. سنُعدّ Bacula في هذا الجزء لتخزين نسخ احتياطية يوميا. تحوي النسخُ الملفاتِ الضروريةَ من الخواديم التي تكون التطبيق (app2، app1، db1 وlb1). حددنا في الجزء السابق الملفات التي نريد نسخها احتياطيا. يُريك هذا المقال كيفية استخدام Bacula لإنشاء نسخ احتياطية من حزمة برمجيات LAMP (أي MySQL، Apache، Linux وPHP). سنستعمل أيضا Percona XtraBackup لإنشاء نسخ احتياطية ساخنة Hot backups من قاعدة بيانات MySQL. ثم - في الأخير - نستخدم rsync لنسخ الملفات التي أنشأها Bacula على خادوم يوجد في موقع جغرافي آخر؛ أي أنه ستكون لدينا نسختان احتياطيتان، واحدة موجودة في نفس مركز بيانات الذي توجد به بيئة الإنتاج والأخرى في موقع ناء. سنضيف خادومين إلى الخواديم الموجودة سلفا: backups وremotebackups؛ الأخير يوجد في مركز بيانات ناء. ملحوظة: نعني بالنسخ الاحتياطي الساخن - أو الديناميكي - أخذ نسخة من قاعدة البيانات وهي في حالة نشاط؛ مما يعني أنه قد يحصل تعديل عليها أثناء عملية النسخ. يقابل النسخَ الساخن النسخُ البارد Cold backup والذي توقف فيه قاعدة البيانات عن العمل، ثم تؤخذ نسخة منها قبل أن يُعاد تشغيلها. تثبيت Bacula على خادوم النسخ الاحتياطيةاضبط Bacula على خادوم backups باتباع خطوات الدرس التالي: كيف تثبت خادوم Bacula على Ubuntu 14.04. ثم اتبع فقرة تنظيم إعداد مدير Bacula (الخادوم) في مقال كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula. ستحتاج لاسم المدير Director name عند إعداد عملاء Bacula على الخواديم التي تريد نسخها احتياطيا. توقف عند الوصول إلى فقرة تثبيت عميل Bacula وإعداده. تثبيت عميل Bacula على كل خادومثبت عميل Bacula على كل واحد من الخواديم التي تريد نسخها احتياطيا (app2، app1، db1 وlb1) باتباع فقرة تثبيت عميل Bacula وإعداده من درس كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula. توقف عند الوصول إلى فقرة إضافة مجموعة ملفات FileSets (الخادوم). يرجى الانتباه إلى أنك ستحتاج اسم FileDaemon (جنيّ الملفات، يكون عادة اسم المستضيف مضافا إليه “fd-“) وكلمة سر المدير Director (كلمة السر التي سيستخدمها خادوم Bacula للاتصال بكل واحد من العملاء). توجد القيمتان ضمن ملف bacula-fd.conf الموجود على كل خادوم. إضافة عملاء Bacula إلى خادوم النسخ الاحتياطيأضف، إلى خادوم Bacula (أي backups)، موردَ عميل Client resource لكل واحد من الخواديم التي ثبت عليها عميل Bacula. يُضاف مورد العميل إلى الملف etc/bacula/conf.d/clients.conf/: sudo nano /etc/bacula/conf.d/clients.confفي ما يلي مثال على تعريف مورد العميل بالنسبة لخادوم قاعدة البيانات db1. يجب أن توافق قيمة Name اسم المورد FileDaemon الموجود على الخادوم العميل. نفس الشيء بالنسبة لPassword التي يجب أن توافق قيمة Password ضمن مورد Director على الخادوم العميل. توجد هذه القيم في ملف etc/bacula/bacula-fd.conf/ على كل واحد من عملء Bacula. Client { Name = db1-fd Address = db1.nyc3.example.com FDPort = 9102 Catalog = MyCatalog Password = "PDL47XPnjI0QzRpZVJKCDJ_xqlMOp4k46" # كلمة سر العميل File Retention = 30 days # 30 يوما Job Retention = 6 months # 6 أشهر AutoPrune = yes # التخلص من الأشغال/الملفات منتهية الصلاحية }أنشئ بنفس الطريقة مورد عميل لكل واحد من الخواديم العميلة لخادوم Bacula. يجب بانتهاء الإعداد في المثال أن تكون لدينا أربعة موارد عملاء: app2-fd، app1-fd، db1-fd وlb1-fd. تضبط هذه الإعدادات الخادوم backups ليكون قادرا على الاتصال بعميل Bacula الموجود على كل خادوم. احفظ الملف ثم أغلقه. يمكن الحصول على تفاصيل أكثر بمراجعة فقرة تثبيت عميل Bacula وإعداده في درس كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula. إنشاء نسخ احتياطية ساخنة من قاعدة البياناتيجب إيلاء اهتمام خاص لنسخ قاعدة البيانات الاحتياطية، من أجل إنشاء نسخ احتياطية متناسقة وقابلة للاستخدام. توجد طريقة سهلة وفعالة لإنشاء نسخ احتياطية ساخنة لقاعدة بيانات MySQL وهي استخدام Percona XtraBackup. تثبيت Percona XtraBackupثبت Percona XtraBackup واضبطه على خادوم قاعدة البيانات db1 باتباع خطوات الدرس كيف تستخدم Percona XtraBackup لإنشاء نسخ احتياطية فورية من قواعد بيانات MySQL على Ubuntu 14.04. توقف عند الوصول إلى فقرة إنشاء نسخة احتياطية كاملة فوريا. إنشاء سكربت XtraBackupPercona XtraBackup جاهز الآن لإنشاء نسخ احتياطية ساخنة من قاعدة بيانات MySQL. سيحتفظ Bacula بهذه النسخ؛ إلا أنه يجب أولا إيجاد طريقة لجدولة النسخ الساخنة. نستخدم cron لهذه المهمة. أنشئ سكربت Bash في usr/local/bin/ وسمه run_extra_backup.sh: sudo nano /usr/local/bin/run_xtrabackup.shأضف السكربت التالي إلى الملف الذي أنشأته للتو (تأكد من إدراج اسم المستخدم وكلمة السر الذين استعملتهما عند تثبيت XtraBackup): #!/bin/bash # pre xtrabackup chown -R mysql: /var/lib/mysql find /var/lib/mysql -type d -exec chmod 770 "{}" \; # delete existing full backup rm -r /data/backups/full # xtrabackup create backup innobackupex --user=bkpuser --password=bkppassword --no-timestamp /data/backups/full # xtrabackup prepare backup innobackupex --apply-log /data/backups/fullاحفظ الملف ثم أغلقه. سيؤدي تنفيذ هذا الملف بصلاحيات الحساب الإداري إلى حذف نسخة XtraBackup الاحتياطية الموجودة ضمن مسار data/backups/full/ وإنشاء نسخة احتياطية كاملة جديدة. توجد تفاصيل أكثر عن النسخ الاحتياطية باستخدام XtraBackup ضمن فقرة إنشاء نسخة احتياطية كاملة ساخنة في درس XtraBackup. اجعل السكربت قابلا للتنفيذ: sudo chmod +x /usr/local/bin/run_xtrabackup.shيجب تنفيذ سكربت XtraBackup وإكماله قبل أن يحاول Bacula أخذ نسخة احتياطية من خادوم قاعدة البيانات، وذلك من أجل نسخ قاعدة البيانات بطريقة صحيحة. يمكن إعداد شغل Job في Bacula للتعامل مع السكربت على أنه “سكربت لما قبل النسخ الاحتياطي”؛ إلا أننا سنختار هنا استخدام شغل cron توخيا للسهولة. أنشئ ملف إعداد لcron (تُضاف الملفات الموجودة ضمن المجلد etc/cron.d/ إلى جدول cron الخاص بالمستخدم الجذر): sudo nano /etc/cron.d/xtrabackupأضف شغل cron التالي: 30 22 * * * root /usr/local/bin/run_xtrabackup.shيُجدول هذا الشغل السكربت ليعمل بصلاحيات الجذر كل يوم عند الساعة العاشرة والنصف مساء (22:30). اخترنا هذا الوقت لأن Bacula مُجدول حاليا ليأخذ نسخا احتياطية يوميا عند الساعة الحادية عشرة مساء وخمس دقائق (23:05). سنناقش هذا الخيار في ما بعد. يعطينا فارق الجدولة هذا 35 دقيقة ليكتمل عمل سكربت XtraBackup. اكتمل الآن إعداد النسخ الاحتياطي الساخن لقاعدة البيانات. ننتقل لمجموعات ملفات FileSets النسخة الاحتياطية لBacula. إعداد مجموعة ملفات FileSets في Baculaسننشئ نسخا احتياطية من الملفات المحدَّدة ضمن مجموعة الملفات المربوطة بأشغال النسخ الاحتياطي التي ستُنفَّذ. ستغطي هذه الفقرة إنشاء مجموعة ملفات تحوي النسخ الاحتياطية الضرورية المحدّدة في خطط الاسترداد. يمكن إيجاد تفاصيل أكثر عن إضافة مجموعة ملفات إلى Bacula تحت فقرة إضافة مجموعة ملفات FileSets (الخادوم) في درس Bacula. افتح ملف filesets.conf الموجود على خادوم النسخ الاحتياطي backups: sudo nano /etc/bacula/conf.d/filesets.confمجموعة الملفات الخاصة بخادوم قاعدة البياناتتتضمن النسخ الاحتياطية المطلوبة من خادوم قاعدة البيانات، وفقا لخطة استرداد قاعدة البيانات: قاعدة بيانات MySQL: ينشئ سكربت XtraBackup نسخة احتياطية من قاعدة البيانات يوميا عند الساعة 22:30 ويضعها في المجلد data/backups/full/.ملف إعداد MySQL الموجود في المجلد etc/mysql/.سنضمِّن أيضا سكربت usr/local/bin/run_xtrabackup.sh/ وملف cron المتعلق به. نضيف اعتمادا على ما سبق مجموعة ملفات باسم MySQL Database إلى إعداد Bacula: FileSet { Name = "MySQL Database" Include { Options { signature = MD5 compression = GZIP } File = /data/backups File = /etc/mysql/my.cnf File = /usr/local/bin/run_xtrabackup.sh File = /etc/cron.d/xtrabackup } Exclude { File = /data/backups/exclude } } ننتقل الآن إلى مجموعة ملفات التطبيق. مجموعة الملفات الخاصة بخادوم التطبيقتتضمن النسخ الاحتياطية المطلوبة من خادوم التطبيق وفقا لخطة استرداد هذا الأخير: ملفات التطبيق الموجودة - في مثالنا - على المسار var/www/html/.نضيف اعتمادا على هذه المعلومة مجموعة ملفات Apache DocumentRoot إلى ملف إعداد Bacula: FileSet { Name = "Apache DocumentRoot" Include { Options { signature = MD5 compression = GZIP } File = /var/www/html } Exclude { File = /var/www/html/exclude } } يمكن أيضا أن تضيف ملف الإعداد الخاص بمنافذ Apache، إلا أنه يمكن تغيير هذا الملف بسهولة عند الحاجة. مجموعة الملفات الخاصة بخادوم توزيع الحملالطريقة المتَّبعة هي نفسها. نحدد الملفات المطلوب نسخها ثم ننشئ مجموعة ملفات في Bacula اعتمادا عليها. الملفات المطلوبة: ملف PEM الخاص بشهادة SSL والملفات المتعلقة بها، توجد هذه الملفات على مسار root/certs/ في مثالنا.ملف إعداد HAProxy: يوجد في مجلد etc/haproxy.سنضيف هذه الملفات إلى مجموعة Apache DocumentRoot: FileSet { Name = "Apache DocumentRoot" Include { Options { signature = MD5 compression = GZIP } File = /var/www/html File = /root/certs File = /etc/haproxy } Exclude { File = /var/www/html/exclude File = /root/exclude } }احفظ الملف ثم أغلقه. بهذا نكمل إعداد مجموعات الملفات. ننتقل لإعداد أشغال Bacula التي ستستخدم هذه المجموعات. إنشاء أشغال النسخ الاحتياطي في Baculaمهمة الأشغال في Bacula هي إنشاء نسخ احتياطية من الخواديم. أنشئ ملف jobs.conf في المسار etc/bacula/conf.d/: >sudo nano /etc/bacula/conf.d/jobs.confشغل النسخ الاحتياطي لخادوم قاعدة البياناتسننشئ شغل نسخ احتياطي جديدا لخادوم قاعدة البيانات باسم Backup db1. من المهم هنا تحديد الاسم الصحيح للعميل db1-fd واسم مجموعة الملفات MySQL Database: Job { Name = "Backup db1" JobDefs = "DefaultJob" Client = db1-fd Pool = RemoteFile FileSet="MySQL Database" }أشغال النسخ الاحتياطي لخواديم التطبيقاتسننشئ شغل نسخ احتياطي لكل من خادومي التطبيق، Backup app1 للخادوم app1 وBackup app2 لapp2. من المهم، مثل ما فعلنا مع خادوم قاعدة البيانات، تحديد الأسماء الصحيحة للعملاء (app1-fd وapp2-fd) ومجموعة الملفات (Apache DocumentRoot). بالنسبة للخادوم app1: Job { Name = "Backup app1" JobDefs = "DefaultJob" Client = app1-fd Pool = RemoteFile FileSet="Apache DocumentRoot" } وبالنسبة للخادوم app2: Job { Name = "Backup app2" JobDefs = "DefaultJob" Client = app2-fd Pool = RemoteFile FileSet="Apache DocumentRoot" }شغل النسخ الاحتياطي لخادوم توزيع الحملنتبع نفس مبدأ الخطوات السابقة لإنشاء شغل جديد ونسميه Backup lb1: Job { Name = "Backup lb1" JobDefs = "DefaultJob" Client = lb1-fd Pool = RemoteFile FileSet="SSL Certs and HAProxy Config" }احفظ الملف ثم أغلقه. إعادة تشغيل مدير Baculaأعد تشغيل Bacula على خادوم النسخ الاحتياطي لاعتماد التغييرات التي أجريناها في الفقرات السابقة: sudo service bacula-director restartيجب أن تختبر، بالوصول إلى هذه النقطة، اتصالات عملاء Bacula وأشغال النسخ الاحتياطي. يغطى مقال كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula هذين الجانبين. يُرجى ملاحظة أنه لاستعادة قاعدة بيانات MySQL ستحتاج لاتباع خطوة الاستعادة من نسخة احتياطية ضمن درس Percona XtraBackup. مراجعة جدول النسخ الاحتياطييمكن تنظيم جدول النسخ الاحتياطي في Bacula بالتعديل على إعداد مدير Bacula (الملف etc/bacula/bacula-dir.conf/). تستخدم جميع الأشغال التي أنشأناها تعريف الشغل DefaultJob الذي يستخدم جدولةً بدورة أسبوعية تعرَّف على النحو التالي: نسخة احتياطية كاملة Full backup في أول يوم أحد من الشهر عند الساعة 23:05.نسخ احتياطية تفاضلية Differential backups في أيام الأحد المتبقية عند الساعة 23:05.نسخ احتياطية تزايدية Incremental backups في باقي الأيام، من الإثنين إلى السبت عند الساعة 23:05.يمكنك التأكد من طريقة الجدولة وفحص حالة المدير في وحدة تحكم Bacula. يجب أن يظهر جميع الأشغال المُجدولة: Scheduled Jobs: Level Type Pri Scheduled Name Volume =================================================================================== Incremental Backup 10 20-May-15 23:05 BackupLocalFiles MyVolume Incremental Backup 10 20-May-15 23:05 Backup lb1 Remote-0002 Incremental Backup 10 20-May-15 23:05 Backup app2 Remote-0002 Incremental Backup 10 20-May-15 23:05 Backup app1 Remote-0002 Incremental Backup 10 20-May-15 23:05 Backup db1 Remote-0002سيكون من الجيد ضبط جدولة النسخ في خواديم التطبيقات بحيث يحدُث في نفس الوقت الذي ينسَخ فيه سكربت XtraBackup قاعدة البيانات (22:30)؛ وهو ما سيحول دون أن تكون نسخ خواديم التطبيقات غير متجانسة مع نسخة قاعدة البيانات. إعداد نسخ احتياطية نائيةيمكننا الآن إعداد خادوم ناء نحفظ فيه النسخ الاحتياطية التي أنشأها Bacula (إضافة إلى حفظها على خادوم Bacula). يجب أن يكون هذا الخادوم في موقع جغرافي منفصل لكي يمكنك الحصول على النسخ الاحتياطية الهامة إن حدث مشكل مزمن في مركز البيانات الذي توجد فيه بيئة الإنتاج. اخترنا SF01 في المثال موقعا لخادوم remotebackups. سنشرح طريقة سهلة لإرسال النسخ الاحتياطية من خادوم backups إلى خادوم remotebackups باستخدام مفاتيح SSH، أداة rsync وcron. أنشئ حسابا على خادوم remotebackups لاستخدامه في الولوج عبر rsync. ثم أنشئ باستخدام الحساب الجذر زوج مفاتيح SSH لا يحتاج لكلمة سر على خادوم backups. ثبت المفتاح العمومي على الحساب الذي أنشأته للتو على خادوم remotebackups؛ الطريقة مشروحة في مقال العمل مع خواديم SSH: العملاء والمفاتيح اكتب، على خادوم backups أمر rsync ينسخ الملفات الموجودة على مسار bacula/backup/ إلى مكان يوجد على خادوم remotebackups. يغطي درس كيف تستخدِم Rsync لمزامنة مجلّدات بين الجهاز المحلّي والخادوم طريقة استخدام rsync. الشكل العام للأمر سيكون على النحو التالي (remoteuser الحساب على الخادوم البعيد، remotebackups_public_hostname_or_IP اسم المستضيف أو عنوان IP العمومي الخاص بالخادوم البعيد، وpath/to/remote/backup/ مسار مجلد النسخ الاحتياطي على الخادوم البعيد): rsync -az /bacula/backup remoteuser@remotebackups_public_hostname_or_IP:/path/to/remote/backupأضف الأمر لسكربت، مثلا: usr/local/bin/rsync_backups.sh/ واجعله قابلا للتنفيذ. وأخيرا، اضبط شغل cron ينفذ سكربت rsync_backups.sh بصلاحيات root بعد إكمال أشغال Bacula. تمكن مراجعة درس كيف تجدول مهامك الروتينية باستخدام أداتي Cron و Anacron في لينكس لمزيد من التفاصيل عن عمل cron. تأكد بعد ضبط كل هذه الإعدادات من وجود نسخ احتياطية على خادوم remotebackups في اليوم الموالي. اعتبارات أخرىلم نتحدث في ما سبق عن متطلبات القرص الصلب من ناحية التخزين. يجب أن تراجع مساحة التخزين التي تستخدمها نسخك الاحتياطية ثم تعيد النظر في إعداد النسخ الاحتياطي وجدولته وفقا لاحتياجاتك والموارد المتوفرة لديك. يمكن أن تحتاج أيضا إلى إعداد نسخ احتياطية لخواديم أخرى غير خواديم التطبيق. على سبيل المثل خادوما المراقبة والسجلات بعد إكمال إعدادهما. خاتمةيجب أن تكون لديك الآن نسخ احتياطية يومية من خواديم التطبيق في بيئة الإنتاج، ونسخ منها على خادوم بعيد. تحقق من إمكانية استعادة الملفات وأضف خطوات استعادة البيانات إلى خطط الاسترداد. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Backups لصاحبه Mitchell Anicas.

يمكننا الآن، بعد إكمال إعداد بيئة الإنتاج في الدرس السابق، البدء في إعداد نظام مركزي للسجلات؛ وهو وسيلة رائعة لجمع سجلات الخواديم ومعاينتها. لا يعدّ إعداد نظام سجلات دقيق، على العموم، في نفس أهمية توفر نظامي نسخ احتياطي ومراقبة فعالين؛ إلا أنه يمكن أن يكون مفيدا جدا عند البحث في اتجهات استخدام التطبيق أو أثناء محاولة تحديد المشاكل التي يعاني منها التطبيق. سنعد في هذا الدليل حزمة برامج ELK، ونعني بها Logstash، Elasticsearch وKibana؛ ثم نعد مختلف الخواديم المكونة لبيئة الإنتاج حتى ترسل السجلات المناسبة إلى خادوم السجلات. سنعد أيضا مُرشِحات Filters في Logstash من أجل تجزئة السجلات وهيكلتها وهو ما يسهِّل عملية البحث في السجلات وترشيحها ثم استخدام Kibana لمعاينتها. المتطلباتيجب، إن أردت الوصول إلى لوحة المراقبة عبر نطاق خاص مثل logging.example.com، إنشاء سجل من نوع A ضمن إعدادات النطاق يحيل إلى عنوان IP العمومي الخاص بخادوم السجلات. أو يمكنك بدلا من ذلك الوصول إلى لوحة التسجيلات باستخدام عنوان الخادوم العمومي. يُنصح بإعداد خادوم السجلات لاستخدام HTTPS وتقييد الوصول إليه بوضعه في شبكة خاصة افتراضية. تثبيت حزمة ELK على خادوم السجلاتاضبط حزمة ELK على خادوم السجلات باتباع خطوات درس كيف تثبت Logstash، Elasticsearch وKibana 4 على خادوم Ubuntu 14.04. تأكد من اتباع الخيار رقم 2 في فقرة توليد شهادات SSL. توقف عند الوصول إلى فقرة ضبط معيد توجيه Logstash. إعداد معيدي توجيه Logstash على العملاءاضبط معيد توجيه Logstash (مُرسِل للسجلات) على الخواديم العميلة (مثلا db1، app2، app1 وlb1) باتباع فقرة ضبط معيد توجيه Logstash في درس ELK. سيمكنك بعد إكمال الإعداد الدخولُ إلى Kibana عبر العنوان العمومي لخادوم السجلات وعرض سجلات النظام الخاصة بخواديمك. تحديد السجلات المراد جمعهاتتيح برامج ELK الكثير من السجلات لجمعها، حسب نوعية البرامج المثبتة على الخواديم وإعدادها. سنجمع، في مثالنا، السجلات التالية: سجل الاستعلامات Queries البطيئة في MySQL (الخادوم db1).سجلات الأخطاء والوصول في Apache (على الخادومين app1 وapp2).سجلات HAProxy (خادوم توزيع الحمل lb1).اخترنا هذه السجلات بالضبط لأن بإمكانها توفير معلومات مفيدة أثناء استكشاف الأخطاء وإصلاحها أو عند محاولة تحديد توجهات المستخدمين. يمكن أن يكون لدى خادومك سجلات أخرى مهمة، حسب إعداداتك. إعداد سجلات MySQLيحفظ MySQL الاستعلامات البطيئة في سجل على المسار var/log/mysql/mysql-slow/. يتضمن السجل الاستعلامات التي أخذت وقتا طويلا للتنفيذ؛ يمكن أن يساعد تحديد هذه الاستعلامات في تحسين التطبيق والبحث عن علله وإصلاحها. تفعيل تسجيل الاستعلامات البطيئة في MySQLتسجيل الاستعلامات البطيئة في MySQL غير مفعَّل في الإعدادات الافتراضية؛ لذا سنحتاج لتفعيله. افتح ملف إعدادات MySQL لتحريره: sudo nano /etc/mysql/my.cnfابحث عن التعليمة log_slow_queries وانزع علامة التعليق # الموجودة أمامها ليصبح السطر على النحو التالي: log_slow_queries = /var/log/mysql/mysql-slow.logاحفظ الملف ثم أغلقه. تجب إعادة تشغيل MySQL لاعتماد التغييرات: sudo service mysql restartسيبدأ MySQL الآن في تسجيل الاستعلامات التي تأخذ وقتا طويلا للتنفيذ. ملف السجل يوجد على المسار المحدّد في الإعداد. إرسال ملفات سجلات MySQLيجب إعداد معيد التوجيه في Logstash لإرسال سجلات الاستعلامات البطيئة إلى خادوم السجلات. حرر ملف إعداد معيد التوجيه على خادوم قاعدة البيانات db1: sudo nano /etc/logstash-forwarder.confأضف الأسطر التالية في آخر فقرة files لإرسال الاستعلامات البطيئة إلى خادوم السجلات وتحديد نوع السجل ب mysql-slow , { "paths": [ "/var/log/mysql/mysql-slow.log" ], "fields": { "type": "mysql-slow" } } احفظ الملف ثم أغلقه. تعد التعليمات السابقة معيد توجيه Logstash لإرسال سجلات الاستعلامات البطيئة إلى خادوم السجلات وتعليمها بmysql-slow. سنستخدم نوع السجل لاحقا في الترشيح. أعد تشغيل معيد التوجيه للبدء في إرسال السجلات: sudo service logstash-forwarder restartمرماز Codec المدخلات متعددة الأسطرسنحتاج لتفعيل مرماز تعدد الأسطر في Logstash لمعالجة سجلات الاستعلامات البطيئة في MySQL التي تأتي على أسطر متعددة. افتح ملف الإعدادات الذي يعرِّف مدخل Lumberjack على خادوم logging: sudo nano /etc/logstash/conf.d/01-lumberjack-input.confأضف الأسطر التالية إلى تعريف lumberjack: codec => multiline { pattern => "^# User@Host:" negate => true what => previous }احفظ الملف ثم أغلقه. تعد التعليمات أعلاه Logstash لاستخدام معالج السجلات متعددة الأسطر عند العثور على سجلات تحتوي على النمط Pattern المُحدَّد (أي تلك التي تبدأ ب # User@Host: ). في ما يلي سنضبط مرشح Logstash لسجلات MySQL. مرشح سجلات MySQLافتح ملفا جديدا على خادوم السجلات logging لإضافة مرشحات لسجل MySQL. سنسمي الملف 11-mysql.conf لكي يُقرأ بعد إعداد مدخلات Logstash (موجودة في ملف 01-lumberjack-input.conf): sudo nano /etc/logstash/conf.d/11-mysql.confأضف تعريف المرشح التالي: filter { # يسجل المستخدم واختياريا اسم المستضيف وعنوان IP if [type] == "mysql-slow" { grok { match => [ "message", "^# User@Host: %{USER:user}(?:\[[^\]]+\])?\s+@\s+%{HOST:host}?\s+\[%{IP:ip}?\]" ] } # يسجل مدة تنفيذ الاستعلام، مدة قفل السطر في قاعدة البيانات، الأسطر المُرجعة في النتيجة والأسطر المفحوصة. grok { match => [ "message", "^# Query_time: %{NUMBER:duration:float}\s+Lock_time: %{NUMBER:lock_wait:float} Rows_sent: %{NUMBER:results:int} \s*Rows_examined: %{NUMBER:scanned:int}"] } # يسجل وقت حدوث الاستعلام grok { match => [ "message", "^SET timestamp=%{NUMBER:timestamp};" ] } # يستخرج الوقت اعتمادا على وقت الاستعلام بدلا من وقت إدراج العنصر في السجلات date { match => [ "timestamp", "UNIX" ] } # يحذف حقل الختم الزمني من السجل نظرا لتسجيل وقت الحدث (الاستعلام) mutate { remove_field => "timestamp" } } } احفظ الملف ثم أغلقه. تعد التعليمات Logstash لترشيح السجلات من نوع mysql-slow باستخدام أنماط Grok المحددة في تعليمات match. راجع التعليقا فوق كل تعليمة لأخذ نبذة عن عملها. لكي تبدأ هذه المرشحات عملها يجب أن نعيد تشغيل Logstash: sudo service logstash restartيجب التأكد في هذه المرحلة من أن Logstash يعمل بطريقة صحيحة؛ إذ أن أخطاء الإعداد قد تتسبب في إخفاق إعادة تشغيله. يجب أن تتأكد أيضا أن Kibana قادر على رؤية سجلات MySQL المرشحة. سجلات Apacheتوجد سجلات Apache عادة على المسار var/log/apache2/ باسم access.log و error.log. يتيح لك جمع هذه السجلات معرفة عناوين IP التي تتصل بخواديمك، طلبات هذه العناوين ونوعية المتصفحات ونظم التشغيل المستخدمة في الاتصال؛ بالإضافة إلى الأخطاء التي يبلغ عنها Apache. إرسال سجلات Apacheنضبط معيد توجيه Logstash لإرسال سجلات الوصول والأخطاء في Apache إلى خادوم logging. نفذ الأمر التالي على كل واحد من خادومي التطبيق، app1 وapp2 لفتح ملف إعاد الخاص بمعيد توجيه Logstash: sudo nano /etc/logstash-forwarder.confأضف ما يلي ضمن فقؤة files تحت التعليمات الموجودة: , { "paths": [ "/var/log/apache2/access.log" ], "fields": { "type": "apache-access" } }, { "paths": [ "/var/log/apache2/error.log" ], "fields": { "type": "apache-error" } } احفظ الملف ثم أغلقه. تعد هذه التعليمات معيد توجيه Logstash لإرسال سجلات الوصول والأخطاء في Apache إلى خادوم السجلات، ثم تعليم كل سجل بنوعه (أي apache-access بالنسبة للوصول وapache-error بالنسبة للأخطاء). أعد تشغيل معيد التوجيه للبدء في إرسال السجلات: sudo service logstash-forwarder restartإذا تركنا الإعداد الحالي فستُظهر كل سجلات Apache عنوان IP الخاص لخادوم HAProxy بوصفه عنوان المصدر. يعود السبب في ذلك إلى أن الخادوم الوسيط lb1 هو الوسيلة الوحيدة للوصول إلى خواديم التطبيق من الإنترنت. يمكن تغيير هذا الأمر بإعداد الصيغة الافتراضية لسجل Apache بحيث يستخدم الرأسيات X-Forwarded-For التي يرسلها HAProxy. افتح ملف إعداد Apache على كل واحد من خادومي التطبيقات: sudo nano /etc/apache2/apache2.confابحث عن سطر يظهر على النحو التالي: [Label apache2.conf — Original "combined" LogFormat] LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined أبدل: h% ب%{X-Forwarded-For}i لكي تصبح هيئة السطر كالتالي: [Label apache2.conf — Updated "combined" LogFormat] LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined احفظ الملف ثم أغلقه. بهذا نكون أعددنا سجلات Apache لتضمين عنوان IP المصدر الفعلي بدلا من عنوان IP الخاص لخادوم توزيع الحمل. أعد تشغيل Apache لاعتماد التغييرات: sudo service apache2 restartنحن الآن جاهزون لإضافة مرشحات لسجلات Apache في Logstash. مرشحات سجلات MySQLننشئ ملف إعداد جديدا على خادوم السجلات logging من أجل إضافة مرشحات لسجل Apache إلى Logstash. سنسميه 12-apache.conf لكي يقرأه Logstash بعد ملف إعداد المُدخلات (أي ملف 01-lumberjack-input.conf): sudo nano /etc/logstash/conf.d/12-apache.confأضف تعريفات المرشحات التالية: filter { if [type] == "apache-access" { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } } } filter { if [type] == "apache-error" { grok { match => { "message" => "\[(?<timestamp>%{DAY:day} %{MONTH:month} %{MONTHDAY} %{TIME} %{YEAR})\] \[%{DATA:severity}\] \[pid %{NUMBER:pid}\] \[client %{IPORHOST:clientip}:%{POSINT:clientport}] %{GREEDYDATA:error_message}" } } } } احفظ الملف ثم أغلقه. تعد هذه التعليمات Logstash لاستخدام مرشحات Grok لتحليل سجلات الوصول والأخطاء في Apache. يعرف كل مرشح صيغة السجلات التي يتعامل معها ضمن تعليمة match الموجودة في المرشح الموافق لنوع السجل في الاسم. يُستخدم مرشح Grok يوفره Logstash لتحليل سجلات الوصول إلى Apache اعتمادا على الصيغة الافتراضية لهذه السجلات؛ بينما كتبنا مرشح Grok خاص لتحليل الصيغة الافتراضية لسجل الأخطاء في Apache. نعيد تشغيل Logstash لكي تبدأ المرشحات الجديدة عملها: sudo service logstash restartيجب التأكد في هذه المرحلة من أن Logstash يعمل بطريقة صحيحة؛ إذ أن أخطاء الإعداد قد تتسبب في إخفاق إعادة تشغيله. يجب أن تتأكد أيضا أن Kibana قادر على رؤية سجلات Apache المرشحة. سجلات HAProxyيسمح جمع سجلات موزع الحمل HAProxy (توجد عادة في الملف var/log/haproxy.log/) بمعرفة عناوين IP التي تتصل بخادوم توزيع الحمل، ماذا تطلب، خادوم التطبيق الذي يجيب على الطلب، ومعلومات مفصَّلة أخرى عن الاتصال. إرسال ملفات السجلات الخاصة بHAProxyنضبط معيد توجيه Logstash لإرسال سجلات HAProxy إلى خادوم السجلات بنفس طريقة الإعداد التي اتبعناها مع الخواديم السابقة. افتح الملف التالي على خادوم توزيع الحمل lb1: sudo nano /etc/logstash-forwarder.confأضف الأسطر التالية إلى فقرة files تحت التعليمات الموجودة سلف. ترسل التعليمات الجديدة سجلات HAProxy إلى خادوم Logstash وتحدد نوعها بـ haproxy-log. , { "paths": [ "/var/log/haproxy.log" ], "fields": { "type": "haproxy-log" } } احفظ الملف ثم أغلقه. تعد التعليمات أعلاه Logstash لإرسال سجلات HAProxy مع تحديد نوعها بhaproxy-log. يستخدَم النوع في ما بعد لترشيح السجلات. أعد تشغيل معيد توجيه في Logstash للبدء في إرسال السجلات: sudo service logstash-forwarder restartمرشح سجلات HAProxyافتح ملفا جديدا على خادوم logging لإضافة مرشح سجلات HAProxy إلى Logstash. سنسمي الملف الجديد 13-haproxy.conf: sudo nano /etc/logstash/conf.d/13-haproxy.confأضف تعريف المرشح التالي: filter { if [type] == "haproxy-log" { grok { match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} %{SYSLOGPROG}: %{IPORHOST:clientip}:%{POSINT:clientport} \[%{MONTHDAY}[./-]%{MONTH}[./-]%{YEAR}:%{TIME}\] %{NOTSPACE:frontend_name} %{NOTSPACE:backend_name}/%{NOTSPACE:server_name} %{INT:time_request}/%{INT:time_queue}/%{INT:time_backend_connect}/%{INT:time_backend_response}/%{NOTSPACE:time_duration} %{INT:http_status_code} %{NOTSPACE:bytes_read} %{DATA:captured_request_cookie} %{DATA:captured_response_cookie} %{NOTSPACE:termination_state} %{INT:actconn}/%{INT:feconn}/%{INT:beconn}/%{INT:srvconn}/%{NOTSPACE:retries} %{INT:srv_queue}/%{INT:backend_queue} "(%{WORD:http_verb} %{URIPATHPARAM:http_request} HTTP/%{NUMBER:http_version})|<BADREQ>|(%{WORD:http_verb} (%{URIPROTO:http_proto}://))"'} } } } احفظ الملف ثم أغلقه. تعد التعليمة Logstash لترشيح السجلات من نوع haproxy-log باستخدام نمط Grok المعيَّن، والذي يحلل السجلات لمطابقتها مع الصيغة الافتراضية لسجلات HAProxy. أعد تشغيل Logstash لاعتماد المرشح: sudo service logstash restartيجب التأكد بعد تنفيذ الأمر أن Logstash يعمل بطريقة صحيحة؛ إذ أن أخطاء الإعداد قد تتسبب في إخفاق إعادة تشغيله. إعداد المعاينة باستخدام Kibanaيمكن البدء باستخدام Kibana لمعاينة السجلات التي جمعناها من مختلف الخواديم. يسعادك المقال التالي في البدء باستخدام Kibana: كيف تستخدم لوحات القيادة والمعاينة في Kibana بعد التأقلم مع Kibana جرب درس كيف تظهر مواقع المستخدمين على خريطة باستخدام GeoIP وELK لمعاينة أكثر تقدما. خاتمةإن اتبّعت الخطوات المشروحة في هذا الدليل فستحصل على بيئة إنتاج مثل تلك التي وصفناها في الجزء الأول نظرة عامة على إنشاء تطبيقات موجهة لبيئة الإنتاج من الدليل. ترجمة - وبتصرف - لمقال Building for Production: Web Applications — Centralized Logging لصاحبه Mitchell Anicas.

أكملنا في الأجزاء السابقة من هذه السّلسلة إعداد خواديم التطبيقات، خطط الاسترداد، وآليات النسخ الاحتياطي. سنضبط في هذا الدرس إعداد المراقبة Monitoring لكي نكون على اطّلاع في أية لحظة بحالة عمل الخواديم والخدمات. تتيح برامج المراقبة مثل Nagios، Icinga وZabbix إمكانية إنشاء لوحات قيادة Dashboards وإشعارات تريك عناصر الإعداد التي تحتاج لاهتمام خاص. الهدف هو اكتشاف المشاكل والبدء في إصلاحها قبل أن تؤثر على المستخدمين النهائيين للتطبيق. سنعد في هذا الدرس المراقبة باستخدام Nagios 4 ونثبت عملاء NRPE (إضافة تتيح تنفيذ أوامر Nagios على أجهزة أخرى) على الخواديم التي تكون التطبيق. سنعد المراقبة على كل واحد من الخواديم لمعرفة هل الخادوم نشط وما إذا كانت العملية الرئيسة عليه (على سبيل المثال MySQL، Apache أو HAProxy) تعمل أم لا. لا يشمل هذا الدرس كل جوانب المراقبة، لذا قد تحتاج لإجراء فحوص إضافية لا يتناولها هذا الدّرس؛ إلا أنه يبقى نقطة جيدة للبدء. المتطلباتأنشئ، إن أردت الوصول إلى لوحة المراقبة عبر نطاق خاص مثل monitoring.example.com، سجلا من نوع A يحيل إلى عنوان IP العمومي الخاص بخادوم المراقبة. أو يمكنك بدلا من ذلك الوصول إلى لوحة القيادة في خادوم المراقبة باستخدام عنوانه العمومي. يُنصح بإعداد خادوم المراقبة لاستخدام HTTPS وتقييد الوصول إليه بوضعه في شبكة خاصة افتراضية. تثبيت Nagios على خادوم المراقبةاضبط Nagios على خادوم المراقبة باتباع الدرس التالي: كيف تستخدم Nagios 4 لمراقبة خواديم Ubuntu 14.04. إن رغبت في استخدام Icinga الذي هو اشتقاق من Nagios فدرس كيف تستخدم Icinga لمراقبة خواديمك وخدماتك على Ubuntu 14.04 يشرح الطريقة. توقف عند فقرة مراقبة مستضيف Ubuntu بواسطة عملاء NRPE. إضافة الخواديم إلى Nagiosطبق خطوات فقرة مراقبة مستضيف Ubuntu بواسطة عملاء NRPE من درس Nagios السابق على كل واحد من الخواديم (app2،app1، db1 وlb1). تأكد من إضافة عنوان IP الخادوم أو اسم مستضيفه الخاص إلى allowed_hosts في ملف إعداد NRPE. يجب أن يكون لديك بعد الانتهاء من إضافة المستضيفات ملف منفصل لكل خادوم: app2.cfg،app1.cfg،db1.cfg، وlb1.cfg. يتضمن كل ملف تعريف المستضيف الذي يحيل إلى اسمه وعنوانه (قد يكون العنوان اسم المستضيف أو عنوان IP الخاص بالخادوم). إعداد المستضيف ومراقبة الخدمةنبدأ بإعداد لائحة لما نريد مراقبته على كل خادوم. نراقب، على كل خادوم، الخدمات التالية: Ping.SSH.الحمل الجاري Current Load.المستخدمون الحاليون Current users.المساحة المستخدمة من القرص الصلب Disk Utilization.تعريف الخدمات المشتركةأعددنا Nagios في الدرس المُشار إليه سابقا ليرقُب الملفات الموجودة في المجلد usr/local/nagios/etc/servers/. سننشئ ملف إعداد Nagios للخدمات المشتركة التي نريد مراقبته؛ نسمي الملف common.cfg. افتح أولا ملف الإعداد لتحريره: sudo nano /usr/local/nagios/etc/servers/common.cfgأضف تعريفات الخدمات التالية، مع تحديد قيمة host_name (أسماء المستضيفات الخاصة بالخواديم، عُرِّفت سابقا ضمن ملفات app2.cfg،app1.cfg،db1.cfg، وlb1.cfg): define service { use generic-service host_name db1,app1,app2,lb1 service_description PING check_command check_ping!100.0,20%!500.0,60% } define service { use generic-service host_name db1,app1,app2,lb1 service_description SSH check_command check_ssh notifications_enabled 0 } define service { use generic-service host_name db1,app1,app2,lb1 service_description Current Load check_command check_nrpe!check_load } define service { use generic-service host_name db1,app1,app2,lb1 service_description Current Users check_command check_nrpe!check_users } define service{ use generic-service host_name db1,app1,app2,lb1 service_description Disk Utilization check_command check_nrpe!check_hda1 } احفظ الملف ثم أغلقه. بالإمكان الآن الانتقال لتعريف الخدمات الخاصة بكل خادوم. نبدأ بخادوم قاعدة البيانات. تعريف عملية MySQLإنشاء أمر NRPE (على العميل)سنضبط أمر NRPE جديدا على خادوم قاعدة البيانات، db1. افتح ملف إعداد NRPE جديدا، commands.cfg: sudo nano /etc/nagios/nrpe.d/commands.cfgأضف تعريف الأمر التالي: command[check_mysqld]=/usr/lib/nagios/plugins/check_procs -c 1: -C mysqldاحفظ الملف ثم أغلقه. يتيح الأمر لـNRPE فحص عملية Process باسم mysqld والإبلاغ عن حالة حرجة Critical status إن كان هناك أقل من عملية واحدة نشطة بهذا الاسم. أعد تحميل إعداد NRPE: sudo service nagios-nrpe-server reloadإنشاء تعريف الخدمة (على الخادوم)نحتاج لتعريف خدمة جديدة على خادوم monitoring (خادوم المراقبة) لاستخدام NRPE لتشغيل أمر check_mysqld السابق. افتح الملف الذي يعرف مستضيف قاعدة البيانات، db1.cfg في مثالنا: sudo nano /usr/local/nagios/etc/servers/db1.cfgأضف تعريف الخدمة التالي في آخر الملف (تأكد من أن قيمة host_name تطابق اسم تعريف المستضيف): define service { use generic-service host_name db1 service_description Check MySQL Process check_command check_nrpe!check_mysqld }احفظ الملف ثم أغلقه. يُعد تعريف الخدمة أعلاه Nagios لاستخدام NRPE لتنفيذ أمر check_mysqld على خادوم قاعدة البيانات. تجب إعادة تحميل Nagios لاعتماد التغييرات. إلا أننا سننتقل أولا لمراقبة عملية Apache أولا. تعريف عملية Apacheإنشاء أمر NRPE (على العميل)نضبط أمر NRPE جديدا على كلٍّ من خادومي التطبيق: sudo nano /etc/nagios/nrpe.d/commands.cfgثم نضيف تعريف الأمر التالي: command[check_apache2]=/usr/lib/nagios/plugins/check_procs -c 1: -w 3: -C apache2احفظ الملف ثم أغلقه. يسمح الأمر لNRPE بالتحقق من وجود عملية باسم apache2 والإبلاغ عن حالة حرجة إن لم توجد عملية بهذا الاسم وإصدار تحذير إن وجدت أقل من ثلاث عمليات. نعيد تحميل إعداد NRPE: sudo service nagios-nrpe-server reloadتأكد من تنفيذ الخطوات على جميع خواديم التطبيقات. إنشاء تعريف الخدمة (على الخادوم)نحتاج تعريف خدمة جديدة تستخدم أمر check_apache2 على خادوم المراقبة monitoring. افتح الملف الذي يعرف مستضيف التطبيق (يوجد في حالتنا اثنان: app1 وapp2): sudo nano /usr/local/nagios/etc/servers/app1.cfgأضف تعريف الخدمة التالي في آخر الملف (تأكد من أن قيمة host_name تطابق اسم تعريف المستضيف): define service { use generic-service host_name app1 service_description Check Apache2 Process check_command check_nrpe!check_apache2 }احفظ الملف ثم أغلقه. يعد تعريف الخدمة Nagios لاستخدام NRPE لتنفيذ أمر check_apache2 على خادوم التطبيق. تأكد من تكرار الخطوة على كل واحد من خواديم التطبيقات. تعريف عملية HAProxyإنشاء أمر NRPE (على العميل)نعد أمر NRPE على خادوم توزيع الحمل lb1 بنفس طريقة إعداده في الخواديم السابقة: sudo nano /etc/nagios/nrpe.d/commands.cfgونضيف تعريف الأمر التالي: command[check_haproxy]=/usr/lib/nagios/plugins/check_procs -c 1: -C haproxyاحفظ الملف ثم أغلقه. يعد تعريف الخدمة السابق NRPE للتحقق من عملية باسم haproxy ثم الإبلاغ عن حالة حرجة إن كان عدد العمليات بهذا الاسم أصغر من 1. نعيد تحميل إعداداتت NRPE: sudo service nagios-nrpe-server reloadإنشاء تعريف الخدمة (على الخادوم)نضيف تعريف خدمة جديدا على خادوم monitoring ليستخدم أمر check_haproxy؛ بنفس الطريقة المشروحة سابقا. sudo nano /usr/local/nagios/etc/servers/lb1.cfgنضيف التعريف التالي في نهاية الملف: define service { use generic-service host_name lb1 service_description Check HAProxy Process check_command check_nrpe!check_haproxy }يعد التعريف Nagios لاستخدام NRPE في تنفيذ الأمر check_haproxy على خادوم توزيع الحمل. تجب إعادة تحميل Nagios من أجل اعتماد التعديلات. إعادة تحميل Nagiosنعيد تحميل Nagios عبر تنفيذ الأمر التالي من أجل اعتماد التعديلات السابقة: sudo service nagios reloadإن لم توجد أخطاء في صياغة الأوامر والتعريفات فيُعاد تحميل Nagios دون مشاكل. التحقق من خدمات Nagiosيجب أن نتأكد من أن Nagios يراقب جميع الخواديم والخدمات التي عرفناها. ادخل إلى خادوم Nagios باستخدام اسم المستضيف العمومي أو عنوان IP (مثلا http://monitoring.example.com/nagios؛ أدخِل بيانات الدخول التي أعددتها أثناء تثبيت Nagios. انقر رابط الخدمات Services في القائمة الجانبية؛ يجب أن تظهر لديك صفحة تشبه ما يلي: الوضعية المثالية هي أن تكون كل المستضيفات والخدمات على حالة OK. يمكن أن نرى في لقطة الشاشة السابقة وجود مشكلة في خادوم التطبيق app2؛ ويرجع ذلك إلى أنه كان مطفأ في أغلب فحوص الحالة الأخيرة. إن وجدت خدمات بحالة مغايرة لOK فأصلحها؛ وإن كانت جميع الخدمات بحالة جيدة فراجع إعدادات Nagios بحثا عن أخطاء ربما تكون أدت لإبلاغ غير صحيح عن حالة الخدمات. اعتبارات أخرىقد ترغب في إنشاء خطة استرداد لخادوم المراقبة، ملفات الإعداد الواجب نسخها إن أردت ذلك توجد في المجلد usr/local/nagios/etc/. يمكن أيضا أن تعدّ Nagios لمراقبة خدمات أخرى مثل البريد الإلكتروني. خاتمةيمكّن خادوم المراقبة من الحصول على حالة الخدمات والخواديم بمجرد إلقاء نظرة على لوحة المراقبة. يساعد خادوم المراقبة، عند حدوث مشاكل، في تحديد الخادوم والخدمة التي لا تعمل بطريقة صحيحة وهو ما يعينك في تخفيض زمن توقف Downtime الخاص التطبيق. في الجزء الموالي من الدليل سنعرض لكيفية إعداد سجلات مركزية لتطبيقات الويب في بيئة الإنتاج. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Monitoring لصاحبه Mitchell Anicas.

أكملنا في الجزء السابق من هذه السّلسلة إعداد التطبيق المثال؛ يجب علينا الآن تصميم خطة استرداد Recovery plan. خطة الاسترداد (أو الاستعادة) عبارة عن مجموعة موثقة من العمليات التي يجب تنفيذها لتصحيح إعدادات بيئة العمل بعد حدوث مشاكل مزمنة أو عند حصول أخطاء إدارية. يساعد إنشاء خطة استرداد أيضا على تحديد العناصر والبيانات الأساسية ضمن إعدادات خادوم التطبيق. يمكن أن تتمثل خطة استرداد قاعدية من إخفاق بيئة العمل في لائحة بالخطوات الواجب اتباعها لإنجاز النشر الابتدائي للخادوم؛ إلى جانب عمليات إضافية لاستعادة بيانات التطبيق من النسخ الاحتياطية. للحصول على خطة استرداد أفضل يجب، إضافة للتوثيق الجيد، استغلال سكربتات النشر وأدوات إدارة الإعدادات مثل Chef، Ansible وPuppet؛ للمساعدة في أتممة وتسريع الاسترداد. سنوضح في هذا الجزء من السّلسلة كيفية إنشاء خطة استرداد قاعدية لتطبيق ووردبريس الذي أعددناه. سيساعدك الشرح في البدء بتصميم خطة استرداد خاصة بك حتى ولو كانت احتياجاتك مختلفة. متطلبات خطة الاستردادمطلبنا الأساسي هو إمكانية استرداد بيئة العمل بعد فقدان واحد من الخواديم المكوّنة لها، واستعادة وظيفة التطبيق وبياناته؛ إلى حد زمني مقبول. سننشئ جردًا لإعدادات كل خادوم نحدد من خلاله البيانات التي نحتاج لنسخ احتياطية منها؛ ثم نكتب خطة استرداد اعتمادا على ما يوجد في الخادوم. يجب أن نتحقق بعد تنفيذ أي واحدة من خطط الاسترداد أن التطبيق استُرِدّ بطريقة صحيحة. سنخرج بخطة استرداد لكل نوع من الخواديم التي يتكون منها التطبيق: خادوم قاعدة البيانات.خواديم التطبيق.خادوم توزيع الحمل.نبدأ بخادوم قاعدة البيانات. خادوم قاعدة البياناتبإعادة تتبع خطواتنا (وإعادة النظر في الدرس السابق) نجد أن خادوم قاعدة البيانات أنشئ وفقا للخطوات التالية: تثبيت MySQL.إعداد MySQL.إعادة تشغيل MySQL.إنشاء قاعدة البيانات والمستخدمين.خطة استرداد خادوم قاعدة البياناتنعرف، بالنظر لطريقة إنشاء خادوم قاعدة البيانات، أنه تمكن إعادة إنشائه من الصفر ما عدا محتوى قاعدة البيانات. تُخزَّن أغلب بيانات تطبيق ووردبريس (التدوينات مثلا) في قاعدة البيانات. يعني هذا أنه يجب علينا الاحتفاظ بنسخة احتياطية من قاعدة البيانات إن أردنا توفير القدرة على استرداد خادوم قاعدة البيانات. سنحتفظ أيضا بنسخ احتياطية من ملف إعدادات MySQL الذي غيرنا فيه قليلا. في ما يلي ملخَّص لخطة الاسترداد الخاصة بخادوم قاعدة البيانات: يجب الآن التدرب على تنفيذ خطة الاستعادة هذه، والتأكد من الاحتفاظ بالنسخ الاحتياطية الضرورية. خواديم التطبيقنعرف بالنظر في طريقة إنشاء خواديم التطبيق (ومراجعة الدرس السابق)؛ أنّ الخطوات المتَّبعة كانت على النحو التالي: تثبيت كل من PHP وApache وإعدادهما.تنزيل التطبيق (ووردبريس) وإعداده.نسخ ملفات التطبيق إلى جذر المستند Document root.تكرار ملفات التطبيق على جميع خواديم التطبيق.خطة الاسترداد لخادوم التطبيقتمكن إعادة إنشاء خادوم التطبيق من الصفر، ما عدا ملفات التطبيق. تتضمن ملفات التطبيق في المثال ملفات إعداد ووردبريس (التي تحتوي على معلومات الاتصال بقاعدة البيانات)، إضافات ووردبريس المثّبَّتة، والملفات المحمَّلة. أي أنه يجب علينا الاحتفاظ بنسخة احتياطية من ملفات التطبيق إن أردنا إمكانية استرداد خادوم التطبيق. أعددنا الخواديم بحيث تُكرَّر الملفات على خواديم التطبيق؛ يعني هذا أننا لا نحتاج لاستعادة البيانات من النسخ الاحتياطية إلا إذا أخفقت خواديم التطبيق جميعها أو تلَفتْ البيانات بطريقة أو بأخرى. إن بقي خادوم تطبيق واحد على الأقل يعمل جيدا، مع ملفات التطبيق الصحيحة؛ فإن إعادة ضبط تكرار الملفات مرة أخرى سيعيد الملفات الصحيحة إلى خادوم التطبيق الجديد. في ما يلي ملخَّص لخطة الاسترداد الخاصة بخواديم التطبيقات، اعتمادا على الجرد أعلاه: اكتمل إعداد خطة الاسترداد لخواديم التطبيق. يجب الآن التدرب على تنفيذ خطة الاسترداد، والتأكد من الاحتفاظ بالنسخ الاحتياطية الضرورية. خادوم توزيع الحملالمبدأ هو نفسه، ننظر إلى خطوات إنشاء موزع الحمل في الدرس السابق؛ فنخرج بالتالي: الحصول على شهادة SSL والملفات المتعلقة بها.تثبيت HAProxy.إعداد HAProxy.إعادة تشغيل HAProxy.خطة الاسترداد لخادوم توزيع الحملنعرف من الخطوات أعلاه، أنه تمكن إعادة إنشاء موزع الحمل انطلاقا من صفر، ما عدا الملفات المتعلقة بشهادة SSL. يعني هذا أنه يتوجب علينا الاحتفاظ بنسخ احتياطية من الملفات المتعلقة بشهادة SSL إن أردنا توفير القابلية لاسترداد خادوم توزيع الحمل. سنضيف أيضا ملف إعداد HAProxy ضمن النسخ الاحتياطية. نضع - مثل ما فعلنا مع العناصر السابقة، ملخصا لخطة الاسترداد الخاصة بخادوم توزيع الحمل: اكتمل إعداد خطة الاسترداد لخادوم توزيع الحمل. يجب الآن التدرب على تنفيذ خطة الاسترداد، والتأكد من الاحتفاظ بالنسخ الاحتياطية الضرورية. اعتبارات أخرىإن تطلب استرداد أحد العناصر إعادة ضبط عنصر آخر (تغير عنوان IP الخاص بخادوم قاعدة البيانات مثلا)؛ فعليك التأكد من إدراج الخطوات الضرورية في خطط الاسترداد. ستحتاج أيضا لكتابة خطط استرداد للعناصر الأخرى المكوِّنة للتطبيق مثل خادوم النطاقات؛ وكذلك جميع العناصر التي يمكن أن تضيفها في المستقبل مثل خواديم النسخ الاحتياطي، المراقبة والسجلات. يجب، مع تطور إعداداتك، إعادة النظر في خطط الاستعادة الموجودة وإجراء التغييرات اللّازمة. لم نتطرق لحد الساعة إلى كيفية إنشاء ثم استعادة النسخ الاحتياطية؛ لذا سنحتاج للنظر في هذه التفاصيل لاحقا. سيكون النسخ الاحتياطي موضوع الجزء الموالي من هذا الدليل. خاتمةيجب الاحتفاظ بخطط الاستعادة الخاصة بالخواديم المختلفة في مكان آمن يمكن لمن أراد تنفيذ الخطوات الموجودة فيها الوصولُ إليه. احتفظ بها في مكان منفصل تماما عن بيئة العمل. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Recovery Planning لصاحبه Mitchell Anicas. حقوق الصورة البارزة: Designed by Freepik.

هذا الدّرس هو الجزء الثّاني من سلسلة من 6 دروس حول "نظرة عامة على إنشاء تطبيقات موجهة لبيئة الإنتاج". إذا لم تقرأ الدّرس الأول فألق نظرة عليه قبل أن تواصل القراءة. سنعدّ في هذا الجزء من السّلسلة تطبيق PHP الذي اخترناه مثالا (ووردبريس) إضافة إلى خادوم أسماء نطاقات DNS خاص. سيستعمل مستخدمو التطبيق اسمَ النطاق للوصول إليه؛ عبر العنوان https://www.example.com على سبيل المثال. يحيل العنوان إلى موزع الحِمل الذي سيعمل وسيطا عكسيا Reverse proxy لخواديم التطبيق التي تتصل بدورها بخادوم قاعدة البيانات. يمكِّننا استخدامُ نظام أسماء نطاقات خاصة Private DNS من الإشارة إلى عناوين الخواديم ضمن الشبكة الداخلية بأسماء المستضيفات الخاصة بها مما يسهل من عملية إعداد الخواديم. سنعد العناصر للتوّ التي أشرنا إليها على ستة خواديم، طبقا للترتيب التالي: نظام أسماء نطاقات خاصة (المستضيفان ns1 وns2).خادوم قاعدة البيانات (db1).خواديم التطبيق (app1 وapp2).موزع حمل (lb1). فلنبدأ بإعداد النطاقات. خواديم النطاقات الداخليةيساعد استخدام أسماء نطاقات بدلا من عناوين IP في التعرف على الخواديم التي نعمل عليها، كما أنه ضروري حال إدارة الكثير من الخواديم؛ إذ يمكّن من إحلال خادوم مكان آخر بمجرد تحديث سجلات النطاق (ضمن ملف وحيد) بدلا من من تحديث عناوين IP ضمن الكثير من ملفات الإعداد. سنعدّ نظام نطاقات للإحالة إلى عناوين الشبكة الداخلية التي توجد بها الخواديم بدلا من عناوين IP. سنشير إلى كل عنوان في الشبكة الداخلية بمستضيف ضمن النطاق الفرعي nyc3.example.com. سيكون عنوان خادوم قاعدة البيانات ضمن الشبكة الداخلية - على سبيل المثال - db1.nyc3.example.com؛ وهو ما ستترجمه خواديم النطاقات إلى عنوان IP داخلي (خاص). تنبغي الإشارة إلى أن اختيار اسم النطاق الفرعي nyc3.example.com اعتباطي. في العادة يُستخدم اسم الموقع الجغرافي للنطاق الفرعي؛ في مثالنا، تشير nyc3 إلى أن الخواديم تتواجد في مركز البيانات NYC3، وexample.com إلى اسم النطاق الخاص بالتطبيق. ستحصل على خادومي BIND هما ns1 وns2. أضف عناوين IP الخاصة بجميع الخواديم التي تخطط لإعدادها إن كنت تعرفها سلفًا، وإلا أضف سجلات النطاق بالتزامن مع إنشاء الخواديم. ننتقل لإعداد خادوم قاعدة البيانات. إعداد خادوم قاعدة البياناتنريد - طبقا للخطة - توزيع الحمل بين خواديم التطبيقات؛ أي تلك التي تشغِّل PHP وApache، لذا سنفْصِل قاعدة البيانات عن خواديم التطبيق لجعلها على خادوم خاص بها. من المهم جدا فصل قاعدة البيانات عن التطبيق في حال أردنا إمكانية التوسع أفقيا Horizontally Scaling (إضافة خواديم جديدة لتعمل مع تلك الموجودة) في تطبيقات PHP. تغطي هذه الفقرة كل الخطوات الضرورية لإعداد خادوم قاعدة البيانات، لكن يمكنك معرفة المزيد عن إعداد قاعدة بيانات MySQL بعيدة بقراءة مقال كيفية إعداد قاعدة بيانات بعيدة لتحسين أداء موقع يستخدِم MySQL. تثبيت MySQLنفذ الأمرين التاليين على خادوم قاعدة البيانات (db1) لتثبيت خادوم MySQL: sudo apt-get update sudo apt-get -y install mysql-serverأدخل كلمة السر التي تريد استخدامها للحساب الإداري في MySQL عندما يُطلب منك ذلك. نفذ: sudo mysql_install_db sudo mysql_secure_installationستحتاج لإدخال كلمة سر المستخدِم الإداري التي اخترتها عند تثبيت خادوم MySQL؛ بعدها سيسألك إن كنت تريد تغيير كلمة السر هذه، اضغط زر N إذا كنت لا تريد تغييرها. بالنسبة لبقية الأسئلة اضغط زر Enter لتأكيد الاختيارات الافتراضية. إعداد MySQL لاستخدام واجهة الشبكة الداخليةافتح ملف إعداد MySQL عبر الأمر التالي: sudo nano /etc/mysql/my.cnfابحث عن bind-address وحدد قيمة المتغير بعنوان IP قاعدة البيانات ضمن الشبكة الداخلية: bind-address = db1.nyc3.example.comاحفظ الملف ثم أغلقه. أعد تشغيل MySQL: sudo service mysql restartضبط قاعدة البيانات ومستخدميهانحتاج الآن لإنشاء قاعدة بيانات والمستخدمين الذين ستتصل خواديم التطبيقات عن طريقهم إلى قاعدة البيانات. استخدم الأمر التالي للدخول إلى سطر أوامر MySQL: mysql -u root -pأدخل كلمة السر عندما تُطلب. أنشئ قاعدة بيانات بتنفيذ الأمر التالي في سطر أوامر MySQL: CREATE DATABASE app;يرفق خادوم MySQL كل مستخدم بالخواديم التي يمكنه منها الاتصال بقاعدة بيانات. يوجد في مثالنا خادوما تطبيق يتصلان بقاعدة البيانات؛ لذا سننشئ مستخدما لكل واحد منهما. أنشئ مستخدما في قاعدة البيانات باسم appuser يمكنه الاتصال من العناوين الداخلية لخواديم التطبيقات (أي app1 وapp2). يجب استخدام نفس كلمة السر للمستخدمَيْن (اختر كلمة سر واكتبها مكان password في الأمرين أدناه): CREATE USER 'appuser'@'app1.nyc3.example.com' IDENTIFIED BY 'password'; CREATE USER 'appuser'@'app2.nyc3.example.com' IDENTIFIED BY 'password';سنضبط في ما بعد امتيازات المستخدم appuser، نكتفي الآن بإعطائه تحكما كاملا على قاعدة البيانات app: GRANT ALL PRIVILEGES ON app.* TO 'appuser'@'app1.nyc3.example.com'; GRANT ALL PRIVILEGES ON app.* TO 'appuser'@'app2.nyc3.example.com'; FLUSH PRIVILEGES;تضمن الامتيازات الممتدة أن سكربت تثبيت التطبيق سيتمكن من تثبيته على قاعدة البيانات. إن كان لديك أكثر من خادومي تطبيقات، فيجب أن تنشئ حسابات المستخدمين الآن بنفس الكيفية. للخروج من سطر أوامر MySQL: exitاكتمل الآن إعداد خادوم قاعدة البيانات. ننتقل لإعداد خواديم التطبيقات. إعداد خواديم التطبيقاتتتصل خواديم التطبيق بخادوم قاعدة البيانات. اخترنا ووردبريس للتمثيل في هذا الدليل، وهو تطبيق PHP يعمل على خادوم ويب مثل Apache أو Nginx. سنضبط خادومين متطابقين لتوزيع الحِمل بينهما. تغطّي هذه الفقرة الخطوات الضرورية لإعداد خواديم التطبيق، لكن الموضوع مشروح بتفاصيل أكثر في مقال كيفية إعداد قاعدة بيانات بعيدة لتحسين أداء موقع يستخدِم MySQL انطلاقا من فقرة إعداد خادوم الويب. تثبيت Apache وPHPنفذ الأوامر التالية على كل واحد من الخادومين app1وapp2 لتثبيت Apache وPHP: sudo apt-get update sudo apt-get -y install apache2 php5-mysql php5 libapache2-mod-php5 php5-mcryptإعداد Apacheسنستخدم HAProxy على خادوم موزع الحمل للتعامل مع الاتصال عبر SSL، مما يعني أننا لا نريد أن يتصل المستخدمون بخادوميْ التطبيقات مباشرة. سنربط Apache بعنوان الشبكة الداخلية الخاص بكل واحد من الخادومين. نفّذ الأمر التالي على كل من الخادومين، app1 وapp2: sudo nano /etc/apache2/ports.confابحث عن السطر الذي توجد فيه العبارة Listen 80 وأضف عنوان خادوم التطبيق الخاص إليها، على النحو التالي (أبدل private_IP بعنوان IP الخاص بك): Listen private_IP:80احفظ الملف ثم أغلقه. يجعل هذا الإعداد خادوم Apache يُنصت لعناوين الشبكة الداخلية فقط؛ ممايعني أنه لا يمكن الوصول إليه عبر عنوان IP العمومي أو اسم المستضيف. أعد تشغيل Apache لأخذ التغيير في الحسبان: sudo service apache2 restartلا يمكن - وفق الإعداد الحالي - الوصول مباشرة إلى خادوم Apache؛ إذ تقتصر الاتصالات التي يقبلها على تلك القادمة من الشبكة الداخلية. سنعدّ - بعد قليل - موزع الحمل لإرسال الطلبات إلى الخواديم. تنزيل التطبيق وإعدادهاخترنا في هذه السّلسلة ووردبريس مثالا للتطبيق. إن كنت تستخدم تطبيق PHP مغايرا فيجب عليك تنزيله وعمل الإعدادات اللازمة (معلومات الاتصال بقاعدة البيانات على سبيل المثال)؛ ثم انتقل إلى الفقرة الموالية. نزل أرشيف ووردبريس على خادوم التطبيق الأول، app1: cd ~ wget http://wordpress.org/latest.tar.gzفك ضغط الأرشيف واستخرج ملفات ووردبريس: tar xvf latest.tar.gzانتقل إلى مجلّد ووردبريس المُستخرَج: cd wordpressيحتاج ووردبريس إلى مجلّد لوضع الملفات التي يحملها فيه؛ فلننشئ هذا المجلّد (wp-content/uploads): ode>mkdir wp-content/uploadsسنستخدم ملف إعداد ووردبريس النموذجي قالبا للإعداد: cp wp-config-sample.php wp-config.phpافتح الملف الإعداد من أجل تحريره: nano wp-config.phpاضبط اتصال ووردبريس بقاعدة البيانات بتحرير المعلومات الميَّزة في الأسطر التالية: /** The name of the database for WordPress */ define('DB_NAME', 'app'); /** MySQL database username */ define('DB_USER', 'appuser'); /** MySQL database password */ define('DB_PASSWORD', 'password'); /** MySQL hostname */ define('DB_HOST', 'db1.nyc3.example..com');نضيف الأسطر التالية إلى ملف إعداد ووردبريس لإخباره بأنه خلف وسيط عكسي يستخدم SSL (موزع الحمل يستخدم TLS/SSL للتعميّة): define('FORCE_SSL_ADMIN', true); if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on';احفظ الملف ثم أغلقه. تبقّى الآن نقلُ ملفات ووردبريس إلى مجلد يمكن لخادوم الويب الوصول إليه من أجل خدمة الزوار. نقل ملفات التطبيق إلى جذر المستند Document Rootنحتاج الآن، بعد إعداد التطبيق، لنقل ملفات ووردبريس إلى جذر المستند في Apache حيث يمكن لخادوم الويب الوصول إليها وتقديمها لزوار الموقع. جذر المستند الافتراضي في Apache هو المسار var/www/html/ وهو ما سنستخدمه في مثالنا. احذف أولا ملف index.html الافتراضي: sudo rm /var/www/html/index.htmlاستخدم أداة rsync لنسخ ملفات ووردبريس إلى المجلد var/www/html/ اجعل www-data (الحساب الذي يشتغل به خادوم ويب Apache) مالكَ هذا المجلّد: sudo rsync -avP ~/wordpress/ /var/www/html sudo chgrp -R www-data /var/www/html/*أصبح خادوم التطبيق الأول app1 جاهزا؛ سنعد الآن خادوم التطبيق الآخر. تكرار ملفات التطبيق على الخواديم الأخرىيتوجب إعداد آلية لتكرار الملفات الموجودة في جذر المستند لخادوم الويب على مختلف الخواديم المكوِّنة للتطبيق؛ من أجل إبقاء ملفات التطبيق متجانسة عبر الخواديم. في حالة ووردبريس فإن استخدام واجهة الويب لتحميل الملفات وتثبيت الإضافات سيجعلها موجودة فقط على الخادوم الذي عالج الطلب. إن لم تكرَّر الملفات على جميع الخواديم فسيرى بعض زوار الموقع صفحات بصور ناقصة وإضافات مكسورة. إن كنت تستخدم تطبيقا آخر غير ووردبريس لا يحفظ بياناته (الملفات المحمَّلة والإضافات المنزّلة مثلا) على خادوم التطبيق فيمكنك الاكتفاء بنقل الملفات إلى الخادوم يدويا مرة واحدة. في هذه الحالة استخدم أداة rsync لنقل ملفات التطبيق من الخادوم app1 إلى الخادوم app2. يمكن استخدام GlusterFS لإنشاء تجزئة قرص مكرَّرة من الملفات الضرورية. الطريقة مشروحة في فقرة مزامنة الملفات في تطبيقات الويب ضمن مقال كيف تستخدم HAProxy لتوزيع الحمل بين خواديم تطبيق ووردبريس. اتبع الخطوات (تجاوز فقرة إعداد ملفات المستضيف لأن خادوم النطاقات لدينا يتولى المهمة) ثم اضبُط تكرار الملفات بين app1 وapp2. بعد الانتهاء من إعداد تكرار الملفات بين الخواديم نكون على استعداد لتجهيز موزِّع الحمل. إعداد موزع الحملاخترنا HAProxy موزعا للحمل؛ وسيعمل وسيطا عكسيا لخواديم التطبيق. سيصل المستخدمون إلى التطبيق عبر عنوان شبيه بhttps://www.example.com بعد المرور بموزع الحمل. تشرح هذه الفقرة الخطوات الضرورية لإعداد خادوم موزِّع للحمل/ نسخ شهادة SSLنفذ الخطوات التالية على خادوم موزع الحمل، lb1. ضع شهادة SSL (أحد متطلبات الجزء الأول من السّلسلة) ومفتاح الشهادة، إضافة لأي شهادات من سلطة وسيطة ضمن ملف pem. واحد (نفترض أن شهادات SSL موجودة في المجلّد root/certs/): cd /root/certs cat www.example.com.crt CAintermediate.ca-bundle www.example.com.key > www.example.com.pemثم انسخ ملف pem إلى المجلّد etc/ssl/private/: sudo cp www.example.com.pem /etc/ssl/private/سيستخدم HAProxy هذا الملف لإنهاء SSL. تثبيت HAProxyنفذ الأوامر التالية على خادوم موزع الحمل، lb1: sudo add-apt-repository ppa:vbernat/haproxy-1.5 sudo apt-get update sudo apt-get -y install haproxyإعداد HAProxyنحتاج لضبط إعداداتٍ عامة في HAProxy إضافة لإنهاء SSL والنهايات الخلفية Backend والأمامية Frontend المناسبة لجعله يعمل مع خواديم التطبيق. افتح ملف إعداد HAProxy لتحريره: sudo nano /etc/haproxy/haproxy.cfgخيارات عامة في إعداد HAProxyأول ما يجب فعله هو تحديد قيمة معقولة للحد الأعلى لعدد الاتصالات maxconn. يحدد هذا المتغير عدد الاتصالات الأكبر التي يسمح بها HAProxy في نفس الوقت؛ وهو ما قد يؤثر على جودة الخدمة ويحول دون انهيار خادوم الويب عند محاولته الإجابة على الكثير من الطلبات. يجب أن تبحث وتجرب قيما عدة لإيجاد تلك المناسبة لبيئة عملك. أضف السطر التالي إلى ملف إعداد HAProxy (اخترنا القيمة 2048): maxconn 2048أضف السطر التالي لضبط الحجم الأكبر للذاكرة المؤقتة لتخزين مفاتيح التعمية: tune.ssl.default-dh-param 2048أضف السطرين التاليين ضمن مقطع defaults مباشرة بعد السطر الذي توجد به mode http: option forwardfor option http-server-closeتفعل الأسطر التالية إذا أضيفت ضمن مقطع defaults صفحة إحصاءات HAProxy (أبدل user وpassword بقيم آمنة): stats enable stats uri /stats stats realm Haproxy\ Statistics stats auth user:passwordيمكن بعد التفعيل عرض إحصاءات HAProxy بالذهاب إلى الصفحة التالية https://www.example.com/stats. لم ننته بعد من ملف إعدادات HAProxy، سنضبط في ما يلي إعدادات الوسيط. إعداد الوسيط في HAProxyنبدأ بإضافة نهاية أمامية للتعامل مع اتصالات HTTP الواردة. نضيف في نهاية ملف الإعداد نهاية أمامية باسم www-http عبر الأسطر التالية: frontend www-http bind www.example.com:80 reqadd X-Forwarded-Proto:\ http default_backend app-backendالهدف من هذا الإعداد هو قبول اتصالات HTTP من أجل توجيهها عبر اتصال HTTPS. ثم نضيف نهاية أمامية للتعامل مع اتصالات HTTPS، تأكد من تحديد ملف pem المناسب. frontend www-https bind www.example.com:443 ssl crt /etc/ssl/private/www.example.com.pem reqadd X-Forwarded-Proto:\ https default_backend app-backendنستكمل الإعداد بضبط النهاية الخلفية: backend app-backend redirect scheme https if !{ ssl_fc } server app1 app1.nyc3.example.com:80 check server app2 app2.nyc3.example.com:80 checkتحدد النهاية الخلفية خواديم التطبيقات التي يوزَّع بينها الحمل. يطلب السطر: redirect scheme https if !{ ssl_fc } توجيه اتصالات HTTP إلى HTTPS. احفظ ملف haproxy.cfg ثم أغلقه. HAProxy جاهز الآن لبدء العمل؛ لكن سنفعل أولا السجلات Logs. تفعيل سجلات HAProxyافتح ملف rsyslog للتحرير: sudo nano /etc/rsyslog.confابحث عن الأسطر التالية وانزع علامة التعليق من أجل تفعيل بروتوكول UDP عند استقبال سجلات النظام Syslog. تبدو الأسطر كما يلي بعد نزع علامة التعليق: $ModLoad imudp $UDPServerRun 514 $UDPServerAddress 127.0.0.1أعد تشغيل خدمة rsyslog لتفعيل الإعداد الجديد: sudo service rsyslog restartسجل HAProxy مفعَّل الآن وسيُنشأ ملف var/log/haproxy.log/ فور بدء عمل HAProxy. إعادة تشغيل HAProxyأعد تشغيل HAProxy لأخذ التعديلات في الحسبان. sudo service haproxy restartاكتمل الآن إعداد موزع الحِمل، ننتقل لتثبيت التطبيق (ووردبريس). تثبيت ووردبريسسيتوجب علينا - قبل البدء في استخدام ووردبريس - تشغيل سكربت التثبيت الذي يهيئ قاعدة البيانات ليستخدمها ووردبريس. أدخل إلى العنوان التالي في المتصفح: https://www.example.com/wp-admin/install.phpستظهر شاشة تثبيت ووردبريس. املأء الحقول بما يناسب ثم انقر على زر التثبيت. بعد انتهاء تثبيت ووردبريس يصبح التطبيق جاهزا للعمل. خاتمةاكتمل الآن إعداد الخواديم المكوِّنة للتطبيق، وهذا الأخير جاهز للاستخدام. يمكنك الدخول بحساب المدير كما يمكن لزوار موقعك الوصول إليه عبر HTTPS عند استخدام اسم النطاق المناسب. تأكد قبل الانتقال إلى الجزء الموالي من الدليل أن التطبيق يعمل بطريقة صحيحة. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Deploying لصاحبه Mitchell Anicas. حقوق الصورة البارزة: Designed by Freepik.

يعرض هذا الدّرس والذي يُعتبر الأول من سلسلة ذات ستة أجزاء كيفية إعداد بنية تحتية لتطبيق مكوَّن من خواديم عدة، انطلاقا من الصفر. سيحتوي الإعداد النهائي على آليات للنسخ الاحتياطي Backup، المراقبة Monitoring، نُظُم مركزية للسجلات Centralized logging مما يعزز من إمكانية تشخيص المشاكل واستعادة إعدادات التطبيق عند الحاجة. الهدف الأسمى هو إنشاء نظام إدارة قائم بذاته، والتعريف بأهم المفاهيم والاعتبارات العملية التي ينبغي التنبه لها عند إعداد خادوم موجَّه للإنتاج Production server. ملحوظة: توجد -عادة- أثناء تطوير وإعداد البرامج بيئة إنتاج وبيئة اختبار (أو أكثر). في بيئة الاختبار يستخدم قليلون التطبيق، ويكون المستخدمون في هذه الحالة غالبا مطورين يبحثون عن علل لترقيعها. في الجانب الآخر فإن التطبيق في بيئة الإنتاج يستخدمه المستهدَفون الحقيقيون بالمنتَج (التطبيق)؛ لذا يجب أن يعمل بكفاءة وسلاسة. قراءة الدّرس التالي وفهمه سيساعدك في المضي قدما مع هذا الدّرس: خمسة إعدادات شائعة لتطبيقات الوب.يقدم المقال خطوطا عريضة لإعداد تطبيق موجَّه للإنتاج، بينما يوضح هذا الدّرس كيفية التخطيط لتطبيق نموذجي وإعداده من البداية إلى النهاية. المأمول هو أن يساعدك الدرس في التخطيط لإعداد خادومك الخاص ثم تنفيذ الإعداد حتى ولو كنت تشغِّل حزمة تطبيقات مختلفة تماما. يحيل الدّرس في أحيان كثيرة، نظرا لأنه يغطي مواضيع مختلفة من إدارة النظم، إلى شروحات مفصلة ضمن مقالات أخرى تقدم معلومات إضافية. الهدفسنحصل بنهاية مجموعة المقالات هذه على خادوم إنتاج معدّ لتشغيل تطبيق PHP، ووردبريس على سبيل المثال، يمكن الوصول إليه عبر العنوان https://www.example.com/. سنعدّ أيضا خواديم إضافية لدعم خواديم التطبيق في بيئة الإنتاج. سيبدو الإعداد النهائي على النحو التالي (لا تظهر خواديم نظام إدارة النطاقات DNS الداخلية ولا النسخ الاحتياطية البعيدة في الصورة أدناه): نعُدُّ الخواديم الموجودة في مربع التطبيق ضرورية ليعمل التطبيق على النحو المرجو. تعمل العناصر المتبقية - النسخ الاحتياطية، المراقبة، والسجلات - بجانب خطة الاستعادة وخادوم النسخ الاحتياطي البعيد؛ على دعم خادوم الإنتاج. سنثبت كل عنصر على خادوم Ubuntu 14.04 منفصل ضمن نفس الحيز الجغرافي مع تفعيل التشبيك الخاص Private networking. نستخدم أسماء المستضيفات Hostnames لتمييز الخواديم المكوِّنة للتطبيق: lb1: موزع الحمل HAProxy، يمكن الوصول إليه عبر العنوان https://www.example.com/.app1: خادوم تطبيقات Apache و PHP.app2: خادوم تطبيقات Apache و PHP.db1: خادوم لقاعدة بيانات MySQL.من المهم التنبيه إلى أنه تم اختيار هذا النوع من الإعداد لتوضيح كيف يمكن لعناصر تطبيق أن تُنشأ على خواديم عدة؛ يجب أن يُخصَّص إعداد تطبيقك بناء على احتياجاتك. توجد نقطة إخفاق Point of failure وحيدة في هذا الإعداد، ويمكن التغلب عليها بتركيب موزع حمل إضافي (وخادوم DNS دوري) ومضاعفة قاعدة البيانات؛ وهو ما لن تطرق إليه في هذا الدرس. نميز العناصر الداعمة للتطبيق بأسماء المستضيفات التالية: النسخ الاحتياطية backups: خادوم النسخ الاحتياطي Bacula.المراقبة monitoring: خادوم Nagios.السجلات logging: سجلات مركزية باستخدام حزمة برمجيات مكونة من Kibana (ELK)، Logstash و Elasticsearch.توجد عناصر أخرى لا تظهر في الصورة، وهي: ns1: وهو خادومنا الرئيس لنظام أسماء النطاقات. نستخدم Bind لهذا الغرض.ns2: وهو الخادوم الثانوي لنظام أسماء النطاقات. نستخدم Bind.remotebackups: خادوم بعيد يوجد في منطقة جغرافية أخرى نحفظ عليه نسخ Bacula الاحتياطية احترازا من كارثة تحل بمركز البيانات الذي يوجد فيه التطبيق.يمكنك أيضا استخدام عنوان IP عائم Floating IP؛ وهو عبارة عن عنوان IP ثابت يُتاح للعموم الوصول إليه ويمكن توجيهه إلى أحد خواديمك الافتراضية أو بنيتك التحتية المكرَّرة Redundant ثم إطلاق موقعك أو خدمتك باستخدام عنوان IP عمومي وحيد. يمكن بعدها إعادة توجيه العنوان العائم إلى خادوم جديد من أجل بيئة إنتاج أكثر مرونة وأسرع تجاوبا. سنضع أيضا خطط استعادة لكلٍّ من العناصر المكونة للتطبيق. ستكون لدينا، عند بلوغ الهدف النهائي، عشرة خواديم. سننشئها كلَّها في نفس الوقت لتسهيل بعض الأمور مثل إعداد النطاقات؛ ولكن يمكنك إنشاؤها الواحد تلو الآخر حسب الحاجة. شبكة خاصة افتراضية Virtual Private Network (اختياري)إذا أردت تأمين اتصالات الشبكة بين خواديمك فيجب عليك إعداد شبكة خاصة افتراضية VPN. يصبح تأمين نقل البيانات عبر الشبكة بتعميتها Encryption أكثر أهمية إذا كانت البيانات تمر عبر الإنترنت. من منافع استخدام شبكة خاصة افتراضية التحقق من هوية المستضيفات بالاستيثاق منها؛ وهو ما يحمي من المصادر التي لا يُرخص لها الوصول للخدمات. إذا كنت تبحث عن أداة مفتوحة المصدر فيمكنك استخدام OpenVPN واتباع خطوات درس دليلك لكيفية إعداد خادوم OpenVPN على Ubuntu لإعداده. المتطلباتيتوجب أن يكون لدى كل خادوم أوبنتو 14.04 حساب مستخدم بصلاحيات إدارية غير المستخدم الجذر؛ يمكن إعداد مستخدم لهذا الغرض باتّباع الخطوات المشروحة في مقال الإعداد الابتدائي لخادوم أوبنتو 14.04. سننفّذ كل الأوامر باستخدام هذا الحساب. سنفترض أيضا أن لديك معرفة بالمفاهيم الأساسية للأمان في لينكس. إذا رغبت في درس تمهيدي حول الموضوع فيمكن الاطلاع على مقال 7 تدابير أمنيّة لحماية خواديمك. اسم نطاقنفترض في هذا المقال أن الوصول إلى التطبيق يكون عبر اسم نطاق، example.com مثلا. إنْ لم يكن لديك اسم نطاق فبالإمكان شراء واحد من أحد مسجلي أسماء النطاقات Domain name registrar. نحتاج اسم النّطاق ليس فقط لتسهيل الوصول إلى الموقع (مقارنة بعنوان IP المكون من أرقام فقط) بل أيضا للحصول على فوائد التحقق من الهوية والنطاق؛ وهو ما يتيح إمكانية الاستفادة من شهادات SSL التي تعمّي البيانات المنقولة بين التطبيق ومستخدميه. شهادة SSLيعمل بروتوكول TLS/SSL على تعميّة البيانات والتحقق من نطاقها أثناء الاتصال بين التطبيق ومستخدميه؛ لذا سنستخدم شهادة SSL لإضافة هذا الإعداد. في المثال نريد أن يصل المستخدمون إلى الموقع عبر العنوان www.example.com وهي القيمة التي سنحددها في الاسم الشّائع للشهادة Common Name (أو ما يُعرف اختصارًا بـ CN). سنثبت الشهادة على خادومHAProxy (المُسمّى lb1) وهو ما يعني أنه من الأفضل توليد مفاتيح الشهادة وطلب توقيع الشهادة Certificate Signing Request CSR على هذا الخادوم. إذا احتجت للتحقق من الهوية فستحتاج لشراء شهادة SSL. توجد الكثير من سلطات الشهادات Certificate Authorities التجارية التي يمكن شراء شهادة SSL منها. كما توجد إمكانية لاستخدام شهادة مجانية من StartSSL يتوفر أيضا حل بديل يتمثل في التوقيع الذاتي لشهادة SSL بتنفيذ الأمر التالي: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ~/www.example.com.key -out ~/www.example.com.crtالخطوات المتبعة للوصول إلى الهدفعرضنا في الفقرات السابقة نظرة عامة على إعداد تطبيقنا الموجَّه للإنتاج، ننتقل الآن لإنشاء خطة عامة نسير وفقها لتحقيق هدفنا. العناصر الأهم هي تلك التي يتكون منها التطبيق؛ لذا يجب أن نشغلها مبكرا. لكن نظرا لأننا نخطط لاستخدام عنونة تعتمد على أسماء النطاقات للاتصالات ضمن الشبكة الخاصة فيجب أن نعد نظام أسماء النطاقات أولا. سنعدّ، بعد الانتهاء من ضبط إعداد النطاقات، الخواديم التي تكون التطبيق من أجل أن يكون جاهزا للتشغيل. يحتاج التطبيق إلى أن تكون قاعدة بيانات مهيَّأة سلفا، كما يتطلب موزع الحِمل أن يكون التطبيق جاهزا. انطلاقا من هذه الاعتبارات فإن إعداد العناصر سيكون حسب الترتيب التالي: خادوم قاعدة البيانات.خواديم التطبيق.موزع الحمل.سيمكننا - بعد إكمال الخطوات السالفة الذكر من أجل إعداد التطبيق - استنباطُ خطة للاستعادة اعتمادا على سيناريوهات عدة. ستكون خطة الاستعادة أساسية في التخطيط لآليات النسخ الاحتياطي. بعد خطة الاستعادة يأتي دور إعداد النسخ الاحتياطي ثم بعد استكماله يمكن ضبط نظام المراقبة من أجل التأكد من أن جميع الخواديم وكل الخدمات في وضعيةِ عمل مقبولة. ثم نأتي للخطوة الأخيرة وهي إنشاء نظام مركزي لتخزين السجلات مما يسمح بعرضها عند الحاجة، تشخيص المشاكل عند حدوثها وتحليلها لتحديد أنواع الاستخدام وطبيعته. خاتمةخطة العمل جاهزة الآن مما يعني أننا جاهزون للبدء في تنفيذ إعدادات التطبيق. ينبغي تذكر أن هذا الإعداد، رغم أنه يعمل على النحو المراد، يبقى مثالا يجب أن تستطيع التقاط معلومات مفيدة منه ثم استخدام ما تعلمته لتحسين إعداد تطبيقك الخاص. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Overview لصاحبه Mitchell Anicas. حقوق الصورة البارزة: Designed by Freepik.