امروز بررسی می‌کنیم که چگونه Automation شبکه بر مدیریت شبکه تأثیر می‌گذارد. به طور خاص، ابزارهای مدیریت پیکربندی مانند Puppet، Chef و Ansible را مرور می‌کنیم. این ابزارها، همراه با سایر ابزارهای مدیریت شبکه، از رابط‌های برنامه‌نویسی کاربردی مبتنی بر انتقال وضعیت نمایشی (REST APIs) و JavaScript Object Notation (JSON) استفاده می‌کنند.

فرمت‌های داده

فرمت‌های داده روشی برای ذخیره‌سازی و تبادل داده در یک ساختار مشخص ارائه می‌دهند. در ادامه برخی از رایج‌ترین فرمت‌های داده مورد استفاده در Automation شبکه و برنامه‌پذیری شبکه آورده شده است:

• JavaScript Object Notation (JSON)
• Extensible Markup Language (XML)
• YAML Ain’t Markup Language (YAML)

مقایسه فرمت‌های داده

فرمت داده	منشأ / تعریف	هدف اصلی	موارد استفاده رایج
JSON	JavaScript (JS) language; RFC 8259	مدل‌سازی و سریال‌سازی عمومی داده‌ها	REST APIs
XML	World Wide Web Consortium (W3C.org)	فرمت متنی متمرکز بر داده، که امکان مدل‌سازی داده را فراهم می‌کند	REST APIs، صفحات وب
YAML	YAML.org	مدل‌سازی عمومی داده‌ها	Ansible

ویژگی‌های هر فرمت داده

هر فرمت داده دارای ویژگی‌های خاصی است:

• سینتکس، که شامل انواع براکت‌های مورد استفاده مانند [ ]، ( ) و { }، به‌کارگیری فضای خالی، تورفتگی، نقل‌قول‌ها، کاماها و سایر عناصر است.
• نمایش اشیا، مانند کاراکترها، رشته‌ها، لیست‌ها و آرایه‌ها.
• نمایش جفت کلید/مقدار. کلید (که معمولاً در سمت چپ قرار دارد) داده را شناسایی یا توصیف می‌کند. مقدار (در سمت راست) داده‌ای است که می‌تواند شامل کاراکتر، رشته، عدد، لیست یا نوع داده‌ای دیگر باشد.

فرمت داده‌ای که انتخاب می‌شود، بستگی به نوع فرمت مورد استفاده در اپلیکیشن، ابزار یا اسکریپت دارد. با این حال، آزمون CCNA به طور خاص بر تفسیر داده‌های JSON تمرکز دارد.

فرمت داده JSON

JSON یک فرمت داده خوانا برای انسان است که توسط برنامه‌ها برای ذخیره‌سازی، انتقال و خواندن داده‌ها استفاده می‌شود. این فرمت به‌راحتی قابل تجزیه بوده و می‌توان آن را با بیشتر زبان‌های برنامه‌نویسی مدرن، از جمله Python، به کار برد.

پایین خروجی جزئی دستور show interface GigabitEthernet0/0/0 را بر روی یک روتر IOS نشان می‌دهد.

GigabitEthernet0/0/0 is up, line protocol is up (connected)  
Description: Wide Area Network  
Internet address is 172.16.0.2/24  

حالا در مثال پایین نشان می‌دهد که این اطلاعات چگونه می‌توانند در فرمت JSON نمایش داده شوند.

خروجی JSON

{
    "ietf-interfaces:interface": {
        "name": "GigabitEthernet0/0/0",
        "description": "Wide Area Network",
        "enabled": true,
        "ietf-ip:ipv4": {
            "address": [
                {
                    "ip": "172.16.0.2",
                    "netmask": "255.255.255.0"
                }
            ]
        }
    }
}

قوانین نحوی JSON

داده‌های JSON مجموعه‌ای از جفت کلید/مقدار هستند که از قوانین زیر پیروی می‌کنند:

• جفت کلید/مقدار: هر داده شامل یک جفت کلید و مقدار است.
• کلید (Key): یک متن داخل علامت نقل‌قول دوتایی است که قبل از دو نقطه (:) قرار گرفته و به‌عنوان نامی برای مقدار متناظر استفاده می‌شود.
• مقدار (Value): مقدار مرتبط با یک کلید که می‌تواند از انواع زیر باشد:
  • متن (Text): در نقل‌قول دوتایی قرار می‌گیرد.
  • عدد (Numeric): بدون نقل‌قول نوشته می‌شود.
  • آرایه (Array): فهرستی از مقادیر که داخل براکت مربعی [ ] قرار می‌گیرند.
  • شیء (Object): یک یا چند جفت کلید/مقدار که داخل آکولاد { } محصور شده‌اند.
• چندین جفت کلید/مقدار: هنگام لیست کردن چندین جفت کلید/مقدار، هر جفت باید با یک کاما (,) از دیگری جدا شود، به‌جز آخرین جفت.

یک لیست از آدرس‌های IPv4 ممکن است به شکل زیر باشد که در نمایش داده شده است.

کلید اصلی addresses است که مقدار آن یک آرایه محسوب می‌شود. هر آیتم درون این آرایه یک شیء جداگانه است که با آکولاد { } محصور شده و با کاما از سایر آیتم‌ها جدا می‌شود. هر شیء دارای دو جفت کلید/مقدار است:

• آدرس IPv4 (ip)
• ماسک زیرشبکه (netmask)

در این آرایه، اشیاء به‌صورت مجزا تعریف شده‌اند و پس از آخرین شیء، آرایه با یک براکت مربعی بسته ( ] ) خاتمه می‌یابد.

لیست JSON از آدرس‌های IPv4

{
    "addresses": [
        {
            "ip": "172.16.0.2",
            "netmask": "255.255.255.0"
        },
        {
            "ip": "172.16.0.3",
            "netmask": "255.255.255.0"
        },
        {
            "ip": "172.16.0.4",
            "netmask": "255.255.255.0"
        }
    ]
}

APIهای RESTful

APIها برای تبادل داده بین دو برنامه استفاده می‌شوند. برخی از APIها برای ارتباطات درون یک سیستم‌عامل واحد (OS) طراحی شده‌اند، در حالی که برخی دیگر برای برنامه‌هایی که روی رایانه‌های دیگر اجرا می‌شوند، در دسترس هستند. این APIها باید پروتکل شبکه را تعریف کنند. بسیاری از آنها بر اساس REST ساخته شده‌اند.

REST یک سبک معماری برای طراحی برنامه‌های کاربردی تحت وب است. یک API مبتنی بر REST از پروتکل HTTP برای درخواست‌ها و پاسخ‌ها استفاده می‌کند. این نوع API مجموعه‌ای از توابع را برای تعامل با منابع از طریق متدهای HTTP مانند GET و POST تعریف می‌کند. یک API زمانی RESTful محسوب می‌شود که ویژگی‌های زیر را داشته باشد:

• Client/Server: کلاینت بخش فرانت‌اند را مدیریت می‌کند و سرور بک‌اند را کنترل می‌کند. هر یک از این دو بخش می‌توانند به طور مستقل جایگزین شوند.
• Stateless: هیچ داده‌ای بین درخواست‌ها روی سرور ذخیره نمی‌شود. اطلاعات نشست (Session) در سمت کلاینت نگهداری می‌شود.
• Cacheable: کلاینت‌ها می‌توانند پاسخ‌ها را برای بهبود عملکرد کش کنند.

پیاده‌سازی RESTful

یک وب‌سرویس RESTful شامل مجموعه‌ای از منابع است که چهار جنبه مشخص دارد:

• فرمت داده پشتیبانی‌شده توسط وب‌سرویس، که معمولاً JSON، XML یا YAML است.
• مجموعه متدهای عملیاتی که توسط وب‌سرویس پشتیبانی می‌شوند و بر اساس متدهای HTTP هستند.
• ساختار API که باید Hypertext Driven باشد.
• شناسه یکتای منبع (URI) برای وب‌سرویس، مانند http://example.com/resources.

APIهای RESTful از متدهای HTTP متداول مانند POST، GET، PUT، PATCH و DELETE استفاده می‌کنند. جدول زیر نشان می‌دهد که این متدها با عملیات RESTful متناظر هستند.

متدهای HTTP و عملیات RESTful

متد HTTP	عملیات RESTful
POST	ایجاد (Create)
GET	خواندن (Read)
PUT/PATCH	به‌روزرسانی (Update)
DELETE	حذف (Delete)

درخواست‌های API RESTful

یک API مبتنی بر REST با استفاده از URI درخواست داده می‌شود. URI رشته‌ای از کاراکترها است که یک منبع شبکه‌ای خاص را شناسایی می‌کند. همان‌طور که در شکل زیر نشان داده شده، URI شامل دو بخش اصلی است:

• Uniform Resource Name (URN): تنها نام فضای نام (Namespace) منبع را بدون اشاره به پروتکل مشخص می‌کند.
• Uniform Resource Locator (URL): مکان دقیق منبع را در شبکه مشخص می‌کند.

ساختار یک URI

یک URI از اجزای زیر تشکیل شده است:

• پروتکل/طرح (Protocol/Scheme): مانند HTTPS یا سایر پروتکل‌ها از جمله FTP، SFTP، mailto، NNTP.
• نام میزبان (Hostname): مانند www.example.com.
• مسیر و نام فایل (Path and File Name): به عنوان مثال /author/book.html.
• بخش قطعه (Fragment): در اینجا #page155.

درخواست API RESTful به سرور MapQuest

یک درخواست RESTful API پاسخی را از سرور API دریافت می‌کند. به عنوان مثال، شکل زیر یک درخواست GET به سرور MapQuest API را نشان می‌دهد که مسیر بین San Jose تا Monterey را در قالب JSON ارائه می‌دهد.

درخواست API RESTful به سرور MapQuest

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

• سرور API: آدرس URL برای سروری که درخواست‌های REST را پاسخ می‌دهد.
• منابع (Resources): مشخص می‌کند که چه چیزی درخواست شده است.
• کوئری (Query): اطلاعات خاصی را مشخص می‌کند که کلاینت درخواست می‌کند. کوئری‌ها می‌توانند شامل موارد زیر باشند:
  • فرمت (Format): معمولاً JSON است اما می‌تواند YAML یا XML نیز باشد.
  • کلید (Key): برای احراز هویت (در صورت نیاز).
  • پارامترها (Parameters): برای ارسال اطلاعات مرتبط با درخواست استفاده می‌شوند.

پاسخ JSON دریافتی از یک درخواست API

{
    "route": {
        "hasTollRoad": false,
        "hasBridge": true,
        "boundingBox": {
            "lr": {
                "lng": -121.667061,
                "lat": 36.596809
            },
            "ul": {
                "lng": -121.897125,
                "lat": 37.335258
            }
        },
        "distance": 71.712,
        "hasTimeRestriction": false,
        "hasTunnel": false,
        "hasHighway": true,
        "computedWaypoints": [],
        "routeError": {
            "errorCode": -400,
            "message": ""
        }
    }
}

ابزارهای مدیریت پیکربندی

یک شرکت با یک مهندس شبکه ممکن است به‌خوبی بتواند پیکربندی تجهیزات شبکه را مدیریت کند، به‌ویژه اگر پیکربندی‌ها به‌طور مکرر تغییر نکنند. مدل پیکربندی دستی برای هر دستگاه در چنین شرایطی منطقی است. در این مدل، مهندس شبکه می‌تواند از startup-config در دستگاه به‌عنوان پیکربندی ایده‌آل اولیه استفاده کند و در صورت نیاز تغییراتی ایجاد کند. با این حال، این روش برای شبکه‌های بزرگ‌تر که صدها یا حتی هزاران دستگاه شبکه و چندین مهندس شبکه دارند، به‌خوبی کار نمی‌کند. شبکه‌های بزرگ معمولاً از ابزارهای مدیریت پیکربندی استفاده می‌کنند.

ابزارهای مدیریت پیکربندی روش‌های مختلفی برای تعریف منطق و فرآیندهای تغییرات ارائه می‌دهند که مشخص می‌کنند:

• چه تغییراتی باید انجام شود،
• روی کدام دستگاه‌ها،
• و در چه زمانی.

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

ابزارهای مدیریت پیکربندی که در آزمون CCNA مشخص شده‌اند شامل موارد زیر هستند:

• Ansible
• Puppet
• Chef

Ansible

Ansible از معماری بدون عامل (Agentless) برای مدیریت دستگاه‌های شبکه استفاده می‌کند. بدون عامل بودن بدین معناست که دستگاه شبکه نیازی به اجرای کد عامل (Agent) ندارد. Ansible از SSH یا NETCONF برای اعمال تغییرات و استخراج اطلاعات استفاده می‌کند. این ابزار از مدل Push استفاده می‌کند که در شکل زیر نشان داده شده است.

مدل Push در Ansible

Ansible از چندین فایل متنی استفاده می‌کند، که شامل موارد زیر هستند:

• Playbooks: فایل‌هایی که شامل اقدامات و منطق اجرایی برای تعیین وظایف Ansible هستند.
• Inventory: شامل نام میزبان‌های دستگاه‌ها به همراه اطلاعات مربوط به هر دستگاه، مانند نقش‌های دستگاه، که به Ansible امکان می‌دهد دستورات را روی زیرمجموعه‌ای از دستگاه‌ها اجرا کند.
• Templates: پیکربندی دستگاه با استفاده از متغیرها.
• Variables: فهرستی از متغیرهای YAML که در قالب‌های (Templates) جایگذاری می‌شوند.

در شکل بالا، مهندس شبکه ابتدا فایل‌های ضروری را ایجاد می‌کند (1)، سپس Ansible را اجرا می‌کند تا playbook را اجرا کند (2)، که در نهایت این پیکربندی به دستگاه (یا چندین دستگاه) ارسال می‌شود (3).

Puppet

Puppet از معماری مبتنی بر عامل (Agent-based) برای پشتیبانی از مدیریت شبکه استفاده می‌کند. برخی دستگاه‌های شبکه از Puppet Agent درون‌ساز (On-device) پشتیبانی می‌کنند، اما همه سیستم‌عامل‌های سیسکو چنین قابلیتی ندارند. در این شرایط، Puppet از یک عامل پراکسی خارجی (External Proxy Agent) استفاده می‌کند که با استفاده از SSH به دستگاه متصل می‌شود (این روش به‌عنوان عملیات بدون عامل – Agentless Operation شناخته می‌شود).

عملیات مبتنی بر عامل یا بدون عامل در Puppet

Puppet از مدل Pull برای اعمال پیکربندی روی دستگاه‌ها استفاده می‌کند که در شکل پایین نشان داده شده است.

مدل Pull در Puppet

Puppet از چندین فایل متنی مهم استفاده می‌کند که شامل موارد زیر هستند:

• Manifest: یک فایل متنی خوانا برای انسان که وضعیت پیکربندی مطلوب یک دستگاه را مشخص می‌کند.
• Resource، Class و Module: بخش‌های مختلف Manifest، که Module به‌عنوان بزرگ‌ترین جزء شامل چندین کلاس کوچک‌تر است که به نوبه خود شامل منابع مختلف هستند.
• Template: فایلی که برای ایجاد Manifest استفاده می‌شود و شامل نام متغیرهایی است که بعداً مقداردهی می‌شوند.

در شکل بالا، مهندس شبکه ابتدا تمام فایل‌های ضروری را ایجاد می‌کند (1) و سپس عامل روی دستگاه یا عامل خارجی را پیکربندی می‌کند (2). پس از آن، عامل Puppet یا پراکسی آن، اطلاعات پیکربندی را از سرور می‌کشد (3) و در نهایت پیکربندی روی دستگاه به‌روزرسانی می‌شود (4).

Chef

Chef مانند Puppet، از معماری مبتنی بر عامل (Agent-based) استفاده می‌کند. Chef از چندین فایل متنی مهم بهره می‌برد:

• Resource: یک شیء پیکربندی که وضعیت آن توسط Chef مدیریت می‌شود (مانند یک مجموعه از دستورات پیکربندی برای یک دستگاه شبکه).
• Recipe: منطق Chef که به منابع اعمال می‌شود تا مشخص کند چه زمانی، چگونه و در برابر چه مواردی باید اقدام کند.
• Cookbook: مجموعه‌ای از Recipeها که برای مدیریت و اشتراک‌گذاری آسان‌تر گروه‌بندی شده‌اند.
• Runlist: ترتیب اجرای دستورات که باید روی یک دستگاه اجرا شوند.

Chef نیاز به اجرای کلاینت Chef روی دستگاه دارد، و بسیاری از دستگاه‌های سیسکو از کلاینت Chef پشتیبانی نمی‌کنند. بنابراین، در بیشتر موارد، استفاده از Ansible و Puppet برای مدیریت پیکربندی شبکه‌های سیسکو مناسب‌تر خواهد بود.

مقایسه Ansible، Puppet و Chef

ویژگی	Ansible	Puppet	Chef
نام فایل دستورات	Playbook	Manifest	Recipe، Runlist
پروتکل ارتباطی با شبکه	SSH، NETCONF	HTTP (REST)	HTTP (REST)
مدل مبتنی بر عامل یا بدون عامل	بدون عامل (Agentless)	عامل یا بدون عامل	عامل (Agent)
مدل Push یا Pull	Push	Pull	Pull

توجه: Puppet می‌تواند از یک عامل داخلی (On-device Agent) یا یک عامل پراکسی خارجی (External Proxy Agent) برای مدیریت دستگاه‌های شبکه استفاده کند.