Как избежать ошибки конфигурации при использовании AWS API Gateway с VPC Link?
Я создал канал VPC, используя балансировщик сетевой нагрузки (NLB) в соответствии с документацией AWS, и подключил его к ресурсу / методу шлюза API. Но он выдает "Внутренняя ошибка сервера" при доступе к "Invoke URL" и отображает эту ошибку во время тестирования: "Выполнение не выполнено из-за ошибки конфигурации: при выполнении вашего запроса произошла внутренняя ошибка".
Процедура, которой я следовал:
1) Создан сетевой балансировщик нагрузки:
- Схема балансировки нагрузки: внутренняя
- Протокол балансировки нагрузки / порт: TCP / 80
- Зона доступности: создан VPC с CIDR "10.0.0.0/16" и общедоступной подсетью с CIDR "1XX.XX.0.0/16".
- Целевая группа: протокол / порт / тип цели - TCP / 80 / Instance
- Нет целевой регистрации.
- Запустил NLB.
2) Создано VPC Link в API Gateway с использованием только что созданного NLB.
3) Создан новый API:
- Метод: получить
- Тип интеграции: VPC Link
- Использовать Proxy Integration: True
- VPC Link: $ {stageVariables.vpcLinkId}
- URL-адрес конечной точки: "URL-адрес моего экземпляра ec2 с портом" (например: http://ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com:3000/)
- Создан ресурс API.
4) Развернуть выбранный API с помощью действия "Развернуть API" и только что созданного этапа.
5) Настроил "vpcLinkId" в разделе "Переменные этапа".
Теперь, если я нажму "Invoke URL", на веб-странице появится сообщение " {"message": " Внутренняя ошибка сервера "} ".
Примечание: если я использую тот же URL-адрес EC2 с "Тип интеграции: HTTP", "Invoke URL" работает. То же самое не работает с VPC Link.
Ошибка:
Другие моменты, на которые стоит обратить внимание:
- В EC2 экземпляр с политикой безопасности разрешит все порты TCP.
- Экземпляр EC2 был запущен с использованием ECS / ECR (Docker Container).
- Включены журналы Cloud Watch со стадии API Gateway, но ничего не выдает.
Я рад предоставить дополнительную информацию, если требуется.
РЕДАКТИРОВАТЬ 1
Основываясь на входных данных JNY (jny), я изменил конечную точку шлюза API на NLB и добавил свой экземпляр EC2 в качестве цели в NLB. Тем не менее, я сталкиваюсь с той же проблемой. Ниже изображения покажут все конфигурации, которые я сделал.
Конфигурация балансировщика нагрузки:
Настройки целевой группы балансировщика нагрузки:
Настройки порта целевой группы:
- Здесь я указал 3000 в качестве порта для проверки работоспособности экземпляра, так как мое приложение (Node) прослушивает порт 3000.
- Включены номера портов 80 и 3000 в политике безопасности.
Настройки шлюза API:
- Наконец, я изменил конечную точку шлюза API на NLB
Результат тот же:
Тем не менее я не уверен, какую ошибку я совершаю здесь.
5 ответов
Вы все сделали правильно, но, возможно, это кому-то поможет:
Моя ошибка заключалась в использовании HTTPS для URL-адреса конечной точки в шлюзе API. Это должен быть HTTP.
Верный:
http://myLoadBalancer.elb.us-east-1.amazonaws.com
Текстовое поле было слишком коротким, чтобы отображать весь URL-адрес, поэтому я его не видел.
Проблема была решена после использования одного и того же порта для NLB, EC2, ECS и т. д.
У меня точно такая же проблема (ы). Я получаю "Внутренняя ошибка сервера", а журналы Cloud Watch - пустые.
Я настроил балансировщик нагрузки TCP на порт 80. Балансировщик нагрузки является внутренним, поэтому я не могу отправить ему запрос через Почтальон.
В вашем NLB отсутствуют входящие разрешения для экземпляра EC2 (в их группах безопасности) для порта 80. Но поскольку NLB не имеет группы безопасности (но имеет постоянный IP-адрес), вам придется использовать его IP-адрес и добавлять его непосредственно в группа безопасности для экземпляра EC2. Вот как вы можете найти IP-адреса своих NLB: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#target-security-groups.
Я также получал 500 Internal server error, затем я добавил правила для входящих подключений в группу безопасности EC2 и разрешил HTTP с CIDR подсети VPC, и теперь я могу получить доступ к API с помощью NLB.