wake-up-neo.com

So erstellen Sie einen neuen Systemdienst mit Ansible-Playbook

Ich habe ein Skript erstellt, um meine Anwendung zu starten/stoppen. Jetzt möchte ich es als Centos-Systemdienst hinzufügen. Zuerst habe ich eine Aufgabe erstellt, um einen Link von meinem Skript zu /etc/init.d/service_name zu erstellen (siehe unten).

---

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

Nachdem Sie den Dienst erstellt haben, möchte ich ihn dem Systemdienst hinzufügen. Der dazu verwendete Befehl lautet "chkconfig --add service_name". Ich frage mich, ob es ein Ansible-Modul gibt, um dies zu tun, anstatt den Befehl in einer Ansible-Playbook-Datei fest zu codieren. Ich habe mir diese Seite angesehen http://docs.ansible.com/ansible/service_module.html , aber sie zeigt nur, wie man einen Dienst verwaltet, nicht einen neuen erstellt.

ansibleansible-playbook
16
Zhao Yi

Das 'Service'-Modul unterstützt ein' Enabled'-Argument.

Hier ist ein Beispiel eines Spielbuchs, von dem ich gerne behaupte, dass es wie ein Anfängerversuch aussieht. Dies setzt RHEL/CentOS 6.x voraus, das SysV verwendet, nicht 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 Viele benutzerdefinierte Init-Skripte werden mit Ansible und SysV init FAIL; Der Grund ist, dass die 'Status'-Option (Service Supervisord Status) einen LSB-kompatiblen Rückkehrcode zurückgeben muss. Andernfalls weiß Ansible nicht, ob ein Dienst aktiv ist oder nicht, und Idempotenz schlägt fehl (Neustart funktioniert weiterhin, da dies nicht unbedingt erforderlich ist).

Hier ist ein Teil eines Skripts, das ich gerade umgeschrieben habe, um die 'status'-Funktion in /etc/init.d/functions zu verwenden (Sie werden dieses Muster auch in anderen von Red Hat bereitgestellten Init-Skripten in/etc/feststellen. 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=$?
    ;;

Referenz: http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

Wenn die Statusaktion angefordert wird, gibt das Init-Skript die .__ zurück. folgenden Exitstatuscodes.

0 Programm läuft oder Dienst ist OK 1 Programm ist tot und /var/run PID-Datei ist vorhanden 2 Programm ist tot und/var/lock-Sperrdatei ist vorhanden 3 Programm läuft nicht 4 Programm- oder Servicestatus ist unbekannt 5-99 für zukünftige LSB-Verwendung reserviert 100-149 für Distributionszwecke 150-199 reserviert für die Anwendung 200-254 reserviert

13
Cameron Kerr

Das folgende Code-Snippet erstellt einen Service in CentOS 7.

Code

Aufgaben

/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

Vorlagen

/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 }}"

Handler

\ handlers\main.yml

- name: reload systemctl
  command: systemctl daemon-reload

Referenz :

30
JosephKumarMichael

Tatsächlich verwaltet das Modul service nur registrierte Dienste, wie Sie es herausgefunden haben. Meines Wissens gibt es kein Modul, um einen Dienst zu registrieren.

Ist Ihnen bewusst, dass dieser Schritt mit einigen Änderungen an Ihrem init.d-Skript übersprungen werden kann? Wenn das Skript diesen Regeln folgt, können Sie einfach das Modul service verwenden, um den Dienst zu aktivieren/starten.

1
udondan

Für RedHat/CentOS 7 (mit systemd/systemctl) ist chkconfig --add ${SERVICE_NAME} das Äquivalent von systemctl daemon-reload [ via fedoraproject.org ].

Dann können Sie mit dem systemd-Modul von Ansible 2.2 oder höher einen Dienst mit einem vorangegangenen systemctl daemon-reload starten, z. B. [ über 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

Aufgrund meiner Erfahrung kann der daemon_reload-Parameter auch innerhalb des generischen service-Moduls verwendet werden, obwohl er nicht dokumentiert ist und auf Nicht-Systemd-Systemen fehlschlagen kann:

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