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

الذكاء الصنعي وخوارزميات تعلم الآلة AI/ML تتفق جميع التقنيات والخوارزميات التي تندرج تحت مسمى الذكاء الصنعي Artificial Intelligence وتعلم الآلة Machine Learning باختلاف أطيافها على البدء بتحليل البيانات الخام والبحث فيها (بطرق خوارزمية ممنهجة) لاستكشاف ما تحتويه من أنماط وعلاقات في داخلها وبين كياناتها. إن معرفة مثل تلك الأنماط والعلاقات ستساعدنا على بناء نماذج قادرة على استقراء الجوهر العام المشترك الذي يجمع ويصنف تلك الكتل من البيانات على الرغم من الاختلافات في التفاصيل الهامشية والتي قد تكون كبيرة ظاهريا ومربكة في عين من لا يتمتع بالخبرة في مجال الدراسة. لقد أثبتت مثل هذه النظم فعاليتها في حوسبة العديد من المهام التي كان يعتقد حتى وقت قريب أنها عصية على عالم البرمجيات، ساعد على ذلك الطفرة التي شهدتها عتاديات الحواسيب في العقد الأخير والتقدم الهائل في إمكانيات الحوسبة المتوازية لوحدات المعالجة الرسومية GPU، وكذلك توافر حلول الحوسبة السحابية لشريحة أكبر من فرق التطوير البرمجية التي كان يصعب عليها في الماضي الحصول على حواسيب فائقة بسهولة. إننا نشهد في الفترة الحالية انتقالا وتحولا جذريا في مفاهيم علم البرمجة مقارنة بما سبق وبما تعلمناه أو استخدمناه خلال القرن الماضي (كالبرمجة الوظيفية ومخططات سير العمل، أو حتى البرمجة الغرضية التوجه بكائناتها وطرائقها)، فالمبرمج هو من كان يضع منطق العمل وخوارزميته ليحدد أسلوب معالجة المدخلات وتوليد المخرجات، وقد امتازت فترة ثمانينيات وتسعينيات القرن الماضي بوفرة القدرة الحاسوبية مقارنة بكمية البيانات المتوافرة للمعالجة أصلا، لكن ما نشهده الآن في القرن الحادي والعشرين قد قلب هذه المعادلة رأسا على عقب، فقد أصبح لدينا فائض كبير من البيانات التي تجمع من كل حدب وصوب على مدار الساعة بدءا من جوالاتنا (التي ما عادت وسيلة للاتصال فقط) وصولا إلى الأقمار الاصطناعية في مداراتها حول الأرض. إن هذا المستوى العالي من الأتمتة في حياتنا ومجتمعاتنا نتج عنه كم هائل من البيانات التي تجاوزت بمراحل القدرة على تحليلها واستخلاص المعلومات منها بالطرق التقليدية، وهو ما أعاد فتح الأبواب مجددا لتقنيات الذكاء الصنعي التي كان لها مجد سابق منتصف القرن الماضي لكنه زال بعد أن عجزت القدرات العتادية في ذلك الحين عن مواكبة شطحات المتنورين من رواد هذا الحقل من العلوم، لكننا اليوم وبتضافر جهود الباحثين في مجالات شتى مثل علم البيانات والإحصاء والحواسيب بلا شك، أصبحنا قادرين على تنفيذ ما كانوا يتحدثون عنه ضمن طيف واسع من التطبيقات ربما بات يتجاوز أقصى طموحاتهم. الشبكات العصبية Neural Networks في جزء من لوحة رافائييل الجصيّة "مدرسة أثينا" تم رسم أفلاطون وأرسطو بشكل يعبّر عن نظريّة كل منهما في المعرفة، فأرسطو يومئ نحو الأرض فيما يشير أفلاطون بإصبعه نحو السماء، حيث كان ينظر أرسطو إلى الطبيعة بحثا عن إجابات في حين أن أفلاطون يبحث عن المثالي. وها نحن ننتقل في عالم البرمجة من فلسفة أفلاطون التي كنا نتّبعها في أدوات بناء تطبيقاتنا من لغات برمجة وما تحويه من متغيرات وتوابع وعبارات شرطية وحلقات وسواها، إلى فلسفة أرسطو حيث نبحث في كيفية عمل أدمغتنا ونحاول محاكاتها في بنيتها وطريقة عملها، وهكذا تماما ولد مجال الشبكات العصبية ضمن علوم الذكاء الصنعي. حيث ابتدأت المحاكاة على مستوى الخلية العصبية (العصبون)، فالعصبونات هي خلايا تتألف من جسم مركزي يتضمن نواة الخلية ويمتد منه استطالة وحيدة تكوّن ليف عصبي طويل يقوم مقام السلك الناقل للإشارة الخارجة من الخلية عند نهايته تفرعات كثيرة تنتهي بعقد مشبكية صغيرة، أما في الطرف الآخر من جسم الخلية العصبية فتبرز تفرّعات تخرج في كافة الاتجاهات والتي عن طريقها ترد إلى جسم الخلية البيانات الداخلة، ولابد للإشارات لكي تمر من عصبون إلى آخر أن تجتاز الفجوة الضيقة ما بين عقدة المشبك والجسم أو التفرّع للعصبون التالي. تتلقى الخلية العصبية عدة تنبيهات من الخلايا المجاورة تؤدي إلى شحنها، فإذا وصلت تلك الشحنة إلى عتبة معينة ينبثق كمون كهربائي عند قاعدة المحور وينتشر دفعة واحدة على طوله. لا تستجيب العصبونات لمختلف التنبيهات بشكل متشابه، فلكل منبه درجة أهمية تزيد أو تنقص، كما أن خرج العصبون لا يمتاز بالتدرج، فإما أن تكون هناك نبضة عصبية تنتشر عبر المحور إلى الخلايا المجاورة أو لن يكون هنالك شيء على الإطلاق. طبعا هذا الوصف لبنية العصبون وطريقة عمله فيه تبسيط شديد لحقيقة الأمر، لكن هذا المستوى من الشرح يفي بالغرض. على الرغم من أننا عندما نحاكي عمل العصبون (بفرض أننا نعلم طريقة عمله تماما) لن نحصل على عصبون حقيقي، لكننا سنحصل على معالجة حقيقية للمعلومات كما لو كان العصبون هو من قام بها، وهذا هو بيت القصيد. إن التمثيل الرياضي للعصبون يفترض أن لدينا n إشارة دخل سنرمز إليها بالمقادير X1, X2, …, Xn يرتبط كل منها بوزن أو تثقيل للتعبير عن دور المشابك العصبية كون العصبونات لا تستجيب بشكل متشابه لمختلف التنبيهات كما اتفقنا سابقا. سنرمز إلى تلك الأوزان بالمقادير W1, W2, …, Wn والتي قد تكون قيما موجبة أو حتى سالبة تكبر أو تصغر بحسب طبيعة ودور إشارة الدخل المرتبطة بها سواء كانت محفّزة أم مثبّطة وإلى أي قدر هي كذلك. وهكذا يمكننا التعبير عن مجمل الدخل الآتي إلى العصبون المفرد بالشكل الرياضي التالي: من جهة أخرى، لتمثيل إشارة خرج العصبون نحتاج إلى دالة رياضية تستطيع توصيف عمل قانون الكل أو لا شيء تبعا لعتبة معيّنة، وهناك عدّة خيارات رياضية شائعة قد يتم تفضيل إحداها على الأخرى بحسب طبيعة البيانات التي نتعامل معها نذكر منها على سبيل المثال لا الحصر: Sigmoid (للقيم الثنائية 0/1 أو نعم/لا أو حتى ذكر/أنثى)، TanH (للفئات أو التصنيفات المتقطعة مثل الأعراق: عربي، أوروبي، أفريقي، آسيوي، هندي، الخ.)، وكذلك ReLU (للقيم المتصلة كالعمر مثلا). يوضح الشكل التالي الصيغة الرياضية والتمثيل البياني الذي يظهر العلاقة فيما بين الدخل والخرج لكل منها: بعد أن قمنا بتوصيف العصبون بشكل رياضي مبسّط، علينا الانتقال للحديث عن بنية الشبكات التي تنتظم بها تلك العصبونات وطرق ارتباطها بعضها ببعض، سنتناول بالشرح شكلا واحدا من أشكال بناء الشبكات العصبية، لكن ذلك لا يعني عدم وجود معماريات أخرى لبناء تلك الشبكات. سنفترض أن العصبونات تنتظم في طبقات ولكل طبقة عدد من العصبونات بحيث أن خرج أي عصبون من هذه الطبقة يتم إيصاله إلى كل عصبونات الطبقة التالية. يمكن تمييز الطبقة الأولى على أنـها طبقة الإدخال والتي تتلقى بياناتها من الوسط الخارجي للشبكة العصبية، كذلك نعرّف طبقة الإخراج على أنـها الطبقة الأخيرة والتي ترسل ناتج معالجة البيانات ثانية إلى الوسط الخارجي، في حين يسمّى كل ما عدى ذلك من طبقات بين هاتين الطبقتين بالطبقات الخفية. كما نلاحظ فإن عدد العصبونات في كل من طبقتي الإدخال والإخراج محدد بحسب طبيعة الوظيفة المناطة بالشبكة العصبية (مثلا عدد العنصورات Pixels الإجمالي في الصورة لكل قناة لونية RGB في الدخل، وعدد الفئات المراد تصنيفها في الخرج)، أمّا عدد الطبقات الخفية وعدد العصبونات في كل منها فلا توجد قواعد ضابطة وواضحة لذلك. مكتبة TensorFlow من Google مكتبة TensorFlow هي منصة متكاملة لتدريب وبناء تطبيقات الذكاء الصنعي وتعلم الآلة بالاعتماد على تقنية الشبكات العصبية طورتها شركة Google باستخدام لغة Python ونشرتها تحت ترخيص البرمجيات الحرة والمفتوحة المصدر، وهي تعد في الوقت الراهن واحدة من أكثر المكتبات شهرة واستخداما في هذا المجال (رغم أنها ليست الوحيدة قطعا)، وذلك نظرا لغزارة وتنوع المصادر والأدوات المتوافرة لها والتي تتيح للباحثين القدرة على بناء واستخدام تطبيقات الذكاء الصنعي في أعمالهم. للمزيد حول TensorFlow يمكنكم الإطلاع على الموقع الرسمي لها على الرابط التالي: https://www.tensorflow.org دورة الذكاء الاصطناعي احترف برمجة الذكاء الاصطناعي AI وتحليل البيانات وتعلم كافة المعلومات التي تحتاجها لبناء نماذج ذكاء اصطناعي متخصصة. اشترك الآن مكنز TensorFlow Hub للنماذج إحدى أهم التحديات في عالم الذكاء الصنعي بشكل خاص، وعلوم البيانات بشكل عام، هي القدرة على إعادة استخدام ما سبق وما توصل إليه فريق تطوير آخر سابقًا، لذا قدمت Google هذا المكنز لوضع طريقة معيارية في مشاركة نماذج الشبكات العصبية بحيث تتضمن كافة المعلومات المطلوبة لإعادة استخدامها سواء كانت بنية الشبكة العصبية ذاتها (من حيث عدد الطبقات، ونوعها، وعدد العصبونات في كل منها، ونوع الروابط فيما بينها، الخ.)، إضافة إلى قيم الوسطاء والأوزان المختلفة في تلك الشبكة العصبية بعد إتمام عملية تدريبها. يمكن أخذ هذه النماذج وإعادة استخدامها في مهام مختلفة أو حتى إعادة تدريبها بسهولة مستخدمين تقنية تدعى نقل التعلم والتي سنتحدث عنها لاحقا في هذا الدرس. لمزيد من المعلومات حول هذا المكنز يمكنكم زيارة الموقع الرسمي له على الرابط التالي: https://www.tensorflow.org/hub. نموذج MobileNet V2 للرؤية الحاسوبية تم تصميم هذه العائلة من نماذج الشبكات العصبية المخصصة لمهام الرؤية الحاسوبية عامة الأغراض مثل التصنيف وتحديد الأجزاء والعناصر في الصورة وسواها من الوظائف مع مراعاة المصادر المحدودة التي قد تكون متوافرة على الأجهزة المحمولة. إن القدرة على تشغيل تطبيقات التعلم العميق على أجهزة الجوال الشخصية ستحسن من تجربة المستخدم نظرا لأنها ستكون متاحة في أي زمان ومكان بغض النظر عن الحاجة إلى الاتصال بمصادر خارجية على الإنترنت، وهو ما سيترافق مع فوائد إضافية لجهة الأمان والخصوصية والاقتصاد في استهلاك الطاقة. لمزيد من المعلومات يمكنك الإطلاع على الرابط المدرج ضمن قسم المراجع1. تقنية نقل التعلم Transfer Learning إن النماذج الحديثة للتعرف على الصور تحتوي على الملايين من الوسطاء (من أوزان للروابط ما بين الآلاف من العصبونات المرصوفة في العشرات من الطبقات الخفية) والتي يتطلب تدريبها من الصفر كما كبيرا من بيانات التدريب من جهة، والكثير من الطاقة الحاسوبية من جهة أخرى (تقدّر بالمئات من ساعات الحساب على وحدات المعالجة الرسومية GPU أو حتى أكثر بكثير). إن تقنية نقل التعلم تعتمد على حيلة ذكية لاختصار كم المصادر الكبير الذي نحتاجه لتطوير نموذج رؤية حاسوبية جديد تخصص مهاراته في التعرف على نمط مختلف من الصور (مثلا صور الأشعة السينية لتشخيص وجود أورام سرطانية محتملة عوض التعرف على الأنواع المختلفة من الأزهار البرية). تقوم الفكرة على استبدال الطبقة الأخيرة فقط من شبكة عصبية سبق وأن تم تدريبها بشكل جيد على تصنيف الصور ولو لغايات مختلفة، مستفيدين بذلك من كم المهارات التي اكتسبتها بنية الطبقات الخفية في ذلك النموذج، ابتداء من التعرف على أنماط النسج والأشكال وترابط الأجزاء وعلاقات الألوان وغيرها مما هو مشترك بالعموم بين كافة نظم الرؤية الحاسوبية، والتي يمكن إعادة استخدامها ومشاركتها بين النماذج المختلفة. وحدها الطبقة الأخيرة فقط الخاصة بالأصناف تتغير بتغير الغاية والهدف من النموذج الذي يجري تطويره وتخصيصه، لذا هي وحدها التي سيتم تدريبها فعليا عند استخدام تقنية نقل التعلم هذه. لمزيد من المعلومات حول هذه التقنية في التعليم يمكنكم الإطلاع على رابط ورقة البحث العلمي المدرجة ضمن قسم المراجع أدناه2. تجهيز بيئة العمل سنستخدم منصة Docker المخصصة لتطوير ونشر وإدارة التطبيقات باستخدام فكرة الحاويات وذلك لتسهيل بناء بيئة العمل لدينا من أجل تنفيذ التطبيق العملي في هذه الجلسة، حيث أن الحاويات هي عبارة عن حزم تنفيذية خفيفة وقائمة بذاتها لتطبيق ما، تحوي كل المكتبات وملفات الإمداد والاعتماديات والأجزاء الأخرى الضرورية ليعمل التطبيق ضمن بيئة معزولة، هذا عدى عن أنها خفيفة لأنها لا تتطلب حملا إضافيا كالأجهزة الافتراضية كونها تعمل ضمن نواة النظام المضيف مباشرة دون الحاجة إلى نظام ضيف، وبذلك نزيل عن كاهلنا في هذه المرحلة أي تعقيدات تختص بالتنصيب والربط والإعداد لمختلف مكونات بيئة التطوير الخاصة بمكتبة TensorFlow وهي مهمة ليست باليسيرة على المبتدئ، لذا عليك القيام بتثبيت Docker على حاسوبك الشخصي من الموقع الرسمي https://www.docker.com/ قبل الانتقال إلى الخطوة التالية. اطلع على مقال «التعامل مع حاويات Docker» في قسم دوكر في أكاديمية حسوب. تطبيق عملي يقوم بتحديد جنس الشخص من صورة وجهه بداية نقوم بتنصيب TensorFlow على Docker ضمن حاوية تحت تسمية hsoub-ft، قد تتطلب هذه الخطوة بعض الوقت نظرا لكون حجم صورة الحاوية التي سيتم سحبها وتنزيلها عبر الإنترنت يتجاوز 1GB: docker pull tensorflow/tensorflow docker run --name hsoub-tf -it -d tensorflow/tensorflow:latest بعد ذلك نقوم بالدخول إلى سطر الأوامر ضمن الحاوية ونقوم بتنصيب الإصدار 2.0 على الأقل من مكتبة TensorFlow وكذلك الإصدار 0.6 على الأقل من نموذج تصنيف الصور3 الذي سنستخدمه والمستضاف في مكنز TensorFlow Hub، و بعد إتمام هذه الخطوات نخرج باستخدام الأمر exit في سطر الأوامر للعودة إلى الجهاز المضيف: docker exec -it hsoub-tf bash pip install "tensorflow~=2.0" pip install "tensorflow-hub[make_image_classifier]~=0.6" exit الخطوة التالية هي تحضير بيانات التدريب وذلك من خلال الحصول على الصور التي سيتم تدريب الشبكة عليها، في مثالنا هذا استخدمنا مجموعة جزئية تتكون من حوالي 2000 صورة مقسمة إلى فئتين ذكور وإناث وهي مقتطعة من مجموعة بيانات أكبر تدعى UTKFace4 المتاحة للاستخدامات غير التجارية والتي تتضمن بالأساس ما يزيد عن 20 ألف صورة وجه. تم اختيار الصور التي سوف نستخدمها في عملية التدريب بحيث تكون متوازنة من حيث الجنس (أي أن عدد الصور الخاصة بالذكور يساوي تقريبا عددها للإناث) والعرقيات (أي تقارب عدد الأشخاص من ذوي الأصول الأوروبية والأفريقية والهندية الخ.) وذلك لضمان عدم التحيز، إضافة إلى أن الصور تخص أشخاصا تتراوح أعمارهم ما بين 20 إلى 40 سنة. للمتابعة عليك تحميل الملف المضغوط المرفق مع هذا المحتوى، ثم قم بفك ضغطه على حاسوبك وستحصل على مجلد باسم training داخله ثلاث مجلدات هي images و output وكذلك test. ستلاحظ ضمن مجلد images أن هنالك مجلد فرعي لك تصنيف تريد من شبكتك العصبية أن تتعرف عليه (في حالتنا هذه هناك مجلدان فقط بتسمية Male و Female) داخل كل منهما مجموعة الصور التي تنتمي إلى ذلك التصنيف. من جهة أخرى فإن مجلد output هو فارغ حاليا لكنه المكان الذي سيتم فيه حفظ الشبكة العصبية بعد إتمام عملية تدريبها (أي حيث سنخزن النموذج الناتج)، أخيرا ستجد في المجلد الثالث test شيفرة برمجية بسيطة لاختبار النموذج الناتج وبعض الصور التي لم يسبق له أن رآها من قبل (أي أنها لم تكن موجودة أصلا ضمن صور وبيانات التدريب). نحن بحاجة إلى نقل كل هذه المجلدات وما فيها من ملفات إلى داخل الحاوية hsoub-tf وذلك باستخدام الأمر التالي على الجهاز المضيف: docker cp .\training hsoub-tf:/training الآن نستطيع الانتقال مجددا إلى سطر الأوامر ضمن الحاوية باستخدام الأمر التالي: docker exec -it hsoub-tf bash وبعد ذلك يمكننا بدء عملية التدريب باستخدام الأمر التالي: make_image_classifier \ --image_dir training/images dir \ --tfhub_module https://tfhub.dev/google/tf2-preview/mobilenet_v2/feature_vector/4 \ --image_size 224 \ --saved_model_dir training/output/model \ --labels_output_file training/output/class_labels.txt \ --tflite_output_file training/output/mobile_model.tflite إن وسطاء الأمر التنفيذي السابق تحدد المسار الذي يحتوي على مجلدات الصور التي سيتم استخدامها في عملية التدريب (أي مسار المجلد ضمن الحاوية وليس على الجهاز المضيف)، وكذلك مصدر النموذج الأصلي الذي ستطبق عليه تقنية نقل التعلم باستبدال طبقته الأخيرة، بعد ذلك نحدد الأبعاد المطلوبة للصور ليتم تحجيمها تلقائيا لتلائم هذه الأبعاد (فهذا محدد ومرتبط بطبقة الإدخال في نموذج الشبكة العصبية المستخدمة)، في حالتنا نحن نستخدم نموذج MobileNet V2 والذي يفترض أبعاد الصورة هي 224 عنصورة/بيكسل للطول والعرض، بعد ذلك نحدد المكان الذي سيتم فيه حفظ النموذج المدرّب الناتج، وكذلك أين سيتم حفظ التسميات المرافقة لعصبونات الخرج من شبكتنا العصبية بالترتيب، وأخيرا أين سيتم تصدير هذا النموذج بصيغة tflite المحزومة والموضبة لتطبيقات الجوال. في نهاية عملية التدريب (والتي قد تطول تبعا لعدد الصور من جهة، ولسرعة الحاسوب الذي تتم عليه عملية التدريب من جهة أخرى)، سنجد أننا حصلنا على نموذج شبكة عصبية يستطيع تمييز جنس الشخص من صورته بدقة تتعدى 80% وذلك بمجهود بسيط جدا دون الحاجة إلى عمليات ضبط ومعايرة فائقة التخصص لوسطاء بناء وتدريب الشبكة العصبية، ودون الحاجة كذلك إلى ساعات وساعات من التدريب ولا إلى آلاف وآلاف من الصورة للتدرب عليها! إنها بحق نتيجة مرضية لأوائل مغامراتك مع الشبكات العصبية، لكنها مجرد البداية. ها قد حان الوقت لتجربة النموذج الذي قمنا بتدريبه على صور لم يسبق له أن رآها من قبل، للقيام بذلك سوف نستخدم برنامج معد مسبقا لهذه الغاية5 وهو مكتوب بلغة Python وموجود داخل المجلد training/test صحبة بضعة صور كأمثلة للتجريب (ويمكن أن تستخدم صورك الخاصة في هذه المرحلة)، حيث ستتم عملية الاختبار لكل صورة من خلال الأمر التالي (وفيه نشير إلى مسار الشبكة العصبية التي سيتم تحميلها واستخدامها، والملف النصي الذي يتضمن اسم التصنيف الخاص بكل عصبون خرج ضمن هذه الشبكة بالترتيب، وأخيرا مسار الصورة المراد تصنيفها): python training/test/label_image.py \ --input_mean 0 --input_std 255 \ --model_file training/output/mobile_model.tflite \ --label_file training/output/class_labels.txt \ --image training/test/Ahmed_Zewail.jpg بعد إتمام تدريبنا واختبارنا للشبكة العصبية حان الوقت للخروج من بيئة التدريب هذه باستخدام الأمر exit للعودة إلى سطر الأوامر على الجهاز المضيف، ومن ثم سنرغب طبعا باستخراج النموذج الذي قمنا بتعليمه خلال هذه الجلسة من داخل حاوية Docker وهو ما نستطيع القيام به باستخدام الأمر التالي: docker cp hsoub-tf:/training/output .\training نقاط تستحق التأمل قد يرى البعض في تقنيات الذكاء الصنعي حلا لجميع المشكلات، لكنها في حقيقة الأمر لا تأتي خالية من المخاطر التي قد ترقى إلى حد اعتبارها نقاط ضعف أو عيوب يجب أن تؤخذ بعين الاعتبار، نذكر منها: باعتبار أن النماذج في الشبكات العصبية تبنى انطلاقا من بيانات التدريب، لذا فإنها غير قادرة على حل أي مشاكل كانت موجودة أصلا في تلك البيانات كالأخطاء أو الانحياز أو عدم التكامل والشمول لمختلف الحالات المراد التعامل معها. يصعب في الشبكات العصبية تفسير المنطق الذي استخدمه النموذج لإعطاء إجابته، فالتعامل معه أقرب ما يكون للصندوق الأسود الذي لا نعلم كمستخدمين آلية عمله الدقيقة في الداخل، بل نؤمن بأن ما نحصل عليه من إجابات هو أفضل المتاح، ولهذه الفكرة تداعياتها الفلسفية والاجتماعية التي تصعّب من استخدام هكذا أدوات في الحالات التي تتطلب تقديم تبرير (مثلا عند تطبيق عقوبة أو حرمان من مكافأة). تطوير نماذج الشبكات العصبية يتطلب قدرا كبيرا من بيانات التدريب المشروحة والمجهزة بشكل جيد وملائم، وهو ما قد يعني الكثير من الجهد لتوفير مثل هكذا مصادر للتدريب. عملية تدريب الشبكات العصبية هي عملية متطلّبة من ناحية قدرات المعالجة الحسابية المتوفّرة للعتاد المستخدم، وذلك على عكس عملية استخدامها في التطبيقات عقب إتمام التدريب، لذا قد يجد المطور في الحوسبة السحابية فرصا متاحة بميزانيات في المتناول. إن بناء النماذج باستخدام خوارزميات تعلم الآلة يتطلب مطورين أذكياء وموهوبين، فعلى الرغم من أن تطبيق المثال الذي قمنا بعرضه يبدو سهلا ويسيرا، إلا أن نظرة أكثر تعمقا ستكشف لك الكثير من التفاصيل التي بحاجة إلى معايرة وضبط، منها على سبيل المثال لا الحصر: معمارية الشبكة، وطريقة توصيف تابع تفعيل العصبونات فيها، وعدد طبقاتها الخفية، وعدد العصبونات في كل منها، وطريقة ربطها بعضها ببعض، وكيفية حساب الخطأ ما بين النتيجة المحسوبة والمطلوبة، ومعدل سرعة التعلم، وعدد مرات تكرار عرض الأمثلة على الشبكة العصبية أثناء التدريب، وغيرها الكثير. إن انتقاء التوليفة الأكثر ملائمة لجملة معايير الضبط هذه يؤثر بشكل حاسم على جودة ودقة النموذج الناتج. مراجع أجنبية للاستزادة MobileNetV2: The Next Generation of On-Device Computer Vision Networks DeCAF: A Deep Convolutional Activation Feature for Generic Visual Recognition Making your own TensorFlow model for image classification UTKFace: Large Scale Face Dataset TensorFlow Lite Python image classification demo اقرأ أيضًا تعلم الذكاء الاصطناعي الذكاء الاصطناعي: دليلك الشامل المقال التالي: إعداد شبكة عصبية صنعية وتدريبها للتعرف على الوجوه الذكاء الاصطناعي: مراحل البدء والتطور والأسس التي نشأ عليها

مقدّمةيكتسي التّواصل 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 المبنيّة على هذا الأساس بهدف إدارة عنقود حاويّات.

قليلة هي تلك المشاريع والابتكارات التي تُحدِث نقلة نوعية في عالم البرمجيات والتقنية بشكل عام، وإن كنا سنشهد في هذه العشرية إحدى هذه المشاريع، فهو Docker بامتياز. فما هو Docker هذا؟ هذا المقال يهدف بشكل خاص إلى التعريف بمشروع Docker والفكرة التي جاء بها، وليس لكيفية البدء به (والتي ستكون في مقال منفصل إن شاء الله)، حيث لا يمكن البدء به إذا لم نفهم فكرته وأهميته في عالم البرمجيات. لمن هذا المقال؟لمدراء الخواديم (SysAdmins) بالدرجة الأولىللمبرمجين ومطوري الويب بالدرجة الثانية قبل أن نتحدث عن ماهية Docker أحب أولا ذكر أهم 03 مشاكل نواجهها حاليا كمطورين ومدراء خواديم والتي يحاول Docker معالجتها... 1. جحيم الاعتماديات (the dependecy hell)الأغلبية الساحقة من مشاريع الويب "الجدية" والكبيرة لا تكون قائمة بذاتها، بل هي عبارة عن مكتبات تتواصل فيما بينها أو تعتمد على مكتبات أخرى من أجل أن تعمل، مطوروا Ruby، Python وحتى node.js و php يفهمون ذلك جيدا، وكل من هذه اللغات حاول حل المشكلة على نطاقه الخاص عبر إنشاء أدوات مساعدة تعرف بـ"مدراء الاعتماديات" أو "مدراء حزم" (dependency/package managers) أمثلة ذلك: pip بالنسبة لبايثونgem بالنسبة لروبيnpm بالنسبة لـ node.jsوأخيرا محاولة متواضعة من php عبر composer..وقد تذهب اللغة إلى أبعد من ذلك مثل ما فعلت بايثون بإنشاء بيئات وهمية تعزل فيها المكتبات والاعتماديات مثل مشروع virtualenv. كل من هذه اللغات تستعمل مدراء الاعتماديات/الحزم لجلب وإدارة المكتبات الخارجية التي يعتمد عليها المشروع (third party librairies)، لكن السؤال هنا، إذا كانت هذه اللغات وفرت هذه الأدوات، فأين المشكل؟ في الحيقيقة بالرغم من توفر هذه الأدوات، تبقى هناك مشاكل عالقة دائما خاصة على مستوى تنصيب المشروع على الخواديم (deployment) من ذلك: كثرة الاعتماديات، مما يأخذ وقتا في التنزيل، وأحيانا لا توجد تلك الاعتمادية على منصة الخادوم البعيد وقد تحتاج إلى عمل تجميع يدوي لها، وهذا يجعل الأمر مُتعبا.اعتمادية تعتمد في حد ذاتها على اعتمادية أخرى، قد تكون مثلا تشترط منصة Java بأكملها، وقد تكون أيضا هذه الأخيرة تعتمد على اعتماديات أخرى وهكذا...تعارض الاعتماديات، وجود إحداها يتطلب غياب الأخرى واستحالة عملهما معا في نفس الوقتنسخة الاعتمادية التي تم تنزيلها مغايرة للتي تم تطوير المشروع بها. والنسخة الجديدة تأتي بتغيرات غير متوافقة رجعيا (API backward compatibility)كل هذه المشاكل وغيرها، تجعل من ناقلية المشروع من مكان إلى آخر أو من خادوم إلى آخر، عملية شاقّة. 2. صعوبة نشر، تنصيب، نقل مشاريع الويبمشاريع الويب الكبيرة تحتاج إلى عدد من الاحتياطات: متغيرات بيئة (environment variables) يجب تعيينها مسبقاإعداد لنظام الـ cacheإعداد للخادوم nginx أو غيرهإعدادات أمنيةتحديث النظام وبرمجياته قد يسبب عطلا ما للمشروع،...ماذا عن نقل المشروع من خادوم إلى آخر؟ أو في حالة وجود أكثر من خادوم... وكل منه له نظامه الخاص (من CentOs إلى Ubuntu مثلا أو حتى BSD).... 3. التطوير، التسليم والزرع المتواصل للمشاريع ( continuous delivery/integration)مشاريع الويب الجدية تتبع دورة تطوير معينة، تحسين دائم، إدخال لميزات جديدة بشكل دوري، قفل للثغرات ... إلخ، بعد هذا يجب إجراء سلسلة من الفحوصات (unit tests مثلا) للتأكد من سلامة المشروع وأنه أهل للمرحلة الإنتاجية منه (production ready)، كل هذا سهل محليا،... لكن عملية إبقاء جميع الخواديم مسايرة لوتيرة التطوير هذه أمر شاق ومتعب، خاصة حينما نحتاج إلى تحديث الاعتماديات أو وجود إعتماديات جديدة وبالتالي احتياطات جديدة... هذه المشاكل ليس حصرا، فهناك غيرها من المشاكلة الأمنية (مثال ثغرة في مشروع الويب تمكن المخترق من الوصول إلى النظام)، مشاكل عزل (قاعدة البيانات في نفس بيئة التطبيق نفسه مما قد يسمح للوصول السهل لها من قبل المخترق)، مشاكل نسخ اختياطي (backups)،.. الخ إذا ما هو Docker؟Docker عبارة عن أداة جديدة تستغل ميزات الإصدارات الأخيرة من نواة Linux الخاصة بعزل المهام والعمليات (processes)، عمليات الإدخال والإخراج (i/o)، حجز الذاكرة وتحديدها، صلاحيات القراءة والكتابة للقرص الصلب... وغير ذلك، في إنشاء حاويات (containers) ركز على هذه الكلمة جيدا، حيث أن هذه الحاويات تلعب دور غلاف حاوي لتطبيق ما (مشروع ويب مثلا)، بحيث يصبح قائما بذاته، مكتفٍ ذاتيا. أي أن مشروع الويب وكامل الاعتماديات التي يحتاجها ليعمل + التوزيعة المناسبة له (Fedora, Ubuntu.. الخ) بجميع التهيئات ومتغيرات البيئة التي يحتاجها، كل هذا في حاوية (قد تكون حاوية واحدة أو عدة حاويات تتخاطب في ما بينها عملا بمبدأ "عزل الاهتمامات" SoC). لتقريب الصورة، تخيل أنه باستعمال Docker يمكنك عمل التالي: طورت تطبيقك على Ubuntu أو تعلم أنه يعمل بشكل جيد على توزيعة Ubuntu وبالتحديد الإصدارة 14.04 منها، وبالتالي تقول لـ Docker استعمل نسخة Ubuntu 14.04 (يتكفل هو بتزيل الصورة الخام من Ubuntu 14.04 - حوالي 60 إلى 300 Mb تقريبا- واستعمالها كتوزيعة للحاوية)مشروع الويب خاصتي يستعمل Python وبالتحديد النسخة 2.7 منها، ويعمل بشكل جيد على هذه النسخة، لم أجرب على Python 3، تقول لـ Docker نصب Python2.7 في الحاوية التي بها نظام Ubuntu 14.04 الذي سبق تنزيل صورته الخاممشروع الويب خاصتي يستعمل مكتبة Flask أو Django و مكتبة Numpy الخاصة ببايثون، يتم تثبيتهم عبر pip وبالتالي تقول لـ Docker نصب لي على الحاوية التي بها Ubuntu 14.04 و Python 2.7 السابقة تطبيق Pip عبر مدير حزم Ubuntu (أي apt-get install python-pip) ثم باستعمال pip نصب لي مكتاب بايثون السابق ذكرهامشروع الويب الخاص بي يحتاج قاعدة بيانات MySQL، نصبها يا Docker عبر مدير حزم Ubuntuأيضا نحتاج nginx أو apache، كذلك تطلب من Docker أن ينصبه عبر مدير حزم Ubuntuاجمع لي كل هذا في صورة واحدة (image) يمكن تشغيلها على أي خادوم أو حاسوب به Docker عبر الأمر: docker run my_imageجميع هذه الخطوات يمكن أتمتتها وسردها في ملف واحد اسمه DockerFile، كل سطر من هذا الملف عبارة عن أمر لـ Docker يقوم به (تماما كما قمنا به أعلاه)، مجموع الأوامر يكون الخطوات التي يمر بها Docker لبناء الحاوية التي نريدها، في ما يلي مثال عن ملف DockerFile: FROM ubuntu 14.04 # Install Python RUN apt-get install -y python-dev # Install pip RUN apt-get install -y python-pip # Install requirements.txt ADD requirements.txt /src/requirements.txt RUN cd /src; pip install -r requirements.txt # Add the Flask App ADD . /src # EXPOSE PORT EXPOSE 80 # Run the Flask APP CMD python src/app.pyيمكن حفظ هذه الأوامر في ملف باسم Dockerfile، يمكنك أيضا تشغيل هذا الملف لبناء صورة (image) لحاوية container من خلال Docker عبر الأمر التالي: docker build -t <your username>/my-flask-app .لاحظ النقطة في آخر الأمر، والتي تعني "استعمل ملف DockerFile الموجود في المجلد الحالي"، أما تعليمة t- بعد أمر build هي لاعطاء وسم (tag) للحاوية التي نريد بناءها. عادة من المتعارف عليه هو اعطاء اسم مستخدمك يليه "/" يليه اسم تطبيقك. مفهوم الحاويات (Containers)الحاوية في Linux عبارة عن غلاف يطبّق مجموعات من القيود لعزل عملية أو مجموعة عمليات (processes) عن باقي مهام وعمليات النظام من ناحية السياق (context)، الذاكرة RAM، القراءة والكتابة، الشابكة (Network)... الخ، بحيث تكون في معزل تام عن باقي الـ processes في النظام. أي نفس فكرة الـ sandboxing. مفهوم الحاويات ليس جديدا، فقد بدأ بالظهور منذ أواخر عام 2007، حين عرض مهندسون لدى Google مشروع cgroups (اختصارا لـ Control Groups) ليتم دمجه في نواة Linux، منذ ذلك الوقت cgroups كان اللبنة الأساسية لعزل الموارد وكبحها في نظام Linux على مستوى النواة. بعدها جاء مشروع LXC (اختصارا لـ LinuX Containers) والذي جمع بين cgroups وميزة عزل نطاقات الأسماء (namespace isolation) في نواة Linux، لتوفير إمكانية إنشاء مجموعات منفصلة عن بعضها من العمليات (process groups)، كل مجموعة مكتفية ذاتيا و/أو محدودة المواد، بحيث لا تدري كل مجموعة عن الأخرى بالرغم من أنهم يشاركون نفس النواة (نواة Linux). هذه المجموعات عُرفت باسم الحاويات Containers. على الرغم من أن LXC الأقرب لفكرة Docker، إلا أنه بقي على مستوى منخفض ولم يوفر واجهة برمجية سهلة للمطورين مثل ما قدمه Docker. إضافات Dockerفي أيامه الأولى، اعتمد مشروع Docker على LXC وبنى عليه، أي استعمله كـ backend أو driver، (لكن الآن يمكن استعمال بدائل لـ LXC) لكنه أضاف عدة أمور عصرية، بعضها مستوحى من أنظمة إدارة النسخ (Version Control Systems) من ذلك: مفهوم Docker image لبناء لقطات من الحاويات (نفس فكرة ملفات .iso) يمكن تصديرها واسترادها، وبالتالي يمكن بناء صورة للمشروع بأكمله ثم يكفي استراد تلك الصورة على الخاودم، يتوجب فقط أن يكون Docker مُنصّبا.إمكانية عمل "إيداع" (Commit) للتغيرات التي قمت بها على صورة المشروع الخاص بك، وبالتالي إمكانية الرجوع للوراء في حال الخطأ، هذه الميزة تسمح أيضا لـ Docker أن يكون وسيلة حفظ احتياطي "backup".كل صورة بنيتها يمكنك مشاركتها مع المجتمع في فهرس docker، والذي كان اسمه Docker index ثم تحول مؤخرا إلى docker hub. ستجد فيه مثلا صور لـتطبيق WordPress منصبة على Ubuntu جاهزة للاستهلاك المباشر، أليس هذا رائعا؟مفهوم الـ Dockerfile الذي سبق عرض ماهيته، وهو وسيلة لأتمتة وسرد خطوات بناء مشروعك أو حاويتك. الأتمتة التي تتيحها ملفات Dockerfiles تسمح بانتهاج نسق Continuous integration الذي تكلمنا عنه، تخيل أنك تريد تجربة مشروعك على Python 3 مثلا، كل ما عليك هو تغيير نسخة Python في ملف Dockerfile وبناء حاوية جديدة لتجرب عليها الناتج، فإن كان جيدا تدفعه للخادوم، وإن لم يكن كذلك تحذفه. نفس الشيء مع إصدارات المكتبات التي يعتمد عليها مشروعك.هذه بعض مما أضافه Docker لما هو موجود، وهي وحدها كفيلة بإحداث قفزة وتحول نوعي في طريقتنا لبناء ونشر البرامج. لكن السؤال الذي قد يطرحه البعض: أليس ما يعمله Docker هو نفسه ما تعمله الآلات الافتراضية Virtual Machines ومحاكاة الأنظمة؟ باختصار، نعم ولا وسنلخص الأمر في النقاط التالية: Docker أخف بكثير من الآلات الافتراضية، يمكنك تشغيل العشرات من الحاويات في حاسوب عادي واحد، في حين لا يمكنك تشغيل 3-4 آلات افتراضية في حاسوب عادي واحد ولو كان قويا نسبيا (يثقل النظام). أي أن Docker يستهلك موارد أقل بكثير.الآلات الافتراضية تقوم بمحاكاة كـــامــل النظام وكل ما فيه ووضعه فوق النظام المضيف، في حين Docker يتشارك النواة (Linux kernel) مع النظام المضيف.ما يقوم به Docker هو تنزيل التوزيعات فقط، أي الـ bins/libs لكل توزيعة وفقط، في حين يتشارك النواة مع النظام المضيف ولا يُنزّل نواة جديدة مع تلك التوزيعة. تلك الـ bins/libs كفيلة لمحاكاة بيئة التوزيعة المرجوة، أما النواة فهي متشابهة بين جميع التوزيعات وبالتالي يتقاسمها مع النظام المضيف (لهذا Docker لا يعمل إلا على Linux).Docker يعزل التطبيق واعتمادياته فقط، في حين الآلات الافتراضية تعزل كامل النظام وما فيه من تطبيقات.الصورتان التاليتان توضحان الفرق بين Docker والآلات الافتراضية: من خلال الصورتين يمكن ملاحظة أن وزن Docker على الخادوم بشكل عام أخف بكثير من الثقل الذي تحدثه الآلات الافتراضية. الجدير بالذكر أيضا أن القائمين على مشروع Docker قاموا بتوفير ما يسمى بـ Docker Hub، يمكن فيه مشاركة صور (images) لمشروعك (إن كان مفتوح المصدر)، تجد فيه صورا للحلول مفتوحة المصدر المعروفة، كصور Wordpress, joomla, mysql, nginx .. الخ، بحيث يمكنك استهلاكها مباشرة أو استيرادها والبناء عليها أدعوك ﻷن تلقي عليه نظرة. يمكن أيضا أن تكون مستودعا خاصا لك، لمشاريعك التجارية غير مفتوحة المصدر / مجانية، تجلب منه وتسترد صورك الخاصة التي قمت ببنائها. إلى هنا نصل إلى خاتمة هذه المقدمة التعريفية. سنقوم في مقال لاحق إن شاء الله بشرح أساسيات Docker بشكل عملي. إذا كانت لغتك الانجليزية جيدة، فأنصحك بمشاهدة الفيديو التالية لفهم أعمق للمقال:

مع انتقال أدوات المطورين إلى السحاب (cloud)، يزداد عدد المتبنين لمنصات بيئة تطوير متكاملة IDE ‏(Integrated Development Environment بيئة التطوير المتكاملة) السحابيّة، فهذه المنصات يمكن الوصول إليها من أي نوع من الأجهزة الحديثة عن طريق المتصفحات، وهي توفّر مميزات مهمة عند التعاون في الوقت الحقيقي، فيوفر العمل في منصة IDE سحابيّة بيئة موحدّة للتطوير والتجربة لك ولفريقك مع تقليل مشاكل عدم توافق المنصات، فيمكنك الوصول إليها من أي نوع من الأجهزة الحديثة عن طريق المتصفحات. فـ Eclipse Theia هي منصة IDE سحابيّة قابلة للتوسع تعمل على خادم عن بعد ويمكن الوصول إليها من متصفح الويب، وشكلها يشبه Microsoft Visual Studio Code وتدعم العديد من لغات البرمجة ولديها تصميم مرن وطرفيّة (Terminal)، وما يفرّق بين Eclipse Theia من بقيّة برامج IDE السحابيّة هي قابليّة تخصيصها وزيادة مميزاتها باستخدام الملحقات المخصّصة، والتي تسمح لك بتعديل IDE السحابي حسب رغباتك. سننشر في هذا الدرس Eclipse Theia إلى خادم أوبنتو 18.04 باستخدام Docker Compose والتي هي أداة لمزامنة الحاوية، والتي ستكشفها في اسم النطاق الخاص بك باستخدام nginx-proxy والذي هو نظام تلقائي لـ Docker يبسط عملية إعداد Nginx ليعمل كوكيل عكسي (reverse proxy) للحاوية، وستأمنها باستخدام شهادة Let’s Encrypt TLS عن طريق الملحق المخصص لها. وفي النهاية ستحصل على Eclipse Theia يعمل على خادم أوبنتو 18.04 متوفّر عن طريق HTTPS يمكن للمستخدم تسجيل دخوله ليبدأ العمل عليه. المتطلبات الأساسية خادم أوبنتو 18.04 مع صلاحيات الجذر بالإضافة إلى حساب آخر عادي ليس جذر، يمكنك اعداد ذلك عن طريق اتباع هذا الدرس بالنسبة لهذا المقال، المستخدم العادي (ليس جذر) هو sammy. تثبيت Docker على خادمك، يمكنك اتباع الخطوة الأولى والثانية من هذا الدرس وللتعرّف على Docker، يمكنك الإطلاع على هذا الدرس. تثبيت Docker Compose على خادمك، يمكنك اتباع الخطوة الأول من درس تثبيت Docker Compose. اسم نطاق مسجّل بالكامل، سنستخدم في هذا درس theia.your_domain والذي يمكنك استبداله بأي اسم ستشتريه من أي موقع يوفر هذه الخدمة. سِجل DNS مع إشارة theia.your_domain إلى عنوان IP الخادم العام، يمكنك الإطلاع على المقدمة إلى DNS الخاص بـ DigitalOcean للمزيد من التفاصيل. الخطوة الأولى - نشر nginx-proxy مع Let’s Encrypt في هذا القسم، ستنشر nginx-proxy مع إضافة Let's Encrypt باستخدام Docker Compose، وسيفعّل هذا عمليّة تفعيل وتجديد شهادة TLS بشكل تلقائي، لذلك عندما تنشر Eclipse Theia، ستتمكن من الوصول إلى نطاقك عن طريق HTTPS. في هذا الدرس، سنسجل جميع الملفات في ‎~/‎eclipse-theia، أنشئ هذا المجلّد عن طريق تشغيل هذا الأمر: mkdir ~/eclipse-theia انتقل إلى هذا المجلّد عن طريق: cd ~/eclipse-theia يجب عليك حفظ إعدادات Docker Compose لـ nginx-proxy في ملف يسمى nginx-proxy-compose.yaml، أنشئه باستخدام محرّر النصوص الخاص بك: nano nginx-proxy-compose.yaml وأضف الأسطر التاليّة إليه (ملف nginx-proxy-compose.yaml): version: '2' services: nginx-proxy: restart: always image: jwilder/nginx-proxy ports: - "80:80" - "443:443" volumes: - "/etc/nginx/htpasswd:/etc/nginx/htpasswd" - "/etc/nginx/vhost.d" - "/usr/share/nginx/html" - "/var/run/docker.sock:/tmp/docker.sock:ro" - "/etc/nginx/certs" letsencrypt-nginx-proxy-companion: restart: always image: jrcs/letsencrypt-nginx-proxy-companion volumes: - "/var/run/docker.sock:/var/run/docker.sock:ro" volumes_from: - "nginx-proxy" ستعرّف هنا خدمتين سيشغلها Docker Compose وهما nginx-proxy و Let’s Encrypt، بالنسبة إلى الوكيل (proxy)، ستحدّد jwilder/nginx-proxy كصورة وستعرّف منافذ HTTP وHTTPS بالإضافة إلى الأماكن (volumes) التي يمكن الوصول إليها وقت التشغيل. الأماكن (Volumes) هي مجلدات في خادمك التي يمكن للخدمات المعرّفة الوصول إليها، والتي ستستخدمها لاحقًا في إعداد مصادقة المستخدم (user authentication)، ولفعل ذلك، ستستخدم المكان الأول من القائمة والذي سيصل مجلد ‎/etc/nginx/htpasswd المحلي إلى نفس المكان في الحاوية، وفي هذا المجلد، سيتوقع nginx-proxy إيجاد نفس الملف مسمى بنفس النطاق المستهدف، ويحتوي على بيانات تسجيل الدخول لمصادقة المستخدم في شكل htpasswd (username:hashed_password). بالنسبة للإضافة، ستضع اسم الصورة وستسمح بالوصول إلى المقبس socket الخاصة بالـ Docker عن طريق تعريف مكان (Volume)، ومن ثم ستحدد أن هذه الإضافة يجب عليها وراثة الوصول إلى الأماكن المعرّفة لـ nginx-proxy، كلا الخدمتين تملكان خيار restart يحتوي على قيمة always، والتي تأمر Docker بإعادة تشغيل الحاويات في حالة التعطل أو إعادة تشغيل النظام. أغلق الملف بعد حفظه وانشر الإعدادات عن طريق تشغيل الأمر التالي: docker-compose -f nginx-proxy-compose.yaml up -d ستمرر في الأمر السابق، اسم ملف nginx-proxy-compose.yaml إلى المعامل ‎-f لأمر docker-compose والذي يحدد الملف الذي سيعمل، وبعد ذلك، ستمرّر فعل up الذي سيشغّل الحاوية. بالنسبة إلى الراية ‎-d فهي تفعّل الوضع المنفصل (detached mode)، والذي يعني أن Docker Compose سيشغّل الحاويات في الخلفية. المخرجات النهائيّة ستشبه لهذه: Creating network "eclipse-theia_default" with the default driver Pulling nginx-proxy (jwilder/nginx-proxy:)... latest: Pulling from jwilder/nginx-proxy 8d691f585fa8: Pull complete 5b07f4e08ad0: Pull complete ... Digest: sha256:dfc0666b9747a6fc851f5fb9b03e65e957b34c95d9635b4b5d1d6b01104bde28 Status: Downloaded newer image for jwilder/nginx-proxy:latest Pulling letsencrypt-nginx-proxy-companion (jrcs/letsencrypt-nginx-proxy-companion:)... latest: Pulling from jrcs/letsencrypt-nginx-proxy-companion 89d9c30c1d48: Pull complete 668840c175f8: Pull complete ... Digest: sha256:a8d369d84079a923fdec8ce2f85827917a15022b0dae9be73e6a0db03be95b5a Status: Downloaded newer image for jrcs/letsencrypt-nginx-proxy-companion:latest Creating eclipse-theia_nginx-proxy_1 ... done Creating eclipse-theia_letsencrypt-nginx-proxy-companion_1 ... done والآن بعد أن نشرنا nginx-proxy ومرافقه Let's Encrypt باستخدام Docker Compose، سننتقل إلى إعداد Eclipse Theia على نطاقك وتأمينه. الخطوة الثانية - نشر Eclipse Thia في Docker سننشئ في هذا القسم ملف يحتوي على بيانات تسجيل الدخول التي سيستخدمها المستخدم، ومن ثم سننشر Eclipse Theia إلى خادمك باستخدام Docker Compose وسنعرضه على نطاقك الآمن باستخدام nginx-proxy. كما شرحنا في الخطوة السابقة، يتوقع nginx-proxy الحصول على بيانات تسجيل الدخول في ملف على النطاق المكشوف على شكل htpasswd ومحفوظة في مجلد ‎/etc/nginx/htpasswd في الحاوية، لا يحتاج المجلد المحلي الذي يشير إلى المجلد الافتراضي أن يكونا نفس الملف، كما حدّدنا في إعدادات nginx-proxy. لإنشاء مجموعات بيانات تسجيل الدخول، ستحتاج أولًا إلى تثبيت htpasswd عن طريق تشغيل الأمر التالي: sudo apt install apache2-utils تحتوي حزمة apache2-utils على أداة htpasswd. أنشئ مجلد ‎/etc/nginx/htpasswd عن طريق الامر التالي: sudo mkdir -p /etc/nginx/htpasswd وأنشئ ملف الذي سيحتوي على بيانات تسجيل الدخول لنطاقك: sudo touch /etc/nginx/htpasswd/theia.your_domain تذكر استبدال theia.your_domain بنطاق Eclipse Theia. لإضافة زوج اسم تسجيل الدخول وكلمة المرور، نفّذ الأمر التالي: sudo htpasswd /etc/nginx/htpasswd/theia.your_domain username استبدل username باسم المستخدم الذي ترغب في إضافته، وسيسألك مرتين عن كلمة المرور، وبعد ذلك سيضيف htpasswd اسم المستخدم وكلمة المرور المشفرة (hashed password) إلى نهاية الملف، يمكنك إعادة هذا الأمر بعدد مرات تسجيلات الدخول التي ترغب في إضافتها. والآن ستنشئ ملف إعدادات لنشر Eclipse Theia، وستخزنها في ملف يسمى eclipse-theia-compose.yaml، أنشئه باستخدام محرر النصوص الخاص بك: nano eclipse-theia-compose.yaml أضف الأسطر التاليّة في ملف ‎~/eclipse-theia/eclipse-theia-compose.yaml: version: '2.2' services: eclipse-theia: restart: always image: theiaide/theia:next init: true environment: - VIRTUAL_HOST=theia.your_domain - LETSENCRYPT_HOST=theia.your_domain عرّفت في هذه الإعدادات خدمة واحدة تسمى eclipse-theia مع خيار restart قيمته always وصورة حاوية theiaide/theia:next ولقد حدّدت init كـ true لإعلام Docker باستخدام init كمدير العمليّة الرئيسي عند تشغيل Eclipse Theia داخل الحاويّة. وبعد ذلك، ستحدّد متغيري بيئة في قسم environment وهما VIRTUAL_HOST و LETSENCRYPT_HOST فالأول سيمرر إلى nginx-proxy وسيخبره على أي نطاق يجب كشف الحاوية، وأما الآخر فسيستخدم من قبل Let's Encrypt لتحديد أي نطاق لطلب شهادات TLS، وفي العادة سيكونان نفسهما إلا لو وضع wildcard كقيمة لـ VIRTUAL_HOST. تذكر استبدال theia.your_domain مع اسم النطاق المطلوب، ومن ثم أغلق الملف بعد حفظه. والآن، انشر Eclipse Theia عن طريق كتابة الأمر: docker-compose -f eclipse-theia-compose.yaml up -d ستكون المخرجات كالتالي: ... Pulling eclipse-theia (theiaide/theia:next)... next: Pulling from theiaide/theia 63bc94deeb28: Pull complete 100db3e2539d: Pull complete ... Digest: sha256:c36dff04e250f1ac52d13f6d6e15ab3e9b8cad9ad68aba0208312e0788ecb109 Status: Downloaded newer image for theiaide/theia:next Creating eclipse-theia_eclipse-theia_1 ... done بعد ذلك في متصفحك، انتقل إلى النطاق الذي تستخدمه لـ Eclipse Theia، سيظهر لك المتصفح واجهة تسجيل الدخول، وبعد توفير البيانات الصحيحة، ستدخل إلى Eclipse Theia وسترى الواجهة الرسوميّة. يدل القفل في شريط العنوان إلى أن الإتصال مؤمن، وإذا لم ترى هذا بشكل فوري، انتظر بضعة دقائق لإصدار شهادات TLS وأعد تحميل الصفحة. والآن، يمكنك الوصول إلى IDE السحابي، ويمكنك البدء باستخدام المحرّر في الخطوة القادمة. الخطوة الثالثة - استخدام واجهة Eclipse Theia ستكتشف في هذا القسم بعض من مميزات واجهة Ecipse Theia. على الجانب الأيسر من IDE، ستجد صف عمودي من أربعة أيقونات لفتح المميزات الشائعة في اللوحة الجانبيّة. يمكنك تخصيص هذا الشريط أي يمكنك تحريك هذه المناظر (Views) لتغيير ترتيبهم أو حذفهم من الشريط. المنظر الأول بشكل افتراضي يفتح لوحة الاكتشاف (Explorer panel) والذي يوفر تصفح شجري لهيكل المشروع، يمكنك إدارة مجلداتك وملفاتك هنا من حيث إنشاء وحذف ونقل وإعادة تسميتهم حسب المطلوب. بعد إنشاء ملف جديد عن طريق قائمة File، سيُفتح ملف فارغ في علامة تبويب جديدة، وبمجرد حفظه، يمكنك رؤية اسم الملف في لوحة الاكتشاف الجانبيّة، ولإنشاء المجلدات، اضغط بالزر الأيمن على شريط Explorer وانقر على New Folder، ويمكنك توسعة المجلد عن طريق الضغط على اسمه وسحب وافلات الملفات والمجلدات إلى الأجزاء العليا من التسلسل الهرمي لتحريكهم إلى المكان الجديد. يوفر المنظر (view) التالي الوصول إلى وظائف البحث والاستبدال، ويوفّر المنظر الثالث لأنظمة التحكم بالمصدر التي قد تستخدمها، مثل Git. أما بالنسبة إلى المنظر الأخير فهو لخيار التنقيح، والذي يوفر الإجراءات الشائعة في اللوحة، ويمكنك حفظ إعدادات التنقيح في ملف launch.json. الجزء الأوسط من الواجهة هو محرّرك، والذي يمكنك فصله بعلامات التبويب لتعديل الشيفرة البرمجيّة، يمكنك تغيير منظر التعديل إلى وضع الشبكة (grid) أو إلى ملفات كل واحدة بجانب الأخرى، ومثل جميع IDE الحديثة، يدعم Eclipse Theia تسليط الضوء على الصياغة لشيفرتك البرمجيّة. يمكنك الوصول إلى الطرفيّة عن طريق ‎CTRL+SHIFT+`‎ أو عن طريق النقر على Terminal في القائمة العلويّة، وتحديد New Terminal، ستفتح الطرفية في لوحة السفليّة وستعمل في المجلد المشروع، والذي سيحتوي على جميع الملفات والمجلدات الموجودة في لوحة Explorer الجانبيّة. والآن لقد تعرّفت على واجهة Eclipse Theia مع أهم المميزات شائعة الاستخدام. الختام الآن، لديك Eclipse Theia مثبت على خادم أوبنتو 18.04 باستخدام Docker Compose وnginx-proxy، ولقد أمنته باستخدام شهادة TLS من Let’s Encrypt مجانيّة وأعددت المثيل لطلب بيانات تسجيل الدخول من المستخدم، يمكنك العمل على شيفرتك المصدريّة والوثائق بشكل فردي أو بالتعاون مع فريقك، ويمكنك تجربة بناء نسختك الخاصة من Eclipse Theia إذا احتجت إلى وظائف إضافيّة، للمزيد من المعلومات حول كيفيّة فعل ذلك، زر توثيق Theia. ترجمة -وبتصرف- للمقال How To Set Up the Eclipse Theia Cloud IDE Platform on Ubuntu 18.04 لصاحبه Savic

يعتبر دوكر 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

يشرح هذا الدّرس كيفيّة نشر Nginx في حاوية Docker container. نقلّل باحتواء Nginx من نفقات إدارة النظام، فلن نعود في حاجة إلى إدارة Nginx عبر مُدير الحِزَم أو بنائِه من المصدر، تسمح لنا حاوية Docker ببساطة أن نستبدل كامل الحاوية عند إطلاق إصدار جديد من Nginx، نحتاج فقط إلى الحفاظ على ملفّات إعدادات Nginx ومحتوانا. يصف Nginx نفسه كما يلي: يُستَخدَم Nginx من قبل العديد من مديري النُظُم sysadmins في الممارسة العمليّة لتخديم محتوى الويب، ابتداءً من مواقع الملفّات الثابتة flat-file وحتى upstream APIs في NodeJS، سنقوم في هذا الدّرس بتخديم صفحة ويب أساسيّة حتى نستطيع التركيز على إعداد Nginx مع حاوية Docker. إنّ حاويات Docker هي شكل شائع من ممارسات عمليّة قديمة نسبيًّا وهي الاحتواء containerization. يختلف الاحتواء عن الآلات الافتراضية (virtualization) في أنّ الإيهام يقوم بعزل العتاد hardware بعيدًا، بينما يقوم الاحتواء بعزل نظام التشغيل الأساسي بعيدًا أيضًا، يعني هذا من النّاحية العمليّة أنّه يمكننا أخذ تطبيق (أو مجموعة تطبيقات) ووضعها في حاوية (أو حاويات) لجعلها من النمط التركيبي modular، محمولة portable، قابلة للتركيب composable، وخفيفة الوزن lightweight. تعني قابليّة النقل portability أنّنا نستطيع تثبيت مُحرِّك Docker Engine (تتم الإشارة له أيضًا بلُب Docker Core، أو حتى Docker فقط) على مجموعة واسعة من أنظمة التّشغيل، وأي حاوية وظيفيّة مكتوبة من قبل أي شخص ستعمل عليه. إن أردت تعلّم المزيد حول Docker بإمكانك الاطلاع على درس Docker التّمهيدي. سنقوم بتثبيت مُحرِّك Docker على Ubuntu لأغراض هذا الدّرس. سنثبّت إصدار Docker المستقر الحالي لـ Ubuntu وهو 1.8.1. هذا الدّرس مُخصَّص لمستخدمي Nginx الجديدين على Docker، إن كنت تريد الأوامر المجرّدة لإعداد حاوية Nginx لديك تستطيع تطبيق الخطوة الأولى ومن ثمّ الانتقال إلى الخطوة الخامسة. إن كنت ترغب ببناء حاويتك خطوة بخطوة والتعلّم عن تعيين المنافذ port mapping والوضع المنفصل detached mode فقم باتّباع كامل الدّرس. المتطلبات الأساسيةمن أجل احتواء Nginx يجب علينا إتمام ما يلي: إعداد خادوم Ubuntu ويُفضَّل أن يكون مع مفاتيح SSH Keys من أجل الأمان.إعداد مستخدم بصلاحيات الجذر sudo.التحقّق من إصدار النّواة Kernel لدينا.يعتمد Docker 1.8.1 إلى حدٍّ ما على بعض الميّزات الأخيرة للنواة، لذا تأكّد من أن يكون إصدار النّواة 3.10 أو أعلى، تمتلك أنظمة تشغيل لينِكس الحديثة نواة جديدة نسبيًّا، ولكن إن كنت تريد التحقّق قم بتنفيذ الأمر uname –r: uname -rلقد قمنا بتضمين الخَرْج output من نسخة Ubuntu 14.04، والتي تحتوي إصدار نواة أعلى من 3.10، لذا لا يجب أن تقلق ما لم تقم بتنفيذ هذا الأمر على نسخة أقدم: 3.13.0-57-genericالخطوة الأولى – تثبيت Dockerيستضيف Docker على موقعه script بدء للحصول على Docker وتشغيله على جهازنا، نستطيع ببساطة تنفيذ الأمر: sudo curl -sSL https://get.docker.com/ | shلا ينبغي بشكل عام تمرير scripts عشوائيّة من الإنترنت إلى الصّدفة Shell عن طريق الأنبوب (Pipe (| sh، لأنّها قد تقوم بفعل أي شيء، ألقِ نظرة على get.docker.com إن كنت تريد معرفة ما أنت مُقبِلٌ عليه. بعد أن ينتهي تنفيذ الأمر السّابق سنرى الإصدار المُثبَّت كما يلي (قد تكون الأرقام لديك أحدث ولا مشكلة في هذا) وبعض التعليمات حول التشغيل كمستخدم غير جذري non-root\بدون sudo، نقوم في هذا الدّرس بالتشغيل كمستخدم sudo لذا لا داعي للقلق حول هذا الأمر: Client: Version: 1.8.3 API version: 1.20 Go version: go1.4.2 Git commit: f4bf5c7 Built: Mon Oct 12 05:37:18 UTC 2015 OS/Arch: linux/amd64 Server: Version: 1.8.3 API version: 1.20 Go version: go1.4.2 Git commit: f4bf5c7 Built: Mon Oct 12 05:37:18 UTC 2015 OS/Arch: linux/amd64اختياري: قم بتشغيل الحاوية hello-world للتحقّق من أنّ كل شيء يعمل كما هو متوقَّع: sudo docker run hello-worldيجب أن ترى خَرْجًا مشابهًا للتالي: $ docker run hello-world Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world 535020c3e8ad: Pull complete af340544ed62: Already exists library/hello-world:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security. Digest: sha256:d5fbd996e6562438f7ea5389d7da867fe58e04d581810e230df4cc073271ea52 Status: Downloaded newer image for hello-world:latest Hello from Docker. This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. 3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading. 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal. To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash Share images, automate workflows, and more with a free Docker Hub account: https://hub.docker.com For more examples and ideas, visit: https://docs.docker.com/userguide/نستطيع بعد الانتهاء ممّا سبق الخوض في أساسيّات Docker. الخطوة الثانية (اختيارية) – مراجعة أساسيات الحاوية: التشغيل Run، السرد List، الإزالة Removeيشرح هذا القسم كيفيّة تشغيل حاوية أساسيّة ومن ثمّ إزالتها، إن كنت تعرف مُسبقًا كيفيّة استخدام Docker بشكل عام وتريد التخطّي إلى القسم المتعلّق بـ Nginx فاذهب إلى الخطوة الخامسة. لقد ثبّتنا عميل Docker Client كجزء من تثبيت Docker لدينا، لذا نمتلك أداة سطر الأوامر التي تسمح لنا بالتفاعل مع حاوياتنا. إن قمنا بتنفيذ الأمر التالي: sudo docker ps -aينبغي أن نحصل على خَرْج مُشابِه لما يلي: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a3b149c3ddea hello-world "/hello" 3 minutes ago Exited (0) 3 minutes ago nostalgic_hopperنستطيع مشاهدة بعض المعلومات الأساسيّة حول حاويتنا. سنلاحظ أنّها تملك اسمًا لا معنى له مثل nostalgic_hopper، يتم توليد هذه الأسماء تلقائيًّا إن لم نُحدِّد اسمًا عند إنشاء الحاوية. نرى أيضًا في هذا المثال أنّه تم تشغيل الحاوية منذ 3 دقائق وتم إنشاؤها منذ 3 دقائق. إن قمنا بتشغيل الحاوية مرّة أخرى باستخدام هذا الأمر (مع وضع اسم حاويتنا بدلًا من nostalgic_hopper): sudo docker start nostalgic_hopperومن ثمّ نفّذنا الأمر التالي لعرض الحاويات: sudo docker ps -aيجب أن نشاهد أنّه تم تشغيل الحاوية مؤخّرًا: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a3b149c3ddea hello-world "/hello" 4 minutes ago Exited (0) 9 seconds ago nostalgic_hopperتقوم حاويات Docker افتراضيًّا بتنفيذ الأوامر المسندة إليها ومن ثمّ الخروج. تكون بعض الحاويات مُعدّة لتنفيذ بعض المهام ومن ثمّ الانتهاء من ذلك، بينما يبقى بعضها يعمل بدون وقت مُحدّد. الآن وقد مررنا على بعض أساسيّات Docker فلنقم بإزالة الصّورة image التي تُدعى hello-world، حيث أنّنا لن نحتاجها مرّة أخرى (تذكّر أن تضع اسم حاويتك بدلًا من nostalgic_hopper أو استخدم مُعرِّف ID الحاوية). سنبدأ بعد ذلك باستخدام Nginx. الخطوة الثالثة (اختيارية) – تعلم كيفية عرض expose المنفذ portسنقوم في هذا القسم بتنزيل صورة Nginx Docker image ونرى كيفيّة تشغيل الحاوية بحيث تكون مُتاحة للعوام كخادوم ويب. تكون الحاويات افتراضيًّا غير مُتاحة للوصول من قبل الإنترنت، لذا نحتاج إلى تعيين منفذ الحاوية الدّاخلي إلى منفذ Droplet لدينا، هذا ما سنتعلّمه في هذا القسم. سنحصل في البداية على صورة Nginx. تحتوي الخطوة الخامسة على الأوامر النهائيّة لنشر الحاوية كاملة، لذا إن لم تكن مهتمًّا بتفاصيل التنفيذ تستطيع التخطّي والانتقال إلى هناك. نقوم بتنفيذ الأمر التالي للحصول على صورة Nginx Docker: sudo docker pull nginxيقوم هذا بتنزيل جميع العناصر الضّروريّة للحاوية، يُخبِّئ Docker كل هذا في ذاكرة مؤقتة cache حتى لا نحتاج إلى تنزيل صورة الحاوية في كل مرّة نريد فيها تشغيل الحاوية. تحتفظ Docker بموقع يُدعى Dockerhub وهو مستودع عام لملفّات Docker (يتضمّن كل من الصّور الرسميّة والمُقدَّمة من قبل المستخدمين)، الصّورة التي قمنا بتنزيلها هي صورة Nginx الرسميّة، والتي توفّر علينا عناء بناء الصّورة الخاصّة بنا. فلنقم بتشغيل حاوية Nginx Docker باستخدام هذا الأمر: sudo docker run --name docker-nginx -p 80:80 nginxrun هو أمر إنشاء حاوية جديدة يُحدِّد العَلَم name-- اسم الحاوية (إن تركناه فارغًا سيتم تعيينه تلقائيًّا لنا، مثل nostalgic_hopper في الخطوة الثّانية)يُحدِّد p- المنفذ الذي نقوم بعرضه على هيئة p local-machine-port:internal-container-port-، في هذه الحالة نقوم بتعيين المنفذ 80 في الحاوية إلى المنفذ 80 على الخادومnginx هو عبارة عن اسم الصورة على dockerhub (قمنا بتنزيلها من قبل باستخدام الأمر pull، ولكن يقوم Docker بهذا تلقائيًّا إن كانت الصورة مفقودة)هذا هو كل ما نحتاجه للحصول على Nginx وتشغيله، نقوم الآن بكتابة عنوان IP لـ Droplet لدينا في متصفّح الويب وهنا يجب أن نرى صفحة "Welcome to nginx". سنلاحظ أيضًا في جلسة الصّدفة shell لدينا أنّه يتم تحديث سِجِل Nginx عندما نقوم بطلبات إلى خادومنا، لأنّنا نشغّل الحاويات لدينا بشكل تفاعلي. فلنضغط على الاختصار CTRL+C للعودة إلى جلسة الصّدفة shell لدينا. إن حاولنا الآن تحميل الصفحة سنتلقّى الصّفحة "تم رفض الاتصال" "connection refused"، وقد حدث هذا لأنّنا قمنا بإيقاف تشغيل حاويتنا، بإمكاننا التحقّق من ذلك باستخدام هذا الأمر: sudo docker ps -aيجب أن نرى شيئًا مشابهًا للخَرْج التّالي: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 05012ab02ca1 nginx "nginx -g 'daemon off" 57 seconds ago Exited (0) 47 seconds ago docker-nginxنستطيع أن نرى أنّه تمّ الخروج من حاوية Docker لدينا. لن يكون Nginx مفيدًا جدًّا إن كان يجب علينا أن نكون متصلين attached إلى صورة الحاوية من أجل أن يعمل، لذا سنشرح في الخطوة التالية كيفية فصل detach الحاوية للسماح لها بالعمل بشكل مستقل. نقوم بإزالة الحاوية docker-nginx الحالية عن طريق هذا الأمر: sudo docker rm docker-nginxسنشرح في الخطوة التالية كيفيّة تشغيلها في الوضع المنفصل detached mode. الخطوة الرابعة (اختيارية) – تعلم كيفية التشغيل في الوضع المنفصلنُنشِئ حاوية Nginx جديدة منفصلة باستخدام هذا الأمر: sudo docker run --name docker-nginx -p 80:80 -d nginxأضفنا العَلَم d- لتشغيل هذه الحاوية في الخلفيّة. يجب أن يكون الخَرْج ببساطة مُعرِّف ID الحاوية الجديدة. إن قُمنا بتشغيل أمر السّرد list: sudo docker psسنرى في الخَرْج العديد من الأشياء التي لم نشاهدها من قبل: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b91f3ce26553 nginx "nginx -g 'daemon off" About a minute ago Up About a minute 0.0.0.0:80->80/tcp, 443/tcp docker-nginxبإمكاننا أن نرى أنّه بدلًا من Exited (0) X minutes ago نمتلك الآن Up About a minute، ونرى أيضًا تعيين المنفذ port mapping. إن ذهبنا إلى عنوان IP خادومنا باستخدام المتصفّح فسنشاهد الصفحة "!Welcome to nginx" مرّة أخرى، ولكن في هذه المرّة تعمل الحاوية في الخلفيّة لأنّنا حدّدنا العَلَم d- والذي يُخبِر Docker أن يُشغِّل هذه الحاوية في الوضع المنفصل. نمتلك الآن نسخة من Nginx تعمل في الوضع المنفصل. وبالرغم من ذلك فهي ليست مفيدة بما فيه الكفاية حتى الآن، لأنّنا لا نستطيع تحرير edit ملف الإعدادات ولا تمتلك الحاوية نفاذًا إلى أي من ملفّات مواقع الويب لدينا. نوقف الحاوية بتنفيذ الأمر التّالي: sudo docker stop docker-nginxوالآن وقد توقفت الحاوية عن العمل (نستطيع التحقّق باستخدام الأمر sudo docker ps –a إن أردنا أن نكون متأكدين من ذلك) فبإمكاننا إزالتها بتنفيذ الأمر التّالي: sudo docker rm docker-nginxسنصل الآن إلى الإصدار النّهائي لحاويتنا مع وقفة سريعة لإنشاء ملف مُخصَّص لموقع الإنترنت. الخطوة الخامسة – بناء صفحة ويب ليتم تخديمها على Nginxسنُنشِئ في هذه الخطوة صفحة فهرس index مُخصَّصة لموقعنا، يسمح لنا هذا الإعداد بأن نملك محتوى للموقع بشكل دائم تتم استضافته خارج الحاوية (العابرة transient). فلنقم بإنشاء دليل جديد من أجل محتوى موقعنا بداخل الدّليل الرئيسي home directory والانتقال إليه بتنفيذ الأوامر التالية: mkdir -p ~/docker-nginx/html cd ~/docker-nginx/htmlنُنشِئ الآن ملف HTML (طبّقنا الأوامر من أجل مُحرِّر النّصوص Vim ولكن تستطيع استخدام أي مُحرِّر نصوص آخر). vim index.htmlننتقل إلى وضع الإدخال insert mode عن طريق الضغط على i، ونلصق المحتوى التّالي بداخل الملف السّابق (أو بإمكانك إضافة محتوى HTML الخاص بك): <html> <head> <link href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css" rel="stylesheet" integrity="sha256-MfvZlkHCEqatNoGiOXveE8FIwMzZg4W85qfrfIFBfYc= sha512-dTfge/zgoMYpP7QbHy4gWMEGsbsdZeCXz7irItjcC3sPUFtf0kuFbDz/ixG7ArTxmDjLXDmezHubeNikyKGVyQ==" crossorigin="anonymous"> <title>Docker nginx Tutorial</title> </head> <body> <div class="container"> <h1>Hello Digital Ocean</h1> <p>This nginx page is brought to you by Docker and Digital Ocean</p> </div> </body> </html>إن كنت على معرفة بـ HTML سترى أنّها صفحة ويب بسيطة، قمنا بتضمين وسم <link> يُشير إلى شبكة توزيع محتوى CDN من أجل Bootstrap (وهو إطار عمل CSS يُعطي لصفحتنا مجموعة من التنسيقات المتجاوبة responsive)، تستطيع قراءة المزيد عن Bootstrap. نحفظ هذا الملف الآن عن طريق الضغط على ESC ومن ثمّ wq: و ENTER: تُخبِر (write (w أن يقوم Vim بكتابة التغييرات إلى الملف.تُخبِر (quit (q أن يقوم Vim بالخروج.نمتلك الآن صفحة فهرس index بسيطة بدلًا من صفحة هبوط Nginx الافتراضيّة. الخطوة السادسة – ربط الحاوية إلى نظام الملفات المحليفي هذا القسم سنضع كل ما سبق معًا، سنقوم بتشغيل حاوية Nginx لدينا بحيث تكون قابلة للنفاذ على الإنترنت عبر المنفذ 80، وسنقوم بتوصيلها إلى محتوى موقع الويب لدينا على الخادوم. معلومات أساسية حول مسارات التخزين (volumes) والتي هي الرّبط إلى محتوى خادوم بشكل دائم من قبل الحاوية الخاصة بنايسمح لنا Docker بربط الأدلّة directories من نظام الملفّات المحلّي للجهاز الافتراضي Virtual Machine لدينا إلى حاوياتنا. وفي حالتنا بما أنّنا نريد تخديم صفحات ويب نحتاج إلى إعطاء حاويتنا الملفّات التي نريد تقديمها. كان باستطاعتنا نسخ الملفّات إلى الحاوية كجزء من ملفّات Docker، أو نسخها إلى الحاوية بعد إسقاطها أو توقيفها، ولكن هاتين الطريقتين تبقيان موقعنا في حالة ثابتة بداخل حاويتنا، أمّا باستخدام ميزة حجوم volumes البيانات بإمكاننا إنشاء ارتباط رمزي بين نظام ملفّات Droplet ونظام ملفّات الحاوية، يسمح لنا هذا بتحرير ملفّات صفحات الويب الموجودة حاليًّا وإضافة ملفّات جديدة إلى الدّليل وستكون الحاوية قادرة على النفاذ لها بشكل تلقائي، إن كنت ترغب بقراءة المزيد حول Docker ومسارات التخزين volumes تحقّق من وثائق حجوم البيانات data volumes. تكون حاوية Nginx مُعدَّة افتراضيًّا لتبحث عن صفحة فهرس index في المسار usr/share/nginx/html/، لذا نحتاج في حاوية Docker الجديدة الخاصّة بنا أن نقوم بإعطائها نفاذًا إلى ملفّاتنا في ذلك الموقع. إنشاء الربطلإنشاء الربط نستخدم العَلَم v- لتعيين مُجلَّد من جهازنا المحلّي (docker-nginx/html/~) إلى مسار نسبي في الحاوية (usr/share/nginx/html/). نستطيع إتمام هذا بتنفيذ الأمر التالي: sudo docker run --name docker-nginx -p 80:80 -d -v ~/docker-nginx/html:/usr/share/nginx/html nginxنرى أنّ الإضافة الجديدة إلى الأمر v ~/docker-nginx/html:/usr/share/nginx/html- هي رابط مسار تخزين volume لدينا. تُحدِّد v- أنّنا نقوم بربط مسار تخزين volume.الجزء الذي على يسار ":" هو موقع ملفّنا/دليلنا على الجهاز الافتراضي (docker-nginx/html/~).الجزء الذي على يمين ":" هو الموقع الذي نقوم بالرّبط إليه في حاويتنا (usr/share/nginx/html/).إن قمنا بعد تنفيذ هذا الأمر بالتوجّه باستخدام المتصفّح إلى عنوان IP الخاص بـ DigitalOcean Droplet مثلا (إن كنت على DigitalOcean) لدينا فيجب أن نرى الترويسة الأولى من Hello Digital Ocean (أو أي صفحة ويب أنشأتها في الخطوة الخامسة). إن كنت سعيدًا بإعدادات Nginx الافتراضيّة الأخرى فأنت الآن جاهز. تستطيع رفع المزيد من المحتوى إلى الدّليل docker-nginx/html/~ وستتم إضافته إلى موقعك بشكل مباشر. إن قمنا على سبيل المثال بتعديل ملف الفهرس لدينا وأعدنا تحميل نافذة متصفحنا، سنرى أنّ التحديث يحدث آنيًّا، نستطيع بناء موقع كامل من ملفّات HTML ثابتة بهذه الطريقة، على سبيل المثال إن أضفنا صفحة about.html فبإمكاننا النفاذ إليها على الرّابط http://your_server_ip/about.html بدون الحاجة للتعامل مع حاويتنا. الخطوة السابعة (اختيارية) – استخدام ملف إعدادات Nginx الخاص بناهذ القسم مُخصَّص للمستخدمين المتقدّمين الذين يرغبون باستخدام ملف إعدادات Nginx الخاص بهم مع حاوية Nginx لديهم، قم بتجاوز هذه الخطوة إن كنت لا تملك ملف إعدادات مُخصَّص تريد استخدامه. فلنقم بالعودة دليلًا إلى الوراء كيلا نكتب إلى دليل HTML المتاح للعوام لدينا: cd ~/docker-nginxإن كنّا نرغب بإلقاء نظرة على ملف الإعدادات الافتراضي نقوم فقط بنسخه باستخدام أمر Docker للنسخ: sudo docker cp docker-nginx:/etc/nginx/conf.d/default.conf default.confوبما أنّنا سنقوم باستخدام ملف conf. مُخصَّص من أجل Nginx سنحتاج إلى إعادة بناء الحاوية. نقوم في البداية بإيقاف الحاوية: sudo docker stop docker-nginxنزيل الحاوية باستخدام الأمر: sudo docker rm docker-nginxنستطيع الآن تحرير الملف الافتراضي محليًّا (لتخديم دليل جديد أو استخدام proxy_pass لتمرير حركة مرور البيانات traffic إلى تطبيق أو حاوية أخرى كما كنّا نفعل مع تثبيت Nginx الاعتيادي)، تستطيع القراءة حول ملف إعدادات Nginx في دليل ملف إعدادات Nginx. بعد أن نقوم بحفظ ملف إعداداتنا المُخصَّص يحين الوقت لصنع حاوية Nginx، نضيف ببساطة علم v- آخر مع المسار المناسب لإعطاء حاوية Nginx الجديدة الروابط المناسبة لتعمل من خلال ملف إعداداتنا: sudo docker run --name docker-nginx -p 80:80 -v ~/docker-nginx/html:/usr/share/nginx/html -v ~/docker-nginx/default.conf:/etc/nginx/conf.d/default.conf -d nginxلا يزال هذا الأمر يربط صفحات الموقع المُخصَّصة إلى الحاوية أيضًا. نلاحظ أنّنا سنحتاج إلى إعادة تشغيل الحاوية باستخدام الأمر docker restart بعد أي تغيير لملف الإعدادات أثناء تشغيل الحاوية، لأنّ Nginx لا يقوم بإعادة تحميل فوري إن تمّ تغيير ملف إعداداته: sudo docker restart docker-nginxالخاتمة نمتلك الآن حاوية Nginx قيد التشغيل وتُخدِّم صفحة ويب مُخصَّصة. نوصي من هذه النقطة القراءة حول ربط حاوية Docker إن كنت تريد التعلّم حول ربط الحاويات ببعضها لأغراض استخدام Nginx كوسيط عكسي reverse proxy لتخديم تطبيقات الويب الأخرى المعتمدة على الحاوية. إن كنت تريد إدارة مجموعة من الحاويات مثل حاوية تطبيق، حاوية قاعدة بيانات، وحاوية Nginx، فألقِ نظرة على تركيب Docker Compose. ترجمة -وبتصرّف- لـ How To Run Nginx in a Docker Container on Ubuntu 14.04 لصاحبه Thomas Taege.

لعلك تتساءل عن السبب الذي يجعلنا نستخدم Docker لتثبيت lamp أو lemp في حين أننا نستطيع تثبيتهما يدويًا؟ فتثبيتهما سهل ولا يحتاج إلى الكثير من التعقيد، لماذا نلجأ إلى Docker؟ دعني أجيب عن هذا السؤال، إنّ docker برنامج خفيف ويغنينا عن الحاجة إلى الآلات الوهمية مثل Virtualbox أو Xen أو غيرهما لنختبر أو نثبت أنظمة التشغيل. وفائدته معنا في هذا المقال أننا نستطيع استخدامه لسحب نسخ جاهزة من LAMP أو LEMP لتشغيلها في بضع دقائق، بدلًا من التثبيت اليدوي لأباتشي، ثم قاعدة بيانات مثل MariaDB أو mySQL، ثم PHP. وتحدث هذه الحالة التي تحتاج فيها إلى نسخة جاهزة وسريعة لاختبار شيء ما عليها إن كنت مطورًا أو مختبرًا أو شغوفًا بالبرمجة وتريد أن تختبر تطبيقًا يعمل في الويب، فتجد نفسك في حاجة إلى تثبيت كل تلك الخطوات التي ذكرتها في الفقرة السابقة، ولعلك جربت هذا من قبل ووجدتها عملية مرهقة وطويلة، وهنا تبرز ميزة Docker حيث يمكننا تثبيت وتشغيل برامج جاهزة ومعدة مسبقًا مباشرة دون الحاجة إلى خوض تفاصيلها التقنية كأننا نثبتها لأول مرة بأنفسنا. وهو ما سنشرحه في هذا المقال على LAMP أو LEMP. تثبيت LAMP/LEMP باستخدام Docker دعنا نبحث في docker عن نسخ جاهزة من LAMP أو LEMP: $ sudo docker search lamp وسيكون الخرج مشابهًا لهذا: NAME DESCRIPTION STARS OFFICIAL AUTOMATED reinblau/lamp Dockerfile for PHP-Projects with MySql client 17 [OK] dockie/lamp 6 [OK] nickistre/ubuntu-lamp LAMP server on Ubuntu 4 [OK] nickistre/ubuntu-lamp-wordpress LAMP on Ubuntu with wp-cli installed 4 [OK] nickistre/centos-lamp LAMP on centos setup 3 [OK] damienlagae/lamp Docker LAMP with supervisord 3 [OK] boolean93/lamp LAMP based on linode/lamp 2 [OK] drunomics/lamp 1 [OK] avatao/lamp LAMP base image 1 [OK] nickistre/ubuntu-lamp-xdebug LAMP on Ubuntu with xdebug installed 1 [OK] nickistre/centos-lamp-wordpress LAMP on CentOS setups with wp-cli installed 1 [OK] linuxconfig/lamp Automated build LAMP stack environment for... 1 [OK] greyltc/lamp a super secure, up-to-date and lightweight... 0 [OK] kazaoki/lamp ローカルフォルダをマウントす... 0 [OK] greyltc/lamp-gateone LAMP stack with gateone server & webdav 0 [OK] fauria/lamp Modern, developer friendly LAMP stack. Inc... 0 [OK] drunomics/lamp-memcached LAMP + Memcached base image. 0 [OK] rpawel/lamp Apache 2.4 + php5-fpm container 0 [OK] lioshi/lamp Docker image for LAMP + MySql under debian 0 [OK] nickistre/centos-lamp-xdebug LAMP on centos with xDebug 0 [OK] greyltc/lamp-aur LAMP stack (in Arch with php7) with AUR ac... 0 [OK] alledia/lamp General LAMP for our tests, based on phusi... 0 [OK] greatfox/lamp 0 [OK] cnrk/lamp LAMP stack Docker image. 0 [OK] grmanit/lamp Based on tutum/lamp with additional settin... 0 [OK] وكما ترى من النتيجة أعلاه، فهناك الكثير من نسخ LAMP المتوفرة لتوزيعات آرتش وCent OS وأوبنتو، وهي مرتبة وفق تقييم المستخدمين لها. وبالمثل يمكننا أن نبحث عن LEMP أيضًا: $ sudo docker search lemp ثم اختر نسخة lemp مناسبة لك، سأحمّل أنا مثلًا nickistre/ubuntu-lamp: $ docker pull nickistre/ubuntu-lamp ويكون الخرج مشابهًا لهذا: Using default tag: latest latest: Pulling from nickistre/ubuntu-lamp faecf96fd5ab: Pull complete 995977506e98: Pull complete efb63fb8dcb6: Pull complete a3ed95caeb02: Pull complete 61626f5cc06d: Pull complete d42e54d21590: Pull complete 4a32d1f581a1: Pull complete 52f44a8dd6d0: Pull complete ce6c1074ae9e: Pull complete 2fa559435609: Pull complete 93a433221384: Pull complete 521d09b9a2d1: Pull complete 6222edddc59d: Pull complete 8fa401b50efc: Pull complete 683063a5d5e0: Pull complete 1f87fa5088b3: Pull complete c5ee1c14048f: Pull complete Digest: sha256:e913d43c204b3cdb931156c1a680c712acfe8db531225ec7b9e4708fc7ebe93c Status: Downloaded newer image for nickistre/ubuntu-lamp:latest سيحمّل الأمر أعلاه نسخة LAMP لأوبنتو، يمكنك تحميل نسختك الخاصة لتوزيعتك كما أوضحنا قبل قليل. وإن لم ترغب في تحميل واستخدام النسخ التي يوفرها docker من الطرفية، فيمكنك تحميلها من Docker hub حيث تجد آلاف النسخ المستضافة هناك. اذهب إلى الرابط أعلاه وابحث عن نسخة LAMP التي تريدها وحمّلها. في حالتي أنا، فقد اخترت نسخة nickistre/ubuntu-lamp كما قلت قبل قليل: اضغط على النسخة التي تريد لمعرفة مزيد من البيانات عنها مثل كيفية تثبيتها واستخدامها: ستجد النسخ التي تحملها في مجلد var/lib/docker/، ولسرد تلك النسخ نفذ الأمر التالي: $ docker images مثال للخرج: REPOSITORY TAG IMAGE ID CREATED SIZE nickistre/ubuntu-lamp latest 5e750e4f49e4 2 days ago 633 MB reinblau/lamp latest 2813b461f843 9 days ago 697.9 MB hello-world latest 690ed74de00f 5 months ago 960 B والآن نشغّل النسخة بعد أن حمّلناها: $ docker run -it nickistre/ubuntu-lamp /bin/bash ستجد نفسك قد دخلت بشكل آلي إلى المجلد الجذر للحاوية على الويب كمستخدم جذر: root@184851ac9ebd:/# شغّل خدمة أباتشي: # service apache2 start ثم خدمة MySQL: # service mysql start تأكد ما إن كان خادم أباتشي يعمل أم لا، بفتح هذه الصفحة في متصفحك http://container_IP/. ولكي تجد عنوان IP، اكتب ifconfig أو ip addr في طرفية الحاوية، يجب أن ترى هنا صفحة اختبار خادم أباتشي. ويمكنك معرفة إصدارات أباتشي وMySQL وPHP بهذه الأوامر بالترتيب: # apache2 -v # mysql -v # php -v وهكذا نكون قد ثبتنا LAMP في أوبنتو واستخدمناه، ويمكنك الآن أن تختبر تطبيقك كما كنت تريد، دون أن تشغل بالك بتثبيت كل تلك الحزم يدويًا أو على حاسوبك، حتى لو كان في آلة وهمية. ترجمة -بتصرف- لمقال Deploy LAMP and/or LEMP stacks easily using Docker لصاحبه SK

تمهيد بشكل عام، نستعمل حاويات Docker لمرة وحيدة فقط، وهي تعمل إلى أن ينتهي تنفيذ الأمر الموكل إليها. لكن في بعض الأحيان تحتاج التطبيقات إلى الوصول إلى بيانات أو حفظها بعد حذف الحاوية. أمثلة عن البيانات التي تحتاج التطبيقات إلى الوصول إليها تتضمن قواعد البيانات، والمحتوى المولّد من قِبل المستخدم لمواقع الويب، وملفات السجلات. يمكن الوصول إلى تلك البيانات بشكلٍ دائم باستخدام حجوم Docker (أي Docker Volumes). المتطلبات المسبقة خادوم أوبنتو 16.04 (أو 14.04) مضبوطٌ كما في درس «الإعداد الابتدائي لخادوم أوبنتو 14.04»، بما في ذلك إعداد حساب مستخدم عادي لكنه يملك امتيازات الجذر (root) عبر الأداة sudo. برمجية Docker مثبّتة على حاسوبك ملاحظة: صحيحٌ أننا نفترض أنَّنا سنستعمل Docker على أوبنتو 16.04، لكن أوامر docker التي تتعامل مع حجوم Docker والمذكورة في هذا الدرس يجب أن تعمل عملًا صحيحًا على بقية الأنظمة لطالما كانت Docker مثبّتةً عليها وأُضيف المستخدم sudo إلى المجموعة docker. يمكن إنشاء حجوم Docker ووصلها بأمرٍ واحد ألا وهو الأمر المُستخدَم لإنشاء الحاوية، أو يمكن إنشاء الحجوم بشكل مستقلٍ عن أيّة حاوية ثم وصلها إليها لاحقًا. سنناقش في هذا الدرس أربع طرائق مختلفة لمشاركة البيانات بين الحاويات. أولًا: إنشاء حجم مستقل أتى الأمر docker volume create مع إصدار 1.9 من Docker والذي يسمح لك بإنشاء حجم دون ربطه بأية حاوية. سنستخدم هذا الأمر لإنشاء حجم باسم DataVolume1: docker volume create --name DataVolume1 إذا عُرِض الاسم، فذلك يُشير إلى نجاح تنفيذ الأمر السابق: DataVolume1 لكي نستعمل هذا الحجم، علينا إنشاء حاوية جديدة مبنية على صورة ubuntu مستعملين الخيار ‎--‎rm لحذف الحاوية تلقائيًا بعد خروجنا منها، وسنستخدم الخيار ‎-v لوصل الحجم الجديد. الخيار ‎-v يتطلب ذكر اسم الحجم متبوعًا بنقطتين رأسيتين : ثم المسار المطلق لمكان وصل الحجم داخل الحاوية. إذا لم يكن المجلد المذكور في المسار السابق موجودًا في صورة التوزيعة، فسيُنشَأ ثم سيُنفَّذ الأمر السابق؛ وفي حال كان المجلد موجودًا، فسيؤدي وصل الحجم إليه إلى إخفاء المحتوى الموجود في الصورة الأصلية. docker run -ti --rm -v DataVolume1:/datavolume1 ubuntu لنكتب بعض البيانات إلى الحجم قبل إغلاق الحاوية: root@802b0a78f2ef:/# echo "Example1" > /datavolume1/Example1.txt ولاستعمالنا الخيار ‎--rm عند إنشاء الحاوية، فستُحذَف الحاوية تلقائيًا عند خروجنا منها. لكن الحجم سيبقى متاحًا للوصول. root@802b0a78f2ef:/# exit يمكننا أن نتحقق أنَّ الحجم ما يزال موجودًا في النظام عبر الأمر docker volume inspect: docker volume inspect DataVolume1 الناتج: [ { "Name": "DataVolume1", "Driver": "local", "Mountpoint": "/var/lib/docker/volumes/datavolume1/_data", "Labels": null, "Scope": "local" } ] ملاحظة: يمكننا أيضًا تفحص البيانات الموجودة في المسار المذكور في سطر Mountpoint لكن لا يُستحسَن تعديلها، لأنَّ ذلك قد يؤدي إلى حدوث عطب في البيانات إن كانت الحاوية تعمل وتجري تعديلات على تلك الملفات. لنبدأ الآن حاويةً جديدةً ونربط الحجم DataVolume1 إليها: docker run --rm -ti -v DataVolume1:/datavolume1 ubuntu سنُنفِّذ الأمر الآتي داخل الحاوية: root@d73eca0365fc:/# cat /datavolume1/Example1.txt الناتج: Example1 لنخرج الآن من الحاوية بالأمر exit. ثانيًا: إنشاء حجم مرتبط بحاوية لكن سيبقى موجودًا بعد حذفها سنُنشِئ في المثال الآتي حجمًا وحاويةً في آنٍ واحد، ومن ثم سنحذف الحاوية، ثم سنربط الحجم إلى حاويةٍ جديدة. سنستخدم الأمر docker run لإنشاء حاوية جديدة بناءً على صورة ubuntu، وسيؤدي استخدام الخيار ‎-t إلى منحنا وصولًا إلى الطرفية، والخيار ‎-i سيسمح لنا بالتفاعل مع الحاوية. ولغرض التوضيح، سأستخدم الخيار ‎--name لتحديد اسم للحاوية، ثم سأستخدم الخيار ‎-v لإنشاء حجم جديد، وسنسميّه DataVolume2، وسنستخدم النقطتين الرأسيتين لفصل الاسم عن مسار وصل الحجم في الحاوية. وفي النهاية سنطلب إنشاء الحاوية لتبدأ تنفيذها بالأمر الافتراضي الموجود في ملف Docker لصورة Ubuntu (الذي هو الأمر bash) لكي نحصل على وصول إلى الصدفة (shell): docker run -ti --name=Container2 -v DataVolume2:/datavolume2 ubuntu ملاحظة: الخيار ‎-v هو خيارٌ مرنٌ جدًا، إذ يستطيع إنشاء وصل ترابطي، أو يمكنه إنشاء حجم جديد بتعديلٍ بسيط جدًا في شكله. فلو بدأ أوّل وسيطٍ بشرطة مائلة / أو ‎~/‎ فسيُنشِئ وصلًا ترابطيًا، لكن إن حذفت الشرطة في أوّل وسيط، فسيُنشِئ حجمًا. ‎-v /path:/path/in/container وصل المسار ‎/path في الجهاز المضيف إلى ‎/path/in/container في الحاوية. ‎-v path:/path/in/container إنشاء حجم باسم path دون علاقة بالمضيف. ولمّا كنا داخل الحاوية، فلنكتب بعض البيانات إلى الحجم: root@87c33b5ae18a:/# echo "Example2" > /datavolume2/Example2.txt root@87c33b5ae18a:/# cat /datavolume2/Example2.txt الناتج: Example2 سنخرج من الحاوية باستخدام الأمر exit. سنُعيد الآن تشغيل الحاوية مرةً أخرى، وسيتم وصل الحجم تلقائيًا. docker start -ai Container2 لنتأكد من أنَّ الحجم قد وصِلَ إلى الحاوية وما تزال البيانات موجودةً فيه: root@87c33b5ae18a:/# cat /datavolume2/Example2.txt الناتج: Example2 لنخرج مرةً أخرى من الحاوية بالأمر exit. لن تسمح لنا Docker بحذف الحجم إذا كان مرتبطًا بحاوية، لننظر ماذا سيحدث لو جربنا ذلك: docker volume rm DataVolume2 ستخبرنا الرسالة الآتية أنَّ الحجم ما يزال مستخدم وستعطينا المُعرِّف الكامل للحاوية: Error response from daemon: Unable to remove volume, volume still in use: remove DataVolume2: volume is in use - [719f98391ecf1d6f0f053ffea1bbd84cd2dc9cf6d31d5a4f348c60d98392804c] يمكننا استخدام المُعرِّف السابق لحذف الحاوية: docker rm 719f98391ecf1d6f0f053ffea1bbd84cd2dc9cf6d31d5a4f348c60d98392804c لن يؤثر حذف الحاوية على الحجم المرتبط بها، وما زال موجودًا في النظام، ونستطيع التحقق من ذلك باستخدام الأمر docker volume ls: docker volume ls الناتج: DRIVER VOLUME NAME local DataVolume2 نستطيع الآن استخدام الأمر docker volume rm لحذف الحجم بتمرير اسمه إلى الأمر السابق: docker volume rm DataVolume2 أنشأنا في هذا المثال حجمًا فارغًا مع الحاوية الذي يرتبط بها في آنٍ واحد. أما في المثال القادم فسنرى ماذا سيحدث لو أنشأنا حجمًا ووصلناه إلى مجلدٍ فيه بيانات موجودة مسبقًا في الحاوية. ثالثًا: إنشاء حجم وربطه بمجلدٍ فيه بيانات عمومًا، لا يكون هنالك فرقٌ بين إنشاء حجم باستخدام الأمر docker volume create وبين إنشائه عند تشغيل الحاوية، لكن هنالك استثناءٌ وحيدٌ لهذه القاعدة، ويحدث عندما نُنشِئ حجمًا في نفس وقت إنشاء الحاوية وكان المسار الذي نريد ربط الحجم فيه مجلدًا موجودًا في الصورة الأصلية وفيه بيانات، وفي هذه الحالة ستُنسَخ البيانات الموجودة في ذاك المجلد إلى الحجم. كمثال عن الحالة السابقة، سنُنشِئ حاويةً ونصل الحجم الجديد إلى المجلد ‎/var الموجود مسبقًا في صورة التوزيعة والذي يحتوي على بيانات: docker run -ti --rm -v DataVolume3:/var ubuntu جميع المحتوى الموجود في مجلد ‎/var في الصورة الأصلية سيُنسَخ إلى الحجم، ثم يمكننا وصل الحجم إلى الحاوية الجديدة. وفي هذه المرة، سنُنفِّذ الأمر ls بدلًا من الأمر الافتراضي bash، والذي سيُظهِر محتويات الحجم دون الحاجة إلى الدخول إلى الصدفة: docker run --rm -v DataVolume3:/datavolume3 ubuntu ls DataVolume3 كما توقعنا، سيحتوي الحجم DataVolume3 على نسخةٍ من محتويات مجلد ‎/var في الصورة الأصلية: backups cache lib local lock log mail opt run spool tmp من غير المرجّح أن نصل المجلد ‎/var بهذه الطريقة، لكن قد تستفيد من المعلومات السابقة إذا أردت إنشاء صورة خاصة بك وتريد طريقةً سهلةً للحفاظ على البيانات. سنشرح في المثال الآتي كيفية مشاركة الحجم مع أكثر من حاوية. رابعًا: مشاركة البيانات بين أكثر من حاوية Docker كل ما فعلناه منذ بداية هذا الدرس هو وصل الحجم إلى حاوية واحدة فقط بنفس الوقت، لكننا نرغب عادةً بالسماح بمشاركة البيانات بين أكثر من حاوية عبر وصل الحجم إلى عدِّة حاوية معًا. وهذا سهلٌ جدًا، لكن هنالك مشكلة محورية: لا تدعم Docker حاليًا ميزة التعامل مع قفل الملفات (file locking)، فلو احتاجت أكثر من حاوية إلى الكتابة على الحجم، فيجب أن تكون البرمجيات الموجودة في تلك الحاويات مصممةً لكي تكتب إلى أماكن تخزين البيانات المشتركة، لتجنّب تلف البيانات. إنشاء الحاوية Container4 والحجم DataVolume4 سنستخدم الأمر docker run لإنشاء حاوية جديدة باسم Container4 ووصل حجم جديد إليها: docker run -ti --name=Container4 -v DataVolume4:/datavolume4 ubuntu سنُنشِئ الآن ملفًا ونضع فيه بعض المحتوى النصي: root@db6aaead532b:/# echo "This file is shared between containers" > /datavolume4/Example4.txt ثم سنخرج من الحاوية بالأمر exit. سنعود الآن إلى سطر الأوامر في الجهاز المضيف، حيث سنُنشِئ حاويةً جديدةً ونصل فيها الحجم DataVolume4. إنشاء الحاوية Container5 ووصل الحجم الذي كان موصولًا في Container4 سنُنشِئ حاويةً جديدةً باسم Container5 ونصل فيها الحجم الذي كان موصولًا في Container4: docker run -ti --name=Container5 --volumes-from Container4 ubuntu root@81e7a6153d28:/# cat /datavolume4/Example4.txt This file is shared between containers لنضف بعض النصوص إلى أحد الملفات من الحاوية الثانية: root@81e7a6153d28:/# echo "Both containers can write to DataVolume4" >> /datavolume4/Example4.txt ثم سنخرج من الحاوية بالأمر exit. سنتأكد الآن أنَّ البيانات الجديدة أصبحت متاحةً للحاوية Container4. رؤية التغييرات التي أجريناها في Container5 لنتحقق من أنَّ الحاوية Container5 قد كتبت البيانات على حجم DataVolume4 بإعادة تشغيل الحاوية Container4: docker start -ai Container4 root@db6aaead532b:/# cat /datavolume4/Example4.txt This file is shared between containers Both containers can write to DataVolume4 بعد أن تأكدنا من إمكانية القراءة والكتابة إلى الحجم من كلا الحاويتين، فسنخرج من الحاوية بالأمر exit. أكرِّر أنَّ Docker لا تملك ميزةً لقفل الملفات، لذا يجب أن تقفل التطبيقاتُ الملفاتَ بنفسها. لكن من الممكن وصل حجم Docker للقراءة فقط لكي نضمن عدم حدوث تلف في البيانات نتيجةً لخطأٍ ما، وذلك عبر إضافة الخيار ‎:ro. تشغيل الحاوية Container6 ووصل الحجم للقراءة فقط نستطيع –بعد وصل الحجم إلى الحاوية– أن نفصله ثم نصله مرةً أخرى للقراءة فقط، لكننا نستطيع أيضًا إنشاء حاوية تصل الحجم كما نشاء مباشرةً. وذلك بإضافة ‎:ro بعد اسم الحاوية التي سنحاول وصل الحجم المرتبط بها: docker run -ti --name=Container6 --volumes-from Container4:ro ubuntu سنتحقق من أنَّ الحجم موصولٌ للقراءة فقط بمحاولتنا حذف الملف الذي أنشأناه سابقًا: root@ab63aebe534c:/# rm /datavolume4/Example4.txt rm: cannot remove '/datavolume4/Example4.txt': Read-only file system بعد إغلاق هذه الحاوية (كالمعتاد، بالأمر exit) فيمكننا حذف الحاويات التي أنشأناها إضافةً إلى الحجم: docker rm Container4 Container5 Container6 docker volume rm DataVolume4 لقد رأينا في هذا المثال كيفية مشاركة البيانات بين حاويتين باستخدام الحجوم، بالإضافة إلى طريقة وصل الحجوم للقراءة فقط. الخلاصة أنشأنا في هذا الدرس حجم بيانات الذي يسمح لنا بالاحتفاظ بالبيانات حتى بعد حذفنا للحاوية. وشاركنا حجمًا بين عدِّة حاويات، ونوهنا إلى أهمية أن تكون التطبيقات المستعملة في الحاويات قادرةً على قفل الملفات لمنع تلف البيانات. وفي النهاية شاهدنا كيف يمكن وصل الحجم للقراءة فقط. إذا كنتَ مهتمًا بكيفية مشاركة البيانات بين الحاويات والنظام المضيف، فأنصحك بقراءة درس «كيفية مشاركة البيانات بين حاوية Docker والمضيف». ترجمة -وبتصرّف- للمقال How To Share Data between the Docker Container and the Hostلصاحبته Melissa Anderson

تمهيد عمومًا، نستعمل حاويات Docker لمرة وحيدة فقط، وهي تعمل إلى أن ينتهي تنفيذ الأمر الموكل إليها. وافتراضيًا تكون البيانات المُنشَأة داخل الحاوية متاحةً فقط إلى الحاوية وقابلة للوصول عند تشغيل الحاوية فقط. حجوم Docker (أي Docker volumes) يمكن أن تُستخدَم لمشاركة الملفات بين النظام المضيف (host system) وحاوية Docker. لنقل –على سبيل المثال– أننا نريد استخدام صورة Nginx الرسمية ونحتفظ بسجل دائم لخادوم Nginx لكي نحلل معلوماته لاحقًا. وافتراضيًا، ستكتب صورة Niginx الرسمية سجلاتها إلى ‎/var/log/nginx داخل الحاوية، والتي لا نستطيع في الحالة العادية الوصول إلى ذاك الملف من النظام المضيف. سنشرح في هذا الدرس كيفية جعل البيانات الموجودة داخل الحاوية متاحةً للجهاز المضيف. المتطلبات المسبقة خادوم أوبنتو 16.04 (أو 14.04) مضبوطٌ كما في درس «الإعداد الابتدائي لخادوم أوبنتو 14.04»، بما في ذلك إعداد حساب مستخدم عادي لكنه يملك امتيازات الجذر (root) عبر الأداة sudo. برمجية Docker مثبّتة على حاسوبك إذا كنتَ جديدًا على Docker، فسلسلة «docker ecosystem» المنشورة على الأكاديمية تعطيك لمحةً عن طريقة استعمالها. الخطوة الأولى: الوصل الترابطي لحجم التخزين الأمر الآتي سيُنشِئ مجلدًا باسم nginxlogs في مجلد المنزل (Home) للمستخدم الحالي ويصله وصلًا ترابطيًا (bindmount) إلى ‎/var/log/nginx في الحاوية: docker run --name=nginx -d -v ~/nginxlogs:/var/log/nginx -p 5000:80 nginx لنأخذ دقيقةً من الزمن لتفحص الأمر بالتفصيل: ‎--name=nginx: تسمية الحاوية لكي نستطيع الإشارة إليها لاحقًا بسهولة. ‎-d: فصل العملية الحالية من الطرفية وتشغيلها في الخلفية، وإلا فسنرى مِحَث Nginx فارغ ولن نتمكن من استعمال جلسة الطرفية إلا بعد انتهاء تنفيذ Nginx. ‎-v ~/nginxlogs:/var/log/nginx: ضبط حجم الوصل الترابطي الذي يربِط بين مجلد ‎/var/log/nginx داخل حاوية Nginx إلى مجلد ‎‎~/nginxlogs في الجهاز المضيف. تَستعمِل Docker النقطتين الرأسيتين : لفصل مسار المضيف عن مسار الحاوية، ويجب ذكر مسار المضيف أولًا. ‎-p 5000:80: ضبط تمرير المنافذ؛ حيث تستمع خدمة Nginx داخل الحاوية إلى المنفذ 80 افتراضيًا، وهذا الخيار يؤدي إلى ربط المنفذ 80 في الحاوية إلى المنفذ 5000 في النظام المضيف. nginx: تحديد أنَّ هذه الحاوية يجب بناؤها على صورة Nginx، والتي تُنفِّذ الأمر nginx -g "deamon off"‎ لتشغيل Nginx. ‎-v /path:/path/in/container وصل المسار ‎/path في الجهاز المضيف إلى ‎/path/in/container في الحاوية. ‎-v path:/path/in/container إنشاء حجم باسم path دون علاقة بالمضيف. الخطوة الثانية: الوصول إلى البيانات من المضيف لدينا الآن خادوم Nginx يعمل داخل حاوية موجودة في جهازنا المحلي، ولدينا المنفذ 5000 الموجود في جهاز المضيف مرتبطٌ بالمنفذ 80 للحاوية. افتح عنوان خادوم الويب في متصفحك، مستخدمًا عنوان IP لجهازك المحلي ورقم المنفذ 5000، مثلًا: http://203.0.113.0:5000 ويجب أن تشاهد الرسالة الآتية: وإذا نظرنا الآن في مجلد ‎~/nginxlogs الموجود في المضيف، فسنرى الملف access.log المُنشَأ من حاوية nginx والذي تظهر فيه الطلبية التي أجريناها: cat ~/nginxlogs/access.log يجب أن يحتوي شيئًا شبيهًا بما يلي: 203.0.113.0 - - [11/Nov/2016:00:59:11 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36" "-" إذا أجريتَ أيّة تعديلات إلى مجلد ‎~/nginxlogs فيجب أن تراها من داخل الحاوية مباشرةً. الخلاصة شرحنا في هذا الدرس كيفية إنشاء حجم Docker لمشاركة المعلومات بين الحاوين والنظام المضيف، مما يفيدنا كثيرًا في بيئات التطوير، حيث من الضروري الوصول إلى السجلات لتحليلها. ترجمة -وبتصرّف- للمقال How To Share Data between the Docker Container and the Host لصاحبته Melissa Anderson

تمهيد عندما تُنشِئ حاوية Docker فسيُسنَد إليها مُعرِّف عالمي فريد (UUID) وهو ضروريٌ لتفادي التضاربات في الأسماء ولتسهيل أتمتة إنشاء الحاويات دون تدخل البشر. وهو مفيدٌ لكي يتعرف الحاسوب المضيف (والشبكة) على المضيف. لكن يصعب التفريق بين الحاويات بالنسبة للبشر، سواءً كنّا نقصد الاسم الطويل (64 محرف) أو المُعرِّف القصير (12 محرف) الذي يبدو كالآتي 285c9f0f9d3d. توفِّر Docker أسماءً مولّدةً تلقائيًا للحاويات تأتي من جمع كلمتين عشوائيتين بشرطة سفلية، مثلًا: evil_ptolemy، مما يُسهِّل التفريق بين الحاويات، لكن الأسماء العشوائية لا تعطينا أيّة فكرة عن وظيفة الحاوية مَثَلُهَا كمثل مُعرِّف UUID. سأخبرك بثلاث نصائح التي ستُسهِّل من التعرف على الحاويات. أولًا: سمِّ الحاوية عندما تُنشِئها وذلك بإضافة الخيار ‎--name=meaningful_name إلى الأمر docker run، وبهذا سيصبح اسم الحاوية ذا معنى عند استخدام الجلسات التفاعلية وفي ناتج بعض الأوامر مثل docker ps. لكن هنالك بعض المحدوديات، لأن أسماء الحاويات يجب أن تكون فريدةً، لهذا لا يمكن استخدام نفس الاسم لأكثر من حاوية. ضع ما يلي في سطر الأوامر أو في ملف Docker: docker run –name=meaningful_name على سبيل المثال، إذا أردنا إنشاء حاوية مبنيةً على صورة nginx فسنُنفِّذ الأمر: docker run --name nginx -d nginx وسيظهر الاسم في قائمة الحاويات التي تعمل حاليًا: docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 08f333ef7216 nginx "nginx -g 'daemon off" 15 seconds ago Up 14 seconds 80/tcp, 443/tcp nginx صحيحٌ أنَّ الاسم سيظهر في ناتج الأمر docker ps ويمكن استخدامه لإدارة الحاوية، لكنه لن يظهر في مِحَث (prompt) سطر الأوامر إذا فتحتَه، أو في السجلات. ولفعل ذلك عليك أن تُسنِد «اسم مضيف» (hostname) إلى الحاوية. ثانيًا: إسناد اسم مضيف إلى الحاوية القيمة المُمرَّرة إلى الخيار ‎--hostname ستُضبِط اسم المضيف داخل الحاوية في الملفين ‎/etc/hostname و ‎/etc/hosts. وبناءً على ذلك، سيظهر اسم المضيف في مِحَث سطر الأوامر، وسيلعب اسم المضيف دورًا في ضبط خدمة DNS للحاوية وقد يكون مفيدًا عند تعلم التعامل مع أكثر من حاوية. لكنه ليس ضروريًا للوصول إلى الحاوية من خارجها، إلا أنَّه سيظهر في ملفات السجل التابعة للحاوية، وعندما تُكتَب تلك الملفات إلى جهاز تخزين مستقل عن الحاسوب المضيف، فسيسهل التعرف على الحاوية بناءً على اسم المضيف الخاص بها. ضع ما يلي في سطر الأوامر أو في ملف Docker: docker run –hostname=value أو docker run -h value وصحيحٌ أنَّ ‎--name و ‎--hostname مفيدان للتعرف على الحاويات، لكن الأمر ليس متعلقًا بإطلاق اسم على الحاوية فحسب، وإنما ستستفيد منه (في السجلات مثلًا) إذا ضبطتَ الحاوية لكي تُحذَف تلقائيًا بعد انتهاءك منها. ثالثًا: حذف الحاويات تلقائيًا بعد انتهاء تنفيذها عندما تجرّب مع حاويات Docker، فقد تستفيد في بعض الأحيان من الحفاظ على الحاوية بعد انتهاء تنفيذها. يمكنك حفظ البيانات مثل ملفات السجلات وتتفحص آخر حالة للحاوية. لكن في بعض الأحيان لا ترغب في بقاء الحاوية بعد انتهاء التجربة معها، وفي هذه الحالة يمكنك استخدام الخيار ‎--rm لحذفها عند انتهاء تنفيذها. وهذا سيُسهِّل من «تنظيف» بيئة التجارب. لكن انتبه! إذا كنتَ تستخدم حجوم Docker ‏(Docker volumes) فالخيار ‎--rm سيؤدي إلى حذف أيّة حجوم مرتبطة بالحاوية. ضع ما يلي في سطر الأوامر أو في ملف Docker: docker run –rm ستستفيد من هذا الخيار كثيرًا عند إنشائك لصورة Docker وتحتاج إلى الوصول إلى حاوية للتجربة عليها، لكنك لا تريد أن تملأ كامل قرصك بحاويات لن تستعملها مرةً أخرى. الخلاصة هنالك ثلاثة خيارات للأمر docker run: الخيار ‎--name و ‎--hostname و ‎--rm التي تُسهِّل من تعاملك مع حاويات Docker عندما تحاول تعلم التعامل معها. يمكنك العثور على مزيدٍ من المعلومات حول الأمر docker run في درس «التعامل مع حاويات Docker». ترجمة -وبتصرّف- للمقال Naming Docker Containers: 3 Tips for Beginners لصاحبته Melissa Anderson

Docker هي أداةٌ لإنشاء الحاويات تُستخدَم لتوفير برمجيات مع نظام ملفات الذي يحتوي كل شيءٍ تحتاج له تلك البرمجيات لتعمل. استخدام حاويات Docker يضمن أنَّ البرمجيات ستعمل عملًا صحيحًا بغض النظر عن النظام الذي ستعمل داخله، لأنَّ بيئة التشغيل ستكون متماثلة في جميع الحالات. سنوفِّر في هذا الدرس لمحةً عن العلاقة بين صور Docker (أي Docker images) وحاويات Docker (أي Docker containers). ثم سنتعلم كيفية تشغيل وإيقاف وحذف الحاويات. لمحة عن حاويات Docker يمكننا أن نتخيل «صورة Docker» على أنها قالبٌ (template) يُستخدم لإنشاء حاويات Docker. تبدأ الصور عادةً بنظام ملفات رئيسي، وتُضاف التعديلات على نظام الملفات (والمعاملات المترافقة معها) على شكل طبقات متتالية. وعلى النقيض من توزيعات لينكس الاعتيادية، تحتوي صورة Docker على المكوِّنات الأساسية اللازمة لتشغيل التطبيق (ولا تحتوي على جميع الأدوات الموجودة في التوزيعات التقليدية). ولا تتغير صور Docker، وإنما تكوِّن نقطة انطلاق لإنشاء حاويات Docker. هذا المزيج بين الطبقات المتاحة للقراءة فقط والتي تعلوها طبقةٌ قابلةٌ للكتابة والقراءة يُشكِّل ما يُعرَف بنظام الملفات الاتحادي (union file system). فعند حدوث تغيير إلى ملفٍ موجودٍ في حاوية فسيُنسَخ الملف من الفضاء المتاح للقراءة فقط إلى الطبقة التي يُسمَح فيها بالقراءة والكتابة، ثم ستُطبَّق التغييرات، والنسخة الموجودة في الطبقة المتاحة للقراءة والكتابة تؤدي إلى «إخفاء» الملف الأصلي لكنها لا تحذفه. التغييرات التي تحدث في الطبقة المتاحة للقراءة والكتابة تتواجد في الحاويات المستقلة فقط، وعندما تُحذَف إحدى الحاويات فستضيع جميع التغييرات إلا إن اتخذنا إجراءات لحفظها. التعامل مع الحاويات في كل مرة تستعمل فيها الأمر docker run سيؤدي إلى إنشاء حاوية جديدة من الصورة التي حدَّدتَها. ما سبق قد يُسبِّب بعض الالتباس، لذا لنأخذ بعض الأمثلة للتوضيح. الخطوة الأولى: إنشاء حاويتَين الأمر docker run الآتي سيُنشِئ حاويةً جديدةً تستعمل الصورة ubuntu، ويمنحنا الخيار ‎-t وصولًا إلى الطرفية، والخيار ‎-i يسمح لنا بالتفاعل معها. سنعتمد على الأمر الافتراضي الموجود في ملف Docker لتوزيعة أوبنتو (وهو bash) لكي نحصل على وصولٍ للصدفة (shell): $ docker run -ti ubuntu سيتغير مِحَث سطر الأوامر (prompt) ليُشير إلى أننا نعمل داخل الحاوية بحساب الجذر، متبوعًا بمُعرِّفٍ ذي 12 محرفًا للحاوية، ويبدو المِحث كالآتي: root@11cc47339ee1:/# سنُجري تعديلًا على الحاوية عبر كتابة جملة نصيّة إلى ملفٍ داخل مجلد ‎/tmp، ثم سنستخدم الأمر cat للتأكد من أنَّ الملف قد تعدّل: echo "Example1" > /tmp/Example1.txt cat /tmp/Example1.txt الناتج: Example1 لنخرج الآن من الحاوية بالأمر exit. سيوقف تشغيل حاويات Docker عند انتهاء تنفيذ الأمر الذي بدأت به، لذا ستتوقف حاويتنا عن العمل عند خروجنا من الصدفة bash. ولو نفَّذنا الأمر docker ps الذي يعرض الحاويات التي تعمل حاليًا، فلن نشاهد حاويتنا مذكورةً بينها: docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES أما إذا استعملنا الخيار ‎-a الذي يعرض جميع الحاويات، سواءً كانت متوقفةً أم تعمل حاليًا، فستظهر عندئذٍ حاويتنا في القائمة: docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 11cc47339ee1 ubuntu "/bin/bash" 6 minutes ago Exited (127) 8 seconds ago small_sinoussi عندما أُنشِئَت الحاوية، أُعطيَتْ مُعرَّفًا واسمٍ مولِّدٍ تلقائيًا. وكان مُعرِّف الحاوية في حالتنا هو 11cc47339ee1 والاسم المولَّد تلقائيًا هو small_sinoussi. الخيار ps -a يُظهِر هذه القيمة بالإضافة إلى اسم الصورة التي بُنيَت الحاوية عليها (ubuntu)، ومتى أُنشِئَت الحاوية (‎6 minutes ago)، وما الأمر الذي بدأت الحاوية به (‎/bin/bash). والناتج يعرض أيضًا حالة الحاوية (Exited) ومتى دخلت الحاوية بهذه الحالة (‎8 seconds ago). إذا ما زالت الحاوية تعمل عند تنفيذ الأمر، فستظهر الحالة Up مع بيان مدّة تشغيلها. إذا أعدنا تنفيذ الأمر السابق، فستُنشَأ حاويةٌ جديدة: docker run -ti ubuntu سنعرف أنَّ هذه حاويةٌ جديدة لأنَّ مُعرِّف الحاوية الظاهر في المِحَث مختلف، وإذا حاولنا عرض الملف Example1 فلن نجده: root@6e4341887b69:/# cat /tmp/Example1 الناتج: cat: /tmp/Example1: No such file or directory قد تظن أنَّ الناتج السابق يعني أنَّ البيانات قد اختفت، لكن ذلك ليس صحيحًا. سنخرج الآن من الحاوية الثانية لنتأكد من أنَّ كلا الحاويتين ما زالتا موجودتين في نظام الملفات، ولم تُحذَف الحاوية الأولى التي أنشأنا فيها الملف. docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6e4341887b69 ubuntu "/bin/bash" About a minute ago Exited (1) 6 seconds ago kickass_borg 11cc47339ee1 ubuntu "/bin/bash" 13 minutes ago Exited (127) 6 minutes ago small_sinoussi الخطوة الثانية: إعادة تشغيل الحاوية الأولى لإعادة تشغيل حاوية موجودة مسبقًا، فسنستخدم الأمر start مع الخيار ‎-a و ‎-i، متبوعًا باسم الحاوية أو مُعرِّفها. احرص على أن تضع مُعرِّف الحاوية التي أنشأتها في نظامك في الأمر الآتي: docker start -ai 11cc47339ee1 سنجد أنفسنا داخل صدفة bash مرةً أخرى، وعندما نستخدم الأمر cat على الملف الذي أنشأناه مسبقًا فسنرى أنَّه ما يزال موجودًا: root@11cc47339ee1:/# cat /tmp/Example1.txt Example1 يمكننا الآن أن نخرج من الحاوية بالأمر exit. الناتج السابق يُظهِر أنَّ التعديلات التي أُجرِيَت داخل الحاوية ستبقى حتى لو أوقفناها ثم أعدنا تشغيلها مرةً أخرى. ولن يُحذَف محتواها إلا عند إزالة الحاوية. وهذا المثال يبيّن أنَّ التعديلات ستبقى محصورةً في الحاوية، ولن تؤثر على ما سواها، وعند بدء حاوية أخرى فستأخذ بنية نظام الملفات من الصورة الأصلية. الخطوة الثالثة: حذف كلا الحاويتين لقد أنشأنا في هذا الدرس حاويتين، وسنختمه بتوضيح كيف نحذفهما. يسمح لنا الأمر docker rm –الذي يعمل على الحاويات المتوقفة فقط– بحذف حاوية أو أكثر عبر تحديد اسمها أو مُعرِّفها كما يلي: docker rm 11cc47339ee1 kickass_borg 11cc47339ee1 kickass_borg لقد حُذِفَت الحاويتان مع جميع محتوياتها. الخلاصة لقد ألقينا نظرةً مفصّلةً على الأمر docker run ورأينا كيف يُنشِئ حاويةً جديدةً في كل مرّة يُنفَّذ فيها، ورأينا أيضًا كيفية الحصول على معلومات عن حاوية متوقفة وكيفية تشغيلها والوصول إليها. ترجمة -وبتصرّف- للمقال Working with Docker Containers لصاحبته Melissa Anderson

يُوفِّر 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 لمعرفة معلومات عن علاقات التّبعيّة بين الحاويّات. خلاصةتُمثِّل إدارة العناقيد والجدولة جزأين مهمَّيْن من إعداد وتنفيذ خدمات تعتمد على الحاويّات في بيئة مُوزَّعة مُكوَّنة من عدّة مُستضيفات، إذ تُوفِّران الوظائف الأساسيّة من أجل بدْء تشغيل الخدمات والتّحكّم فيها. يُمكِن عبر استخدام المُجدوِلات بفعاليّة إحداثُ تغييرات كبيرة على عمل التّطبيقات، بالقليل من الجُهد.