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

يُستعمل Varnish Cache بكثرة لتخبئة محتوى مواقع الويب لتسريع أداء المواقع وتخفيض الحمولة على الخادوم الأصل (origin-server). لطالما شجعنا على استعمال التّخبئة لتسريع أداء تطبيقات الويب وتسهيل قابلية التوسع (Scalability) وضمان الاستقراريّة إضافة إلى الفوائد الأخرى التي تأتي مع هذه الإجراءات من تحسين لتجربة المُستخدم إلى التوفير في الموارد. لكن رغم ذلك فلا نزال بحاجة إلى التأكيد على أهميّة التّخبئة. وفي بعض الأحيان، قد يعني الأمر شرح كيفيّة استعمال Varnish Cache وما يُميّزه عن بقيّة التقنيات الأخرى. الأمور الغريبة التي تُميّز Varnish Cache Varnish Cache عبارة عن خادوم HTTP بنظام HTTP خلفي له قدرة على تقديم الملفّات. يعتمد على هندسة سلسليّة (threaded architecture)، دون حلقة أحداث (event loop). ولأن شيفرة الكتابة قادرة على استعمال استدعاءات النظام الحاصرة (blocking system calls)، فذلك يجعله أسهل استعمالا من Apache أو NGINX، التي يتطلّب استعمالها التعامل مع حلقة أحداث. يقوم Varnish Cache بالتسجيل (logging) على الذاكرة عوضا عن القرص الصلب، تم تصميمه بهذه الطّريقة لأن تسجيل 10000 من عمليات HTTP كل ثانية على القرص الصلب أمر يتطلب الكثير من الموارد. يقوم Varnish بتسجيل جميع التّفاصيل (حوالي 200 سطر لكل طلب) على الذاكرة مُباشرة. إن لم يتم طلب التفاصيل المُسجّلة فستتم الكتابة فوقها (overwrite). يعتبر Varnish التطبيق الوحيد الذي يتخذ هذا المسلك. المرونة: استعمال VCL الميّزة الكبرى لـ Varnish Cashe هي لغة الضّبط الخاصّة به. تمّ إنشاء لغةVCL (Varnish Configuration Language) منذ أكثر من 11 عاما لتدعم النسخة الأولى من Varnish Cache. على عكس Apache أو بقيّة البرمجيّات، فـVarnish Cache لا يعتمد على إعداد تقليدي.بل يعتمد عوضا عن ذلك على مجموعة من السّياسات التي تُكتب بهذه اللغة. تتم ترجمة هذه السيّاسات إلى شيفرة ثنائية، تُحمّل هذه الشيفرة ويتمّ تشغيلها بعد ذلك. يقول مهندس Varnish Cache Poul-Henning Kamp بأنVCL أُنشأت لتكون مجموعة أدوات يمكن استعمالها حسب الحاجة، وليس قطعة موحدة يُمكن إضافتها إلى بيئة العمل. في يومنا الحالي، هناك أكثر من 100 وحدة (modules) لـ VCL يمكن استعمالها ببساطة. في الحقيقة، ففي ملتقيات Varnish Summits هناك دائما ورشة عمل لتعليم الأشخاص كيفيّة كتابة وحدات خاصّة. تعتبر لغة VCL من أكبر الأسباب التي تجعل النّاس تستعمل وتتعلّق بـVarnish Cache. إذ تفتح المرونة التي توفرها اللغة الأبواب للقيام بأي شيء قد يرغب أحدهم بفعله، ما يمحو القيود التي عادة ما تأتي مع البرمجيّات التقليديّة. إذا، ما هي أهم الأدوات التي توفّرها VCL وكيف يُمكننا الاستفادة منها؟ التنطيف Purging لا يدعم Varnish تنظيف المحتوى عند إعداده لأول مرّة، إذ لا يُمكنك تنزيله وتنصيبه ثمّ استعمال نظام تنظيف دون أية خطوات إضافيّة. عوضا عن تمكين إعدادات افتراضيّة، يتوجب على مستخدمي Varnish Cache العمل على تفعيل الميزات المرغوبة كل على حدة، لكن إعداد نظام تنظيف أمر بسيط، ويمكنك الحصول على النتيجة التي ترغبها. sub vcl_recv { if (req.method == "PURGE") { return (purge); } } إن لم ترغب بتمكين الأشخاص على الأنترنت من تنظيف المحتوى على نظام تخبئتك، فسيتوجب عليك ضبط حدّ الوصول ACL كما يلي: acl purge { "localhost"; "192.168.55.0"/24; } sub vcl_recv { if (req.method == "PURGE") { if (!client.ip ~ purge) { return(synth(405,"Not allowed.")); } return (purge); } } إضافة ميزة لـVarnish Cache: خنق الرّبط السّاخن (Hot linking) يسمح إطار العمل الخاص بـVarnish للمستخدمين بإضافة أية ميزة يحتاجون إليها. أول ميّزة أضيفت هي استعمال VCL للحد من الرّبط السّاخن. الرّبط السّاخن هو عمليّة سرقة موارد أحدهم على الويب وكتابة مقال يستخدم صورا مرفوعة على خادوم الضّحية ليدفع تكاليف استخدام الموارد. يسمح Varnish للخوادم بإيقاف هذه العملية عند استعمال الرّبط السّاخن للموارد الخاصة بالخادم دون إذن. على سبيل المثال، يمكن لـVarnish وضع سقف لعدد مرّات حدوث هذا الأمر كل ثانيّة عبر استخدام وحدة من وحدات Varnish (VMOD) باسم vsthrottle لإضافة الخنق (throttling). يمكن القيام بالأمر عبر استيراد وتحميل الوحدة. شيفرة VCL أسفله تُوضّح كيفيّة الحدّ من الرّبط السّاخن. في هذا المثال، نقوم بتطبيق ثلاثة قواعد. القاعدة الأولى تتحقّق من أن عنوان URL المطلوب يبدأ بـ/assets/. القاعدتان الثانيّة والثّالثة تحميان مجلّد الملفات السّاكنة من الرّبط السّاخن. يتمّ هذا عبر التحقق ممّا إذا كان المُحيل referrer طرفا غير مُتوقّع، وما إن طلبت أسماء نطاق أخرى ملفّاتك لأكثر من 10 مرّات خلال 60 ثانيّة. ما سبق عبارة عن دالّة الخنق، يُستعمل رابط URL كمفتاح للخنق.الحدّ المسموح به هو 10 مرّات كلّ 60 ثانيّة. يُمكن تقديم الملفات السّاكنة غير المُشار إليها، وعندما يحصل ذلك، فسيتم إرسال خطأ 403 مع منع الربط السّاخن. يُمكن كذلك توسيع الخنق لاستعمال memcache، وذلك ليحصل المستخدم على المُحاسبة الرّئيسيّة (central accounting) في العنقود (cluster). import vsthrottle; (..) if (req.url ~ "^/assets/" && (req.http.referer !~ "^http://www.example.com/") && vsthrottle.is_denied(req.url, 10, 60s) { return(error(403,"Hotlinking prohibited"); } التّعامل مع ملفات تعريف الارتباط (cookies) لن يقوم Varnish بتخبئة المحتوى الذي يُطلَبُ باستعمال ملفّات تعريف الارتباط. ولن يستجيب إلى طلب محتوى مخبّأ إن كان الطّلب متعلّقا بملف تعريف ارتباط. عوضا عن هذا، يُمكن استعمال وحدة VMOD لحذف ملفّ تعريف الارتباط. المحترفون يستعملون تعبيرا نمطيّا (regular expression) لترشيح ملفات تعريف الارتباط. ولأنّنا لسنا محترفين، فـVarnish يوفّر وحدة باسم cookie تبدو كما يلي: import cookie; sub vcl_recv { cookie.parse ("cookie1: value1; cookie2: value2"); cookie.filter_except("cookie1"); // get_string() will now yield // "cookie1: cookie2: value2;"; } لا يقوم Varnish بإنشاء ترويسة (header) ملف تعريف ارتباط. وإن رأى بأن النظام الخلفي قد أرسل شيفرة إنشاء ملفّ تعريف ارتباط، فلن يقوم بتخبئته. الحل أن تحذف ترويسة Set-Cookie أو إصلاح الخادوم الخلفي. ترويسات Set-Cookie تقوم بتعطيل ملفّات تعريف الارتباط. الحلّ: احذف ترويسة Set-Cookie أو أصلح النّظام الخلفيّ. نمط الإمهال Grace Mode يُمكن نمط الإمهال Varnish من تقديم محتوى قديم إن لم يكن المحتوى الجديد جاهزا أو مُتوفّرا. يساهم هذا في تحسين الأداء عبر إعادة تحميل المحتوى من النظام الخلفيّ بشكل غير متزامن (asynchronous). في الوقت الذي تم فيه تقديم Varnish 1.0 كحل لنظام تخبئة لموقع الجريدة النرويجيّة Verdens Gang، كانت هناك مشاكل كبرى بسبب التكتّلات السلسليّة (threading pileups). كانت الصفحة الرّئيسيّة للموقع تُقدّم 3000 مرّة كلّ ثانيّة، لكن نظام إدارة المُحتوى (CMS) كان بطيئا، إذ كان يأخذ 3 ثوان لإعادة توليد الصّفحة الرّئيسيّة. في بعض المواقع، إن اتّبعت طلبات التّعليقات (RFC)، فسيقوم وسيط (proxy) التّخبئة بإلغاء الصّفحة الرّئيسيّة أو سيحدث انقضاء وقت (time out). عندها سيأتي مُستخدم آخر وسيتوجب جلب نسخة جديدة من الصّفحة الرّئيسيّة. يقوم Varnish بهذا عبر عمليّة التئام التّخبئة (coalescing). إذ يتم وضع المستخدمين الجدد عند وصولهم على قائمة انتظار. (أنظمة التّخبئة الأخرى تُرسل المُستخدمين إلى النظام الخلفيّ ما يقتل الخادم). إن تّمت إضافة 3000 مُستخدم إلى قائمة الانتظار كلّ ثانيّة، فبعد ثلاثة ثوان، سيكون الطابور عبارة عن 9000 مستخدم ينتظرون النظام الخلفي لجلب المحتوى. في البداية، كان Varnish يأخذ المحتوى المطلوب، ويقوم بالتواصل مع السّلاسل (Thread) الـ9000 التي تمّ إنشاؤها، ويُحاول دفع كل شيء دفعة واحدة. سمّي هذا الحدث بالقطيع الصّاخب (thundering herd). وكانت النّتيجة موت الخادوم فورا. لحلّ هذه المُشكلة، قرّر Varnish استعمال الصفحة الرّئيسيّة القديمة عوضا عن انتظار الخادوم لإعادة توليد المحتوى. لن يهتم أحد إن كان المحتوى قديما بـ20 ثانيّة، إلا في حالة كانت البيانات التي تقدّمها متعلّقة بمعلومات ماليّة وترغب عرضها في الوقت الفعلي. تغيّرت التّفاصيل المتعلّقة بـGrace خلال السنوات الماضيّة. في Varnish 4.0 (إن تمّ تفعيله) فستبدو كما يلي: sub vcl_backend_response { set beresp.grace = 2m; } يتم ربط Grace مع كائن الإجابة الخلفيّة (backend response object). إن تم تحديد القيمة في دقيقتين (2m) فسيُبقي Grace على الكائن لدقيقتين بعد انقضاء الـTPL. إن تم طلب الكائن خلال هذا الوقت، فسيتم تفضيل تقديم ما هو مُخبّأ عوضا عن إرسال طلب جديد إلى النظام الخلفيّ. سيتم استعمال الكائن وإعادة تحميله بعدها بشكل غير متزامن. تفاصيل Grace لا يتطلب فهم Varnish Cache النظر إلى الشّيفرة المصدريّة، عوضا عن ذلك، يتم توفير VCL افتراضيّ يُمكن الاعتماد عليه لإضافة أية تفاصيل أخرى حسب الحاجة. فبِميّزة مثل Grace يُمكن للمُستخدمين قراءة شيفرة VCL والنظر إلى التفاصيل: Insert code sub vcl_hit { if (obj.ttl >= 0s) { // A pure unadulterated hit, deliver it return (deliver); } if (obj.ttl + obj.grace > 0s) { // Object is in grace, deliver it // Automatically triggers a background fetch return (deliver); } // fetch & deliver once we get the result return (fetch); } إن كان الكائن VCL يحمل قيمة أكبر من 0 ثوان، هذا يعني بأنّ الـTTL موجب، سيتمّ الرجوع والتّقديم. إن كانتا كل من قيمتي TTL وGrace أكبر من 0 ثوان، فهذا يعني بأنّها ضمن Grace وسيقوم Varnish بتقديمها. إن كانتا كل من قيمتي TTL وGrace أصغر من 0 ثوان، فسيتّم طلب الصّفحة من النّظام الخلفيّ. تعديل كيفيّة عمل Grace يُمكن للمؤسّسات التي تكون بحاجة إلى تقديم معلومات ماليّة وتأبى عرض معلومات قديمة للمُستخدم أن تُغيّر من كيفيّة عمل Grace. في المثال التّالي، لم يتغيّر الجزء الأول، في الجزء الثّاني نقوم بالتقديم في حالة لم يكن الخادوم الخلفيّ على ما يرام وكانت كلا من قيمتي TTL و Grace أكبر من 0 ثانيّة. sub vcl_hit { if (obj.ttl >= 0s) { // A pure unadulterated hit, deliver it return (deliver); } if (!std.healthy(req.backend_hint) && (obj.ttl + obj.grace > 0s)) { return (deliver); } // fetch & deliver once we get the result return (fetch); } *بضعة معلومات إضافيّة: beresp: كائن الطّلب الخلفّي backend request object. req: كائن الطّلب request object. يُستعمل في vcl_recv. bereq: كائن الطّلب الخلفي backend request object. يُستعمل في vcl_backed_fetch. beresp: كائن الإجابة الخلفيّة. يُستعمل في vcl_backend_response. resp: كائن الإجابة response object. يُستعمل في vcl_deliver. obj: الكائن الأصلي في الذّاكرة. يُستعمل في vcl_hit. للمزيد من التّفاصيل استعمل man(7) vcl. آلة الحالة (state machine) يمرّ كل طلب عبر عدّة حالات. يُمكن تشغيل شيفرة مخصّصة في كل حالة لتعديل كائنات الطّلب. بعد تنفيذ الشّيفرة المخصّصة، يقوم Varnish باتّخاذ قرار ما إذا كان نجاحا (Hit) أو إخفاقا (Miss) بعدها يتم تشغيل إمّا VCL hit أو VCL Miss. في حالة النّجاح سيقوم Varnish بتقديم المحتوى. والإخفاقات تُعيد الطّلب من النظام الخلفي. 90% من التّغييرات التي يُحدثها المُستخدمون تحدث هنا. كيفيّة التّضبيط (Tuning) على Linux يتم تحديد الانضباطيات (Tunables) على Linux بشكل محافظ، ونجد SOMAXCONN و TCP_MAX_SYN_Backlog أكثرها مشقّة. عند الانصات (listen) إلى المقابس (socket)، يأخذ Varnish بضعة ثوان للانصات للنّداء. إن كانت السّلاسل مشغولة، فستبدأ النّواة (kernel) بالتّكتّل (queue). لا يُسمَحُ لهذا التّكتّل بأن ينمو إلى ما وراء قيمة SOMAXCONN. سيطلب Varnish 1024 اتّصالا على تكتّل عمق الانصات (listen depth queue)، لكنّ النواة تقوم بإبطال ذلك لتحصل على 928 فقط. ولأنّ Varnish يعمل بصلاحيات الجذر (root)، فمن الممكن تقرير عمق انصات خاصّ، لكنّ Linux أدرى بما هو أفضل. قد يرغب المُستخدمون بالرّفع من هذا الحدّ إن أرادوا تخفيض خطر رفض الاتّصالات عند انقضاء عمق الانصات. سيتوجّب على المستخدم اتخاذ قرار ما إذا كان عدم التّقديم وتقديم صفحة خطأ أفضل أو لا. يقوم TCP_MAX_SYN_Backlog بتعريف عدد الاتّصالات البارزة التي يُمكن لها أن تكون بداخل إقامة الاتّصال (handshake) الثّلاثي الأطراف قبل أن تقرّر النواة بأنّها تحت الهجوم. القيمة الافتراضيّة هي 128. لكن في حالة دخل جمع كبير من النّاس إلى موقعك دفعة واحدة فقد تحصل على أكثر من 128 اتّصال TCP كلّ ثانيّة. لا تقم بتعديل tcp_tw_recycle. تأكّد بأنّك تعرف ما تفعله قبل لمس الإعدادات وابحث على الويب قبل ذلك. إذ أنّ الكثير من العفاريت (demons) تعتمد على هذه القيّم. مساحات العمل (Work spaces) في Linux في Varnish، الذاكرة المحليّة متواجدة في كلّ سلسلة. ولأنّ التّراجع (rollback) يستنزف الموارد، فإنّنا لا نتراجع كلّما احتجنا إلى قليل من المساحة في الذّاكرة. عوضا عن ذلك، نقوم بتعيين مُسبق للذّاكرة على كلّ سلسلة إن كان للمستخدم العديد من سياسات VCL التي قد تستنزف مساحة العمل بأكملها. لا يقوم Varnish بتتبّع الاتّصال، وحدة التّعاقد (contract module) بطيئة للغاية. يتمّ افتراضيّا تشغيل خمسة سلاسل. يُمكن إنشاء سلاسل جديدة بسرعة نسبيّا، لكن إن كنت تخطّط لفتح ألف اتّصال كلّ ثانيّة أي ألف سلسلة، ففي هذه الحالة لديك مُعطى (parameter) لتخصيص سلاسل مُسبقا. خلاصة: احذر عند التّعامل مع مساحات العمل. لا تقم بتتبّع الاتّصالات (connection tracking). ارفع معدّل السّلاسل إلى طلب واحد في الثانيّة لكل سلسلة. الموازنة بين ما هو غريب وما هو رائع في Varnish Cache المرونة القويّة والمميّزات التّي يتمتّع بهاVarnish Cache لا تأتي في حزمة جاهزة (ما قد يجده البعض غريبا)، لذا فقد لا يكون الحلّ الأنسب للجميع. لكنّ المرونة التي يتمتّع بها قد تُغيّر من مجريات الأمور عند الرغبة في تخصيص والتّحكم بأداء المواقع وقابليّة توسيعها. ترجمة -بتصرّف- للمقال Getting started with web app accelerator Varnish Cache لصاحبه Per Buer.

يوفّر Laravel واجهة تطبيقات برمجية موّحدة للتعامل مع أنظمة تخبئة Cache مختلفة مثل Memcached وRedis. سنعرض في هذا المقال لكيفية إعداد التخبئة في Laravel ومبدأ عملها ثم نتطرق للدالة المساعدة cache التي أضيفت إلى إطار العمل بداية من الإصدار 5.3. تهيئة بيئة التطوير يُحدَّد اسم النظام المستخدَم في التعليمة CACHE_DRIVER ضمن ملف env.. تأخذ التعليمة CACHE_DRIVER مبدئيا القيمة file التي تعني أن الكائنات Objects المخبَّأة ستخزن ضمن ملف ضمن نظام التشغيل. تُضبَط إعدادات نظام التخبئة المستخدَم في الملف config/cache.php، بعد تعيينه بالتعليمة السابقة. نفترض أنك لديك مشروع Laravel بالإصدار 5.3 للتطبيق عليه. ننفذ الخطوات التالية لتهيئة مثال نعتمد عليه في ما بعد للشرح. إنشاء نموذج والتهجير المصاحب له وبذره نستخدم artisan لإنشاء نموذج Eloquent مع التهجير المصاحب له على النحو التالي: php artisan make:model Post -m نفتح ملف التهجير لضبط الحقول في جدول البيانات بإضافة حقل جديد يُسمّىtitle (العنوان): public function up() { Schema::create('posts', function (Blueprint $table) { $table->increments('id'); $table->string("title"); $table->timestamps(); }); } يمكننا الآن تنفيذ التهجير: php artisan migrate الخطوة التالية هي بذر الجدول الحصول على بيانات للتطبيق عليها. ننشئ ملف البذر: php artisan make:seeder PostsTableSeeder ثم نعدل عليه: class PostsTableSeeder extends Seeder { public function run() { Model::unguard(); // نستورد faker لبذر الجدول $faker = Faker\Factory::create(); // ننشئ 10 تسجيلات في الجدول foreach(range(1, 10) as $index) { Post::create([ 'title' => $faker->sentence(5), ]); } Model::reguard(); } } نعدّل ملف بذر قاعدة البيانات لإضافة ملف بذر الجدول posts إليه: public function run() { $this->call(PostsTableSeeder::class); } ثم ننفذ البذر: php artisan db:seed --class=PostsTableSeeder لدينا الآن جدول بيانات بـ10 تسجيلات. أكملنا إعداد النموذج الذي نريد العمل عليه، الخطوة الموالية هي إعداد المتحكم والمسارات. المتحكم والمسارات نستعين بأداة artisan لإنشاء متحكم على النحو التالي: php artisan make:controller PostsController ننشئ في المتحكم PostsController دالة باسم index نستخدمها للحصول على جميع المنشورات الموجودة في جدول البيانات posts بصيغة JSON: public function index() { $posts = Post::all(); return response()->json($posts); } لا تنس استيراد النموذج Post: use App\Post; ثم ننتقل إلى إعداد المسارات. سنضيف مسارا باسم posts/ إلى ملف مسارات واجهةالوب routes/web.php: Route::get('/posts', 'PostsController@index'); يمكننا الآن تنفيذ الأمر php artisan serve من مجلد المشروع لتشغيل الخادوم الخاص ببيئة التطوير ثم الذهاب إلى الرابط http://localhost:8000/posts لرؤية جميع المنشورات المحفوظة في الجدول. إعداد التخبئة واستخدامها تُضبَط التخبئة - كما أسلفنا - في الملفين env. وconfig/cache.php. يحوي الصنف Illuminate\Support\Facades\Cache الكثير من الدوال الثابتة Static التي تتعامل مع التخبئة. إضافة قيمة إلى التخبئة تُستخدَم الدالة Cache::put لإضافة قيمة إلى التخبئة. تأخذ الدالة ثلاثة معطيات: Cache::put('key', 'value', 10); مفتاح key يمثل اسم المتغير. لا يمكن أن تحمل قيمتان في النظام نفس المفتاح. قيمة المفتاح value. مدة زمنية معبَّر عنها بالدقائق (10 في المثال أعلاه)، وتمثل المدة التي سيحتفظ النظام فيها بقيمة المفتاح ضمن التخبئة. تمكن أتمتة إضافة المفاتيح إلى التخبئة بالدالة remember. تبحث هذه الدالة أولا عن قيمة المفتاح في التخبئة، وترجعها إن وجدته؛ فإن لم تجده تنشئ المفتاح وتعطيه القيمة التي ترجعها دالة الإغلاق Closure الممررة في المعطى الثالث. سنستخدم الدالة remember في دالة index التي أضفناها سابقا إلى المتحكم. نعدّل الدالة index على النحو التالي: public function index() { $posts = Cache::remember('posts', 5, function() { return Post::all(); }); return response()->json($posts); } لا ننسى استدعاء الصنف Cache: use Illuminate\Support\Facades\Cache; تعني الشفرة أعلاه أننا عند طلب الدالة index فإنها ستبحث عن المنشورات الموجودة في التخبئة، فإن وجدتها ترجعها وإلا فإنها تنشئها باستدعاء الدالة all من النموذج Post؛ وتحتفظ بها في التخبئة لمدة خمس دقائق؛ ثم ترجع النتيجة. بهذا تكون جميع الطلبات التي ترد إلى المسار posts/ تمر عبر التخبئة؛ سنضيف لأغراض التوضيح مسارا جديدا (ضمن routes/web.php) لنعدل عن طريقه على إحدى التسجيلات الموجودة في جدول المنشورات: Route::get('/edit/post/{id}', 'PostsController@edit'); ونعدّل المتحكم بإضافة الدالة edit التالية: public function edit($id) { $post = Post::find($id); $post->title = "New title for ".$id; $post->save(); $posts = Post::all(); return response()->json($posts); } ما يحدث هو التالي: تظهر عند زيارة الرابط posts/ المنشورات مع المرور على نظام التخبئة؛ أما عند زيارة المسار edit/post/id/ فسنعدّل على المنشور ذي المعرف id، ثم نعرض المنشورات المخزنة في الجدول مباشرة، دون البحث عنها في التخبئة. يظهر في الصورة المتحركة التالية الفرق بين استخدام التخبئة وطلب المنشورات مباشرة من الجدول: تكون التخبئة فارغة عند زيارة المسار posts/ لأول مرة. في هذه الحالة يطلب Laravel المنشورات مباشرة من جدول البيانات، يعرضها ثم يضيفها إلى التخبئة. نطلب الرابط edit/post/1/ الذي يغيّر عنوان المنشور ذي المعرف 1 ليصبح New title for 1؛ ثم يعرض المنشورات بطلبها مباشرة من جدول قاعدة البيانات. لاحظ تغير عنوان المنشور. نعود للرابط posts/ قبل انقضاء المدة المحددة في دالة التخبئة (5 دقائق)، نلاحظ أن التعديل الذي أجريناه لا يظهر في المنشورات المعروضة. ملحوظة: يجب التأكد في التطبيقات الموجهة لبيئة الإنتاج من تناسق عمليات التعديل على قاعدة البيانات والتخبئة. بمعنى أنه يجب أن ينعكس التعديل على قيمة في جدول البيانات مباشرة على القيمة المحفوظة في التخبئة. العمليات على التخبئة الحصول على قيمة من التخبئة: Cache::get('key'); يمكن إرجاع قيمة مبدئية في حال عدم وجود المفتاح في التخبئة: Cache::get('key', 'default'); تبحث الدالة أعلاه عن قيمة المفتاح key في التخبئة، فإن لم تجدها ترجع القيمة المبدئية default. التحقق من وجود مفتاح في التخبئة: if (Cache::has('key')){ Cache::get('key'); } else { Cache::put('key', $values, 10); } نتحقق في الشفرة أعلاه من وجود قيمة للمفتاح key ونرجعها إن وجدت؛ وإلا نضيف قيمة جديدة للمفتاح في التخبئة. نزع مفتاح من التخبئة: Cache::forget('key'); كما يمكن استخدام الدالة pull التي تبحث عن قيمة في التخبئة، ثم تحذفها بعد الحصول عليها: Cache::pull('key'); يشبه الأمر تنفيذ الدالتين get وforget بالتتالي. توجد طريقة أخرى لحذف محتوى التخبئة قبل انتهاء المدة المحددة له بتنفيذ أمر artisan التالي: php artisan cache:clear الدالة المساعدة cache يحتوي إطار العمل Laravel على الكثير من دوال PHP المساعدة؛ بعضها مستخدَم في وظائف إطار العمل نفسه. تعمل الدوال المساعدة Helper functions على الرفع من الإنتاجية والابتعاد عن تكرار الشفرات البرمجية بتجميع وظائف اعتيادية وإتاحة الوصول إليها حيث دعت الحاجة. يضيف الإصدار 5.3 دالة مساعدة جديدة باسم cache يمكن استخدامها في أي جزء من المشروع من أجل تسهيل التخاطب مع نظام التخبئة، بدلا من الصّنف Illuminate\Support\Facades\Cache. نحصل على قيمة المتغير key (المفتاح) باستخدام الدالة المساعدة cache على النحو التالي: cache('key'); تكافئ التعليمة أعلاه استخدام الصنف Cache على النحو التالي: Cache::get('key'); يمكن أيضا تمرير مصفوفة بالمفاتيح وقيمها إلى الدالة cache؛ ونحدّد المدة الزمنية التي نريد أن تستغرقها التخبئة: cache(['title' => 'Hsoub Academy'], 5); إن طلبنا في الخمس دقائق القادمة قيمة المفتاح title في الدالة cache فسنجد القيمة Hsoub Academy. نستخدم الدوال الموجودة في الصنف Cache في الدالة المساعدة cache بنفس الطريقة: إضافة مفتاح إلى التخبئة: cache()->put('key', 'value', 10); أو cache(['key' => 'value'],10); البحث عن قيمة المفتاح في التخبئة، وإضافته إليها إن لم يوجد بها: cache()->remember('key', 5, function() { // }); الحصول على قيمة مفتاح من التخبئة ثم حذفه منها بعد ذلك: cache()->pull('key'); حذف مفتاح من التخبئة: cache()->forget('key'); نعيد كتابة الدالة index في المتحكم PostsController بالدالة المساعدة cache بدلا من الصنف Cache: public function index() { $posts = cache()->remember('posts', 5, function() { return Post::all(); }); return response()->json($posts); } يمكن ملاحظة أنك لا تحتاج لاستيرد صنف جديد؛ فالدالة المساعدة متوفرة في جميع المشروع.

ما هو OPcache؟ يحتاج كلّ طلب Request في PHP إلى أن يُحلَّل Parsed، يُترجَم Compiled ثمّ يُنفَّذ Executed؛ لكن في حالات عديدة تؤدّي الطّلبات دائمًا إلى نفس النّتائج، وهو ما يعني أن الخادوم يكرّر في كلّ مرة الخطوات الثّلاث المذكورة دون حاجة لذلك. هنا يأتي دور أدوات التّخزين المؤقَّت للشّيفرة العمليّة Opcode (اختصار ل Operation code، وهو ناتج التّحليل ثمّ التّرجمة أي الصّيغة الّتي يُنفَّذ بها الطّلب)، ومن بينها OPcache. يتلخَّص عمل OPcache في الاحتفاظ بالشيفرة العمليّة في ذاكرة الوصول العشوائي RAM وتنفيذها - عند إعادة الطّلب - من الذّاكرة مباشرةً دون الحاجة للمرور بخطوتَيْ التّحليل والتّرجمة؛ وهو ما يعني اختصار الخطوات والتّقليل من حِمل العمل، غير الضّروريّ، على الخادوم. نفترض في هذا الدّرس وجود حزم LAMP مثبَّتة ومضبوطة على خادومك. تفعيل OPcache تأتي أداة OPcache مضمَّنةً في الإصدار 5.5 من PHP. الأمر التّالي يُظهر إصدار PHP المستخدَم: php -v عندي مثلًا: PHP 5.5.9-1ubuntu4.9 (cli) (built: Apr 17 2015 11:44:57) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies لاحظ السّطر الأخير: with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies يخبرنا هذا السّطر أن OPache مُثبَّت؛ وأنّ الإصدار المستخدَم هو 7.0.3. إذا اتّبعت خطوات كيف تُثبِّت وتؤمِّن phpMyAdmin على Ubuntu 14.04 فستجد أنّ OPcache مُفعَّل. للتّأكّد ننشئ ملفّ info.php (راجِع الدّرس السّابق) ثمّ ندخل إلى العنوان http://domain_or_ip/info.php حيث domain_or_ip نطاق أو عنوان IP الخادوم. في صفحة معلومات الخادوم نبحث عن بعض التّفاصيل. يُمكن ملاحظة أنّ ملفّ إعداد خادوم الويب المستخدَم هو etc/php5/apache2/php.ini/ وأنّ خادوم الويب يبحث عن ملفّات إعداد إضافيّة في المجلَّد etc/php5/apache2/conf.d/؛ تظهر ملفّات الإعداد الموجودة في هذا المجلّد ضمن خانة Additional .ini files parsed، ومن بينها الملفّ etc/php5/apache2/conf.d/05-opcache.ini/. يتحكّم هذا الملفّ في إعداد OPcache كما سنرى. إذا نزلنا أسفل الصّفحة فسنجد فقرات خاصّة ب OPcache: ما يهمّنا الآن من هذه الفقرة هو السّطر الأوّل: Opcode Caching Up and Running أي أنّ التّخزين المؤقَّت مُفعَّل ويعمل. إعداد OPcache توجد خيّارات عديدة لضبط آليّة عمل OPcache. سنتعرّض في هذه الفقرة لأهمّها. يقدّم توثيق PHP قائمة بجميع الخيّارات الموجودة. 1- حجم ذاكرة التّخزين المؤقّت تُحدّد تعليمة opcache.memory_consumption حجم الذّاكرة المخصَّصة لاستخدام OPcache، حيثُ تُخزّن الشيفرة العمليّة لسكربتات PHP. تُضاف هذه التّعليمة إلى ملفّ إعداد OPcache الموجد على المسار etc/php5/apache2/conf.d/05-opcache.ini/. نفتح الملفّ للتّحرير: sudo nano /etc/php5/apache2/conf.d/05-opcache.ini محتوى الملفّ: ; configuration for php ZendOpcache module ; priority=05 zend_extension=opcache.so ملحوظة: لتعطيل OPcache أضف علامة ; أما سطر zend_extension=opcache.so؛ ثمّ أعد تشغيل خادوم ويب Apache. ستلاحظ أنّ صفحة المعلومات لم تعد تظهر البيانات المتعلّقة ب Zend OPcache. نُضيف تعليمة opcache.memory_consumption ونحدّد قيمتها، علمًا أنّ القيمة الافتراضيّة هي 64MB. مثلًا، التّعليمة التّاليّة تحدّد حجم ذاكرة التّخزين المؤقّت ب128 ميغا بايت: opcache.memory_consumption=128 ينصح التّوثيق الرّسمي لOPcache بإعطاء قيمة 128 لهذه التّعليمة، إلّا أنّ الأمر يعتمد على قدرات خادومك ونوعيّة وعدد التّطبيقات والخدمات العاملة عليه. 2- الحدّ الأقصى لعدد الملفّات المُخزّنة تُتيح تعليمة opcache.max_accelerated_file تحديد عدد أقصى للملفّات المحتفظ بها في ذاكرة التّخزين المؤقَّت. القيمة المنصوح بها هي 4000: opcache.max_accelerated_files=4000 3- المدّة اللّازمة للتّحقّق من وجود تغيير على برنامج مُخزَّن في الذّاكرة تُحدّد تعليمة opcache.revalidate_freq مدّة زمنيّة (بالثّانيّة) يُتحقّق بعد انقضائها من وجود تغييرات على الملفّ المخزّن في ذاكرة الوصول العشوائيّ؛ إذا كان الاختبار إيجابيًّا، أي حدث تغيير، فإنّ الملفّ يُعاد تحليله وترجمته قبل أن يُخزّن من جديد. يُنصَح بقيمة 60 لهذه التّعليمة: opcache.revalidate_freq=60 ملحوظة: إضافة علامة ; في بداية سطر يعني تجاهلَه. في هذه الحالة، إذا كان السّطر يحوي تعليمة فلن تؤخَذ في الحسبان. يظهر الملفّ الآن بالمحتوى التّالي: ; configuration for php ZendOpcache module ; priority=05 zend_extension=opcache.so opcache.memory_consumption=128 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 لم يتبقّ إلا إعادة تشغيل خادوم الويب لتفعيل الخيّارات: sudo service apache2 restart ملحوظة: يمكن التّأكّد من عبر صفحة info.php حيث تظهر قيمة الخيّارات أعلاه في خانات بنفس أسماء الخيّارات. خاتمة يُساعد استخدام أداة OPcache في تحسين أداء الخادوم بشكل ملحوظ والاستفادة القصوى من موارد الجهاز. حاول - بحذر - تجربة إعدادات مختلفة وتفحّص تأثيراتها على الأداء حتى تجد الإعداد الأكثر مناسبةً لبيئة عملك. إذا أردت مواصلة التّحسين فدرس كيفيّة تثبيت وإعداد الذّاكرة المُخبّئة (Memcache) على Ubuntu خطوة جيّدة في هذا المجال.

Redis عبارة عن نظام تخزين مؤقّت cache بنمط مفتاح-قيمة key-value مفتوح المصدر. إن كنت ترغب في استخدام Redis على بيئة الإنتاج الخاصة بك، فإن نسخ بياناتك على خادومين على الأقل يُعتبر من بين أفضل الممارسات (best practices)، تتيح الوفرة الاسترداد في حالة فشل البيئة، ما يُعتبر مهمّا عند نمو قاعدة مستخدمي تطبيقك. بنهاية هذا الدرس، سنضبط خادومي Redis كالتالي: خادوم Redis للمتبوع/السيد (master server) خادوم Redis للتّابع (slave server) سنشرح كذلك كيفيّة الانتقال إلى خادوم التّابع وضبطه كسيّدِِ مؤقّت. لك كامل الحريّة في ضبط أكثر من خادوم واحد خاص بالتابع. هذا الدرس يركز على ضبط عنقود تابع ومتبوع خاص بـredis، لتعلم المزيد عن Redis بشكل عام واستخدامه الأساسي كقاعدة بيانات، ألق نظرة على هذا الدرس. المتطلبات في حين سيعمل هذا على إصدارات أقدم وتوزيعات لينكس أخرى، لكن ننصح باستعمال نظام أوبنتو 14.04. سنعتمد على: نظام أوبنتو Ubuntu 14.04 LTS. خادومين، بأي حجم تريد، واحد متبوع وآخر أو أكثر للتّوابع. ادخل إلى خواديمك عبر SSH مع مستخدم غير جدري مع صلاحيّات sudo كما هو مبيّن في الإعداد الابتدائي لخادوم أوبنتو 14.04 . الخطوة الأولى: تثبيت Redis سنبدأ مع الخادوم الذي سيستضيف المتبوع/السّيّد، وأول خطوة هي تثبيت Redis. أولا نحتاج إلى إضافة مستودع Redis الخاص بـ Chris Lea (كما جرت عليه العادة، توخ الحذر عند إضافة مستودعات طرف ثالث، نستخدم هذا المستودع لأن صاحبه حسنُ السمعة): sudo add-apt-repository ppa:chris-lea/redis-server اضغط ENTER لقبول المستودع. شغل الأمر التالي لتحديث الحزم: sudo apt-get update ثبت خادوم Redis: sudo apt-get update تأكد أنّ Redis مُشغل وقيد التنفيذ: redis-benchmark -q -n 1000 -c 10 -P 5 الأمر أعلاه يخبر بأننا نريد تشغيل الأمر redis-benchmark في وضع صامت، مع 1000 طلبات إجماليّة، 10 اتصالات موازية، و 5 طلبات أنابيب. للمزيد من المعلومات عن هذا الأمر، شغّل الأمر redis-benchmark –help على الطرفيّة لتظهر لك معلومات وأمثلة حول الأمر. بعد انتهاء العمليّة، يجب أن ترى مُخرجات تبدو كالتالي: PING_INLINE: 166666.67 requests per second PING_BULK: 249999.98 requests per second SET: 249999.98 requests per second GET: 499999.97 requests per second INCR: 333333.34 requests per second LPUSH: 499999.97 requests per second LPOP: 499999.97 requests per second SADD: 499999.97 requests per second SPOP: 499999.97 requests per second LPUSH (needed to benchmark LRANGE): 499999.97 requests per second LRANGE_100 (first 100 elements): 111111.12 requests per second LRANGE_300 (first 300 elements): 27777.78 requests per second LRANGE_500 (first 450 elements): 8333.33 requests per second LRANGE_600 (first 600 elements): 6369.43 requests per second MSET (10 keys): 142857.14 requests per second الخطوة الثانية: ضبط Redis المتبوع الآن بما أن Redis قيد التنفيذ على العنقود المتكون من الخادومين، يجب علينا تعديل ملفات الإعدادات. كما سنرى، هناك اختلافات طفيفة بين ضبط الخادوم المتبوع والتابع. لنبدأ أولا مع المتبوع master. افتح الملف etc/redis/redis.conf/ باستخدام محرر النصوص المُفضّل لديك: sudo nano /etc/redis/redis.conf وعدّل الأسطر التّالية: ضع قيمة معقولة لمؤقّت الإبقاء على قيد الحياة KeepAlive للـTCP: tcp-keepalive 60 اجعل الخادوم متاحا للجميع على الويب بجعل هذا السّطر كتعليق (أو بحذفه): #bind 127.0.0.1 بحكم طبيعة Redis وسرعاتها العاليّة قد ينفذ مهاجم هجوم القوة الغاشمة Brute force على كلمة المرور. لذلك ننصح إزالة تعليق سطر requirepass وإضافة كلمة مرور معقّدة (أو من الأفضل أن تكون جملة مرور معقدة): requirepass your_redis_master_password على حسب سيناريو استخدامك، قد ترغب في تعديل السّطر التالي أو لا. لغرض هذا الدرس ، نفترض أن حذف أي مفتاح key deletion ممنوع. قم بإزالة التعليق عن هذا السّطر واضبطه كالتالي: maxmemory-policy noeviction أخيرا، سنقوم بالتعديلات التاليّة، وهي مطلوبة للنسخ الاحتياطي للبيانات. أزل التعليق/أو اضبط هذه الأسطر كالتالي: appendonly yes appendfilename redis-staging-ao.aof احفظ التغييرات. أعد تشغيل خدمة Redis لإعادة تحميل تعديلات الضبط التي قمنا بها. sudo service redis-server restart إذا أردت، يُمكنك إضافة بعض المحتوى إلى قاعدة بيانات المتبوع من خلال اتباع قسم أوامر Redis في هذا الدرس. حتى نتمكن من معرفة كيفية نسخه إلى الخادوم التابع. الآن وبعد أن جهزنا خادوم المتبوع أو السيّد، لننتقل إلى خادوم التابع. الخطوة الثالثة: إعداد Redis التابع نحتاج للقيام ببعض التعديلات التي ستسمح لخادوم التابع بالاتّصال مع المتبوع: افتح الملف etc/redis/redis.conf/ بمحررك المُفضل: sudo nano /etc/redis/redis.conf عدّل الأسطر التالية، بعض الإعدادات ستكون تماما مثل الإعدادات الخاصة بالمتبوع. اجعل الخادوم متاحا للجميع على الويب بتحويل هذا السطر إلى تعليق (عبر إضافة # إلى بدايته): #bind 127.0.0.1 يحتاج التابع كذلك إلى كلمة مرور لنستطيع إعطاء الأوامر له (مثل INFO). أزل التعليق عن هذا السطر وضع كلمة سر للخادوم: requirepass your_redis_slave_password أزل التعليق عن هذا السطر وضع عنوان IP الخاص بالمتبوع، متبوعا برقم المنفذ المضبوط على الخادوم. افتراضيّا يكون الرقم 6379 هو رقم المنفذ: SLAVEOF your_redis_master_ip 6379 تأكد من تغيير your_redis_master_ip إلى عنوان IP الخاص بالمتبوع. احفظ الآن هذه التغييرات، واخرج من الملف. ومن ثم، أعد تشغيل الخدمة كما فعلنا مع خادوم المتبوع: sudo service redis-server restart هذا الأمر سيعيد ضبط Redis وسيحمل الملفات التي عدّلناها. اتصل بـredis: redis-cli -h 127.0.0.1 -p 6379 استوثق بكلمة المرور الخاصة بالتابع: AUTH your_redis_slave_password لقد شغّلنا الآن عنقود Redis يعمل كتابع ومتبوع، مع ضبط كل من الخادومين بشكل صحيح. الخطوة الرابعة: تحقق من نسخ التابع-المتبوع سيسمح لنا اختبار هذا التّنصيب فهم كيفية تصرف خوادم Redis بشكل أفضل، عندما نرغب في بداية برمجة الحماية من الفشل. ما سنفعله الآن هو التحقق من أن الإعدادات تعمل بشكل صحيح، وأن المتبوع يتواصل مع التابع بشكل صحيح. أولا، نتصل بـredis عبر الطرفيّة، على خادوم المتبوع: اتّصل أولا بالنموذج المحليّ، مع استعمال المنفذ الافتراضي 6379. إذا كنت قد غيّرت المنفذ، فغير الأمر بما يناسب: redis-cli -h 127.0.0.1 -p 6379 الآن، استوثق مع Redis باستعمال كلمة المرور التي وضعتها عند ضبط المتبوع: AUTH your_redis_master_password يجب عليك أن تحصل على OK كمُخرج. الآن، كل ما عليك فعله هو تنفيذ الأمر: INFO سترى كلّ ما تحتاج معرفته عن خادوم المتبوع. ما يهمنا هو القسم Replication# والذي يجب أن تبدو كالمخرجات التاليّة: . . . # Replication role:master connected_slaves:1 slave0:ip=111.111.111.222,port=6379,state=online,offset=407,lag=1 master_repl_offset:407 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:406 . . . لاحظ سطر connected_slaves:1، الذي يخبرنا بأن نموذج التابع يتواصل مع الخادوم المتبوع. كما يُمكنك ملاحظة أنّنا حصلنا على عنوان IP الخاص بالتابع، وكذلك المنفذ، الحالة، ومعلومات أخرى. الآن لنلق نظرة على قسم Replication# في الخادوم الخاص بالتابع، العمليّة نفسها التي قمنا بها مع المتبوع، ادخل إلى Redis، طبق الأمر INFO، وانظر إلى المُخرجات: . . . # Replication role:slave master_host:111.111.111.111 master_port:6379 master_link_status:up master_last_io_seconds_ago:3 master_sync_in_progress:0 slave_repl_offset:1401 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 . . . يُمكننا ملاحظة أن هذا الخادوم يقوم بدور التابع، وأنه يتواصل مع خادوم Redis المتبوع، ولا يملك أي توابع خاصة به. الخطوة الخامسة: التبديل إلى التابع بناء هذه الهندسة يعني أننا نريد التعامل مع الأخطاء والفشل بطريقة يُمكننا التأكد بها من سلامة البيانات وفي أقل وقت توقف ممكن لتطبيقنا. يُمكن لأي تابع أن يرتقي ليصبح متبوعا. أولا، لنختبر التبديل بشكل يدوي. على خادوم التابع، يجب أن نتصل مع نموذج Redis: redis-cli -h 127.0.0.1 -p 6379 الآن قم بالاستيثاق مع Redis باستخدام كلمة المرور التي استخدمتها عند ضبط التابع. AUTH your_redis_slave_password قم بإنهاء دور التابع: SLAVEOF NO ONE يجب الحصول على OK كمُخرج. الآن، نفذ الأمر: INFO قسم Replication# في الرد يجب أن يبدو كالمخرجات التاليّة: . . . # Replication role:master connected_slaves:0 master_repl_offset:1737 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 . . . كما هو متوقع، فقد تحول التابع إلى متبوع، وهو الآن جاهز لقبول اتّصالات من خوادم أخرى (إذا كانت موجودة). يُمكننا استعماله كمخزن نسخ احتيّاطي مؤقّت أثناء إصلاح الأخطاء في المتبوع الأصلي. إذا كنت تمتلك عدة توابع مُعتمدة على المتبوع الرئيسي، فسيتوجب عليك توجيههم إلى المتبوع الجديد. يُمكن القيّام بذلك بسهولة، بالخطوات التاليّة التي يجب تطبيقها في حال كُشِف عن أيّ أخطاء. من التطبيق، أرسل جميع الطلبات لـredis إلى خادوم تابع. على هذا التابع، نفّذ الأمر SLAVEOF NO ONE. منذ النسخة 1.0.0 من Redis هذا الأمر يُخبر التابع بالتوقف عن نسخ البيانات، والبداية في التصرف كخادوم متبوع. على جميع التابعين المتبقّين (إذا كانوا موجودين)، تشغيل الأمر SLAVEOF hostname port سيوجههم للتوقف عن النسخ من المتبوع القديم، وتجاهل البيانات، والبداية في النسخ من المتبوع الجديد. تأكد من تغيير hostname و port بالمعلومات المناسبة من المتبوع الجديد. بعد حل المشكلة، قد يرجع المتبوع القديم كمتبوع رئيسي، إذا كانت الإعدادات الخاصّة بك تتطلّب ذلك. هناك العديد من الطرق الممكنة لتنفيذ الخطوات أعلاه. ومع ذلك، الأمر يعود لك لتنفيذ أي حل تراه ملائما لبيئتك، وتأكد من اختبارها قبل أن يحدث أي فشل حقيقي. الخطوة السادسة: إعادة الاتصال بالمتبوع الأصلي لنرجع الاتصال بالمتبوع الأصلي. على الخادوم التابع ادخل إلى Redis وشغل الأمر التالي: SLAVEOF your_redis_master_ip 6379 تأكد من تغيير your_redis_master_ip إلى عنوان IP الخاص بالمتبوع إذا قمت بتشغيل الأمر INFO مجددا، يجب أن تلاحظ أنّنا عدنا إلى الإعدادات الأصليّة. في الختام لقد قمنا بإعداد بيئة مكونة من خادومين بنجاح، واحد يتصرف كمتبوع Redis والآخر ينسخ البيانات كتابع. بهذه الطريقة، إذا كان خادوم المتبوع يعاني من أي أخطاء أو فقد بياناتنا علي، فقد تعلمنا كيفية تبديل تابع ليصبح متبوعا كاحتياط إلى حين إصلاح المشكلة. الخطوات التالية تتعلق ببرمجة إجراء الحماية من الخطأ التلقائي، أو ضمان اتصالات آمنة بين جميع خوادمك باستعمال حلول VPN مثل OpenVPN أو Tinc، اختبار الإجراءات والسكربتات للتحقق من صحة إعداداتك. إضافة إلى ذلك، يجب عليك اتخاذ احتياطات عند نشر مثل هذه لإعدادات على بيئات الإنتاج. يجب أن تدرس توثيق Redis ويجب أن تفهم جيدا أي من نماذج الأمان هي الملائمة لتطبيقك. نستعمل عادة Redis كمَخزن للجلسة، وما يحتويه من معلومات قد يكون ذا قيمة لمهاجم ما. الممارسة الشائعة هي أن تمتلك هذه الخواديم إمكانية وصول فقط عبر شبكة خاصة private network. هذه نقطة بداية بسيطة عن كيفية بناء مخزن بيانات خاص بك؛ وليس درسا شاملا عن ضبط Redis لاستخدام هندسة تابع-متبوع. إذا كان هناك أي شيء كنت ترغب في تغطيّته في هذا الدرس، اترك تعليقات أسفله، ولمزيد من المعلومات عن هذا الموضوع، فإن قسم أسئلة DevOps بالأكاديمية تعتبر أماكن جيّدة لتبدأ منها. ترجمة -وبتصرّف- للمقال How To Configure a Redis Cluster on Ubuntu 14.04 لصاحبه Florin Dobre.

إن Squid هو خادوم تخزين وسيط للويب (web proxy cache server) الذي يوفر خدمات الوساطة والتخزين لبروتوكول نقل النص الفائق (HTTP)، وبروتوكول نقل الملفات (FTP)، وغيرهما من بروتوكولات الشبكة الشهيرة؛ يمكن أن يدعم Squid التخزين والوساطة لطلبات طبقة المقابس الآمنة (SSL) وتخزين طلبيات DNS؛ ويدعم Squid أيضًا بروتوكولات تخزين مخبأ مختلفة، مثل بروتوكول تخزين الإنترنت (Internet Cache Protocol اختصارًا ICP)، وبروتوكول تخزين النص الفائق (Hyper Text Caching Protocol اختصارًا HTCP)، وبروتوكول تخزين مصفوفة التوجيه (Cache Array Routing Protocol اختصارًا CARP)، وبروتوكول تنسيق تخزين الويب (Web Cache Coordination Protocol اختصارًا WCCP). إن الخادوم الوسيط Squid هو حل ممتاز لاحتياجاتٍ كثيرةً للوساطة أو التخزين المؤقت، والتوسع من مكتب فرعي إلى شبكة الشركة الكبيرة وذلك بتوفير آليات مراقبة وتحكم في الوصول للمعاملات المهمة باستخدام بروتوكول إدارة الشبكة المبسط (Simple Network Management Protocol اختصارًا SNMP). عند اختيار حاسوب ليعمل كخادوم Squid، فتأكد أنه مضبوط مع كمية كبيرة من الذاكرة الفيزيائية، حيث يستخدم Squid التخزين في الذاكرة لزيادة الأداء. التثبيتأدخِل الأمر الآتي في الطرفية لتثبيت خادوم Squid: sudo apt-get install squid3الضبطيُضبَط Squid بتعديل التعليمات الموجودة ضمن ملف الضبط ‎/etc/squid3/squid.conf؛ الأمثلة الآتية تعرض بعض التعليمات التي يمكن تعديلها لتغيير سلوك خادوم Squid؛ للمزيد من التفاصيل المعمَّقة حول Squid، فانظر إلى قسم المصادر. تنويه: قبل تعديل ملف الضبط، تأكد أنك ستُنشِئ نسخةً من الملف الأصلي وتحميها من الكتابة كي تحصل على الإعدادات الافتراضية كمرجعٍ لك، أو أن تعيد استخدامها وقت الحاجة. انسخ الملف ‎/etc/squid/squid.conf واحمهِ من الكتابة بإدخال الأوامر الآتية في الطرفية: sudo cp /etc/squid3/squid.conf /etc/squid3/squid.conf.original sudo chmod a-w /etc/squid3/squid.conf.originalلضبط خادوم Squid لكي يستمع إلى منفذ TCP ذو الرقم 8888 بدلًا من منفذ TCP الافتراضي 3128، فعدِّل التعليمة http_port كما يلي: http_port 8888عدِّل التعليمة visible_hostname لكي تعطي خادوم Squid اسم مضيف خاص به؛ هذا الاسم لا يفترض أن يكون نفس اسم المضيف للحاسوب؛ ضُبِطَ في هذا المثال إلى weezie: visible_hostname weezieباستخدام التحكم في الوصول الخاص بخادوم Squid، ربما تضبط استخدام خدمات الإنترنت التي يكون فيها Squid وسيطًا لتتوفر للمستخدمين الذي يملكون عناوين IP معيّنة؛ ففي هذا المثال، سنسمح بالوصول لمستخدمي الشبكة الفرعية 192.168.42.0/24 فقط: أضف ما يلي إلى نهاية قسم ACL من ملف ضبط ‎/etc/squid3/squid.conf: acl fortytwo_network src 192.168.42.0/24ثم أضف ما يلي إلى بداية قسم http_access في ملف ‎/etc/squid3/squid.conf: http_access allow fortytwo_networkباستخدام ميزات التحكم بالوصول الممتازة التي يوفرها Squid؛ فربما تضبط استخدام خدمات الإنترنت التي يكون فيها Squid وسيطًا كي تتوفر فقط أثناء ساعات العمل العادية؛ على سبيل المثال، سنحاكي وصول الموظفين خلال ساعات العمل من 9:00AM إلى 5:00PM ومن الاثنين إلى الجمعة، الذين يستخدمون الشبكة الفرعية 10.1.42.0/42: أضف ما يلي إلى نهاية قسم ACL في ملف ‎/etc/squid3/squid.conf: acl biz_network src 10.1.42.0/24 acl biz_hours time M T W T F 9:00-17:00ثم أضف ما يلي إلى أعلى قسم http_access في ملف ‎/etc/squid3/squid.conf: http_access allow biz_network biz_hoursملاحظة: بعد عمل تغيرات إلى ملف الضبط ‎/etc/squid3/squid.conf، فاحفظ الملف ثم أعد تشغيل خادوم Squid لكي تأخذ التغيرات مجراها بإدخال الأمر الآتي في الطرفية: sudo service squid3 restartمصادرموقع Squid.صفحة ويكي أوبنتو «Squid».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Squid - Proxy Server.