web-dev-qa-db-fra.com

Comment créer un nouveau service système avec ansible-playbook

J'ai créé un script pour démarrer/arrêter mon application. Maintenant, je veux l’ajouter en tant que service système Centos. J'ai d'abord créé une tâche pour créer un lien entre mon script et /etc/init.d/service_name comme ci-dessous.

---

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

Après avoir créé le service, je souhaite l’ajouter au service système. La commande utilisée est "chkconfig --add service_name". Je me demande s'il existe un module ansible pour le faire au lieu de coder en dur la commande dans le fichier ansible-playbook. J'ai consulté cette page http://docs.ansible.com/ansible/service_module.html mais cela montre seulement comment gérer un service et non en créer un nouveau.

ansibleansible-playbook
16
Zhao Yi

Le module 'service' prend en charge un argument 'activé'.

Voici un exemple de partie d'un livre de jeu, qui, j'en conviens volontiers, ressemble à une tentative de débutant. Cela suppose RHEL/CentOS 6.x, qui utilise SysV, pas 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

IMPORTANT De nombreux scripts d'initiation personnalisés échoueront avec Ansible et SysV init; la raison étant que l'option 'status' (statut du superviseur de service) doit renvoyer un code de retour conforme à LSB. Sinon, Ansible ne saura pas si un service est actif ou inactif, et idempotency échouera (le redémarrage fonctionnera toujours car il est inconditionnel)

Voici une partie d'un script que je viens de réécrire pour utiliser la fonction 'status' dans /etc/init.d/functions (vous remarquerez ce même motif dans d'autres scripts d'initialisation fournis par Red Hat dans/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's 'service'
    # module, as without this behaviour it won't know if a service is up or down.
    RETVAL=$?
    ;;

Référence: http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

Si l'action status est demandée, le script d'initialisation renverra le suivant les codes d'état de sortie.

0 programme est en cours d'exécution ou le service est correct 1 programme est mort et /var/run Le fichier pid existe 2 le programme est mort et/var/lock le fichier de verrouillage existe 3 programme n'est pas en cours d'exécution 4 ou l'état du programme est inconnu 5-99 réservé aux futures utilisations de LSB 100-149 réservé à la distribution 150-199 réservé à l'utilisation de l'application 200-254 réservé

13
Cameron Kerr

L'extrait de code ci-dessous créera un service dans CentOS 7.

Code

Les tâches

/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

Modèles

/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

\ templates\teamcity.env.j2

TEAMCITY_DATA_PATH="{{ teamcity.data_path }}"

Manutentionnaires

\ handlers\main.yml

- name: reload systemctl
  command: systemctl daemon-reload

Référence :

30
JosephKumarMichael

En effet, le module service ne gère que les services déjà enregistrés, comme vous l'avez compris. À ma connaissance, il n'y a pas de module pour enregistrer un service.

Savez-vous que cette étape peut être ignorée avec quelques modifications dans votre script init.d? Si le script respecte ces règles, vous pouvez simplement utiliser le module service pour activer/démarrer le service.

1
udondan

Pour RedHat/CentOS 7 (en utilisant systemd/systemctl), l'équivalent de chkconfig --add ${SERVICE_NAME} est systemctl daemon-reload [ via fedoraproject.org ].

Ensuite, en utilisant le module systemd de Ansible 2.2 ou supérieur, vous pouvez démarrer un service avec un systemctl daemon-reload précédent, comme ceci [ via 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

D'après mon expérience, le paramètre daemon_reload peut également être utilisé dans le module générique service, bien qu'il ne soit pas documenté et qu'il puisse échouer sur des systèmes non-systemd:

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