اصول اتوماسیون شبکه: API، فرمت‌های داده، و شبکه‌سازی مبتنی بر کنترل‌کننده

چرا پیکربندی دستی CLI مقیاس‌پذیر نیست

هر مثال پیکربندی در سراسر این مجموعه تاکنون به تایپ دستورات مستقیماً در CLI، که پیش‌تر در این مجموعه بحث شد، متکی بوده. این رویکرد برای تعداد کمی دستگاه خوب کار می‌کند، اما در مقیاس یک مرکز داده مدرن یا شبکه سازمانی بزرگ با صدها یا هزاران دستگاه غیرعملی و مستعد خطا می‌شود — تکرار دستی همان تغییر پیکربندی در سراسر هزار سوئیچ کند، خسته‌کننده، و به‌شدت مستعد اشتباهات تایپی و ناسازگاری بین دستگاه‌هاست.

حرکت از CLI به مدیریت مبتنی‌بر-API

به‌جای اینکه یک انسان دستوراتی که قرار است توسط انسان دیگری خوانده شود تایپ کند، مدیریت مبتنی‌بر-API (Application Programming Interface) اجازه می‌دهد نرم‌افزار به‌طور برنامه‌ای دستگاه‌های شبکه را پیکربندی و پرس‌وجو کند، با استفاده از درخواست‌ها و پاسخ‌های ساختاریافته به‌جای متن خط‌فرمان قابل‌فهم‌برای-انسان.

رویکرد سنتی CLI:
یک انسان به‌صورت دستی تایپ می‌کند:
  interface gigabitethernet 0/1
  description Uplink to Core
  no shutdown
-- توسط نرم‌افزار بدون تطبیق الگوی متن شکننده
-- به‌راحتی تجزیه یا تولید نمی‌شود

رویکرد مبتنی‌بر-API:
یک اسکریپت یک درخواست ساختاریافته می‌فرستد:
  PUT /interfaces/GigabitEthernet0-1
  {"description": "Uplink to Core", "enabled": true}
-- به‌راحتی توسط نرم‌افزار تولید، تأیید، و تجزیه می‌شود،
-- بدون هیچ ابهامی درباره معنا

این رویکرد ساختاریافته اجازه می‌دهد همان تغییر پیکربندی به‌طور سازگار و قابل‌اعتماد در سراسر هزاران دستگاه به‌طور هم‌زمان از طریق یک اسکریپت اعمال شود، به‌جای تکرار دستی همان توالی CLI دستگاه‌به‌دستگاه.

REST API ها: رویکرد غالب مدرن

بیشتر دستگاه‌ها و کنترل‌کننده‌های شبکه مدرن یک REST (Representational State Transfer) API را در معرض قرار می‌دهند، که از متدهای استاندارد HTTP برای انجام عملیات‌ها استفاده می‌کند، که پیش‌تر در این مجموعه درباره HTTP به‌عنوان یک پروتکل لایه اپلیکیشن بحث شد.

عملیات‌های رایج REST API، نگاشت‌شده به متدهای HTTP:

GET     - بازیابی اطلاعات (مثلاً پیکربندی
          فعلی اینترفیس)
POST    - ساخت یک منبع جدید
PUT     - به‌روزرسانی/جایگزینی یک منبع موجود
DELETE  - حذف یک منبع

مثال درخواست بازیابی وضعیت اینترفیس:
GET https://device-ip/restconf/data/interfaces

مثال پاسخ (ساده‌شده):
{
  "interfaces": {
    "interface": [
      {"name": "GigabitEthernet0/1", "enabled": true}
    ]
  }
}

این الگوی CRUD (Create, Read, Update, Delete) را که در سراسر توسعه نرم‌افزار به‌طور کلی یافت می‌شود منعکس می‌کند، که اتوماسیون شبکه را برای برنامه‌نویسانی که از پس‌زمینه‌های نرم‌افزاری دیگری می‌آیند قابل‌دسترس می‌کند بدون نیاز به یادگیری یک پارادایم کاملاً ناآشنا.

JSON: زبان مشترک پاسخ‌های API

JSON (JavaScript Object Notation) رایج‌ترین فرمت داده مورد استفاده در درخواست‌ها و پاسخ‌های API است، که داده را به‌عنوان جفت‌های کلید-مقدار تودرتو ساختاردهی می‌کند که هم قابل‌فهم‌برای-انسان هستند و هم به‌راحتی توسط تقریباً هر زبان برنامه‌نویسی تجزیه می‌شوند.

مثال JSON که یک اینترفیس سوئیچ را نشان می‌دهد:
{
  "interface": "GigabitEthernet1/0/1",
  "vlan": 10,
  "status": "up",
  "speed": 1000,
  "duplex": "full"
}

ویژگی‌های کلیدی:
- آکولاد {} یک آبجکت را تعریف می‌کند
- براکت مربعی [] یک لیست/آرایه را تعریف می‌کند
- کلیدها و مقادیر رشته‌ای در گیومه پیچیده می‌شوند
- تودرتویی روابط سلسله‌مراتبی را نشان می‌دهد

YAML: یک جایگزین قابل‌فهم‌تر برای انسان

YAML (YAML Ain't Markup Language) همان نوع داده ساختاریافته را مانند JSON نمایش می‌دهد، اما با استفاده از تورفتگی به‌جای آکولاد و براکت، که به‌طور محسوسی خواندن و نوشتن دستی آن را برای انسان راحت‌تر می‌کند — YAML فرمت استاندارد برای فایل‌های پیکربندی ابزار اتوماسیون است، مانند playbook های Ansible.

همان داده اینترفیس نمایش‌داده‌شده در YAML:

interface: GigabitEthernet1/0/1
vlan: 10
status: up
speed: 1000
duplex: full

-- تورفتگی (فاصله، هرگز تب) ساختار را به‌جای
-- آکولاد و براکت صریح تعریف می‌کند

JSON و YAML دقیقاً همان ساختارهای داده زیربنایی را نمایش می‌دهند و می‌توانند به‌طور برنامه‌ای بین یکدیگر تبدیل شوند — انتخاب بین آن‌ها عمدتاً درباره این است که کدام فرمت توسط یک ابزار خاص مصرف می‌شود، با YAML که معمولاً برای فایل‌هایی که انسان‌ها مستقیماً می‌نویسند و ویرایش می‌کنند ترجیح داده می‌شود، و JSON که معمولاً برای داده تبادل‌شده بین سیستم‌ها ترجیح داده می‌شود.

Ansible: مدیریت پیکربندی اعلانی

Ansible در میان پراستفاده‌ترین ابزارهای اتوماسیون شبکه است، که از Playbooks فرمت‌شده به YAML برای توصیف وضعیت نهایی مطلوب پیکربندی یک دستگاه استفاده می‌کند، به‌جای دستورات گام‌به‌گام مورد نیاز برای رسیدن به آن.

مثال ساده‌شده playbook Ansible:

- name: Configure interface description
  hosts: switches
  tasks:
    - name: Set interface description
      ios_config:
        lines:
          - description Uplink to Core
        parents: interface GigabitEthernet0/1

این رویکرد Declarative (اعلانی) — توصیف اینکه وضعیت نهایی چگونه باید به‌نظر برسد به‌جای توالی دقیق دستورات برای رسیدن به آنجا — یک تغییر بنیادین در تفکر در مقایسه با پیکربندی CLI امری و گام‌به‌گام پوشش‌داده‌شده در سراسر این مجموعه است، و Ansible (یا ابزارهای مشابه) دستورات خاص مورد نیاز روی هر دستگاه برای رسیدن به آن وضعیت توصیف‌شده را تعیین می‌کند.

شبکه‌سازی مبتنی بر کنترل‌کننده: یک تغییر معماری عمیق‌تر

فراتر از صرفاً خودکارسازی پیکربندی دستگاه‌های مدیریت‌شده جداگانه، Controller-Based Networking (شبکه‌سازی مبتنی بر کنترل‌کننده) یک سیستم متمرکز معرفی می‌کند که یک ناوگان کامل دستگاه را به‌عنوان یک نهاد منطقی واحد مدیریت می‌کند، از نظر روحی مشابه با معماری متمرکز WLC که پیش‌تر در این مجموعه درباره شبکه‌های بی‌سیم بحث شد، اما به زیرساخت کابلی نیز گسترش‌یافته.

مدل سنتی: هر دستگاه جداگانه پیکربندی و
  مدیریت می‌شود، چه از طریق CLI چه API

مدل مبتنی‌بر-کنترل‌کننده: یک کنترل‌کننده مرکزی
  (مانند Cisco DNA Center یا Cisco ACI) پیکربندی
  و سیاست مطلوب در سراسر شبکه را نگه می‌دارد،
  و به‌طور خودکار پیکربندی مناسب را به هر دستگاه
  مدیریت‌شده فشار می‌دهد، و به‌طور مداوم برای
  انحراف پیکربندی نظارت و آن را تصحیح می‌کند

این تغییر معماری همان الگوی زیربنایی که در سراسر تکامل شبکه‌سازی دیده شده را منعکس می‌کند: جایگزینی هوش توزیع‌شده و جداگانه-مدیریت‌شده با مدیریت و سیاست متمرکز، الگویی که از قبل از معماری بی‌سیم مبتنی‌بر-WLC که پیش‌تر در این مجموعه بحث شد آشناست، اکنون به کل بافت شبکه گسترش‌یافته.

چرا تسلط بر اتوماسیون در حال تبدیل‌شدن به یک مهارت اصلی شبکه‌سازی است

اتوماسیون شبکه مفاهیم بنیادین شبکه‌سازی پوشش‌داده‌شده در سراسر باقی این مجموعه را جایگزین نمی‌کند — درک OSPF، VLAN ها، و ACL ها ضروری باقی می‌ماند، چون ابزارهای اتوماسیون در نهایت دقیقاً همان فناوری‌های زیربنایی را پیکربندی می‌کنند. آنچه اتوماسیون تغییر می‌دهد این است که آن پیکربندی چگونه در مقیاس اعمال می‌شود: تسلط بر API ها، فرمت‌های داده JSON/YAML، و ابزارهایی مانند Ansible به یک مهارت به‌طور فزاینده مورد انتظار برای مهندسان شبکه‌ای که در محیط‌های مدرن و بزرگ‌مقیاس کار می‌کنند تبدیل شده، که تخصص CLI سنتی را تکمیل می‌کند نه جایگزین آن.