‫متطلبات هذه المحاضرة هي أنك شاهدت محاضرات الشبكة السابقة وأنك تفهم المفاهيم الأساسية
‫لشبكات Docker والأوامر المصاحبة لها.
‫حسنا.
‫وهذه المحاضرة ، ستتعلم وتلعب مع DNS وكيف تؤثر على الحاويات في الشبكات المخصصة والشبكات
‫الافتراضية.
‫سننتقل بسرعة إلى
‫مدى أهمية أن يكون لدينا DNS جيد لأنه لا يمكنك الاعتماد على عناوين IP داخل الحاويات لأن
‫الأشياء ديناميكية للغاية. سننظر في الاختلافات بين الشبكات الافتراضية والمخصصة
‫فيما يتعلق بكيفية تعاملهم مع DNS.
‫وبعد ذلك سنتحقق من خيار --link لتشغيل الحاوية لتمكين DNS على شبكة الجسر الافتراضية.
‫لذلك هناك شيء آخر مهم لكل هذه الحاويات والشبكات الافتراضية ويتحدثون
‫مع بعضهم البعض ؛ وهذا هو التسمية. لأنه في عالم الحاويات التي يتم إطلاقها واختفائها
‫باستمرار وتتحرك وتتوسع وتتقلص ، وكل روعة هذه الخدمات الصغيرة التي نشهدها
‫تظهر في كل مكان ، هو أننا لم يعد بإمكاننا الاعتماد بسهولة على عناوين IP كطريقة للتحدث
‫من شيء إلى آخر. لأننا لا نستطيع أن نفترض من دقيقة إلى دقيقة أن
‫عناوين IP ستكون هي نفسها.
‫قد تختفي الحاوية أو قد تفشل ثم يقوم Docker بإحضارها في مكان آخر.
‫إنه ديناميكي للغاية ومعقد للغاية للتعامل مع ذلك.
‫لذلك اتضح أن هناك حلًا مدمجًا لهذا ، وهو تسمية DNS. يستخدم Docker أسماء الحاويات كمكافئ
‫لاسم مضيف للحاويات التي تتحدث مع بعضها البعض.
‫الآن إذا كنت تتذكر أنه كان لدينا فقط حاويتان تعملان ...
‫إذا كنت تتذكر أن Nginx كان على شبكة جديدة تسمى my_app_net.
‫الصحيح.
‫ولها الحاوية الواحدة عليها. نظرًا لأنني أنشأت هذه الشبكة الجديدة
‫، فهذه ليست شبكة الجسر الافتراضية
‫، فهي في الواقع تحصل على ميزة جديدة خاصة ، وهي حل DNS التلقائي لجميع الحاويات على تلك الشبكة الافتراضية من جميع الحاويات
‫الأخرى على تلك الشبكة الافتراضية باستخدام أسماء الحاويات الخاصة بهم.
‫إذا كنت سأقوم بإنشاء حاوية ثانية على تلك الشبكة الافتراضية ، فسيكون بمقدورهم العثور على بعضهم البعض
‫، بغض النظر عن عنوان IP ، بأسماء الحاوية الخاصة بهم.
‫لذلك دعونا نجرب هذا: اسم تشغيل حاوية عامل الإرساء ... وسوف نسميها nginx الخاص بي ... وسنقوم بتحديد الشبكة
‫على أنها شبكة تطبيقي من
‫صورة nginx.
‫الآن ، إذا نظرنا إلى تلك الشبكة ، يجب أن نرى حاويتين ؛ وإذا أجريت تنفيذًا لحاوية عامل إرساء
‫، من الحاوية الجديدة التي أنشأتها للتو - عفوًا ، نحتاج أيضًا إلى تكنولوجيا
‫المعلومات الموجودة هناك - ونقوم بإجراء اختبار ping على nginx
‫الجديد ، ستلاحظ أن حل DNS يعمل فقط. هذا يجعل من السهل جدًا أن يكون لديك حاوية واحدة
‫وتحتاج إلى تعيين ملف تكوين فيها للتحدث إليه ، ربما لنفترض أن خادم PHP سيتحدث
‫إلى الواجهة الخلفية لـ MySQL. Ctrl-c خارج ذلك ، وسترى أنه يعمل بطريقة أخرى أيضًا.
‫إذا قفزت إلى حاوية nginx الجديدة وحاولت تنفيذ الأمر ping على ngnix ، فسترى أن الحل يعمل في كلا الاتجاهين.
‫وهذا هو ما يحل مشكلة كبيرة عندما تقوم بتدوير الحاويات لأنك لا تستطيع التنبؤ
‫بالمدة التي ستستمر فيها وأين قد تكون دقيقة من الآن في تصميم إنتاج حيث
‫لديك مجموعة من خوادم Docker Swarm.
‫لذلك قد لا يتغير كثيرًا على جهازك المحلي ، ولكن إذا أوقفت 3 أو 4 حاويات
‫، ثم بدأت نفس الحاويات ، وقمت بتشغيلها بترتيب مختلف
‫، فقد لا يكون لها نفس عنوان IP. لكن أسماء مضيفهم ، أو أسماء حاوياتهم ، ستظل دائمًا
‫هي نفسها.
‫وهكذا يمكنك الاعتماد عليها.
‫الآن يجب أن أشير ، إذا قمنا بعمل قائمة شبكة عامل ميناء ، فإن شبكة الجسر الافتراضية لها عيب واحد هنا.
‫لا يحتوي على خادم DNS مضمن فيه افتراضيًا.
‫لذا يمكنك استخدام الرابط --link.
‫لذلك عند إنشاء حاوية ، ستلاحظ وجود خيار ارتباط ويمكنك في الواقع تحديد روابط يدوية بين
‫الحاويات في شبكة الجسر الافتراضية هذه.
‫ولكن في الحقيقة ، من الأسهل بكثير إنشاء شبكة جديدة لتطبيقاتك حتى لا تضطر إلى القيام
‫بذلك في كل مرة.
‫وفي قسم مستقبلي ، عندما نتحدث عن Docker Compose ، سترى كيف يصبح الكثير من هذا أسهل
‫لأن الإنشاء تلقائيًا سينشئ شبكات افتراضية جديدة كلما قمت بتدوير تطبيق باستخدامه.
‫لذلك يصبح التواصل بين الحاويات الخاصة بك أسهل.
‫كخلاصة سريعة ، تناولنا في هذه المحاضرة كيف لا تستطيع الحاويات حقًا ، أو لا ينبغي حقًا ، الاعتماد على
‫عناوين IP للتحدث مع بعضها البعض لأنه لا يمكن الاعتماد عليها.
‫وهذا DNS هو حقًا المعيار هنا لكيفية قيامنا بالاتصال بين الحاويات
‫على نفس المضيف وعبر المضيفين.
‫ولذا أوصيك دائمًا بإنشاء شبكات مخصصة لأنه بهذه الطريقة أسهل من
‫إنشاء رابط طوال الوقت.
‫وبعد ذلك أعطيتك دعابة حول Docker Compose وكيف ستجعل كل هذا أسهل
‫، خاصة الشبكات.