Terraform создал инфраструктуру AWS ECS: проверка работоспособности продолжается

Question

Короче говоря, я хочу развернуть свой образ докера Nginx и Node.js в AWS ECS.Для создания инфраструктуры я использую Terraform.Однако задача, выполняемая на сервере, продолжает сбой.Кроме того, я получил 503 Service Temporarily Unavailable при доступе к своему домену bb-diner-api-https.shaungc.com .

(Вы можете увидеть весь мой репозиторий проекта здесь ,но я вставлю ссылки ниже и проведу вас через определенные связанные файлы.)

После terraform apply он сообщает о 15 созданных ресурсах, и я вижу, что служба и задача выполняются на веб-портале ECS.Однако моя задача всегда будет терпеть неудачу через некоторое время, как показано ниже:

Поскольку проверка работоспособности всегда не выполняется:

Для nodejs у меня есть код ошибки 137, который вызван получением сигнала выключения.Это означает, что nodejs не является причиной - nginx провалил слишком много проверок работоспособности, так что он завершает работу nodejs.Для nginx сообщение вообще не отображается после нажатия на View logs in CloudWatch (я установил awslogs в определении задачи ).

Настройка проверки моего здоровья

Проверка работоспособности контейнера определения задачи

В основном я подготовил маршрут в nginx только для проверки работоспособности.В определении задачи > container_definition (в формате json) у меня есть проверка работоспособности контейнера nginx примерно так: "command": ["CMD-SHELL","curl -f http://localhost/health-check || exit 1"], а в моем nginx.conf у меня есть:

...
server {
  listen 80;
  ...

  location /health-check {
        # access_log off;
        return 200 "I'm healthy!" ; # refer to https://serverfault.com/questions/518220/nginx-solution-for-aws-amazon-elb-health-checks-return-200-without-if 
  }
}

Так что я действительно не знаю, почему задача не проходит проверку работоспособности.

Проверка работоспособности целевой группы для балансировщика нагрузки

Я также создал балансировщик нагрузки приложениядля меня, чтобы связать мое доменное имя на маршруте 53 к нему.Я заметил, что есть еще одно место, где выполняется проверка работоспособности: целевая группа и балансировщик нагрузки приложения.Проверка здесь также не удалась, и мой статус экземпляра draining.

Группа безопасности

Я думаю, что открыл все возможные порты.

Так почему проверка состояния не проходит и что еще отсутствует?

Таммного статей, в которых указывается конфигурация Nginx, PORT или входящее ограничение (группа безопасности / целевая группа) в AWS, могут быть общими причинами, и я рассмотрел все из них.Я позволил nginx прослушивать 80, установить порт контейнера равным 80, разрешить широкий диапазон входящих портов в группе безопасности.Что еще я могу упустить?

Answer 1

Я вроде понял сам.Хотя я никогда не проходил проверку работоспособности на уровне контейнера, мне удалось исправить ошибку проверки работоспособности на балансировщике нагрузки приложения.

Проблема и причина

Оказалось, что это как-то связано сгруппа безопасности экземпляра EC2.Я заметил это, когда следил за страницей Устранение неполадок AWS для проверки работоспособности, где они советуют ssh войти в экземпляр и попробовать curl -v ... непосредственно на экземпляре.Ошибка curl, и я обнаружил, что моя группа безопасности экземпляра EC2 использует sg по умолчанию.Хотя группа безопасности по умолчанию (sg) разрешает весь трафик, она ограничивает свой источник для себя, то есть группу безопасности по умолчанию.Это может сбивать с толку, но я думаю, что это означает, что он разрешает трафик только от сервисов aws, которые также используют группу безопасности по умолчанию.В любом случае, это блокирует любой трафик за пределами службы aws, поэтому я не могу получить доступ через мое доменное имя и агент проверки работоспособности ALB.

Решение

Мое окончательное решение - иметьвыделенную группу безопасности для ALB, а затем создайте новую группу безопасности для экземпляров EC2, которая разрешает только трафик из группы безопасности ALB.Также обратите внимание, что, поскольку мы уже ограничиваем порт до 80 и 443 в группе безопасности ALB, и теперь экземпляр sg EC2 установлен за sg ALB (теперь весь внутренний трафик), нет необходимости ограничивать порт до 80/443 в экземпляре sg EC2.Вы можете оставить это как 0, чтобы разрешить все порты.Если вы ограничены неправильным портом, проверка работоспособности начнет сбой.См. Следующее на странице устранения неполадок AWS:

Убедитесь, что группа безопасности, связанная с вашим экземпляром контейнера, разрешает весь входящий трафик в диапазоне временных портов (обычно это порты 32768-65535) из группы безопасности, связанной с вашим балансировщиком нагрузки

Важно : если вы объявите порт хоста в своем определении задачи, служба будет отображаться на указанном порту, а не в диапазоне временных портов.По этой причине убедитесь, что ваша группа безопасности отражает указанный порт хоста, а не диапазон эфемерного порта.

---

Другие проблемы

Это действительно заняло у меня много усилий ивремя, чтобы выяснить.Небольшое замечание: я до сих пор не могу заставить работать проверку уровня контейнера, что определено в определении задачи AWS ECS.Я попытался ssh в экземпляр контейнера (экземпляр EC2), и оказалось, что localhost, видимо, не работает.Даже на странице устранения неполадок AWS используется некоторый IP-адрес, сгенерированный из docker inspect, при непосредственном тестировании curl на экземпляре EC2.Но тогда для проверки работоспособности контейнера определения задачи, если не проверка на localhost, что я должен проверить?Должен ли я запустить docker inspect в команде проверки работоспособности, чтобы сначала получить IP-адрес?Эта проблема остается нерешенной, теперь я просто даю exit 0, чтобы обойти проверку работоспособности.Если кто-нибудь знает, как правильно настроить это, не стесняйтесь поделиться, и я действительно хочу знать.