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

يمكن لنقل مدونتك إلى خادوم جديد أو خدمة استضافة ووردبريس أخرى أن يستهلك الكثير من الوقت وقد يتحول الأمر إلى كابوس حقيقي ما لم تملك الأدوات المُناسبة لذلك. لحسن حظّك لن تراودك أية كوابيس بفضل مُلحق Snapshot. لا يعلم كثير من مستخدمي snapshot أنه يحتوي على خاصية التهجير. ولهذا رغبت في أن أتطرّق لها في هذا الدّرس. هذا الدّرس موجّه لك سواء كنت تستخدم نسخة ووردبريس العادية (موقع واحد) أو نسخة متعددة المواقع. يُمكنك تنفيذ خطوات هذا الدّرس حتى ولو رغبت من نقل مدونتك من نسخة ووردبريس عادية إلى تلك التي تدعم مواقع عديدة والعكس. إن أردت أن تغير اسم نطاق موقعك، سأعمل على إعطاء بعض التوجيهات في ما يخص هذا الأمر أيضا. لم تعد وظائف ملحق Snapshot تقتصر على عمل نسخ احتياطية (backing up) واسترجاعها (restoring) فحسب بل أصبحت تتعدى ذلك بكثير، لنبدأ دون أي تأخير في التعرف على كيفية تهجير موقعك. يبدأ الأمر بإعداد نسخة احتياطية (Backup) فلنبدأ بالأساسيات: إن أردت تهجير موقعك باستخدام Snapshot عليك أولا بعمل نسخة احتياطية، لكن قبل القيام بذلك يجب أن تنصب وتفعل Snapshot سواء من خلال استخدام ملحق WPMU DEV Dashboard في خلفية (backend) موقعك أو عن طريق تحميل Snapshot مباشرة. قبل أن نواصل، من الحري بنا أن نشير إلى إمكانية مواجهة Snapshot بعض المشاكل في التشغيل إن لم تكن تمتلك حد ذاكرة أقصى كافيا على استضافة ووردبريس الخاصة بك. لتجاوز هذا المشكل اطلع على مقال: كيفية الزيادة في القيمة القصوى للرفع وفي الحد الأقصى لذاكرة PHP على ووردبريس، يعتبر القيام بهذه العملية التي لا تستغرق أكثر من بضع دقائق أمرا في غاية الأهمية، من الوارد جدا أن تواجه مستقبلا مشاكل أخرى تتعلق بالحد الأقصى للذاكرة إن لم يكن قد حدث ذلك فعلا. إليك كيفية عمل نسخة احتياطية (backup): اذهب إلى: Snapshots > Add New في لوحة التحكم، (أو في لوحة تحكم الشبكة (super admin) في حالة نسخة ووردبريس متعددة المواقع). إن لم يتم عرض عنوان URL الخاص بموقعك أسفل Blog to backup، اضغط على زر Change لتحديد موقع آخر في حال استخدامك نسخة ووردبريس متعددة المواقع، لن تواجه هذا الأمر في حال استخدام النسخة العادية (موقع واحد). حدد الموقع الذي تريد تهجيره إن لم يكن محددا مسبقا قم بتحديد include selected files في قسم What Files to Archive، ثم ضع علامة في كل الخانات الظاهرة أمام الملفات الموافقة لها. بغرض نقل موقعك بنجاح، عليك بحفظ كل شيء. إن اخترت أيا من الخيارات الأخرى، لن يتم نسخ التغييرات المخصصة التي قمت بها. إن كنت تعتزم عمل نسختك الاحتياطية على Dropbox يمكنك أن تترك خيار Archive الافتراضي عوض خيار Mirror/Sync. يجب أن يتم حفظ كل الملفات من أجل عملية تهجير ناجحة في القسم التالي، اضغط على زر الاختيار Include selected database tables in this Snapshot. لا تنس تحديد الجداول (tables) عندما تظهر قائمة جداول قاعدة البيانات، اضغط على Select all links لتحديد كل الخانات تلقائيا، يضمن القيام بهذه الخطوة تخزين نسخة احتياطية لكل الجداول حتى يظهر موقعك بنفس الشكل بعد تهجيره. يمكن تحديد زر الاختيار الأوسط لتضمين كل الجداول تلقائيا دونما الحاجة إلى تحديدها كلها، يضمن تحديد كل الجداول يدويا التأكد من تخزين نسخة احتياطية منها كلها. يبقى القرار الأخير لك حول أي الخيارين ستعتمد. أسفل Backup Interval، اترك خيار Run Immediate محددا واكتب رقما مناسبا في خانة Maximum number of local archives، عادة ما أكتب رقم 2، حتى يتم تخزين نسختين فقط دفعة واحدة فيما يخص هذا الجانب بالتحديد. إن قمت بكتابة عدد كبير أو 0 للحفاظ على كل النسخ الاحتياطية، عليك أن تتأكد من توفرك على مساحة التخزين الكافية لهذا الغرض. حدد مكان حفظ نسختك الاحتياطية من القائمة المنسدلة Backup Destination من خلال تحديد واحدة من الخيارات التي أعددتها مسبقا. إن لم تكن تتوفر على أي وجهة تخزين محفوظة ولا تريد عمل نسختك الاحتياطية على خادومك، تجاوز هذا القسم حاليا. اختر وجهة حفظ نسختك الاحتياطية بعد الاختيار، اضغط على زر Create Snapshot المتواجد أسفل الصفحة. يمكنك أن ترى في الصفحة التالية نسخة snapshot الخاصة بك في طور الإنشاء. لا تقلق إن استغرق الأمر بضع ثوان، خصوصا بالنسبة للمواقع الكبيرة فهذا عادي جدا. لن تأخذ العملية فترة طويلة. عندما ترى رسالة أعلى الشاشة تخبرك بنجاح العملية فإن ذلك علامة على انتهاء إنشاء نسختك الاحتياطية، اذهب إلى: Snapshots > All Snapshots لتراها في القائمة. أخيرا، تفحص حالة نسختك أسفل خانة Archives، يجب أن يتم إدراج حالة النسخة الاحتياطية في وجهة الحفظ (destination) التي اخترتها. تأكد من إرسال نسختك الاحتياطية إلى الوجهة المحددة إن رأيت جملة Destination: 1 Pending فمعنى ذلك أنه يتم رفع نسختك إلى وجهة الحفظ، في حالتي يعني هذا أن عملية المزامنة مع حسابي في Dropbox في طور الإنجاز. بمجرد مزامنة نسختك الاحتياطية مع وجهة التخزين، فأنت على أتم استعداد لبدأ تهجير موقعك. تهجير موقعك بعد تجهيز نسخة snapshot الخاصة بك، عليك بتنصيب نسخة جديدة من ووردبريس على خادومك الجديد. يتضمن ذلك كل الاحتمالات الممكنة لتهجير موقعك سواء ضمن شبكة ما أو إلى شبكة ما. على استضافتك الجديدة، قم بتثبيت وتفعيل نفس القوالب والملحقات المتواجدة على الموقع الذي تود تهجيره. بعد ذلك، قم بتثبيت وتفعيل القالب الذي تود استخدامه في موقعك الجديد بعد التهجير، يجب أن يتم تفعيله قبل التهجير حتى وإن كان متضمنا في نسخة snapshot. تضمن هذه الخطوة جاهزية موقعك مباشرة بعد إتمام العملية. نصِّب وفعِّل Snapshot على موقعك الجديد إن لم تكن قمت بذلك مسبقا. بعد ذلك، اذهب إلى: Snapshots > Import وأدخل عنوان URL عامًا (public URL) أو مسار ملف إلى ملحق snapshot الخاص بك. ما يعني أنك إن أرسلت نسختك الاحتياطية إلى Dropbox ،Amazon S3 أو وجهة أخرى، سيكون عليك سواء أن تجعل الملف عاما (public)، مشاركته برابط أو حفظه في مكان آخر. استيراد نسخة snapshot إن كانت نسخة snapshot الخاصة بك متواجدة على خادومك، ما عليك إلا أن تكتب مسار الملف الذي يؤدي إليها. عند إدخال نسخة snapshot إلى خانة الاستيراد (import field)، اضغط على زر Scan/Import Snapshots. من المفترض أن يتم عرض رسالة " success" أسفل الصفحة. إن أدخلت مسار ملف قد تظهر أكثر من رسالة واحدة. حان الوقت الآن لإتمام تهجير الموقع من خلال الذهاب إلى: Snapshots > All Snapshots تم استيراد نسخة snapshot بنجاح اعثر على نسخة snapshot الخاصة بك مدرجة في القائمة، ضع مؤشر فأرة الحاسوب فوق العنوان ثم حدد رابط restore. إن لم تكن متأكدا من ماهية كل عنصر، حاول مقارنة اسم ملف نسخة snapshot مع اسم الملف في وجهة الحفظ. من المفترض أن يتم بعد ذلك توجيهك إلى صفحة أرشيف كل النسخ الاحتياطية. اضغط على restore لإنهاء عملية التهجير شخصيا، أمتلك نسخة snapshot واحدة في أرشيفي، يمكن أن يكون لديك أكثر من ذلك. اختر تلك التي تريد استخدامها، ثم ضع الفأرة فوق عنوانها. اختر استرجاع (restore) نسخة snapshot التي تريد اضغط على رابط restore الذي يظهر. في الصفحة الموالية، يمكنك مراجعة الخيارات وما تستطيع أن تقوم بتهجيره. الانتهاء من التهجير وتغيير النطاق انزل نحو قسم Restore Blog Options، ثم اضغط على زر Change قرب الوسم Site URL.تستطيع أن تغير عنوان URL الخاص بملفات نسختك الاحتياطية حتى يتم استخدام موقعك القديم مع نطاقك الجديد. يمكن تهجير موقعك إلى عنوان URL مختلف في الخانة الظاهرة، تستطيع إدخال رقم تعريف الموقع (site ID) أو مسار المدونة الخاص بالموقع الجديد الذي أنشأته ليتم استبداله بنسخة snapshot. اضغط على زر Lookup ليتم عرض الموقع الذي قمت بتحديده. في القسم التالي المسمى ?What Tables to Restore اضغط على الخيار Restore selected database tables. لا تختر الخيار الأول لاسترجاع كل الجداول نظرا لأن بعضها تم استثناؤه اضغط على رابط Select All قرب وسم WordPress Global Tables. من المفترض أن يتم تحديد الجداول الأخرى تلقائيا، إن لم يحدث ذلك، اضغط على روابط Select All. اختر خيار Include selected files في القسم التالي وتأكد من وضع علامة في كل الخانات. إن لم تكن تقوم بتهجير موقعك الأساسي قم بتحديد خيار Restore all files. في آخر جزء من الصفحة، اختر من القائمة القالب الذي تود استخدامه من بين تلك المتوفرة في استضافتك الحالية. تأكد من تنصيب وتفعيل القالب الذي تود استخدامه في موقعك الجديد بعد التهجير تأكد أيضا من عدم وضع علامة في خانة Turn off all plugins وإلا قد لا يتم عرض موقعك بشكل جيد بعد التهجير. أخيرا، اضغط زر Restore Snapshot أسفل الصفحة. من المفترض أن ترى رسالة مشابهة بمجرد انتهاء عملية التهجير باستخدام snapshot في الصفحة التالية، ستظهر قائمة تحتوي على الجداول والملفات إضافة إلى عمود يعرض حالة تقدم عملية الرفع. بعد انتهاء عملية التهجير بنجاح تظهر رسالة أعلى الصفحة تشير إلى ذلك. عملية تهجير بسيطة باستخدام Snapshot موقعك الجديد بعد التهجير جاهز الآن كما أنه يبدوا تماما مثل سابق عهده فقط على خادوم ونطاق جديدين. لقد قمت بعد تطبيق هذا الموضوع بتهجير موقعك بسهولة باستخدام Snapshot موفرا عليك عناء الساعات التي كنت ستقضيها للقيام بهذه العملية يدويا. ترجمة -وبتصرف- للمقال: How to Move a WordPress Site Without Hassle with Snapshot لكاتبته: JENNI MCKINNON.

تعرفنا في الدرس الماضي على مفهوم حاويات لينكس (LXC)، مبدأ عملها وكيفية تثبيتها، سنشرع في هذا الدرس إلى كيفية بدء تشغيلها واستعمالها. لا يملك LXC عفريتًا (daemon) يعمل طوال الوقت، لكنه يملك مهام upstart: المهمة ‎/etc/init/lxc-net.conf: هي مهمة اختيارية تعمل فقط إذا حَدَّد الملف ‎/etc/default/lxc الخاصية USE_LXC_BRIDGE (قيمتها هي true افتراضيًا)؛ حيث تهيِّء جسر NAT لكي تستخدمه الحاويات. المهمة ‎/etc/init/lxc.conf: تعمل إذا كانت الخاصية LXC_AUTO (قيمتها true افتراضيًا) مضبوطة إلى true في ‎/etc/default/lxc؛ حيث تبحث عن القيود في المجلد ‎/etc/lxc/auto‎/‎ حيث توجد وصلات رمزية إلى ملفات الضبط للحاويات التي يجب أن تُشغَّل في وقت الإقلاع. المهمة ‎/etc/init/lxc-instance.conf: تُستخدَم من ‎/etc/init/lxc.conf للبدء التلقائي لتشغيل حاوية. التخزين يدعم LXC عدّة أنماط من التخزين لجذر نظام ملفات الحاوية؛ افتراضيًا يكون مجلدًا بسيطًا، لأنه لا يتطلب أي ضبط مسبق للمضيف طالما أن نظام الملفات فيه مساحة تخزينية كافية؛ وهو لا يتطلب أيضًا امتيازات الجذر لإنشاء المخزن، لذلك سيكون ملائمًا للاستخدام دون امتيازات؛ جذر نظام الملفات للاستخدام مع امتيازات موجود افتراضيًا في ‎/var/lib/lxc/C1/rootfs، بينما جذر نظام الملفات للحاويات التي تعمل دون امتيازات يكون في ‎~/.local/share/lxc/C1/rootfs، إذا حُدِّد lxcpath خاص في lxc.system.com، فإن جذر نظام ملفات الحاوية سيكون موجودًا في ‎$lxcpath/C1/rootfs. نسخة snapshot باسم C2 لحاوية C1 التي تُخزَّن في مجلد ستصبح حاوية overlayfs، بجذر نظام ملفات هو overlayfs:/var/lib/lxc/C1/rootfs:/var/lib/lxc/C2/delta0، أنواع التخزين الأخرى تتضمن loop، و btrfs، و LVM، و zfs. حاوية تعتمد على تخزين btrfs تبدو عمومًا مثل حاوية تعتمد على التخزين في مجلد، ويكون جذر نظام الملفات في نفس المكان؛ لكن جذر نظام الملفات يحتوي على حجم فرعي (subvolume)، لذلك تكون نسخة snapshot مُنشَأة باستخدام نسخة snapshot لحجم فرعي. جذر نظام الملفات لحاوية تستخدم LVM يمكن أن يكون أي حجم منطقي منفصل؛ اسم مجموعة الحجوم الافتراضي يمكن أن يُحدَّد في ملف lxc.conf؛ ويُضبَط نوع وحجم نظام الملفات لكل حاوية باستخدام lxc-create. جذر نظام الملفات لحاوية تستخدم zfs هو نظام ملفات zfs منفصل، وموصول في المكان التقليدي ‎/var/lib ‎/lxc/C1/rootfs، يمكن تحديد zfsroot باستخدام lxc-create، ويمكن تحديد قيمة افتراضية في ملف lxc.system.conf. المزيد من المعلومات حول إنشاء الحاويات بمختلف طرائق التخزين يمكن أن توجد في صفحة دليل lxc-create. القوالب يتطلب إنشاء حاوية عادةً إنشاء جذر نظام ملفات للحاوية؛ يفوض الأمر lxc-create هذا العمل إلى القوالب (templates)، التي تكون عادةً خاصة بالتوزيعة؛ قوالب lxc التي تأتي مع lxc يمكن أن توجد في مجلد ‎/usr/share/lxc/templates، بما فيها القوالب لإنشاء أوبنتو، ودبيان، وفيدورا، وأوراكل، وسنتوس، وجنتو بالإضافة لغيرها. إنشاء صور للتوزيعات في أغلب الحالات يتطلب القدرة على إنشاء عقد أجهزة، ويتطلب ذلك أدوات التي ليست متوفرة في بقية التوزيعات، وعادةً يستغرق هذا الأمر وقتًا طويلًا؛ فلذلك يأتي lxc بقالب download، الذي ينزل صور مبنية مسبقًا للحاويات من خادوم lxc مركزي؛ أهم حالة استخدام هي السماح بإنشاء بسيط لحاويات دون امتيازات بواسطة مستخدمين غير الجذر، الذين لن يستطيعوا ببساطة تشغيل الأمر debootstrap. عند تشغيل lxc-create، فجميع الخيارات التي تأتي بعد «--» تُمرَّر إلى القالب؛ ففي الأمر الآتي، تمرر الخيارات ‎--name و ‎--template و ‎--bdev إلى lxc-create، بينما يمرر الخيار ‎--release إلى القالب: lxc-create --template ubuntu --name c1 --bdev loop -- --release trusty يمكنك الحصول على مساعدة حول الخيارات المدعومة في حاوية معينة بتمرير الخيار ‎--help واسم القالب إلى الأمر lxc-create؛ فعلى سبيل المثال، للحصول على مساعدة حول تنزيل قالب: lxc-create --template download --help البدء التلقائي يدعم LXC تعليم الحاويات لكي تُشغَّل عند إقلاع النظام؛ ففي الإصدارات قبل أوبنتو 14.04، كان يتم ذلك باستخدام وصلات رمزية في المجلد ‎/etc/lxc/auto؛ وبدءًا من أوبنتو 14.04، يتم ذلك عبر ملفات ضبط الحاوية؛ القيد: lxc.start.auto = 1 lxc.start.delay = 5 يعني أن على الحاوية البدء عند إقلاع النظام ويجب الانتظار 5 ثواني قبل بدء تشغيل الحاوية التالية؛ يدعم LXC أيضًا ترتيب وتجميع الحاويات، وأيضًا إعادة الإقلاع وإيقاف التشغيل عبر مجموعات autostart؛ راجع صفحات دليل lxc-autostart و lxc-container.conf للمزيد من المعلومات. AppArmor يأتي LXC مع ملف ضبط AppArmor مهمته هي حماية المضيف من الإساءة العرضية للامتيازات داخل الحاوية؛ على سبيل المثال، لن تكون الحاوية قادرةً على الكتابة إلى ‎/proc/sysrq-trigger أو أغلبية ملفات ‎/sys. الملف usr.bin.lxc-start يدخل حيز التنفيذ عند تشغيل lxc-start؛ يمنع ملف الضبط lxc-start من وصل أنظمة ملفات جديدة خارج نظام ملفات الجذر الخاص بالحاوية؛ قبل تنفيذ init للحاوية، فإن LXC يطلب تبديلًا لملف ضبط الحاوية؛ افتراضيًا، هذا الضبط هو السياسة lxc-container-default المعرَّفة في ملف الضبط ‎/etc/apparmor.d/lxc/lxc-default. يمنع هذا الضبط الحاوية من الوصول إلى مسارات خطرة، ومن وصل أغلبية أنظمة الملفات. لا يمكن تقييد البرامج في الحاوية أكثر من ذلك؛ فعلى سبيل المثال، خادوم MySQL الذي يعمل ضمن نطاق الحاوية (مما يحمي المضيف) لا يمكن أن يدخل في نطاق ملف ضبط MySQL (لحماية الحاوية). لا يدخل lxc-execute ضمن سلطة AppArmor، لكن الحاوية التي يُنشِئها (spawn) ستكون مقيدةً. تعديل سياسات الحاوية إذا وجدت أن lxc-start لا يعمل بسبب تقييد في الوصول من سياسة AppArmor، فيمكنك تعطيل ملف ضبط lxc-start بتنفيذ: sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/ هذا سيجعل lxc-start يعمل دون قيود، لكن ستبقى الحدود موجودةً للحاوية نفسها، وإذا أردت إزالة التقييد عن الحاوية، فعليك بالإضافة إلى تعطيل ملف الضبط usr.bin.lxc-start أن تضيف السطر: lxc.aa_profile = unconfined إلى ملف ضبط الحاوية. يأتي LXC مع سياسات بديلة للحاويات، فإذا أردت إنشاء حاويات داخل حاويات (تشعب)، فعليك استخدام ملف الضبط lxc-container-default-with-nasting بإضافة السطر الآتي إلى ملف ضبط الحاوية: lxc.aa_profile = lxc-container-default-with-nesting إذا أردت استخدام libvirt داخل الحاويات، فستحتاج إلى تعديل تلك السياسة (المعرفة في ‎‎/etc/apparmor.d/lxc/lxc-default-with-nasting) وإزالة التعليق عن السطر الآتي: mount fstype=cgroup -> /sys/fs/cgroup/**, ثم أعد تحميل السياسة. لاحظ أن سياسة التشعب للحاويات ذات الامتيازات هي أقل أمانًا من السياسة الافتراضية، حيث تسمح للحاويات بإعادة وصل ‎/sys و ‎/proc في أمكان غير قياسية، مما يتجاوز سياسة AppArmor؛ لا تملك الحاويات دون امتيازات هذا التأثير الجانبي، ﻷن جذر الحاوية لا يمكنه الكتابة إلى ملفات proc و sys المملوكة من الجذر. إذا أردت تشغيل الحاوية بملف ضبط مخصص، فبإمكانك إنشاء ملف ضبط في ‎/etc/apparmor.d/lxc، ويجب أن يبدأ اسمه بالكلمة lxc-‎ لكي يُسمَح لبرنامج lxc-start بالانتقال إليه؛ ملف lxc-default يتضمن إعادة استعمال الملف المجرد ‎/etc/apparmor.d/abstraction/lxc/container-base؛ طريقة سهلة لإنشاء ملف ضبط جديد هي فعل المثل، ثم إضافة الأذونات الإضافية في نهاية السياسة. حَمِّل الضبط الجديد بعد إنشاءه كما يلي: sudo apparmor_parser -r /etc/apparmor.d/lxc-containers سيُحمَّل هذا الضبط تلقائيًا بعد إعادة الإقلاع، ﻷنه يُقرَأ من الملف ‎/etc/apparmor.d/lxc-containers؛ وفي النهاية ولجعل الحاوية CN تستخدم ملف الضبط الجديد lxc-CN-profile، فأضف السطر الآتي إلى ملف الضبط: lxc.aa_profile = lxc-CN-profile مجموعات التحكم إن مجموعات التحكم (cgroups) هي ميزة من ميزات النواة توفر تجميع للمهام تجميعًا هيكليًا، وإسناد وتحديد الموارد لكل مجموعة تحكم؛ تُستخدَم في الحاويات للحد من الوصول إلى الأجهزة الكتلية أو المحرفية (block or character devices) وتجمِّد عمل الحاويات؛ يمكن استعمالها أيضًا لتحديد استخدام الذاكرة وإيقاف الدخل أو الخرج، وضمانة استخدام أصغري للمعالج، والسماح للحاوية بالوصول إلى معالجات محددة. افتراضيًا، سيُسند للحاوية CN ذات امتيازات مجموعةُ تحكمٍ باسم ‎/lxc/CN؛ وفي حال حدوث تضارب بالاسم (الذي قد يحدث عند استخدام lxcpaths مخصصة)، فستُضاف لاحقة «‎-n» حيث n هو رقم صحيح يبدأ من الصفر، ويُسنَد إلى اسم مجموعة التحكم. افتراضيًا، سيُسند للحاوية CN دون امتيازات مجموعة تحكم باسم CN في مجموعة التحكم الخاصة بالمهمة التي بدأت الحاوية، على سبيل المثال ‎/usr/1000.user/1.session/CN سيُمنَح جذر الحاوية ملكية المجموعة للمجلد (لكن ليس جميع الملفات)، وهذا ما سيسمح بإنشاء مجموعات تحكم فرعية. وفي أوبنتو 14.04، يستخدم LXC مدير مجموعات التحكم cgmanager لإدارة مجموعات التحكم؛ يستقبل مدير مجموعات التحكم طلبات D-Bus عبر مقبس يونكس ‎/sys/fs/cgroup/cgmanager/sock؛ يجب أن يُضاف السطر الآتي لاستخدام آمن للحاويات المتشعبة: lxc.mount.auto = cgroup إلى ملف ضبط الحاوية، مما يصل المجلد ‎/sys/fs/cgroup/cgmanager وصلًا ترابطيًا (bind-mounted) إلى الحاوية؛ ويجب على الحاوية في المقابل تشغيل وسيط إدارة مجموعات التحكم (ويتم ذلك افتراضيًا إذا كانت الحزمة cgmanager مثبتةً على الحاوية) الذي سينقل المجلد ‎/sys/fs/cgroup/cgmanager إلى ‎/sys/fs/cgroup‎/cgmanager.lower ثم سيبدأ الاستماع إلى الطلبات للوسيط على مقبسه ‎/sys/fs/cgroup ‎/cgmanager‎/sock؛ سيتأكد مدير مجموعات التحكم في المضيف أن الحاويات المتشعبة لن تستطيع «الهروب» من مجموعات التحكم المُسندَة إليها أو إنشاء طلبات غير مصرح لها بها. الاستنساخ للتزويد السريع بالحاويات، ربما تريد تخصيص حاوية تبعًا لحاجاتك ثم تُنشِئ عدَّة نسِخٍ منها؛ ويمكن فعل ذلك بالبرنامج lxc-clone. الاستنساخ إما أن يكون عبر snapshots أو بنسخ حاوية أخرى؛ فالنسخ هو إنشاء حاوية جديدة منسوخة من الأصلية، وتأخذ مساحة تخزينية مثل الحاوية الأصلية؛ أما snapshot فإنها تستخدم قدرة آلية التخزين على إنشاء snapshots لإنشاء حاوية النسخ-عند-الكتابة (copy-on-write) تُشير إلى الحاوية الأولى؛ يمكن إنشاء snapshots للحاويات المخزنة في btrfs، و LVM، و zfs، وتلك التي تكون مخزنة في مجلدات؛ حيث كل آلية تخزين لها خصوصياتها؛ فمثلًا، حاويات LVM التي ليست thinpool-provisioned لا تدعم إنشاء snapshots من snapshots؛ ولا يمكن حذف حاويات zfs مع snapshots قبل أن تُطلَق (release) جميع snapshots؛ ويجب أن يُخطط جيدًا لحاويات LVM فقد لا يدعم نظام الملفات أن يزيد حجمه. لا يعاني btrfs من تلك السلبيات، لكنه يعاني من أداء fsync منخفض يسبب جعل dpkg و apt-get أبطئ. تُنشَأ snapshots من الحاويات المخزنة في مجلدات عبر نظام الملفات؛ فمثلًا يكون لحاوية ذات امتيازات C1 جذر نظام ملفات في ‎/var/lib/lxc/C1/rootfs، وستبدأ نسخة snapshot للحاوية C1 باسم C2 بجذر نظام الملفات للحاوية C1 موصولًا للقراءة فقط في ‎/var/lib/lxc/C2/delta0؛ كل ما يهم في هذه الحالة أنه لا يفترض أن تعمل أو تحذف الحاوية C1 أثناء عمل C2؛ من المستحسن اعتبار الحاوية C1 هي حاوية أساسية واستخدام نسخة snapshot لها فقط. لنفترض أن لدينا حاوية باسم C1، فيمكن إنشاء نسخة منها باستخدام الأمر: sudo lxc-clone -o C1 -n C2 يمكن إنشاء snapshot باستخدام: sudo lxc-clone -s -o C1 -n C2 راجع صفحة دليل lxc-clone لمزيد من المعلومات. Snapshots LXC يدعم snapshots لتسهيل دعم نسخ snapshot لتطوير تكراري للحاوية؛ فعندما تعمل على حاوية C1 -وقبل إنشاء تغيير خطير وصعب العكس- يمكنك إنشاء snapshot: sudo lxc-snapshot -n C1 التي هي نسخة snapshot باسم «snap0» في مجلد ‎/var/lib/lxcsnaps أو ‎$HOME/.local ‎/share/lxcsnaps، النسخة الثانية ستُسمى «snap1» وهكذا؛ يمكن عرض النسخ الموجودة حاليًا باستخدام الأمر lxc-snapshot -L -n C1، ويمكن أن تُستعاد نسخة snapshot وتمحى حاوية C1 الحالية باستخدام الأمر lxc-snapshot -r snap1 -n C1، وبعد تنفيذ أمر الاستعادة، فستبقى النسخة snap1 موجودةً. تُدعَم snapshots لحاويات btrfs، و lvm، وzfs، و overlayfs؛ إذا استدعي الأمر lxc-snapshot على حاوية تُخزَّن في مجلد، فسيسجل خطأ وستُنشَأ نسخة copy-clone؛ وسبب ذلك أنه لو أنشأ المستخدم نسخة overlayfs snapshot لحاوية تخزن في مجلد، فسينعكس جزء من تغيرات الحاوية الأصلية على نسخة snapshot؛ إذا كنت تريد إنشاء snapshots لحاوية C1 مخزنة في مجلد، فيمكن إنشاء نسخة overlayfs للحاوية C1، ويجب ألّا تلمس C1 بعد ذلك قط، لكن يمكن أن نعدِّل overlayfs وننسخها نسخ snapshots كما نريد، أي: lxc-clone -s -o C1 -n C2 lxc-start -n C2 -d # make some changes lxc-stop -n C2 lxc-snapshot -n C2 lxc-start -n C2 # etc الحاويات العابرة «الحاويات العابرة» (Ephemeral containers) هي حاويات تستخدم لمرة واحدة فقط؛ فليكن لدينا حاوية موجودة مسبقًا باسم C1، فيمكنك إنشاء حاوية عابرة باستخدام: lxc-start-ephemeral -o C1 ستبدأ الحاوية كنسخة snapshot للحاوية C1، وستطبع التعليمات للدخول إلى الحاوية على الطرفية، وستدمر الحاوية العابرة بعد إيقاف التشغيل، راجع صفحة الدليل lxc-start-ephemeral لمزيد من الخيارات. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: LXC.