At this point.
We all know that the playbooks in Ansible are written in YAML format.
So in this video there are a few important things to remember when we are writing our playbooks in YAML
and the syntax that we should follow when creating YAML files.
First thing is, all tasks in YAML are executed in sequential order.
If you want a task to be executed first, it has to be written in the first order.
Then each task that you want to be executed is processed one at a time.
So just like a batch shell scripting, if you are familiar, it goes through the first task and then
it goes to the second and third and so forth.
Indentation in YAML file is extremely important.
A lot of people will experience this issue that when you do not have the right indentation in the GMO
file, it won't execute.
So you need to know how many spaces you have to define, where you have to define those spaces.
By the way, as we go through creating simple.
YAML files.
We will know exactly about the indentation then a no tabs and yaml file.
Yes.
Please do not use tabs.
Then you are creating yaml file while you are using the editor.
Now maybe you are using a different editor which allows you to create or run tabs, but then it converts
to spaces.
Then it's fine.
But when you are creating YAML files using VI editor or VM editor and Linux, then do not use tabs.
Only use spaces.
Yes.
It goes along with the first one.
What?
I said do not use tabs.
You should always use spaces and that spaces should define our indentation.
Then empty lines that have no value.
So if you have one empty line to empty line, it doesn't make a difference.
Just like a bash shell script.
When you create empty lines, it has no value in your execution of your task.
File extensions is usually dot by QML or dot by a HTML.
Now, if you do not have a file extension that is still fine.
The file or the playbook will be executed.
But it is a good practice that you create your YAML files with extension dot html or dot by a HTML.
All right then.
There is no difference in double codes or no codes for a task name.
So when we define a task name, every time we write a playbook or rewrite a play, a task name has to
be defined.
Now, you will notice maybe when you do a search online or you go through a certain other resources
that certain people have double codes around a task name and certain people don't have codes.
That is fine.
You could use double codes or not, it will still execute.
Then a Jammal playbook files can be placed anywhere on the file system as long as they are being executed
with absolute path.
Yes.
So our yaml home directory is sorry.
Our ansible home directory is slash root.
Sorry.
Slash at c slash ansible.
So you can keep all your playbook or yaml files in that directory.
That's a good practice, but if you wanted to keep those executable files somewhere else, that is still
fine.
But when you run it, you have to run it with the absolute path.
All right.
When a flat file is written in YAML format to execute certain tasks or place, then it is called a playbook
inside of a playbook.
The format that we use or the code that we use that is in YAML syntax.
But once it's created and saved it is called a playbook.
There is no need to modify file permission.
Yes.
As you notice, if you have written bash shell scripts, you will have to give it permission, executable
permission at the owner level, group level or others level, which is the x x x.
But in a yaml files or playbooks, you do not have to give those executable permission.
You can leave it as a flat file or the read executable files.
That's fine and you do not need executables, so you do not have to use the change mod command to define
the special permission for your file.
So anyway, these are these were the few important things that you should know and remember before you
start creating your playbooks in YAML format.
So the very first thing you would do when you log into your Linux system, then you use a bi or editor
and then you specify the name that you wanted to choose for the file.
So here you start via editor, and in order to define that it is a YAML file, you have to type it in
hyphen, hyphen, hyphen in the very first line.
This is what defines that.
It says yaml file.
Once this is defined, then you put in spaces and put in the name of the playbook.
This is the name of the entire playbook as to what playbook is exactly doing.
Then you put down the host.
If you notice, host is right below, exactly below the name.
Make sure there are no additional or less spaces.
It has to be right below the name.
And this host defines where you want to run this playbook or which host you will be running this playbook
against.
Then you have another syntax or parameters in the GMO file is to become which states that run as a different
user.
If you type it in yes, then it means it will.
You will have to define which user you want to run run it as.
So in the second fourth line you define become underscore user root.
Now you do not need to define become yes or become user.
Which type of user?
If you take it out and then you run this playbook as a root, then it will run it as a root.
But if you run it as a regular user, then it will run a regular user.
This is only defined when you are running as a regular user and you want it to run as a root or vice
versa.
All right.
Next thing you notice, here is an empty line.
And we are starting our tasks after the empty line.
Empty line, once again, does not make any difference.
And the task is a right below where the be or become is the indentation in the YAML syntax format matters
a lot.
The task is where you declare the task.
You're telling the playbook.
Okay, playbook.
Now this is what I want you to run or this is what I want you to do.
And the playbook says, Okay, what is that?
Then you have to define the name of that play and the name is I want you to install Apache HTTP.
And it's just a name.
It's nothing executable.
It's just a defining the name of the task.
Look at the task, the T right below the T, that's where we put in the hyphen space.
Then the name.
You cannot move this on the left or to the right.
Because it will cause problem when you're going to execute it.
So indentation matters.
Then it's saying, okay, you want me to run the task?
And the name of the task is Install Apache Oak.
But what are we doing?
So you're telling it, use the module.
Yum.
Run task modules.
Yum.
To install this HTTP feed package.
All right, perfect.
What is the name of the package that you wanted to run as using the module?
Yum.
That would be a HTTP feed.
Now, this is the exact name that you will use as if you are installing yum, install http or yum,
install anti PD or yum install any package name.
So that package name has to be the exact same name that you would install it with DNF or Yum!
All right.
You're saying this is the name of the package.
Perfect.
Next thing is state.
Now, I.
I'll go and and check that package.
I'll get the package.
Now, what do you want me to do with it?
With that package?
Well, when you define the state, followed by the present, it means what to do.
And we are saying present, meaning install.
Now there are different type of states in a package which you could get from the documentation, of
course, which will cover in many, many of the playbooks.
So that's what the task will do as one of the task.
It will get the package and it will install a HTTP package.
Beautiful.
Now, do you want to do anything with this package?
Once that package is installed, then yes.
I want you to do.
The task within that main task, of course, and this is the second task name.
And in the second task I want you to use the module called service, and then the name of that service
is a HTTP feed.
And what do you want?
We want the playbook to do you want the player.
So you want that package to be started.
So this these are two tasks that are defined within the same one big task of a HTTP.
You can create additional task if you want to install another package, but that will be in a different
indentation.
All of these modules.
If you are thinking Enron, hey, how would I know which state to use and what package to use, or what
are the different modules that I could use?
Well, as you're going to go through the module.
And creating ansible playbooks.
You will learn just like as if you are learning a new language or a programming language.
The more you do it, the more you learn about it.
So if you go to this documentation.
Exactly dockside ansible dot com.
I already have that open for you in my firefox.
This is the address and here these are the lists of all the modules that are given to you out of the
box by Ansible.
So if you do control F to find your module, you'll see right here is the Yum module and you click on
it.
You will see all the parameters that can be used against that Yama module.
So in our example, we are using parameter state.
And the choice that we are using for state is present, which means the package, the defined package
has to be installed.
And in the second task, we want the package or that service of that package to be started.
So for that, you have to go to the service module.
This is the module.
So we'll go back and do a find on service.
Here is the service module.
You click on it, you go to parameters.
And the state that we define in our example is started, which means to start up the service.
So you could, you could get all the different kind of helps from this documentation whenever you want
to define a module and you should spend some time to go over or skim through the list of all the modules
that that are available to you and what are the different parameters that you could define?