Từ CLI sang YAML: Infrastructure as Code dành cho Network Engineer

[Nguyễn Văn Đông]

1️⃣ Infrastructure as Code (IaC) là gì?


Infrastructure as Code (IaC) là phương pháp biểu diễn và quản lý hạ tầng CNTT dưới dạng code, thường là các file YAML hoặc JSON, để các công cụ tự động có thể đọc và triển khai cấu hình.

IaC không chỉ áp dụng cho hạ tầng mạng, mà còn cho:

• Server
• Cloud resources
• Firewall, Load Balancer…

Trong lĩnh vực mạng, IaC đôi khi được gọi là Network as Code (NaC), nhưng về bản chất đây là cùng một khái niệm.

👉 IaC là thành phần cốt lõi của NetDevOps.

---

2️⃣ IaC mang lại điều gì cho Network Engineer?


Trước đây, Network Engineer thường:

• SSH vào từng thiết bị
• Cấu hình thủ công qua CLI
• Khó kiểm soát thay đổi, khó rollback

Với IaC:

• Cấu hình được viết dưới dạng file máy đọc được
• Mọi thay đổi được quản lý như source code
• Áp dụng quy trình DevOps cho vận hành mạng

Các file YAML/JSON chứa các key–value đại diện cho cấu hình mạng, ví dụ:

• IP address của interface
• BGP AS number
• VRF route distinguisher
• Prefix-list, VLAN, routing policy…

Những dữ liệu này có thể:

• Do Network Engineer nhập
• Hoặc lấy từ các hệ thống trung tâm như:
  • IPAM
  • Inventory Database
  • ITSM / OSS / BSS

---

3️⃣ Lợi ích nổi bật của Infrastructure as Code


✔ Cấu hình được lưu trữ trong GitHub / GitLab
✔ Có thể validate & test trước khi đưa vào production
✔ Theo dõi lịch sử thay đổi (versioning)
✔ Dễ dàng rollback khi có sự cố
✔ Tự động hóa, giảm lỗi con người

👉 Cấu hình mạng trở thành code có kiểm soát, không còn là các lệnh rời rạc trên thiết bị.

---

4️⃣ Vì sao Source Control (Git) lại quan trọng?


Khi hạ tầng được lưu trong hệ thống source control:

• Có lịch sử ai thay đổi – thay đổi cái gì – khi nào
• Có peer review & approval trước khi triển khai
• Có thể tích hợp CI/CD để:
  • Kiểm tra cú pháp
  • Validate cấu hình
  • Ngăn lỗi trước khi vào production

Nếu một thay đổi gây lỗi:
👉 Chỉ cần rollback về version trước và triển khai lại.

Ngoài ra, Git còn đóng vai trò là tài liệu sống (self-documenting) cho toàn bộ hệ thống mạng.

---

5️⃣ Ví dụ IaC – Cấu hình OSPF đơn giản bằng YAML

---
ospf:
process_id: 1
router_id: "1.1.1.1"

networks:
- network: "10.10.1.0"
wildcard: "0.0.0.255"
area: 0
- network: "10.10.2.0"
wildcard: "0.0.0.255"
area: 0
---
Giải thích dễ nhớ:

• process_id: ID của tiến trình OSPF
• router_id: Router ID của thiết bị
• networks: danh sách các mạng tham gia OSPF
  • network: địa chỉ mạng
  • wildcard: wildcard mask
  • area: OSPF area

👉 File YAML này sẽ được công cụ cấu hình (ví dụ Ansible) đọc và tự động sinh ra các lệnh OSPF tương ứng trên router.

---

6️⃣ Source of Truth – Yếu tố sống còn khi làm IaC


Để triển khai IaC thành công, tổ chức bắt buộc phải xác định rõ Single Source of Truth (SSoT).

❗ Cấu hình trên thiết bị KHÔNG còn là source of truth

Thay vào đó:

• Mỗi loại dữ liệu chỉ có 1 nguồn duy nhất
• Ví dụ:
  • IPAM → Source of Truth cho IP, subnet
  • Active Directory / Cisco ISE → Source of Truth cho security
  • Git Repository → Source of Truth cho cấu hình mạng

Nếu cấu hình trên thiết bị khác với IaC system:
👉 Thiết bị phải được cập nhật để khớp với Source of Truth, thủ công hoặc tự động qua NetDevOps pipeline.

---

7️⃣ Nguyên tắc quan trọng về Source of Truth

• Thiết bị không phải là nơi quyết định cấu hình
• Hệ thống audit so sánh thiết bị với Source of Truth
• Thiết bị được cấu hình từ dữ liệu trung tâm
• Mỗi data domain chỉ có 1 Source of Truth

---

8️⃣ Kết luận


Infrastructure as Code giúp Network Engineer:

• Làm mạng nhanh hơn – chuẩn hơn – an toàn hơn
• Áp dụng tư duy DevOps vào vận hành mạng
• Sẵn sàng cho NetDevOps và Automation

👉 Network Engineer hiện đại không chỉ biết CLI, mà còn phải biết Code.