я использовал этот ответьте как руководство, которое поможет мне написать сценарий запуска для 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 вы можете проверить это вики.