Welcome back. In this lesson, I'll be talking about roles.

Roles are a key feature for making reusable code with Ansible. Roles allow you to take common functionality and bundle it up into it's own unit and that unit is called a role.

The playbook in the previous lesson combine tasks to install the LAMP stack as well as the application. Creating a LAMP stack is a fairly common engineer requirement which means there should be a LAMP role instead which is responsible for getting all of the LAMP components installed. If you have multiple teams in your company that all use LAMP for different applications, they could share this LAMP role because it installs the base components and doesn't care about your application.

Let's migrate the LAMP functionality to a role. Roles have a specific folder structure that Ansible expects to see. While you can create this folder structure manually, an easy way to do it is to use the Ansible Galaxy command. Ansible Galaxy is a way to create and share roles and while it's outside of the scope of this course, I'll show you how to use it to create the role structure.

First, I'm going to change directories into the directory shared between my Mac and Vagrant, and now, I need to create a roles folder to store any custom roles and I'll change directories into that and here's where I'll use Ansible Galaxy to create a role structure. To do that, I'll use the ansible-galaxy executable and the init subcommand and then the final argument is the name of the role I want to create. This is going to take a moment, though, when it's complete, I should see the full structure that's been created by running the tree command.

Okay, it creates directories for default settings for any files that we might need to use for the role, for nay handlers, for metadata, for tasks, templates, tests, and variables, and it creates placeholders in these directories. Notice here, there are a lot of files named main.yml and that's because Ansible expects that to be the name of the entry point for each section. What I mean by that is, when Ansible looks for your tasks inside of a role, it looks for the task folder and then the main.yml file inside of it, and the same goes for things like handlers, defaults, variables, et cetera.

Let's head over to the text editor and start moving the LAMP tasks into its new role. I'll start up with the defaults. These are variables that can be overridden by adding a variable of the same name just about anywhere else. I mentioned variable precedence in a previous lesson. Defaults are the lowest level of that making it easier to override them.

Next, I'll move the handler into the main.yml file that is in handlers directory. So, I'll copy the handler from the existing playbook and paste it in and I'll fix up the indentation and then I'll save the file. Next, I need to move the tasks that are responsible for setting up the LAMP stack into the main.yml that is in the tasks directory.

First, I'll clean up the indentation. Remember, yml is sensitive to whitespace and indentation and now, I'll get rid of the hard coded packages and services, the variables that I added to the default will allow me to replace all of these list items with a variable name. This will enable anyone who uses this role to override these adding and removing packages and services as needed. I also need to add a notified property to the last item so that it triggers a restart of the Apache Server.

Okay now, to test this out, I need to go back to the app.yml file. I need to remove all of the LAMP tasks and the handler. Okay now, with these gone, the playbook doesn't have any idea about our new LAMP role. So, to add that, I need to add a property called roles and I'm gonna pass it a list item of LAMP. Now, if I run this, everything should still work. It's going to take a moment so I'll fast forward to when it's complete, and everything was successful. So, I'm gonna refresh the page so that we can make sure everything works and it's loading as expected.

With this LAMP role, you can now include it whenever you need it and it's going to install Apache and MySQL. It makes for a great way to share common functionality across teams. To paint a clearer picture of the value of roles, imagine you have a standard Linux configuration that all servers are supposed to use. Maybe it includes installing the correct versions of services and tools as well as applying software updates, installing security patches and disabling services with known security issues.

Ansible will allow you to encapsulate all of these functionality into a role. So, that role might be named something like base settings and then you could start using that server for whatever you need. Maybe the next step is to to run a web server role and after that a more custom role for installing your application. Or here's another scenario, imagine that you need to create a very specific cloud infrastructure before you can start running your role to install your application. Ansible has modules to automate all of that and if you break the functionality out into generic roles, you get a lot more reuse from the code.

Let's go through and turn the application deployment process that we had in the previous lesson into it's own role. So, it starts out again with Ansible Galaxy and I'll create a role named webapp and now, it's time to move the default variables. This is the same thing that I did with the LAMP role. The goal is to have the variables set at the defaults so that they can be changed easily by anyone using that role.

Next up, I need to move the tasks. I'm going to move them into three separate yml files. One is going to be for the database, one will be for the application and the other is going to be for the site configuration. This isn't a requirement. They could go all into the main.yml file. However, I wanna show you that it's possible to break them out into separate files so that no one file becomes too complex.

And so, I'll keep copying and pasting the tasks from the existing playbook into the files that I've created for them. And I'll clean up the indentation as I go, and then once this is done, I can start cleaning up the current playbook. The playbook is going to be pretty empty by the time this is done and if you want a playbook to include a role, it needs to be added to the roles list.

So, I'm gonna add that new webapp rule to my app.yml file. All right, I've forgotten two things. The first is that I need to copy the Apache configuration template into the templates directory for the webapp role. Doing that will ensure that Ansible knows where to find that template.

The second thing that I forgot is that I need to add the include statements to the main.yml file for the tasks. That way, it'll include those three files, otherwise, Ansible won't know what tasks to run because it doesn't understand that there are three separate task files. Okay now, it's time to test. So, I'm going to fast forward to the end of the process and everything was successful.

So, breaking things down by role makes it easy to compose playbooks from reusable bits of functionality. Okay, that gonna wrap up this lesson.

In the next lesson, I'll show you how to handle errors and how to do some basic debugging. So, if you're ready to keep learning about Ansible, then let's get started with the next lesson.