Как сохранить контейнер ECS во время работы долго запущенного скрипта запуска - PullRequest
0 голосов
/ 13 сентября 2018

Я развертываю приложение со стартовым скриптом, который генерирует данные кэша, если они не существуют, если они существуют, этот процесс будет пропущен, и основное приложение запустится, все это контролируется ENTRYPOINT["/opt/entrypoint.sh"], таможенный сценарий, который определяет, что делать в зависимости от сценария.

У меня проблема в том, что AWS ECS убивает контейнер и помечает его как нездоровый. Тем не менее, он запускает entrypoint.sh, указанный в Dockerfile. Что в этом "вредного для здоровья"? Как сохранить генерацию кэша перед запуском основного приложения в контейнере? Это однократный процесс, который происходит, когда изображение сначала извлекается и запускается как локальный контейнер.

Ответы [ 2 ]

0 голосов
/ 18 сентября 2018

Моя организация и я в конечном итоге решили эту проблему, поддерживая контейнер Docker как можно более тонким и используя снимки и тома AWS для управления внешней полезной нагрузкой, а не пытались использовать первую загрузку для передачи данных в локальный контейнер Docker.,Это потребовало некоторого незначительного рефакторинга, но дало нам то, что нам было нужно для продвижения вперед.Докер работал нормально, для протокола, это была проверка работоспособности AWS ECS и невозможность приостановить работу других сервисов, пока эта загружалась в течение длительного периода времени.

0 голосов
/ 13 сентября 2018

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

Чтобы исправить это, вы должны отрегулировать проверки здоровья. Это можно сделать в нескольких местах (целевая группа, определение задачи). Я предлагаю вам сделать это в определении задачи, потому что проверка работоспособности будет связана с поведением вашего контейнера. Вот документация для полей проверки работоспособности в определении задачи .

Внимание! Исходя из моего опыта, вы не можете удалить конфигурацию проверки работоспособности после добавления ее в определение задачи. В моем случае имело смысл продолжать проверять здоровье от ELB (таким образом, я должен был определить их в целевой группе). Мне пришлось удалить определение задачи и создать его заново, чтобы избавиться от конфигурации проверки работоспособности.

...