‫لذلك القليل من السحر لم يكن سحرًا في الواقع. كانت شبكة التوجيه. شبكة التوجيه هي شبكة واردة
‫أو دخول تقوم بتوزيع الحزم لخدمتنا على مهام تلك الخدمة ، لأنه يمكن أن يكون لدينا
‫أكثر من مهمة واحدة.
‫هذا في الواقع يمتد على جميع العقد ، ويستخدم بدائل Kernel التي كانت موجودة منذ فترة
‫تسمى بالفعل IPVS.
‫لذلك نحن لا نتحدث عن بعض الخدمات الجديدة الفاخرة. نحن نتحدث فقط عن الميزات
‫الأساسية لـ Linux Kernel. ما يفعله هنا حقًا هو موازنة التحميل عبر جميع
‫العقد والاستماع إلى جميع العقد لحركة المرور.
‫هناك طريقتان يمكننا التحدث عن كيفية عمل ذلك.
‫المثال الأول من حاوية إلى أخرى.
‫إذا تمت زيادة نظام الواجهة الخلفية لدينا ، مثل قواعد البيانات ، إلى نسختين متماثلتين ، فإن الواجهات الأمامية التي تتحدث
‫إلى الخلفية ، لن تتحدث
‫في الواقع مباشرة إلى عنوان IP الخاص بها.
‫سيتحدثون بالفعل إلى شيء يسمى VIP ، أو IP افتراضيًا ، يضعه Swarm أمام جميع
‫الخدمات.
‫هذا عنوان IP خاص داخل الشبكة الافتراضية لـ Swarm ، ويضمن توزيع الحمل بين
‫جميع مهام الخدمة.
‫لذلك إذا كان بإمكانك أن تتخيل ما إذا كان لديك دور عامل في تطبيقك ، وكان يحتوي على 10 حاويات مختلفة ، فلن تضطر إلى
‫وضع موازن تحميل أمام ذلك.
‫هذا يفعل ذلك من أجلك.
‫عندما تتحدث عن حركة المرور من خدمة واحدة داخل شبكتك الافتراضية ، تتحدث إلى خدمة أخرى داخل
‫شبكتك الافتراضية.
‫والمثال الثاني لكيفية عمل شبكة التوجيه هو أن حركة المرور الخارجية القادمة إلى سربك
‫يمكنها في الواقع أن تختار ضرب أي من العقد في سربك.
‫ستفتح أي من العقد العاملة هذا المنفذ المنشور وتستمع لحركة مرور تلك الحاوية ، وبعد ذلك ستعيد توجيه
‫حركة المرور هذه إلى الحاوية المناسبة بناءً على موازنة التحميل الخاصة بها.
‫ما يعنيه هذا هو أنه عندما تنشر حاويات في سرب ، ليس من المفترض أن تهتم بالخادم
‫الموجود عليه لأنه قد يتحرك ، أليس كذلك؟
‫إذا فشلت إحدى الحاويات ، وتم إعادة إنشاء المهمة بواسطة السرب ، فقد يضع ذلك على عقدة مختلفة. وأنت بالتأكيد لا تريد أن تضطر إلى تغيير
‫جدار الحماية الخاص بك أو إعدادات DNS الخاصة بك لجعل هذه الحاوية تعمل
‫مرة أخرى.
‫تحل شبكة التوجيه الكثير من هذه المشكلات من خلال السماح بالوصول إلى موقع ويب Drupal الخاص
‫بنا على المنفذ 80 من أي عقدة في السرب. وفي الخلفية ، يتم أخذ تلك الحزم من ذلك الخادم
‫ثم توجيهها إلى الحاوية. إذا كانت على عقدة مختلفة ، فسيتم توجيهها عبر الشبكات
‫الافتراضية.
‫إذا كانت على نفس العقدة ، فستقوم فقط بإعادة توجيهها إلى منفذ تلك الحاوية.
‫ولم يكن علينا فعل أي شيء لتمكين ذلك.
‫كان هذا كله خارج الصندوق.
‫دعنا نرى رسمًا تخطيطيًا لكيفية عمل ذلك.
‫إذا قمت بإنشاء خدمة نموذج أخبار ، وقلت لها أن تحتوي على ثلاث نسخ متماثلة. وأنشأت ثلاث مهام ، بثلاث
‫حاويات ، على ثلاث عقد. داخل شبكة التراكب هذه ، تقوم بالفعل بإنشاء عنوان IP افتراضي
‫تم تعيينه لاسم DNS للخدمة ، أليس كذلك؟ والخدمة ، افتراضيًا ، اسم DNS ، هو اسم الخدمة.
‫في هذه الحالة ، قمت بإنشاء خدمة تسمى my-web ، وأي حاويات أخرى لدي في شبكات التراكب الخاصة بي والتي
‫تحتاج إلى التحدث إلى تلك الخدمة داخل السرب ، عليهم فقط القلق
‫بشأن استخدام DNS على الويب الخاص بي. يؤدي تحميل IP الظاهري بشكل صحيح إلى ارتداد
‫حركة المرور بين جميع المهام في تلك الخدمة.
‫هذا ليس في الواقع جولة DNS Robin. هذا في الواقع تكوين مختلف قليلاً. يمكننا تمكين ذلك
‫إذا أردنا ذلك. هناك بالفعل خيار لاستخدام DNS Round Robin.
‫تتمثل مزايا VIPs over Round Robin في أن مخازن DNS المؤقتة الخاصة بنا داخل تطبيقاتنا تمنعنا في كثير من الأحيان
‫من توزيع الحمل بشكل صحيح.
‫بدلاً من القتال مع عملاء DNS الخاصين بنا في تكوين DNS ، فإننا نعتمد فقط على VIP ، وهو
‫نوع يشبه ما كنت ستحصل عليه إذا اشتريت موازن تحميل أجهزة مخصص.
‫في المثال الثاني ، يوضح هذا في الواقع كيف سيكون الأمر مع وصول حركة المرور الخارجية.
‫هذا مشابه لما فعلناه للتو مع دروبال ، حيث عندما أنشأت تلك المربعات الصفراء ، من خلال إنشاء
‫خدمة واحدة ، تسمى الويب الخاص بي ، وأنشأت مهمتين ، وطبقتهما على عقدتين مختلفتين ، كل واحدة من هذه العقد لديها بنية
‫مدمجة -في موازن التحميل على عنوان IP الخارجي. بالنسبة لي ، لأنني أستخدم DigitalOcean ، فإن عنوان
‫IP هذا هو العنوان الذي أعطته لي DigitalOcean. عندما أستخدم -p ونشرته على منفذ ، في هذا المثال
‫يستخدم المنفذ 80:80 ، فإن أي حركة مرور تأتي إلى أي من هذه العقد الثلاثة تصل إلى
‫موازن التحميل على المنفذ 80:80. يقرر موازن التحميل الحاوية التي يجب أن تحصل على حركة المرور وما إذا
‫كانت حركة المرور هذه على العقدة المحلية أم لا ، أو يحتاج إلى إرسال حركة المرور
‫عبر الشبكة إلى عقدة مختلفة.
‫مرة أخرى ، يحدث كل هذا في الواقع في الخلفية دون بذل أي جهد خاص من جانبنا.
‫حسنا. دعونا نرى شبكة التوجيه هذه في العمل.
‫لقد رأينا بالفعل مثال دروبال وكيف يستمع إلى العقد الثلاثة.
‫ولكن ماذا لو كان لدينا مهام متعددة ترى أن موازن التحميل يعمل.
‫إذا قمنا بإنشاء خدمة عامل إرساء
‫، فإن ما سنفعله هو ، سنستخدم حاوية Elasticsearch. سنسميها بحث ونعطيها ثلاث
‫نسخ متماثلة. وتريد نشرها على المنفذ 9200 وهو المنفذ الافتراضي لها.
‫في هذه الحالة ، نريد بالتأكيد وجود: 2 لأنه أسهل إصدار
‫يتم نشره الآن. أثناء الإنشاء ، سأذكر فقط
‫أن Elasticsearch هي في الواقع قاعدة بيانات بحث يمكن الوصول إليها عبر واجهة برمجة تطبيقات الويب JSON.
‫لذلك من السهل حقًا التعامل مع curl وإعطائنا أمثلة جيدة عن كيفية عمل ذلك.
‫أقوم بإجراء بحث ps في خدمة docker ، يمكننا أن نرى أنه تم إنشاء كل مهمة بذكاء على عقدة مختلفة.
‫إذا قمت بإجراء تجعيد على مضيفي المحلي ، على العقدة الأولى على المنفذ 9200 لأنني قمت بنشر هذا المنفذ ، فسأستعيد
‫معلومات Elasticsearch الأساسية. جزء من ذلك هو أنه سيتم إنشاء اسم عشوائي.
‫هذه مجرد ميزة من Elasticsearch.
‫إذا قمت بتجعيد هذا عدة مرات ، فسترى في هذا التصحيح ، خادم التصحيح ، ثم مرة
‫ثالثة ، جين
‫فوستر ، وبعد ذلك سيبدأ في تكرار نفسه على هذا النحو.
‫هذا في الواقع عنوان IP الافتراضي يعمل كموازن تحميل ويوزع حملي عبر المهام
‫الثلاث.
‫بضع ملاحظات أخرى حول شبكة التوجيه. في 17. 03 ، وهو الإصدار الذي أعرضه لك على هذا ، شبكة
‫التوجيه وموازنة الحمل هما حاليًا موازن تحميل عديم الحالة.
‫إذا سبق لك التعامل مع الحالة داخل موازن التحميل الكلاسيكي من Amazon ، أو تقنيات موازن التحميل الأخرى ، فأنت
‫تعرف ما يدور حوله هذا الأمر.
‫هذا يعني بشكل أساسي أنه إذا كان عليك استخدام ملفات تعريف الارتباط للجلسة على تطبيقك ، أو تتوقع حاوية
‫متسقة للتحدث مع عميل ثابت ، فقد تحتاج إلى إضافة بعض الأشياء الأخرى للمساعدة في حل هذه
‫المشكلة.
‫من خارج الصندوق ، في كل مرة تصل فيها إلى خدمة ذات مهام متعددة ، ستمنحك نتيجة مختلفة
‫على الأرجح.
‫أيضًا ، إذا دخلت في تفاصيل هذا ، فهو في الواقع موازن تحميل للطبقة 3 ، ويعمل
‫بالفعل على طبقة IP والمنفذ.
‫إنه لا يعمل بالفعل في طبقة DNS.
‫إذا سبق لك تشغيل مواقع ويب متعددة على نفس المنفذ ، على نفس الخادم ، فلن يؤدي ذلك إلى القيام بذلك حتى
‫الآن.
‫ما زلت بحاجة إلى قطعة أخرى من اللغز فوق ذلك إذا
‫كنت تريد بالفعل تشغيل مواقع ويب متعددة على نفس المنفذ ، على نفس السرب.
‫لحسن الحظ ، هذا طلب شائع جدًا ، وهناك العديد من الخيارات التي يمكنك القيام بها لحل هاتين
‫المشكلتين.
‫أحدهما هو استخدام Nginx أو HAProxy ، والتي توجد أمثلة جيدة جدًا على الحاويات التي ستجلس أمام شبكة التوجيه الخاصة
‫بك ، وتعمل في الواقع كموازن تحميل ذي حالة أو طبقة لموازنة التحميل ، والتي يمكنها أيضًا القيام بالتخزين المؤقت
‫والكثير من الأشياء الأخرى. إذا كنت بحاجة إلى ذلك ، فقد ترغب في التحقق
‫من بعض هؤلاء الموجودين في موارد هذا القسم.
‫يجب أن أذكر أيضًا أنه إذا كنت ستدفع مقابل اشتراك في إصدار Docker Enterprise ، فإنه يأتي بشيء
‫يسمى UCP أو Docker Data Center ، وهو واجهة ويب. لكن يجب أن أذكر أن إصدار Docker Enterprise
‫، إذا حصلت على اشتراك في ذلك لعقد السرب الخاصة بك ، فإنه يأتي بالفعل مع
‫طبقة مدمجة لوكيل الويب الذي يسمح لك فقط برمي أسماء DNS في تكوين الويب لخدمات السرب الخاصة
‫بك و كل شيء يعمل فقط.