Construct a simple playbook - Ansible Tutorial

- [Instructor] I know in the previous chapter I said I wasn't going to cover the basics, but the data in me compels me to at least level set with a simple playbook. After this, I promise I'll try and keep things more advanced. This playbook will simply be adding a user to my Rocky 9 server. Both my Ansible host and the host I'm managing via automation are both Rocky Linux servers, though they can really be any flavor of enterprise Linux if you want to follow along with these tutorials. I'll start by adding my customary three dashes. One, two, three. Now I'll give my playbook a name. Keep in mind that often a name portion is optional, but you should always add one and be verbose here, - name: A simple playbook to add users to a Rocky host. I'll now add my hosts. In most environments, this option is left as all, which is a group that represents all hosts in an inventory. Admins running the playbook will then use the --limit option that will narrow down which hosts specifically I want to operate against. This can be useful if you don't want anyone to have to modify the playbook to change which hosts are chosen. It could, however, be a bit dangerous because if the user forgets to add the limit option, it will operate against everything in the inventory. For cases like this, I have a special task that is attached to the beginning of some playbooks that will check and ensure that a limit option was utilized, and if not, it will stop the playbook run. Having said all of that, for this course where I'm only operating against a single host, I'll just specify it. Two spaces, hosts: LL-rocky9-01. Now we'll turn off fact gathering, which runs by default. Fact gathering pulls variablized information from the host that can be used for automations. For each host, this adds some additional processing time. Thus, if it's not needed, it's best to turn it off. This is done with gather_facts: false. You'll now notice that I'm going to add a VAR section. Even though I don't use it in this playbook, I almost always utilize variables, so it's something of my standard to go ahead and add it, which will make sense when I cover it more in the variable section later, vars:. Now I'm on to my first task. I'll start by adding my task section indicator, tasks:. Now the first task, for me at least, always starts with a name, - name: Add Users to the Rocky Host. Next, I'll use the Fully Qualified Collection Named, or FQCN, for my module. It's not strictly required when it is a built in module as they come packaged with Ansible Community, but I like to standardize on how I create my playbooks. So when FQCN is something I always employ, ansible.builtin.user:. Now we'll add the name and state parameters, name: test1 and state: present. Last, I'll add a task level parameter. This is a setting or option that applies to the task and is independent of the module. This means I can use the same parameter with pretty much any module. In this case, it's the become option. Become tells Ansible to perform privilege escalation for this task. In Windows, this would be run as administrator, but in my Rocky host, it indicates that this task should be run with the sudo option. So same precedence level as the module name, become: true. Note that you can tell it's a task level parameter because it's spacing is in line with the module name as well as the name option. I'll now save the file and fire off the automation from my Ansible server with ansible-playbook -i and I'll specify the inventory file and then the name of the playbook, simple-playbook.yml. Excellent, I can see that it's added the new user.