لب عملی: پیکربندی RESTCONF

هدف لب

فعال‌کردن RESTCONF روی یک روتر، بازیابی پیکربندی اینترفیس با استفاده از یک درخواست استاندارد HTTP GET، تغییر توصیف اینترفیس با استفاده از یک درخواست HTTP PATCH، و تأیید تغییر از طریق CLI، و مقایسه گردش‌کار کلی با رویکرد NETCONF از لب قبلی.

هدف لب (چرا مهم است)

NETCONF، پوشش‌داده‌شده در لب قبلی، از انتقال SSH و RPC های فرمت‌شده-XML استفاده می‌کند، و نیازمند یک کتابخانه کلاینت آگاه-از-NETCONF است. RESTCONF همان داده پیکربندی مدل‌شده-با-YANG زیربنایی را از طریق یک API REST استاندارد مبتنی‌بر-HTTPS با استفاده از فعل‌های آشنای HTTP آشکار می‌کند، و آن را از هر ابزار قادر به ساختن یک درخواست پایه HTTP، شامل curl یا یک اسکریپت ساده بدون کتابخانه تخصصی NETCONF، دسترس‌پذیر می‌کند.

توپولوژی لب

R1 ---- Gi0/0: 192.168.255.1/24

ایستگاه مدیریتی: 192.168.255.100، با استفاده
از curl برای تعامل RESTCONF

وظیفه ۱: فعال‌کردن RESTCONF روی R1

سرویس RESTCONF را در کنار سرویس NETCONF که از‌قبل در لب قبلی پیکربندی شده فعال کن.

وظیفه ۲: بازیابی پیکربندی اینترفیس از طریق HTTP GET

از ایستگاه مدیریتی، یک درخواست GET به API RESTCONF برای پیکربندی اینترفیس صادر کن، و فرمت JSON را درخواست کن.

وظیفه ۳: تغییر توصیف اینترفیس از طریق HTTP PATCH

یک درخواست PATCH که توصیف اینترفیس را به‌روزرسانی می‌کند صادر کن، و یک payload JSON بفرست.

وظیفه ۴: تأیید تغییر از طریق CLI

تأیید کن توصیف جدید از طریق CLI سنتی قابل‌مشاهده است.

وظیفه ۵: مقایسه گردش‌کار RESTCONF با NETCONF

تفاوت‌ها در انتقال، فرمت درخواست، و ابزارسازی مورد نیاز بین دو رویکرد را یادداشت کن.

راه‌حل و تأیید

R1(config)# restconf

-- RESTCONF و NETCONF، پوشش‌داده‌شده در لب
-- قبلی، می‌توانند هم‌زمان اجرا شوند، چون هر
-- دو صرفاً همان مدل داده YANG زیربنایی را از
-- طریق مکانیزم‌های انتقال و قالب‌بندی متفاوت
-- آشکار می‌کنند

ManagementStation> curl -k -u admin:password \
  -H "Accept: application/yang-data+json" \
  https://192.168.255.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/0",
    "description": "",
    "enabled": true
  }
}
-- یک درخواست ساده HTTP GET، احراز‌هویت‌شده
-- با اعتبارنامه‌های پایه، دقیقاً همان داده
-- اینترفیسی که RPC get-config NETCONF فراهم
-- کرد را بازمی‌گرداند -- اما با ابزاری به
-- سادگی curl دسترس‌پذیر

ManagementStation> curl -k -u admin:password -X PATCH \
  -H "Content-Type: application/yang-data+json" \
  -d '{"ietf-interfaces:interface":{"description":"Configured via RESTCONF"}}' \
  https://192.168.255.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0

-- HTTP 204 No Content
-- یک پاسخ 204 تأیید می‌کند PATCH پذیرفته و
-- اعمال شد -- کد وضعیت استاندارد HTTP برای
-- یک به‌روزرسانی موفق بدون نیاز به بدنه پاسخ

R1# show running-config interface gigabitethernet0/0

interface GigabitEthernet0/0
 description Configured via RESTCONF
 ip address 192.168.255.1 255.255.255.0
-- توصیف تنظیم‌شده از طریق یک درخواست ساده
-- curl PATCH کاملاً قابل‌مشاهده و مؤثر از
-- طریق CLI است

-- خلاصه مقایسه:

NETCONF: انتقال SSH، payload های XML، نیازمند
         یک کتابخانه کلاینت NETCONF یا ابزار
         تخصصی

RESTCONF: انتقال HTTPS، payload های JSON (یا
          XML)، با هر کلاینت استاندارد HTTP
          شامل curl، Postman، یا کتابخانه‌های
          اسکریپت‌نویسی پایه در تقریباً هر
          زبان برنامه‌نویسی کار می‌کند

نکته کلیدی

RESTCONF و NETCONF همان مدل داده YANG زیربنایی یکسان را آشکار می‌کنند، اما استفاده RESTCONF از HTTPS استاندارد و فعل‌های آشنای HTTP (GET، POST، PUT، PATCH، DELETE) آن را به‌طور قابل‌توجهی برای توسعه‌دهندگانی که از‌قبل با API های REST راحت‌اند قابل‌دسترسی‌تر می‌کند، بدون نیاز به کتابخانه کلاینت تخصصی‌ای که رویکرد XML-RPC مبتنی‌بر-SSH NETCONF نیاز داشت — انتخاب بین آن‌ها معمولاً به این بستگی دارد که toolchain اتوماسیون در استفاده از‌قبل چه انتظاری دارد، نه اینکه یکی قطعاً برتر از دیگری باشد.