Posted inNetworking

Tự động hóa mạng đa thiết bị: Ngừng vật lộn với CLI nhờ NAPALM và Python

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

Cơn ác mộng CLI trên hệ thống đa thiết bị

Quản lý một mạng lưới chỉ dùng thiết bị của một hãng đã đủ khó rồi. Nhưng thực tế, hầu hết các tủ rack vận hành hiện nay là sự kết hợp “tốt nhất từ nhiều nguồn” giữa Cisco IOS, Juniper Junos và Arista EOS. Điều này thường có nghĩa là bạn phải giữ ba bảng tra cứu khác nhau cho cùng một thay đổi VLAN cơ bản. Mỗi hãng có cú pháp riêng, cách xử lý commit riêng và định dạng đầu ra lộn xộn riêng cho những tác vụ đơn giản như kiểm tra trạng thái interface.

Quý trước, đội ngũ của tôi đã mất gần 15 giờ mỗi tuần chỉ để phân tích văn bản từ các lệnh show nhằm xác minh trạng thái cổng trong quá trình kiểm tra. Việc này rất tẻ nhạt và dễ gây sai sót. Để khắc phục, chúng tôi đã tích hợp NAPALM vào quy trình làm việc. Kể từ khi chuyển sang mô hình này, tính nhất quán trong cấu hình của chúng tôi đã tăng vọt. Giờ đây, chúng tôi coi cơ sở hạ tầng của mình như mã nguồn có phiên bản (versioned code) thay vì một tập hợp các thiết bị “snowflake” được cấu hình thủ công và riêng biệt.

Các khái niệm cốt lõi: Tại sao nên chọn NAPALM?

NAPALM là viết tắt của Network Automation and Programmability Abstraction Layer with Multivendor support (Lớp trừu tượng hóa lập trình và tự động hóa mạng hỗ trợ đa thiết bị). Hãy coi nó như một trình biên dịch vạn năng cho phần cứng mạng của bạn. Thay vì viết các script riêng biệt cho Cisco Catalyst và Juniper MX, bạn chỉ cần viết một script Python duy nhất. NAPALM sẽ đảm nhận công việc nặng nhọc là kết nối tới thiết bị và dịch các yêu cầu của bạn sang ngôn ngữ cụ thể của từng hãng.

1. Lớp trừu tượng (Abstraction Layer)

Lợi thế lớn nhất của NAPALM là các “Getters”. Nếu bạn cần kiểm tra thời gian hoạt động (uptime) của thiết bị hoặc số sê-ri, bạn chỉ cần gọi get_facts(). Không quan trọng bạn đang truy cập vào Cisco ISR hay switch Arista; NAPALM luôn trả về một dictionary Python chuẩn hóa. Điều này giúp bạn không phải viết 200 dòng biểu thức chính quy (Regex) phức tạp chỉ để tìm một địa chỉ MAC trong một “rừng” văn bản.

2. Quản lý cấu hình

NAPALM không chỉ dừng lại ở việc đọc dữ liệu; nó còn quản lý trạng thái thực tế của thiết bị. Nó hỗ trợ hai phương thức chính: Merge (Hợp nhất) để thêm các đoạn cấu hình nhỏ và Replace (Thay thế) để ghi đè cấu hình bằng một template chuẩn. Quan trọng hơn, tính năng compare_config() đóng vai trò như một lưới an toàn. Nó cho bạn thấy chính xác những gì sẽ thay đổi trước khi bạn commit. Nếu một thay đổi làm mất kết nối, tính năng rollback() có thể khôi phục thiết bị về trạng thái trước đó chỉ trong vài giây.

Thực hành: Thiết lập môi trường

Bắt đầu khá đơn giản. Bạn sẽ cần Python 3.6 trở lên và các thư viện driver cụ thể cho phần cứng của mình. Tôi khuyên bạn nên sử dụng môi trường ảo (virtual environment) để giữ cho các gói phụ thuộc (dependencies) được sạch sẽ.

# Thiết lập không gian làm việc của bạn
python3 -m venv napalm-env
source napalm-env/bin/activate

# Cài đặt thư viện
pip install napalm

Trước khi chạy script, hãy xác minh rằng các API phần cứng đã sẵn sàng. Đối với Cisco IOS, hãy đảm bảo SSH đang hoạt động. Các thiết bị Arista yêu cầu bật eAPI, trong khi thiết bị Juniper cần bật NETCONF.

Kết nối và lấy dữ liệu

Hãy xem một script lấy thông tin cơ bản từ router Cisco. Hãy chú ý xem logic đơn giản thế nào sau khi chúng ta xác định driver.

from napalm import get_network_driver
import json

# Chỉ định 'ios', 'junos', hoặc 'eos'
driver = get_network_driver('ios')
device = driver(hostname='10.1.1.50', username='admin', password='secure_password')

print("Đang mở kết nối...")
device.open()

# Lấy dữ liệu bằng phương thức đã được chuẩn hóa
facts = device.get_facts()

# Xuất kết quả
print(json.dumps(facts, indent=4))

device.close()

Nếu bạn đổi 'ios' thành 'junos' và cập nhật IP, phương thức get_facts() vẫn trả về cùng một cấu trúc dữ liệu. Logic tự động hóa của bạn vẫn được giữ nguyên bất kể thương hiệu phần cứng là gì.

Tự động hóa thay đổi cấu hình

Giá trị thực sự xuất hiện khi đẩy các thay đổi. Trong ví dụ này, chúng ta sẽ cập nhật mô tả interface bằng chiến lược Merge. Cách này thường an toàn hơn cho các hoạt động hàng ngày so với việc thay thế toàn bộ.

from napalm import get_network_driver

driver = get_network_driver('ios')
device = driver('10.1.1.50', 'admin', 'secure_password')
device.open()

print("Đang chuẩn bị cấu hình (staging)...")
device.load_merge_candidate(config='interface GigabitEthernet1\n description Lien_ket_den_Core')

# 'diff' cho bạn thấy điều gì sắp xảy ra
diff = device.compare_config()

if diff:
    print("Các thay đổi đang chờ xử lý:\n" + diff)
    
    confirm = input("Xác nhận commit các thay đổi này? (y/n): ")
    if confirm.lower() == 'y':
        device.commit_config()
        print("Hoàn tất.")
    else:
        device.discard_config()
else:
    print("Không phát hiện thay đổi nào.")

device.close()

Trong môi trường thực tế, đầu ra diff đó là một “vị cứu tinh”. Nó ngăn chặn các lỗi đánh máy (fat-finger) thường dẫn đến các cuộc gọi xử lý sự cố khẩn cấp lúc nửa đêm.

Lưới an toàn Rollback

Sai sót luôn có thể xảy ra ngay cả khi đã lập kế hoạch tốt nhất. Một lý do tôi tin dùng NAPALM cho môi trường production là hàm rollback(). Nếu một lệnh commit được thực hiện nhưng hệ thống giám sát bắt đầu cảnh báo về độ trễ tăng cao, bạn có thể khôi phục ngay lập tức.

try:
    # Chạy một script kiểm tra sau khi cấu hình tại đây
    validate_ospf_neighbor_count()
except Exception as e:
    print(f"Cảnh báo: {e}. Đang khôi phục về trạng thái trước đó!")
    device.rollback()

Lưu ý rằng đối với Cisco IOS, NAPALM mô phỏng việc này bằng cách lưu trữ cấu hình. Trên Juniper, nó sử dụng kiến trúc rollback gốc được tích hợp sẵn trong hệ điều hành.

Những bài học kinh nghiệm từ thực tế

Sau sáu tháng sử dụng hàng ngày, tôi đã tìm ra một vài cách để giúp các script này hoạt động ổn định hơn:

  • Ngừng viết cứng (hardcode) mật khẩu: Sử dụng os.environ hoặc một công cụ như HashiCorp Vault. Lịch sử Git của bạn không nên chứa thông tin đăng nhập mạng.
  • Điều chỉnh thời gian chờ (timeout): Các thay đổi cấu hình lớn trên các dòng Cisco ISR 4000 cũ có thể rất chậm. Hãy tăng tham số timeout trong driver lên 60 hoặc 90 giây để ngăn tình trạng ngắt kết nối ngẫu nhiên.
  • Lưu vết kiểm tra (audit trail): Luôn ghi log đầu ra của compare_config() vào một tệp trung tâm. Sẽ rất hữu ích khi biết chính xác ai đã thay đổi cái gì và khi nào.
  • Xác minh trạng thái: Đừng chỉ tin tưởng vào lệnh commit. Hãy kiểm tra lại bằng get_bgp_neighbors() để đảm bảo bảng định tuyến của bạn không bị mất sau khi thay đổi.

Lời kết

Chuyển từ làm việc CLI thủ công sang tự động hóa bằng Python có thể giống như một cuộc leo núi dốc. Tuy nhiên, tính nhất quán mà nó mang lại hoàn toàn xứng đáng với công sức học tập. Bằng cách trừu tượng hóa các đặc thù của từng hãng, bạn có thể tập trung vào thiết kế mạng cấp cao thay vì phải ghi nhớ cú pháp câu lệnh. Cho dù bạn đang quản lý một văn phòng nhỏ hay một trung tâm dữ liệu trải rộng, quản lý cấu hình thống nhất là một bước bắt buộc đối với cơ sở hạ tầng hiện đại.

Share:
Tags: