Тестовая политика перезапуска - как вывести контейнер из строя, чтобы он перезапустился

Question

У меня есть файл docker-compose, который создает 3 приложения Hello World и использует nginx для балансировки трафика между различными контейнерами.

Код docker-compose выглядит следующим образом:

version: '3.2'
services:
  backend1:
      image: rafaelmarques7/hello-node:latest
      restart: always
  backend2:
      image: rafaelmarques7/hello-node:latest
      restart: always
  backend3:
      image: rafaelmarques7/hello-node:latest
      restart: always
  loadbalancer:
      image: nginx:latest      
      restart: always
      links:
          - backend1
          - backend2
          - backend3
      ports:
        - '80:80'
      volumes: 
        - ./container-balancer/nginx.conf:/etc/nginx/nginx.conf:ro

Я бы хотел убедиться, что политика restart: always действительно работает.

Я попробовал следующий подход:

• Сначала я запускаю свое приложение с docker-compose up;
• Я идентифицирую идентификаторы контейнеров с помощью docker container ps;
• Я убиваю / останавливаю один из контейнеров с помощью docker stop ID_Container или docker kill ID_Container.

Я быложидая, что после 3-го шага (остановка / уничтожение контейнера. это делает его существующим с кодом 137), политика перезапуска включится и снова создаст новый контейнер.

Однако этого не происходит.Я читал, что это намеренно, так как у меня есть возможность вручную останавливать контейнеры с политикой перезапуска.

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

Спасибо за помощь.

Answer 1

Вы можете docker exec войти в работающий контейнер и уничтожить процессы.Если ваш процесс точки входа (pid 1) запускает подпроцесс, найдите его и убейте его

docker exec -it backend3 /bin/sh
ps -ef

Найдите процесс, для которого pid 1 является его родителем, а kill -9 это.

Если вашточка входа в единственный процесс (pid 1), она не может быть уничтожена командой kill.Попробуйте заменить точку входа сценарием, который вызывает фактический процесс, что позволит вам использовать идею, предложенную мной выше.

Это должно симулировать сбойный контейнер и запустить процесс перезапуска.

ПРИМЕЧАНИЯ:

1. См. Объяснение в https://unix.stackexchange.com/questions/457649/unable-to-kill-process-with-pid-1-in-docker-container
2. Посмотрите, почему бы не запустить NodeJS в качестве pid 1 в https://www.elastic.io/nodejs-as-pid-1-under-docker-images/

Answer 2

Если вы запустите ps на хосте, вы сможете увидеть фактические процессы во всех ваших контейнерах Docker.Как только вы найдете идентификатор процесса основного процесса контейнера, вы можете sudo kill его (вы должны быть пользователем root).Это будет выглядеть скорее как «сбой», особенно если вы kill -13 отправляете SIGSEGV.

В таких сценариях проверки очень редко бывает полезно иметь конечную точку, которая приводит к сбою приложения, которое вы можете включить в тесте.строит и некоторые другие подобные глупости.Просто убедитесь, что у вас есть ворота, чтобы эти конечные точки не существовали в производственных сборках.(В старой школе C #ifdef TEST справился бы с работой; у некоторых языков есть эквиваленты, но у многих их нет.)