Ansible is a configuration management tool that can
help alleviate these challenges.
It replaces the need for an operator to manually tune
configuration files and does a good job at application deployment
and orchestrating multi‑deployment scenarios.
In reality, Ansible is relatively easy to install,
and you will see how easy it is in the upcoming demos.
However, Ansible is not a single entity.
Ansible comprises of tools, modules,
and software‑defined infrastructure that formed Ansible
toolset that can be configured from a single host that can
then manage multiple hosts.
So keep in mind that Ansible does not deploy the infrastructure.
For this, you would have to use other solutions,
such as Terraform, that are best suited for these use cases.
Terraform is infrastructure as a code tool.
So Ansible is an easy‑to‑use DevOps tool that manages
configuration as code and has the same configuration parameters
that can be used throughout any size environment.
It is often described as configuration management tool and is typically
mentioned in the same lines as Puppet and Chef and Salt.
However, there's considerable differences in how they operate,
most notably with the installation of agents.
So when talking about configuration management,
we typically mean writing a state description of the managed
assets and then using a tool to ensure or even enforce that the
managed servers are in the desired state.
For this,
Ansible exposes a domain‑specific language that you can use
to describe the state of your servers.
In Ansible, we have different ways to represent the state,
such as present or absent.
That will then instruct Ansible to carry out the actions
required to meet the desired state.
And Ansible ensures that the state is met,
and it's all about state management, and it does this with playbooks.
More specifically, YAML playbooks.
Ansible playbook syntax is built on YAML and is an
easy‑to‑read data format language.
And to guarantee consistency,
these playbooks are often provided through a Git repository.
However, you don't need to use a Git repository to run Ansible Playbooks.
As a best practice,
I would recommend using the Git repository for production environments.
A playbook is a term Ansible uses for configuration management
script and ensures that the desired state is met.
Essentially, playbooks are Ansible's configuration management scripts.
We'll be looking at playbooks and how to optimize playbooks and make
them flexible with variables throughout this course.
So on the opposite side of the spectrum,
we have Ansible ad hoc commands, and these are used for,
let's say, simple tasks or one‑off checks.
But for now, consider a playbook to describe the hosts,
which are Ansible's managed assets or remote servers to configure,
which also contained an ordered list of tasks to perform under those hosts.
So Ansible is written in Python, but it uses its DSL language.
You can, however, write using DSL language,
and Ansible will convert it to Python on the remote machines to execute tasks.
Keep in mind that Ansible is not a fully fledged programming language,
but it does have several good features.
One of the most important of these is variable substitution or using the
value of variables in strings or in other variables.
The use of variables in Ansible makes the Ansible Playbooks become more
like executable documents and very flexible to use.
Variables are a powerful construct within Ansible
and can be used in various ways.
We also have dynamic variables.
These are known as facts, and we'll discuss these more in the next module.
The defaults of Ansible can also be extended by the
use of a Jinja2 tempting language.
Ansible's use of Jinja2 templating adds more advanced use cases to Ansible.