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

Redis عبارة عن مخزن يعتمد على مفتاح وقيمته ويُعرف بمرونته، وأدائه، ودعمه العديد من اللغات. يوضح هذا المقال كيفية تثبيت وإعداد وتأمين Redis على خادم أوبونتو 18.04. المتطلبات ستحتاج إلى الدخول إلى خادم أوبونتو 18.04 والذي لا يملك صلاحيات مستخدم مسؤول ويملك صلاحيات sudo. بالإضافة إلى جدار حماية معد. يمكنك إعداد ذلك من خلال مقال التهيئة الأولية لِخادم أوبونتو. للبدء سجل دخولك إلى خادم أوبونتو 18.04 باستخدام مستخدم sudo وليس مستخدم مسؤول. خطوة 1 - تثبيت وإعداد Redis للحصول على أحدث إصدار من Redis، سنستخدم الأمر apt لتثبيته من متجر أوبونتو الرسمي. حدِّث ذاكرة التخزين المؤقتة لحزمة apt وثبت Redis باستخدام الأمرين التاليين: $ sudo apt update $ sudo apt install redis-server تنفيذ هذان الأمران سيؤدي إلى تنزيلRedis وتثبيته بالإضافة إلى تثبيت كل الأشياء المتعلقة به. بعد ذلك، يوجد إعداد مهم يجب تغييره في ملف إعداد Redis والذي وُلد تلقائيا أثناء التثبيت. افتح هذا الملف بأي محرر تفضله: $ sudo nano /etc/redis/redis.conf ابحث عن supervised في الملف. تتيح لك هذه التعليمة تعريف init في النظام لإضافة Redis كخدمة، مما يتيح لك تحكمًا أفضل بعملياته. تعليمة supervised تكون معطلة no بشكل افتراضي. غيِّر قيمة no إلى systemd؛ ذلك لأنك تستخدم أوبونتو المعتمد على نظام "systemd init". الملف ‎/etc/redis/redis.conf: . . . # If you run Redis from upstart or systemd, Redis can interact with your # supervision tree. Options: # supervised no - no supervision interaction # supervised upstart - signal upstart by putting Redis into SIGSTOP mode # supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET # supervised auto - detect upstart or systemd method based on # UPSTART_JOB or NOTIFY_SOCKET environment variables # Note: these supervision methods only signal "process is ready." # They do not enable continuous liveness pings back to your supervisor. supervised systemd . . . حتى الآن هذا هو التعديل الوحيد الذي نحتاج القيام به في ملف إعداد Redis. احفظ الملف واغلقه بعد تعديله. ثم أعد تشغيل خدمة Redis لتصبح التغييرات التي أجريتها على الملف سارية المفعول. $ sudo systemctl restart redis.service وبهذا تكون قد أعددت Redis، لكن قبل استخدامة يجب التأكد من أنه يعمل بالطريقة الصحيحة. خطوة 2 - اختبار Redis يفضل التأكد من صحة عمل أي برنامج جديد قبل تغيير أي من إعداداته. في هذه الخطوة سنتعرف على بعض الطرق للتأكد من ذلك. نبدأ بالتأكد من أن خدمة Redis تعمل: $ sudo systemctl status redis ستظهر مخرجات مشابهة لما يلي في حال كان Redis يعمل بدون أي أخطاء: المخرجات: ● redis-server.service - Advanced key-value store Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2018-06-27 18:48:52 UTC; 12s ago Docs: http://redis.io/documentation, man:redis-server(1) Process: 2421 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS) Process: 2424 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS) Main PID: 2445 (redis-server) Tasks: 4 (limit: 4704) CGroup: /system.slice/redis-server.service └─2445 /usr/bin/redis-server 127.0.0.1:6379 . . . يمكنك رؤية أن Redis مُفعَّل وقيد التشغيل، ما يعني أنه معد كي يبدأ التشغيل مع بدء تشغيل الخادم. ملاحظة: هذا الإعداد مستحسن في أغلب حالات استخدام Redis. إن كنت تفضل تشغيل Redis يدويا في كل مرة تحتاج إليه. يمكنك القيام بذلك باستخدام الأمر: $ sudo systemctl disable redis لاختبار صحة أداء Redis، اتصل بالخادم باستخدام سطر أوامر العميل: $ redis-cli في الشاشة التالية، اختبر الاتصال باستخدام أمر ping: 127.0.0.1:6379> ping المخرجات: PONG تأكد هذه المخرجات أن اتصال الخادم مفعل. بعد ذلك، تأكد من إمكانية إعداد المفاتيح باستخدام الأمر: 127.0.0.1:6379> set test "It's working!" المخرجات: OK استرجِع القيمة باستخدام الأمر: 127.0.0.1:6379> get test ستتمكن من استرجاع القيمة التي أدخلتها في حال كان كل شيء يعمل بشكل صحيح: المخرجات: "It's working!" بعد تأكدك من إمكانية استرجاع القيمة، أغلق شاشة تنفيذ أوامر Redis: 127.0.0.1:6379> exit كاختبار أخير لفحص ما إن كان Redis قادرا على الاستمرار حتى بعد إبقافة أو إعادة تشغيله. لتطبيق هذا الاختبار نبدأ بإعادة تشغيل Redis: $ sudo systemctl restart redis اتصل بشاشة أوامر عميل Redis مرة أخرى وتأكد من بقاء القيمة التي خزنتها: $ redis-cli 127.0.0.1:6379> get test يجب أن تظل القيمة المخزنة متاحة: المخرجات: "It's working!" أخرج مجددَا بعد انتهائك: 127.0.0.1:6379> exit وبذلك، يكون Redis مثبتَا ويعمل بشكل صحيح وجاهز للاستخدام. بالرغم من ذلك، ما تزال بعض إعداداته الافتراضية غير آمنة وتوفر بعض الفرص للأشخاص المخترقون للهجوم على الخادم وبياناته. تشرح باقي الخطوات في هذا المقال بعض الطرق لتقليل هذه الثغرات الأمنية كما ذكر في موقع Redis الرسمي. هذه الخطوات اختيارية وسيستمر Redis بالعمل حتى لو لم تنفذها، لكن يفضل أن تكمل هذه الخطوات لتقوية أمن نظامك. خطوة 3 - الربط مع المضيف المحلي (localhost) Redis متاح تلقائيا عبر المضيف المحلي، لكن إن كنت قد ثبتت Redis بطريقة أخرى فربما تكون قد حدَّثت ملف الإعداد الخاص ب Redis الأمر الذي يتيح اتصالات Redis من أي مكان. هذا الأمر غير آمن كالربط بالمضيف المحلي. لتصحيح الأمر، افتح ملف تكوين Redis لتعديله: sudo nano /etc/redis/redis.conf إذهب إلى السطر التالي وتأكد من إلغاء تعليقه (احذِف # إن وجدت): الملف /etc/redis/redis.conf: bind 127.0.0.1 ::1 احفظ الملف واغلقه عند الانتهاء (اضغط على CTRL + X, Y, ثم ENTER). أعد تشغيل الخدمة للتأكد من قراءة النظام للتغييرات: $ sudo systemctl restart redis للتأكد من تأثير هذه التغييرات، نفِّذ أمر netstat التالي: $ sudo netstat -lnp | grep redis المخرجات: tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 14222/redis-server tcp 0 0 ::1:6379 :::* LISTEN 14222/redis-server توضح هذه المخرجات أن برنامج خادم Redis مرتبط بالمضيف المحلي (127.0.0.1). مما يدل على انعكاس التغيير الذي أجريته على ملف التكوين. إن رأيت عنوان بروتوكول إنترنت آخر (مثل 0.0.0.0) فتأكد من إلغاء تعليق السطر المطلوب وأعد تشغيل خدمة Redis مجددَا. الآن وبعد أن أصبح Redis مربوطا بالمضيف المحلي فقط سيصبح من الصعب على جهات الاختراق تقديم الطلبات أو الوصول إلى الخادم. مع ذلك لا يزال Redis غير معد لِطلب المصادقة من المستخدمين قبل القيام بأي تغيير على إعداداته أو البيانات التي يحتفظ بها. لمعالجة هذا، يتيح لك Redis طلب تأكيد هوية من المستخدمين باستخدام كلمة مرور قبل إحداث ي تغيير وذلك باستخدام الأمر (redis-cli). خطوة 4 - إعداد كلمة مرور Redis يتيح لك إعداد كلمة مرور Redis تفعيل إحدى ميزات الحماية المدمجة فيه — الأمر auth يطلب من المستخدمين إثبات الهوية للوصول إلى قاعدة البيانات. يتم تكوين كلمة المرور مباشرة في ملف تكوين Redis "/etc/redis/redis.conf", لذلك؛ افتح الملف مجددا باستخدام محرِّرك المفضل: $ sudo nano /etc/redis/redis.conf انتقل إلى جزء "SECURITY" وابحث عن السطر التالي: الملف ‎/etc/redis/redis.conf: # requirepass foobared ألغِ تعليق هذا السطر بِإزالة "#" وغير "foobared" إلى كلمة مرور أكثر أمانًا. ملاحظة: يوجد تحذير معلق فوق الموجه "requirepass" في ملف "redis.conf": # Warning: since Redis is pretty fast an outside user can try up to # 150k passwords per second against a good box. This means that you should # use a very strong password otherwise it will be very easy to break. # لذلك، من المهم تحديد كلمة مرور طويلة. يمكنك استخدام الأمر "openssl" ِلتوليد كلمة مرور تلقائيا بدلا من القيام بذلك يدويا كما في المثال التالي. وذلك بتمرير مخرجات الأمر الأول إلى أمر "openssl" الثاني. سيزيل الأمر أي أسطر فارغة تم توليدها من الأمر الأول: $ openssl rand 60 | openssl base64 -A ستكون المخرجات مشابهة لما يلي: RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE بعد نسخ ولصق المخرجات لتكون هي القيمة الجديدة ل "requirepass": /etc/redis/redis.conf requirepass RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE بعد إضافة كلمة المرور، احفظ وأغلق الملف ثم أعد تشغيل Redis: $ sudo systemctl restart redis.service لِاختبار من عمل كلمة المرور، أدخل إلى سطر أوامر Redis: $ redis-cli الأوامر التالية تستخدم لاختبار ما إن كانت كلمة المرور تعمل أم لا. يحاول الأمر الأول إضافة مفتاح إلى قيمة قبل المصادقة: 127.0.0.1:6379> set key1 10 لن يتنفذ الأمر لعدم المصادقة وسيرجع Redis خطأ: المخرجات: (error) NOAUTH Authentication required. يقوم الأمر التالي بالمصادقة باستخدام كلمة المرور المحددة في ملف التكوين: 127.0.0.1:6379> auth your_redis_password يُأكد Redis المصادقة: المخرجات: ok بعد ذلك، سينجح الأمر السابق: 127.0.0.1:6379> set key1 10 المخرجات: ok الأمر "get key1" يطلب من Redis قيمة المفتاح الجديدة. 127.0.0.1:6379> get key1 المخرجات: ok يمكنك إغلاق "redis-cli" بعد تأكدك من أنه يمكنك تنفيذ أوامر عميل Redis: 127.0.0.1:6379> quit لاحقا، ستتعلم كيفية إعادة تسمية أوامر Redis والتي إن تم إدخالها بالخطأ أو من خلال جهة غير مُخَوًّلًة سيسبب الكثير من الأضرار لجهازك. خطوة 5 - إعادة تسمية الأوامر المهمة تتضمن ميزة الحماية الأخرى المدمجة في Redis إعادة تسمية بعض الأوامر التي تعتبر خطرة أو إلغاء تفعيلها. يمكن أن تستخدم بعض هذه الأوامر بواسطة مستخدمون غير مخولين بالدخول لإعادة إعداد، أو تدمير أو حذف بياناتك. سيتم إعادة تسمية الأوامر بنفس الجزء الذي تم تعديل كلمة المرور منه "SECURITY" من ملف "/etc/redis/redis.conf" بعض الأوامر المهمة والتي قد تكون ذات خطورة هي: FLUSHDB FLUSHALL KEYS PEXPIRE DEL CONFIG SHUTDOWN BGREWRITEAOF BGSAVE SAVE SPOP SREM RENAME DEBUG هذه القائمة ليست شاملة، لكن إعادة تسمية أو تعطيل هذه القائمة يعتبر بداية جيدة لتعزيز أمان خادم Redis. يعتمد إعادة تسمية أو تعطيل الأوامر على احتياجك لها لموقعك. إن كنت تعلم أنك لن تستخدم أمرًا ما؛ فيمكنك تعطيله. أو إعادة تسميته إن ان ذات أهمية لك. افتح ملف تكوين Redis لتفعيل أو تعطيل أي أمر: $ sudo nano /etc/redis/redis.conf تحذير: توضح الخطوات التالية كيفية تعطيل أو إعادة تسمية كأمثلة. يجب أن تختار تعطيل أو إعادة تسمية الأوامر التي تريدها فقط. يمكنك مراجعة قائمة الأوامر كاملة ومعرفة كيف يمكن أن تستخدم بطريقة ضارة على redis.io/commands. لِتعطيل أمر ما، أعد تسميته إلى نص فارغ (يشار إلى النص الفارغ بِعلامتي تنصيص "") كما في الأسفل: الملف ‎/etc/redis/redis.conf: . . . # It is also possible to completely kill a command by renaming it into # an empty string: # rename-command FLUSHDB "" rename-command FLUSHALL "" rename-command DEBUG "" . . . لإعادة تسمية أمر ما، اعطه اسما آخر كما في المثال بالأسفل. يجب أن تكون الأسماء صعبة التخمين للآخرين ولكن سهلة بالنسبة لك كي تتذكرها لاحقًا: الملف ‎/etc/redis/redis.conf: . . . # rename-command CONFIG "" rename-command SHUTDOWN SHUTDOWN_MENOT rename-command CONFIG ASC12_CONFIG . . . احفظ التغييرات وأغلق الملف. أعد تشغيل Redis بعد إعادة تسمية الأمر لتطبيق التغييرات: $ sudo systemctl restart redis.service أدخل إلى سطر أوامر Redis لاختبار الأمر الجديد: $ redis-cli قم بالمصادقة: 127.0.0.1:6379> auth your_redis_password المخرجات: OK لنفترض أنك أعدت تسمية الأمر "CONFIG" إلى "ASC12_CONFIG" كما في المثال السابق. أولا حاول استخدام الأمر الأصلي "CONFIG". يجب أن يفشل تنفيذ الأمر لأنك أعدت تسميته: 127.0.0.1:6379> config get requirepass المخرجات: (error) ERR unknown command 'config' سينجح الأمر عند استخدام الاسم الجديد. لا يهم حالة الأحرف. 127.0.0.1:6379> asc12_config get requirepass المخرجات: 1) "requirepass" 2) "your_redis_password" وأخيرا يمكنك الخروج من "redis-cli". 127.0.0.1:6379> exit ملاحظة: عندما تُعيد تشغيل سطر أوامر Redis، سيطلب منك إعادة المصادقة أو سيظهر لك الخطأ التالي عند محاولتك لتنفيذ أمر ما: المخرجات: NOAUTH Authentication required. ملاحظة: بالنسبة لإعادة تسمية الأوامر؛ يوجد جملة تحذيرية في نهاية جزء SECURITY في الملف "‎/etc/redis/redis.conf" والتي تنص على: Please note that changing the name of commands that are logged into the AOF file or transmitted to slaves may cause problems. يعني هذا التحذير أن إعادة تسمية الأوامر المحفوظة في ملف AOF أو المنقولة في ملف فرعي قد يتسبب ببعض المشاكل. ملاحظة: يستخدم Redis المصطلحات “master” و “slave” بينما يفضل DigitalOcean استخدام البدائل “primary” و “secondary”. ولتجنب الخلط بين المصطلحات فإننا نستخدم المصطلحات التي يستخدمها Redis في ملفات التوثيق الخاصة به. يعني ذلك أنه إن كانت الأوامر التي تمت إعادة تسميتها ليست في ملف AOF أو إن كانت فيه لكن لم يتم نقلها إلى مجلد فرعي فلن يكون هناك أية مشاكل. لذلك يجب أن تتذكر هذا عند قيامك بإعادة تسمية أمر ما. أفضل وقت لإعادة تسمية الأوامر هو عند عدم استخدامك ل AOF أو بعد التثبيت مباشرة قبل استخدام Redis. عند استخدامك ل AOF وتعاملك مع التثبيت بنوع master-slave، خذ بعين الاعتبار هذه الإجابة من صفحة المشروع على GitHub: الإجابة: تُسجَّل الأوامر في AOF ثم تُكرر إلى المجلدات الفرعية بنفس الطريقة التي تم إرسالها، لذلك إن شغَّلت AOF على نسخة لا تحتوي الأوامر التي تمت إعادة اسميتها ستواجه بعض التعارضات ولن تنفذ بعض الأوامر. لذلك فإن أفضل طريقة لإعادة تسمية لأوامر في مثل هذه الحالة هي عبر التأكد من أن الأوامر التي تمت إعادة تسميتها مطبقة على جميع النسخ في طريقة التثبيت باستخدام master-slave. الخلاصة ختاما، في هذا المقال، لقد ثبتته وإعداد Redis، وتأكدت من صحة عمل Redis، واستخدمت ميزات الحماية المدمجة فيه والتي تقلل عدد الثغرات الممكنة للهجوم من قبل المخترقين. تذكر أنه بمجرد تسجيل أحدهم الدخول إلى الخادم، فمن السهل عليه التحايل على إعدادت حماية Redis التي قمنا بها. لذلك فإن أهم ميزة أمان على الخادم هي جدار الحماية (الذي أعددته إن كنت تابعت المقال السابق حول التهيئة الأولية لخادم أوبونتو 18.04) الذي يجعل الاختراق صعبًا جدًا. ترجمة -وبتصرف- للمقال How To Install and Secure Redis on Ubuntu 18.04 لصاحبه الكاتب Mark Drake.

إنّ السجلّات logs أمر ضروري لحل مشاكل تثبيت Redis، وقد تتساءل عن مكان تواجد هذه السجلّات أو عن المكان الذي يقوم Redis بتخزين السجلّات فيه على نظام Ubuntu. عند تثبيت Redis بالطريقة الافتراضية باستخدام apt-get على Ubuntu 14.04 فسيقوم Redis بإنشاء سجلّاته في المسار var/log/redis/redis-server.log/. لاستعراض آخر 10 أسطر في سجلّات redis، نقوم بتنفيذ الأمر التالي: $ sudo tail /var/log/redis/redis-server.log لاحظ في الأمر السابق استخدامنا لـ sudo نظرًا لأننا نحتاج لصلاحيات أعلى لنتمكن من قراءة سجلّات redis. أما في حال تثبيت Redis من ملفّات الشيفرة المصدرية على Ubuntu 14.04، فسيقوم بتخزين السجلّات في المسار var/log/redis_6379.log/. ولاستعراض آخر 10 أسطر نستخدم الأمر: $ sudo tail /var/log/redis_6379.log التحقق من السجلات المؤرشفة يقوم Redis بأرشفة ملفّات السجلّات القديمة، ولاستعراض قائمة الملفّات المتوفرة ننفذ الأمر: $ ls /var/log/redis فسيظهر الخرج بما يشبه التالي: redis-server.log redis-server.log.1.gz ولاستعراض آخر 10 أسطر من سجل مؤرشف نحتاج أولًا أن نقوم بفك ضغطه، ونستخدم gunzip لفك ضغط الملفات من نوع gz، كما في الأمر التالي: $ sudo gunzip /var/log/redis/redis-server.log.1.gz انتبه: يقوم gunzip بفك ضغط ملفات gz وحذف الملف الأساسي المضغوط، لذا إن كنت تريد المحافظة على الأرشيف المضغوط توفيرًا للمساحة واستعراض محتويات الملف المضغوط بشكل مؤقت فقم بنسخه إلى المسار المؤقت tmp/ وقم بفك ضغطه هناك. ومن ثم ننفذ الأمر tail مع الملف الذي نحصل عليه: $ sudo tail /var/log/redis/redis-server.log.1 البحث عن ملفات السجلات باستخدام أمر find إن لم تكن ملفّات السجلّات في المسارات المذكورة السابقة، فمن الممكن تنفيذ عملية بحث واسعة باستخدام الأمر find في المسار var/logs/ على الشكل التالي: $ find /var/log/* -name *redis* أو البحث في كامل النظام. قد تأخذ عملية البحث بهذا الشكل بعض الوقت إن كنت تملك الكثير من الملفّات، وقد تظهر لك بعض التحذيرات حول عدم كفاية الصلاحيات للبحث في بعض المسارات، وهذا أمر طبيعي، بالرغم من أنّنا نتجنب أسوأ مسارين للبحث فيهما وهما proc/ و sys/ باستعمال المعامل prune-. سيظهر تنفيذ الأمر التالي جميع الملفّات التي تحوي على كلمة redis في اسمه، بما في ذلك ملفات التثبيت: $ find / -path /sys -prune -o -path /proc -prune -o -name *redis* تحديد مسار تخزين السجلات في ملف إعدادات Redis نستطيع تغيير مسار تخزين ملفات السجلّات وذلك بتغيير المسار في ملف الإعدادات redis.conf، ويتواجد الملف غالبًا في المسار etc/redis/redis.conf/ نقوم بفتح الملف بمحرر نصوص مثل nano أو أي محرر آخر تفضّله: $ sudo nano /etc/redis/redis.conf ونبحث عن السطر الذي يبدأ بـ logfile ونقوم بتغيير المسار الذي يظهر فيه إلى المسار الجديد، كما بالإمكان تغيير اسم ملف السجل الأساسي: logfile /var/log/redis/redis-server.log التحقق من سجلات systemd باستخدام journalctl في Ubuntu 15.04 والإصدارات الأحدث منه قد نحتاج أن نتحقق من سجلّات Redis التي يقوم بالتقاطها سجل النظام systemd (يستخدم نظام Ubuntu 15.04 والأحدث منه سجل النظام systemd، بينما يستخدم Ubuntu 14.04 سجّلات Upstart بشكل افتراضي). الخلاصة لتتعلّم المزيد حول إعدادات Redis، يرجى قراءة هذا المقال حول إعداد عنقود Redis cluster. ترجمة -وبتصرّف- للمقال How To Find Redis Logs on Ubuntu لصاحبته Sharon Campbell.

سنتطرق في هذا الدّرس إلى كيفية تطبيق حماية أساسيّة لخادوم Redis. على الرغم من هذا، عليك تذكر بأن Redis قد صُمّم أساسا للاستخدام من طرف مستخدمين موثوقين على بيئة موثوقة، بدون أي مميزات أمنيّة خاصة به. لفهم هذه النّقطة أكثر إليك اقتباسا من الموقع الرسمي لـredis: بشكل عام، Redis ليس مُحسّنا لحماية قصوى بل لأداء عالي وبساطة فائقة. الأداء والبساطة بلا حماية بمثابة وصفة لكارثة. حتى مميّزات الحماية القليلة لدى Redis ليست ممتازة، وتشمل كلمة مرور بسيطة غير مُشفّرة، إعادة تسميّة الأوامر وتعطيلها. وتفتقر إلى نظام حقيقي للتحكم بالولوج. على الرغم من هذا، فإن ضبط هذه الخصائص الأمنيّة يبقى خطوة كبيرة إلى الأمام وأفضل من ترك قاعدة بياناتك بدون حماية. ستقرأ في هذا الدّرس كيفيّة ضبط الخصائص الأمنيّة القليلة التي يمتلكها Redis، وبعض الخصائص الأمنية الأخرى للنظام ما سيزيد من نسبة الحماية لخادوم Redis مُستقل على Ubuntu 14.04. ننوّه إلى أن هذا الدرس لا يتحدث عن حالات وجود كل من خادوم Redis وتطبيقات العملاء على استضافات مختلفة أو مراكز بيانات مختلفة. أو الحالات التي يجب على الاتصال بـ Redis أن يقطع شبكات غير آمنة أو غير موثوقة تتطلب نوعا مختلفا من الإعداد، مثل ضبط SSL proxy أو VPN بين خواديم Redis ، إضافة إلى الخطوات المذكورة هنا. المتطلبات ستحتاج في هذا الدّرس: خادوم Ubuntu مع مستخدم sudo مُضَاف، انظر درس الإعداد الابتدائي لخادوم أوبنتو 14.04 جدار ناري iptables معدّ باستخدام الدرس كيف تنفذ نموذجا للجدار الناري باستعمال Iptables إلى غاية خطوة "تحديث nameservers" (إذا لم تقم بإعداد جزء الخادوم nameserver فالـAPT لن يعمل). Redis مُثبت وقيد التنفيذ باستعمال الخطوات في الموضحة في الدرس كيفية تنصيب واستخدام Redis على أوبنتو. الخطوة الأولى، التأكد من أن Redis قيد التشغيل أولاً ادخل إلى الخادوم باستعمال SSH: ssh username@server-ip-address username: اسم المستخدم server-ip-address: عنوان IP الخاص بالخادوم للتأكد من أنّ Redis قيد التنفيذ، استعمل سطر الأوامر الخاص ب Redis .يُستعمل الأمر redis-cli للوصول إلى سطر أوامر Redis. redis-cli إذا سبق وأن أعددت كلمة مرور لـ Redis، فيجب عليك الاستيثاق بالأمر auth بعد الاتّصال: auth كلمة_المرور المخرج سيكون كلمة OK اختبر خادوم قاعدة البيانات: ping الرّد: PONG اُخرج: quit الخطوة الثانية، حماية الخادوم بـاستخدام Iptables إذا اتّبعت المُتطلّبات من أجل ضبط Iptables، فلك كامل الحريّة في تخطّي هذه الخطوة، أو يُمكنك القيام بذلك الآن. Redis مجرّد تطبيق يُنفّذ على خادومك، ولأنه لا يملك أي خصائص أمنيّة خاصة، فإنّ أول خطوة لحمايته حقيقة تكمن في حماية الخادوم الذي يُشغل منه. في حالة خادوم موجّه للعامة كخادومك Ubuntu 14.04، فإن ضبط جدار ناريّ كما هو مبيّن في درس Iptables يُعتبر الخطوة الأولى لذلك. اتّبع ذلك الرّابط واضبط جدارا ناريّا الآن. إذا طبّقت أحكام الجدار النّاري باستعمال ذلك الدّرس، فلن تحتاج لإضافة قاعدة أخرى لـ Redis، افتراضيّاً، إن أي مرور traffic يُمنَع إلّا عند السّماح له صراحةً. وبما أن خادوم Redis افتراضيّا يستمع على واجهة الاسترجاع (loopback (127.0.0.1 أو localhost، فلا يجب القلق حول المرور عبر المنفذ الافتراضي. إذا كنت تحتاج للسّماح لعنوان IP للوصول خصّيصا لـ Redis، يُمكنك التحقق من العنوان الذي يستمع منه Redis، وعلى أي منفذ باستخدام أمر grep لمُخرجات الأمر netstat. العمود الرّابع 127.0.0.1:6379 يطلعنا على عنوان IP والمنفذ المرتبطين بـ Redis: sudo netstat -plunt | grep -i redis المخرجات: tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 8562/redis-server 1 تأكّد من أن هذا العنوان مسموح له في الجدار النّاري. للمزيد من المعلومات عن كيفيّة إضافة الأحكام، اطّلع رجاء على درس أساسيّات Iptables. الخطوة الثالثة، الربط إلى المضيف المحلي localhost افتراضيًّا، يُمكن الوصول إلى خادوم Redis من المضيف المحليّ، على أي حال، إذا اتّبعت درس ضبط Redis على خادوم متبوع/سيّد فقد حدّثت ملفّ الإعدادات للسّماح للاتّصالات من أي مكان. وهذا ليس آمنا كالربط إلى المُضيف المحليّ. افتح ملفّ إعدادات Redis للتّعديل: sudo nano /etc/redis/redis.conf ابحث عن هذا السّطر وتأكّد من أنه ليس على شكل تعليق (احذف الرّمز # إذا كان موجودا): bind 127.0.0.1 سنستمرّ في استعمال هذا الملفّ، لذلك أبقه مفتوحا الآن. الخطوة الرابعة، ضبط كلمة مرور لـ Redis إذا ثبتت Redis باتّباع درس كيف تضبط خواديم Redis متعددة على أوبنتو 14.04 فيجب عليك أن تكون قد ضبطت كلمة مرور مُسبقا، يُمكنك أن تضع كلمة مرور أكثر أمانا باتّباع هذا القسم الآن، وهذه الخطوات تعرض كيفية وضع كلمة مرور لخادوم قاعدة البيانات. ضبط كلمة مرور لـ Redis يفعّل إحدى ميزتي الحماية المُضمّنة في Redis، وهو الأمر auth، الذي يطلُب من العملاء الاستيثاق للوصول إلى قاعدة البيانات. تُضبَطُ كلمة المرور مُباشرة في ملف الإعدادات etc/redis/redis.conf/ الذي يجب أن تكون قد فتحته منذ الخطوة الماضيّة. اذهب عن قسم SECURITY وابحث عن سطر مُعلّق بالرمز # كالتّالي: # requirepass foobared أزل التّعليق عن السّطر بحذف الرمز #، وغيّر foobared إلى كلمة مرور قويّة وطويلة. عوضاً عن الإتيان بكلمة مرور من عندك، يمكنك استعمال أداة مثل apg و pwgen لتوليد واحدة. إذا لم تكن ترغب بتثبيت أداة فقط لتوليد كلمة مرور، يُمكنك استخدام السطر التّالي. لتوليد كلمة مرور مُختلفة عن هذا المثال غير القيمة بداخل علامتي التنصيص: echo "hsoub-academy" | sha256sum المُخرج سيبدو كالتّالي: e118c2b8fa805fbd0a6af458ab7df9fea14881b87c2e793b4a2192cda30bf8d5 لكنّ كلمة المرور المولّدة لن تكون منطوقة، وهي قويّة وطويلة وهو تماما المطلوب لحماية Redis. بعد نسخ ولصق مُخرج هذا الأمر كقيمة جديدة لـ requirepass، يجب أن تكون كالتّالي: requirepass 960c3dac4fa81b4204779fd16ad7c954f95942876b9c4fb1a255667a9dbe389d إذا كنت تُفضّلُ كلمة مرور أقصر، استخدم مُخرج الأمر التالي عوضا عنها. غيّر القيمة بين علامتي التنصيص لكي لا تولّد نفس كلمة المرور: echo "hsoub-academy" | sha1sum المخرج سيكون أقصر هذه المرّة: 773a12cfe8616ff740258f8843c567f32227ac0f بعد ضبط كلمة المرور، احفظ الملفّ وأعد تشغيل Redis : sudo service redis-server restart لاختبار عمل كلمة المرور، حاول الوصول إلى سطر أوامر Redis : redis-cli السطر التالي يعرض سلسلة من الأوامر المُستعملة لاختبار ما إذا كانت كلمة المرور تعمل أو لا، الأمر الأول يُحاول إعطاء قيمة لمفتاح قبل القيام بالاستيثاق: set key1 10 الأمر لن يعمل، لذلك فإنك سترى خطأ في المخرجات: (error) NOAUTH Authentication required. الأمر الثاني يقوم بالاستيثاق بكلمة المرور التي وضعناها في ملفّ إعدادات Redis. auth your_redis_password سيُوافق Redis في الحال: OK بعد هذا، تنجح إعادة تنفيذ الأمر السّابق. set key1 10 المُخرج: OK الأمر get key1 يطلب من Redis قيمة المفتاح الجديد: get key1 المُخرج: “10” الأمر الأخير يقوم بإنهاء سطر الأوامر redis-cli. ويمكنك أيضاً استخدام exit: quit تالياّ، سننظر إلى إعادة تسميّة أوامر Redis. الخطوة الخامسة، إعادة تسمية الأوامر الخطرة الخاصيّة الأمنيّة الأخرى المبنيّة داخل Redis تُخوّل لك إعادة تسميّة أو تعطيل أوامر معيّنة والتّي تُعتبر أوامر خطيرة. عند تشغيل مستخدمين غير مُخولين لأوامر معينّة فقد تُستخدم هذه الأوامر لإعادة ضبط، أو تدمير أو حذف بياناتك. ومثل كلمة مرور الاستيثاق،فإن إعادة تسمية الأوامر أو تعطيلها تتم في نفس قسم SECURITY من الملفّ etc/redis/redis.conf/. بعض الأوامر المعروف أنها خطيرة هي: FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME و DEBUG وهذه القائمة ليست شاملة، لكنّ إعادة تسميّتها أو تعطيلها كلّها يُعتبر نقطة بداية جيّدة. تعطيل أو إعادة تسميّة أمر يعتمد على مدى استعمالك للأمر، فمثلاً إذا كنت تعلم أنّك لن تستعمل أبدا أمرا يُمكن أن يُستَغلّ سلبيّاً، فمن المستحسن أن تُعطّله، عدا ذلك فمن الأفضل إعادة التّسميّة. لتشغيل أو تعطيل أمر ما، افتح ملفّ الإعدادات للتحرير مرة أخرى: sudo nano /etc/redis/redis.conf هذه بعض الأمثلة فقط. ويجب عليك أن تعيد تسميّة أو تعطّل الأوامر بما يُناسبك. يُمكنك التحقق من الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands. لتعطيل أو إيقاف أمر ما، فقط أعد تسميّتها إلى قيمة فارغة كما هو مبيّن أسفله: # It is also possible to completely kill a command by renaming it into # an empty string: # rename-command FLUSHDB "" rename-command FLUSHALL "" rename-command DEBUG "" وعند إعادة تسميّة أمر ما، عيّن اسما آخر كقيمة، كما في الأمثلة أسفله. الأوامر المعاد تسميّتها يجب أن تكون صعبة التخمين، وفي نفس الوقت سهلة التذكر بالنسبة لك.ولا تجعلها صعبة عليك. rename-command CONFIG "" rename-command SHUTDOWN SHUTDOWN_MENOT rename-command CONFIG ASC12_CONFIG بعد إعادة التّسميّة، طبّق التعديلات بإعادة تشغيل Redis: sudo service redis-server restart لاختبار الأمر الجديد، ادخل إلى سطر أوامر Redis: redis-cli بعد ذلك، على افتراض بأنّك قمت بإعادة تسميّة الأمر CONFIG إلى ASC12_CONFIG، المُخرج التّالي يوضح كيفيّة التأكد من أنّ الأمر الجديد يعمل. بعد الاستيثاق: auth your_redis_password المُخرج: OK يجب أن تكون مُحاولة استخدام الأمر config باسمه الأصلي فاشلة، لأنّنا بالطبع قمنا بإعادة تسميّتها: config get requirepass المُخرج": (error) ERR unknown command 'config' مناداة الأمر باسمه الجديد سيعمل (وهو غير حسّاس لحالة الأحرف): asc12_config get requirepass المُخرج: 1) "requirepass" 2) "your_redis_password" أخيرا، يمكنك الخروج من redis-cli: exit ملاحظة: إذا كنت تستخدم مسبقا سطر الأوامر Redis ثم أعدت تشغيل Redis، سيتوجب عليك إعادة الاستيثاق. إن لم تقوم بذلك، ستحصل على هذا الخطأ عند كتابة أمر ما: NOAUTH Authentication required. على الرغم من إعادة تسميّتك للأوامر، فهناك جملة تحذيريّة في آخر قسم SECURITY على ملفّ etc/redis/redis.conf/ تقول: هذا يعني أنّه إذا لم يكن الأمر المعاد تسميّته داخل ملفّ AOF، أو إذا كان موجودا لكنّ ملفّ AOF لم يُحَلْ إلى التّوابع، فلا يجب أن يكون هناك أي مُشكلة. لذلك تذكّر عند محاولة تغيير أسماء الأوامر، أفضل وقت لإعادة تسميّة أمر هو عند عدم استخدام AOF، أو مباشرة بعد التثبيت أي قبل نشر التطبيق المُستعمِل لـ Redis. عندما تستخدم AOF وعند التّعامل مع نظام تابع-متبوع، ضع في بالك هذه الإجابة من صفحة المسائل في المشروع على Github. الاقتباس التّالي هو جواب على سؤال الكاتب: لذلك فإن أفضل طريقة للتعامل مع إعادة التسمية في حالات كهذه هي أن تتأكّد من أنّ إعادة تسميّة الأوامر مطبّقة في جميع الخوادم في أنظمة تابع-متبوع. الخطوة السادسة، ضبط مجلد البيانات وصلاحيات المستخدم للملفات في هذه الخطوة، سوف نعرض بعض تعديلات المالك والصلاحيّات التّي يُمكنك القيّام لها لزيّادة حماية Redis. يتمثّل هذا في التأكد من أنّ المُستخدم الذي يحتاج إلى الوصول إلى Redis فقط يملك صلاحيّات قراءة البيانات. هذا المُستخدم افتراضيّا هو المُستخدم redis. يُمكنك التحقق من هذا باستخدام أداة grep مع الأمر ls لرؤية معلومات عن المُجلّد الأب لمجلّد بيانات Redis. الأمر والمُخرجات أسفله. ls -l /var/lib | grep redis المُخرج: drwxr-xr-x 2 redis redis 4096 Aug 6 09:32 redis يُمكنك ملاحظة بأن مجلّد بيانات Redis مملوك من طرف المُستخدم Redis، مع وصول ثانوي للمجموعة redis. وهذا أمر جيّد. الأمر السيئ هو صلاحيّات الوصول إلى المُجلّد، أي 755. للتأكد من أن المُستخدم redis هو فقط من يمتلك حقّ الوصول إلى المجلد ومُحتوياته، غيّر الصلاحية إلى 700: sudo chmod 700 /var/lib/redis الصلاحيّة الأخرى التّي عليك تغييرها هي الخاصّة بملفّ إعدادات Redis. يمتلك افتراضيّا صلاحيّة 644 ومملوك للمُستخدم الجذر root، مع مالك ثانوي يتمثّل في مجموعة الجذر root group: ls -l /etc/redis/redis.conf المُخرج: -rw-r--r-- 1 root root 30176 Jan 14 2014 /etc/redis/redis.conf هذه الصّلاحيّة (644) تعني مقروء من الكل، والتي تعتبر فكرة سيّئة لأن ذلك الملف يحتوي على كلمة المرور غير المُشفرة التّي وضعناها في الخطوة الرّابعة. نحتاج إلى تغيير المالك والصّلاحيّات. يجبُ أن تكون مملوكة للمُستخدم redis مع مجموعة الجذر كمالك ثانوي، لفعل ذلك، شغّل الأمر التّالي: sudo chown redis:root /etc/redis/redis.conf بعد ذلك غيّر المالك لكي يتمكّن مالك الملفّ فقط من قراءته أو/و الكتابة عليه: sudo chmod 600 /etc/redis/redis.conf يُمكنك التحقّق من المالك الجديد والصّلاحيّات باستخدام الأمر: ls -l /etc/redis/redis.conf المُخرج: total 40 -rw------- 1 redis root 29716 Sep 22 18:32 /etc/redis/redis.conf في الأخير، أعد تشغيل Redis: sudo service redis-server restart خاتمة تذكّر بأنه عند دخول أي شخص إلى خادومك، فمن السّهل التحايل على خصائص Redis الأمنيّة التي قمنا بضبطها. لذلك فإنّ أكثر خاصيّة أمنيّة هي التي تجعل من تجاوز هذا الحاجز صعبا قدر المُستطاع. أي خاصيّة الجدار النّاري. للتّقدّم بحماية خادومك إلى المستوى التّالي، فعليك ضبط نظام كشف تطفّل مثل OSSEC. إذا كنت تريد حماية تواصل Redis عبر شبكات غير آمنة فعليك توظيف SSL proxy، كما هو منصوح به من مطوّري Redis على دليل حمايةRedis الرسمي. وضبط SSL proxy لحماية تواصل Redis فهو موضوع آخر. لم نتطرّق إلى قائمة شاملة من أوامر Redis بقسم إعادة التّسميّة، لكنّك تستطيع إلقاء نظرة على مجموعة الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands. ترجمة -بتصرّف- للمقال How To Secure Your Redis Installation on Ubuntu 14.04 لصاحبه finid.

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.

تمّ تطوير Redis في عام 2009، وهو مُخزّن بيانات بنمط المفتاح والقيمة (key value)، وهو مفتوح المصدر، ويُقدّم مرونة في الاستخدام، وكما في جميع نمط قواعد البيانات من نوع NoSQL الّتي اتبعها Redis، أمثال Cassandra, CouchDB, MongoDB، فإن Redis يَسمح للمُستخدِم بتخزين كميات ضخمة من البيانات بدون التقيد المفروض بقواعد البيانات العلائقيّة/الارتباطيّة (relational database)، بالإضافة إلى أنّه قد تمّ مُشابهته ومقارنته مع memcache، فيُمكن استخدامه بعناصره الأساسية كنظام تخبئة. إعداد بيئة ومتطلبات Redis قبل الشروع في تنصيب redis، يجب توفّر بعض المُتطلّبات والّتي من شأنها أنّ تجعل من عمليّة التنصيب أكثر سهولة. سيتمّ في البداية تحديث جميع حزم apt-get: sudo apt-get update سيتمّ بعد ذلك تحميل مُترجم (compiler) باستخدام الحزمة build-essential، والّتي من شأنها المساعدة في تنصيب Redis من المصدر: sudo apt-get install build-essential سيتمّ في الخطوة الأخيرة تحميل الأداة tcl الّتي يَعتمد عليها Redis: sudo apt-get install tcl8.5 تنصيب Redis بعد أنّ تمّ تنصيب المُتطلّبات الأساسيّة، فمن المُمكن الآن الشروع وتنصيب redis، ويُمكن تحديد الإصدار المطلوب أو تحميل الإصدار الأخير والذي سيحمل دائمًا الاسم redis-stable: wget http://download.redis.io/redis-stable.tar.gz يجب بعد ذلك فك ضغط الملفّ والانتقال إليه: tar xvzf redis-stable.tar.gz cd redis-stable يجب الآن المُتابعة مع الأمر make: make ولتنصيب Redis على كامل النّظام، فيُمكن إما نسخ ملفاته من المصدر: sudo cp src/redis-server /usr/local/bin/ sudo cp src/redis-cli /usr/local/bin/ أو تنفيذ الأمر التّالي: sudo make install بعد انتهاء عمليّة التنصيب، من المُستحسن تشغيل Redis كحارس (daemon) في خلفيّة النّظام، ولعمل ذلك يأتي Redis بملفّ برمجي (سكريبت) لهذه المُهمّة. يجب الانتقال إلى المسار utils للوصول إلى هذا الملفّ: cd utils ومن ثم تشغيل الملفّ الخاص بتوزيعات Ubuntu/Debian: sudo ./install_server.sh سيَعرض السكريبت بعض الأسئلة لإتمام عمليّة التهيئة، ولكن يُمكن الاعتماد على الإعداد الافتراضي والاكتفاء بالضغط على Enter، وبعد انتهاء عملية التهيئة سيكون خادم Redis يعمل في الخلفيّة (background). يُمكن تنفيذ الأمر التّالي للوصول إلى قاعدة البيانات Redis: redis-cli يُمكن اختبار Redis كالتّالي: $ redis-cli redis 127.0.0.1:6379> ping PONG redis 127.0.0.1:6379> set mykey somevalue OK redis 127.0.0.1:6379> get mykey "somevalue" أوامر Redis يتمّ إضافة بعض المُعطيات إلى سلسلة رموز (string)، والّتي تُعتبر من أبسط أنواع البيانات (datatype)، باستخدام الأمر التّالي: > SET users:SomeOne "job: SomeJob, email:example@example.com, age: some number " OK تمّ في الأمر السابق استخدام الأمر SET متبوعًا بالمُفتاح users:SomeOne، ومن ثمّ القيمة (value)، وهي سلسلة الرموز (string) نفسها. لا تُؤثر النقطتان (:) الموجودة في المُفتاح على الأمر السابق، ولكن من المُمكن الاستفادة منهما في وصف أوضح للمُفتاح المُراد تعيينه. يُمكن استعراض تفاصيل سلسلة الرموز السابقة باستخدام الأمر GET: GET users:SomeOne "job: SomeJob, email:example@example.com, age: some number " المجالات (Ranges) يتمّ تحديد مجال باستخدام مُعاملين والذين سيُمثلان العنصر الأوّل والعنصر الأخير، فالعنصر الأوّل سيُعتبر 0، وإن كان المُعامل الأخير -1، فإن جميع العناصر حتّى نهاية القائمة سيتمّ شملها، فعلى سبيل المثال، إن كانت قائمة تحتوي على ألوان قوس قزح مُرتبة بالترتيب ROYGBV، فيُمكن استعراضها كما في التّالي: > LRANGE ROYGBV 0 3 1) "red" 2) "orange" 3) "yellow" 4) "green" > LRANGE ROYGBV 0 -1 1) "red" 2) "orange" 3) "yellow" 4) "green" 5) "blue" 6) "violet" > LRANGE ROYGBV 3 -1 1) "green" 2) "blue" 3) "violet" انتهاء الصلاحية (Expiration) لا يُعتبر Redis ذو فائدة في تخزين المعلومات فقط، بل يُمكن استخدامه أيضًا في إنهاء صلاحيتها. يُعيّن الوقت اللازم على المُفتاح أنّ يتواجد خلاله إما بالثواني أو باستخدام طابع الوقت الخاصّ يونكس (Unix Time stamp)، ويتحكم الأمر EXPIRE بالمُدّة الّتي يتوجب على المُفتاح التواجد فيها، ويَعرض الأمر TTL الوقت المُتبقي حتّى انتهاء الصلاحيّة. > SET classified:information "Secret Stuff" OK > EXPIRE classified:information 45 (integer) 1 > TTL classified:information (integer) 31 وفي مُحاولة لاستعادة المعلومات بعد انقضاء مدّة الصلاحيّة، ستكون النتيجة هي nil: > GET classified:information (nil) التزايد أو العلاوة (Incrementing) يَملك Redis القدرة على زيادة سلاسل الرموز (strings) في قاعدة بياناته، مع الانتباه أنّه في حال وجود عمليّة جارية في زيادة قيمةٍ ما، فلا يستطيع أمر آخر التدخل والتعديل، هذا الأمر من شأنه أن يجعل من قاعدة البيانات ثابتة وغير شائبة. > SET population 6 OK > INCRBY population 10 (integer) 16 > INCR population (integer) 17 المداولات (Transactions) يملك Redis القدرة على إنجاز المُداولات (transactions)، والّتي يجب أنّ تخضع إلى: تنفيذ الأوامر بالترتيب، ولن يتمّ مقاطعتها خلال العمليّة من قبل طلبات أُخرى. على المُداولات أنّ تُعالج كلها دفعةً واحدة. تبدأ المُداولات بالأمر MULTI وبعد ذلك لتنفيذها يتمّ استخدام الأمر EXEC. سيتمّ الخروج من المُداولة، عند أي مُقاطعة للعمليّة، وسيواجه Redis خطًا سيوقفه من إعادة التشغيل حتّى تنفيذ الأمر edis-check-aof ليتمّ التراجع عن المُداولة الجزئية الّتي تمّت بالفعل قبل حدوث الخطأ وحذفها. سيَتمكّن الخادم بعد ذلك من إعادة التشغيل. > MULTI OK > SET population 6 QUEUED > INCRBY population 10 QUEUED > INCR population QUEUED > EXEC 1) OK 2) (integer) 16 3) (integer) 17 أنواع البيانات في Redis يَملك Redis خمسة أنواع من البيانات: Strings Sets Sorted Sets Lists Hashes سلاسل الرموز (Strings) تُعتبر سلاسل الرموز جوهر وأساس الأنواع في Redis الأوامر التّالية هي الأوامر الشائعة مع سلاسل الرموز: SET: يُعيّن قيمة إلى مُفتاح. GET: يجلب قيمة من مُفتاح. DEL: حذف مُفتاح وقيمته. INCR: زيادة قيمة مُفتاح. INCRBY: زيادة قيمة مُفتاح بقيم مُحدّدة. EXPIRE: الوقت اللازم على المُفتاح التواجد به، ويُعيّن بالثواني. تُستخدم سلاسل الرموز في تخزين الكائنات (objects): > SET newkey "the redis string begins" OK > GET newkey "the redis string begins" المجموعات (Sets) يُمكن الجمع بين سلاسل الرموز (strings)، ولذلك يُمكن استخدام مجموعات Redis، والّتي يُمكن القول عنها أنها مجموعة من سلاسل الرموز غير المُرتبة. بعض الأوامر الشائعة مع المجموعات: SADD: إضافة عنصر أو عناصر إلى مجموعة. SMEMBERS: جلب جميع العناصر المُعيّنة. SINTER: إيجاد تقاطع أكثر من مجموعة. SISMEMBER: التأكّد من وجود قيمة في مجموعة. SRANDMEMBER: جلب عنصر عشوائي. يُستفاد من المجموعات في Redis في العديد من الحالات، ولأن كل عنصر من مجموعة هو فريد، فإن إضافة عنصر إلى المجموعة لا يتطلّب عمليّة “افحص قبل الإضافة”، بدلًا من ذلك، فإن المجموعة ستتأكّد فيما إذا كان العنصر مكرّرًا أم لا، وذلك عند أي تنفيذ للأمر SADD: > SADD colors red (integer) 1 redis 127.0.0.1:6379> SADD colors orange (integer) 1 redis 127.0.0.1:6379> SADD colors yellow (integer) 1 redis 127.0.0.1:6379> SADD colors orange (integer) 0 redis 127.0.0.1:6379> SMEMBERS colors 1) "red" 2) "yellow" 3) "orange" يُستفاد من المجموعات بشكل خاصّ في فحص وضبط عناوين IPs في حال أنها فريدة لزوار صفحة ما، أو مثلًا في استخلاص عناصر بشكل عشوائي بالأمر SRANDMEMBER. المجموعات المرتبة (Sorted Sets) إن المجموعات المُرتبة هي اسمٌ على مُسمّى، فهي مجموعة من سلاسل الرموز (strings) مُرتبطة مع رقم مع ترتيب، وهو بشكلٍ افتراضيّ من الأصغر إلى الأكبر. يَعمل هذا النوع من البيانات بشكل مُلائم جدًا مع المجالات (ranges)، وبسبب التّرتيب الخاصّ به، فإن إضافة وحذف وتحديث القيم تتمّ بسرعة ملحوظة. بعض الأوامر الشائعة مع المجموعات المُرتّبة: ZADD: إضافة عناصر إلى مجموعة مُرتّبة. ZRANGE: عرض عناصر مجموعة مُرتّبة. ZREVRANGE: عرض عناصر مجموعة مُرتّبة بشكل عكسي. ZREM: إزالة عناصر من مجموعة مُرتّبة. يُمكن إنشاء مجموعة مُرتّبة كما في المثال التّالي، وهو لمساحة بعض البلدان، فعلى الرغم من تعيينها بشكل عشوائي، فإن استعراضها يَكون على التّرتيب: > ZADD countries 9 Tuvalu (integer) 1 > ZADD countries 62 Liechtenstein (integer) 1 > ZADD countries .7 Monaco (integer) 1 > ZADD countries .2 VaticanCity (integer) 1 > ZADD countries 107 Seychelles (integer) 1 redis 127.0.0.1:6379> ZRANGE countries 0 -1 1) "VaticanCity" 2) "Monaco" 3) "Tuvalu" 4) "Liechtenstein" 5) "Seychelles" القوائم (Lists) تُعتبر القوائم في Redis مجموعة من القيم المُرتّبة، وبالتّالي فهي عكس المجموعات (Sets)، والّتي هي غير مُرتّبة، فيُمكن إضافة عناصر إلى بداية ونهاية قائمة، حتّى بوجود ملايين العناصر داخل القائمة، وبسرعة كبيرة جدًا. الأوامر الأكثر شيوعًا مع القوائم: LPUSH: إضافة قيمة في بداية قائمة. RPUSH: إضافة قيمة في نهاية قائمة. LPOP: جلب وإزالة العنصر الأوّل في قائمة. LREM: إزالة العناصر من قائمة. LRANGE: جلب مجال من العناصر من قائمة. LTRIM: تعديل قائمة بترك عناصر مُحدّدة من مجال. أمثلة: > RPUSH lunch.provider alice (integer) 1 > RPUSH lunch.provider bob (integer) 2 > RPUSH lunch.provider carol (integer) 3 > RPUSH lunch.provider don (integer) 4 > RPUSH lunch.provider emily (integer) 5 عند الرغبة بالدفع (push) إلى واجهة صف الانتظار (queue)، فمن المُمكن استخدام الأمر LPUSH: LPUSH lunch.provider zoe (integer) 6 يُمكن استخدام الأمر LRANGE لاستعراض عناصر القائمة جميعًا: LRANGE lunch.provider 0 -1 1) "zoe" 2) "alice" 3) "bob" 4) "carol" 5) "don" 6) "emily" تُستخدم القوائم في مُعظم الأحيان لإنشاء خط زمني للأحداث، أو في الحفاظ على مجموعة مُحدودة من العناصر المبعثرات (Hashes) تُعتبر المبَعثرات في Redis من الأدوات المُفيدة في تمثيل الكائنات (objects) ذو العديد من الحقول (fields)، فهي مُعدّة لتخزين عدد هائل من الحقول في حجم صغير، وتستطيع البَعثرة تخزين أكثر من أربعة مليارات من أزواج قيم الحقول (field-value). بعض أوامر البعثرة الأكثر شيوعًا في Redis: HMSET: تعيين قيم بعثرة مُتعدّدة. HSET: تعيين حقل البعثرة بقيمة سلسلة رموز (string). HGET: جلب قيمة حقل البعثرة. HMGET: جلب جميع القيم من حقول البعثرة المعطاة. HGETALL: جلب جميع القيم لبعثرة ما. تُستخدم البَعثرة في وصف حساب المُستخدِم: > HMSET user:1 username someuser password 4bAc0s email someuser@example.com OK > HGETALL user:1 1) "username" 2) "jsmith" 3) "password" 4) "4bAc0s" 5) "email" 6) "jsmith@gmail.com" يتمّ استخدام الأمر HMGET للبحث عن معلومة مُحدّدة، وعرض القيم للحقول المطلوبة فقط. > HMGET user:1 username email 1) "someuser" someuser@example.com الختام انتشر Redis بسرعة كبيرة، واكتسب شهرةً واسعة بين المواقع أمثال: Github, Flickr, Disqus، وغيرها من المواقع، وذلك لتوافقه مع مُعظم لغات البرمجة، فهو بالفعل تقنية مُفيدة يُنصح بالاعتماد عليها وتجربتها. ترجمة -وبتصرّف- للمقال How To Install and Use Redis لصاحبته Etel Sverdlov.

إنّ Redis هي عبارة عن ذاكرة مؤقتة cache بنمط مفتاح-قيمة key-value ومَخزَن في الذاكرة (أي قاعدة بيانات) والتي يمكن نقلها وحفظها بشكل دائم على القرص، سنشرح في هذا الدّرس كيفيّة النّسخ الاحتياطي لقاعدة بيانات Redis على خادوم Ubuntu. يتم حفظ بيانات Redis بشكل افتراضي إلى القرص في ملف rdb.، والذي هو لقطة snapshot لنقطة في الوقت المناسب لمجموعة بيانات Redis لدينا، يتم عمل اللقطة في فواصل مُحدّدة، ويكون هذا رائعًا من أجل النسخ الاحتياطيّة لدينا. المتطلبات الأساسيةسنحتاج لإكمال الخطوات في هذا الدّرس إلى: خادوم Ubuntu.تنصيب redis، تستطيع اتباع الإعداد الرئيسي master في هذا الدّرس لإعداد Redis (بالرغم من أنّه سيعمل بشكل جيّد مع عنقود تابع ومتبوع master-slave cluster).التحقق من أنّ خادوم Redis قيد التشغيل لدينا.إن تمّ تعيين كلمة سر لخادوم Redis -والذي ننصح به بشدّة- يكون ذلك مفيدًا، توجد كلمة السّر في ملف الإعدادات /etc/redis/redis.confالخطوة الأولى – إيجاد دليل بيانات Redisتقوم Redis بتخزين بياناتها إلى دليل على خادومنا، وهو ما نريده من أجل النّسخ الاحتياطي، نحتاج في البداية لمعرفة مكان هذا الدّليل. يوجد دليل قاعدة بيانات Redis في Ubuntu وتوزيعات لينِكس الأخرى في المسار var/lib/redis/، ولكن إن كُنّا ندير خادوم تم تغيير مكان بيانات Redis فيه، نستطيع تحديد مكانه بكتابة ما يلي: sudo locate *rdbوبإمكاننا بشكل بديل إيجاده عن طريق المُحث prompt الذي يُدعى redis-cli، ولفعل هذا نكتب ما يلي: redis-cliإن لم يكن خادوم Redis قيد التشغيل ستكون الاستجابة التي سنتلقاها هي: Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected>وفي هذه الحالة نقوم بتشغيل Redis وإعادة الاتصال باستخدام الأوامر التالية: sudo service redis-server startredis-cliسيتغير مُحث الـ Shell إلى: 127.0.0.1:6379>في الوقت الذي نكون متصلين فيه إلى Redis سيقوم الأمران التاليان بالاستيثاق authenticate معه والحصول على دليل البيانات: 127.0.0.1:6379> auth insert-redis-password-here 127.0.0.1:6379> 127.0.0.1:6379> config get dirيجب أن يكون خَرْج الأمر الأخير هو دليل بيانات Redis لدينا: 1) "dir" 2) "/var/lib/redis"نلاحظ دليل Redis لدينا فإن كان مختلفًا عن الدّليل الظاهر هنا فيجب أن نحرص على استعماله خلال هذا الدّرس. نستطيع الآن الخروج من واجهة سطر الأوامر لقاعدة البيانات: 127.0.0.1:6379> exitنتحقّق من أنّ هذا هو الدّليل الصحيح: ls /var/lib/redisينبغي أن نرى ملف dump.rdb وهو عبارة عن بيانات Redis، إن تمّ تمكين appendonly فسنرى ملف يُدعى appendonly.aof أو حتى أي ملف aof. آخر، والذي يحتوي على سجل لجميع عمليّات الكتابة التي تم تلقّيها بواسطة الخادوم. قم بقراءة هذا المنشور حول استمرار Redis persistence من أجل النقاش حول الاختلافات بين هذين الملفين. بشكل مُبسَّط فإنّ الملف rdb. هو اللقطة الحاليّة، والملف aof. يقوم بحفظ تاريخ Redis، وكلاهما يستحقّان أخذ نسخة احتياطيّة عنهما. سنبدأ فقط بالملف rdb. وننتهي بنسخة احتياطيّة تلقائيّة لكلا الملفين. الخطوة الثانية (اختيارية) – إضافة عينة sample بياناتسنقوم في هذا القسم بإنشاء عيّنة بيانات لتخزينها في قاعدة بيانات Redis، إن كنتَ تملك مٌسبقًا بيانات على خادومك تستطيع النسخ الاحتياطي للمحتوى الموجود حاليًّا. نقوم بتسجيل الدخول من خلال واجهة سطر الأوامر لقاعدة البيانات: redis-cliنقوم بالاستيثاق بكتابة ما يلي: 127.0.0.1:6379> auth insert-redis-password-hereفلنقم بإضافة عيّنة بيانات، يجب أن نتلقّى استجابة OK بعد كل خطوة. 127.0.0.1:6379> SET shapes:triangles "3 sides" 127.0.0.1:6379> 127.0.0.1:6379> SET shapes:squares "4 sides"نتأكّد من أنّه تمّت إضافة البيانات: 127.0.0.1:6379> GET shapes:triangles 127.0.0.1:6379> 127.0.0.1:6379> GET shapes:squaresوهذا هو الخَرْج output الذي يجب أن نحصل عليه: "3 sides" "4 sides"ولفرض هذه التغييرات على الملف var/lib/redis/dump.rdb/ نقوم بحفظهم: 127.0.0.1:6379> saveنستطيع الآن الخروج: 127.0.0.1:6379> exitبإمكاننا الآن إن كُنّا نرغب التّحقّق من محتويات الملف dump، يجب أن يحتوي على بياناتنا ولو أنّها في شكل مناسب للآلة أكثر: sudo cat /var/lib/redis/dump.rdb REDIS0006?shapes:squares4 sidesshapes:triangles3 sides??o????Cالخطوة الثالثة – النسخ الاحتياطي لبيانات Redisحان الوقت الآن لعمل نسخة احتياطيّة بعد أن أصبحنا نعلم مكان تواجد بيانات Redis لدينا، نجد هذا الاقتباس من موقع Redis الرّسمي: إذًا نستطيع النسخ الاحتياطي أو نسخ ملف قاعدة البيانات أثناء تشغيل خادوم Redis، وعلى افتراض أنّنا نريد النسخ الاحتياطي لها إلى دليل داخل الدّليل الرئيسي لدينا فإنّ القيام بالنسخ الاحتياطي بسيط بكتابة ما يلي: sudo cp /var/lib/redis/dump.rdb /home/sammy/redis-backup-001يحفظ Redis المحتوى هنا بشكل دوري، ممّا يعني أنّ الأمر السابق غير مضمون بالنسبة لنا وأنّنا لا نملك أحدث نسخة احتياطيّة حتى الدقيقة الأخيرة إن كان كل ما نقوم به هو تشغيل هذا الأمر، نحتاج لحفظ البيانات الخاصّة بنا أولًا. ومع ذلك إن كان من المقبول فقدان كمية صغيرة من البيانات فإنّ النّسخ الاحتياطي لهذا الملف فقط سيعمل بشكل جيّد. حفظ حالة قاعدة البياناتللحصول على نسخة أحدث بكثير من بيانات Redis فمن الأفضل النفاذ إلى redis-cli، سطر أوامر Redis. نقوم بالاستيثاق كما شرحنا في الخطوة الأولى. ثمّ نكتب الأمر حفظ save كما يلي: 127.0.0.1:6379> saveينبغي أن يكون الخَرْج مُشابِهًا لهذا: OK (1.08s)نخرج من قاعدة البيانات. نستطيع الآن تشغيل الأمر cp السّابق واثقين من أنّ النسّخة الاحتياطيّة هي أحدث نسخة حتى الآن بشكل كامل. بينما يُزوِّدنا الأمر cp بنسخة احتياطيّة مرّة واحدة من قاعدة البيانات، فإنّ الحل الأنسب هو إعداد وظيفة cron تقوم بأتمتة هذه العمليّة، واستخدام أداة تستطيع تنفيذ تحديثات تزايديّة incremental updates وتستعيد البيانات إن احتجنا لذلك. الخطوة الرابعة – إعداد التحديثات التلقائية باستخدام rdiff-backup وCronسنقوم في هذا القسم بإعداد نسخ احتياطي تلقائي يشمل كامل دليل بيانات Redis لدينا، بما في ذلك كلا ملفي البيانات. توجد العديد من أدوات النسخ الاحتياطي التلقائي المتاحة، سنستخدم أداة جديدة وسهلة الاستخدام تُدعى rdiff-backup. إنّ rdiff-backup هي أداة نسخ احتياطي تعمل عبر سطر الأوامر، من المحتمل أنّ rdiff-backup غير مُثبَّتة على خادومك، لذا يجب عليك تثبيتها أولًا: sudo apt-get install -y rdiff-backupنستطيع الآن بعد تثبيتها أن نختبرها بالنسخ الاحتياطي لبيانات Redis لدينا إلى مجلّد في دليلنا الرئيسي، سنفترض في هذا المثال أنّ الدليل الرئيسي لدينا هو home/sammy/. نلاحظ أنّ الدليل الهدف سيتم إنشاؤه من قبل الـ script إن لم يكن موجودًا، أي بمعنى آخر لا نحتاج إنشاءه بأنفسنا. ومع وجود preserve-numerical-ids-- ستكون الملكيّات نفسها للمجلدات المصدر والوجهة. sudo rdiff-backup --preserve-numerical-ids /var/lib/redis /home/sammy/redisوكما وجدنا مع الأمر cp سابقًا فإنّ هذه نسخة احتياطيّة لمرّة واحدة، ولكنّ الذي تغيّر هو أنّنا نقوم الآن بالنسخ الاحتياطي لكامل الدليل var/lib/redis/ وباستخدام rdiff-backup. سنقوم الآن بأتمتة النّسخ الاحتياطي باستخدام cron بحيث تحدث النسخة الاحتياطيّة في وقت مُحدّد، ولإنجاز هذا نفتح crontab النّظام: sudo crontab -e(إن لم تستخدم crontab على هذا الخادوم من قبل قم باختيار مُحرّر النّصوص المفضل لديك عند سؤالك عنه.) نقوم بإضافة المُدخَل entry التالي في نهاية الملف: 0 0 * * * rdiff-backup --preserve-numerical-ids --no-file-statistics /var/lib/redis /home/sammy/redisسيقوم مُدخَل Cron هذا بعمل نسخة احتياطيّة لـ Redis يوميًّا عند منتصف الليل، سيعطّل التحوّل no-file-statistics-- الكتابة إلى الملف file_statistics في الدّليل rdiff-backup-data، والذي يجعل من rdiff-backup يعمل بشكل أسرع أكثر ويستخدم مساحة قرص أقل بقليل. ونستطيع بشكل بديل استخدام هذا المُدخَل للقيام بنسخ احتياطي يومي: @daily rdiff-backup --preserve-numerical-ids --no-file-statistics /var/lib/redis /home/sammy/redisوكما هو مذكور سيتم عمل نسخة احتياطيّة مرّة في اليوم، لذا بإمكانك العودة غدًا من أجل اختباره لآخر مرّة، أو تستطيع بشكل مؤقّت زيادة وتيرة النّسخ الاحتياطي لكي تتأكّد من أنّه يعمل. ولأنّ الملفّات مملوكة من قبل مستخدم النّظام redis نستطيع التحقّق من أنّها في مكانها باستخدام هذا الأمر.(تأكّد من الانتظار إلى أن يتم تحفيز بدء النسخ الاحتياطي): ls -l /home/sammy/redisينبغي أن يبدو الخَرْج مُشابِهًا لما يلي: total 20 -rw-rw---- 1 redis redis 70 Sep 14 13:13 dump.rdb drwx------ 3 root root 12288 Sep 14 13:49 rdiff-backup-data -rw-r----- 1 redis redis 119 Sep 14 13:09 redis-staging-ao.aofنمتلك الآن نُسَخ احتياطيّة يوميّة لبيانات Redis لدينا مُخزَّنة في الدّليل الرئيسي على نفس الخادوم. الخاتمةإنّ النّسخ الاحتياطي لبيانات Redis بالطرق المذكورة في هذا الدّرس جيّد عندما لا نمانع من النّسخ الاحتياطي للبيانات إلى دليل على نفس الخادوم. يبقى النهج الأكثر أمانًا بالطّبع هو النّسخ الاحتياطي إلى جهاز آخر، تستطيع استكشاف المزيد من خيارات النسخ الاحتياطي بقراءة هذا الدّرس حول النُسَخ الاحتياطيّة: كيفية اختيار استراتيجية فعالة للنسخ الاحتياطي للخادوم الخاص الافتراضي VPS. نستطيع استخدام العديد من طرق النّسخ الاحتياطي هذه مع نفس الملفّات في الدّليل var/lib/redi/. ترجمة -وبتصرّف- لـ How To Back Up Your Redis Data on Ubuntu 14.04 لصاحبه finid.

إنّ Redis هو عبارة عن نظام تخزين وذاكرة مؤقتة cache بنمط مفتاح-قيمة key-value مفتوح المصدر، ويتم الإشارة له أيضًا كخادوم بُنية معطيات data structure بسبب دعمه المتقدّم للعديد من أنواع البيانات كالتلبيدات Hashes، اللوائح lists، المجموعات sets والخرائط الثنائيّة Bitmaps من بين الخواديم الأخرى، يدعم أيضًا الحشد clustering والذي يجعل منه مُستخدَمًا عادةً في البيئات ذات التوافر العالي والقابلة للتطوير. سنشاهد في هذا الدّرس كيفيّة تثبيت وإعداد خادوم Redis خارجي لكي يتم استخدامه كمُداوِل للجلسة Session Handler من أجل تطبيق PHP يعمل على Ubuntu. إنّ مُداوِل الجلسة مسؤول عن تخزين واسترجاع البيانات المحفوظة ضمن الجلسات، حيث تستخدم PHP افتراضيًّا الملفّات من أجل هذا، يُمكن استخدام مُداوِل الجلسة الخارجي من أجل إنشاء بيئات PHP قابلة للتطوير خلف مُوازِن الحِمل load balancer، حيث ستتصل جميع عُقَد nodes التّطبيقات إلى خادوم مركزي لتتشارك معلومات الجلسة. المتطلبات الأساسيةسنعمل في هذا الدّرس على خادومين مُنفصلين، ومن الهام من أجل الأداء والأمان أن تتوضّع كلا Droplets الخاصّة بهما في نفس مركز البيانات مع تمكين ربط الشبكات الخاصّة Private networking، وهذا ما سنحتاجه: خادوم ويب PHP يقوم بتشغيل LAMP أو LEMP على Ubuntu – سنقوم بالإشارة لهذا الخادوم بـ web.خادوم Ubuntu آخر حيث سيتم تثبيت Redis – سنقوم بالإشارة لهذا الخادوم بـ redis.سنحتاج نفاذ مناسب عبر SSH إلى كلا الخادومين كمستخدم اعتيادي مع صلاحيّات sudo. نستطيع أيضًا من أجل خادوم Redis استخدام تطبيق Redis بنقرة واحدة والانتقال للخطوة الثانية. الخطوة الأولى – تثبيت خادوم Redisإنّ أول شيء نحتاجه هو الحصول على خادوم Redis يعمل على redis Droplet الخاصّة بنا. سنستخدم مُدير حِزَم Ubuntu الاعتيادي مع مستودع PPA موثوق يتم تزويدنا به بواسطة Chris Lea، وهو ضروري لكي نتأكّد أنّنا نحصل على آخر إصدار مُستَقر من Redis. كنصيحة أمان عامّة ينبغي أن نستخدم PPAs من مصادر موثوقة فقط. نُضيف في البداية مستودع PPA بتنفيذ الأمر التالي: sudo add-apt-repository ppa:chris-lea/redis-serverنضغط Enter للتأكيد. نحتاج الآن لتحديث الذاكرة المؤقتة cache لمدير الحِزَم: sudo apt-get updateفلنقم أخيرًا بتثبيت Redis بتنفيذ الأمر التالي: sudo apt-get updateينبغي الآن أن يكون تم تثبيت Redis على خادومنا، ولاختبار التثبيت نُجرِّب هذا الأمر: redis-cli pingسيقوم هذا الأمر بالاتصال إلى نموذج instance من Redis يعمل على localhost على المنفذ 6379، ويجب أن نتلقّى PONG كاستجابة. الخطوة الثانية – ضبط Redis لكي يقبل اتصالات خارجيةيسمح Redis بالاتصال فقط إلى localhost والذي يعني بشكل أساسي أنّنا نملك النفاذ إليه فقط من داخل الخادوم حيث تمّ تثبيت Redis، نحتاج إلى تغيير هذه الإعدادات للسماح بالاتصالات التي تأتي من خواديم أخرى على نفس الشبكة الخاصّة مثل الخادوم redis. إنّ أول شيء يجب علينا فعله هو معرفة عنوان IP الجهاز Redis على الشبكة الخاصّة، ينبغي تنفيذ الخطوات التالية على الخادوم redis. نقوم بتنفيذ الأمر ifconfig للحصول على معلومات حول واجهات شبكتنا: sudo ifconfigينبغي أن نتلقّى خَرْجًا Output مُشابِهًا لما يلي: eth0 Link encap:Ethernet HWaddr 04:01:63:7e:a4:01 inet addr:188.166.77.33 Bcast:188.166.127.255 Mask:255.255.192.0 inet6 addr: fe80::601:63ff:fe7e:a401/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3497 errors:0 dropped:0 overruns:0 frame:0 TX packets:3554 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4895060 (4.8 MB) TX bytes:619070 (619.0 KB) eth1 Link encap:Ethernet HWaddr 04:01:63:7e:a4:02 inet addr:10.133.14.9 Bcast:10.133.255.255 Mask:255.255.0.0 inet6 addr: fe80::601:63ff:fe7e:a402/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:648 (648.0 B) TX bytes:578 (578.0 B)فلنبحث عن inet_addr المُخصَّص للواجهة eth1، في هذه الحالة نجده 10.133.14.9، وهذا هو عنوان IP الذي سنستخدمه لاحقًا للاتصال إلى الخادوم redis من الخادوم web. نفتح الملف etc/redis/redis.conf/ باستخدام مُحرِّر سطر الأوامر command line editor المُفضَّل لدينا ونبحث عن السّطر الذي يحتوي على التّعريف bind، يجب أن نُضيف عنوان IP للشبكة الخاصّة لدينا إلى هذا السّطر كما يلي: sudo vim /etc/redis/redis.confetc/redis/redis.conf/ bind localhost 10.133.14.9إن وجدنا 127.0.0.1 بدلًا من localhost فليس هناك مشكلة، فقط نضيف عنوان IP الخاص لدينا بعد ما هو موجود. نحتاج الآن لإعادة تشغيل الخدمة Redis لتطبيق التغييرات: sudo service redis-server restartإن قمنا بتثبيت Redis باستخدام تطبيق النقرة الواحدة فسيكون اسم الخدمة redis بدلًا من redis-server. ولإعادة تشغيلها نكتب الأمر: sudo service redis restartبعد هذه التغييرات سيكون أي خادوم داخل نفس الشّبكة الخاصّة قادرًا على الاتصال إلى نموذج Redis. الخطوة الثالثة – تعيين كلمة سر لخادوم Redisلإضافة طبقة أمان إضافيّة إلى تثبيت Redis لدينا فنحن نُشجِّع على تعيين كلمة سر للنفاذ إلى بيانات الخادوم، سنقوم بتحرير نفس ملف الإعدادات الذي قمنا بتحريره في الخطوة السّابقة etc/redis/redis.conf/: sudo vim /etc/redis/redis.confنقوم الآن بإلغاء التّعليق uncomment عن السّطر الذي يحتوي على requirepass ونضع كلمة سر قويّة: etc/redis/redis.conf/ requirepass yourverycomplexpasswordhereنعيد تشغيل خدمة Redis لكي يتم تطبيق التغييرات: sudo service redis-server restart الخطوة الرابعة – اختبار الاتصال إلى Redis والاستيثاق Authenticationلكي نتأكّد من أنّ كافّة التغييرات تعمل كما هو متوقّع نقوم بالاتصال إلى خدمة Redis من داخل الجهاز redis: redis-cli -h 10.133.14.9المخرجة: 10.133.14.9:6379>بالرغم من أنّه ليس من الإجباري هنا تحديد المُعامِل host (بما أنّنا نتصل من localhost)، فقد قمنا بذلك للتأكّد من أنّ خدمة Redis تقبل الاتصالات الموجّهة إلى واجهة الشّبكة الخاصّة. إن كُنّا قد عرّفنا كلمة سر وحاولنا الآن النفاذ إلى البيانات ينبغي أن نتلقّى خطأ AUTH: 10.133.14.9:6379> keys *المخرجة: (error) NOAUTH Authentication required.نحتاج من أجل الاستيثاق أن نقوم فقط بتنفيذ الأمر AUTH مع تزويده بنفس كلمة السّر التي عرّفناها في الملف etc/redis/redis.conf/: 10.133.14.9:6379> AUTH yourverycomplexpasswordhereينبغي أن نتلقّى استجابة OK، والآن إن قمنا بتنفيذ الأمر: 10.133.14.9:6379> keys *يجب أن يكون الخَرْج مُشابِهًا لما يلي: المخرجة: (empty list or set)يعني هذا الخَرْج فقط أنّ خادوم Redis لدينا فارغ، وهو ما كُنّا نتوقّعه تمامًا، حيث أنّ الخادوم web ليس مُعدًّا بعد لاستخدام خادوم Redis هذا كمداوِل للجلسة. فلنحافظ على جلسة SSH هذه مفتوحة ومتّصلة إلى redis-cli بينما نقوم بتنفيذ الخطوات التالية، سنعود إلى المُحِث prompt redis-cli لكي نتحقّق من أنّه يتم تخزين بيانات الجلسة بشكل مناسب، وذلك بعد أن نقوم بالتغييرات الضروريّة للخادوم web. الخطوة الخامسة – تثبيت امتداد Redis Extension على الخادوم webيجب تنفيذ الخطوات التالية على الخادوم web، نحتاج إلى تثبيت الامتداد PHP Redis وإلّا لن تكون PHP قادرة على الاتصال إلى الخادوم Redis. في البداية نقوم بتحديث الذاكرة المؤقتة لمدير الحِزَم بتنفيذ الأمر التالي: sudo apt-get updateنقوم بعدها بتثبيت الحِزمَة php5-redis: sudo apt-get install php5-redisينبغي الآن أن يكون الخادوم web قادرًا على الاتصال إلى Redis. الخطوة السادسة – تعيين Redis كمداول الجلسة الافتراضي على الخادوم webنحتاج الآن لتحرير الملف php.ini على الخادوم web لتغيير مُداوِل الجلسة الافتراضي لـ PHP، يعتمد مسار الملف على استخدامنا LAMP أو LEMP، ففي LAMP على Ubuntu يكون المسار عادةً في etc/php5/apache2/php.ini/، وفي LEMP على Ubuntu يكون المسار عادةً في etc/php5/fpm/php.ini/. إن لم نكن متأكّدين من مسار الملف php.ini نستطيع إيجاده بطريقة سهلة باستخدام الدالّة ()phpinfo، فقط نقوم بوضع الشيفرة code التالية في ملف نسمّيه info.php داخل دليل الويب الجذري root: <?php phpinfo();عند الوصول للـ script من متصفحنا ننظر إلى السطر الذي يحتوي على ملف الإعدادات الذي تمّ تحميله، ينبغي أن نجد المسار الصحيح للملف php.ini قد تمّ تحميله. يجب ألّا ننسى إزالة الملف info.php بعد الانتهاء من هذا، لأنّه يحتوي على معلومات حسّاسة حول البيئة لدينا. نفتح الملف php.ini ونبحث عن السّطر الذي يحتوي على session.save_handler، إنّ القيمة الافتراضيّة له هي files، ينبغي أن نقوم بتغييرها إلى redis. على بيئة LAMP: sudo vim /etc/php5/apache2/php.iniعلى بيئة LEMP: sudo vim /etc/php5/fpm/php.inietc/php5/fpm/php.ini/ session.save_handler = redisينبغي أن نجد الآن السّطر الذي يحتوي على session.save_path، نقوم بإلغاء التعليق عنه وتغيير قيمته بحيث تحتوي مقطع string اتصال Redis، يجب أن يتّبع المحتوى النَّسَق التالي كله في سطر واحد: tcp://IPADDRESS:PORT?auth=REDISPASSWORDetc/php5/fpm/php.ini/ session.save_path = "tcp://10.133.14.9:6379?auth=yourverycomplexpasswordhere"نحتاج فقط إلى تزويد المُعامِل auth إن كُنّنا قد أعددنا كلمة سر عند ضبط Redis. نحفظ الملف ونعيد تشغيل خدمة php. على بيئة LAMP: sudo service apache2 restartعلى بيئة LEMP: sudo service php5-fpm restart الخطوة السابعة – اختبار مداولة Redis للجلسةلكي نتأكّد من أنّ الجلسات لدينا يتم الآن مُداوَلتها من قبل Redis نحتاج PHP script أو تطبيق يقوم بتخزين المعلومات في الجلسات، سنستخدم Script بسيط يقوم بتنفيذ عدّاد Counter، حيث تتم زيادة الرقم كلّما أعدنا تحميل الصّفحة. ننشئ ملف يُدعى test.php على الخادوم web ونضعه داخل المجلّد الجذر للمستند document root folder: sudo vim /usr/share/nginx/html/test.phpلا يجب أن ننسى تغيير usr/share/nginx/html/ بحيث يكون مسار جذر المستند لدينا. usr/share/nginx/html/test.php/ <?php //simple counter to test sessions. should increment on each page reload. session_start(); $count = isset($_SESSION['count']) ? $_SESSION['count'] : 1; echo $count; $_SESSION['count'] = ++$count;نتوجّه في متصفحنا إلى http://web/test.php لكي نصل إلى الـ script، ينبغي أن يقوم بزيادة الرقم كلما قمنا بإعادة تحميل الصّفحة. يجب أن نمتلك الآن معلومات الجلسة مُخزّنة على خادوم Redis، وللتحقّق من ذلك نعود إلى جلسة SSH على الجهاز redis، حيث قُمنا مُسبَقًا بالاتصال إلى خدمة Redis باستخدام redis-cli. نقوم بجلب المحتوى مرّة أخرى باستخدام * keys: 10.133.14.9:6379> keys *ينبغي أن نحصل على خَرْج مُشابِه لهذا: 1) "PHPREDIS_SESSION:j9rsgtde6st2rqb6lu5u6f4h83"وهذا يُظهِر أنّه يتم تخزين معلومات الجلسة على خادوم Redis، ونستطيع الاتصال من خواديم ويب إضافيّة إلى خادوم Redis بطريقة مماثلة. الخاتمةإنّ Redis خدمة تخزين من نمط مفتاح-قيمة سريعة وقويّة نستطيع أيضًا استخدامها كمُداوِل للجلسة في PHP، مما يُمكّننا من الحصول على بيئات PHP قابلة للتطوير عن طريق تزويدها لنا بنظام مُوزَّع لتخزين الجلسة، وللمزيد من المعلومات حول تقييس scaling تطبيقات PHP تستطيع التحقّق من هذا الدّرس: تقييس تطبيقات PHP أفقيًّا. ترجمة -وبتصرّف- للمقال How to Set Up a Redis Server as a Session Handler for PHP on Ubuntu 14.04 لصاحبته Erika Heidi.

مقدّمةRedis هو عبارة عن مَخزَن قيم مفاتيح key value store مفتوح المصدر يمكنه العمل كمخزن لتخزين البيانات في الذاكرة in-memory store أو كمخزن تخزين بيانات مؤقت. Redis هو خادوم بنية بيانات data structure server يُمكن استخدامه إمّا كخادوم قاعدة بيانات لوحده أو مرتبطًا مع قاعدة بيانات أخرى مثل MySQL لتسريع بعض الأشياء، وهو ما سنشرحه في هذا الدليل. في هذا الدليل، سيتم إعداد Redis كذاكرة تخزين مؤقت cache لووردبريس لتخفيف الحمل الزائد عن عمليات الاستعلام query التي تتم على قاعدة البيانات المُستخدمة لعرض صفحة ووردبريس. النتيجة ستكون توفير موقع ووردبريس أسرع بكثير من ذي قبل ويستخدم موارد أقل للتعامل مع قاعدة البيانات بالإضافة إلى توفير ذاكرة تخزين مؤقت مضبوطة ومستمرة. سيتم استخدام توزيعة Ubuntu 14.04 في هذا الدليل. صحيحٌ أن الوضع يختلف من موقعٍ إلى آخر، ولكن أدناه ستجد مثالًا على قياس أداء الصفحة الرئيسية لعملية تثبيت ووردبريس افتراضية مع وبدون Redis, كما تم إعداده باستخدام هذا الدليل. تم استخدام أدوات مطوري كروم للقيام بعملية الاختبار مع تعطيل عملية التخزين المؤقت الخاصة بالمتصفح لتجنب التأثير على النتائج. صفحة ووردبريس الرئيسية الافتراضية من دون Redis: وقت تحميل الصفحة: 804 ميلي ثانية.صفحة ووردبريس الرئيسية الافتراضية مع Redis:وقت تحميل الصفحة: 449 ميلي ثانية.تحذير: عملية التطبيق هذه لـRedis للقيام بعملية التخزين المؤقت لذاكرة ووردبريس يعتمد على سكربت script طرفٍ ثالث تم تطويره عبر طرفٍ خارجي. إذا كنتَ تريد القيام بعملية تطبيق Redis لووردبريس بنفسك فعليك أن تقوم بعمل بعض العمل الإضافي بناءً على المفاهيم التي سيتم تقديمها هنا. Redis أو Memcachedيُعتبر Memcached أيضًا خيارًا مشهورًا لعمل ذاكرة تخزينٍ مؤقت، لكن في هذه الحالة، Redis يقوم بكل ما يستطيع Memcached القيام به بالإضافة إلى تشكيلة أوسع من المميزات. هذه الصفحة على Stack Overflow بها بعض المعلومات العامة عن المقارنة بينهما. كيف يعمل التخزين المؤقت caching؟عندما يتم تحميل صفحة ووردبريس لأول مرّة، يتم إجراء عملية استعلام على قاعدة البيانات المثبتة على الخادوم. Redis يتذكر أو بالأحرى يخزن مؤقتًا عملية الاستعلام هذه. لذا عندما يحاول مستخدمٌ آخر القيام بتحميل صفحة الووردبريس هذه فالنتيجة سيتم توفيرها من طرف Redis والذاكرة دون الحاجة إلى القيام بعملية استعلام جديدة من قاعدة البيانات. عملية تطبيق Redis المُستخدمة في هذا الدليل ستجعله يعمل ككائن تخزينٍ مؤقت مستمر (persistent object cache) لووردبريس (دون انتهاء). يعمل كائن التخزين المؤقت عبر تخزين عمليات استعلام SQL التي يحتاجها ووردبريس لتحميل الصفحات مؤقتًا في الذاكرة. عندما يتم تحميل أيّ صفحة، يتم توفير النتائج الناتجة عن عمليات الاستعلام في SQL من الذاكرة باستخدام Redis, لذا فإنه لا توجد هناك حاجة لعمل عملية استعلام جديدة من قاعدة البيانات من جديد. وهو ما يعطي سرعةً أكبر في تحميل الصفحات بالإضافة إلى حملٍ أقل من طرف الخادوم على موارد قاعدة البيانات. إذا كان هناك استعلام غير متوفر في Redis، فإنّ قاعدة البيانات تقوم بتوفير نتيجة عملية الاستعلام تلك ويقوم Redis بإضافة تلك النتيجة إلى ذاكرته المؤقتة. إذا تمّ تحديث أيّ قيمة في قاعدة البيانات (مثل إنشاء موضوع أو صفحة جديدة على ووردبريس) فإنّ القيمة المُخزّنة الموازية لتلك القيمة في Redis يتم إبطالها تجنبًا لعرض بيانات قديمة. إذا واجهتَ مشاكل مع التخزين المؤقت، فإنه بإمكانك إلغاء صلاحية ذاكرة التخزين المؤقت الخاصة بـRedis باستخدام أمر flushall عبر سطر الأوامر الخاص بـRedis: redis-cliبمجرد أن ترى سطر الأوامر، طبّق: flushallمرجع إضافي: التوثيق الخاص بكائن التخزين المؤقت لووردبريس. المتطلباتقبل البدء بهذا الدليل، ستحتاج إلى إعداد مستخدمٍ بصلاحيات الجذر (sudo) بالإضافة إلى تثبيت ووردبريس. خادوم Ubuntu 14.04 (من المستحسن أن تكون بذاكرة عشوائية 1 جيجابايت أو أعلى). إضافة مستخدم بصلاحيات الجذر (sudo). تثبيت ووردبريس. الخطوة الأولى – تثبيت Redisبهدف استخدام Redis مع ووردبريس، فإننا بحاجة إلى تثبيت حزمتين: redis-server و php5-redis. حزمة redis-server توفرّ تطبيق Redis نفسه، بينما حزمة php5-redis تقوم بتوفير امتداد PHP للتطبيقات المكتوبة بـPHP مثل ووردبريس للتعامل مع Redis. لتثبيت هذه البرمجيات: sudo apt-get install redis-server php5-redisالخطوة الثانية – إعداد Redis كذاكرة تخزين مؤقتيمكن لـRedis أن يعمل إمّا كمخزن قاعدة بيانات NoSQL أو كذاكرة تخزينٍ مؤقت. في هذا الدليل وهذه الحالة بالضبط، سيتم ضبط Redis كذاكرة تخزينٍ مؤقت. الإعدادات التالية ستكون مطلوبة بهدفِ فعلِ ذلك. حرر الملف /etc/redis/redis.conf عن طريق الأمر: sudo nano /etc/redis/redis/confوقم بإضافة السطور التالية لنهاية الملف: maxmemory 256mb maxmemory-policy allkeys-lru ثم احفظ الملف. الخطوة الثالثة – حمّل سكربت ذاكرة التخزين المؤقت الخلفي لـRedisتم تطوير سكربت الـPHP هذا لووردبريس بواسطة Eric Mann. وهو عبارة عن سندٍ خلفي backend لكائن ذاكرةِ التخزين المؤقت من Redis لووردبريس. عليك تحميل سكربت object-cache.php. عملية التحميل هذه ستتم من خواديم DigitalOcean، ولكن هذا السكربت هو سكربت تم تطويره بواسطة طرفٍ ثالث. يجب عليك قراءة التعليقات داخل السكربت لمعرفة كيفية عمله. لتحميل سكربت الـPHP: wget https://assets.digitalocean.com/articles/wordpress_redis/object-cache.phpقم بنقل الملف إلى مسار /wp-content داخل مجلد ووردبريس الخاص بك: sudo mv object-cache.php /var/www/html/wp-content/قد يكون مسار المجلد (باللون الأحمر) مختلفًا اعتمادًا على طريقة تثبيتك لووردبريس. الخطوة الرابعة – فعّل إعدادات التخزين المؤقت في ملف wp-config.phpالآن، قم بتحرير ملف wp-config.php لإضافة ملحِ مفتاحِ ذاكرةِ تخزينٍ مؤقت (cache key salt) مع اسم موقعك (أو أيّ سلسلة string تريدها): nano /var/www/html/wp-config.phpثم أضف السطر الآتي إلى نهاية قسم * Authentication Unique Keys and Salts: define('WP_CACHE_KEY_SALT', 'example.com');يمكنك استخدام اسم النطاق الخاص بك domain أو أي سلسلة نصية كملح salt. ملاحظة: للمستخدمين الذين يستضيفون أكثر من موقع ووردبريس واحد، يمكن لكلِ موقعٍ أن يتشارك باستخدام تثبيت Redis واحد طالما أن كلّ موقعٍ منفصل يمتلك ملحَ مفتاح ذاكرة التخزين المؤقت الخاص به. أيضًا، قم بإضافة السطر التالي بعد سطر WP_CACHE_KEY_SALT لإنشاء ذاكرة تخزينٍ مؤقت مستمرة مع مُلحق كائن ذاكرة التخزين المؤقت لـRedis: define('WP_CACHE', true);في النهاية، يجب أن يكون ملفّك هكذا: * Authentication Unique Keys and Salts. . . . define('NONCE_SALT', 'put your unique phrase here'); define('WP_CACHE_KEY_SALT', 'example.com'); define('WP_CACHE', true); احفظ الملف وأغلقه. الخطوة الخامسة – قم بإعادة تشغيل Redis و Apacheأخيرًا، قم بإعادة تشغيل redis-service و apache2. لإعادة تشغيل Redis: sudo service redis-server restartلإعادة تشغيل Apache: sudo service apache2 restartأيضًا قم بإعادة تشغيل php5-fpm إذا كنتَ تستخدمها; هذا ليس جزءًا أساسيًا من عملية التثبيت، وعلى كل حال، لفعل ذلك طبّق: sudo service php5-fpm restartهذا كل شيء ! أصبح موقع ووردبريس الخاص بك مضبوطًا ليستخدم تخزين Redis المؤقت. يجب أن تلاحظ تحسنًا إذا قمتَ بالتحقق من سرعة تحميل صفحات موقعك واستهلاك الموارد الآن. مراقبة Redis باستخدام redis-cliلمراقبة Redis، استخدم أمر redis-cli كالتالي: redis-cli monitorعندما تقوم بتشغيل هذا الأمر، ستشاهد خرجًا بالوقت الحقيقي لعمليات تخديم الاستعلامات المُخزّنة مؤقتًا التي يديرها Redis. إذا لم ترى أيّ شيء، فقم بزيارة موقعك وقم بإعادة تحميل أيّ صفحة. بالأسفل مثال على خرجٍ من موقع ووردبريس مضبوط باستخدام هذا الدليل عبر Redis: OK 1412273195.815838 "monitor" 1412273198.428472 "EXISTS" "example.comwp_:default:is_blog_installed" 1412273198.428650 "GET" "example.comwp_:default:is_blog_installed" 1412273198.432252 "EXISTS" "example.comwp_:options:notoptions" 1412273198.432443 "GET" "example.comwp_:options:notoptions" 1412273198.432626 "EXISTS" "example.comwp_:options:alloptions" 1412273198.432799 "GET" "example.comwp_:options:alloptions" 1412273198.433572 "EXISTS" "example.comwp_site-options:0:notoptions" 1412273198.433729 "EXISTS" "example.comwp_:options:notoptions" 1412273198.433876 "GET" "example.comwp_:options:notoptions" 1412273198.434018 "EXISTS" "example.comwp_:options:alloptions" 1412273198.434161 "GET" "example.comwp_:options:alloptions" 1412273198.434745 "EXISTS" "example.comwp_:options:notoptions" 1412273198.434921 "GET" "example.comwp_:options:notoptions" 1412273198.435058 "EXISTS" "example.comwp_:options:alloptions" 1412273198.435193 "GET" "example.comwp_:options:alloptions" 1412273198.435737 "EXISTS" "example.comwp_:options:notoptions" 1412273198.435885 "GET" "example.comwp_:options:notoptions" 1412273198.436022 "EXISTS" "example.comwp_:options:alloptions" 1412273198.436157 "GET" "example.comwp_:options:alloptions" 1412273198.438298 "EXISTS" "example.comwp_:options:notoptions" 1412273198.438418 "GET" "example.comwp_:options:notoptions" 1412273198.438598 "EXISTS" "example.comwp_:options:alloptions" 1412273198.438700 "GET" "example.comwp_:options:alloptions" 1412273198.439449 "EXISTS" "example.comwp_:options:notoptions" 1412273198.439560 "GET" "example.comwp_:options:notoptions" 1412273198.439746 "EXISTS" "example.comwp_:options:alloptions" 1412273198.439844 "GET" "example.comwp_:options:alloptions" 1412273198.440764 "EXISTS" "example.comwp_:options:notoptions" 1412273198.440868 "GET" "example.comwp_:options:notoptions" 1412273198.441035 "EXISTS" "example.comwp_:options:alloptions" 1412273198.441149 "GET" "example.comwp_:options:alloptions" 1412273198.441813 "EXISTS" "example.comwp_:options:notoptions" 1412273198.441913 "GET" "example.comwp_:options:notoptions" 1412273198.442023 "EXISTS" "example.comwp_:options:alloptions" 1412273198.442121 "GET" "example.comwp_:options:alloptions" 1412273198.442652 "EXISTS" "example.comwp_:options:notoptions" 1412273198.442773 "GET" "example.comwp_:options:notoptions" 1412273198.442874 "EXISTS" "example.comwp_:options:alloptions" 1412273198.442974 "GET" "example.comwp_:options:alloptions" اضغط CTRL-C لإيقاف الخرج. هذا الأمر مفيد لرؤية الاستعلامات التي يعالجها Redis بالضبط. الخاتمةبعد اتّباع هذا الدليل، سيصبح ووردبريس مضبوطًا لاستخدام Redis كذاكرة تخزينٍ مؤقت على Ubuntu 14.04. ترجمة -وبتصرّف- للمقال: How To Configure Redis Caching to Speed Up WordPress on Ubuntu 14.04