Tasks are the smallest units of action that you can automate using Ansible Playbook. Gameplay manuals often contain a series of tasks that serve a goal, such as setting up a Web server, or deploying an application to a remote environment.
Ansible performs tasks in the same order as they are defined in the game manual. Before automating a program, such as setting up a LEMP server, you need to evaluate which manual steps are necessary and the order in which they are done to get all the work done. You will then be able to determine which tasks you need and which modules you can use to achieve your goal in fewer steps.
The _ module _ provides shortcuts to perform operations that you would otherwise have to run as raw bash commands. These modules are also often used to abstract commands from different operating systems.
When you created your first PlayBook in the previous section of this tutorial, you defined a task and used Debug to output a message. Let’s look at that game manual again. You can use the cat command to print the contents of the file for inspection.
cat ~/ansible-practice/playbook-01.yml
Copy the codeThe Playbook contains a single task, printing a message in the output of Play.
~/ansible-practice/playbook-01.yml
---
- hosts: all
tasks:
- name: Print message
debug:
msg: Hello Ansible World
Copy the codeTasks are defined as a list called Tasks, within a game, at the same level as the hosts directive that defines the goal of the game. The name attribute defines the output to be printed when the task is about to be executed.
The sample task calls the Debug module, which allows you to display messages within a game. These messages can be used to display debugging information, such as the contents of variables or the output returned by a command.
Each module has its own set of options and properties. The debug module wants to have a property called MSG that contains information to print out. Pay special attention to indentation (2 Spaces), because MSG must be a property within debug.