Nếu phải SSH vào 50 switch để cấu hình cùng một thay đổi, CLI vẫn làm được. Nhưng khi số lượng tăng lên hàng trăm thiết bị, Automation trở thành cách vận hành hạ tầng hiệu quả hơn.
Hình trên mô tả khá rõ kiến trúc Ansible và lý do công cụ này được sử dụng nhiều trong DevOps, NetDevOps và Infrastructure Automation.
Ansible sử dụng Agentless + Push
Điểm nổi bật của Ansible là agentless: không cần cài Ansible Agent trên từng switch, router hay server.
Thay vào đó, Ansible Control Node chủ động kết nối và đẩy các tác vụ xuống thiết bị khi Playbook được chạy. Đây gọi là Push Model.
Với thiết bị mạng, Ansible có thể giao tiếp thông qua SSH/CLI hoặc API, tùy platform và module/collection.
Inventory – Ansible quản lý thiết bị nào?
Ansible sử dụng Inventory để xác định danh sách node cần quản lý.
Ví dụ:
[nexus]
leaf01
leaf02
spine01
spine02
[aci]
apic01
Nhờ Inventory, kỹ sư có thể thực hiện cùng một automation workflow trên nhiều thiết bị mà không phải SSH vào từng node.
Playbook – mô tả công việc cần thực hiện
Ansible sử dụng Playbook viết bằng YAML. Một Playbook chứa nhiều Task, mỗi Task mô tả một hành động.
Ví dụ:
tasks:
- name: Create Tenant
aci_tenant:
host: 192.168.0.1
username: admin
tenant: New_Tenant
Trong Production, password/secret không nên hard-code trong Playbook mà nên quản lý bằng Ansible Vault hoặc secret manager.
Module và Plugin
Module giúp Ansible thực hiện những tác vụ cụ thể như:
Thay vì phải tự viết toàn bộ logic bằng Python, Network Engineer có thể sử dụng module/collection có sẵn và mô tả công việc bằng YAML. Đây là một lý do Ansible tương đối dễ tiếp cận với kỹ sư mạng.
Từ CLI đến Network as Code
Mô hình truyền thống:
Engineer → SSH → CLI → Switch
Với Automation:
Engineer
↓
Git / YAML Playbook
↓
Ansible
↓
API / SSH
↓
Network Infrastructure
Cấu hình mạng giờ đây có thể được version control, review, test và triển khai đồng nhất trên nhiều thiết bị.
Ansible cũng có thể trở thành một phần của CI/CD:
Git Commit
↓
CI/CD Pipeline
↓
Lint / Validate → Test
↓
Ansible Playbook
↓
Network Infrastructure
↓
Post-Deployment Validation
Như vậy, thay đổi cấu hình không còn chỉ là SSH vào thiết bị rồi gõ lệnh. Nó trở thành một quy trình có thể kiểm thử, quản lý phiên bản, audit và tự động hóa.
Đó là lý do Ansible thường là một trong những công cụ đầu tiên mà kỹ sư Network/DevNet/Automation nên học khi chuyển từ CLI sang Infrastructure as Code và Network as Code.
Hình trên mô tả khá rõ kiến trúc Ansible và lý do công cụ này được sử dụng nhiều trong DevOps, NetDevOps và Infrastructure Automation.
Ansible sử dụng Agentless + Push
Điểm nổi bật của Ansible là agentless: không cần cài Ansible Agent trên từng switch, router hay server.
Thay vào đó, Ansible Control Node chủ động kết nối và đẩy các tác vụ xuống thiết bị khi Playbook được chạy. Đây gọi là Push Model.
Với thiết bị mạng, Ansible có thể giao tiếp thông qua SSH/CLI hoặc API, tùy platform và module/collection.
Inventory – Ansible quản lý thiết bị nào?
Ansible sử dụng Inventory để xác định danh sách node cần quản lý.
Ví dụ:
[nexus]
leaf01
leaf02
spine01
spine02
[aci]
apic01
Nhờ Inventory, kỹ sư có thể thực hiện cùng một automation workflow trên nhiều thiết bị mà không phải SSH vào từng node.
Playbook – mô tả công việc cần thực hiện
Ansible sử dụng Playbook viết bằng YAML. Một Playbook chứa nhiều Task, mỗi Task mô tả một hành động.
Ví dụ:
tasks:
- name: Create Tenant
aci_tenant:
host: 192.168.0.1
username: admin
tenant: New_Tenant
Trong Production, password/secret không nên hard-code trong Playbook mà nên quản lý bằng Ansible Vault hoặc secret manager.
Module và Plugin
Module giúp Ansible thực hiện những tác vụ cụ thể như:
- Create VLAN
- Configure Interface
- Deploy ACL
- Configure BGP
- Collect device facts
- Create ACI Tenant
Thay vì phải tự viết toàn bộ logic bằng Python, Network Engineer có thể sử dụng module/collection có sẵn và mô tả công việc bằng YAML. Đây là một lý do Ansible tương đối dễ tiếp cận với kỹ sư mạng.
Từ CLI đến Network as Code
Mô hình truyền thống:
Engineer → SSH → CLI → Switch
Với Automation:
Engineer
↓
Git / YAML Playbook
↓
Ansible
↓
API / SSH
↓
Network Infrastructure
Cấu hình mạng giờ đây có thể được version control, review, test và triển khai đồng nhất trên nhiều thiết bị.
Ansible cũng có thể trở thành một phần của CI/CD:
Git Commit
↓
CI/CD Pipeline
↓
Lint / Validate → Test
↓
Ansible Playbook
↓
Network Infrastructure
↓
Post-Deployment Validation
Như vậy, thay đổi cấu hình không còn chỉ là SSH vào thiết bị rồi gõ lệnh. Nó trở thành một quy trình có thể kiểm thử, quản lý phiên bản, audit và tự động hóa.
Đó là lý do Ansible thường là một trong những công cụ đầu tiên mà kỹ sư Network/DevNet/Automation nên học khi chuyển từ CLI sang Infrastructure as Code và Network as Code.