Назад | Перейти на главную страницу

Сценарий запуска systemd для контейнера докеров не работает

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

[Unit]
Description=Docker container that houses the Jenkins build service.
After=network-online.target

[Service]
Group=docker
ExecStart=/usr/bin/docker start jenkins
ExecStop=/usr/bin/docker stop jenkins

[Install]
WantedBy=multi-user.target

Я поместил это в /etc/systemd/system/jenkins.service.

Когда я бегу sudo systemctl start jenkins, Ничего не произошло. Никаких ошибок или чего-либо распечатанного, и контейнер не запускается (если я запускаю docker ps, нет контейнеров, перечисленных как работающие).

Я могу бегать /usr/bin/docker start jenkins из командной строки вручную, и он запускается отлично, поэтому проблема, похоже, в том, как я написал сценарий, но я не могу понять, почему он не работает должным образом. Любая помощь приветствуется.

Обновить:

Я обновил скрипт, изменив ExecStart и ExecStop ценности быть /bin/sh -c '/usr/bin/docker start jenkins' и /bin/sh -c '/usr/bin/docker stop jenkins'соответственно, но это все равно не сработало.

Обновление 2:

Я обновил ExecStart и ExecStop удалив /bin/sh -c "..." и просто заключив команду в двойные кавычки, но теперь я получаю интересный вывод в sudo systemctl status jenkins:

$ sudo systemctl status jenkins
● jenkins.service - Docker container that houses the Jenkins build service.
   Loaded: loaded (/etc/systemd/system/jenkins.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2017-12-03 12:20:39 EST; 10s ago
  Process: 1513 ExecStop=/usr/bin/docker stop jenkins (code=exited, status=203/EXEC)
  Process: 1511 ExecStart=/usr/bin/docker start jenkins (code=exited, status=203/EXEC)
 Main PID: 1511 (code=exited, status=203/EXEC)

Dec 03 12:20:39 evt-jenkins systemd[1]: Started Docker container that houses the Jenkins build service..
Dec 03 12:20:39 evt-jenkins systemd[1]: jenkins.service: Main process exited, code=exited, status=203/EXEC
Dec 03 12:20:39 evt-jenkins systemd[1]: jenkins.service: Control process exited, code=exited status=203
Dec 03 12:20:39 evt-jenkins systemd[1]: jenkins.service: Unit entered failed state.
Dec 03 12:20:39 evt-jenkins systemd[1]: jenkins.service: Failed with result 'exit-code'.

Есть ли способ увидеть именно что не получается? Эти коды ошибок на самом деле ни о чем не говорят.

Обновление 3:

Хорошо, поэтому я снова посмотрел с самого начала и удалил кавычки. В jenkins.service файл теперь читается точно так же, как и в начале вопроса. Когда я перезагружаю systemd и запускаю службу, это результат sudo systemctl status jenkins:

$ sudo systemctl status jenkins
● jenkins.service - Docker container that houses the Jenkins build service.
   Loaded: loaded (/etc/systemd/system/jenkins.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Sun 2017-12-03 12:31:59 EST; 2s ago
  Process: 1683 ExecStop=/usr/bin/docker stop jenkins (code=exited, status=0/SUCCESS)
  Process: 1594 ExecStart=/usr/bin/docker start jenkins (code=exited, status=0/SUCCESS)
 Main PID: 1594 (code=exited, status=0/SUCCESS)

Dec 03 12:31:59 evt-jenkins systemd[1]: Started Docker container that houses the Jenkins build service..
Dec 03 12:31:59 evt-jenkins docker[1594]: jenkins
Dec 03 12:31:59 evt-jenkins docker[1683]: jenkins

Таким образом, systemd не только сообщает об успешном запуске скрипта, но также показывает правильный результат запуска контейнера по его имени (а не по его SHA). Но когда я бегу docker ps, ничего не указано !! Напомню, когда я запускаю команду docker вручную, контейнер работает нормально.

Есть предположения? С Systemd довольно сложно работать.

Обновление 4:

Хорошо, я только что заметил здесь что-то очень странное. Если вы заметили в приведенном выше фрагменте (вывод sudo systemctl status jenkins), вы заметите, что PID ExecStart равно 1594, а PID ExecStop равно 1683. Теперь, ниже в выводе, вы увидите, что вывод ExecStart идет первым, перед в ExecStop. Я не уверен, было ли это из-за буферизации вывода, или если systemd делает ExecStart бежать до ExecStop.

Есть ли причина, по которой вы пытаетесь сделать это с помощью сценария запуска systemd, а не с помощью механизмов докеров, таких как restart: always?

Мы используем docker-compose.yml, и он выглядит так:

docker-compose.yml

version: '2'

services:
  jenkins:
    image: ###OWN_JENKINS_IMAGE###
    restart: always
    mem_limit: 2100m
    networks:
      - web
      - dockerhub
    environment:
      - "REVERSE_PROXY_PORT=8080"
      - "REVERSE_PROXY_HOSTNAME=####INTERNAL_HOSTNAME####"
      - "X_PROXY_PORT=443"
      - "X_PROXY_SCHEME=https"
      - "X_PROXY_NAME=####INTERNAL_HOSTNAME####"
    volumes:
      - ./data/jenkins:/var/jenkins_home
      - ./data/ssh/:/var/ssh/
      - /var/run/docker.sock:/var/run/docker.sock
      - /usr/bin/docker:/usr/bin/docker
      - ./data/volumes/lib64/libdevmapper.so.1.02:/usr/lib/libdevmapper.so.1.02
      - ./data/volumes/lib64/libdw.so.1:/usr/lib/libdw.so.1
      - ./data/volumes/lib64/libgcrypt.so.11:/usr/lib/libgcrypt.so.11
      - ./data/volumes/lib64/libsystemd-id128.so.0:/usr/lib/libsystemd-id128.so.0
      - ./data/volumes/lib64/libsystemd-journal.so.0:/usr/lib/libsystemd-journal.so.0

networks:
  web:
    external:
      name: web
  dockerhub:
    external:
      name: ####INTERNAL_HOSTNAME####

После запуска образа с docker-compose up -d он будет перезапущен при возникновении проблемы и сразу после перезапуска всего сервера, указанного ниже.

Я согласен с использованием Docker для запуска контейнера и с параметром restart: always.

Что касается сценария и ведения журнала:

  • Вы отменяете какие-либо значения по умолчанию для демона докера? Возможно, вы захотите использовать файл переопределения только с нестандартными значениями, а не редактировать сами файлы конфигурации systemd.

  • Ваш вывод из systemctl: пробовали ли вы установить StandardOutput = tty, чтобы увидеть, что происходит, когда это происходит?

  • Другие журналы: видите ли вы какие-либо ошибки в других журналах вашей системы, таких как / var / log / syslog или / var / log / messages? Для systemd выводом по умолчанию для stderr является syslog.

Я спрашиваю об этом, потому что в моем опыте работы с Unix / Linux вам нужно просматривать журналы, когда системные действия не складываются.

Для получения дополнительной информации об использовании Docker с systemd вы можете проверить это вики.