บทนำ: ทำไม Ansible Command Line ไม่เพียงพอสำหรับองค์กรขนาดใหญ่
Ansible เป็น Automation Tool ที่ได้รับความนิยมสูงสุดในโลก IT Infrastructure ด้วยความง่ายในการใช้งาน ไม่ต้อง Agent และใช้ภาษา YAML ที่อ่านง่าย อย่างไรก็ตาม เมื่อองค์กรเริ่มใช้ Ansible ในระดับ Enterprise ที่มี Playbook หลายร้อยตัว ทีมงานหลายสิบคน และเครื่อง Server นับพันเครื่อง การ Run Ansible จาก Command Line บนเครื่องของ Engineer แต่ละคน เริ่มสร้างปัญหาหลายอย่าง ไม่มี Centralized Control ว่าใคร Run อะไร เมื่อไหร่ บนเครื่องไหน ไม่มี Role-Based Access Control ที่จะจำกัดสิทธิ์ของแต่ละคน ไม่มี Audit Trail ที่จะตรวจสอบย้อนหลังได้ว่ามีการเปลี่ยนแปลงอะไรบ้าง ไม่สามารถ Schedule Job ให้ Run อัตโนมัติได้สะดวก และ Credential Management ไม่ปลอดภัย เพราะ SSH Key และ Password อยู่บนเครื่องของ Engineer แต่ละคน
Ansible AWX และ Ansible Automation Platform (เดิมเรียก Ansible Tower) ถูกสร้างมาเพื่อแก้ปัญหาเหล่านี้ โดยเพิ่ม Web-based UI, REST API, RBAC, Audit Logging, Job Scheduling และ Credential Management เข้าไปบน Ansible ทำให้ Ansible พร้อมใช้งานในระดับ Enterprise ได้อย่างเต็มรูปแบบ
ในบทความนี้จะอธิบายทุกอย่างเกี่ยวกับ AWX และ Tower ตั้งแต่ความแตกต่างระหว่างสองตัว การติดตั้ง การใช้งาน Web UI การจัดการ Inventory, Credential, Job Template, Workflow การวาง RBAC สำหรับทีมขนาดใหญ่ ไปจนถึง Best Practices สำหรับ Enterprise Deployment ในปี 2026
AWX vs Ansible Tower (Ansible Automation Platform): ความแตกต่างที่ต้องรู้
AWX คืออะไร
AWX คือ Open-source Project ที่เป็น Upstream ของ Ansible Tower (ปัจจุบันคือ Ansible Automation Platform) พัฒนาภายใต้ License Apache 2.0 AWX ให้ Web UI, REST API และ Task Engine สำหรับ Ansible โดยไม่มีค่าใช้จ่าย AWX เปรียบเสมือน Fedora ที่เป็น Upstream ของ Red Hat Enterprise Linux (RHEL) โดย Feature ใหม่ๆ จะถูกพัฒนาและทดสอบใน AWX ก่อน แล้วจึงนำไป Include ใน Ansible Automation Platform เวอร์ชัน Commercial
AWX เหมาะสำหรับ องค์กรขนาดเล็กถึงกลางที่ต้องการ Automation Platform โดยไม่มีงบประมาณสำหรับ License, Lab Environment สำหรับทดสอบ Automation, ทีมที่มี Skill ในการ Deploy และ Maintain Open-source Software, และ Home Lab หรือ Personal Project ที่ต้องการ Centralized Automation
Ansible Tower / Ansible Automation Platform คืออะไร
Ansible Tower เป็นชื่อเดิมของ Commercial Product ที่ Red Hat พัฒนาจาก AWX ปัจจุบัน Red Hat ได้ Rebrand เป็น Ansible Automation Platform (AAP) ซึ่งรวม Component หลายตัวเข้าด้วยกัน ได้แก่ Automation Controller (เดิมคือ Tower สำหรับ Job Execution และ Web UI), Automation Hub (Private Repository สำหรับ Ansible Content Collections), Event-Driven Ansible (EDA สำหรับ Event-based Automation), Automation Mesh (สำหรับ Scale Execution ข้าม Network Boundary), และ Automation Analytics (Dashboard และ Report)
Ansible Automation Platform ต้องซื้อ Subscription จาก Red Hat ราคาขึ้นอยู่กับจำนวน Managed Node สิ่งที่ได้เพิ่มจาก AWX ได้แก่ Official Support จาก Red Hat, Certified Content Collections ที่ผ่านการทดสอบ, Security Patch และ Bug Fix ที่ Guaranteed, Stable Release Cycle, Integration กับ Red Hat Satellite, RHEL, OpenShift และ Product อื่นๆ ของ Red Hat และ Documentation และ Training ที่ครบถ้วน
เปรียบเทียบ AWX vs AAP
ในด้าน Cost AWX ฟรีทั้งหมด ในขณะที่ AAP ต้องซื้อ Subscription ด้าน Support AWX ได้ Community Support เท่านั้น ส่วน AAP ได้ Red Hat Official Support ด้าน Release Cycle AWX มี Release บ่อยมาก (ทุก 2-4 สัปดาห์) อาจมี Breaking Change ส่วน AAP มี Stable Release ทุก 6-12 เดือนพร้อม Long-term Support ด้าน Security AWX ต้อง Patch เอง ส่วน AAP มี Red Hat Security Team ดูแล ด้าน Scalability AWX ใช้ได้ในระดับหนึ่ง ส่วน AAP มี Automation Mesh สำหรับ Scale ข้าม Data Center ด้าน Content AWX ใช้ Ansible Galaxy ส่วน AAP มี Automation Hub ที่มี Certified Collections
สำหรับองค์กรในไทย ถ้าเป็น SME หรือ Startup ที่มีทีม IT เก่ง AWX เป็นทางเลือกที่ดีมาก แต่ถ้าเป็น Enterprise ขนาดใหญ่ โดยเฉพาะธนาคาร โรงพยาบาล หรือหน่วยงานรัฐที่ต้องการ Support Agreement และ Compliance การลงทุนใน AAP คุ้มค่ากว่าในระยะยาว
การติดตั้ง AWX
AWX บน Docker Compose
วิธีติดตั้ง AWX ที่ง่ายที่สุดคือใช้ Docker Compose ซึ่งเหมาะสำหรับ Lab หรือ Development Environment ความต้องการของระบบขั้นต่ำคือ CPU 4 Core, RAM 8 GB (แนะนำ 16 GB), Disk 40 GB, Docker Engine และ Docker Compose ติดตั้งบน Linux (Ubuntu 22.04+ หรือ RHEL 8+)
ขั้นตอนการติดตั้งเริ่มจาก Clone AWX Repository จาก GitHub ด้วยคำสั่ง git clone https://github.com/ansible/awx.git จากนั้นเข้าไปในโฟลเดอร์ tools/docker-compose แล้ว Copy ไฟล์ .env.example เป็น .env แก้ไขค่า Configuration ตามต้องการ เช่น POSTGRES_PASSWORD, SECRET_KEY, AWX Admin Password จากนั้น Run docker compose up -d เพื่อ Start AWX Container ทั้งหมด
AWX ประกอบด้วย Container หลายตัว ได้แก่ awx_web (Web Server ที่ใช้ Nginx), awx_task (Task Runner ที่ Execute Ansible Job), postgres (PostgreSQL Database), redis (Redis สำหรับ Queue และ Cache) และ awx_rsyslog (สำหรับ Logging) หลังจาก Container Start สำเร็จ สามารถเข้า Web UI ได้ที่ https://localhost:8043
AWX บน Kubernetes (AWX Operator)
สำหรับ Production Deployment แนะนำให้ใช้ AWX Operator บน Kubernetes ซึ่งเป็นวิธีที่ Official Recommend AWX Operator ใช้ Kubernetes Operator Pattern ในการ Deploy, Manage และ Upgrade AWX โดยอัตโนมัติ
ขั้นตอนการ Deploy AWX ด้วย Operator เริ่มจาก Deploy AWX Operator ด้วย kustomize หรือ Helm จากนั้นสร้าง AWX Custom Resource (CR) ที่กำหนด Configuration เช่น Replicas, Resource Limits, Storage Class, Ingress Host Apply CR ลง Kubernetes และ Operator จะ Deploy AWX ให้โดยอัตโนมัติ AWX Operator จะสร้าง Deployment, Service, PVC, Secret และ Resource อื่นๆ ที่จำเป็น
ข้อดีของ AWX บน Kubernetes คือ Auto-scaling, Self-healing (ถ้า Pod Crash จะ Restart อัตโนมัติ), Rolling Update สำหรับ Upgrade, และ Integration กับ Kubernetes Ecosystem เช่น Cert-Manager สำหรับ TLS Certificate, External Secrets สำหรับ Secret Management, และ Ingress Controller สำหรับ Load Balancing
AWX Web UI Walkthrough: รู้จักหน้าจอ AWX
Dashboard
หน้า Dashboard เป็นหน้าแรกที่เห็นเมื่อ Login เข้า AWX แสดงภาพรวมของระบบทั้งหมด ประกอบด้วย Job Activity Chart แสดงจำนวน Job ที่ Run ในแต่ละวัน แบ่งตาม Status (Successful, Failed, Error), Recent Jobs แสดงรายการ Job ล่าสุดพร้อม Status, Host Summary แสดงจำนวน Host ทั้งหมดและ Status, และ Inventory Summary แสดง Inventory ที่มีทั้งหมด Dashboard ช่วยให้ Admin เห็นภาพรวมของ Automation Health ได้อย่างรวดเร็ว
Inventories
Inventory คือ Collection ของ Host ที่ AWX จะ Execute Ansible Playbook AWX รองรับ Inventory หลายประเภท Static Inventory ที่ Admin กำหนด Host ด้วยมือ, Dynamic Inventory ที่ Sync จาก Source เช่น VMware vCenter, AWS EC2, Azure, GCP, OpenStack, Red Hat Satellite, และ SCM-based Inventory ที่เก็บ Inventory File ใน Git Repository
Dynamic Inventory เป็นจุดแข็งสำคัญของ AWX ใน Cloud Environment เช่น ถ้าองค์กรใช้ AWS EC2 สามารถ Configure Dynamic Inventory ให้ Sync รายการ EC2 Instance อัตโนมัติทุก 30 นาที เมื่อมี Instance ใหม่ถูกสร้าง จะปรากฏใน AWX Inventory โดยไม่ต้อง Add ด้วยมือ สามารถกำหนด Group ตาม Tag, VPC, Region หรือ Instance Type ได้
Smart Inventory เป็น Feature ที่ช่วยสร้าง Dynamic Group จาก Host ที่มีอยู่ใน Inventory หลายตัว โดยใช้ Filter เช่น สร้าง Smart Inventory ที่รวม Host ทุกตัวที่มี Tag “web-server” จากทุก Inventory ทำให้สามารถ Run Playbook กับ Host ที่ตรงเงื่อนไขได้โดยไม่ต้อง Maintain Group ด้วยมือ
Projects
Project ใน AWX คือ Collection ของ Ansible Playbook ที่เก็บอยู่ใน Source Control (Git, SVN, Mercurial) หรือ Local Directory บน AWX Server เมื่อสร้าง Project จะกำหนด SCM Type (Git, SVN, Archive), SCM URL (เช่น https://github.com/org/ansible-playbooks.git), SCM Branch (เช่น main, develop), SCM Credential (ถ้า Repository เป็น Private) และ Update Options (Clean, Delete, Update Revision on Launch)
AWX จะ Clone/Pull Repository มาเก็บไว้บน AWX Server และสามารถ Sync อัตโนมัติเมื่อ Launch Job หรือ Schedule ให้ Sync เป็นระยะ การใช้ SCM-based Project เป็น Best Practice เพราะทุก Change มี Version Control, Code Review (Pull Request) ก่อน Merge, และสามารถ Rollback ได้
Templates
Job Template เป็นหัวใจของ AWX คือการรวม Playbook, Inventory, Credential และ Variable เข้าด้วยกันเป็น Executable Unit ที่ User สามารถ Run ได้ด้วย Click เดียว
การสร้าง Job Template ต้องกำหนด Name (ชื่อ Template), Job Type (Run หรือ Check), Inventory (เลือก Inventory ที่จะ Run), Project (เลือก Project ที่มี Playbook), Playbook (เลือก Playbook File จาก Project), Credential (เลือก Credential สำหรับเชื่อมต่อ Host), Limit (จำกัด Host ที่จะ Run), Verbosity (ระดับ Debug Output), Extra Variables (ตัวแปรเพิ่มเติม), Forks (จำนวน Parallel Process), และ Job Tags/Skip Tags (เลือก Task ที่จะ Run หรือข้าม)
Job Template ช่วยให้ Non-technical User สามารถ Run Automation ได้โดยไม่ต้องเข้าถึง Command Line เช่น Help Desk สามารถ Reset Password หรือ Restart Service ได้ด้วยการ Click Template บน Web UI โดยไม่ต้องรู้ Ansible Syntax
Credentials
Credential Management เป็นจุดแข็งสำคัญของ AWX ที่ช่วยแก้ปัญหา Security ของ Ansible CLI ใน AWX Credential ถูกเก็บใน Database แบบ Encrypted (AES-256) และจะไม่ถูก Expose ให้ User เห็น Plain Text
AWX รองรับ Credential Type หลายประเภท ได้แก่ Machine Credential (SSH Key หรือ Password สำหรับเชื่อมต่อ Host), Source Control Credential (สำหรับ Access Private Git Repository), Vault Credential (Ansible Vault Password สำหรับ Decrypt Encrypted Variables), Cloud Credential (AWS, Azure, GCP, VMware สำหรับ Dynamic Inventory และ Cloud Module), Network Credential (สำหรับ Network Device เช่น Cisco, Juniper, Arista), Container Registry Credential (สำหรับ Pull Container Image จาก Private Registry), และ Custom Credential Type ที่ Admin สามารถสร้างเองได้
สิ่งที่ทำให้ AWX Credential Management ปลอดภัยกว่า Ansible CLI คือ User สามารถ Use Credential ใน Job Template ได้โดยไม่เห็น Password หรือ SSH Key จริง, Credential ถูก Inject เข้า Job Runtime เป็น Environment Variable ไม่เก็บไว้ในไฟล์, มี RBAC ควบคุมว่าใครใช้ Credential ตัวไหนได้, และมี Audit Log ว่า Credential ถูกใช้เมื่อไหร่ โดยใคร ใน Job ไหน
Workflow Templates: Multi-step Automation
ทำไมต้องใช้ Workflow
ในโลกจริง Automation Task มักประกอบด้วยหลายขั้นตอนที่ต้อง Execute ตามลำดับ และบางขั้นตอนมี Dependency กัน ตัวอย่างเช่น Deployment Workflow อาจประกอบด้วย Step 1 Run Unit Test, Step 2 Build Application (ถ้า Test ผ่าน), Step 3 Deploy to Staging, Step 4 Run Integration Test, Step 5 Deploy to Production (ถ้า Integration Test ผ่าน), Step 6 Send Notification (ไม่ว่าจะ Success หรือ Fail)
Workflow Template ใน AWX ช่วยให้สร้าง Multi-step Automation ที่มี Conditional Logic ได้ โดยไม่ต้องเขียน Complex Playbook
การสร้าง Workflow Template
Workflow Template สร้างจาก Workflow Visualizer ที่เป็น Drag-and-Drop Interface แต่ละ Node ใน Workflow คือ Job Template, Project Sync, Inventory Sync หรือ Approval Node ที่รอ Manual Approval ก่อนดำเนินการต่อ
Connection ระหว่าง Node มี 3 ประเภท คือ Success (Execute Node ถัดไปเมื่อ Node ก่อนหน้า Succeed), Failure (Execute เมื่อ Node ก่อนหน้า Fail), และ Always (Execute ไม่ว่า Node ก่อนหน้าจะ Succeed หรือ Fail) ทำให้สามารถสร้าง Error Handling Logic ได้ เช่น ถ้า Deployment Fail ให้ Run Rollback Playbook
Workflow ยังสามารถ Converge ได้ คือ Node หนึ่งจะ Execute เมื่อ Node หลายตัวที่เป็น Dependency Execute สำเร็จทั้งหมด (ALL Convergence) และสามารถ Pass Variable ระหว่าง Node ได้ด้วย set_stats Module ทำให้ Output ของ Node หนึ่งเป็น Input ของ Node ถัดไป
RBAC: การจัดการสิทธิ์ในระดับ Enterprise
Organizations
Organization เป็น Top-level Unit ใน AWX สำหรับแบ่งแยก Resource ระหว่างหน่วยงาน แต่ละ Organization มี Inventory, Project, Credential, Template และ Team ของตัวเอง ใน Multi-tenant Environment สามารถสร้าง Organization แยกให้แต่ละ Business Unit หรือ Department เช่น Organization IT-Infrastructure, Organization Development, Organization Security
Teams
Team คือ Group ของ User ภายใน Organization ใช้สำหรับ Assign Permission เป็น Group แทนที่จะ Assign ให้ User แต่ละคน เช่น Team Network-Engineers มี Permission ใช้ Credential สำหรับ Network Device และ Run Job Template ที่เกี่ยวกับ Network Configuration ส่วน Team Linux-Admins มี Permission ใช้ Credential สำหรับ Linux Server และ Run Job Template ที่เกี่ยวกับ Server Management
Roles
AWX มี Role-based Access Control ที่ละเอียดมาก Role ใน AWX ไม่ใช่ Global Role แต่เป็น Object-level Role ที่ Assign ให้ User หรือ Team บน Object เฉพาะ ตัวอย่างเช่น User A มี Role Admin บน Inventory Production-Servers (จัดการ Host ใน Inventory นี้ได้) User A มี Role Execute บน Job Template Deploy-App (Run Job ได้แต่แก้ Template ไม่ได้) User A มี Role Use บน Credential SSH-Production (ใช้ Credential นี้ใน Job Template ได้แต่ดู Password ไม่ได้)
Role ที่มีใน AWX ได้แก่ Admin (Full Control บน Object), Execute (Run Job Template ได้), Use (ใช้ Object เช่น Credential, Inventory ใน Job Template ได้), Update (Sync Project หรือ Inventory ได้), Read (ดูข้อมูลได้อย่างเดียว), และ Approve (Approve Workflow Approval Node ได้)
RBAC ใน AWX ช่วยให้ Implement Principle of Least Privilege ได้อย่างมีประสิทธิภาพ ตัวอย่างเช่น Junior Engineer สามารถ Run Standard Job Template ได้ แต่ไม่สามารถแก้ไข Template หรือเข้าถึง Production Credential ได้ Senior Engineer สามารถ Create และ Edit Job Template ได้ แต่ต้องผ่าน Approval ก่อน Deploy to Production และ Manager สามารถ Approve Workflow แต่ไม่สามารถแก้ไข Technical Configuration ได้
Notifications: การแจ้งเตือนอัตโนมัติ
AWX สามารถส่ง Notification เมื่อ Job หรือ Workflow เสร็จสิ้น ไม่ว่าจะ Success หรือ Fail รองรับ Notification Type หลายรูปแบบ ได้แก่ Slack (ส่งข้อความไปยัง Slack Channel), Email (ส่ง Email ไปยัง Recipient ที่กำหนด), Microsoft Teams (ผ่าน Webhook), PagerDuty (สำหรับ Incident Management), Webhook (ส่ง HTTP POST ไปยัง URL ที่กำหนด เช่น Custom API), IRC, Mattermost, Rocket.Chat และ Twilio (SMS)
Notification Template สามารถ Customize Message ได้โดยใช้ Jinja2 Template เช่น รวม Job Name, Status, Execution Time, Host Summary และ Error Message ลงใน Notification ทำให้ทีมได้รับข้อมูลที่เพียงพอโดยไม่ต้อง Login เข้า AWX เพื่อดูรายละเอียด
สามารถ Assign Notification ได้ที่ 3 ระดับ คือ Organization Level (Notify ทุก Job ใน Organization), Job Template Level (Notify เฉพาะ Job จาก Template นี้), และ Workflow Level (Notify เมื่อ Workflow เสร็จ) แต่ละระดับสามารถกำหนด Notification แยกสำหรับ Success, Failure และ Start
Scheduling Automated Jobs: การ Schedule งานอัตโนมัติ
AWX มี Built-in Job Scheduler ที่ช่วยให้ Run Job Template หรือ Workflow Template ตามเวลาที่กำหนด โดยไม่ต้องพึ่ง External Scheduler เช่น Cron
Schedule สามารถกำหนดได้หลายรูปแบบ Run Once (Run ครั้งเดียวตามวันเวลาที่กำหนด), Recurring (Run ซ้ำตาม Pattern เช่น ทุกวัน, ทุกสัปดาห์, ทุกเดือน), Complex Pattern (ใช้ RRULE Format สำหรับ Pattern ที่ซับซ้อน เช่น ทุกวันจันทร์ถึงศุกร์ เวลา 02:00 น.), และ Timezone Aware (กำหนด Timezone ได้ เช่น Asia/Bangkok)
ตัวอย่าง Schedule ที่ใช้บ่อยใน Enterprise ได้แก่ Patch Tuesday (Run Patching Playbook ทุกวันอังคารที่ 2 ของเดือน), Daily Compliance Check (Run Compliance Scan ทุกวัน 06:00 น.), Backup Schedule (Run Backup Playbook ทุกคืน 22:00 น.), Certificate Renewal Check (ตรวจสอบ SSL Certificate ใกล้หมดอายุทุกวันจันทร์), และ Inventory Sync (Sync Dynamic Inventory จาก Cloud ทุก 30 นาที)
API และ CLI Usage
REST API
AWX มี REST API ที่ครอบคลุมทุก Feature โดย API Documentation สามารถเข้าถึงได้ที่ https://awx-host/api/v2/ API ใช้ Token-based Authentication หรือ Basic Authentication ทุก Operation ที่ทำได้บน Web UI สามารถทำผ่าน API ได้ทั้งหมด
ตัวอย่างการใช้ API เช่น Launch Job Template ด้วย curl สามารถ POST ไปที่ /api/v2/job_templates/{id}/launch/ พร้อม Extra Variables ในรูปแบบ JSON ได้ API Response จะ Return Job ID ที่สามารถใช้ Track Status ได้
API เหมาะสำหรับ Integration กับ CI/CD Pipeline เช่น Jenkins, GitLab CI, GitHub Actions สามารถ Trigger AWX Job จาก Pipeline เมื่อ Code ถูก Merge เข้า Main Branch หรือ Integration กับ ITSM Tool เช่น ServiceNow เพื่อ Auto-remediate Incident โดย ServiceNow สร้าง Incident แล้ว Trigger AWX Job ผ่าน API เพื่อ Fix ปัญหาอัตโนมัติ
AWX CLI (awxkit)
AWX มี CLI Tool ชื่อ awxkit ที่เป็น Python Package ติดตั้งด้วย pip install awxkit สามารถใช้ awx command เพื่อจัดการ AWX จาก Command Line ได้ทั้งหมด เช่น awx job_templates launch –name “Deploy App” –extra_vars ‘{“version”: “2.0”}’ CLI เหมาะสำหรับ Scripting และ Automation ที่ต้องการ Interact กับ AWX จาก Script
AWX + Git Integration: SCM-based Projects
การ Integrate AWX กับ Git เป็น Foundation ที่สำคัญที่สุดสำหรับ Infrastructure as Code (IaC) Practice ทุก Playbook, Role, Variable File และ Inventory File ควรถูกเก็บใน Git Repository
Workflow ที่แนะนำสำหรับ AWX + Git คือ Developer สร้าง Branch ใหม่จาก Main, เขียนหรือแก้ไข Playbook แล้ว Commit, สร้าง Pull Request (PR) ให้ Reviewer ตรวจสอบ, Reviewer Approve PR แล้ว Merge เข้า Main, AWX Auto-sync Project จาก Git (หรือ Sync เมื่อ Launch Job), Job Template ใช้ Playbook ล่าสุดจาก Main Branch
สำหรับ Multi-environment Setup (Dev, Staging, Production) สามารถใช้ Git Branch Strategy เช่น develop Branch สำหรับ Dev Environment, staging Branch สำหรับ Staging, main Branch สำหรับ Production สร้าง Project แยกใน AWX สำหรับแต่ละ Branch และ Job Template ของแต่ละ Environment ใช้ Project ที่ต่าง Branch กัน
Webhook Integration AWX รองรับ Webhook จาก GitHub, GitLab และ Bitbucket เมื่อมี Push หรือ Merge Event สามารถ Trigger Job Template ให้ Run อัตโนมัติ ทำให้ได้ Continuous Deployment Pipeline โดยไม่ต้องใช้ CI/CD Tool เพิ่มเติม
Survey Forms: Self-service Automation
Survey คือ Feature ที่ช่วยสร้าง Form สำหรับ User กรอกข้อมูลก่อน Launch Job เปรียบเสมือน Form ที่มี Text Field, Dropdown, Checkbox ให้ User เลือก ข้อมูลที่ User กรอกจะถูกส่งเป็น Extra Variables ให้ Playbook
Survey รองรับ Field Type หลายแบบ ได้แก่ Text (กรอกข้อความ), Textarea (กรอกข้อความหลายบรรทัด), Password (กรอก Password ที่จะถูก Mask), Integer (กรอกตัวเลข), Float (กรอกทศนิยม), Multiple Choice (เลือก 1 จากหลายตัวเลือก), และ Multiple Select (เลือกหลายตัวเลือก)
ตัวอย่างการใช้ Survey เช่น Job Template สำหรับ Create VM มี Survey ที่ถามชื่อ VM, CPU, RAM, Disk Size, Network และ OS Template User เพียงกรอก Form แล้ว Click Launch ระบบจะสร้าง VM ตาม Specification ที่กรอก โดย User ไม่ต้องรู้ Ansible Syntax เลย นี่คือ Self-service IT ที่ช่วยลด Workload ของ IT Team และเพิ่ม Speed of Delivery
อีกตัวอย่างคือ Job Template สำหรับ Onboard New Employee มี Survey ถามชื่อพนักงาน, Department, Role, ต้องการ Software อะไรบ้าง Playbook จะ Create AD Account, Create Email Account, Install Software, Set Permission ตาม Department และส่ง Welcome Email ทั้งหมดอัตโนมัติ
Logging and Auditing: การบันทึกและตรวจสอบ
AWX บันทึก Activity ทั้งหมดในระบบ ซึ่งเป็นสิ่งจำเป็นสำหรับ Compliance และ Security Audit ข้อมูลที่ถูกบันทึก ได้แก่ Job Activity Log (ใคร Run Job อะไร เมื่อไหร่ บน Host ไหน ผลลัพธ์เป็นอย่างไร), Job Output (Full Output ของ Ansible Playbook ทุกบรรทัด), User Activity (Login, Logout, Create, Modify, Delete Resource), System Event (Inventory Sync, Project Update, Schedule Trigger), และ Credential Usage (Credential ถูกใช้ใน Job ไหน เมื่อไหร่)
AWX สามารถส่ง Log ไปยัง External Log Aggregator ได้ รองรับ Splunk, Elastic Stack (ELK), Loggly, Sumologic และ Custom HTTP Endpoint ทำให้สามารถ Centralize AWX Log เข้ากับ SIEM ขององค์กรได้ การ Integrate AWX Log เข้า SIEM ช่วยให้ Security Team สามารถ Detect Anomaly เช่น User Run Job นอกเวลาทำงาน, Job ที่ Fail บ่อยผิดปกติ หรือมีการแก้ไข Production Template โดย Unauthorized User
AWX vs SemaphoreUI vs Rundeck: เปรียบเทียบ Automation Platform
SemaphoreUI
SemaphoreUI (เดิมชื่อ Ansible Semaphore) เป็น Open-source Web UI สำหรับ Ansible เขียนด้วย Go ทำให้ Lightweight มากกว่า AWX ใช้ Resource น้อยกว่ามาก (RAM 512 MB ก็พอ ในขณะที่ AWX ต้อง 8 GB ขึ้นไป) ติดตั้งง่ายมาก เพียง Single Binary หรือ Docker Container เดียว
ข้อจำกัดของ SemaphoreUI เมื่อเทียบกับ AWX คือ ไม่มี RBAC ที่ละเอียดเท่า AWX, ไม่มี Workflow Template, ไม่มี Dynamic Inventory Plugin, ไม่มี Survey Form, API ไม่ครอบคลุมเท่า AWX, ไม่มี Credential Injection ที่ปลอดภัยเท่า AWX SemaphoreUI เหมาะสำหรับทีมขนาดเล็ก (1-5 คน) ที่ต้องการ Web UI สำหรับ Ansible โดยไม่ต้องการ Feature ระดับ Enterprise
Rundeck
Rundeck เป็น Open-source Job Scheduler และ Runbook Automation Tool ที่ไม่ได้ผูกกับ Ansible โดยเฉพาะ สามารถ Execute Script, Command หรือ Workflow บน Remote Server ได้ Rundeck มี Plugin System ที่รองรับหลาย Executor เช่น SSH, WinRM, Ansible, Docker, Kubernetes
ข้อดีของ Rundeck เทียบกับ AWX คือ ไม่ผูกกับ Ansible สามารถใช้กับ Script หรือ Tool อื่นได้, มี Access Control Policy ที่ยืดหยุ่น, รองรับ Key-Value Storage สำหรับ Secret, และ Community Edition ใช้ได้ฟรี ข้อเสียคือ ไม่ได้ Optimize สำหรับ Ansible โดยเฉพาะ, UI ไม่ Modern เท่า AWX, และ Ansible Integration ไม่ Deep เท่า AWX
สรุปว่า ถ้าองค์กรใช้ Ansible เป็นหลัก AWX เป็นตัวเลือกที่ดีที่สุด ถ้าต้องการ Lightweight UI สำหรับทีมเล็ก SemaphoreUI เหมาะกว่า ถ้าต้องการ Multi-tool Automation ที่ไม่ผูกกับ Ansible Rundeck เป็นทางเลือก
Scaling AWX: การขยายระบบรองรับงานขนาดใหญ่
Horizontal Scaling
AWX บน Kubernetes สามารถ Scale ได้โดย Increase Replica ของ Task Pod เพื่อรองรับ Concurrent Job ที่มากขึ้น AWX ใช้ Redis เป็น Queue ระบบจะ Distribute Job ไปยัง Task Pod ที่ว่างอัตโนมัติ สามารถตั้ง Instance Group เพื่อแยก Execution Pool เช่น Instance Group “network” สำหรับ Job ที่ Run กับ Network Device และ Instance Group “servers” สำหรับ Job ที่ Run กับ Server
Execution Environment
ใน AWX Version ล่าสุด ใช้ Execution Environment (EE) ซึ่งเป็น Container Image ที่มี Ansible, Python Library และ Collection ที่ต้องการ ติดตั้งไว้พร้อม EE ช่วยแก้ปัญหา Dependency Conflict เพราะแต่ละ Job Template สามารถใช้ EE คนละตัวได้ เช่น EE สำหรับ Network Automation มี netmiko, paramiko, napalm ติดตั้ง ส่วน EE สำหรับ Cloud Automation มี boto3, azure-mgmt, google-cloud ติดตั้ง
สามารถ Build Custom EE ด้วย ansible-builder โดยสร้าง execution-environment.yml ที่กำหนด Base Image, Python Package, System Package และ Ansible Collection ที่ต้องการ จากนั้น Run ansible-builder build เพื่อสร้าง Container Image แล้ว Push ไปยัง Container Registry ที่ AWX สามารถ Pull มาใช้ได้
Database Optimization
PostgreSQL เป็น Database Backend ของ AWX สำหรับ Production ควร Tune PostgreSQL ให้เหมาะกับ Workload ตั้งค่า shared_buffers, work_mem, effective_cache_size ให้เหมาะกับ RAM ที่มี ใช้ Connection Pooler เช่น PgBouncer สำหรับ High Concurrency และ Set up Backup Schedule สำหรับ Database เป็นประจำ
Best Practices สำหรับ Enterprise Deployment
Architecture Design
สำหรับ Enterprise Deployment ควรวาง Architecture ดังนี้ ใช้ Kubernetes สำหรับ Deploy AWX เพื่อ High Availability และ Scalability แยก PostgreSQL Database ออกมาเป็น Managed Database (เช่น RDS ถ้าบน AWS) หรือ Dedicated Server ใช้ External Redis (เช่น ElastiCache) แทน Embedded Redis ตั้ง Load Balancer หน้า AWX Web Service สำหรับ SSL Termination และ High Availability ใช้ Shared Storage (NFS, S3) สำหรับ Project Directory ถ้ามี Task Pod หลายตัว
Security Hardening
ใน Production ควร Harden AWX ดังนี้ Enable HTTPS (TLS 1.2+) สำหรับ Web UI และ API, Integrate กับ Enterprise IdP (LDAP, SAML, OIDC) สำหรับ Authentication แทนการใช้ Local User, Enable MFA (Multi-Factor Authentication) สำหรับ Admin Account, ใช้ External Credential Lookup Plugin (HashiCorp Vault, CyberArk, Azure Key Vault) แทนการเก็บ Credential ใน AWX Database โดยตรง, กำหนด Session Timeout และ Password Policy, ใช้ Network Policy (ถ้าบน Kubernetes) เพื่อจำกัด Network Access ไปยัง AWX Pod, และ Regular Update AWX Version เพื่อรับ Security Patch
Organization Design
สำหรับองค์กรขนาดใหญ่ ควรวาง Organization Structure ใน AWX ตาม Business Unit หรือ Department สร้าง Team ตาม Role เช่น Network-Admins, Linux-Admins, Windows-Admins, DBA, Security Assign Permission ตาม Principle of Least Privilege ใช้ Naming Convention ที่ชัดเจนสำหรับทุก Object เช่น [ENV]-[APP]-[ACTION] เช่น PROD-WebApp-Deploy, DEV-Database-Backup Document RBAC Matrix ให้ชัดเจนว่า Team ไหนมี Permission อะไรบน Object ไหน
Playbook Development Workflow
กำหนด Standard Workflow สำหรับ Playbook Development ดังนี้ ใช้ Git Feature Branch สำหรับ Development, ใช้ ansible-lint และ yamllint ใน Pre-commit Hook เพื่อตรวจสอบ Code Quality, ใช้ Molecule สำหรับ Test Playbook ใน CI Pipeline, Code Review ทุก PR ก่อน Merge, ใช้ ansible-vault สำหรับ Encrypt Sensitive Data ใน Repository, แยก Variable File ตาม Environment (group_vars/dev, group_vars/staging, group_vars/prod), ใช้ Ansible Collection สำหรับ Reusable Role แทนการ Copy-paste
Monitoring AWX
AWX Expose Metrics ที่ /api/v2/metrics/ ในรูปแบบ Prometheus-compatible สามารถ Scrape ด้วย Prometheus แล้วสร้าง Grafana Dashboard สำหรับ Monitor AWX Metrics ที่ควร Monitor ได้แก่ Job Success/Failure Rate, Job Execution Time, Queue Length (จำนวน Job ที่รอ Execute), Active Sessions, Database Connection Pool, และ API Response Time
ตั้ง Alert สำหรับ Critical Metric เช่น Job Failure Rate สูงกว่า Threshold, Queue Length เพิ่มขึ้นต่อเนื่อง (อาจเป็นสัญญาณว่า Execution Capacity ไม่พอ), Database Connection Exhausted, และ AWX Pod Restart บ่อย
สรุป: AWX และ Tower สำหรับ Enterprise Automation ในปี 2026
Ansible AWX และ Ansible Automation Platform (Tower) เป็นเครื่องมือที่จำเป็นสำหรับองค์กรที่ต้องการ Scale Ansible Automation จาก Individual Use ไปเป็น Enterprise-wide Practice Web UI ช่วยให้ Non-technical User สามารถ Run Automation ได้ RBAC ช่วยควบคุมสิทธิ์ Audit Log ช่วยตรวจสอบ Credential Management ช่วยรักษาความปลอดภัย และ API ช่วยให้ Integrate กับ Tool อื่นได้
สำหรับองค์กรในไทยที่เริ่มต้น แนะนำให้เริ่มจาก AWX บน Docker Compose สำหรับ Lab และ POC จากนั้น Deploy AWX บน Kubernetes สำหรับ Production ถ้าต้องการ Support Agreement และ Certified Content ค่อยพิจารณา Upgrade เป็น Ansible Automation Platform
Key Takeaway สำหรับ IT Admin คือ เริ่มจากจัดระเบียบ Playbook ใน Git Repository ก่อน Install AWX, สร้าง Inventory ที่เป็น Dynamic จาก Infrastructure ที่มี, ใช้ Credential Management ของ AWX แทนการเก็บ SSH Key บนเครื่อง Engineer, สร้าง Job Template สำหรับงาน Routine ทุกอย่าง, ใช้ Survey Form สำหรับ Self-service Task, วาง RBAC ตาม Team Structure ขององค์กร, Monitor Job ด้วย Notification และ Log Aggregation, และ Iterate ปรับปรุง Automation อย่างต่อเนื่อง AWX ไม่ใช่แค่เครื่องมือ แต่เป็น Platform ที่เปลี่ยน Culture ขององค์กรให้เป็น Automation-first ในปี 2026 องค์กรที่ไม่ Automate จะตามไม่ทัน
