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

مقدّمةيكتسي التّواصل Communication والتّشبيك Networking أهميّةً بالغة عند بناء نُظُم موزَّعة تعمل عليها حاويّات Docker؛ حيثُ تعتمد بنية التّطبيقات الّتي تتبع التّصميم خَدَمي التّوجّه Service-oriented بشكل كبير على تواصُل المكوِّنات في ما بينها حتى تعمل كما يُرادُ لها. سنذكُر في هذا الدّرس أدواتِ وإستراتيجيّات التّشبيك المُتعدّدة المُستخدَمة لضبط الشّبكات الّتي تعمل عليها الحاويّات؛ وذلك من أجل الوصول إلى الوضعية المرغوبة للشّبكة. يُمكن في بعض الحالات الاعتماد على الحلول الّتي يُوفّرها Docker افتراضيًّا، إلّا أنّ في بعض الحالات تتطلّب الاستعانة ببعض المشاريع البديلة. الحل الافتراضي للتّشبيك على Dockerيقدّم Docker افتراضيًا العديد من الأدوات القاعديّة المطلوبة للتّواصل بين الحاويّات Container-to-container وبين الحاويّات والنِّظام المُستضيف Container-to-host. يضبُطُ Docker عند تشغيله واجهة وهميّة Virtual interface جديدة للشّبكة باسم docker0 على النّظام المُستضيف. تعمل هذه الواجهة كجسر Bridge يُمكّن Docker من إنشاء شبكة فرعيّة Subnet تستخدمها الحاويّات في ما بعد؛ إضافةً إلى عملها كنقطة وصل بين آلية التّشبيك في الحاويّة وتلك الموجودة في المُستضيف. تُنشَأ واجهة وهميّة عندما يبدأ Docker تشغيل حاوية جديدة، وتُمنح عنوان IP ضمن مجال الشّبكة الفرعيّة المذكورة سابقًا. يدخُل عنوان IP الواجهة الوهمية الجديدة في إطارالشّبكة الدّاخليّة للحاويّة ممّا يوفِّر مسارًا يُمكن للحاويّة الاتّصال عن طريقه بالجسر docker0 الموجود على المُستضيف. يضبُط Docker آليًّا قواعد Iptables للسّماح بإعادة التّوجيه Forwarding ويُعدّ آليّة ترجمة العناوين على الشّبكة Network address translation (أو NAT اختصارًا) للاستخدام عند تبادل البيانات بين docker0 والعالم الخارجي. 1- كيف تعرِض الحاويّات الخدماتِ للعملاء؟لا تحتاج الحاويّة لأي إعدادات إضافيّة للحصول على الخدمات المُقدَّمة من طرف الحاويّات المتواجدة على نفس المُستضيف، حيثُ إنّ المُستضيف سيُوجِّه الطّلبات الّتي تُرسَل من الواجهة docker0 وتتّجه إليها (كلّ من المصدَر والوِجهة يوجدان على نفس الشّبكة الفرعيّة) إلى المكان المُناسِب. يُمكن للحاويّات عرضُ expose منافذها Ports عبرَ المُستضيف لتلقي البيانات ينقلها هذا الأخير إليها من العالم الخارجي. يُمكن قرن Mapping منافذ الحاويّة المعروضة بمنفذ من النِّظام المستضيف (تُنقل البيانات المُتبادلَة عبر منفذ المُستضيف إلى منافذ الحاويّة المقرونة بها) إمّا باختيار منفَذ مُحدَّد؛ أو ترك هذه المهمّة لـ Docker، في هذه الحالة يختار Docker منفذًا عشوائيًا غير مُستعمل برقم عالٍ. يتولّى Docker في هذا الإطار إدارة قواعد التوّجيه وإعدادت iptables لإيصال البيانات إلى وجهتها الصّحيحة. 2- ما الفرق بين عرض ونشر منفَذ Publishing ؟يُمكِن عند إعداد صورة أو بدْء تشغيل حاويّة، الاختيارُ بين عرض أو نشر المنافذ. من المهمّ التّفريقُ بين الاثنين. يعني عرضُ منفَذ مّا إعلامَ Docker أنّ الحاويّة تستخدِم المنفَذ المذكور، ويُمكن بالتّالي استخدام هذا المنفذ لأغراض الرّبط Linking أو الاستكشاف. يُعطي فحصُ حاويّة - على سبيل المثال - معلوماتٍ عن المنافذ المعروضة، وعند ربط حاويّات فإنّ متغيّرات البيئة تُضبَط لمعرفة المنافِذ المعروضة في الحاويّة الأصليّة.يُمكن - في الإعداد الافتراضي - للنِّظام المُستضيف الوصولُ إلى الحاويّة؛ نفس الشّيء بالنّسبة للحاويّات الموجودة على نفس المُستضيف. تقتصِر فائدة عرض المنافِذ في هذه الحالة على توثيق استخدام المنفذ وجعل هذه المعلومة مُتاحةً للرّبط والتّعيين الآليّيْن. على الجانب الآخر، يؤدّي نشر منفذ إلى جعله متاحًا للعالم الخارجي عبر قرنه بواجهة المُستضيف. 3- ماهيّ روابِط Docker؟يُوفّر Docker آليةً لإعداد الاتّصالات بين الحاويّات، تُسَمّى "روابط Docker" . تحصُل حاويّة جديدة عندَ ربطها بأخرى موجودة على معلومات اتّصال الأخيرة عبر متغيّرات مُشترَكة في بيئة التّنفيذ. تُشكّل هذه الوسيلة طريقةً سهلة للتّأسيس لاتّصال بين حاويّتيْن عبر إعطاء الحاويّة الجديدة معلومات مُفصَّلة عن كيفية النفاذ إلى الحاوية المُصاحِبة. تُضبَط المتغيّرات المُشترَكة حسب المنافذ الّتي تعرضها الحاويّة بينما يضبط Docker عنوان IP الحاويّة ومعلومات اتّصال أخرى. مشاريع للرّفع من قدرات Docker في التّشبيكنموذج التّشبيك المُقدَّم أعلاه يُشكِّل نقطة بدْء جيّدة في بناء وربط الشّبكات. الاتّصال بين الحاويّات الموجودة على نفس المُستضيف يعمل بشكل مُباشر. بالنّسبة للاتّصال بين المُستضيفات فيعمل عن طريق الشّبكات العمومية Public networks ما دامت المنافذ مقرونة بشكل صحيح ومعلومات الاتّصال متوفّرة لدى الطّرف الآخر. على الرّغم من ما سبق، تتطلّب بعض التّطبيقات بيئات شبكيّة خاصّة (نظرًا لبعض الأهداف الأمنيّة أو الوظيفيّة) لا يستطيع نموذج التّشبيك الأصلي في Docker توفيرها. لهذا السّبب أُنشِئت مشاريع عديدة لزيادة قُدُرات Docker في الرّبط بين الشّبكات. 1- إنشاء شبكات فوقيّة Overlay لتجريد Abstract البنية التّحتيّةركّزت العديد من المشاريع على تحسين وظيفي يتمثّل في التأسيس لشبكات فوقيّة Overlay Networks؛ وهيّ عبارة عن شبكات افتراضيّة مبنيّة على اتّصالات موجودة مُسبَقًا. يُمكّن التّأسيس لشبكات فوقيّة من إنشاء بيئات تشبيك منتظِمة يُمكن التّنبّؤ بها، وتربط بين عدّة مستضيفات. يُساعد هذا الأمر في تسهيل ربط الحاويّات بالشّبكة دون الاهتمام بالمُستضيف الذي تعمل عليه هذه الحاويّات. يُمكِن استخدام هذه الطّريقة لبناء شبكة افتراضيّة واحدة تمتدّ على عدّة مُستضيفات، أو لبناء شبكات فرعيّة لكل مُستضيف اعتمادًا على نفس الشبكة الفوقيّة. تُتيح الشّبكات الفوقيّة أيضًا بناء نسيج عنقودي Fabric clusters. تعمل الحوسبة النسيجيّة Fabric computing (يُطلَق عليها أحيانًا الحوسبة التوحيديّة Unified computing) على توحيد عدّة مُستضيفات وإدارتها كما لو كانت كيانًا واحدًا بموارد أكبر. يسمح إنجاز مبدأ الحوسبة النسيجيّة للمُستخدِم النّهائي بإدارة العنقود كوحدة بدلًا من مستضيفات متفرّقة. يلعب ربطُ الشّبكات جزءًا كبيرًا من إنشاء عناقيد حسب هذا المبدأ. 2- الإعداد المتقدّم للتّشبيكتتولّى مشاريعُ أخرى الرّفع من قدرات Docker التّشبيكيّة عن طريق توفير مرونة أكبر. إعداد التّشبيك الأصلي في Docker يقوم بالوظيفة الّتي أُنشئ من أجلها، ولكنّه بسيط جدّا. على الرغم من أنّ الحواجز الوظيفيّة للإعداد الافتراضي للشّبكات في Docker قد تظهر عند تخصيص مُتطلَّبات التّشبيك في مستضيف واحد، إلّا أنّها تظهر بشكل أوضح عند التّعامل مع شبكات عابرة للمُستضيفات. يُلجأ - من أجل إضافة وظائف جديدة إلى "تطويع" تلك الموجودة مُسبَقًا. لا تُضيف هذه المشاريع إعدادات خارقة لكنّها تسمح بربط أجزاء في ما بينها لإنشاء تصوّرات أكثر تعقيدًا لعمل الشّبكات. تمتد الوظائف الّتي تُضيفها هذه المشاريع من مجرّد إنشاء وربط شبكات خاصّة بين بعض المستضيفات إلى ضبط جسور، شبكات محليّة افتراضيّة، تخصيص الشّبكات الفرعيّة والبوّابات Gateways. توجد مشاريع وأدوات أخرى تُستخدم كثيرًا في بيئات Docker لتوفير وظائف جديدة، وذلك رغم أنّها لم تُطوَّر خصّيصًا لـDocker. يتعلّق الأمر خصوصًا بتقنيّات وصلت لمرحلة النّضوج في إنشاء الشّبكات الخاصّة والأنفاق Tunnels الّتي تُستخدَم غالِبًا لتأمين التّواصل بين المستضيفات وعبر المُستضيفات. هل من مشاريع شائعة الاستخدام للتحسين من أداء الشّبكات في Docker؟توجد عدّة مشاريع تُركِّز على توفير شبكة فوقيّة لمستضيفات Docker. في ما يلي بعض أكثر هذه المشاريع شيوعًا: flannel: يُطوِّره فريق CoreOs. أُنشئ هذا المشروع أصلًا لإعطاء كل مُستضيف شبكة فرعيّة خاصّة به ضمنَ شبكة مُشترَكة؛ وهو شرط ضروري لعمل أداة التّنسيق kubernetes الّتي تُطوِّرها Google، لكنّه مفيد أيضًا في حالات أخرى. weave: تُنشئ أداة Wweave شبكة افتراضيّة تربط بين مختلف مُستضيفات Docker. يُسهّل هذا الأمر من توجيه بيانات التّطبيق، إذ أنّ الحاويّات تبدو كما لو كانت كلّها على نفس المُوزِّع Switch. بالنسبة للتّشبيك المتقدّم، تهدف المشاريع أدناه إلى توفير قدرات تطويع أكثر للشّبكة. pipework: يهدف هذا المشروع إلى سد الفجوة في آلية التّشبيك الأصليّة في Docker من حيث نقص الوظائف المتقدِّمة، في انتظار تطّورها حيثُ يُسهّل التحكّم في وضبطَ إعدادات متقدّمة للتّشبيك. الأداة التّاليّة هي مثال على اختيّار برمجيّات موجودة خارج النّظام البيئي لـDocker واستخدامها بإضافة وظائف جديدة إليه. tinc: عبارة عن برنامج لإنشاء شبكة افتراضيّة خاصّة Virtual private network (أو VPN اختصارًا) يعتمد على التّعميّة Encryption والأنفاق. تُقدّم هذه الأداة طريقة وسيلة صلبة لجعل استخدام الشّبكة الخاصّة شفّافًا بالنّسبة لأيّ تطبيق. خاتمةيعتمد نموذج Docker على توفير خدمات عبر عناصر داخليّة وأخرى خارجيّة، وهو ما يجعل من الاعتبارات المُتعلّقة بالشّبكة مهمّةً للغاية. يُوفّر Docker وظائف أساسيّة لإعداد الشّبكات مثل الواجهات الافتراضيّة، الشّبكات الفرعيّة، iptables وإدارة ترجمة العناوين على الشّبكة (NAT)؛ وهيّ الوظائف الّتي تُكمّلها مشاريع أخرى أُنشِئت لإتاحة إمكانية ضبط إعدادات أكثر تقدّمًا. سنتطرّق في الدّرس القادم لكيفيّة عمل المُجدوِلات Schedulers وأدوات التّنسيق orchestration المبنيّة على هذا الأساس بهدف إدارة عنقود حاويّات.

يعد دوكر تطبيقًا يبسّط إدارة عمليات التطبيق في الحاويات. حيث تتيح لك الحاويات تشغيل تطبيقاتك في عمليات معزولة الموارد فيما بينها. فهي من ناحية المبدأ تشبه Virtual Machines، لكن الحاويات أكثر قابلية للنقل وأكثر ملاءمة للموارد وأكثر اعتمادًا على نظام تشغيل المضيف. وللحصول على مقدمة تفصيلية للمكونات المختلفة لحاوية دوكر، راجع المقال نظام Docker Ecosystem: مقدمة إلى المكونات المشتركة.. في هذا الدليل، ستقوم بتثبيت واستخدام Docker Community Edition ‏(CE) على دبيان 10. حيث ستقوم بتثبيت دوكر بذاته والتعامل مع الحاويات والنِسخ، ورفع نسخة إلى مستودع دوكر. المتطلبات لمتابعة هذا الدليل، ستحتاج إلى ما يلي: خادم دبيان 10 مع مستخدم عادي بصلاحيات sudo بالإضافة لجدار الحماية. حساب على Docker Hub في حال كنت ترغب في إنشاء نسخك الخاصة ورفعها إلى Docker Hub، كما هو موضح في الخطوتين 7 و 8. الخطوة 1- تثبيت دوكر قد لا تكون حزمة تثبيت دوكر المتوفرة في مستودع دبيان الرسمي حزمًة ذو أحدث إصدار. لذا لضمان حصولنا على أحدث إصدار، سنقوم بتثبيت دوكر من مستودع دوكر الرسمي وذلك بإضافة مصدر حزمة جديد مع مفتاح GPG من دوكر للتأكد من صلاحية التنزيلات، ومن ثم تثبيت الحزمة. أولاً، قم بتحديث قائمة الحزم الموجودة لديك: $ sudo apt update بعد ذلك قم بتثبيت بعض الحزم الأساسية التي تتيح لـ apt استخدام الحزم عبر HTTPS: $ sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common ثم أضف مفتاح GPG لمستودع دوكر الرسمي إلى نظامك: $ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add أضف مستودع دوكر إلى مصادر APT: $ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable" بعد ذلك قم بتحديث قاعدة بيانات الحزم بحزم دوكر من المستودع المضاف حديثًا: $ sudo apt update تأكد من أنك على وشك التثبيت من مستودع دوكر بدلاً من مستودع دبيان الافتراضي: $ apt-cache policy docker-ce سترى مخرجات مثل هذا على الرغم من أن رقم إصدار دوكر قد يكون مختلفًا: $ docker-ce: Installed: (none) Candidate: 5:18.09.7~3-0~debian-buster Version table: 5:18.09.7~3-0~debian-buster 500 500 https://download.docker.com/linux/debian buster/stable amd64 Packages لاحظ أن docker-ce غير مثبت، لكن المرشح للتثبيت هو من مستودع دوكر لـ دبيان 10 (buster) أخيرًا، قم بتثبيت دوكر: $ sudo apt install docker-ce تم الآن تثبيت دوكر وبدأ البرنامج الخفي (daemon، العفريت كما يطلق عليه مستخدمو لينكس)، و تم تمكين العملية للبدء في التشغيل. تحقق من أنه يعمل بتنفيذ الأمر التالي: $ sudo systemctl status docker سيكون الناتج مشابهًا لما يلي، مما يدل على أن الخدمة نشطة وتعمل: docker.service - Docker Application Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-07-08 15:11:19 UTC; 58s ago Docs: https://docs.docker.com Main PID: 5709 (dockerd) Tasks: 8 Memory: 31.6M CGroup: /system.slice/docker.service └─5709 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock لا يمنحك تثبيت دوكر خدمة Docker daemon وحسب، بل يمنحك أيضًا خط أوامر docker، أو عميل دوكر. سنكتشف كيفية استخدام أمر docker لاحقًا في هذا الدليل التعليمي. الخطوة 2- تنفيذ أمر دوكر دون sudo (اختياري) افتراضيًا، لا يمكن تشغيل أمر docker إلا للمستخدم الجذر أو بواسطة مستخدم في مجموعة docker، والتي يتم إنشاؤها تلقائيًا أثناء عملية تثبيت دوكر. وإذا حاولت تشغيل الأمر docker دون أن تضيفه إلى sudo أو دون أن تكون في مجموعة docker، فستحصل على ناتج مثل هذا: docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host?. See 'docker run –help'. إذا كنت تريد تجنب كتابة sudo كلما قمت بتشغيل أمر docker، أضف اسم المستخدم الخاص بك إلى مجموعة docker: $ sudo usermod -aG docker ${USER} لتطبيق عضوية المجموعة الجديدة، قم بتسجيل الخروج من الخادم والعودة مرة أخرى أو اكتب ما يلي: $ su - ${USER} عندها سيُطلب منك إدخال كلمة مرور المستخدم للمتابعة. تأكد من إضافة المستخدم الآن إلى مجموعة docker عن طريق كتابة: $ id -nG sammy sudo docker وإذا كنت بحاجة إلى إضافة مستخدم آخر إلى مجموعة docker التي لم تسجل الدخول بها من قبل، فيمكنك الإعلان عن اسم المستخدم هذا باستخدام: $ sudo usermod -aG docker username تفترض بقية المقالة هذه أنك تقوم بتشغيل أمر docker كمستخدم في مجموعة docker. في حال اخترت عدم القيام بذلك، يرجى إلحاق الأوامر بـsudo. دعنا نستكشف أمر docker تاليًا. الخطوة 3- استخدام أمر docker يتكون استخدامdocker من تمرير سلسلة من الخيارات والأوامر متبوعة بالوسطاء (arguments). حيث تأخذ الصيغة هذا الشكل: $ docker [option] [command] [arguments] لعرض كافة الأوامر الفرعية المتاحة، اكتب: $ docker فبالنسبة لـ دوكر 18، تتضمن القائمة الكاملة للأوامر الفرعية المتاحة ما يلي: Attach إرفاق تدفقات الإدخال والإخراج والخطأ القياسية المحلية إلى حاوية قيد التشغيل Build إنشاء نسخة من ملف Dockerfile Commit إنشاء نسخة جديدة من تغييرات الحاوية Cb نسخ الملفات / المجلدات بين الحاوية ونظام الملفات المحلي Create إنشاء حاوية جديدة Diff فحص التغييرات بالملفات أو المجلدات على نظام ملفات الحاوية Events معرفة الأحداث مباشرًة من الخادم Exec تشغيل أمر في حاوية قيد التشغيل Export استخراج نظام ملفات الحاوية كإنشاء محفوظة (tar archive) History إظهار تاريخ النسخة Images عرض قائمة النسخ Import استيراد المحتويات من tarball لإنشاء نسخة نظام ملفات Info عرض المعلومات على مستوى النظام Inspect إظهار معلومات منخفضة المستوى عن كائنات دوكر Kill إيقاف حاوية واحدة قيد التشغيل أو أكثر Load تحميل نسخة من أرشيف tar أو STDIN Login تسجيل الدخول إلى سجل دوكر Logout تسجيل الخروج من سجل دوكر Logs عرض سجلات الحاوية Pause إيقاف جميع العمليات مؤقتًا داخل حاوية واحدة أو أكثر Port سرد تعيينات المنافذ (port mappings) أو تعيين معين للحاوية Ps قائمة الحاويات Pull سحب نسخة أو وحدة تخزين (repository) من سجل Push رفع نسخة أو وحدة تخزين إلى السجل Rename إعادة تسمية الحاوية Restart إعادة تشغيل حاوية واحدة أو أكثر Rm إزالة حاوية واحدة أو أكثر Rmi إزالة نسخة واحدة أو أكثر Run تشغيل أمر في حاوية جديدة Save حفظ نسخة أو أكثر في أرشيف tar (يتم بثها إلى STDOUT افتراضيًا) Search بحث في Docker Hub عن النسخ Start بدء تشغيل حاوية واحدة أو أكثر Stats عرض بث مباشر لإحصائيات استخدام موارد الحاوية Stop إيقاف تشغيل حاوية واحدة أو أكثر Tag إنشاء علامة TARGET_IMAGE تشير إلى SOURCE_IMAGE Top عرض العمليات الجارية للحاوية Unpause إلغاء الإيقاف المؤقت لجميع العمليات داخل حاوية واحدة أو أكثر Update تحديث التكوين لحاوية واحدة أو أكثر Version إظهار معلومات إصدار دوكر Wait القيام بالحظر حتى تتوقف حاوية واحدة أو أكثر، ثم اطبع رموز الخروج الخاصة بها لعرض الخيارات المتاحة لأمر معين، اكتب: $ docker docker-subcommand –help أما لعرض معلومات على مستوى النظام حول دوكر، يمكنك استخدام: $ docker info دعنا نستكشف بعضًا من هذه الأوامر. حيث سنبدأ بالعمل مع النسخ. الخطوة 4 – التعامل مع نسخ دوكر يتم إنشاء حاويات دوكر من نسخ دوكر عندها يقوم تلقائيًّا بسحب هذه النسخات من Docker Hub، وهو سجل تديره الشركة المسؤولة عن مشروع دوكر. حيث يمكن لأي شخص إنزال نسخ دوكر على Docker Hub، لذا فإن معظم التطبيقات وتوزيعات Linux التي ستحتاج إليها ستتم استضافتها هناك. للتحقق مما إذا كان يمكنك الوصول إلى النسخ وتنزيلها من Docker Hub، اكتب: $ docker run hello-world سيشير الإخراج إلى أن دوكر يعمل بشكل صحيح: Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world 1b930d010525: Pull complete Digest: sha256:41a65640635299bab090f783209c1e3a3f11934cf7756b09cb2f1e02147c6ed8 Status: Downloaded newer image for hello-world:latest Hello from Docker! This message shows that your installation appears to be working correctly. … بدايةً لم يتمكن دوكر من العثور على نسخة hello-world محليًا، لذلك تم تنزيل النسخة من وحدة التخزين الافتراضية Docker Hub. فبمجرد تنزيل النسخة، يقوم دوكر بإنشاء حاوية من النسخة ويتم تنفيذ التطبيق ضمن الحاوية عارضاً الرسالة. يمكنك البحث عن النسخات المتاحة على Docker Hub باستخدام أمر docker مع الأمر الفرعي search. على سبيل المثال، للبحث عن نسخة Ubuntu، اكتب: $ docker search ubuntu سيقوم هذا البرنامج بالبحث ضمن Docker Hub ويعرض قائمة بجميع النسخات التي يتطابق اسمها مع سلسلة البحث. وفي هذه الحالة، سيكون الناتج مشابهًا لما يلي: NAME DESCRIPTION STARS OFFICIAL AUTOMATED ubuntu Ubuntu is a Debian-based Linux operating sys… 9704 [OK] dorowu/ubuntu-desktop-lxde-vnc Docker image to provide HTML5 VNC interface … 319 [OK] rastasheep/ubuntu-sshd Dockerized SSH service, built on top of offi… 224 [OK] consol/ubuntu-xfce-vnc Ubuntu container with "headless" VNC session… 183 [OK] ubuntu-upstart Upstart is an event-based replacement for th… 99 [OK] ansible/ubuntu14.04-ansible Ubuntu 14.04 LTS with ansible 97 [OK] neurodebian NeuroDebian provides neuroscience research s… 57 [OK] 1and1internet/ubuntu-16-nginx-php-phpmyadmin-mysql-5 ubuntu-16-nginx-php-phpmyadmin-mysql-5 50 [OK] ubuntu … في العمود OFFICIAL، تشير OK إلى نسخة تم إنشاؤها ودعمها من قبل الشركة المسؤولة عن المشروع. فبمجرد تحديد النسخة التي ترغب باستخدامها، يمكنك تنزيلها على الحاسوب باستخدام الأمر الفرعي pull. قم بتنفيذ الأمر التالي لتنزيل نسخة ubuntu الرسمية على الحاسب: $ docker pull ubuntu سترى الناتج التالي: Using default tag: latest latest: Pulling from library/ubuntu 5b7339215d1d: Pull complete 14ca88e9f672: Pull complete a31c3b1caad4: Pull complete b054a26005b7: Pull complete Digest: sha256:9b1702dcfe32c873a770a32cfd306dd7fc1c4fd134adfb783db68defc8894b3c Status: Downloaded newer image for ubuntu:latest يمكنك بعد ذلك تشغيل حاوية باستخدام النسخة التي تم تنزيلها بالأمر run. وكما رأيت في مثال hello-world، في حال لم يتم تنزيل صورة عند تنفيذ docker باستخدام الأمر الفرعي run، فسيقوم عميل دوكر بتنزيل النسخة أولاً ثم تشغيل حاوية باستخدامها. لرؤية النسخات التي تم تنزيلها على الحاسوب، اكتب: $ docker images ستبدو المخرجات مشابهة لما يلي: REPOSITORY TAG IMAGE ID CREATED SIZE ubuntu latest 4c108a37151f 2 weeks ago 64.2MB hello-world latest fce289e99eb9 6 months ago 1.84kB كما سترى لاحقًا في هذا الدليل، يمكن تعديل النسخ التي تستخدمها لتشغيل الحاويات واستخدامها لإنشاء نسخ اخرى جديدة، والتي قد يتم رفعها بعد ذلك (يعني يتم عمل push لها حسب المصطلح التقني) إلى Docker Hub أو سجلات دوكر الأخرى. سنرى في الخطوة التالية كيفية تشغيل الحاويات بمزيد من التفاصيل. الخطوة 5 - تشغيل حاوية دوكر إن حاوية hello-world التي قمت بتشغيلها في الخطوة السابقة هي مثال على حاوية يتم تشغيلها والخروج منها بعد بث رسالة اختبار. فيمكن للحاويات ان تكون تفاعلية و أكثر فائدة من ذلك. فهي تشبه الآلات الافتراضية، لكن أكثر ملاءمة للموارد. كمثال، لنقم بتشغيل حاوية باستخدام أحدث نسخة لـ Ubuntu. حيث يمنحك الجمع بين المبدلين ‎-i و ‎-t إمكانية الوصول التفاعلي إلى القشرة في الحاوية (interactive shell access): $ docker run -it ubuntu يجب تغيير موجه الأوامر ليعكس حقيقة أنك تعمل الآن داخل الحاوية ويجب أن يأخذ هذا النموذج: root@d9b100f2f636:/# لاحظ معرف الحاوية في موجه الأوامر. نظرًا الى هذا المثال، يكون المعرف d9b100f2f636. فستحتاج إلى معرّف الحاوية هذا لاحقًا لتحديد الحاوية عندما تريد إزالتها. الآن يمكنك تشغيل أي أمر داخل الحاوية. فعلى سبيل المثال، فلنقم بتحديث قاعدة بيانات الحزمة داخل الحاوية. لست بحاجة إلى إضافة أي أمر باستخدام sudo، لأنك تعمل داخل الحاوية كمستخدم جذر (root): root@d9b100f2f636:/# apt update ثم قم بتثبيت أي تطبيق فيه. دعنا نثبت Node.js: root@d9b100f2f636:/# apt install nodejs يؤدي هذا إلى تثبيت Node.js في الحاوية من مستودع Ubuntu الرسمي. وعند انتهاء التثبيت، تحقق من تثبيت Node.js: root@d9b100f2f636:/# node -v سترى رقم الإصدار المعروض في جهازك الطرفي: v8.10.0 أي تغييرات تجريها داخل الحاوية تنطبق فقط على الحاوية نفسها. للخروج من الحاوية، اكتب exit في واجهة الأوامر. دعنا نلقي نظرة على إدارة الحاويات على نظامنا بعد ذلك. الخطوة 6- إدارة حاويات دوكر بعد استخدام دوكر لفترة من الوقت، سيكون لديك العديد من الحاويات النشطة (قيد التشغيل) وغير النشطة على الحاسوب الخاص بك. ولعرض الحاويات النشطة، استخدم: $ docker ps سترى ناتج مشابه لما يلي: CONTAINER ID IMAGE COMMAND CREATED في هذا الدليل التعليمي، بدأت حاويتين؛ واحدة من نسخة hello-world والأخرى من نسخة ubuntu. بحيث لم يعد كلا الحاويتين قيد التشغيل، لكنهما لا تزالان موجودتان على نظامك. لعرض جميع الحاويات - النشطة وغير النشطة، قم بتشغيل docker ps باستخدام المبدّل ‎-a: $ docker ps -a سترى مخرجات مشابهة لهذا: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d42d0bbfbd35 ubuntu "/bin/bash" About a minute ago Exited (0) 20 seconds ago friendly_volhard 0740844d024c hello-world "/hello" 3 minutes ago Exited (0) 3 minutes ago elegant_neumann لعرض أحدث حاوية قمت بإنشائها، قم بتشغيل docker ps باستخدام ‎-l: $ docker ps -l CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d42d0bbfbd35 ubuntu "/bin/bash" About a minute ago Exited (0) 34 seconds ago friendly_volhard لبدء تشغيل حاوية ما، استخدم docker start، متبوعًا بمعرف الحاوية أو اسم الحاوية. لنبدأ الحاوية القائمة على Ubuntu بمعرف d9b100f2f636: $ docker start d42d0bbfbd35 عندها ستبدأ الحاوية، ويمكنك استخدام docker ps لمعرفة حالتها: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d42d0bbfbd35 ubuntu "/bin/bash" About a minute ago Up 8 seconds friendly_volhard لإيقاف حاوية جارية، استخدم docker stop، متبوعًا بمعرف الحاوية أو الاسم. وهذه المرة سنستخدم الاسم الذي خصصه دوكر للحاوية، الا وهو friendly_volhard: $ docker stop friendly_volhard بمجرد أن تقرر أنك لم تعد بحاجة إلى الحاوية بعد الآن، قم بإزالتها باستخدام الأمر docker rm، مرة أخرى باستخدام إما معرف الحاوية أو إسمها. يمكنك استخدام الأمر docker ps -a للعثور على معرف الحاوية أو اسم الحاوية المرتبط بصورة hello-world وإزالتها. $ docker rm elegant_neumann يمكنك بدء حاوية جديدة وتسميتها باستخدام المفتاح--name. ويمكنك أيضًا استخدام المبدل ‎--rm لإنشاء حاوية تزيل نفسها عندما تتوقف. راجع الأمر help docker run للحصول على مزيد من المعلومات حول هذه الخيارات وغيرها. يمكن تحويل الحاويات إلى صور يمكنك استخدامها لبناء حاويات جديدة. دعونا نلقي نظرة على كيفية عمل ذلك. الخطوة 7- إحداث التغييرات في حاوية لنسخة دوكر عند بدء تشغيل نسخة من دوكر، يمكنك إنشاء الملفات وتعديلها وحذفها تمامًا كما يمكنك باستخدام جهاز افتراضي (virtual machine). حيث ستنطبق التغييرات التي تجريها على تلك الحاوية فقط.. يمكنك تشغيلها وإيقافها، لكن بمجرد ازالتها باستخدام الأمر docker rm، ستفقد التغييرات للأبد. يوضح لك هذا القسم كيفية حفظ حالة الحاوية كنسخة دوكر جديدة. بعد تثبيت Node.js داخل حاوية Ubuntu، لديك الآن حاوية تعمل على نسخة معينة، لكن هذه الحاوية مختلفة عن النسخة (image) التي استخدمتها لإنشائها. عندها قد ترغب في إعادة استخدام حاوية Node.js هذه كأساس للنسخ الجديدة لاحقًا. ثم قم بتنفيذ التغييرات على نسخة دوكر جديدة باستخدام الأمر التالي. $ docker commit -m "What you did to the image" -a "Author Name" container_id repository/new_image_name إن المفتاح ‎-m مخصص لرسالة التنفيذ (commit message) التي تساعدك والآخرين على معرفة التغييرات التي أجريتها، بينما يُستخدم ‎-a لتحديد المؤلف. معرف الحاوية container_id هو الحاوية التي لاحظتها سابقًا في الدليل عندما بدأت جلسة دوكر التفاعلية. إلا إذا قمت بإنشاء مستودعات إضافية على Docker Hub، فعادة ما يكون المستودع هو اسم مستخدم Docker Hub. على سبيل المثال، بالنسبة للمستخدم sammy بمعرّف الحاوية d9b100f2f636، سيكون الأمر كما يلي: $ docker commit -m "added Node.js" -a "sammy" d42d0bbfbd35 sammy/ubuntu-nodejs وعند تنفيذك نسخة ما، يتم حفظ النسخة الجديدة محليًا على جهاز الحاسب الخاص بك. لاحقًا في هذا الدليل، ستتعلم كيفية رفع نسخة إلى سجل دوكر مثل Docker Hub حتى يتمكن الآخرون من الوصول إليها. سيؤدي إدراج نسخ دوكر مرة أخرى إلى إظهار النسخة الجديدة، بالإضافة إلى النسخة القديمة التي تم اشتقاقها منها: $ docker images سترى مخرجات مثل هذا: REPOSITORY TAG IMAGE ID CREATED SIZE sammy/ubuntu-nodejs latest d441c62350b4 10 seconds ago 152MB ubuntu latest 4c108a37151f 2 weeks ago 64.2MB hello-world latest fce289e99eb9 6 months ago 1.84kB في هذا المثال، ubuntu-nodejs هي النسخة الجديدة التي تم اشتقاقها من نسخة ubuntu الموجودة من Docker Hub. حيث يعكس اختلاف الحجم التغييرات التي تم إجراؤها. وفي هذا المثال، كان التغيير هو تثبيت NodeJS. لذا في المرة القادمة التي تحتاج فيها إلى تشغيل حاوية باستخدام Ubuntu مع NodeJS مثبتة مسبقًا، يمكنك فقط استخدام النسخة الجديدة. يمكنك أيضًا إنشاء نسخ من ملف Dockerfile، والذي يتيح لك أتمتة تثبيت البرنامج في نسخة جديدة. لكن يعد هذا خارج نطاق المقال. الآن دعنا نشارك النسخة الجديدة مع الآخرين حتى يتمكنوا من إنشاء حاويات منها. الخطوة 8- رفع نسخ دوكر إلى مستودع دوكر الخطوة المنطقية التالية بعد إنشاء نسخة جديدة من نسخة موجودة هي مشاركتها مع عدد قليل من أصدقائك أو العالم كله على Docker Hub أو أي سجل دوكر آخر يمكنك الوصول إليه. و لرفع نسخة ما إلى Docker Hub أو أي سجل دوكر آخر، يجب أن يكون لديك حساب هناك. يوضح لك هذا القسم كيفية رفع نسخة دوكر إلى Docker Hub. ولمعرفة كيفية إنشاء سجل دوكر الخاص بك، تفقد كيفية إعداد سجل دوكر خاص على Ubuntu 14.04 لرفع نسختك، قم أولاً بتسجيل الدخول إلى Docker Hub. $ docker login -u docker-registry-username عندها ستتم مطالبتك بالمصادقة باستخدام كلمة مرور Docker Hub. و إذا حددت كلمة المرور الصحيحة، فيجب أن تنجح المصادقة. ملاحظة: إذا كان اسم مستخدم سجل دوكر الخاص بك مختلفًا عن اسم المستخدم المحلي الذي استخدمته لإنشاء النسخة، فسيتعين عليك وضع علامة على نسختك باسم مستخدم التسجيل خاصتك. بالنسبة للمثال الوارد في الخطوة الأخيرة، اكتب: $ docker tag sammy/ubuntu-nodejs docker-registry-username/ubuntu-nodejs ثم يمكنك رفع نسختك باستخدام: $ docker push docker-registry-username/docker-image-name لرفع نسخة ubuntu-nodejs إلى مستودع sammy، سيكون الأمر على الشكل التالي: $ docker push sammy/ubuntu-nodejs قد تستغرق العملية بعض الوقت حتى تكتمل أثناء تحميل النسخ، ولكن عند اكتمالها سيبدو الإخراج كما يلي: The push refers to a repository [docker.io/sammy/ubuntu-nodejs] e3fbbfb44187: Pushed 5f70bf18a086: Pushed a3b5c80a4eba: Pushed 7f18b442972b: Pushed 3ce512daaf78: Pushed 7aae4540b42d: Pushed … بعد رفع النسخة إلى السجل، يجب أن تكون مدرجة في لوحة تحكم حسابك مثل تلك التي تظهر في الصورة أدناه. إذا أظهرت محاولة الرفع خطأ من هذا النوع، فمن المحتمل أنك لم تقم بتسجيل الدخول: The push refers to a repository [docker.io/sammy/ubuntu-nodejs] e3fbbfb44187: Preparing 5f70bf18a086: Preparing a3b5c80a4eba: Preparing 7f18b442972b: Preparing 3ce512daaf78: Preparing 7aae4540b42d: Waiting unauthorized: authentication required قم بتسجيل الدخول باستخدام docker login وتكرار محاولة الرفع. ثم أثبت وجوده في صفحة مستودع Docker Hub الخاص بك. يمكنك الآن استخدام docker pull sammy/ubuntu-nodejs لسحب النسخة إلى جهاز جديد واستخدامها لتشغيل حاوية جديدة. الخلاصة لقد قمت بتثبيت دوكر، وعملت بالنسخ والحاويات، ورفعت نسخة معدلة إلى Docker Hub. الآن بعد أن تعرفت على الأساسيات، استكشف بقية دروس أكاديمية حسوب قسم DevOps. ترجمة -وبتصرف- للمقال How To Install and Use Docker on Debian 10 لصاحبه Brian Hogan

يعتبر دوكر Docker من أشهر التطبيقات مفتوحة المصدر لإنشاء وإدارة ونشر استنساخ التطبيقات باستخدام الحاويات، فالحاوية هي حزمة تحتوي على متطلبات التطبيق للعمل على مستوى نظام التشغيل أي أن التطبيق المنشور باستخدام Docker يعمل في بيئته الخاصة ويُتعامل مع متطلباته بشكل منفصل. أما Flask فهو إطار ويب مصغّر (micro-framework) مبني باستخدام لغة بايثون، وتعود تسميته بالإطار المصغّر لأنه لا يحتاج إلى أدوات محدّدة أو مكونات إضافيّة لكي يعمل، بالإضافة إلى أنه يتميّز بالخفّة والمرونة وبدرجة عالية من التنظيم مما يجعل المبرمجين يفضلونه على بقية الإطارات. سيسمح لك نشر تطبيق Flask باستخدام Docker باستنساخ التطبيق على مختلف الخوادم بأقل إعدادات ممكنة، لذا سنرى كيفية إنشاء تطبيق Flask و نشره باستخدام Docker بالإضافة إلى كيفية تحديث التطبيق بعد نشره. المتطلبات الأساسية لمتابعة هذا الدرس، ستحتاج إلى ما يلي: مستخدم عادي - ليس جذر - مع صلاحيات sudo معّد باستخدام هذا الدليل خادم أوبنتو 18.04 مع Docker، يمكنك إعداده عن طريق اتباع الخطوات في هذا الدرس أو عن طريق استخدام ميّزة التثبيت الخاصة بـ DigitalOcean في هذا الدرس تثبيت Nginx بإتباع الخطوة الأولى من هذا الدرس الخطوة الأولى - إعداد تطبيق Flask ستحتاج إلى إنشاء هيكل مجلدات تطبيقك، لذلك أنشئ مجلدًا في ‎/var/www وسمّهِ على سبيل المثال TestApp: sudo mkdir /var/www/TestApp ثم انتقل إلى هذا المجلد باستخدام الأمر: cd /var/www/TestApp وبعد ذلك، أنشئ المجلد الرئيسي لتطبيق Flask: sudo mkdir -p app/static app/templates تشير راية ‎-p إلى أن mkdir سينشئ المجلد مع جميع المجلدات الرئيسية غير الموجودة، وفي هذه الحالة، سينشئ mkdir مجلد الأب app حتى يتمكن من إنشاء مجلدات static و templates داخله. سيحتوي المجلد app على جميع الملفات المتعلّقة بتطبيق Flask مثل الواجهات (views) والمخططات الأوليّة (blueprints). فالواجهة هي الشيفرة البرمجيّة التي تكتبها للاستجابة إلى طلبات تطبيقك، أما المخططات الأوليّة فتنشئ مكونات التطبيق وتدعم الأنماط الشائعة داخل التطبيق أو عبر تطبيقات مختلفة. ستضع جميع الأصول مثل الصور وملفات CSS وملفات جافاسكربت في مجلد static ، وأما بالنسبة لقوالب HTML فستضعهم في مجلد templates. والآن، بعد أن أنشأنا هيكل المجلدات الأساسية، فسننشئ الملفات التي نحتاجها لتشغيل تطبيق Flask. أنشئ أولًا ملف ‎__init__.py داخل مجلد app، سيجعل هذا الملف مفسر بايثون يتعامل مع مجلد app كحزمة. أنشئ ملف ‎__init__.py باستخدام الأمر التالي: sudo nano app/__init__.py تسمح لك الحزم في بايثون بجمع الوحدات إلى مساحات أسماء منطقيّة أو تسلّسلات هرميّة لكي تتمكن من تقسيم الشيفرة البرمجيّة إلى كتل منفصلة قابلة للإدارة ذات وظائف معيّنة. بعد ذلك، ستضيف شيفرة برمجيّة إلى ‎__init__.py لإنشاء نسخة من Flask واستدعاء المنطق الموجود في ملف views.py، والذي ستنشئه بعد إنهائك لهذا الملف. أضف الشيفرة البرمجيّة التاليّة إلى الملف الجديد: from flask import Flask app = Flask(__name__) from app import views ستنشئ الآن ملف views.py في مجلد app، سيحتوي هذا الملف على أغلب منطق التطبيق. sudo nano app/views.py بعد ذلك أضف هذه الشيفرة البرمجيّة إلى ملف views.py، ستُعيد هذه الشيفرة البرمجيّة السلسلة النصيّة ‎hello world!‎ إلى زوار صفحة الويب. from app import app @app.route('/') def home(): return "hello world!" يسمى السطر ‎@app.route‎‏ فوق الدالة بالمزخرِف ويعمل على تعديل الدالة التي بعده، وفي هذه الحالة، سيخبر المزخرِف Flask أي رابط URL ستنفّذ دالة home‎‎()‎، وأما بالنسبة إلى النص hello world المُعاد من الدالة home فسيظهر للمستخدم في المتصفّح. الآن، بعد الانتهاء من ملف views.py، فنحن مستعدين لإنشاء ملف uwsgi.ini الذي سيحتوي على إعدادات uWSGI لتطبيقنا وهذا الأخير عبارة عن خيار نشر لـ Nginx والذي هو خادم لكل من البروتوكول والتطبيق، أي يخدم بروتوكولات uWSGI و FastCGI و HTTP. استخدم الأمر التالي لإنشاء هذا الملف: sudo nano uwsgi.ini بعد ذلك، أضف هذه الإعدادات إلى الملف لإعداد خادم uWSGI: [uwsgi] module = main callable = app master = true تعرّف هذه الشيفرة البرمجية الوحدة التي سيعمل منها تطبيق Flask، والتي هي في هذه الحالة ملف main.py، ولقد أشرنا إليه بـ main. وبالنسبة إلى خيار callable فهو يخبر uWSGI باستخدام نسخة من app المصدّر من التطبيق الرئيسي. ويسمح الخيار master للتطبيق أن يعمل دائمًا ولن يتوقف إلا لبعض الوقت عند إعادة تحميل التطبيق كاملًا. بعد ذلك، أنشئ ملف main.py ليكون مدخل تطبيقك، فالمدّخل يخبر uWSGI عن كيفية التعامل مع تطبيقك. sudo nano main.py والآن، أضف السطر التالي إلى الملف حيث أن هذا الأخير سيستدعي نسخة من Flask يسمى app من حزمة التطبيق التي أنشأناها سابقًا. from app import app وفي النهاية، أنشئ الملف requirements.txt لتحديد الاعتماديات التي سيثبتها مدير الحزم pip إلى نشر Docker الخاص بك: sudo nano requirements.txt أضف السطر التالي في الملف ‎/var/www/TestApp/app/requirements.txt لإضافة Flask كتبعيّة: Flask==1.0.2 يحدد هذا السطر نسخة Flask التي يجب تثبيتها، والتي هي في وقت كتابة هذا المقال، النسخة 1.0.2، ويمكنك التأكد من التحديثات على الموقع الرسمي لـ Flask. والآن لقد أنتهيت من إعداد تطبيق Flask ومستعد لإعداد Docker. الخطوة الثانية - إعداد Docker سننشئ في هذه الخطوة ملفين، Dockerfile و start.sh لإنشاء نشر Docker الخاص بك، فملف Dockerfile هو مستند نصي يحتوي على الأوامر التي تُستخدم لتجميع الصورة (image) وأما بالنسبة لملف start.sh فهو سكربت shell الذي سيبني الصورة وسينشئ الحاوية من ملف Dockerfile. أنشئ أولًا ملف Dockerfile: sudo nano Dockerfile بعد ذلك، أضف إعداداتك التي ترغب بها إلى Dockerfile، ستحدّد هذه الأوامر كيف ترغب ببناء الصورة وكيف ستضاف المتطلبات الإضافيّة. الملف ‎/var/www/TestApp/Dockerfile: FROM tiangolo/uwsgi-nginx-flask:python3.6-alpine3.7 RUN apk --update add bash nano ENV STATIC_URL /static ENV STATIC_PATH /var/www/app/static COPY ./requirements.txt /var/www/requirements.txt RUN pip install -r /var/www/requirements.txt في هذا المثال، سنبني صورة Docker (أي image) من صورة موجودة بالفعل وهي tiangolo/uwsgi-nginx-flask ويمكنك إيجادها على DockerHub وتعتبر هذه الصورة من أفضل الصور الموجودة لأنها تدعم العديد من نسخ بايثون بالإضافة إلى أنظمة التشغيل المختلفة. أول سطرين سيحددان الصورة الرئيسيّة التي ستستخدمها لتشغيل التطبيق وتثبيت معالج أوامر Bash والمحرّر النصي nano، وستثبت أيضًا عميل git للسحب والدفع إلى خدمات استضافة التحكّم بالإصدارات مثل GitHub و GitLab و Bitbucket. أما بالنسبة إلى ENV STATIC_URL /static فهو متغيّر البيئة الخاص بصورة Docker الحالية ويحدد الملف الثابت (static) الذي سيحتوي على جميع الأصول مثل الصور وملفات CSS و ملفات جافا سكربت. بالنسبة لآخر سطرين فستنسخ الملف requirements.txt إلى الحاوية ومن ثم ستثبّت التبعيات. والآن، بعد أن أنهينا ملف Dockerfile، أصبحنا مستعدين لإنشاء ملف start.sh الذي سيبني حاوية Docker، وقبل كتابة سكربت start.sh، تأكد من وجود منفذ (port) مفتوح لاستخدامه في الإعدادات، ويمكنك التأكد من ذلك عن طريق تشغيل الأمر التالي: sudo nc localhost 56733 < /dev/null; echo $? إذا كانت مخرجات الأمر السابق هي 1 فهذا المنفذ مفتوح ويمكن استخدامه، وخلافا ذلك، ستحتاج إلى اختيار منفذ آخر لاستخدامه في ملف إعدادات start.sh. بمجرّد أن تجد منفذ مفتوح للاستخدام، أنشئ سكربت start.sh: sudo nano start.sh سيبني سكربت start.sh ملف Dockerfile وينشئ الحاوية من صورة Docker، ولهذا سنضيف إلى الملف ‎‎/var/www/TestApp/start.sh‎ الإعدادات التالية: #!/bin/bash app="docker.test" docker build -t ${app} . docker run -d -p 56733:80 \ --name=${app} \ -v $PWD:/app ${app} يسمى السطر الأول بـ shebang، وهو يحدد أن هذا الملف هو ملف bash وستُنفّذ أوامره، وأما السطر الثاني فيحدّد اسم الصورة والحاوية وستُحفظ على شكل متغيّر يسمى app. أما السطر التالي فيخبر Docker ببناء الصور من ملف Dockerfile الموجود في المجلّد الحالي، وفي هذا المثال، سينشئ صورة تسمى docker.test. الأسطر الثلاثة الأخيرة تنشئ حاوية تسمى docker.test والتي تعمل على المنفذ 56733، وفي النهاية، تربط المجلد الحالي بمجلد ‎‎‎/var/www في الحاوية. يمكنك استخدام الراية ‎-d لتشغيل الحاوية في وضع العفريت (daemon mode) أو كعملية خلفيّة (background process)، ويمكنك تضمين الراية ‎-p لربط منفذ الخادم إلى منفذ معيّن في حاوية Docker، وفي هذه الحالة ستربط منفذ 59733 بمنّفذ 80 في حاوية Docker. بالنسبة إلى الراية ‎-v ‏(volume) ‏فيحدد مكان Docker لوصله في الحاوية. شغّل سكربت start.sh لإنشاء صورة Docker وبناء حاوية من الصورة: sudo bash start.sh بمجرّد الانتهاء من الأمر السابق، استخدم الأمر التالي لعرض جميع الحاويات التي تعمل: sudo docker ps سيظهر لك شيء مشابه لهذا: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 58b05508f4dd docker.test "/entrypoint.sh /sta…" 12 seconds ago Up 3 seconds 443/tcp, 0.0.0.0:56733->80/tcp docker.test سترى أن حاوية docker.test تعمل، والآن لنزور عنوان IP في المنفذ الذي اخترناه في متصفحك: http://ip-address:56733 ستشاهد صفحة مشابهة لهذه الصفحة: في هذه الخطوة نجحنا في نشر تطبيق Flask على Docker، سنستخدم في الخطوة التالية القوالب لعرض المحتوى إلى المستخدمين. الخطوة الثالثة - خدمة ملفات القوالب القوالب هي ملفات لعرض محتوى ثابت وحيوي لزوار تطبيقك، في هذه الخطوة، سننشئ قالب HTML لإنشاء الصفحة الرئيسية لتطبيقك. إبدأ بإنشاء ملف home.html في مجلد app/templates: sudo nano app/templates/home.html أضف الشيفرة البرمجية إلى قالبك لإنشاء صفحة HTML5 تحتوي على عنوان وبعض النصوص. الملف ‎/var/www/TestApp/app/templates/home.html: <!doctype html> <html lang="en-us"> <head> <meta charset="utf-8"> <meta http-equiv="x-ua-compatible" content="ie=edge"> <title>Welcome home</title> </head> <body> <h1>Home Page</h1> <p>This is the home page of our application.</p> </body> </html> بعد ذلك، عدّل على ملف app/views.py لخدمة الملف المنشئ حديثًا: sudo nano app/views.py أضف أولا السطر التالي إلى بداية ملفك لإستدعاء أسلوب render_template من Flask والذي يرمّز صفحة HTML لتصيير (render) صفحة ويب للمستخدم. from flask import render_template ... أضف مسار (route) آخر في نهاية الملف لتصيير ملف القالب حيث ستحدّد هذه الشيفرة البرمجية أن المستخدمين سيخدمون بمحتوى ملف home.html عند زيارة مسار ‎/template في تطبيقك. ... @app.route('/template') def template(): return render_template('home.html') سيبدو ملف app/views.py بعد تحديثه كالتالي: from flask import render_template from app import app @app.route('/') def home(): return "Hello world!" @app.route('/template') def template(): return render_template('home.html') من أجل تفعيل هذه التغييرات، ستحتاج إلى إيقاف وإعادة تشغيل حاويات Docker. شغّل الأمر التالي لإعادة بناء الحاوية: sudo docker stop docker.test && sudo docker start docker.test زر تطبيقك الآن على http://your-ip-address:56733/template لمشاهدة خدمة القالب الجديد. في هذه الخطوة أنشأت ملف قالب Docker لخدمة زوار تطبيقك وفي الخطوة القادمة سنرى كيف يمكنك تفعيل التغييرات دون الحاجة إلى إعادة تشغيل حاوية Docker. الخطوة الرابعة - تحديث التطبيق ستحتاج في بعض الأحيان إلى القيام ببعض التغييرات في تطبيقك مثل تثبيت متطلبات جديدة، تحديث حاوية Docker أو تغيير شيفرة HTML أو المنطق، لذلك، سنتحدّث الآن عن إعداد touch-reload للقيام بهذه التغييرات دون الحاجة إلى إعادة تشغيل حاوية Docker. يراقب بايثون autoreloading نظام الملفات للتغييرات وتحديث التطبيق عند إيجاد تغيير، وهذه العملية غير منصوح بها عند مرحلة الإنتاج (production) لأنها ستستهلك الكثير من الموارد. سنستخدم touch-reload لمراقبة التغييرات لملف معيّن وإعادة التحميل عند تحديث أو استبدال هذا الملف. لفعل ذلك، نبدأ بفتح ملف uwsgi.ini: sudo nano uwsgi.ini ونضيف هذا السطر الأخير إلى نهاية ملف uwsgi.ini كما هو موضح في الشيفرة التالية: module = main callable = app master = true touch-reload = /app/uwsgi.ini يحدد هذا السطر الملف الذي يجب التعديل عليه لإعادة تحميل كامل التطبيق. لمشاهدة هذا، غيّر قليلا في تطبيقك، فعلى سبيل المثال، افتح ملف app/views.py: sudo nano app/views.py استبدل السلسلة النصيّة التي تعود من الدالة home: from flask import render_template from app import app @app.route('/') def home(): return "<b>There has been a change</b>" @app.route('/template') def template(): return render_template('home.html') والآن، إذا فتحت الصفحة الرئيسية لتطبيقك على http://ip-address:56733 ستلاحظة عدم ظهور التغييرات، وهذا بسبب أن شرط إعادة التحميل هو تغيير ملف uwsgi.ini، لذا استخدم touch لتفعيل هذا الشرط: sudo touch uwsgi.ini أعد تحميل صفحة الرئيسية في تطبيقك على متصفحك مرّة أخرى، ستظهر لك التغييرات: في هذه الخطوة، أعددت شرط touch-reload لتحديث تطبيقك بعد القيام بتغييرات. الخلاصة في هذا الدرس، أنشأت ونشرت تطبيق Flask على حاوية Docker، ولقد أعددّت touch-reload لإعادة تحميل التطبيق دون الحاجة إلى إعادة تشغيل الحاوية. يمكنك الآن التوسع أكثر واكتشاف Docker بطريقة معمّقة، ويمكنك البدء بالتوثيق الرسمي ترجمة -وبتصرف- للمقال How To Build and Deploy a Flask Application Using Docker on Ubuntu 18.04 لصاحبه Michael Okoh

يُوفِّر Docker كل الدّوال (Functions) المطلوبة لبناء، رفع Upload، تنزيل Download، بدْء تشغيل وإيقاف الحاويّات؛ وهو مناسِب جدًّا لإدارة كل هذه العمليّات في بيئة من مُستضيف وحيد بعدد محدود من الحاويّات. رغم ذلك يلجأ كثيرون لاستخدام هذه المنصّة كأداة لبناء حاويّات تتوزَّع على عدّة مستضيفات مختلفة. تُمثِّل إدارة عناقيد من المُستضيفات Clustered hosts تحدِّيًّا جدّيًا يتطلّب مجموعةً مختلفة من الأدوات. سنعرِض في هذا المقال المُجدوِلاتِ Schedulers وأدواتِ التّنسيق Orchestration المُستَخدمةَ مع Docker. تُمثّل هذه الأدوات الواجهة الرّئيسة لإدارة الحاويّات والنّشر المُوزَّع. جدولة الحاويات، التنسيق وإدراة العنقودالقدرة على إدارة كل نظام مُستضيف وتفادي تعقيدات البنية التّحتيّة لبيئة العمل هي إحدى الوظائف الأكثر جاذبية عند التّطرق إلى توسّع Scaling التّطبيقات عبر عدة أنظمة مستضيفة. يظهر في هذا الإطار مُصطلح التّنسيق الّذي يشمل جدولة الحاويّات، وإدارة العنقود، وفي بعض الأحيان تجهيز وإعداد مُستضيفات جديدة. تُحيل الجدولة Scheduling عند الحديث عن النّظام البيئي لDocker إلى القدرة على رفع ملفّ يُعرِّف كيفيّة تشغيل حاويّة مُعيَّنة إلى النّظام المُستضيف؛ في حين نعني بالمُجدوِلات الأدواتِ المسؤولةَ عن التّدخّل في نِظام التّهيِئة الأوّليّة Init system لإدارة الخدمات حسب المطلوب. أمّا إدارة العنقود فتُشير إلى التّحكّم في مجموعة من المُستضيفات. يُمكِن أن تشمل هذه العمليّة إضافة أو إخراج مُستضيفات من العنقود، الحصول على معلومات عن حالة المُستضيفات أو الحاويّات، وبدْء تشغيل أو إيقاف العمليّات Processes. ترتبط إدارة العنقود بشكل وثيق مع الجدولة، إذ يجب أن تكون لدى المُجدوِل القدرةُ على الوصول إلى كل واحد من المستضيفات الموجودة في العنقود من أجل جدولة الخدمات. لهذا السبّب يغلُب استخدام نفس الأداة للتّنسيق والجدولة. من أجل إدارة وتشغيل الحاويّات على المُستضيفات المتواجدة على العنقود، يجب على المُجدوِل التّعاطي مع نظام التهيئة الأوّليّة لكلّ واحد من المُستضيفات. يجب على المُجدوِل في نفس الوقت، لتسهيل الإدارة، تقديمُ رؤية مُوَّحّدة لحالة الخدمات على كامل العنقود؛ ممّا يقوده إلى أن يعمل كنظام تهيئة أوليّة عابر للعنقود. لهذا السّبب تلجأ العديد من المُجدوِلات إلى أخذ صوّر طبق الأصل من بنية أوامر أنظمة التّهيئة الأوّليّة، ثمّ تعمل على تجريدها Abstract (إخفاء تعقيدات التّعامل مع بنية هذه الأنظمة). يُعتَبر اختيّارُ المُستضيف أحد أهمّ مسؤوليّات المُجدوِل، حيثُ إنه يتولّى تحديد المُستضيف الّذي ستعمل عليه الخدمة (الحاويّة) أوتوماتيكِيًّا بعدَ اتّخاذ المُدير قرار تنفيذها. يُمكِن للمُدير تحديد قيود على اختيّار المُستضيف، لكن في النّهاية المُجدوِل هو من سيُنفّذ هذه التّعليمات. كيف يتّخذ المُجدوِل قراراته؟تُعرِّف المجدوِلات عادةً سياسة افتراضيّة للجدولة. تُحدِّد هذه السّيّاسة كيف ستُنَفَّذ الخدمات في حال عدم وجود مُدخَلات من طرف المُدير. على سبيل يُمكن أن تكون السّيّاسة الافتراضيّة هيّ وضع الخدمات الجديدة على المُستضيفات الّتي يوجد بها أقلّ عدد من التّطبيقات النّشِطة. تُتيح المُجدوِلات إمكانيّة إعادة كتابة آليّاتِها، ممّا يسمح للمُديرين بتدقيق ضبط عمليّة الاختيّار لتستجيبَ لمُتطَلَّبات مُحدَّدة. على سبيل المثال، إذا وجَب تشغيل حاويّتَين على نفس المُستضيف لكونهما تعملان كوِحدة Unit، فيُمكِن إعلان هذا الغرض أثناء الجدولة. بالمِثل، يُمكِن فصلُ حاويَّتيْن بحيثُ لا تعملان على نفس المُستضيف، لأغراض تتعلّق بالتّوفّر العالي High availability لنظيرَيْن Instances من نفس الخدمة على سبيل المثال. قد تُمثَّل القيود الّتي يُمكِن لمُجدوِل أخذها في الحسبان، على هيأة بيانات وصفيّة Metadata مُوَّجَّهة لأغراض التّحكّم، فتُوضع لصائق Labels على المُستضيفات ليستعين بها المُجدوِل. يكون هذا ضروريًّا إذا كان المُستضيف يحوي تجزئةَ بيانات Data volume يحتاجها أحد التّطبيقات. تحتاج بعض الخدمات إلى أن تُنشَر على كلّ مُستضيف في العنقود، وهو ما تُتيحه المُجدوِلات. ما وظائف إدارة العنقود التي توفرها المُجدوِلات؟ترتبِط وظيفتا الجدولة وإدارة العنقود ارتباطًا وثيقًا لأنّ كلًّا منهما تتطلّب القدرة على العمل على مُستضيفات مُحدَّدة وعلى العنقود ككلّ. تُستخدَم برامج إدارة العناقيد لطلب معلومات عن أعضاء عنقود، إضافة أو حذف أعضاء، أو حتّى الاتّصال بمُستضيف مُعيَّن لإدارة أكثر تخصيصًا. يُمكِن أن تُضاف هذه الوظائف إلى المُجدوِل كما يُمكِن إدراجها ضمن مسؤوليّة برنامج مُستقلّ. ترتبِط إدارة العنقود في كثيرٍ من الحالات بأداة استكشاف الخدمة أو مخزن إعدادات بصيغة مفتاح-قيمة. يُفيد هذا الارتباط في توزيع المعلومات وحفظها عبرَ كامل العنقود، كما أنّ المنصّة في هذه الحالة جاهزة لوظيفتها الأوليّة. في هذه الحالة (ارتباط أداة الإدارة باستكشاف الخدمة ومخزن الإعدادات) يحتاج إجراء بعض مهامّ إدارة العنقود، إن لم تتوفّّر طُرُق Methods للتّخاطُب مع المُجدوِل، إلى تغيير قيّم موجودة في مخزن الإعدادات عن طريق واجهته لبرمجة التّطبيقات Application programming interface, API. على سبيل المثال: تُغَيَّر عضويّات العنقود عن طريق التّعديل على قيّم في مخزن الإعدادات. يُحتفَظ بالبيانات الوصفيّة المُتعلِّقة بالمُستضيفات في مخزن الإعدادات؛ حيثُ يُمكن استخدامها كما ذكرنا سابِقًا لاستهداف مستضيف أو مجموعة من المُستضيفات بقرارات جدولة. كيف تكون الجدولة في حالة تجميع الحاويّات؟يتوجّب في بعض الأحيان إدارة عدّة خدمات كما لو كانت تطبيقًا واحدًا، ففي بعض الحالات لا يُمكن حتى نشر خدمة دون نشر خدمة أخرى مُصاحِبة لها، لارتباط عملهما. تُوفّر عدّة مشاريع تنسيقًا متقدِّمًا يأخذ في الحسبان تجميع الحاويّات، ولهذه الوظيفة عدّة فوائد. تسمح إدارة الحاويّات على مجموعات للمُدير بالتّعامل مع تشكيلة من الحاويّات على أنّها تطبيق واحد. يُبسِّط تشغيلُ عدّة عناصر مُرتبِطة بإحكام إدارةَ التّطبيقات دون أن يكون ذلك على حساب فوائد تقسيمها إلى حاويّات لكلٍّ منها وظيفة منفصِلة؛ حيثُ يسمح للمُدير بالحفاظ على فوائد استخدام التّصميم خدَمي التّوجّه Service-oriented مع تقليل جهد الإدارة. يُمكِن أن يعنيَ تجميعُ التّطبيقات ببساطة جدولتَها وإتاحة إمكانيّة تشغيلها أو إيقافها معًا؛ كما أنّه قد يُشير إلى تصوّرات أكثر تعقيدًا مثل فصل كل مجموعة ضمن شبكة فرعيّة أو العمل على توسّع Scaling مجموعة من الحاويّات بدل العناية بالتّوسّع الفردي لكل واحدة منها. ماذا نعني بالتّجهيز Provisioning؟يرتبِط مفهوم التّجهيز بإدارة العناقيد. نعني بالتّجهيز مجموعة الآليّات الّتي تسمح بإضافة وإعداد مُستضيفات جديدة لتكون جاهزةً للعمل ضمن العنقود. في حالة نشر التّطبيقات عبر Docker فإنّ التّجهيز يعني إعداد Docker وضبطَ المُستضيف الجديد للالتحاق بعنقود موجود. تختلف طريقة التّجهيز بشكل كبير حسب الأدوات المُستخدَمة ونوعيّة المُستضيف، ولكن الهدف في الأخير هو نظام جديد جاهز للعمل. على سبيل المثال، إذا كان المُستضيف آلة تخيّليّة Virtual machine فإن أدواتٍ مثل Vagrant يُمكِن أن تُستخدَم لإعداد المستضيف الجديد. يسمح معظَم مزوّدي الخدمات السّحابية Cloud providers بإنشاء مُستضيفات جديدة اعتمادًا على واجهة تطبيقات برمجيّة API. على الجانب الآخر، يحتاج تجهيزُ عتاد خام (حاسوب بدون نظام تشغيل) لتدخّل يدوي أكثر؛ يُمكن اللّجوء إلى أدوات مثل Ansible، Puppet، Chef أو Salt من أجل الإعداد التّمهيدي للمُستضيف وتجهيزه بالمعلومات المطلوبة للاتّصال بالعنقود. يوجد خيارات للتّجهيز: إمّا أن يكون عمليّة يدويّة يُطلِقها المُدير، أو أن يكون جزْءًا من أدوات إدارة العنقود من أجل أتممة التوسّع Automation. يتطلّب الخيّارُ الأخير تعريفَ إجراء يطلُب مُستضيفات جديدة والشّروط الّتي يجب أن يحصُل حسبها الطّلب. على سبيل المثال، إذا كان تطبيقٌ يُعاني من الحِمل الزّائد على الخادوم، فيُمكِن ضبط مُستضيفات وإلحاقُها بالنِّظام لتتوسَّعَ الحاويّات أفقيًّا عبر البُنية التّحتيّة الجديدة، من أجل التّخفيف من الضّغط على الخادوم. ماهيّ المُجدوِلات الأكثر انتشارًا؟من بين المشاريع الأكثر شهرةً في الجدولة وإدارة العناقيد (الوظائف الأساسيّة): Fleet: أداة الجدولة وإدارة العناقيد ضمن توزيعة CoreOs. تقرأ Fleet معلومات الاتّصال لكل مُستضيف في العنقود من etcd ( أداة استكشاف خدمة وإعداد عموميّ مُوزَّع لكل من الحاويّات والأنظمة المُستضيفة، جزْء من توزيعة CoreOs) وتُوفِّر خدمة إدارة شبيهة بSystemd (نِظام تهيئة أوّليّة بدأت الكثير من توزيعات غنو/لينوكس اعتمادَه ليكون بديلًا عن أنظمة التّهيِئة الأوّليّة التّقليديّة). Marathon: وهو العنصُر المسؤول عن الجدولة وإدارة الخدمات في Mesosphere (نظام تشغيل مُوجَّه لإدارة مراكز البيانات Data centers). يعمل مع mesos (أداة لتجريد وإدارة جميع موارد العنقود) للتّحكّم في الخدمات الّتي تعمل لفترات زمنيّة طويلة. كما أنّه يُوفِّر واجهة ويب لإدارة الحاويّات. Swarm: أعلن مشروع Docker عن مُجدوِل Swarm في ديسمبر/كانون الأوّل سنة 2014، ويأمل في أن يُقدِّمَ مجدوِلًا جيّدًا يُمكنه تقسيم الحاويّات على المُستضيفات المُجهَّزَة على Docker، وذلك باستخدام نفس الصّيّاغة Syntax الّتي يستخدمها Docker. بالنّسبة للجدولة المُتقدّمة والتّحكّم في مجموعات الحاويّات، توجد المشاريع التّاليّة: kubernetes: مُجدوِل مُتقدّم من Google. يُتيح kubernetes تحكّمًا متقدّمًا في الحاويّات؛ حيث يُمكِن توصيف الحاويّات، تجميعها، وإعطاءُها شبكات فرعيّة مستقلّة للاتّصال. compose: مشروع تابِع لـ Docker، أُنشِئ لإضافة إمكانيّة إدارة مجموعات من الحاويّات باستخدام ملفّات إعداد تقريريّة Declarative. يستخدِم روابط Docker لمعرفة معلومات عن علاقات التّبعيّة بين الحاويّات. خلاصةتُمثِّل إدارة العناقيد والجدولة جزأين مهمَّيْن من إعداد وتنفيذ خدمات تعتمد على الحاويّات في بيئة مُوزَّعة مُكوَّنة من عدّة مُستضيفات، إذ تُوفِّران الوظائف الأساسيّة من أجل بدْء تشغيل الخدمات والتّحكّم فيها. يُمكِن عبر استخدام المُجدوِلات بفعاليّة إحداثُ تغييرات كبيرة على عمل التّطبيقات، بالقليل من الجُهد.