Как изменить поведение перезапуска стека Docker?

Question

В нашем проекте мы унаследовали среду Docker с некоторым служебным стеком.

Я заметил, что Docker перезапускает стек, когда он сталкивается с ограничением памяти.

К сожалению, я не нашел ни одногоинформация в соответствии с моими вопросами на сайте Докера, поэтому я спрашиваю здесь:

1. Настраивается ли это поведение?Например, я не хочу, чтобы Docker перезапускал мой стек ни при каких обстоятельствах.Если настраивается , то как?
2. Существует ли какой-либо журнал докеров, в котором все стеки перезагружаются при записи?

Answer 1

1. Это поведение настраивается?Например, я не хочу, чтобы Docker перезапускал мой стек ни при каких обстоятельствах.Если это настраивается, то как?

При использовании стека версии 3 политика перезапуска перемещена в раздел развертывания:

version: '3'
services:
  crash:
    image: busybox
    command: sleep 10
    deploy:
      restart_policy:
        condition: none
        # max_attempts: 2

Документация по этому вопросу доступна на: https://docs.docker.com/compose/compose-file/#restart_policy

Существует ли какой-либо журнал докеров, в котором сохраняются перезапуски стека в виде его записей?

В зависимости от предела истории задач (настраивается с помощью docker swarm update, вы можете просмотреть ранее запущенные задачи дляслужба:

$ docker service ps restart_crash
ID                  NAME                  IMAGE               NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
30okge1sjfno        restart_crash.1       busybox:latest      bmitch-asusr556l    Shutdown            Complete 4 minutes ago
papxoq1vve1a         \_ restart_crash.1   busybox:latest      bmitch-asusr556l    Shutdown            Complete 4 minutes ago
1hji2oko51sk         \_ restart_crash.1   busybox:latest      bmitch-asusr556l    Shutdown            Complete 5 minutes ago

И вы можете проверить состояние любой задачи:

$ docker inspect 30okge1sjfno --format '{{json .Status}}' | jq .
{
  "Timestamp": "2018-11-06T19:55:02.208633174Z",
  "State": "complete",
  "Message": "finished",
  "ContainerStatus": {
    "ContainerID": "8e9310bde9acc757f94a56a32c37a08efeed8a040ce98d84c851d4eef0afc545",
    "PID": 0,
    "ExitCode": 0
  },
  "PortStatus": {}
}

В модуле докера также есть история событий, которую вы можете запросить:

$ docker events --filter label=com.docker.swarm.service.name=restart_crash --filter event=die --since 15m --until 0s
2018-11-06T14:54:09.417465313-05:00 container die f17d945b249a04e716155bcc6d7db490e58e5be00973b0470b05629ce2cca461 (com.docker.stack.namespace=restart, com.docker.swarm.node.id=q44zx0s2lvu1fdduk800e5ini, com.docker.swarm.service.id=uqirm6a8dix8c2n50thmpzj06, com.docker.swarm.service.name=restart_crash, com.docker.swarm.task=, com.docker.swarm.task.id=1hji2oko51skhv8fv1nw71gb8, com.docker.swarm.task.name=restart_crash.1.1hji2oko51skhv8fv1nw71gb8, exitCode=0, image=busybox:latest@sha256:2a03a6059f21e150ae84b0973863609494aad70f0a80eaeb64bddd8d92465812, name=restart_crash.1.1hji2oko51skhv8fv1nw71gb8)
2018-11-06T14:54:32.391165964-05:00 container die d6f98b8aaa171ca8a2ddaf31cce7a1e6f1436ba14696ea3842177b2e5e525f13 (com.docker.stack.namespace=restart, com.docker.swarm.node.id=q44zx0s2lvu1fdduk800e5ini, com.docker.swarm.service.id=uqirm6a8dix8c2n50thmpzj06, com.docker.swarm.service.name=restart_crash, com.docker.swarm.task=, com.docker.swarm.task.id=papxoq1vve1adriw6e9xqdaad, com.docker.swarm.task.name=restart_crash.1.papxoq1vve1adriw6e9xqdaad, exitCode=0, image=busybox:latest@sha256:2a03a6059f21e150ae84b0973863609494aad70f0a80eaeb64bddd8d92465812, name=restart_crash.1.papxoq1vve1adriw6e9xqdaad)
2018-11-06T14:55:00.126450155-05:00 container die 8e9310bde9acc757f94a56a32c37a08efeed8a040ce98d84c851d4eef0afc545 (com.docker.stack.namespace=restart, com.docker.swarm.node.id=q44zx0s2lvu1fdduk800e5ini, com.docker.swarm.service.id=uqirm6a8dix8c2n50thmpzj06, com.docker.swarm.service.name=restart_crash, com.docker.swarm.task=, com.docker.swarm.task.id=30okge1sjfnoicd0lo2g1y0o7, com.docker.swarm.task.name=restart_crash.1.30okge1sjfnoicd0lo2g1y0o7, exitCode=0, image=busybox:latest@sha256:2a03a6059f21e150ae84b0973863609494aad70f0a80eaeb64bddd8d92465812, name=restart_crash.1.30okge1sjfnoicd0lo2g1y0o7)

См. Более подробную информацию о команде событий по адресу: https://docs.docker.com/engine/reference/commandline/events/

. В крупных организациях рекомендуется отправлять журналы контейнеров в центральное местоположение (например, Elastic) и осуществлять внешний мониторинг показателей (например, Прометей / Графана).

Answer 2

Поскольку вы не добавили ни одного фрагмента конфигурации или команд времени выполнения к своему сообщению, мне придется выдвинуть гипотезу по вашему актуальному вопросу.

Мои предположения:

• выработают несколько служб с использованием docker-compose
• эти службы имеют настроенные ограничения памяти (в файле docker-compose.yml)
• вы видите их перезапуск, как только они достигают настроенного предела памяти, и выхочу запретить их перезапуск

Я предполагаю, что ваш docker-compose.yml выглядит следующим образом:

version: '2.1'
services:
   service1:
     image: some/image
     restart: always
     mem_limit: 512m
   service2:
     image: another/image
     restart: always
     mem_limit: 512m

При такой конфигурации любой из сервисных контейнеров будет OOM-Уничтожено ядром, когда оно пытается использовать более 512 МБ памяти.Затем Docker автоматически перезапустит новый контейнер, чтобы заменить убитый.

Итак, чтобы ответить на ваш 1-й пункт: да, это так, просто измените «restart» на «no», или просто удалите эту строку (так как «нет "является значением по умолчанию для этого параметра).Что касается вашего второго пункта, просто ищите перезапуски сервисов в журналах демона docker.

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

Было бы лучше рассмотреть схему использования памяти вашими службами и понять, почему они пытаютсяиспользовать больше установленного лимита.В конце концов, решение состоит в том, чтобы либо настроить ваши службы на использование меньшего количества памяти, либо увеличить mem_limit в вашем docker-compose.yml.

Например:

• для базы данныхнастройте параметры памяти, чтобы механизм не использовал больше оперативной памяти, чем mem_limit (SGA и PGA под Oracle, различные буферы и размеры кэша для MySQL / MariaDB, ...)
• для Java-приложений, настройтеXmx должно быть меньше, чем mem_limit (с учетом потребностей в памяти без кучи), или, желательно, с недавним JDK (последние 8 или 9+) идти на -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap.

IНадеюсь, что это поможет вам;чтобы быть более точным, мне действительно нужно больше контекста.