Techerest

Ansible for Cisco Network Automation: Inventory, Playbook และ Compliance

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 R1

2. เตรียม 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 list

Collection และ 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.12

IP 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 State

8. 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 this
Facebook Share X
TECHEREST COMMUNITY

Share your thoughts here

Join the conversation and share your perspective on this article.

Comments will load when you reach this section.