In this lesson, you will learn how to use the Ansible service module and other Ansible modules such as systemd, reboot, at, cron, etc to manage the boot processes and schedule tasks in Linux.
The Ansible service module is used to manage services on the managed hosts; such as starting, restarting, reloading, enabling, disabling services, etc.
Of course, one can use the”ansible-doc service” command to see other arguments/options that can be used with the service module.
The playbook below is an example of how the service module can be used.
*create a playbook
[lisa@drsdev1 ansible]$ vi service.yml
--- - name: restart services hosts: hqsdev1.tekneed.com tasks: - name: start the firewalld service service: name: firewalld state: started - name: stop the nginx service service: name: nginx state: stopped ignore_errors: true - name: enable the firewalld service service: name: firewalld enabled: yes - name: restart the firewalld service service: name: firewalld state: restarted - name: reload the nginx service service: name: nginx state: reloaded ignore_errors: true - name: stop the httpd service service: name: httpd state: stopped
In the playbook above, the first task will start the firewalld service, the second task will stop the nginx service and ignore any errors, the third task will enable the firewalld service, the fourth task will restart the firewalld service, the fifth task will reload the nginx service, and the sixth task will stop the httpd service.
*Run the playbook
[lisa@drsdev1 ansible]$ ansible-playbook service.yml
Just like the service module, the Ansible systemd module manages systemd services on the managed host. However, the Ansible systemd module offers more configuration options than the Ansible service module.
The systemd module is specifically designed to manage systemd-related services
The examples below are the ones extracted from the Ansible systemd manual page.
EXAMPLES: - name: Make sure a service is running systemd: state: started name: httpd - name: stop service cron on debian, if running systemd: name: cron state: stopped - name: 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 - name: reload service httpd, in all cases systemd: name: httpd state: reloaded - name: enable service httpd and ensure it is not masked systemd: name: httpd enabled: yes masked: no - name: enable a timer for dnf-automatic systemd: name: dnf-automatic.timer state: started enabled: yes - name: just force systemd to reread configs (2.4 and above) systemd: daemon_reload: yes
The Ansible reboot module is used to reboot managed hosts. The reboot module waits for the managed hosts to come back online before it continues to respond to commands.
For Windows systems, the win_reboot module is used instead.
An example of using the reboot module, extracted from the manual page is seen below:
EXAMPLES: - name: Unconditionally reboot the machine with all defaults reboot: - name: Reboot a slow machine that might have lots of updates to apply reboot: reboot_timeout: 2600
Tasks can be scheduled with the use of at or cron modules. Let’s see how to use these modules to schedule a job with examples.
The at module is used to schedule tasks that need to be done just once (a one time job) and not repeatedly.
The playbook below shows how to use the at module to schedule jobs.
[lisa@drsdev1 ansible]$ vi at.yml
--- - name: schedule a task hosts: hqsdev1.tekneed.com tasks: - name: schedule a task with at at: command: userdel -r anthony count: 30 units: minutes unique: yes
The options used are:
command: The command option is used to specify the command/job that will run. In this case, the job will delete the user, anthony.
count: The count option represents the count of units. The count option has to be used/run with units. It simply means that the job should run in 30 something, in our case 30 minutes from now.
units: The unit option is used to specify the time value. Units can be minutes, hours, days or weeks. In this case, the unit is in minutes, hence, the job will run 30 minutes from now.
unique: The unique option, as the name implies, unique, will not make a job run or added if that job is already present or running. The default option is false. In this case, it is set to be true. Hence, if this type of job is already present/unique and you try to add this same type of job, it will not be added.
*Run the playbook
[lisa@drsdev1 ansible]$ ansible-playbook at.yml PLAY [schedule a task] ********************************************************** .............
*Verify the configuration, of course, after 30 minutes
[lisa@drsdev1 ansible]$ ansible hqsdev1.tekneed.com -a 'cat /etc/passwd' ..............
The Ansible cron module is used to schedule tasks that need to be done perpetually.
An example of the playbook below shows how to use the cron module.
[lisa@drsdev1 ansible]$ vi cron.yml
--- - name: schedule a task hosts: hqsdev1.tekneed.com tasks: - name: schedule a task with cron cron: name: "append date" user: root minutes: 37 hour: 12 job: "date >>/root/latest-date"
The option used are:
name: This option represents the name/description of the job. In this case, the job name is “append date”.
user: This option represents the user for whom the cron job is going to be installed. In this case, the cron job is going to be installed/run as the root user.
minutes: This option represents the minutes when the job will run; ( 0-59, *, */2, etc ). The default is (*). In this case, the job will run in the 37th minutes
hour: This option represents the hour the job will run; ( 0-23, *, */2, etc ). The default is (*). In this case, the job will run in the 12th hour.
job: This option represents the command that will be run or executed. In this case, the command will append the date output to the file, /root/latest-date file.
In summary, at 37 minutes past the 12th hour, the job will be executed.
Other examples extracted from the manual page are shown below:
EXAMPLES: - name: Ensure a job that runs at 2 and 5 exists. Creates an entry like "0 5,2 * * ls -alh > /dev/null" cron: name: "check dirs" minute: "0" hour: "5,2" job: "ls -alh > /dev/null" - name: 'Ensure an old job is no longer present. Removes any job that is prefixed by "#Ansible: an old job" from the crontab' cron: name: "an old job" state: absent - name: Creates an entry like "@reboot /some/job.sh" cron: name: "a job for reboot" special_time: reboot job: "/some/job.sh" - name: Creates an entry like "PATH=/opt/bin" on top of crontab cron: name: PATH env: yes job: /opt/bin - name: Creates an entry like "APP_HOME=/srv/app" and insert it after PATH declaration cron: name: APP_HOME env: yes job: /srv/app insertafter: PATH - name: Creates a cron file under /etc/cron.d cron: name: yum autoupdate weekday: 2 minute: 0 hour: 12 user: root job: "YUMINTERACTIVE=0 /usr/sbin/yum-autoupdate" cron_file: ansible_yum-autoupdate - name: Removes a cron file from under /etc/cron.d cron: name: "yum autoupdate"
Like I mentioned during the Ansible ad hoc lesson, the command module is the default module that is used whenever one runs ad hoc without using the -m option to specify any module.
The shell module takes the command name followed by a list of space-delimited arguments. It is almost exactly like the command module but runs the command through a shell (/bin/sh) on the managed hosts.
For Windows targets, use the [win_shell] module instead.
Watch This Video On Using Ansible Service Module & Other Related Modules To Manage Boot & Schedule Processes
RHCE Exam Practice Question On Using Ansible Service Module & Other Related Modules To Manage Boot & Schedule Processes
Ansible service module
Your feedback is welcomed. If you love others, you will share with others.