Как создать новый системный сервис с помощью загрузочной книги

Я создал скрипт для запуска/остановки моего приложения. Теперь я хочу добавить его в качестве системного сервиса centos. Сначала я создал задачу для создания ссылки из моего сценария в /etc/init.d/service_name, как показано ниже.

---

- name: create startup link
  file: src={{ cooltoo_service_script }} dest={{ cooltoo_service_init }} state=link

После создания службы я хочу добавить ее в системный сервис. Команда, используемая для этого, это "chkconfig --add имя_службы". Интересно, есть ли доступный модуль для этого, а не для жесткой кодировки команды в файле незанятой пьесы. Я просмотрел эту страницу http://docs.ansible.com/ansible/service_module.html, но только показывает, как управлять сервисом, а не создавать новый.

Ответы

Ответ 1

Модуль 'service' поддерживает аргумент 'enabled'.

Здесь примерная часть сборника пьес, которую я свободно признаю, выглядит как попытка новичка. Предполагается, что RHEL/CentOS 6.x использует SysV, а не systemd.

  - name: install rhel sysv supervisord init script
    copy: src=etc/rc.d/init.d/supervisord dest=/etc/rc.d/init.d/supervisord owner=root group=root mode=0755

  - name: install rhel sysv supervisord sysconfig
    copy: src=etc/sysconfig/supervisord dest=/etc/sysconfig/supervisord owner=root group=root mode=0640

  - name: enable sysv supervisord service
    service: name=supervisord enabled=yes

  - name: start supervisord
    service: name=supervisord state=started

ВАЖНО Множество пользовательских сценариев инициализации завершатся неудачно с Ansible и SysV init; причина в том, что опция 'status' (статус супервизора службы) должна возвращать LSB-совместимый код возврата. В противном случае Ansible не будет знать, работает ли служба или нет, и идемпотентность не будет работать (перезапуск все равно будет работать, потому что это безоговорочно)

Здесь часть скрипта, которую я только что переписал, чтобы использовать функцию "status" в /etc/init.d/functions (вы заметите этот же шаблон в других init-скриптах, предоставленных Red Hat в /etc/init.d/

status)
    /usr/bin/supervisorctl $OPTIONS status
    status -p $PIDFILE supervisord
    # The 'status' option should return one of the LSB-defined return-codes,
    # in particular, return-code 3 should mean that the service is not
    # currently running. This is particularly important for Ansible 'service'
    # module, as without this behaviour it won't know if a service is up or down.
    RETVAL=$?
    ;;

Ссылка: http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

Если запрашивается действие статуса, сценарий инициализации возвращает следующие коды состояния выхода.

0 программа работает или служба в порядке 1 программа не работает и файл /var/run pid существует 2 программа не работает и /var/lock файл блокировки существует 3 программа не запущена 4 программа или статус службы неизвестен 5-99 зарезервировано для будущего использования Использование LSB 100-149 зарезервировано для использования в распределении 150-199 зарезервировано для использования в приложении 200-254 зарезервировано

Ответ 2

Ниже фрагмент кода создаст службу в CentOS 7.

Код

Задания

/tasks/main.yml

- name: TeamCity | Create environment file
  template: src=teamcity.env.j2 dest=/etc/sysconfig/teamcity
- name: TeamCity | Create Unit file
  template: src=teamcity.service.j2 dest=/lib/systemd/system/teamcity.service mode=644
  notify:
    - reload systemctl
- name: TeamCity | Start teamcity
  service: name=teamcity.service state=started enabled=yes

Шаблоны

/templates/teamcity.service.j2

[Unit]
Description=JetBrains TeamCity
Requires=network.target
After=syslog.target network.target
[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/teamcity
ExecStart={{teamcity.installation_path}}/bin/teamcity-server.sh start
ExecStop={{teamcity.installation_path}}/bin/teamcity-server.sh stop
User=teamcity
PIDFile={{teamcity.installation_path}}/teamcity.pid
Environment="TEAMCITY_PID_FILE_PATH={{teamcity.installation_path}}/teamcity.pid"
[Install]
WantedBy=multi-user.target

\Шаблоны\teamcity.env.j2

TEAMCITY_DATA_PATH="{{ teamcity.data_path }}"

Обработчики

\Обработчики\main.yml

- name: reload systemctl
  command: systemctl daemon-reload

Справка:

Несложная структура плейбуков: http://docs.ansible.com/ansible/playbooks_intro.html
SystemCtl: https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

Ответ 3

Действительно, service модуль управляет уже зарегистрированными службами, как вы выяснили. Насколько мне известно, нет модуля для регистрации сервиса.

Знаете ли вы, что этот шаг можно пропустить с некоторыми изменениями в сценарии init.d? Если сценарий следует этим правилам, вы можете просто использовать service модуль для включения/запуска службы.

Ответ 4

Для RedHat/CentOS 7 (с использованием systemd/systemctl) эквивалент chkconfig --add ${SERVICE_NAME} - systemctl daemon-reload systemctl [ через fedoraproject.org ].

Затем, используя модуль systemd от Ansible 2.2 или выше, вы можете запустить службу с предыдущим systemctl daemon-reload как [ через docs.ansible.com ]:

# Example action to restart service cron on centos, in all cases, also issue daemon-reload to pick up config changes
- systemd:
    state: restarted
    daemon_reload: yes
    name: crond

Основываясь на моем опыте, параметр daemon_reload также можно использовать и в общем service модуле, хотя он не документирован и может не работать в системах без системы:

- service:
    state: restarted
    daemon_reload: yes
    name: crond