Ansible Tower / AWX: Web UI สำหรับ Manage Ansible บน Enterprise

Categories

Ansible Tower (Red Hat) และ AWX (open-source upstream) คือ Web UI และ REST API สำหรับ manage Ansible playbooks ในระดับ enterprise — เปลี่ยนการรัน ansible-playbook ผ่าน terminal ให้กลายเป็น self-service portal ที่ทีมใช้ได้โดยไม่ต้องมีสิทธิ์ SSH บน control node

บทความนี้อธิบายความแตกต่างระหว่าง AWX กับ Tower, concepts หลักของระบบ (Organizations, Credentials, Projects, Inventories, Job Templates, Workflows), การกำหนดสิทธิ์ด้วย RBAC, การตั้ง schedule และ notifications รวมถึง pattern การใช้งานจริงในทีม DevOps

AWX vs Ansible Tower

AWX คือ open-source upstream project ของ Ansible Tower — Tower คือ enterprise product ของ Red Hat ที่มาพร้อม support และ lifecycle guarantees, ส่วน AWX เป็น community version ที่ใช้ฟรีแต่ไม่มี official support

# เปรียบเทียบ AWX vs Ansible Tower

# AWX
# - ฟรี, open-source (github.com/ansible/awx)
# - release cycle เร็ว, อาจมี breaking changes
# - ติดตั้งบน Kubernetes (Operator) หรือ Docker Compose
# - เหมาะสำหรับ: ทดลองใช้, lab, non-critical workloads

# Ansible Automation Platform (Ansible Tower)
# - ต้องมี Red Hat subscription
# - release cycle ช้ากว่า, stable มากกว่า
# - มี official support, CVE patches
# - รวม Private Automation Hub, Event-Driven Ansible
# - เหมาะสำหรับ: production enterprise, regulated industries

# ติดตั้ง AWX ด้วย Kubernetes Operator (วิธีแนะนำ)
kubectl create namespace awx

# สร้าง AWX instance
cat <<EOF | kubectl apply -f -
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx-demo
  namespace: awx
spec:
  service_type: nodeport
EOF

# ติดตาม deployment
kubectl get pods -n awx -w

Concepts หลัก: Organizations และ Teams

AWX/Tower ใช้ hierarchy ของ Organizations → Teams → Users เพื่อ isolate resources และกำหนดสิทธิ์ — Organizations เป็นหน่วยแยกที่สุด แต่ละ Org มี Inventories, Projects, Credentials และ Users เป็นของตัวเอง

# โครงสร้าง AWX/Tower Resources

Organization
├── Teams (กลุ่มผู้ใช้)
│   ├── Dev Team
│   └── Ops Team
├── Users
├── Credentials (secrets สำหรับ SSH, cloud, vault)
├── Projects (แหล่งของ playbooks จาก Git)
├── Inventories (รายชื่อ hosts)
├── Job Templates (playbook + inventory + credentials)
└── Workflows (ลำดับ Job Templates)

# ตัวอย่าง: สร้าง Credential ผ่าน AWX REST API
curl -X POST https://awx.example.com/api/v2/credentials/ \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Production SSH Key",
    "organization": 1,
    "credential_type": 1,
    "inputs": {
      "username": "deploy",
      "ssh_key_data": "-----BEGIN OPENSSH PRIVATE KEY-----\n..."
    }
  }'

# Credential Types ที่สำคัญ:
# Machine (SSH)      — สำหรับ connect ไปยัง hosts
# Source Control     — SSH key/token สำหรับ clone Git repo
# Vault              — Ansible Vault password
# Amazon Web Services, Google Compute Engine, Azure — cloud credentials

Projects — เชื่อม Git Repository

Project คือการเชื่อม AWX/Tower กับ Git repository ที่เก็บ playbooks — ทุกครั้งที่รัน Job Template ระบบจะ sync playbooks จาก Git โดยอัตโนมัติ ทำให้ version ที่รันตรงกับ commit ใน repository เสมอ

# ตัวอย่าง Project configuration (ผ่าน AWX UI หรือ API)

# Project settings:
# Name: MyApp Playbooks
# Organization: Default
# Source Control Type: Git
# Source Control URL: https://github.com/myorg/ansible-playbooks.git
# Source Control Branch/Tag/Commit: main
# Source Control Credential: GitHub Token (Source Control credential)
# Update Revision on Launch: ✅ (sync ก่อนรัน job ทุกครั้ง)

# โครงสร้าง Git repo สำหรับใช้กับ AWX:
ansible-playbooks/
├── inventory/
│   ├── production/
│   │   ├── hosts.ini
│   │   └── group_vars/
│   └── staging/
│       └── hosts.ini
├── playbooks/
│   ├── deploy_app.yml
│   ├── update_nginx.yml
│   └── provision_vps.yml
├── roles/
│   └── common/
└── collections/
    └── requirements.yml   # AWX auto-install collections จากไฟล์นี้

Inventories — จัดการ Hosts

Inventory ใน AWX/Tower รองรับทั้ง static inventory (กำหนด hosts ตรง ๆ), dynamic inventory (ดึงจาก cloud provider), และ inventory file จาก SCM (อ่านจาก Git repo)

# Static Inventory — กำหนด hosts โดยตรงใน AWX UI
# Variables (YAML) สำหรับ group "webservers":
---
ansible_user: deploy
ansible_ssh_private_key_file: /tmp/ssh_key
nginx_version: "1.25"

# Dynamic Inventory — ดึง hosts จาก cloud
# ใช้ Inventory Source พร้อม credential ของ cloud

# ตัวอย่าง: Dynamic Inventory จาก Amazon AWS EC2
# Source: Amazon EC2
# Credential: AWS credentials
# Regions: ap-southeast-1
# Filter: tag:Environment=production

# SCM Inventory — อ่าน inventory file จาก Git Project
# Source: Sourced from a Project
# Project: MyApp Playbooks
# Inventory File: inventory/production/hosts.ini

# Smart Inventory — filter hosts ข้าม Inventories
# Filter: ansible_facts['os_family'] == 'Debian'
# ใช้สำหรับ run job เฉพาะ Ubuntu hosts ข้ามหลาย Inventories

Job Templates — กำหนด Playbook Execution

Job Template คือหัวใจของ AWX/Tower — เชื่อม Project (playbook) + Inventory + Credentials เข้าด้วยกัน พร้อมกำหนด extra variables, tags, และ limits ที่ใช้รันทุกครั้ง

# Job Template settings ที่สำคัญ

# ชื่อ: Deploy MyApp
# Job Type: Run (หรือ Check สำหรับ dry-run)
# Inventory: Production Inventory
# Project: MyApp Playbooks
# Playbook: playbooks/deploy_app.yml
# Credentials: Production SSH Key
# Variables (Extra Vars):
app_version: "1.5.0"
deploy_env: production

# Options ที่ควรเปิด:
# Enable Privilege Escalation: ✅ (become: true)
# Allow Simultaneous: ❌ (ป้องกัน 2 คน run พร้อมกัน)
# Enable Webhook: ✅ (ให้ CI/CD trigger ได้)

# Prompt on Launch — ให้ผู้ใช้กรอก variables ตอน run:
# Extra Variables: ✅ (ถาม app_version ก่อนรัน)
# Limit: ✅ (เลือก hosts ที่จะ deploy)

# Labels — ใช้ filter job templates ใน UI:
# Labels: production, webapp, nginx

Workflow Templates — ลำดับ Jobs

Workflow Template เชื่อม Job Templates หลายตัวเป็น pipeline — กำหนด success/failure path, รัน jobs แบบ parallel หรือ sequential, และ pass variables ระหว่าง jobs ได้

# ตัวอย่าง Workflow: Full Deployment Pipeline
# (กำหนดผ่าน Workflow Visualizer ใน UI หรือ API)

# โครงสร้าง Workflow:
#
# [Run Tests] ──✅──> [Deploy Staging] ──✅──> [Run Smoke Tests] ──✅──> [Deploy Production]
#                                                          │
#                                               ❌──> [Rollback Staging]
#
# [Run Tests] ──❌──> [Notify Failure]

# Workflow Node types:
# Job Template     — รัน playbook
# Approval         — รอให้คนอนุมัติก่อนไปต่อ (เหมาะกับ production gate)
# Workflow Template — nested workflow

# Set Stats — ส่งต่อ variables ระหว่าง nodes
- name: Set deployment version for next job
  ansible.builtin.set_stats:
    data:
      deployed_version: "{{ app_version }}"
      deploy_timestamp: "{{ ansible_date_time.iso8601 }}"
    per_host: false

RBAC — กำหนดสิทธิ์

Role-Based Access Control ใน AWX/Tower กำหนดสิทธิ์ระดับ resource — ทีม Dev อาจ Execute Job Templates ได้แต่แก้ไขไม่ได้, ส่วน Admin เท่านั้นที่เปลี่ยน Credentials หรือสร้าง Projects ได้

# Roles หลักสำหรับแต่ละ Resource:

# Job Template Roles:
# Admin     — แก้ไข, ลบ, รัน Job Template ได้
# Execute   — รัน Job Template ได้อย่างเดียว (ไม่เห็น credentials)
# Read      — ดูข้อมูลได้ ไม่รัน

# Inventory Roles:
# Admin     — แก้ไข Inventory, hosts, groups
# Update    — sync dynamic inventory
# Use       — ใช้ใน Job Template ได้
# Read      — ดูข้อมูลได้

# Credential Roles:
# Admin     — แก้ไขได้ (เห็น plaintext password)
# Use       — ใช้ใน Job Template ได้ (ไม่เห็น plaintext)
# Read      — ดูชื่อได้

# ตัวอย่าง: Dev Team สามารถ Execute ได้ แต่ไม่แก้ไข
# Team: Dev Team → Job Template "Deploy MyApp" → Role: Execute
# Team: Dev Team → Inventory "Production" → Role: Use
# Team: Dev Team → Credential "Production SSH" → Role: Use

# System Roles (ระดับ AWX):
# System Administrator — สิทธิ์เต็ม
# System Auditor       — ดูทุกอย่างแต่แก้ไขไม่ได้

Scheduling และ Notifications

AWX/Tower มีระบบ Schedule ในตัวสำหรับรัน Job Templates ตามเวลา และ Notification ส่งผลลัพธ์ไปยัง Slack, Email, PagerDuty และอื่น ๆ เมื่อ job สำเร็จหรือล้มเหลว

# Schedule — รัน Job Template ตามเวลา
# (กำหนดได้บน Job Template → Schedules tab)

# ตัวอย่าง: รัน backup ทุกวันเที่ยงคืน
# Name: Nightly Backup
# Start Date/Time: 2026-04-17 00:00:00 UTC+7
# Repeat Frequency: Daily
# End: Never

# RRULE format (iCalendar):
# DTSTART;TZID=Asia/Bangkok:20260417T000000
# RRULE:FREQ=DAILY;INTERVAL=1

# Notification Templates — ตั้งค่าใน Organizations → Notifications
# Types: Email, Slack, MS Teams, Webhook, PagerDuty, Grafana

# Slack Notification:
# Notification Type: Slack
# Token: xoxb-...
# Destination Channels: #deployments
# Notify When: Success, Failure, Error

# Webhook Notification — ส่งไปยัง custom endpoint:
# URL: https://hooks.example.com/notify
# HTTP Method: POST
# Payload (ตัวอย่างที่ AWX ส่ง):
# {
#   "job_id": 42,
#   "name": "Deploy MyApp",
#   "status": "successful",
#   "url": "https://awx.example.com/#/jobs/playbook/42"
# }

AWX API — Automate Automation

AWX/Tower มี REST API ครบถ้วน — CI/CD pipelines สามารถ trigger Job Templates, รอผลลัพธ์, และตรวจสอบ status ได้โดยไม่ต้องผ่าน UI ทำให้ใช้ AWX เป็น execution backend ของ pipeline ได้

# ตัวอย่าง: Trigger Job Template จาก CI/CD

# 1. สร้าง Token (Personal Access Token)
curl -X POST https://awx.example.com/api/v2/tokens/ \
  -u admin:password \
  -H "Content-Type: application/json" \
  -d '{"description": "CI/CD Token", "application": null, "scope": "write"}'

# 2. Launch Job Template (ID: 15)
JOB=$(curl -s -X POST https://awx.example.com/api/v2/job_templates/15/launch/ \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"extra_vars": {"app_version": "1.6.0"}}')

JOB_ID=$(echo $JOB | python3 -c "import sys,json; print(json.load(sys.stdin)['id'])")
echo "Job ID: $JOB_ID"

# 3. รอผลลัพธ์ (polling)
while true; do
  STATUS=$(curl -s https://awx.example.com/api/v2/jobs/$JOB_ID/ \
    -H "Authorization: Bearer $TOKEN" \
    | python3 -c "import sys,json; print(json.load(sys.stdin)['status'])")
  echo "Status: $STATUS"
  if [[ "$STATUS" == "successful" || "$STATUS" == "failed" ]]; then
    break
  fi
  sleep 10
done

# 4. ตรวจสอบผลลัพธ์
if [[ "$STATUS" != "successful" ]]; then
  echo "Deployment failed!"
  exit 1
fi

สรุป

AWX/Ansible Tower เปลี่ยน Ansible จาก CLI tool เป็น enterprise platform — ด้วย Job Templates ที่ standardize การรัน playbooks, RBAC ที่กำหนดสิทธิ์ละเอียด, Workflow Templates ที่เชื่อม jobs เป็น pipeline, Schedule สำหรับ automation ตามเวลา และ REST API สำหรับ integrate กับ CI/CD

สำหรับทีมที่เริ่มต้น AWX คือตัวเลือกที่ดีที่สุดเพราะฟรีและใช้ได้บน Kubernetes หรือ Docker — ส่วน Ansible Automation Platform เหมาะกับองค์กรที่ต้องการ support อย่างเป็นทางการและ integration กับ Red Hat ecosystem