Let's take a look at that rigid directory structure I mentioned.
You're going to need a root level folder for each role.
You'll find that Python naming conventions are normally used here in Ansible,
so we've got install_sql_server with underscores.
And you don't have to populate every one of the subfolders.
There's defaults, files, handlers, as you can see.
And each one has a file called main.yml.
Now, some of the subfolders, you can change the name.
But I would recommend you do it exactly like everyone else does.
No need to buck convention.
The reason why this is such a rigid structure is to make it easy
for Ansible community members around the world to share roles
because you have such a strict schema here.
All right.
So we can create default variables at the role level and populate those.
Files, this is for,
you may have static website artifacts that need to go
into the configuration management.
You might have an Azure Bicep deployment template, whatever
file content that you'll need to invoke,
it could be an installer. Handlers are used to pick
up notifications from other tasks.
Meta is a place to document dependencies.
Very importantly, we've got a README markdown file where you don't have to,
but you really should document the role.
Tasks, this is the main thrust of the role.
This is where you're decomposing what would normally be N number of tasks in a
play in a playbook. Here you're making them much more atomic,
but it's the same exact YAML syntax that we would use in playbooks themselves.
We can integrate with Jinja2 templating in order to
dynamically create and edit files.
In this example,
Jinja is going to help us create a personalized SQL Server
INE config file or INI rather config file.
And we can do unit tests as well.
So that is a lightning round review of the role directory structure.
More on this in the demo.