Service Discovery не работает с Route 53 и контейнером ECS Nginx. Хостинг Angular code

У меня есть статические страницы пользовательского интерфейса, выполняющие вызовы API REST для других контейнеров ECS-Fargate. Статические страницы снова размещаются в контейнере с Nginx. Вызовы api не разрешаются службой DNS маршрута 53. Если я разверну экземпляр EC2 и использую nslookup, значит, преобразование адресов происходит правильно.

Все контейнеры находятся в одной подсети, и только контейнер Nginx-Angular имеет общедоступный IP-адрес. Я хочу получить доступ к контейнеру Nginx-Angular через Интернет, который будет выполнять вызовы api для других контейнеров ECS Fargate. Пожалуйста, порекомендуйте.

nginx.conf

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    server {
       #listen 80;
       server_name  localhost;
       ssl_certificate /etc/nginx/ssl/nginx.crt;
       ssl_certificate_key /etc/nginx/ssl/nginx.key;

       listen 443 ssl;
       root /usr/share/nginx/html/login-ui;
       index  index.html index.htm;
       include /etc/nginx/mime.types;

       gzip on;
       gzip_min_length 1000;
       gzip_proxied expired no-cache no-store private auth;
       gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

       location / {
           try_files $uri $uri/ /index.html;
       }
}

docker nginx amazon-route53 amazon-ecs aws-fargate
person Sushrut Kanetkar    schedule 04.06.2019    source источник
comment
... REST api вызывает другие контейнеры ECS-Fargate ... Чтобы уточнить, ваше приложение пользовательского интерфейса находится в контейнере ECS Fargate, да? ... Все контейнеры находятся в одной подсети, и только контейнер Nginx-Angular имеет публичный IP-адрес ... IIRC, если подсеть является публично маршрутизируемой, это «публичная подсеть»; означает, что любая служба в подсети может иметь общедоступный IP-адрес. Попробуйте назначить общедоступный IP-адрес службе REST API и указать приложению пользовательского интерфейса общедоступный IP-адрес. Просто чтобы посмотреть, работает ли это.   -  person David J Eddy    schedule 04.06.2019
comment
Да вы правильно поняли вопрос. Все работает, когда я назначаю общедоступный IP-адрес службе REST API и указываю приложению пользовательского интерфейса общедоступный IP-адрес. Есть ли способ, чтобы я мог открывать только контейнер пользовательского интерфейса в Интернете, а остальные контейнеры оставались частными? Контейнеры без общедоступного IP-адреса общаются с использованием DNS-имени, предоставленного Route 53 в настоящее время. Спасибо !   -  person Sushrut Kanetkar    schedule 05.06.2019
comment
Обычно, если вы хотите, чтобы одна служба была частной, а одна общедоступной, вам нужны две подсети (они могут находиться в одной зоне доступности). Одна общедоступная подсеть для сервисов, доступных за пределами VPC; и одна частная подсеть для сервисов, доступных только из VPC. Настройте экземпляры ECS для связи друг с другом через частный IP-адрес, назначенный каждому экземпляру, и вы должны получить нужную функциональность.   -  person David J Eddy    schedule 05.06.2019
comment
Спасибо за помощь. Я считаю, что ecs не дает полного контроля над экземпляром ec2. Значит, частный IP-адрес изменится, когда мы увеличим масштаб, верно? Как маршрутизировать внутренние запросы на частный IP. Любая помощь или ссылка на частную IP-связь в ECS были бы очень полезны. Спасибо !   -  person Sushrut Kanetkar    schedule 17.06.2019
comment
Маршрутизация контейнерного трафика - это хорошо изученная проблемная область. Один из известных мне проектов - github.com/containous/traefik. Вы также можете использовать AWS App Mesh или группы Auto Scale с балансировщиками нагрузки.   -  person David J Eddy    schedule 18.06.2019

Ответы (1)


arrow_upward
2
arrow_downward

Я решил проблему, сохранив контейнер angular & nginx в частной подсети. Я настраиваю балансировщик нагрузки приложений с общедоступным IP-адресом в общедоступной подсети. Я маршрутизирую весь трафик из Интернета с помощью механизма обратного прокси-сервера Nginx, и запросы обрабатываются Nginx и перенаправляются в мои контейнеры API с использованием внутреннего DNS Route53. Браузер должен отправлять все запросы только в расположение Nginx, и он должен решить, куда направить тему частной интрасети, используя внутренний DNS Route53. authenticationservice.local - это моя запись DNS. Вот мой nginx.conf.

worker_processes  1;

events {
    worker_connections  1024;
}

http {
server {
    server_name  localhost;
    resolver 127.0.0.1;
    ssl_certificate /etc/nginx/ssl/nginx.crt;
    ssl_certificate_key /etc/nginx/ssl/nginx.key;

    listen 443 ssl;
    root /usr/share/nginx/html/login-ui;
    index  index.html index.htm;
    include /etc/nginx/mime.types;

    gzip on;
    gzip_min_length 1000;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    location / {
        try_files $uri $uri/ /index.html;
    }


    location /test/api/ {
            rewrite /test/api/login/ break;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header Host $host;
            proxy_redirect   off;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass https://authenticationservice.local:8443/api/login;
    }
  }
}
person Sushrut Kanetkar    schedule 27.06.2019