- [Instructor] Unlike the orchestration tools
we've already covered in this module
Ansible is an Agent-less tool.
So in other words, no software needs to be installed
on the client machines
in order for management to take place.
As you can probably guess,
this means Ansible uses the push model
of configuration management.
The Ansible architecture is pretty straightforward.
We have an Ansible Management node,
where everything takes place.
This is where configuration happens
as also where configurations are pushed out
to connected nodes.
In addition to this simplistic architecture,
uses a very simple programming language called YAML.
And YAML stands for YAML Ain't Markup Language.
And yes, I'm 100% serious about that.
That is exactly what it stands for.
The management node is referred to as
the Controller Machine.
And this is the machine where Ansible is installed.
This is the only piece needed in the deployment.
So you can see that this is a much easier
model to deploy as compared to those
agent based models that we've looked at.
The controller machine,
communicates via SSH as its most common method,
but it also has the capability of using
Windows Remote Management, and a few other methods
based on what the client needs.
Of course, there are some terms we want to know
with Ansible and those components
that we need to define
starting with the Ansible inventory file.
The inventory file,
is a list of nodes that are under the management
of the Ansible system, such as servers or switches.
Using the YAML language that we mentioned previously,
we can write code to define tasks for execution.
These configuration codes are referred to as
playbooks and are essentially like to do lists.
They are sets of instructions for the hosts to take.
Playbooks can also be used
to retrieve information from the hosts
about their current state.
Here's a look at a YAML based playbook,
and I think you can see right away that this is
a bit easier to interpret than maybe Python or Ruby.
It's a fairly simple language.
This particular example
would be used to install an Apache Web Server
on multiple hosts.
The controller machine has what's referred to as an
automation engine.
And the automation engine is what the users will access
in order to create Ansible playbooks in the YAML language.
Inside the automation engine,
we have a few pieces that we want to define,
which are the Inventory, the API, the Plugins
and the Modules.
The inventory is very simply a list of all the IP addresses
which Ansible is actively managing.
The modules, are tasks which are invoked by the playbooks.
In other words, the playbook defines which modules should be
executed against the host in the inventory.
These modules are pushed out
to the Manage clients to perform specific actions.
Also, as far as the inventory goes,
know that Ansible can manage
both physical devices in your private enterprise network,
and also cloud platforms such as Azure, VMware
and Rackspace, just to name a few.
That's what API's and Ansible are used for.
They transport data for cloud services,
both public and private.
The plugins, you can think of,
very similar to how browser plugins work.
These are pre-built pieces of code
that can be executed to perform specific things
against the inventory hosts.
And again, the controller machine is in charge
of organizing all these pieces,
and organizing the playbook input from the users
and pushing all of those desired configuration changes
out to the managed hosts
that are listed in the inventory.
So you can see that Ansible
has a few less moving pieces
than the tools we've looked at previously,
and also a very intuitive language.
If you're leaning toward an Agent-less orchestration tool
Ansible is definitely worth checking out.