У меня есть определение задачи ecs, которое обычно развертывается без проблем в экземпляре ec2. Я пытаюсь включить awslogs в одной из служб задачи, чтобы синхронизировать журналы контейнеров с cloudwatch.
Я следовал инструкциям awslogs amazon и получил определение задачи, которое включает в себя:
"containerDefinitions": [
{
"logConfiguration": {
"logDriver": "awslogs",
"secretOptions": null,
"options": {
"awslogs-group": "server-test",
"awslogs-region": "us-east-1",
"awslogs-create-group": "true",
"awslogs-stream-prefix": "gunicorn"
}
}
...
}
],
...
"requiresAttributes": [
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.logging-driver.awslogs"
},
...
...
Помимо этих изменений, определение задачи совпадает с тем, что я использовал без проблем. Когда я пытаюсь запустить это определение задачи в моем кластере (через ecs-cli compose service up), оно зависает и время ожидания с сообщением:
service main was unable to place a task because no container instance met all of its requirements. The closest matching container-instance <...> has insufficient memory available. For more information, see the Troubleshooting section.
Больше нет сообщений, даже если включен подробный вывод.
Мне не удалось найти какую-либо информацию о требованиях к памяти для awslogs, и я не ожидаю, что она будет настолько ресурсоемкой. Я не изменил ни одного ограничения памяти службы, и они обычно работают с большим запасом. И как только я удаляю конфигурацию журнала из определения задачи, она развертывается и работает нормально.
Имеет ли awslogs и агент журнала определенные c требования к типу памяти / экземпляра? В любом случае я могу получить более подробные журналы из команды ecs / ecs-cli compose?