AWX in Action

Job Templates: The Reusable Definition

We already have a project with a playbook that installs the epel-release package (and the tree package if you followed the steps above). Now, we'll create a job template that uses this project to run the playbook on the nebula host.

A job template, as you may have guessed, is a template for running a job. It defines the playbook, inventory, credentials, and other settings needed to run the job.

Go to the Templates menu and click on Add. You have two choices:

• Job Template: Used to run a job on a host or group of hosts.
• Workflow Template: Used to run multiple job templates in a specific order.

We'll start with job templates for now.

Building a Job Template, Field by Field

You have multiple options to configure a job template.

• Name: The name of the job template. We'll name it My AWX job template.

• Description: A brief description of the job template. We'll use My first AWX job template.

• Job Type: The type of job you want to run. You can choose between Run and Check. When you run a job, it will make changes to the host. When you check a job, it will only check how the job would run without making any changes. This is a "dry run". We'll choose Run for this example.

• Inventory: The inventory you want to use. For this example, we won't provide an inventory and we'll activate the Prompt on launch option. This means that when you launch the job, you'll be asked to provide the inventory.

• Project: The project you want to use. We'll use the Demo Ansible Playbooks project.

• Execution Environment: Leave the field empty.

• Source Control Branch/Tag/Commit: Because we enabled Allow Branch Override on the project, this field overrides the revision set on the project. You can enter a branch name, a tag, or a commit SHA. Enable Prompt on launch to be asked for the value each time the job runs. This is how you run the same playbook against a feature branch, a release tag, or a specific commit without creating a separate project for each.

• Playbook: The playbook you want to run. We'll use the playbook.yml playbook.

• Credentials: The credentials you want to use to connect to the host. We have already created the MyCredentials credential. We'll use this credential for this example.

• Labels: You can add labels to the job template. Labels help organize job templates and make them easier to locate later by filtering. For this example, we're going to use the demo label.

• Variables: You can add extra variables to the job template. These will be passed to the playbook when it runs. We're not going to use any variables for this example since the playbook does not require any additional variables.

• Forks: You can configure the number of parallel processes to use while executing the playbook. An empty value, or a value less than 1, will use the Ansible default, which is usually 5. We'll leave this field empty for this example.

Ansible uses forks to set how many hosts run tasks in parallel. The default is 5: with 10 hosts in the inventory, Ansible runs the playbook against 5 hosts, then the next 5 once the first batch finishes. Raise it when you have many hosts and want jobs to finish faster. The cost is CPU and memory on the execution node running the job (the EE pod in AWX), since each fork is a separate Python process holding an SSH connection. Set it too high on an undersized execution node and you'll see OOM kills or slow jobs from CPU contention, not faster ones.

• Limit: You can use the limit pattern to target hosts in the inventory. Leaving the field blank, all, and * will target all hosts in the inventory, but you can also use a pattern to focus on specific ones. For example, nebula will target the nebula host from the inventory. We'll leave this field blank for this example to target all hosts in the inventory (in this case, only the nebula host).

• Verbosity: You can set the verbosity level for the job. The verbosity level can be set to 0, 1, 2, 3, 4, or 5. While 0, 1, 2, and 3 are the standard verbosity levels, 4 and 5 are used for debugging purposes. The 5 verbosity level is used for WinRM debugging. We'll use 2 as the verbosity level for this example.

WinRM is a Windows Remote Management service that allows you to execute commands on a remote Windows host. You can use WinRM to run PowerShell scripts, commands, and other tasks on Windows hosts. Ansible uses WinRM to connect to Windows hosts and run playbooks on them.

• Job Slicing: Splits the inventory into N chunks and runs each chunk as a separate job, scheduled in parallel across your execution nodes. AWX wraps the slices in a workflow job automatically. The API field is job_slice_count. Set it to 10 with 100 hosts and you get 10 jobs of 10 hosts each, which is useful when one execution node cannot handle the full inventory or when you want to spread load across the cluster. Our inventory has one host, so we leave this blank.

Forks run hosts in parallel inside one job on a single execution node. Slicing splits the inventory into separate jobs that AWX schedules across multiple execution nodes, spreading CPU and memory load across the cluster instead of concentrating it on one node.

• Timeout: The maximum amount of time (in seconds) the job can run before it is canceled. We'll leave this field empty for this example to set no timeout.

• Show Changes: Shows the changes made by the playbook. When you run a job, Ansible will show you the changes made by the playbook. This is like running a diff command to see the changes made by the playbook. We don't need to enable this option for this example since we're not making changes to files on the host. Whenever there are important changes that you want to see, you can enable it.