AWS Beanstalk: ни один из экземпляров не отправляет данные, и не может ssh в ec2 - PullRequest
Новая
       6

AWS Beanstalk: ни один из экземпляров не отправляет данные, и не может ssh в ec2

0 голосов
/ 02 декабря 2018

Я столкнулся с этой проблемой 

None of the Instances are sending data

при развертывании новой версии моего приложения на beanstalk, единственная разница между двумя версиями незначительна, и я совершенно уверен, что это не причина.Вот что я вижу:

  • Я не могу получить журналы с консоли beanstalk
  • Я не могу подключиться к экземпляру EC2 этой конфигурации beanstalk по протоколу ssh (хотя состояние этого экземпляра 'выполняется'.
  • В прошлый раз, когда я столкнулся с той же проблемой с экземпляром ec2.micro, он был решен при обновлении до ec2.small. Что я думал, вероятно, использование ресурсов делает его неотзывчивым (хотя и странно, так кактолько развертывание, даже не обслуживая какой-либо трафик.) Я не хочу обновлять (опять же), не понимая, что здесь происходит.
  • Процессор работает примерно на 80% -> 60% -> 20% во времяпервые 5 минут развертывания, затем постоянно оставайтесь на уровне 10%.

Единственный способ получить журнал сервера - это получить системный журнал из консоли aws, и вот он:

Вот журнал: https://pastebin.com/PWWjPr3b

Вот то, что я увидел, когда я выпускаю ssh: 

OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/okidogi/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to ec-******.eu-west-2.compute.amazonaws.com 
[35.177.76.128] port 22.
debug1: Connection established.
debug1: identity file aws-eb type 1
debug1: key_load_public: No such file or directory
debug1: identity file aws-eb-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4

Затем он находится там в ожидании.

Оцените, есликто-то может помочь в этом.

1 Ответ

0 голосов
/ 10 декабря 2018

Фэн, рад слышать, что сделал трюк для тебя.Однако эта идея была скорее диагностическим тестом, чем долгосрочным решением.Поскольку переключение на Immutable работало для вас - это указывало бы на возможность того, что вашему процессу сборки требуется больше памяти, чем доступно на (уже работающем) небольшом устройстве, таком как t2.micro или t1.micro.Используя неизменную стратегию, вы начинаете каждое развертывание с нового экземпляра, который имеет больше доступных ресурсов, чем тот, который уже использовался для запуска вашего приложения.

Это распространенная проблема, которую трудно диагностировать, поскольку она представляет много разныхспособы в зависимости от платформы и фреймворка.Вы можете прочитать больше здесь: https://medium.com/@deanslamajr/an-insufficient-memory-deployment-failure-d9f1cb9b5c0.

Мой предпочтительный способ решения этой проблемы - использование своп-памяти, как я обрисовал в общих чертах в ответе на аналогичный вопрос: AWS EB, развертывающее приложение Node: не удалось запуститьnpm install

Я бы посоветовал попробовать упомянутую там стратегию .ebextensions, а также вернуться к стратегии развертывания All at once, чтобы проверить, действительно ли это решает вашу проблему.

...