Everything in Ansible Tower revolves around the concept of a job template.
A job template is a collection of the configurations
needed to perform an automation job.
So consider the job template to be the glue that
allows playbooks to be controlled, delegated,
and scaled within the enterprise.
So we need to create a job template so that playbooks can be
launched with little or no user input,
and it's here we can introduce a lot of governance with the template features.
Meaning that they can be delegated to teams who might not know
all the details of how a playbook works, or it can be run on a
scheduled basis without anyone present.
When creating a job template,
we choose whether we want to create a normal job
template or a workflow template.
We choose a job template if you want to be able to create simple jobs
with a workflow template. It's possible to create more complex jobs
composed of multiple job templates along with flow control features
between one job and the next.
So this is known as a workflow template,
and it can be also integrated into your CI/CD pipeline.
So we have a number of job template options,
and there are many fields in Job Template creation window that are the
options that will enable us to Prompt on Launch.
This provides us stability to set a value optionally
during the creation of a job template,
but also allowing the user running the job to enter or override at runtime.
A use case for Prompt on Launch may be useful when you
have a field that changes on each run.
You can also use this for sanity checks as it prompts the
user for a value and gives them a chance to modify it before
the playbook is actually run.
However,
keep in mind that the Prompt on Launch feature could
actually block scheduled job runs,
so exercise caution when enabling this feature so you don't use
the Prompt on Launch with scheduled jobs.
So facts allow you to adjust, branch,
and have conditions of playbook execution based on the
discovered state of the managed assets.
However,
gathering facts across all managed assets on all playbooks can
be time consuming in large environments.
This is where we have the integrated features of fact caching in Ansible Tower.
When we check the box, use fact cache on each job template,
and it can be enabled and disabled on a template basis.
So when it's checked,
it will read stored facts from Ansible Tower for that host and
store any newly found facts in its fact cache. So we already
touched on workflow templates,
but let's just jump into this in a bit more detail.
This particular feature in Ansible Tower enables a user to create a
sequence consisting of any combination of tower objects.
We have job templates that glue all the automation primers together,
and then we have these multi‑job templates that allow us to
create more complex automation tasks.
Multi‑playbook workflows enable a sequence of unrelated
workflow templates to form an automation job.
The big benefit of workflow templates is that they
may or may not share inventory, playbooks,
or permissions.
So a workflow template is a job template that links
together different types of resources.
So you may be thinking that it's just used to link job templates,
but a workflow template can include job templates,
other workflow templates, project syncs,
and inventory source syncs.
We also have several options here, success,
failure, and always, and we'll have a look at this in the demo soon.
So once you've decided how you want to use your workflow template,
you can then use the visualizer,
and this allows you to define the workflow within the UI.
The real value of this is that we can have one team,
let's say the Linux team, that can create its template.
The template that the Linux team creates will reference its own inventory,
it will have its set of playbooks, and its complete permission structure,
along with role‑based access control.
The job template allows us to connect all of this together,
even if different users run them with different
inventories and have different credentials.
The really important point to note is that different
teams can use different playbooks, different credentials,
and inventories, yet everything is linked together in one atomic unit.
So complex dependencies can be broken down into simple
steps using different templates,
and then, we can have workflow approval nodes that require
human interaction to advance to workflow.
A simple example of this would be, let's say,
a finance team wants to check if funds are available before
deploying a new service in the public cloud.
I often use this when I want to double check that there's
enough capacity on my target hosts.