أنا ألعب مع Amazon ECS (إعادة تجميع لـ Docker) وأجد أن هناك قدرة Docker واحدة لا يبدو أن ECS توفرها. على وجه التحديد ، أود أن يكون لدي عدة حاويات تعمل في مثيل ، ولدي طلبات قادمة إلى عنوان IP 1 خريطة للحاوية 1 ، والطلبات القادمة إلى عنوان IP 2 لتعيين الحاوية 2 ، إلخ.

في Docker ، يتم ربط حاوية بعنوان IP محدد عبر:

docker run -p myHostIPAddr:80:8080 imageName command

ومع ذلك ، في Amazon ECS ، لا يبدو أن هناك طريقة للقيام بذلك.

لقد قمت بإعداد مثيل EC2 مع عدة عناوين IP مرنة. عند تكوين حاوية كجزء من تعريف المهمة ، من الممكن تعيين منافذ المضيف لمنافذ الحاوية. ومع ذلك ، على عكس Docker ، لا توفر ECS طريقة لتحديد عنوان IP للمضيف كجزء من التعيين.

هناك تطور إضافي وهو أنني أرغب في أن يكون للطلبات الصادرة من الحاوية N عنوان IP الخارجي للحاوية N.

هل هناك طريقة لفعل كل ما سبق؟

لقد بحثت في وثائق AWS CLI ، وكذلك AWS SDK لـ Java. أستطيع أن أرى أن CLI يمكنه إرجاع مصفوفة ربط شبكية تحتوي على عناصر مثل هذا:

{
  "bindIP": "0.0.0.0", 
  "containerPort": 8021, 
  "hostPort": 8021
},

وتحتوي Java SDK على فئة تسمى NetworkBinding تمثل نفس المعلومات. ومع ذلك ، يبدو أن هذه المعلومات هي للمخرجات فقط ، استجابة لطلب. لا يمكنني العثور على طريقة لتقديم هذه المعلومات الملزمة إلى ECS.

السبب وراء رغبتي في القيام بذلك هو أنني أرغب في إعداد أجهزة افتراضية مختلفة تمامًا لدوائر انتخابية مختلفة ، باستخدام حاويات مختلفة يحتمل أن تكون على نفس مثيل EC2. سيكون لكل جهاز افتراضي خادم ويب خاص به (بما في ذلك شهادات SSL المميزة) ، بالإضافة إلى خدمة FTP و SSH الخاصة به.

شكرا.

answer

هذه طريقة منطقية فعلية للقيام بذلك. يبدو الأمر معقدًا للغاية ولكن يمكنك تنفيذه فعليًا في غضون دقائق ، وهو يعمل. أنا في الواقع أنفذها ونحن نتحدث.

تقوم بإنشاء مهمة لكل حاوية ، وتقوم بإنشاء خدمة لكل مهمة ، إلى جانب مجموعة مستهدفة لكل خدمة. وبعد ذلك تقوم بإنشاء 1 Elastic Load Balancer.

يمكن لموازنات التحميل المرنة المستندة إلى التطبيق توجيه الطلبات بناءً على المسار المطلوب. باستخدام المجموعات المستهدفة ، يمكنك توجيه الطلبات القادمة elb-domain.com/1إلى الحاوية 1 ، elb-domain.com/2إلى الحاوية 2 ، إلخ.

الآن أنت على بعد خطوة واحدة فقط. قم بإنشاء خادم وكيل عكسي.

في حالتي ، نحن نستخدم nginx ، لذا يمكنك إنشاء خادم nginx بأكبر عدد تريده من عناوين IP ، وباستخدام قدرة الوكيل العكسي لـ nginx ، يمكنك توجيه عناوين IP الخاصة بك إلى مسارات ELB الخاصة بك ، والتي توجّهها وفقًا لذلك إلى الحاوية الصحيحة (س). فيما يلي مثال إذا كنت تستخدم المجالات.

server {
    server_name domain1.com;
    listen 80;
    access_log /var/log/nginx/access.log vhost;
    location / {
        proxy_pass http://elb-domain.com/1;
    }
}

بالطبع ، إذا كنت تستمع بالفعل إلى عناوين IP ، فيمكنك حذف server_nameالسطر والاستماع فقط إلى الواجهات المقابلة.

هذا في الواقع أفضل من تعيين عنوان IP ثابت لكل حاوية لأنه يتيح لك الحصول على مجموعات من أجهزة عامل الإرساء حيث تتم موازنة الطلبات عبر تلك المجموعة لكل من "عناوين IP" الخاصة بك. لا تؤثر إعادة إنشاء جهاز على عنوان IP الثابت ولا يتعين عليك إعادة الكثير من التهيئة.

على الرغم من أن هذا لا يجيب تمامًا على سؤالك لأنه لن يسمح لك باستخدام FTP و SSH ، إلا أنني أزعم أنه لا يجب عليك استخدام Docker مطلقًا للقيام بذلك ، ويجب عليك استخدام الخوادم السحابية بدلاً من ذلك. إذا كنت تستخدم Docker ، فبدلاً من تحديث الخادم باستخدام FTP أو SSH ، يجب عليك تحديث الحاوية نفسها. ومع ذلك ، بالنسبة إلى HTTP و HTTPS ، تعمل هذه الطريقة بشكل مثالي.

خيار واحد: قم بإنشاء ELB لكل عميل ، ثم قم بتعيين حاويات معينة لكل ELB.

[1] http://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html

لا يمكنك استخدام الحاوية نفسها ، ولكن يمكنك إنشاء مثيل EC2 مخصص لحاوية معينة. بعد ذلك ، عندما تحتاج إلى الوصول إلى هذه الخدمة ، يمكنك الرجوع إلى مضيف EC2 الذي يقوم بتشغيل الحاوية.

  • قم بإنشاء مجموعة مخصصة لخدماتك مع هذا المطلب
  • قم بإنشاء مثيل EC2 مُحسَّن من AMI باستخدام نوع المثيل المفضل لديك
    • تأكد من تعيين هذا المثيل إلى المجموعة أعلاه باستخدام خيار UserData كما هو موضح في هذا الدليل.
  • إنشاء TaskDefinition مع NetworkMode مضبوطًا على "جسر" (مثل سطح المكتب الخاص بك)
  • أنشئ تعريف خدمة باستخدام:
    • تم تعيين LaunchType على EC2
    • تم تعيين الكتلة على الكتلة التي أنشأتها أعلاه
    • تم تعيين تعريف المهمة على تعريف المهمة الذي قمت بإنشائه أعلاه
  • قم بتعيين أي مجموعات أمان لمثيل EC2 كما تفعل بخلاف ذلك.

على الرغم من أنك لا تزال تتحدث مباشرة إلى مثيل EC2 ، يمكنك التحكم في IP للحاوية (بشكل غير مباشر) كما تفعل مع مثيل EC2. هذا يوفر عليك عناء تشغيل الخدمات على "bare metal" مما يتيح لك سهولة إدارة وتهيئة الخدمة والتكوين فيها.