Почему мои задачи ECS приостанавливаются на шесть часов при запуске?
У меня есть задача Fargate ECS, которая запускает приложение Django через gunicorn. Эта задача успешно запускалась несколько недель назад и не имела никаких проблем. Затем она была заменена в результате рутинного обслуживания/обновления AWS. Замена задачи началась успешно, но она приостановилась во время выполнения сценария точки входа на время, превышающее льготный период проверки работоспособности балансировщика нагрузки. Задача, конечно же, не прошла проверку работоспособности, что заставило ECS снова остановить и заменить задачу. Затем это происходило бесконечно, причем при каждой замене задачи возникала одна и та же проблема.
В образе Docker, используемом для задачи, не было никаких изменений кода. Очевидно, я ожидал, что в задаче ECS ничего не изменится и она будет выполняться так же, как и раньше.
После внедрения автоматического выключателя развертывания задачи ECS, чтобы остановить бесконечный цикл замены задач, я оставил приостановленную (но запущенную) задачу ECS в покое на некоторое время. Из журналов Cloudwatch я понял, что задача приостанавливается на ровно шесть часов каждый раз, когда в середине выполняется сценарий точки входа. Вот сценарий точки входа:
set -euo pipefail
cd /home/viewer/projects/server || exit
export DJANGO_SETTINGS_MODULE=viewer_server.settings
export PYTHONPATH="/home/viewer/projects/server/"
echo "DJANGO_SETTINGS_MODULE and PYTHONPATH set."
python manage.py makemigrations
python manage.py migrate
python viewer_server/create_django_superuser.py
gunicorn --timeout 120 --graceful-timeout 120 --workers 3 --bind :80 viewer_server.wsgi:application
Вот выдержка из журналов Cloudwatch:
2024-06-10T08:44:37.294Z DJANGO_SETTINGS_MODULE and PYTHONPATH set.
2024-06-10T14:44:40.849Z No changes detected
2024-06-10T20:44:43.978Z Running migrations:
2024-06-10T20:44:43.978Z No migrations to apply.
2024-06-10T20:44:44.654Z Django superuser already exists.
2024-06-10T20:44:44.871Z Starting gunicorn 20.1.0
2024-06-10T20:44:44.871Z Listening at: http://0.0.0.0:80 (769)
2024-06-10T20:44:44.871Z Using worker: sync
2024-06-10T20:44:44.874Z Booting worker with pid: 771
2024-06-10T20:46:46.181Z WORKER TIMEOUT (pid:771)
2024-06-10T20:46:46.182Z Worker exiting (pid: 771)
2024-06-10T20:46:46.542Z Booting worker with pid: 782
2024-06-10T20:48:47.609Z WORKER TIMEOUT (pid:782)
2024-06-10T20:48:47.610Z Worker exiting (pid: 782)
Есть и другие рабочие-гуникорны, но я немного сократил журнал для удобства чтения. Все они делают одно и то же. Я проверил, что таймаут рабочего вызван GET-запросом healthcheck балансировщика нагрузки, включив логирование на уровне gunicorn DEBUG. Похоже, что пауза во время выполнения команды Django по какой-то причине привела к нерабочему веб-серверу, несмотря на отсутствие миграций.
Единственное связанное с ECS упоминание о шести часах в документации AWS, которое я нашел, находится здесь: https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-iam-roles.html
Роль IAM такая же, как и всегда, поэтому я не знаю, как это может быть связано. Пытаясь хотя бы заставить задачу ECS работать, я пытался выяснить, как обновить временные учетные данные, которые задача получает от своей роли IAM. Но я так и не смог понять, как заставить это работать.
Любая помощь будет оценена по достоинству!