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

تطرقنا في أكاديمية حسوب سابقًا إلى أساسيات الصندوق المرن Flexbox وكيف يُمكن للمطوّر استخدام هذه الخاصية الرائعة في CSS3، وفي هذا المقال سنكمل مع الأساسيات ولكن بتركيز على الأمثلة بعيدًا عن الكلام النظري، وللحصول على الفائدة المطلوبة من هذا الأمثلة من الضروري قراءة المقال الآنف الذكر، وتحديث المتصفح إلى آخر إصدار متوفّر لتطبيق وعرض الأمثلة بالشكل الصحيح. إنشاء حاوية مرنة Flex Containerإن الخطوة الأولى في هيكلة أجزاء الصفحة باستخدام الصندوق المرن flexbox هي إنشاء المستوعبة/الحاوية المرنة flex container، وذلك من خلال إسناد قيمة الخاصية display إلى flex، مع الانتباه إلى إضافة البادئة webkit- من أجل المتصفح ‹‹سفاري›› Safari. .flexcontainer { display: -webkit-flex; display: flex; }توضيع العناصر المرنة Flex Items ضمن صف Rowعناصر الصندوق المرن ما هي إلا أبناء (عناصر فرعية) من الحاوية المرنة flex container، وتتموضع على طول محور رئيسي main axis ومحور جانبي cross axis، المحور الرئيسي هو أفقي افتراضيًا، ولذلك العناصر تتموضع ضمن صف، ومن الممكن تغيير اتجاه المحور الرئيسي من خلال إسناد flex-direction إلى القيمة column، والتي هي افتراضيا row. .flexcontainer { display: -webkit-flex; display: flex; -webkit-flex-direction: row; flex-direction: row; } توضيع العناصر المرنة Flex Items ضمن عمود Column.flexcontainer { display: -webkit-flex; display: flex; -webkit-flex-direction: column; flex-direction: column; } نقل العناصر المرنة Flex Items إلى الجهة العلويةيَعتمد نقل العناصر المرنة إلى الأعلى على اتجاه المحور الرئيسي main axis، فإن كان عموديًا vertical، يُمكن استخدام الخاصية align-items، وإن كان أفقيًا horizontal، فيُمكن استخدام الخاصية justify-content. .flexcontainer { -webkit-flex-direction: column; flex-direction: column; -webkit-justify-content: flex-start; justify-content: flex-start; } .flexcontainer { display: -webkit-flex; display: flex; -webkit-flex-direction: row; flex-direction: row; -webkit-align-items: flex-start; align-items: flex-start; } نقل العناصر المرنة Flex Items إلى جهة اليمينيَعتمد نقل العناصر إلى جهة اليسار أو جهة اليمين على اتجاه المحور الرئيسي أيضًا، فإن كان flex-direction معينًا إلى row (صف)، عندها يجب استخدام justify-content، وإن كان مُعيّنًا إلى column (عمود)، عندها يجب استخدام align-items. .flexcontainer { display: -webkit-flex; display: flex; -webkit-flex-direction: row; flex-direction: row; -webkit-justify-content: flex-start; justify-content: flex-start; } .flexcontainer { display: -webkit-flex; display: flex; -webkit-flex-direction: column; flex-direction: column; -webkit-align-items: flex-start; align-items: flex-start; } نقل العناصر المرنة Flex Items إلى جهة اليسار .flexcontainer { display: -webkit-flex; display: flex; -webkit-flex-direction: row; flex-direction: row; -webkit-justify-content: flex-end; justify-content: flex-end; } .flexcontainer { display: -webkit-flex; display: flex; -webkit-flex-direction: column; flex-direction: column; -webkit-align-items: flex-end; align-items: flex-end; } توسيط كافة العناصر باستخدام Flexboxيُعتبر توسيط العناصر في المستوعبة سواء كان عموديًا أو أفقيًا سهلًا للغاية، كل ما يجب فعله هو إسناد justify-content و/أو align-items إلى القيمة center، ويعتمد الأمر دائمًا على اتجاه المحور الأساسي main axis وذلك فيما إذا كان قيمة الخاصية flex-direction مسندة إلى القيمة row أو column. .flexcontainer { display: -webkit-flex; display: flex; -webkit-flex-direction: row /* works with row or column */ flex-direction: row; -webkit-align-items: center; align-items: center; -webkit-justify-content: center; justify-content: center; } تكبير حجم عنصر مرن Flex Item نسبة إلى العناصر المرنة الأخرىيُمكن تحديد كيف لعنصر مرن أن يزداد أو بنقص بالحجم نسبة إلى باقي العناصر الأخرى في المستوعبة، ولتطبيق ذلك يمكن إسناد القيمة المطلوبة ولكل عنصر ومن خلال الخاصية flex، ففي المثال التّالي، تمّ زيادة حجم أحد العناصر إلى ضعف حجم العنصر الآخر. .bigitem { -webkit-flex: 2 0 0; flex: 2 0 0; } .smallitem { -webkit-flex: 1 0 0; flex: 1 0 0; } التفاف العناصر المرنة إلى صفوف Wrap flex items into rowsتأخرت بعض المتصفحات في دعم هذه الخاصية مثل متصفح Firefox، على العموم من المفترض أن تعمل هذه الخاصية في الوقت الحالي مع جميع المتصفحات بإصداراتها الأخيرة. .flexcontainer { display: -webkit-flex; display: flex; -webkit-align-items: center; align-items: center; -webkit-justify-content: center; justify-content: center; /* You can set flex-wrap and flex-direction individually */ -webkit-flex-direction: row; flex-direction: row; -webkit-flex-wrap: wrap; flex-wrap: wrap; /* Or do it all in one line with flex flow */ -webkit-flex-flow: row wrap; flex-flow: row wrap; /* tweak the where items line up on the row */ /* valid values are: flex-start, flex-end, space-between, space-around, stretch */ -webkit-align-content: flex-end; align-content: flex-end; } التفاف العناصر المرنة إلى أعمدة Wrap flex items into columns .flexcontainer { display: -webkit-flex; display: flex; -webkit-align-items: center; align-items: center; -webkit-justify-content: center; justify-content: center; -webkit-flex-flow: column wrap; flex-flow: column wrap; -webkit-align-content: stretch; align-content: stretch; } إزالة المساحة بين الأعمدة أو الصفوف الملتفةتُقدّم الخاصية align-content للمطوّر إمكانية توزيع المساحة حول الأعمدة والصفوف الملتفة wrapped، وذلك بتقديم الخيارات التالية: flex-startflex-endspace-betweenspace-aroundstretchولإزالة المساحة حول الأعمدة الملتفة، يمكن إسناد align-content إلى center. .flexcontainer { display: -webkit-flex; display: flex; -webkit-align-items: center; align-items: center; -webkit-justify-content: center; justify-content: center; -webkit-flex-flow: column wrap; flex-flow: column wrap; -webkit-align-content: center; align-content: center; } تخصيص مكان العنصر في الحاويةيُمكن للمطوّر التحكم بقيمة align-items لكل عنصر على حِدة باستخدام align-self، وكما يمكن أيضًا استخدام margins لتحريك أي عنصر وفي أي اتجاه من الاتجاهات الأربعة، فمثلًا لتوزيع أعمدة الصّفحة يُمكن تحريك العنصر المرن إلى أقصى يسار مستوعبته من خلال إسناد margin-right إلى القيمة auto. .left { -webkit-align-self: flex-start; align-self: flex-start; } .right { margin-left: auto; } خاتمةخاصيّة الصندوق المرن خاصيّة رائعة ومن الضروري على مطوّر الويب إضافتها إلى أدواته في التطوير خاصة وأنها أصبحت مدعومة بشكل جيّد مع المتصفحات. ترجمة وبتصرّف للمقال The Ultimate Flexbox Cheat Sheet.

الحاويات (containers) هي تقنية أنظمة وهمية خفيفة؛ حيث تجنح لأن تكون شبيهةً بطريقة chroot محسّنة بدلًا من كونها تقنية أنظمة وهمية كاملة مثل Qemu أو VMware؛ لأن كلاهما لا يحاكي العتاد ولأن الحاويات تشارك نفس نظام التشغيل للمضيف؛ لذلك من الأفضل مقارنة الحاويات إلى «نطاقات سولارس» (Solaris zones) أو «سجون BSD» ‏(BSD jails). إن Linux-vserver و OpenVZ هما نسختان من الحاويات لنظام لينُكس مطورتان بشكل منفصل عن بعضهما؛ في الواقع، ظهرت الحاويات نتيجةً للعمل على تطوير وظائف vserver و OpenVZ. هنالك نسختان في «مجال المستخدم» (user-space) للحاويات تستخدمان نفس مزايا النواة؛ تسمح Libvirt باستخدام الحاويات عبر محرك LXC بالاتصال إلى «lxc:///‎»، قد يكون هذا أمرًا ملائمًا لأنها تملك نفس طريقة الاستخدام الموجودة في المحركات الأخرى. النسخة الأخرى المُسماة ببساطة «LXC» هي غير متوافقة مع libvirt؛ لكنها أكثر مرونةً بأدوات أكثر في مجال المستخدم؛ من الممكن التبديل بين النسختين آنفتَيّ الذكر، لكن هنالك بعض الخصوصيات التي قد تسبب ارتباكًا. سنشرح في هذا الدرس حزمة lxc شرحًا رئيسيًا، حيث أن استخدام libvirt-lxc ليس مستحسنًا ﻷنه يفتقر إلى حماية AppArmor لحاويات libvirt-lxc؛ وستكون أسماء الحاويات الموجودة في هذا الفصل هي CN، أو C1، أو C2. التثبيت يمكن تثبيت حزمة lxc باستخدام الأمر: sudo apt-get install lxc سنحتاج إلى تنزيل الاعتماديات المطلوبة والمستحسنة، وضبط جسر الشبكة لكي يستخدمه الحاويات؛ إذا أردت استخدام حاويات دون امتيازات، فربما تحتاج إلى أن تتأكد أن للمستخدمِين امتيازات subuids و subgids، وتريد أن تسمح للمستخدمين بوصل الحاويات إلى جسر؛ راجع القسم «الاستخدام الأساسي دون امتيازات». الاستخدام الأساسي يمكن أن نستخدم LXC بطريقتين مختلفتين، الأولى بامتيازات عبر تنفيذ أوامر lxc بحساب المستخدم الجذر؛ أو دون امتيازات بتنفيذ أوامر lxc بحساب أي مستخدم عدا الجذر (في الواقع، يمكن تشغيل حاويات دون امتيازات بحساب الجذر، لكننا لن نشرح ذلك هاهنا)؛ الحاويات دون امتيازات محدودة أكثر، فمثلًا لن تستطيع إنشاء عقد أجهزة أو تصل أنظمة ملفات كتلية؛ لكنها أقل خطرًا للمضيف، حيث يكون الجذر في الحاوية مربوطًا بحساب غير جذر في المضيف. الاستخدام الأساسي بامتيازات لإنشاء حاوية ذات امتيازات، كل ما عليك فعله هو تنفيذ الأمر: sudo lxc-create --template download --name u1 أو بشكل مختصر: sudo lxc-create -t download -n u1 الذي سيسألك تفاعليًا عن نوع جذر نظام الملفات لكي يُنزَّل، وخصوصًا التوزيعة والإصدارة والمعمارية؛ يمكنك تحديد هذه القيم في سطر الأوامر لإنشاء حاوية دون الإجابة على تلك الأسئلة تفاعليًا: sudo lxc-create -t download -n u1 -- --dist ubuntu --release trusty --arch amd64 أو sudo lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64 يمكنك الآن استخدام lxc-ls لعرض قائمة بالحاويات، و lxc-info للحصول على معلومات مفصلة عن حاوية، و lxc-start لبدء و lxc-stop لإيقاف الحاوية؛ بينما يسمح لك الأمران lxc-attach و lxc-console بالدخول إلى حاوية إذا لم يكن الاتصال إليها عبر SSH متاحًا؛ والأمر lxc-destory يحذف الحاوية، بما في ذلك جذر نظام الملفات؛ راجع صفحات الدليل للأوامر السابقة للمزيد من المعلومات؛ أمثلة: sudo lxc-ls --fancy sudo lxc-start --name u1 --daemon sudo lxc-info --name u1 sudo lxc-stop --name u1 sudo lxc-destroy --name u1 مجالات أسماء المستخدم تسمح الحاويات دون امتيازات للمستخدمين بإنشاء وإدارة الحاويات دون الحصول على امتيازات الجذر؛ أساس هذه الميزة هو ما يسمى «مجالات أسماء المستخدم» (user namespaces)، إن مجالات أسماء المستخدم هيكليةٌ، حيث تكون المهام ذات امتيازات في مجال الأسماء الأب قادرة على ربط معرِّفاتها إلى مجالات أسماء الأبناء؛ افتراضيًا، كل مهمة على المضيف تعمل في مجال أسماء مبدئي (initial user namespace)، حيث المجال الكامل لمعرفاتها مربوطٌ مع المجال الكامل؛ يمكن مشاهدة ذلك بالنظر إلى ‎/proc/self/uid_map و ‎/proc/self ‎/gid_map؛ اللذان سيظهران القيمة «‎‎0 0 4294967295‎» عندما يُقرأ من مجال الأسماء المبدئي؛ وفي أوبنتو 14.04، المستخدمون الجدد الذين يُنشؤون يكون لهم افتراضيًا مجال من معرفات المستخدم؛ هذه القائمة من المعرفات المُسنَدة يمكن أن تُشاهد في الملفين ‎/etc/subuid و ‎/etc/subgid؛ انظر إلى صفحات الدليل الموافقة لهم للمزيد من المعلومات؛ ويبدأ subuid و subgid عرفيًا من المعرف 100000 لتجنب التضارب مع مستخدمي النظام. إذا أُنشِئ المستخدم في إصدارة قديمة، فيمكنك منحه مجالًا من المعرفات باستخدام usermod، كما يلي: sudo usermod -v 100000-200000 -w 100000-200000 user1 برنامجا newuidmap و newgidmap هما برنامجا setuid-root في حزمة uidmap، اللذان يُستخدمان داخليًا بواسطة lxc لربط subuids و subgids من المضيف إلى حاوية دون امتيازات؛ ويتأكدان من أن المستخدم يربط المعرفات المصرَّح بها فقط من ضبط المضيف. الاستخدام الأساسي دون امتيازات لإنشاء حاويات دون امتيازات، فإن هنالك خطوات أولية ضرورية؛ حيث تحتاج إلى إنشاء ملف ضبط حاوية افتراضي، مُحدِّدًا ربط المعرفات الذي تريده وضبط الشبكة، بالإضافة إلى ضبط المضيف للسماح لمستخدم دون امتيازات بالارتباط إلى شبكة المضيف؛ يفترض المثال الآتي أنك ربطت معرفات المستخدم والمجموعة ذات المجال 100000 – 165536. mkdir -p ~/.config/lxc echo "lxc.id_map = u 0 100000 65536" > ~/.config/lxc/default.conf echo "lxc.id_map = g 0 100000 65536" >> ~/.config/lxc/default.conf echo "lxc.network.type = veth" >> ~/.config/lxc/default.conf echo "lxc.network.link = lxcbr0" >> ~/.config/lxc/default.conf echo "$USER veth lxcbr0 2" | sudo tee -a /etc/lxc/lxc-usernet بعد ذلك، يمكنك إنشاء حاويات دون امتيازات بنفس طريقة إنشاء حاويات بامتيازات، لكن ببساطة دون sudo: lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64 lxc-start -n u1 -d lxc-attach -n u1 lxc-stop -n u1 lxc-destroy -n u1 التشعب لكي نشغِّل حاويات داخل حاويات – الأمر الذي يُشار إليه بتشعّب الحاويات – فإن سطرين يجب أن يوجدا في ملف ضبط الحاوية الأب: lxc.mount.auto = cgroup lxc.aa_profile = lxc-container-default-with-nesting سيسبب السطر الأول بدمج مقبس مدير مجموعات التحكم في الحاوية، لذلك سيكون lxc داخل الحاوية قادرًا على إدارة مجموعات التحكم للحاويات المتشعبة الخاصة به؛ أما السطر الثاني فيسبب تشغيل الحاوية بوضع أكثر سماحيةً بالنسبة إلى AppArmor، مما يسمح للحاوية بإجراء عمليات الوصل اللازمة لبدء تشغيل الحاويات؛ لاحظ أن سياسة AppArmor التي ستُطبَّق أقل أمنًا من السياسة العادية أو سياسة حاوية دون امتيازات؛ راجع القسم «AppArmor» في هذا الدرس القادم لمزيدٍ من المعلومات. الضبط العام تُستخدَم ملفات الضبط الآتية من LXC؛ للاستخدام ذو الامتيازات، فإنها ستتواجد في مجلد ‎/etc/lxc، بينما للاستخدام دون امتيازات فستكون موجودةً في ‎~/.config/lxc. lxc.conf: يُحدِّد اختياريًا القيم البديلة لمختلف خيارات ضبط lxc، بما فيها lxcpath، والضبط الافتراضي، ومجموعات التحكم التي ستُستخدَم، ونمط إنشاء مجموعة تحكم، وإعدادات الواجهات الخلفية لتخزين lvm و zfs. default.conf: يحدد الضبط الذي يجب أن يحتويه كل ملف ضبط للحاويات المُنشأة حديثًا؛ يحتوي هذا الملف عادةً على الأقل على قسم للشبكة؛ ويحتوي على قسم لربط المعرفات للمستخدمين دون امتيازات. lxc-usernet.conf: يحدد كيف يوصل المستخدمون دون امتيازات حاوياتهم إلى شبكة مملوكة من المضيف. الملفان lxc.conf و default.conf موجودان في ‎/etc/lxc و ‎$HOME/.config/lxc؛ بينما الملف lxc-usernet.conf هو ملف لعموم المضيف. افتراضيًا، تقبع الحاويات في مجلد ‎/var/lib/lxc بالنسبة للمستخدم الجذر، و ‎$HOME/.local/share/lxc عدا ذلك؛ يمكن تحديد المسار لجميع أوامر lxc باستخدام المعامل «‎-P|--lxcpath». ضبط الشبكة افتراضيًا، يُنشِئ LXC مجال أسماء شبكي خاص لكل حاوية، الذي يتضمن مجموعة الاتصال الشبكي من الطبقة الثانية (layer 2)، تتصل الحاويات عادةً إلى العالم الخارجي إما بالحصول على بطاقة شبكية فيزيائية، أو عبر نفق veth يُمرَّر إلى الحاوية؛ ينُشِئ LXC جسر NAT، الذي هو lxcbr0 عند إقلاع المضيف؛ والحاويات المُنشَأة باستخدام ملف الضبط الافتراضي سيكون لها بطاقة شبكية veth تكون نهايتها موصولةٌ إلى الجسر lxcbr0، يمكن للبطاقة الشبكية أن تتواجد في مجال أسماء واحد في وقتٍ واحد، لذلك البطاقة الشبكية الفيزيائية المُمررة إلى الحاوية ستكون غير قابلة للاستخدام في المضيف. من الممكن إنشاء حاويات دون مجال أسماء شبكي خاص، ففي هذه الحالة، ستحصل الحاوية على وصول إلى شبكة المضيف مثل أي تطبيق آخر، لاحظ أنه هذا خطير خصوصًا إذا كانت الحاوية تُشغِّل توزيعة تستخدم upstart، مثل أوبنتو، لأن البرامج التي «تتحدث» إلى init، مثل shutdown، سيتحدثون عبر مقبس مجال يونكس مجرد (abstract Unix domain socket) إلى upstart للمضيف، مما سيوقف تشغيل المضيف! لمنح الحاويات في lxcbr0 عنوان IP ثابت بناءً على اسم المضيف، فيمكنك كتابة هذه المدخلات إلى ‎/etc/lxc/dnsmasq.conf: dhcp-host=lxcmail,10.0.3.100 dhcp-host=ttrss,10.0.3.101 إذا كان من المطلوب أن يُسمَح بالوصول إلى الحاوية من الخارج، فهنالك عدِّة طرق للالتفاف على ذلك، إحداها هي استخدام iptables لتمرير منافذ المضيف إلى الحاوية، فمثلًا: iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 587 -j DNAT \ --to-destination 10.0.3.100:587 طريقة أخرى هي إنشاء جسر إلى إلى البطاقة الشبكية للمضيف (راجع درس ضبط الشبكة لمزيدٍ من المعلومات)؛ ثم حدد جسر المضيف في ملف ضبط الحاوية بدلًا من lxcbr0، فمثلًا: lxc.network.type = veth lxc.network.link = br0 في النهاية، يمكنك سؤال LXC ليستخدم macvlan كبطاقة شبكية للحاوية؛ لاحظ أن لهذه الطريقة حدود واعتمادًا على الضبط قد لا تتمكن الحاوية من «التحدث» إلى المضيف نفسه، وبالتالي الخياران السابقان أفضل ويُستخدمان أكثر. هنالك عدِّة طرق لتحديد عنوان IP للحاوية، فأولًا، يمكنك استخدام lxc-ls --fancy الذي سيطبع عناوين IP لجميع الحاويات التي تعمل؛ أو lxc-info -i -H -n C1 الذي سيطبع عنوان IP للحاوية C1؛ إذا كان dnsmasq مثبتًا على المضيف، فيمكنك إضافة قيد إلى ‎/etc/dnsmasq.conf كما يلي: server=/lxc/10.0.3.1 بعد أن يستبين dnsmasq عنوان C1.lxc محليًا، فيمكنك تنفيذ: ping C1 ssh C1 للمزيد من المعلومات، راجع صفحة دليل lxc.conf ومثال ضبط الشبكة في ‎/usr/share/doc/lxc ‎/examples/‎. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: LXC.

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