Ansible AWX Job Templates and Workflow Configuration

AWX (the open-source upstream of Red Hat's automation controller, formerly Ansible Tower) turns playbooks into governed, repeatable operations: who may run what, with which credentials, against which inventory, with the result logged. A job template is the unit of that governance, and a workflow template is how you chain several of them with success and failure paths. This guide builds both, plus the credential model that confuses most first-time operators.

The Object Model

• Project — a Git repository AWX checks out; playbooks live here.
• Inventory — hosts and groups, static or sourced from a dynamic inventory plugin.
• Credential — machine (SSH), cloud, network device, and vault credentials; AWX injects them at run time.
• Job template — project + playbook + inventory + credentials + limits + survey.
• Workflow template — a graph of job templates with success/failure/always edges.

Create a Job Template

# API equivalent of the UI "Add job template" form
curl -s -X POST "https://awx.example.com/api/v2/job_templates/" \
  -H "Authorization: Bearer ${AWX_TOKEN}" -H "Content-Type: application/json" \
  -d '{
    "name": "Update Web Servers",
    "description": "Updates packages on all web servers",
    "job_type": "run",
    "inventory": 3,
    "project": 5,
    "playbook": "update_webservers.yml",
    "credentials": [7, 11],
    "ask_variables_on_launch": true
  }' | jq '.id, .name'

# or with the awx CLI
awx job_templates create \
  --name "Deploy Production" \
  --project "My Project" \
  --playbook "site.yml" \
  --inventory "Production" \
  --credential "Machine Credential" \
  --vault_credential "Production Vault Password"

Vault Credentials Replace --ask-vault-pass

AWX never passes vault passwords on the command line as a text argument. A vault credential stores the secret, and the runner materialises a temporary password file that is deleted after the job:

# associate a vault credential with an existing job template
curl -s -X POST "https://awx.example.com/api/v2/job_templates/42/credentials/" \
  -H "Authorization: Bearer ${AWX_TOKEN}" -H "Content-Type: application/json" \
  -d '{"associate": true, "id": 15}'

# multiple vault IDs are supported for group_vars with different secrets
#   group_vars/production/vault.yml  -> encrypted with vault id 'prod'
#   group_vars/staging/vault.yml     -> encrypted with vault id 'staging'

Surveys: Variables Without Editing Playbooks

Survey questions
  Question:          Application version to deploy
  Variable name:     app_version
  Type:              Text
  Default:           latest
  Required:          true

  Question:          Deploy to which servers?
  Variable name:     server_group
  Type:              Multiple choice (single select)
  Choices:           app-server-1, app-server-2, all
  Default:           all

- name: Deploy application
  ansible.builtin.git:
    repo: https://github.com/company/app.git
    version: "{{ app_version }}"
    dest: /var/www/app

Surveys are the correct place for operator-supplied parameters, and they can replace vault-encrypted variables entirely for values that are not secrets but should not be hard-coded.

Workflows: Provision, Deploy, Verify, Rollback

# workflow node graph, expressed as data (awx.awx collection)
- name: Deployment workflow
  awx.awx.workflow_job_template:
    name: "Web App Deployment"
    organization: "Default"
    schema:
      - identifier: provision
        unified_job_template: "Provision Infrastructure"
        success_nodes: [deploy]
      - identifier: deploy
        unified_job_template: "Deploy Application"
        success_nodes: [verify]
        failure_nodes: [rollback]
      - identifier: verify
        unified_job_template: "Smoke Tests"
        success_nodes: [notify]
      - identifier: rollback
        unified_job_template: "Rollback Release"
        always_nodes: [notify]
      - identifier: notify
        unified_job_template: "Send Notification"

The graph is the value: failure_nodes and always_nodes let you encode an operational procedure once, instead of relying on a runbook that people follow only under pressure.

Launching and Auditing from CI

curl -s -X POST "https://awx.example.com/api/v2/job_templates/42/launch/" \
  -H "Authorization: Bearer ${AWX_TOKEN}" -H "Content-Type: application/json" \
  -d '{"extra_vars": {"app_version": "2.14.1"}}' | jq '.id, .status'

curl -s "https://awx.example.com/api/v2/jobs/1234/" -H "Authorization: Bearer ${AWX_TOKEN}" | jq '.status, .elapsed'
curl -s "https://awx.example.com/api/v2/jobs/1234/stdout/?format=txt" -H "Authorization: Bearer ${AWX_TOKEN}" | tail -20

Poll the job endpoint rather than sleeping on the launch call, and gate promotion in CI on .status == "successful". Every run keeps its full stdout, inventory, credential references and extra variables, which is exactly the evidence you need when someone asks who changed production last Tuesday.

Related reading: Idempotent Ansible automation for IOS XR and YANG and OpenConfig models with pyang.

原文链接：https://compilenrun.com/docs/devops/ansible/ansible-towerawx/ansible-tower-job-templates