Amazon ECS (Docker): прив'язує контейнер до конкретної IP-адреси

Я граю з Amazon ECS (перепаковка Docker) і виявляю, що є одна можливість Docker, яка, схоже, не забезпечує ECS. А саме, я хотів би мати кілька контейнерів, що працюють в екземплярі, і мати запити, що надходять на IP-адресу 1, карта в контейнер 1, і запити, що надходять на IP-адресу 2, карту в контейнер 2 і т.д.

У Docker прив'язка контейнера до певної IP-адреси здійснюється за допомогою:

docker run -p myHostIPAddr:80:8080 imageName command

Однак в Amazon ECS, здається, немає способу зробити це.

Я створив екземпляр EC2 з декількома Elastic IP-адресами. Конфігуруючи контейнер як частину визначення завдання, можна зіставити хости-порти на порти контейнерів. Однак, на відміну від Докера, ECS не забезпечує спосіб вказати IP-адресу хоста як частину відображення.

Додатковим поворотом є те, що я хотів би вихідні запити з контейнера N мати зовнішню IP-адресу контейнера N.

Чи є спосіб зробити все вищезазначене?

Я ознайомився з документацією AWS CLI, а також AWS SDK для Java. Я бачу, що CLI може повернути мережевий масив, що містить такі елементи:

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

і Java SDK має клас під назвою NetworkBinding, який представляє ту саму інформацію. Однак ця інформація видається лише вихідною у відповідь на запит. Я не можу знайти спосіб надання цієї обов'язкової інформації ECS.

Причиною того, що я хочу це зробити, є те, що я хочу створити абсолютно різні VM для різних округів, використовуючи різні контейнери потенційно на одному екземплярі EC2. Кожен VM матиме власний веб-сервер (включаючи окремі сертифікати SSL), а також власну службу FTP та SSH.

Спасибі.

Один варіант: Створіть ELB для кожного клієнта, а потім призначте певні контейнери кожному ELB.

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

Ось фактичний логічний спосіб це зробити. Це звучить занадто складно, але реально реалізувати його можна за лічені хвилини, і це працює. Я насправді реалізую це, як ми говоримо.

Ви створюєте завдання для кожного контейнера і створюєте службу для кожного завдання разом із цільовою групою для кожної служби. І тоді ви створюєте лише 1 еластичний балансир навантаження.

Еластичні балансири навантаження на основі додатків можуть направляти запити на основі запитуваного шляху. Використовуючи цільові групи, ви можете маршрутизувати запити, що надходять 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 цей метод працює чудово.

Ви не можете самій контейнер, але ви можете зробити екземпляр EC2, присвячений конкретному контейнеру. Потім, де вам потрібно отримати доступ до цієї послуги, ви можете посилатися на хост EC2, який працює з контейнером.

• Створіть спеціальний кластер для своїх послуг із цією вимогою
• Створіть EC2-оптимізований екземпляр EC2, використовуючи бажаний тип екземпляра
  • Обов’язково призначте цей екземпляр вищевказаному кластеру за допомогою параметра UserData, як описано в цьому посібнику.
• Створіть визначення завдання з NetworkMode, встановленого на "міст" (те саме, що і на робочому столі)
• Створіть визначення служби за допомогою:
  • Тип запуску встановлено на EC2
  • Кластер встановлений для кластера, який ви створили вище
  • Визначення завдання встановлено для визначеного вище завдання
• Призначте будь-які групи безпеки до екземпляра EC2 так, як інакше.

Хоча ви все ще спілкуєтесь безпосередньо з екземпляром EC2, ви можете керувати IP контейнера (опосередковано), як і екземпляр EC2. Це економить головний біль від запуску сервісів на «голому металі», що дозволяє вам легше керувати та налаштовувати сервіс та конфігурацію в ньому.