- A completely different category
is Using Plugin-Based Inventory.
Let's go check it out.
So inventory can be written in any format,
which is the old format.
It's still a very common format.
The new alternative is the YAML format.
An inventory since Ansible 2.4 is managed through plugins.
The ansibe.cfg lists which plugins are used
in the inventory section,
if you're using inventory based plugins at least.
Notice that you may have never seen it
because inventory based plugins are still not very common
because the ini format is so simple and so convenient
for many environments.
Both using plugins allows Ansible
to support new inventory format
by just providing a new plugin.
So it makes it a lot more flexible.
We have the ini plugin, which is a default,
which supports old cell inventory format.
We have the script plugin
which supports old cell dynamic inventory.
Dynamic inventory, where in the in the old days
you would fetch dynamic inventory scripts
from the community websites.
There's a YAML plugin, which supports new cell YAML format.
And these are the options and you need to enable the plugins
that you want to support in your ansible.cfg.
And notice that using plugins
is preferred over dynamic inventory scripts.
Before continuing let's check out the ansible.cfg
for the current plugins that are used.
So here we are.
I'm going to show you sudu vim
on etc/ansible/ansible.cfg.
And we are going to look for inventory.
This is not the one, oops.
I want the next one and the next one.
This is what we are looking for, inventory plugins.
Inventory plugins is use the share ansible plugins
inventory, or that's just the plugins path.
What else do we have?
There we go.
We can see the inventory section right here.
This is what it should be looking like.
And you can see that the enable inventory plugins,
the default is set to host_list, script, auto, yaml,
ini and toml
and you can see these settings right here.
Do remember if you want to use plugins
you need this enabled plugins in your local ansible.cfd.
I'm just showing it here to show you what is hard coded
as a default.
And as it is coded as a default,
you don't really have to specify it
but if you want to do something specific
apart from the common inventory plugin,
you will need to open an inventory section
in your ansible.cfg to provide that.
Good, let's check out some of these formats.
So here we have an example where the ini plugin is used.
This is what we've seen throughout in this course.
So you have the group name, below the group name
which is between square brackets.
You have the list of the hosts
and you can specify Nestle groups as well
which is what we see in [Allserver:children]
where web servers and dbservers are a member of all servers.
Right, if you would be using the yaml plugin
then this is what it looks like.
So the parent level group is all servers,
children is defining the children
and we have webservers, dbservice and so on.
You can also put your variables, you can put everything
in this yaml based plugin.
Hey before you are going to work with these inventories
I do need to show you the documentation behind the plugins.
So if you use ansible.docs -t inventory -l,
we get a list,
oh, ansible-doc of course.
We get a list of all the different inventory types.
And did you know that every inventory type
has its own documentation?
So we use ini and here we can see the example
for ini based inventory,
including variables and everything
that you might want to do.
We use YAML and there you can see
what it looks like all the way to the bottom
for the YAML based inventory.
You are going to appreciate this example
because it's telling you how exactly to compose it
including the variables that you might be including
at a specific level.
And what else do we have?
Well, let's get back to the list and let's have a look
at one of the sources that is not so common.
Kubernetes for instance.
So -t inventory Kubernetes
and there we go.
We see the example that can be used
for Kubernetes based inventory.
Ooh, this is all about Kubernetes authentication
which means you are going to hand it over to Kubernetes.
That is what corresponds
to the old scripting style inventory.
And you can use some references
to other scripting style inventories as well.
Like Azure Resource Manager,
like foreman, like Docker machine,
like just a host list,
like openshift or openstack or whatever.
Now we should focus at this point on ini
in YAML based inventories.
We will see these specific inventories later.
So let's get back to the slides
and talk about inventory script conversion.
So ini based inventory is the standard,
but you might want to move over to YAML based inventory
which seems to be the future anyway.
You can easily convert using the Ansible inventory command.
So for instance, use
ansible-inventory --yaml -i inventory --list
- -output inventory.yaml.
So let me just demonstrate how to do that
based on the inventory that we are going to use later
in the windows,
in the lesson about windows.
But important, when ini-based inventory contains variables,
they maybe messed up after conversion
and you should always check
because you might have to manually fix it.
Of course you can easily avoid it
by using the approach of putting your variables
in group_vars/ and host_vars/.
Hey, I'm mentioning the recommended approach here.
I think it's time to think about the recommendation
where to put your inventory variables
because how are you going to use group_vars/ and host_vars/
if you're using Ansible tower,
then you might need to be to get back
to inventory based variables anyway.
So that is really something to think about
but more about tower in the next lesson.
For now, let's check out this conversion.
So in order to show you the conversion,
let's go to the windows directory.
That's a project directory that we will discuss
in more detail later.
For now I only want to have a look at
the inventory where you can see
that there are three groups
and there are variables for the group win.
And that is what makes this an interesting one.
So if I wanna do the conversion,
then ansible-inventory --yaml to specify the format
- i inventory --list --output winventory.yaml.
So that is creating winventory.yaml.
And there we go, we can see that the conversion
actually has worked pretty well.
So it works with the implicit host group all,
we don't see that anywhere in the original inventory
but it's an implicit host group so it's there,
which is children,
children file and lamp and ungrouped.
Ungrouped are the hosts that are a member of no group at all
that doesn't apply in this case.
Then we have win.
And in win we have the hosts
and the host windows.example.com.
And here we have all the variables that apply
to that specific host.
That is looking pretty good.
Let's get back to the slide one more time
because we need to talk about inventory sources
a little bit more to make sure
you fully understand what's going on.
So inventory is just discussed as plugin-based.
You can use ansible-doc -t inventory -l
for a complete list.
We've already seen it.
The inventory enabled plugins option in ansible.cfg,
as how you determine what plugins needs to be enabled.
So here we can see an example where host_list
and script and auto and yaml and ini and toml,
all of them are enabled.
And if you are using legacy inventory scripts,
they are still supported because of the script plugin.
That's a nice backward compatibility
that is implemented and that goes
without any additional work.
And if you wanna use additional inventory plugins,
you need to add them in product based
or generic ansible.cfg.
Well, let's make sure you understand this.
This product based or generic ansible.cfg,
they are not merged.
So either in product based where no generic ansible.cfg
is considered or in generic ansible.cfg,
if you don't have a project based inventory.
Use a fully qualified collection name
if the plugin is a part of a collection.
And that's all you need to know about inventories.