Ansible for Cisco Network Automation ช่วยให้ Network Engineer จัดการอุปกรณ์หลายตัวด้วย Inventory และ YAML Playbook แทนการล็อกอินเพื่อรันคำสั่งซ้ำทีละเครื่อง บทความนี้เน้นการสำรอง Configuration, ตรวจสอบ Compliance และควบคุมการเปลี่ยนแปลงอย่างปลอดภัยบน Cisco IOS/IOS XE
1. Ansible คืออะไร และต่างจาก Python/Netmiko อย่างไร?
Ansible เป็น Automation Framework ที่ใช้ Inventory ระบุเป้าหมายและ Playbook อธิบายงานที่ต้องทำ สำหรับ Network Device สามารถใช้ Collection เฉพาะ Vendor เช่น cisco.ios โดยเชื่อมต่อผ่าน SSH และ Network CLI แทนการติดตั้ง Agent บน Switch
Python/Netmiko เหมาะกับการเขียน Workflow แบบกำหนดเอง ส่วน Ansible เหมาะกับงานที่ต้องการโครงสร้างซ้ำได้ ตรวจสอบได้ และจัดการหลายอุปกรณ์ด้วย Playbook เดียว ทั้งสองเครื่องมือใช้ร่วมกันได้ ไม่จำเป็นต้องเลือกเพียงอย่างใดอย่างหนึ่ง
Engineer / Git Repository
|
v
Ansible Control Node (Linux / WSL)
|
+---- SSH ---- Cisco Switch SW1
|
+---- SSH ---- Cisco Switch SW2
|
+---- SSH ---- Cisco Router R12. เตรียม Lab และติดตั้งเครื่องมือ
ตัวอย่างใช้ Linux หรือ Windows Subsystem for Linux (WSL) เป็น Control Node และ Cisco IOS/IOS XE ที่เปิด SSH และมีบัญชีที่ได้รับอนุญาตแล้ว ทดสอบกับอุปกรณ์ Lab ก่อน Production ทุกครั้ง
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install ansible-core
ansible-galaxy collection install cisco.ios ansible.netcommon
ansible --version
ansible-galaxy collection listCollection และ ansible-core มี Compatibility Requirements แตกต่างกันตามรุ่น ควร Pin Versions ใน Project และตรวจ Release Notes ก่อนใช้งานจริง
โครงสร้าง Project
cisco-ansible/
├── ansible.cfg
├── inventory.yml
├── group_vars/
│ └── cisco_ios.yml
├── playbooks/
│ ├── audit.yml
│ ├── backup.yml
│ ├── compliance.yml
│ └── change.yml
└── backups/โฟลเดอร์ backups/ ต้องถูกควบคุมสิทธิ์และไม่ควร Commit ขึ้น Public Repository เพราะ Running Configuration อาจมีข้อมูลสำคัญ
3. สร้าง Inventory และตั้งค่า SSH Connection
inventory.yml
all:
children:
cisco_ios:
hosts:
sw1:
ansible_host: 192.0.2.11
sw2:
ansible_host: 192.0.2.12IP 192.0.2.0/24 เป็นช่วงสำหรับเอกสารตัวอย่าง ให้เปลี่ยนเป็น Management IP ของ Lab ที่ได้รับอนุญาต
group_vars/cisco_ios.yml
ansible_connection: ansible.netcommon.network_cli
ansible_network_os: cisco.ios.ios
ansible_user: netops
ansible_password: "{{ vault_network_password }}"
ansible_become: true
ansible_become_method: enable
ansible_become_password: "{{ vault_enable_password }}"เก็บ vault_network_password และ vault_enable_password ใน Ansible Vault หรือ Secret Manager ไม่ใส่รหัสผ่านจริงใน Inventory ที่เผยแพร่
ansible.cfg
[defaults]
inventory = inventory.yml
host_key_checking = True
retry_files_enabled = Falseอย่าปิด Host Key Checking เพื่อแก้ปัญหา SSH อย่างถาวร ให้ตรวจและบันทึก Host Key ของอุปกรณ์ที่เชื่อถือได้ก่อนเริ่ม Automation
4. Lab 1 — Read-Only Network Audit
เริ่มจากคำสั่งที่ไม่เปลี่ยน Configuration เช่น show version และ show interfaces status ซึ่งคำสั่งหลังมีความพร้อมใช้งานแตกต่างกันตาม Platform
playbooks/audit.yml
---
- name: Cisco read-only audit
hosts: cisco_ios
gather_facts: false
tasks:
- name: Collect device information
cisco.ios.ios_command:
commands:
- show version
- show ip interface brief
register: audit_result
- name: Display interface summary
ansible.builtin.debug:
msg: "{{ audit_result.stdout[1] }}"รัน Playbook
ansible-playbook playbooks/audit.yml --ask-vault-passตัวอย่างนี้สมมติว่ามีไฟล์ Vault ที่โหลดเข้าสู่ Project แล้ว เช่นผ่าน vars_files หรือการตั้งค่าที่เหมาะสม หากไม่ได้โหลดตัวแปร Vault จะเกิด Undefined Variable Error
ให้ตรวจ Inventory และการเชื่อมต่อด้วย ansible-inventory --graph และใช้ Playbook แบบ Read-Only เป็นจุดเริ่มต้นก่อนสั่งเปลี่ยนค่า
5. Lab 2 — Configuration Backup หลายอุปกรณ์
Module cisco.ios.ios_config รองรับการสำรอง Running Configuration ด้วย backup: true โดยไม่ได้เปลี่ยน Configuration เมื่อใช้เพื่อ Backup เพียงอย่างเดียว
playbooks/backup.yml
---
- name: Back up Cisco configurations
hosts: cisco_ios
gather_facts: false
tasks:
- name: Save running configuration
cisco.ios.ios_config:
backup: true
backup_options:
dir_path: ./backups
filename: "{{ inventory_hostname }}-running.cfg"ข้อควรระวัง: ชื่อไฟล์คงที่อาจถูกเขียนทับเมื่อรันซ้ำ ควรใช้ Versioned Backup, Timestamp หรือระบบจัดเก็บที่มี Retention Policy ใน Production และตรวจสอบว่า Backup ครบทุก Device
ansible-playbook playbooks/backup.yml --ask-vault-passการ Backup ไม่ใช่การ Restore โดยอัตโนมัติ ต้องทดสอบขั้นตอน Recovery และตรวจความถูกต้องของ Configuration ก่อนนำกลับไปใช้
6. Lab 3 — Configuration Compliance
ตัวอย่างตรวจว่ามีการตั้งค่า SSH Version 2 และ Logging ตาม Baseline หรือไม่ การตรวจด้วยข้อความเหมาะกับ Lab เบื้องต้น แต่ Production ควรคำนึงถึง Syntax Variation และ Context ของ Configuration
playbooks/compliance.yml
---
- name: Basic Cisco compliance check
hosts: cisco_ios
gather_facts: false
tasks:
- name: Read relevant running configuration
cisco.ios.ios_command:
commands:
- show running-config | include ^ip ssh version|^logging host
register: config_check
- name: Verify SSH v2 setting exists
ansible.builtin.assert:
that:
- "'ip ssh version 2' in config_check.stdout[0]"
fail_msg: "SSH v2 baseline not found"
success_msg: "SSH v2 baseline found"การไม่พบ ip ssh version 2 ใน Running Configuration ไม่ได้พิสูจน์ว่าอุปกรณ์กำลังใช้ SSHv1 เสมอไป เพราะ Default Behavior อาจแตกต่างตาม Release ต้องตรวจ Operational State และ Vendor Documentation ประกอบ
เมื่อทำ Compliance จริง ควรสร้างตาราง Control ID → Expected State → Evidence → Pass/Fail → Remediation เพื่อใช้เป็นหลักฐาน Audit และติดตามการแก้ไข
7. Lab 4 — Change Control และ Configuration Deployment
ก่อนเปลี่ยน Configuration ให้กำหนด Scope, Approved Change Window, Backup, Peer Review, Verification และ Rollback Plan ตัวอย่างต่อไปนี้ใช้กับ Lab เท่านั้น
playbooks/change.yml
---
- name: Configure lab interface description
hosts: cisco_ios
gather_facts: false
serial: 1
tasks:
- name: Update interface description
cisco.ios.ios_config:
parents: interface GigabitEthernet1/0/1
lines:
- description LAB-AUTOMATION-TEST
register: change_result
- name: Show change result
ansible.builtin.debug:
var: change_result.changedคำสั่งนี้เปลี่ยน Description ของ Interface จริง หาก Port ที่ระบุมีอยู่ จึงต้องตรวจ Interface Mapping และอนุมัติการเปลี่ยนแปลงก่อนใช้กับอุปกรณ์ Production
ตรวจ Syntax และ Scope
ansible-playbook playbooks/change.yml --syntax-check
ansible-playbook playbooks/change.yml --list-hostsบาง Network Module รองรับ Check Mode และ Diff Mode แต่ไม่ควรถือว่าผล Preview เป็นการรับประกันว่าอุปกรณ์จะยอมรับคำสั่งทุกกรณี ต้องตรวจพฤติกรรมของ Collection และ Platform ที่ใช้งาน
ขั้นตอน Rollback
บันทึก Description เดิมก่อนเปลี่ยน หากต้องย้อนกลับ ให้ Deploy ค่าเดิมผ่าน Playbook ที่ผ่านการตรวจสอบ แทนการสั่ง no description โดยไม่ทราบค่าเดิม
Before Change
|
v
Backup + Approval
|
v
Deploy One Device
|
v
Verify Connectivity and Config
|
+-- PASS --> Continue
|
+-- FAIL --> Restore Approved State8. Verification และ Troubleshooting
ตรวจการเชื่อมต่อ SSH
หาก Playbook Timeout ให้ตรวจ Management IP, Route, ACL, SSH Service, Credentials และ Privilege Level รวมถึงการเชื่อถือ Host Key
ตรวจ Module และ Collection
ansible-doc cisco.ios.ios_command
ansible-doc cisco.ios.ios_config
ansible-galaxy collection listตรวจ YAML และ Inventory
ansible-inventory --graph
ansible-playbook playbooks/audit.yml --syntax-checkวิเคราะห์ Failure ตามลำดับ
Inventory Correct?
|
SSH Reachable?
|
Authentication Works?
|
Enable Privilege Available?
|
Module / Collection Compatible?
|
Command Supported by Platform?
|
Expected Output Received?หากใช้ Verbose Logging เช่น -vvv ต้องระวังข้อมูลสำคัญที่อาจปรากฏใน Log และจำกัดการเผยแพร่ผลลัพธ์
9. Security และ Production Best Practices
- Least Privilege: ใช้บัญชี Automation ที่มีสิทธิ์เท่าที่จำเป็น และแยก Read-Only กับ Change Account ตามความสามารถของ Platform
- Secrets Management: ใช้ Ansible Vault หรือ Secret Manager และห้าม Commit Credentials ลง Git
- Source Control: จัดเก็บ Playbook ใน Git พร้อม Pull Request และ Peer Review
- Idempotency: ออกแบบให้รันซ้ำแล้วไม่เปลี่ยนค่าโดยไม่จำเป็น และตรวจว่า Module ที่ใช้รองรับพฤติกรรมดังกล่าวจริง
- Staged Deployment: ทดสอบ Lab → Pilot Device → Production Batch และกำหนด
serialเมื่อเหมาะสม - Backup and Recovery: สำรองก่อนเปลี่ยน ตรวจ Backup และทดสอบ Rollback
- Audit Trail: เก็บ Job Result, Device, เวลา, Change Ticket และผู้อนุมัติ
- Network Safety: หลีกเลี่ยงการแก้ Uplink, Management VLAN, AAA หรือ Routing พร้อมกันหลายอุปกรณ์โดยไม่มี Out-of-Band Access
10. FAQ
Ansible ใช้กับ Cisco Switch ได้หรือไม่?
ได้ หากรุ่นและ Software รองรับวิธีเชื่อมต่อและ Module ที่เลือก เช่น SSH Network CLI สำหรับ IOS/IOS XE
ต้องติดตั้ง Agent บน Cisco Switch หรือไม่?
โดยทั่วไปไม่ต้องสำหรับ Network CLI Automation เพราะ Control Node เชื่อมต่อไปยังอุปกรณ์ผ่าน SSH
Ansible ฟรีหรือไม่?
ansible-core เป็น Open-Source Software ส่วน Automation Platform เชิงพาณิชย์และบริการเสริมอาจมีค่าใช้จ่าย
ควรใช้ Ansible หรือ Netmiko?
Netmiko เหมาะกับ Python Script แบบกำหนดเอง ส่วน Ansible เหมาะกับงานหลายอุปกรณ์ที่ใช้ Inventory และ Declarative/Task-Based Playbook ทั้งสองใช้ร่วมกันได้
Check Mode ปลอดภัย 100% หรือไม่?
ไม่ควรสรุปเช่นนั้น การรองรับขึ้นกับ Module และอุปกรณ์ และไม่สามารถจำลองผลกระทบทุกอย่างของ Production Change ได้
11. บทสรุป
Ansible ช่วยเปลี่ยนงาน Network Operations ที่ทำซ้ำให้เป็นกระบวนการที่ตรวจสอบและควบคุมได้ โดยเริ่มจาก Inventory → Read-Only Audit → Backup → Compliance → Approved Change → Verification และ Rollback
Inventory
|
Read-Only Audit
|
Configuration Backup
|
Compliance Report
|
Approved Change
|
Verification
|
Audit Trail / Rollbackสำหรับ Production ควรเริ่มจากอุปกรณ์ Lab และงาน Read-Only ก่อนเสมอ โดยเฉพาะระบบเครือข่ายที่ให้บริการต่อเนื่องและไม่สามารถหยุดทำงานได้ง่าย
บทความถัดไป: Wireshark Packet Analysis สำหรับ Network Engineer — Capture, Display Filters, TCP Handshake, DNS, ICMP และ Troubleshooting
Share your thoughts here
Join the conversation and share your perspective on this article.