EX294 Red Hat Certified Engineer RHCE – Exploring Core Components of Ansible Part 4

10. Ansible Ad-Hoc Commands-Part 2

Now we are on ensable control node and I am logged in as root. Before we proceed further with the execution of example ad hoc commands I would display inventory file. I will use tail to display only last ten lines of inventory file. So here I removed the host variables we defined for am m host one earlier. Also I removed group variable. Now we have two groups my group one and my group two. My group one containing two managed nodes m host one and am host two. My group two containing two nodes Mhost three and Mhost four. Now we’ll verify connectivity using ping module from ansible point of view we’ll execute ansible all m ping. We know we can do this using ping module so everything is okay now. Next I will display help for an siebel command line and I will pipe the output to more command to have Pagewise output. We already know basic syntax of ansible ad hoc command.

Here we’ll discuss about optional arguments which can be provided to ansible ad hoc command. We will discuss only important options we need to know at this moment as we progress through the course, we will be discussing about more options. So we already used dash list hosts to list inventory nodes in a group or to list all nodes defined in inventory file. Next important option, we also used version which displays ansible version in use and also it displays ansible config file which is taken into account by ansible in case you have multiple config file defined at multiple locations. We also used option to supply arguments by using different variables to modules. We supply arguments to modules by using dash e option. Dash e option can be used to provide extra variables to ensure addo command. We’ll discuss about this later on f to provide forks or we can also use long options forks in this case or in this case instead of dasha, you can also use dash arcs.

So here we know as defined in ansible config file, default forks is set to five. But we can use f option to override default behavior defined in ansible config file. Next, by using I option, we can tell ansible to use the inventory file other than default inventory file. By using Dashl option, we can limit target systems to be used in ansible ad hoc command. We’ll discuss this with one example dashm option to specify module name. We know about this o to condense the output. Now here we have privileged escalation options. We can use these options to overwrite default behavior which is defined in ansible config file. By using dash dash become method we can overwrite default behavior defined in ansible config file. We know default is pseudo.

We can display different choices by using this command. However, at RSCE level you will be using only pseudo. You don’t need to know about other choices. By using become user, you can overwrite default value which is root configured in ansible config file. You can set for example dash dash become user to Apache. But again I would say at RC level we would be using default value of this variable or option. But this is just for your knowledge by using dash capital k option which is equal to become underscore ask underscore pass in ansible config file which is set to false by default. So what does it mean? In case remote node is configured with privilege escalation for some user, but he needs to provide password. But without providing password it’s not possible to escalate privileges. In that case you can use capital k option to tell the ansible ask for per village escalation password. If you don’t use this option, ansible simply will give some error.

Although we have pervillage escalation configured on the remote node, but in case per village escalation is configured on the remote node for some user and it’s possible even without entering password. In that case everything would be okay. We’ll discuss more on this while doing tasks b or dash dash become this is short option, this is long option. Again to override default behavior in ancient config file we can use this. So in case become is set to false enhanceable config file. Still we can enable it by using dash dash become with ansible ad hoc commands. Now, here we have options related to connection. So I would explain only important one. Here we have you or user which can be used to specify remote user. We know by default remote underscore user directive is not used as per Ansible config file. Or I would say by default this is set to none. In this condition Ansible uses current user to connect to remote nodes. But we can override this behavior by specifying this option using you or dash dash user and providing remote user we want ansible to use to connect to remote nodes.

We can use this option with ansible addo command or with ansible playbook to tell ansible to prompt for the connection password in case passwordless login is not configured without this option a passwordless login is not configured, ansible simply will give some error. Now I will clear the screen. Now I will display ansible documentation for command module. Here you can find all the information about command module. The command module takes the command name followed by list of space delimited arguments. So here important thing to be noted. Command module cannot be used where variables and the operations involving input output redirection pipe ampersand are involved. Because while using command module commands are not processed through the shell. If you need to use commands involving these operations, you must use shell module. However, for this exam you would be using command module only to display or verify configurations on the remote nodes. And this will be very helpful. So here we have different optional arguments which can be provided to command module using these options. Or I would say variables, but they are more important in case of playbooks. We’ll discuss about them if needed. While discussing playbooks, I would tell about this option. Chrdir change into this directory before running the command.

By using chrdir, you can tell ansible to execute some command or remote node after changing to directory path as specified by this option or variable. So here in the end, you will find some examples how command module can be used in case of player books. We’ll come to this later on. Now I will quit. I will clear the screen. Now we’ll execute our first example ado command using command module. Ansible target is m host one as for example m to provide module name, a to provide command as argument to command module. We’ll use double quotation marks to enclose the argument. Here I will type cat, forward, slash etc hosts.

So this will display host file on mhstone return the output on ansible control node. So here we have the output, I will clear the screen. In similar way you can use command module to display configurations on the remote node. And this is very helpful on the exam. For example if you want to display FS tab file on the remote host just to verify if the desired entry is there in the file. Or note, you can use command module to display FS tab file. So here we have the output, so we are connected as root. So we have all the permissions to display FS tab file. In case you are using normal user to execute and sibling command, you must use per village escalation to display this file. In similar way, if you need to display same file for all managed nodes, you can use all. Here it will take some time. So here we have output for all. Now we’ll execute same command. But this time I will use s to specify fourths. I will use one so this will override default behavior. You will see the difference here.

Here you would see output from the different nodes one by one. Because we have set forks to one. So in this way by using additional option with ansible addo command, you can override default behavior defined in ansible config file. Now Dashl option to limit the target hosts I will use amhost one. Here we have output for amhost one. Although we have here old defined in target, still we can limit the target by using Dashl option and supplying here the target. Here we can provide group name as well. So in this case you don’t need to type the same command again. So this is the advantage of using this option. Now I will clear the screen. Now we’ll move to our next example using copy module to copy file. I will display and see by documentation for copy module.

So here you have all the information about copy module. The copy module copies a file from the local or the remote machine to a location on the remote machine. The example we discussed already is the example where we are copying from the local machine which is ansible control node to the target node. But it’s also possible to have source and destination both on the target. I will explain how we can do that. So here we have different options which can be used to provide different arguments to this module. Options with equal to sign are mandatory, with dash they are not mandatory. Again, we’ll discuss only important one we need to know at RSE level. However, we can always come back to this during this course whenever we need to know something extra. So here we can use content option or content variable to provide input as a string which needs to be copied to some destination file. We can use either SRC to specify source file or we can use content in place of SRC just to provide string to be copied to some destination file so here we can see dest with equal to sign which is mandatory. Destination can be file or directory depending upon the operation so in case sources directory destination must be a directory because your intention would be to copy all the files from source directory to the destination directory group by using group option or variable you can specify name of the group that should own the file or directory. This is similar to crown actions we can use mode to set the permissions on target file or directory.

We can use owner to name the user that should own the file or directory. This option is important. Remote underscore SRC having already said, we can copy from the remote source to the remote destination. So by default, if you don’t use this variable source will be taken from local node which is ansible control node in our case but if you set this variable remote underscore SRC to yes then source will be taken from remote node only then we have more options related to Se Linux we don’t need to discuss all of them now. So here is SRC. We discussed about this already. In the end, again, we have some examples showing how this module can be used in playbooks to perform different tasks. So this is very useful. Then you will be working with Playbooks. Even you can get indication from these examples how we can use different options or variables to supply arguments. I will quit now. I will clear the screen. Now we’ll execute our next example. Ad.

Hoc command ancible target is M host two, as, for example, M to specify module, which is copy A. To provide module arguments. Again, we’ll enclose the arguments in double quotation marks. Don’t forget this we’ll provide source. We know. We need to copy host file from ensable control node to dest under temp directory to destination file under temp directory with name hosts underscore BKP. In case this file is not existing, same will be created. Same is in. Our case. It will take some time. It’s done. So here you can find bunch of information which is very useful. In case you will execute same command again. You will see the output in green. This is because of remote node is already in the same state as we wanted it to be. Now, if we execute same command again and again we have again the same output in green. No changes will be done on the remote node.

Because they are not required anymore. Changes are already done with first command. Now I will clear the screen by using Command Module we will display this file we know to Command Module we provide command as argument. So this is all we need to do. So here we have output. So this means our file is copied successfully here, you might have noticed output is shown in yellow color. Although no changes are made on the remote system. We are simply displaying the file. This is because of in case of command module. This color is determined by return course, which is zero in this case, which means success. So in that case, it will be shown as yellow. Take this as exception. Now I will clear the screen now. Next we’ll move to our next example using file module I will display documentation for file module again. Here you can find all the information about file module file.

Module can be used for the file operations directory operations to create file to delete file, to create directory to delete directory or to create symbolic link and to create hard link and same can be deleted by using file module. So here we have many optional arguments which can be provided to this module using different options. We can use excess underscore time variable to set access time on some file. But again, here we’ll discuss only important options. At this moment, we can use group to set group ownership on the file or directory mode to set permissions on file or directory. You might have noticed these two options or variables can also be used in case of copy module for similar tasks. Owner to set the owner of file or directory. Here we see equal to sign for path path to the file being managed. So by using path option we specify path of file or directory. Which we need to manage using file module. This is mandatory option. We can use recurs to implement something at directory level. Recursively to all the sub, directory and files under this again we have options or variables related to SC linux SRC variable can be used for creating symbolic links or heard links. This will be more clear when we’ll do practical tasks related to this so here state is important option so state can be absent directory, file hard link and touch so absent to delete some file or directory when state is set to directory. So it means we are dealing with directories. When state is set to file, it means we are dealing with files. When state is set to hard, it means we are managing hard links.

When state is set to link, it means we are managing symbolic links. When state is set to touch so it means we want to change access. Time for some file or in case file is not existing, same will be created now I will move further again here we have many examples how we can use file module inside player books we don’t have any examples. For addo commands here. We’ll discuss about them while discussing player books. Now I will quit. I will clear the screen. Now we’ll execute our Ansible command. Ansible target is amhost. Three M to specify module A to provide module arguments path file to be managed we want to create file with name test under temp directory. For this case, state must be touch because file is known existing. So if we use state is equal to file, it will give error because this state can be used if file is already existing. See, we have error.

So it means state is equal to file can be used for different file operations on existing files by using state is equal. To touch we can create zero length file it will take some time so we have yellow output change so file has been created so this bunch of information is very important change is equal to true changes are done on the remote node this is destination. This is group. ID. This is group these are permissions, honor, information about Se Linux context, size of file state and user ID. Now we’ll use command module to display information about this. File. I will replace module name with command. And here we need to provide command as argument. I would use L, then file par. This will list details about this file. So we have different permissions. User owner, group owner. So this means file is existing. So you can do one thing. You can just display contents of this file.

So we don’t have anything. Now we’ll move to our next example. Using user module I will display information about user module. So, as name indicates user module is used to manage user accounts again, we have multiple options or optional arguments which can be provided by using these options or variables. Again, we’ll discuss only important one we need to know at this moment. Using comment, we can provide comment, for example, username or full name of the user to be created. We know how we can use this with user ed command create underscore home, which is default. Yes. So normally we don’t need to use this, but in case you don’t want to create home directory of user set this variable to no or false expires deals with expiry of account generate underscore SSH underscore key. We can use this option to generate SSH key for the user being created.

Group can be used to set primary group for the user. Groups can be used to assign supplementary groups to the user name with equal to sign which is mandatory username of the user to be created password to supply password for the user or to assign password to user. But password must be in encrypted format otherwise it will not work. We’ll discuss more on this later on because this is important from exam point of view. So here I would now discuss all the options we’ll move down and I will just show you again some examples of using user module in playbooks. Now I will quit. I will clear the screen. Now we will execute our last example ad hoc command on target am host four module we are going to use is user. Here we need to provide module arguments name we are going to create test user. Here you might have noticed I’m taking username as test. But in the example I shown you username as ansible we’ll create ansible user later on. So this is just for understanding state which must be set to present to create user.

We haven’t discussed about this option but this is important. One you need to simply set state to present to create user and state to absent to delete some existing user. This is all we need to do to create user. So here we are not assigning any password to this user. So we have yellow output indicating change with this bunch of information. So home directory of user already exists. So this is giving some more information. Anyway, now I will clear the screen. I will use command module to display this user. I will simply use it test. So we have user with user ID 1000 group ID primary group ID 1000. Now here if we omit this information again command and would be successful. This is because by default command module is default module. So this is all about this lecture. In next lecture we’ll.

11. Ansible Play and Playbooks

Last lecture we discussed how we can use ansible Adobe commands to perform some quick actions on the remote nodes. But when it comes to automation which is objective behind ansible ansible playbooks are very powerful feature of ansible playbooks are used for the actions which we need to do again and again for automation. Purpose novel define playbook or I would say play at basic level ansible playbook describes some configuration steps that need to be enforced on remote host. So it means in playbook we define some tasks using modules that need to be executed on the remote nodes. Ansible playbooks are written in Yamal which is humoridable and this makes ansible easy to use and understand than other programming languages. This is something we know already. So here one important thing, we can think of modules as tools, playbook sets, instruction manuals and inventory as raw material. We know we execute all the tasks using modules which are our tools. In playbook we define instructions or tasks to be executed an inventory on which tasks are executed.

So essentially a playbook contains a list of plays where each play defines instruction to perform some task on remote host. We can write a playbook comprising different plays each play with different target and different set of tasks. Now, here we have information about different sections a play can have first of all host section or I would say target section to define target of play and other directives like remote underscore user become for privileged escalation gather underscore facts in case you want to disable or enable gathering of facts. By default, facts are always gathered as defined in ancient config file. By using this directive in target section, you can override this behavior same for per village escalation and in similar way you can use remote underscore user to define the user to be used for this specific play or playbook. Similarly, we have more directives which we can use at this level. Next section is VARs to define playbook variables we are going to discuss about them in coming lectures. Next tasks section to define list of tasks to be executed. So here we define different tasks using different module to be executed on the remote nodes defined in target section. Next is handlers section.

So in this section we define tasks as we define in tasks section. The only difference is tasks defined in the handlers section are executed as ticked by successful execution of some tasks in the tasks section. I would give one example to clarify this in case we make some changes in config file of some surveys, we know we need to restart service to make the changes effective. Second example, if we add some firewall rules persistently using firewall D, we need to reload the firewall to make the changes effective. So we can define task in task section to make changes in config file and to restart the service, we can define task in the handlers section. So when changes will be done in config file as per task defined in task section. It will notify task defined in handler section to restart surveys.

So in this way, task defined in Handler section will be executed only when there are changes done in the config file with task defined in task sections. So in case you will execute playbook again and again. So config file will not be changed again and again because it will be changed only first time as per task defined in tasks section. So it means so it will not trigger task defined in handlers section to restart service which is not needed anymore. So next roles we have not discussed anything about roles yet. We have separate section on roles.

But if you know how you can create player books using roles and creating roles are easy tasks, we’ll discuss about them in separate section. At this moment we need to focus on only playbooks. How we can create playbooks to perform different system administration tasks on the remote nodes. During this course we’ll create many playbooks to configure remote systems, create user installing packages etc. Etc. This is all about this lecture. In next lecture we’ll discuss about playbook format with the help of one example.

12. Understanding Playbook YAML format with an example

Hello, welcome to this lecture. In this lecture we will understand ansible playbook format example in YAML. Having already discussed, ansible playbooks can be written in YAML format or JSON format. But most used format is YAML format. For RSE exam this is enough to know know about YAML format only. We really don’t need to know about JSON format. Here we have one playbook example having one play defined inside it. This play is defined to add firewall rule on this target system. In this example, target system is m host one and we are using firewall D module for the same action. Now first of all we must keep in mind every YAML file should start with three dashes on the top and should end with three doors in the end. In many cases you will not see three doors in the end. It works perfectly fine. But it’s always good practice to include them to indicate end of Yummy document.

Now here we have dash symbol indicating list item. We know a playbook contains list of plays. Here we have only one play in the target section. Here we have target system defined using host directive we can define single host host group. We can also mention multiple host groups separated by commas. Then here we are using become directive to enable privilege escalation at ansible level. Then we have tasks section. And here we have one task defined as list item. This symbol indicates list item. We can define multiple tasks as list item under tasks section. Now before moving further, I would like to mention one important thing about level of indentation. Level of indentation of hosts. Become and tasks must be same. Here we can see they are at same level of indentation. Then here under tasks section, name and firewall D must have same level of indentation dashpace name. Using name keyword we can specify description of task. Care space is very important.

Then here we have module name which is firewall D in this example. Then under this using different variables directives will set. We will provide different arguments needed for this task. Using port directive we are defining port as 80 with protocol TCP you must define port in this format along with protocol port colon space this is important then port in this format, this is dictionary variable format. In coming lectures we will discuss about dictionary variables. Then it will be more clear. So here idea is just to understand format of player book. Then here state directive is set to enable to add firewall rule on the firewall. On this target system if we need to remove firewall rule, we need to set state to disabled. Next permanent directive we set to yes for persistent or permanent firewall changes. This is equal to dash dash permanent we use with firewall CMD command line for persistent firewall changes. Now we know when we make permanent changes to firewall, we must reload firewall to make them effective. To reload firewall a task in a handler’s section is included.

I’ll come back to this notify keyword. Now, under handler section we have one task defined to reload firewall and we are using System D module. I know at this moment you don’t know about different directives to be used with different modules. But again I would say idea is just to understand format of playbook. Later on when we’ll execute playbooks during this course it will be more clear. Using name directive will set service to be reloaded. In this example we need to reload firewall D and using state will set reloaded to reload this service. Now here this task description is very important. This must match with the task description we specified with Notify keyword. Now, why notify keyword is used? Notify keyword is used to trigger some task in the handlers section which is required to be executed for some task in the tasks section.

For example, in this case when this task will be executed and firewall definition will be done to reload firewall, notify keyword will inform or trigger this task in the handlers section to reload firewall to make this definition effective. But here you must keep in mind when you execute the same playbook, again notify keyword will not trigger this task because this is not needed anymore. Notify keyword will always notify corresponding task in a handler section when it’s needed. Now, you might be thinking why this is not needed when we execute playbook second time. This is because during first time this definition is done and firewall will be reloaded due to this task triggered by Notify keyword.

Next time when you execute same playbook, no changes will be done on the firewall level because this definition is already done. So this task will skip. This makes sense, but we must make sure task description specified here must match description specified with notify keyword. Otherwise task will not be triggered. This is important. So this is objective of using tasks in a handlers section. Now again here I would like to specify about level of indentation. Different sections in the playbook must have same level of indentation. For example, tasks and handlers must have same level of indentation and under different sections this name keyword and Firewall D module must have same level of indentation.

But they must be indented to write than tasks in this section and handlers in this section. Again, different directives to be used to set or to supply different arguments must be indented to write than module name. But they must be at same level of indentation within the task. Here important is notify keyword must have same level of indentation as that of module name and level of indentation of different modules used throughout the playbook must be same. For example, here we have firewall D and here we have system D. So now we have basic understanding of playbook format example. It will be more clear when we’ll execute different player books during this course. This is all about this lecture.

• Category: Uncategorized