- In this lesson, we are going to talk about variables.
And before we are diving into
the details of vault of variables and facts,
I want to give you an overview
of how variables are used by talking about
separating code from site-specific configuration.
That's one of the DevOps best practices.
Ansible itself is all about configuration as code.
Let's face it.
You define your playbooks,
in your playbooks, in YAML file you define the configuration
that you want to enroll on the managed assets
in your environment.
And if you are developing flexible code,
you should separate site-specific information from the code
which will be static.
We've already seen that a couple of times.
If in your playbook, you are too specific
then it's not going to work out well.
So you need to try to maintain a certain obstruction level
in your playbook and to keep out very specific information.
If you develop dynamic code
where your static code is combined with variables
that allows you to use your code on any site
reduce some minor modifications in the variables themselves.
So to provide the site-specific information,
variables I use.
And apart from variables, Ansible provides facts.
Well, I'm not even sure
if I should put it that way, because effect is a variable.
The only difference is that variables
in general are defined by the system administrator
and Ansible effects are discovered on the managed machines.
So effects are system properties that are
dynamically discovered, and you can use them as variables.
And separating site-specific information
from static code is also referred to as decoupling.
So what does that mean?
That means that you should try to develop your playbooks
in such a way that they can be used throughout.
If you want to use them somewhere else,
the only thing you need to change is the variables.
In the next couple of videos,
we are going to discover how this works.