So a project is a collection of playbooks, and these are
going to be held in a certain location. By default, this is
going to be in a repository.
So you can use any source control management
system, and Git is just the protocol.
So this allows you to pull playbooks from, for example,
GitHub, and if you want, you can authenticate via token to pull from the
repositories. You can get the token from the developer settings and use a
personal access token, and you can generate one here under GitHub. So
projects allow you to define an area or space that allows all of your
resources and playbooks to exist.
It's a location where your playbooks are going to be stored.
The default points to GitHub, but you can choose Manual as a source
control credential type, and then you can have all your playbooks
on the local directory on your host.
However,
keep in mind that this is not the recommended approach for production as
you don't have any version control for projects that are stored locally on
the Tower machines. Then we have the inventory, and these are the managed
servers that can be statistically or dynamically defined. And to manage
services in Ansible Tower,
your license must allow you to do so. There will also be a limit on the number
of services you can manage in Tower subscription, and under the developer
license, the maximum could be 16 or, in my case, 100.
So when you add an inventory,
you really have a number of options. You have the option to add a normal
inventory, and you can also add what's known as a smart inventory.
Smart inventories are a lot more granular approach to adding hosts dynamically
to your inventory, and basically, they can scrape hosts that are stored in
other inventories based on a filter that we'll be looking at in later modules.
Like the Ansible Engine, the Ansible Tower,
the goal of running an Ansible playbook, that each
playbook has what's known as a job.
So you need to provide a bit more configuration upfront with
Ansible Tower before you can run your first job.
So every time a playbook runs, we have a job, and every time a task runs,
we also have a job, and when source control updates, this
is also considered a job, and running a playbook run
template is also considered a job.
So now that we have the playbooks and our projects and
we have hosts in our inventories,
it's only then can we proceed with the creation of a job template. As the
name suggests, a job template is also an instance of a job.
So with Ansible Tower,
a playbook is run from a job template. Within the job template,
we can specify a number of parameters and environmental details
of how you want to run your playbook.
So the playbook is a job definition with all of its parameters.
The job template can be launched or scheduled. Scheduled is
useful for running playbooks at regular intervals,
such as nightly backup of configuration of all of your network devices.
We have to choose whether we're creating a job or a workflow template.
We will choose a job template in most cases since we want to be
able to create simple jobs out of a template.
If we want to create more complex jobs that links objects
together and we'll have flow between those objects,
we will need to have a workflow template,
which we will be looking at in later modules.
So, we have two options.
We can have a normal template or a workflow template.
So a job template is used to run a single playbook with one set of settings.
On the other hand,
we have a workflow template that says I want to run this job with
this template, and then if this passes or fails,
we have, for example, a continuous workflow of multiple templates.
So when creating templates,
you need to specify the inventory, and the
inventory can be of a number of types.
It can be a simple text file that needs to be updated manually,
or it can be a dynamic inventory that uses scripting. And then
we need a project, which is like a repository of all of your
playbooks stored together.
We also need credentials. That is needed to log in to the managed hosts.
All of this is tied together in a job template.
A job template is a collection of the
configurations needed to perform your jobs.
So we need to create a job template so that playbook runs can
be launched with little or no user input,
meaning they can be delegated to teams who might not know
all the details of how the playbook works,
but only need to perform certain checks.
So as a final tip before we get into the final demo, as
a common practice in Ansible Tower,
it's very useful to have your playbooks target all of your hosts.
Then you can run your flexible playbooks against
different inventories and inventory types,
all using different credentials.
This will bring a level of consistency to your currently varied environments.