Не удалось проверить работоспособность в Docker-контейнере на CloudFoundry: такого файла или каталога нет - PullRequest
0 голосов
/ 04 июня 2018

Я запускаю докер-контейнер в CloudFoundry.

Через несколько дней экземпляр аварийно завершился со следующей ошибкой:

Экземпляр стал неработоспособным: сбой exec: container_linux.go: 348:запуск процесса контейнера вызвал "exec: \" / tmp / lifecycle / healthcheck \ ": stat / tmp / lifecycle / healthcheck: нет такого файла или каталога"

Факты:

  • Тип проверки работоспособности установлен на «порт»
  • После сбоя приложение перезапускается и работает нормально
  • Это происходило несколько раз в разных местах
  • Это также происходилов экземпляре dev, который не обрабатывал запросы одновременно

Вопросы:

  1. Что это за проверка работоспособности?
  2. Почему эта проверка выполняется?
  3. Как это предотвратить?

1 Ответ

0 голосов
/ 05 июня 2018

Что это за проверка работоспособности?

Платформа Cloud Foundry контролирует ваше приложение.Когда он обнаруживает, что приложение «упало», оно перезапустит его для вас.Я поместил «сбои» в кавычки, потому что это туманный термин.

Платформа определяет «сбои» как приложение, которое больше не отвечает на проверки работоспособности, отправленные платформой.Есть три проверки здоровья.

  1. Первый - это проверка работоспособности на основе pid, когда платформа отслеживает процесс, чтобы убедиться, что он продолжает работать.Если процесс завершается, платформа интерпретирует это как сбой и перезапускает ваше приложение.

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

  3. Третий - проверка работоспособности на основе HTTP.Этот на самом деле отправляет HTTP-запрос к конечной точке вашего приложения.Это должно ответить успешным кодом состояния HTTP, в противном случае ваше приложение считается сбойным.

Каждое приложение, развернутое в CF, использует первую проверку работоспособности.Любое приложение с привязанным к нему маршрутом будет использовать вторую или третью проверку работоспособности, в дополнение к первой.

Похоже, что ваше приложение использует проверку работоспособности на основе порта, которая является # 2.

Почему выполняется эта проверка?

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

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

Как это предотвратить?

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

Если вы действительно хотите отключить его, вы должны установить проверку работоспособности на «обработка».Это говорит платформе только о выполнении проверки pid (т. Е. № 1) выше.

Пример: cf push --health-check-type process

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

Надеюсь, это поможет!

...