So let's do a quick recap so far.
So our projects are better controlled with additional governance, with
some settings to ensure playbook consistency. And all of this is done
from one central place, which is the Project option under the Resources
section in the UI. We have selected update revision on launch to remove
playbook inconsistencies.
We now have our playbooks under source control, which is much better
when you have more than one person automating.
We have stored our playbooks on GitHub and also use a personal
access token for additional granularity.
This has allowed us to implement additional options while
connecting to GitHub. So now it's time to move to inventories,
and we have several inventory types to suit your automation
requirements for your managed assets.
So in Tower, an inventory is very similar to the Ansible Core inventory.
So in its most basic form, an inventory provides host information to Ansible
so it can trigger the tasks on the right managed assets.
These may be containers, Edge devices, or even network nodes.
So in traditional and non‑dynamic environments,
this static inventory would be sufficient.
However, as we start to expand our use case of automation,
we need to transition to, let's say, more effective methods of gathering
the ever changing environment details, and this is where dynamic
inventories and smart inventories come to play. A prime example of using
a dynamic inventory plugin is to gather inventory information from a
cloud provider or a hypervisor, and Ansible Tower has a built‑in dynamic
inventory support. So you don't need to edit configuration files or
install additional Python modules that you may have needed to do with
Ansible Core.
So with a dynamic inventory, we can auto populate the inventory with
information from a source of truth, such as a public or private cloud
provider. Public cloud provider inventories could include AWS,
Azure, Google Cloud platforms are all supported. And then for your private
cloud inventory we could use VMware or OpenStack, or other systems such as Red
Hat Satellite or even custom scripting is supported.
So in AWS Cloud environments, organizations
commonly use EC2 for their workflows.
However,
managing an inventory for all of your instances running in AWS Cloud,
when done manually, will be problematic and time consuming. Using AWS
Identity and Access Management interface, we can now get programmatic
access to our AWS account.
Then with Ansible Tower, we can use this IAM credential to build
inventory and execute automated tasks on our AWS account, and we
will demo this in just a moment.
Then we have smart inventories, and I really am a big fan
of how granular you can get when creating inventories
when using smart inventories.
Smart inventories are populated by Tower,
starting with the host present in other inventories by
filtering them with specific smart host filters.
The smart inventory builds host caching, which allows your user to run
playbooks based on facts of the host, which are pieces of information on
properties related to them that are gathered by Ansible when you run
playbooks. We can pull the host inventory from any source,
including public or private clouds, or even a local CMDB.
This can be incredibly useful for dynamically creating inventories
with a specific type of host based on a filter and save the need
for manually creating lots of different groups, or worse, having to
add the host multiple times.
I often use this filter based on OS distribution and IP
subnet ranges, so when a host matching the filter based on
the distribution of, for example,
Linux Rocky or a subnet range that I specify, gets
pulled into my personal inventory.