Докерский контейнер nginx на aws ecs >> Простой HTTP-запрос был отправлен на порт HTTPS - PullRequest
Новая
       122

Докерский контейнер nginx на aws ecs >> Простой HTTP-запрос был отправлен на порт HTTPS

1 голос
/ 28 октября 2019

У меня есть внешнее угловое приложение, работающее на экземпляре aws ecs ec2, и оба подключены к TCP-порту 443 и 80 устройства балансировки сетевой нагрузки. У меня будет много vhost, настроенных на этом контейнере Dogin nginx с несколькими доменными именами. В сервисе ecs баланс контейнера для нагрузки задается как порт 443. Для балансировки нагрузки нам нужно будет выбрать порт 443 или 80 контейнера. https://prnt.sc/pocu41. На https сайт загружается нормально. Но на http я получаю сообщение об ошибке 

The plain HTTP request was sent to HTTPS port

Я планирую использовать сертификат ssl в контейнере Docker, а не ssl в балансировщике нагрузки. Если я выберу ssl в балансировщике нагрузки, тогда нам нужно использовать многодоменный ssl в сертификате балансировщика нагрузки приложения по умолчанию, что может оказаться невозможным при сотнях доменов.

Мой конфиг Nginx выглядит следующим образом 

server {
        listen 80;
        server_name  example.com;

        root   /usr/share/nginx/html/docroot;
        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;
        }
    }


server {
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl on;
    ssl_certificate /etc/nginx/ssl/example.com/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com/example.com.key;

    server_name  example.com;
    root           /usr/share/nginx/html/docroot;
    index          index.html;
    location / {
                try_files $uri $uri/ =404;
        }

}

Есть идеи, как мы можем решить этот сценарий?

1 Ответ

0 голосов
/ 28 октября 2019

Я планирую использовать сертификат ssl в док-контейнере, а не ssl в балансировщике нагрузки. Если я выберу ssl на балансировщике нагрузки, тогда нам нужно использовать многодоменный ssl в сертификате балансировщика нагрузки приложения по умолчанию, и это может оказаться невозможным при сотнях доменов.

Ваше это предположение не кажется правильным,вы можете создать * сертификат из LB или настроить несколько из ACM, а также . Вы можете использовать AWS ACM с балансировщиком нагрузки и его бесплатно , и почему я должен беспокоиться об управлении SSL на уровне приложений? и почему я должен открыть порт 80 на уровне приложения, когда я могу сделать перенаправление с приложением LB, если NLB не является требованием?

Оценка менеджера сертификатов AWS

PublicСертификаты SSL / TLS, предоставляемые через AWS Certificate Manager, бесплатны. Вы платите только за ресурсы AWS, созданные для запуска приложения.

Цены менеджера сертификатов

Во-вторых, любая особая причина использования NLB? Для веб-приложения я никогда не пойду на балансировщик сети, NLB имеет смысл для связи на уровне TCP, но я пойду на приложение LB для связи HTTP, которое обеспечивает расширенные маршрутизации, такие как маршрутизация на базе хоста, перенаправление имаршрутизация на основе пути , которая устранит необходимость в Nginx.

Контейнеры предназначены для облегченной задачи, и AWS рекомендует использовать объем памяти около 300-500 МБ и те же рекомендации для ЦП.

Знаете ли вы стоимость SSL-терминации на уровне контейнера?

Трафик SSL может быть интенсивно вычислять , поскольку он требует шифрования и дешифрования трафика,SSL использует криптографию с открытым ключом для шифрования обмена данными между клиентом и сервером, безопасно отправляя сообщения по сетям.

Преимущество терминации SSL на уровне LB

Прекращение SSL на балансировщике нагрузкижелательно, потому что дешифрование требует значительных ресурсов и ресурсов процессора. Наложение бремени дешифрования на балансировщик нагрузки позволяет серверу тратить вычислительную мощность на задачи приложения , что помогает повысить производительность. Это также упрощает управление сертификатами SSL.

new-tls-termination-for-network-load-балансировщиков

ssl-termination

enter image description here

10 советов по улучшению производительности вашего приложения AWS

Итак, основываясь на этом, я не собираюсь отвечать на вашу проблему, как предлагает @Linpy, может помочь, если вы все еще хотите пойти, вы тоже можете это сделать имеем дело с-nginx-400-the-plain-http-request-был посланный к HTTPS-порт-ошибки

...