چرا NETCONF در کنار REST API ها وجود دارد
رویکرد REST API که پیشتر در این مجموعه درباره اصول اتوماسیون شبکه بحث شد برای بسیاری موارد استفاده خوب کار میکند، اما در ابتدا برای خدمات وب عمومی طراحی شد نه بهطور خاص پیکربندی دستگاه شبکه. NETCONF (Network Configuration Protocol) از ابتدا بهطور خاص برای پیکربندی دستگاههای شبکه ساخته شد، با قابلیتهایی که شکافهایی که یک REST API عمومی ذاتاً فراهم نمیکند را برطرف میکنند.
قابلیتهای کلیدی که NETCONF بومی فراهم میکند
تغییرات پیکربندی تراکنشی: NETCONF از یک
datastore پیکربندی "candidate" پشتیبانی میکند،
جداگانه از پیکربندی در حال اجرا -- تغییرات
میتوانند ساخته، تأیید، و فقط بهعنوان یک
تراکنش اتمی واحد وقتی درست تأیید شدند
اعمال شوند، بهجای اعمال فوری و جداگانه تغییرات
قابلیت rollback داخلی: NETCONF از توانایی
بازگشت خودکار به یک پیکربندی قبلی اگر یک
تغییر صراحتاً در یک بازه زمانی مشخص تأیید نشود
پشتیبانی میکند، که در برابر یک تغییر
پیکربندی که بهطور غیرمنتظره اتصال خود دستگاه
را میشکند محافظت میکند
اعتبارسنجی داده ساختاریافته: داده پیکربندی
در برابر یک اسکیمای رسمی (YANG، که در ادامه
بحث میشود) پیش از اعمالشدن تأیید میشود،
و بسیاری خطاهای پیکربندی را پیش از رسیدن
اصلاً به دستگاه میگیرداین قابلیتها مستقیماً ریسکهای عملیاتی واقعیای را برطرف میکنند که تغییرات پیکربندی مبتنیبر-REST ساده ذاتاً از آنها محافظت نمیکنند — قابلیت rollback بهویژه یک مسئله کلاسیک و دردناک را حل میکند: یک تغییر پیکربندی فرستادهشده از راه دور که دقیقاً همان اتصال مدیریتی مورد نیاز برای رفعش را میشکند.
YANG: زبان مدلسازی داده زیربنای NETCONF
YANG (Yet Another Next Generation) یک زبان مدلسازی داده است که دقیقاً تعریف میکند یک قطعه از داده پیکربندی یا عملیاتی چگونه بهنظر میرسد — ساختار، مقادیر معتبر، و محدودیتهایش — و اسکیمایی که NETCONF برای تأیید داده استفاده میکند را فراهم میکند.
مثال مدل YANG سادهشده، که ساختار پیکربندی
یک اینترفیس را تعریف میکند:
container interface {
leaf name {
type string;
}
leaf enabled {
type boolean;
default true;
}
leaf mtu {
type uint16 {
range "68..9216";
}
}
}
-- این مدل YANG تعریف میکند یک اینترفیس یک
-- نام دارد (متن)، یک وضعیت فعال (درست/نادرست،
-- پیشفرض درست)، و یک مقدار MTU که باید درون
-- یک بازه معتبر خاص بیفتد -- یک تلاش برای
-- تنظیم MTU به 100000 فوراً بهعنوان نامعتبر
-- طبق این اسکیما رد میشد، پیش از رسیدن
-- اصلاً به پیکربندی واقعی دستگاهاین تعریف اسکیمای رسمی چیزی است که به ابزارها اجازه میدهد داده پیکربندی را بهطور خودکار تأیید کنند و پیامهای خطای معنادار و خاصی وقتی چیزی اشتباه باشد فراهم کنند — بهبودی قابلتوجه نسبت به کشف یک اشتباه پیکربندی فقط پس از اینکه یک دستگاه یک دستور بدفرم را با یک خطای عمومی رد میکند.
یک تبادل پیکربندی NETCONF
RPC (Remote Procedure Call) سادهشده NETCONF
که یک تغییر پیکربندی اینترفیس را درخواست میکند:
<rpc>
<edit-config>
<target><candidate/></target>
<config>
<interface>
<name>GigabitEthernet0/1</name>
<description>Uplink to Core</description>
<enabled>true</enabled>
</interface>
</config>
</edit-config>
</rpc>
-- NETCONF از XML بهجای JSON که معمولاً در
-- REST API ها استفاده میشود، که پیشتر در
-- این مجموعه بحث شد، استفاده میکند، هرچند
-- مدل داده YANG زیربنایی همچنین میتواند در
-- JSON نمایش داده شود وقتی از پروتکل مرتبط
-- RESTCONF استفاده میشود، که مفاهیم
-- NETCONF/YANG را روی یک رابط سبک-REST
-- آشناتر اعمال میکنداستفاده از پایتون برای تعامل با دستگاههای شبکه
پایتون به زبان برنامهنویسی غالب برای اتوماسیون شبکه تبدیل شده، هم برای تعامل مستقیم NETCONF و هم برای کار با REST API هایی که پیشتر در این مجموعه بحث شد، عمدتاً بهدلیل کتابخانههای بالغی که جزئیات پروتکل زیربنایی را مدیریت میکنند.
مثال پایتون سادهشده با استفاده از کتابخانه
ncclient برای NETCONF:
from ncclient import manager
with manager.connect(host='192.168.1.1', port=830,
username='admin', password='cisco',
hostkey_verify=False) as m:
config = m.get_config(source='running')
print(config)
-- این به یک دستگاه از طریق NETCONF متصل میشود
-- و کل پیکربندی در حال اجرایش را بهعنوان
-- داده ساختاریافته بازیابی میکند، که سپس میتواند
-- بهطور برنامهای تجزیه، تغییر، و تأیید شود،
-- بهجای تجزیه دستی خروجی متن خام CLI به شیوهای
-- که یک اسکریپت اتوماسیون sảnکردن-صفحه سنتی
-- نیاز داشتمثال پایتون سادهشده با استفاده از کتابخانه
requests برای یک فراخوانی REST API، که مفاهیم
پوششدادهشده پیشتر در این مجموعه درباره اصول
اتوماسیون را به کد واقعی کاری متصل میکند:
import requests
response = requests.get(
'https://192.168.1.1/restconf/data/interfaces',
auth=('admin', 'cisco'),
verify=False
)
print(response.json())چرا داده ساختاریافته بر Screen-Scraping غالب است
رویکرد اتوماسیون قدیمیتر (screen-scraping):
فرستادن یک دستور CLI معمولی مانند "show
interfaces"، سپس نوشتن کد تجزیه-متن شکننده
برای استخراج مقادیر خاص از خروجی قابلفهم-
برای-انسان -- این هروقت یک بهروزرسانی
نرمافزار فاصلهگذاری، عبارتبندی، یا فرمت
خروجی را حتی کمی تغییر دهد میشکند
رویکرد مدرن (NETCONF/RESTCONF):
دریافت مستقیم داده ازقبل-ساختاریافته (XML یا
JSON)، با مقادیر در فیلدهای بهروشنی-برچسبگذاریشده
-- مصون در برابر تغییرات فرمتبندی، چون
ساختار داده خودش، نه چیدمان بصری، چیزی است
که کد اتوماسیون به آن متکی استاین تمایز صرفاً موضوع راحتی نیست — اتوماسیون screen-scraping بهطرز بدنامی در محیطهای تولیدی شکننده است، چون حتی یک تغییر کوچک آرایشی در فرمتبندی خروجی CLI در یک بهروزرسانی نرمافزار میتواند بیسروصدا اسکریپتهای اتوماسیونی که ماهها بهدرستی کار میکردند را بشکند، حالت شکستی که فرمتهای داده ساختاریافته بهطور خاص برای حذف آن طراحی شدهاند.
چرا این سطح از پیچیدگی اتوماسیون اهمیت دارد
حرکت از اتوماسیون پایه REST/JSON، پوششدادهشده پیشتر در این مجموعه، بهسمت NETCONF/YANG نشاندهنده بلوغ در اینکه پیکربندی شبکه چقدر جدی بهعنوان یک مسئله مهندسی نرمافزار رفتار میشود است — با تأیید داده رسمی، ایمنی تراکنشی، و قابلیتهای rollback خودکار که بهترین شیوهها از استقرار نرمافزار بهطور گستردهتر را منعکس میکند. درک هر دو رویکرد، و بهطور خاص چرا ساختار و مکانیزمهای ایمنی اضافی NETCONF برای تغییرات شبکه تولیدی در مقیاس اهمیت دارند، دانش ضروریای برای هرکسی است که اتوماسیون را برای شبکههایی که یک تغییر پیکربندی شکستخورده ریسک عملیاتی واقعی دارد طراحی میکند.