Настройка HTTPS с Amazon AWS для чайников
Я запускаю настройку Amazon AWS для размещаемой мной веб-страницы. Он использует один экземпляр EC2 и отлично работает через HTTP. Но в последнее время у меня возникла необходимость предложить HTTPS. И здесь я совершенно запутался. Экземпляр EC2 работает под управлением Apache, PHP и MySQL на Linux.
Я немного понимаю (абстрактно), как HTTPS работает в мире, отличном от AWS. (Я никогда этого не делал.) Но я полагаю, что это не лучший способ сделать это с AWS, который, похоже, требует настройки чего-то в диспетчере сертификатов, а затем подключения к нему Elastic Load Balancer. Я как бы в растерянности.
Я успешно создал сертификат в диспетчере сертификатов. Я создал ELB с «целевой» группой, которая мне показалась правильной, и подключил ее к сертификату. Когда я пытаюсь добавить https: // перед своим хостом, он говорит, что сервер отказывается подключаться. Когда я захожу в сам ELB и получаю доступ к URL-адресу, который он дает мне для ELB, я получаю сообщение об ошибке 503 «Сервис временно доступен».
Я думаю, что, возможно, я просто не понимаю этого правильно, и все сообщения AWS / HTTPS здесь, похоже, предполагают, что вы знаете, чего пытаетесь достичь. Может ли кто-нибудь просто объяснить мне, как все эти вещи (сертификат, ELB, экземпляр EC2 и Apache) должны быть связаны вместе? Спасибо.
Во-первых, не думайте, что вам нужно спускаться по маршруту Amazon Certificate Manager (ACM) / Load Balancer. Это хорошее решение, но оно предназначено для ситуаций, когда у вас есть несколько серверов за балансировщиками нагрузки, а не один автономный экземпляр.
Другим потенциально более дешевым вариантом может быть использование Cloudfront перед вашим сайтом с сертификатом ACM или использование Lets Encrypt на самих экземплярах.
Тем не менее, вы спросили о LB, так что мы идем:
Если вы новичок в балансировщиках нагрузки в AWS, вы сначала должны понять, что существует два типа: ELB и ALB.
ELB (Elastic Load Balancer) - это старый балансировщик нагрузки «классического стиля», который в основном ретранслирует соединение через балансировщик без какой-либо сложной логики. Вы бросаете его перед любым количеством экземпляров и переходите на случайный сервер в пуле.
ALB (Application Load Balancer) немного сложнее, поскольку они могут выполнять некоторую логическую маршрутизацию приложения. При использовании ALB вы определяете целевые группы, а также правила маршрутизации, что означает, что вы можете отправлять трафик в различные наборы экземпляров в зависимости от запрашиваемого пути. ALB можно использовать аналогично ELB, и AWS, похоже, продвигает их использование.
Независимо от того, какой тип LB вы используете, вы по-прежнему устанавливаете перед экземпляром балансировщик, который ретранслирует трафик на исходные машины.
HTTPS / SSL немного усложняет ситуацию, когда речь идет об AWS LB, поскольку они настроены немного по-разному.
Если вы используете ELB, вкладка слушателей в интерфейсе AWS позволяет настроить сопоставление портов. Здесь вы сопоставляете «то, что люди запрашивают» с тем, «откуда это исходит». В этом случае вы, вероятно, захотите 80 -> 80 и 443 -> 80. Поскольку вы хотите прослушивать и http, и https, но подключаться только к http на сервере, так как у него нет https. Для более продвинутой и безопасной конфигурации вы можете установить самозаверяющий сертификат на сервере для сквозного шифрования соединения, а затем использовать 443 -> 443.
Если вы используете ALB, вкладка слушателей снова сопоставляет «то, что люди запрашивают», с тем, «откуда они поступают», но вместо простого сопоставления портов она сопоставляется с «Целевыми группами». В большинстве случаев эффект будет таким же, как и при использовании ELB, вы соединяете порт 80 и 443 по конвейеру с одной целевой группой.
Интерфейс ALB в основном вытягивает часть интерфейса ELB на свою страницу, но и ELB, и ALB пытаются добиться здесь того же, определяя экземпляры / цели и проверки работоспособности. Если у вас нет действительных целей и проверок работоспособности, вы получите 503 ошибки.
С помощью ELB вы определяете, на какие «экземпляры» смотреть. На вкладке экземпляра будет отображаться «Статус», который в основном определяет, будет ли ELB направлять на него трафик или нет. Это должно быть «InService», по крайней мере, в одном экземпляре, или вы получите 503. Если у вас есть какой-либо другой статус, попробуйте подождать несколько минут, чтобы он успокоился, если он не обновляется до InService, у вас что-то не так с ваши экземпляры, или вы не настроили действительную проверку работоспособности.
В ALB цели определяются таким же образом. Основное отличие состоит в том, что вы определяете порт, на котором хотите подключиться к своим экземплярам, в дополнение к тем экземплярам, к которым вы хотите подключиться. Самый распространенный способ настроить это - указать экземпляры на порту 80, так как это то, на чем работает большинство веб-серверов, хотя, как и в случае ELB, для повышения безопасности вы можете использовать HTTPS в экземплярах, использующих self подписанные сертификаты, чтобы все было зашифровано до конца.
Как и в случае с ELB, ваша самая важная информация здесь - это целевой статус, в этом случае вы хотите видеть «исправен». Если вы этого не видите, подождите немного или проверьте состояние вашего здоровья.
И ALB, и ELB полагаются на проверки работоспособности, чтобы знать, следует ли им направлять трафик к вашим экземплярам. Обычно это довольно просто. Большинство людей настроят проверки работоспособности так, чтобы они указывали на довольно простую страницу, что-то на вашем веб-сайте или в корень вашего сайта, которые загружаются очень быстро, поскольку AWS будет запускать их несколько раз в минуту. Экземпляр получит перенаправленный трафик, только если он пройдет проверку работоспособности. По умолчанию используется корень веб-сайта. Очень важно настроить эти параметры для наилучшего соответствия вашему сайту. Я часто устанавливаю работоспособный поток на минимум, чтобы мои серверы обслуживали трафик как можно быстрее, и уменьшаю интервал опроса до более быстрого.
Если вы запустите сингл ec2 экземпляр там ИМХО нет необходимости использовать ELB. Если вы хотите использовать ELB следить за этим руководство.
Если вы хотите напрямую подключиться к своему ec2 экземпляр без ELB настроить https на вашем Apache вот так:
LoadModule ssl_module modules/mod_ssl.so
Listen 443
<VirtualHost *:443>
ServerName www.example.com
SSLEngine on
SSLCertificateFile "/path/to/www.example.com.cert"
SSLCertificateKeyFile "/path/to/www.example.com.key"
</VirtualHost>
Взгляните на документация для получения подробных инструкций.
Скорее всего, вы либо неправильно настроили https на стороне ELB, либо пытаетесь подключиться к своему экземпляру через https с IP-адресом экземпляра, а не с IP-адресом ELB.