استخدام ملحق Azure Operator Service Manager (AOSM) CLI

في هذا الدليل الإرشادي، يتعلم ناشري خدمة وناشري وظائف الشبكة المصمم كيفية استخدام ملحق Azure CLI لبدء استخدام تعريفات وظائف الشبكة (NFDs) وتصميمات خدمة الشبكة (NSDs).

az aosm يهدف ملحق CLI إلى توفير الدعم لنشر تصميمات وتعريفات Azure Operator Service Manager. يساعد ملحق CLI في عملية نشر تعريفات وظائف الشبكة (NFDs) وتصميمات خدمة الشبكة (NSDs) لاستخدامها مع Azure Operator Service Manager.

المتطلبات الأساسية

اتصل بفريق حساب Microsoft لتسجيل اشتراك Azure للوصول إلى Azure Operator Service Manager (AOSM) أو أعرب عن اهتمامك من خلال نموذج تسجيل الشريك.

تنزيل Azure CLI وتثبيته

استخدم بيئة Bash في Azure cloud shell. لمزيد من المعلومات، راجع بدء Cloud Shell لاستخدام بيئة Bash في Azure Cloud Shell.

بالنسبة للمستخدمين الذين يفضلون تشغيل أوامر مرجع CLI محليا، راجع كيفية تثبيت Azure CLI.

إذا كنت تعمل على Window أو macOS، ففكر في تشغيل Azure CLI في حاوية Docker. لمزيد من المعلومات، راجع كيفية تشغيل Azure CLI في حاوية Docker.

إذا كنت تستخدم تثبيتا محليا، فسجل الدخول إلى Azure CLI باستخدام az login الأمر وأكمل المطالبات المعروضة في المحطة الطرفية لإنهاء المصادقة. لمزيد من خيارات تسجيل الدخول، راجع تسجيل الدخول باستخدام Azure CLI.

تثبيت ملحق Azure Operator Service Manager (AOSM) CLI

تثبيت ملحق Azure Operator Service Manager (AOSM) CLI باستخدام هذا الأمر:

az extension add --name aosm
  1. قم بتشغيل az version لمشاهدة الإصدار والمكتبات التابعة المثبتة.
  2. قم بتشغيل az upgrade للترقية إلى الإصدار الحالي من Azure CLI.

تسجيل موفري الموارد المطلوبين والتحقق منهم

قبل البدء في استخدام Azure Operator Service Manager، تأكد من تسجيل موفر الموارد المطلوب. نفذ الأوامر التالية. قد تستغرق عملية التسجيل هذه ما يصل إلى 5 دقائق.

# Register Resource Provider
az provider register --namespace Microsoft.HybridNetwork
az provider register --namespace Microsoft.ContainerRegistry

تحقق من حالة تسجيل موفري الموارد. نفذ الأوامر التالية.

# Query the Resource Provider
az provider show -n Microsoft.HybridNetwork --query "{RegistrationState: registrationState, ProviderName: namespace}"
az provider show -n Microsoft.ContainerRegistry --query "{RegistrationState: registrationState, ProviderName: namespace}"

إشعار

قد يستغرق الأمر بضع دقائق حتى يكتمل تسجيل موفر الموارد. بمجرد نجاح التسجيل، يمكنك المتابعة باستخدام Azure Operator Service Manager (AOSM).

متطلبات وظيفة الشبكة المعبأة في حاويات (CNF)

بالنسبة لأولئك الذين يستخدمون وظائف الشبكة الحاوية، من الضروري التأكد من تثبيت الحزم التالية على الجهاز الذي تقوم بتنفيذ CLI منه:

  • تثبيت Helm، راجع تثبيت Helm CLI.
  • في بعض الحالات، قم بتثبيت docker، راجع تثبيت Docker Engine. مطلوب فقط إذا كانت الصورة المصدر في مستودع docker المحلي، أو ليس لديك أذونات على مستوى الاشتراك مطلوبة لدفع المخططات والصور.

الأذونات

مطلوب حساب Azure مع اشتراك نشط. إذا لم يكن لديك اشتراك Azure، فاتبع الإرشادات هنا ابدأ مجانا لإنشاء حساب قبل البدء.

تحتاج إلى دور المساهم عبر هذا الاشتراك لإنشاء مجموعة موارد أو مجموعة موارد موجودة حيث يكون لديك دور المساهم.

أذونات نشر CNFs

إذا كان مصدر صور CNF من ACR موجود، تحتاج إلى الحصول Reader/AcrPull على أذونات من ACR هذا، وبشكل مثالي، Contributor الدور + AcrPush الدور (أو دور مخصص يسمح importImage بالإجراء و AcrPush) على الاشتراك بأكمله من أجل أن تكون قادرا على الاستيراد إلى مخزن Artifact الجديد. إذا كان لديك هذه، فلن تحتاج إلى تثبيت docker محليا، ونسخة الصورة سريعة.

إذا لم يكن لديك الأذونات على مستوى الاشتراك، فيمكنك تشغيل az aosm nfd publish الأمر باستخدام العلامة --no-subscription-permissions لسحب الصورة إلى جهازك المحلي ثم دفعها إلى Artifact Store باستخدام بيانات اعتماد البيان التي تم تحديد نطاقها للمخزن فقط. يتطلب تثبيت docker محليا.

نظرة عامة على ملحق Azure Operator Service Manager (AOSM) CLI

يستخدم ناشرو وظائف الشبكة المصمم الخدمة ملحق Azure CLI للمساعدة في نشر تعريفات وظائف الشبكة (NFDs) وتصميمات خدمة الشبكة (NSDs).

كما هو موضح في الأدوار والواجهات، فإن ناشر وظائف الشبكة لديه مسؤوليات مختلفة. يساعد ملحق CLI في العناصر المعروضة بخط غامق:

  • إنشاء دالة الشبكة.
  • قم بترميز ذلك في تصميم وظيفة الشبكة (NFD).
  • حدد معلمات التوزيع لعرضها على المصمم الخدمة.
  • إلحاق تصميم وظيفة الشبكة (NFD) ب Azure Operator Service Manager (AOSM).
  • تحميل البيانات الاصطناعية المقترنة.
  • التحقق من صحة تصميم وظيفة الشبكة (NFD).

المصمم الخدمة أيضا مسؤوليات مختلفة، منها ملحق CLI يساعد في العناصر بخط غامق:

  • اختر تعريفات وظائف الشبكة المضمنة في تصميم الخدمة.
  • قم بترميز ذلك في تصميم خدمة الشبكة.
  • دمج البنية الأساسية ل Azure في تصميم خدمة الشبكة.
  • حدد كيفية قياس الخدمة عن طريق تعريف مخطط مجموعة تكوين واحد أو أكثر (CGSs).
  • حدد كيفية تعيين المدخلات من عامل تشغيل الخدمة إلى المعلمات المطلوبة بواسطة تعريفات وظائف الشبكة والبنية الأساسية ل Azure.
  • إلحاق تصميم خدمة الشبكة (NSD) ب Azure Operator Service Manager (AOSM).
  • تحميل البيانات الاصطناعية المقترنة.
  • التحقق من صحة تصميم خدمة الشبكة (NSD).

ملخص Workflow

سير عمل عام لاستخدام ملحق CLI هو:

  1. ابحث عن العناصر الأساسية التي تحتاجها لحالة الاستخدام الخاصة بك.

  2. generate-config قم بتشغيل أمر لإخراج مثال لملف تكوين JSON للأوامر اللاحقة.

  3. املأ ملف التكوين.

  4. build قم بتشغيل أمر لإخراج قالب bicep واحد أو أكثر لتعريف وظيفة الشبكة أو تصميم خدمة الشبكة.

  5. راجع إخراج أمر البناء، واحرر الإخراج حسب الضرورة لمتطلباتك.

  6. publish تشغيل أمر إلى:

    • إنشاء كافة الموارد الأساسية مثل Resource Group وPublisher و Artifact Stores و Groups.
    • انشر قوالب bicep هذه.
    • تحميل البيانات الاصطناعية إلى مخازن البيانات الاصطناعية.

نقطة بدء VNF

بالنسبة إلى VNFs، تحتاج إلى قالب ARM واحد من شأنه إنشاء موارد Azure ل VNF الخاص بك، على سبيل المثال جهاز ظاهري وأقراص وNIC. يجب تخزين قالب ARM على الجهاز الذي تقوم بتنفيذ CLI منه.

بالنسبة لإصدارات تعريف دالة الشبكة الظاهرية (VNF NFDVs)، يجب أن تحتوي قائمة networkFunctionApplications على VhdImageFile واحد وقالب ARM واحد. من غير المعتاد تضمين أكثر من VhdImageFile واحد وأكثر من قالب ARM واحد. ما لم يكن لديك سبب قوي لعدم ذلك، يجب أن ينشر قالب ARM جهازا ظاهريا واحدا. يجب أن يتضمن المصمم الخدمة العديد من نسخ تعريف وظيفة الشبكة (NFD) مع تصميم خدمة الشبكة (NSD) إذا كنت تريد نشر أجهزة ظاهرية متعددة. يمكن لقالب ARM (لكل من AzureCore و Nexus) نشر موارد ARM فقط من موفري الموارد التاليين:

  • Microsoft.Compute

  • Microsoft.Network

  • Microsoft.NetworkCloud

  • Microsoft.Storage

  • Microsoft.NetworkFabric

  • Microsoft.Authorization

  • Microsoft.ManagedIdentity

تحتاج أيضا إلى صورة VHD التي سيتم استخدامها للجهاز الظاهري VNF. يمكن تخزين صورة VHD على الجهاز الذي تقوم بتنفيذ CLI منه، أو في تخزين Azure blob الذي يمكن الوصول إليه عبر SAS URI.

نقطة بدء CNF

بالنسبة إلى عمليات نشر دوال الشبكة المعبأة في حاويات (CNFs)، من الضروري تخزين ما يلي على الجهاز الذي تقوم بتنفيذ CLI منه:

  • Helm Packages with Schema - يجب أن تكون هذه الحزم موجودة على التخزين المحلي الخاص بك والمشار إليها داخل input.json ملف التكوين. عند اتباع هذا التشغيل السريع، يمكنك تنزيل حزمة helm المطلوبة.

  • إنشاء نموذج ملف تكوين - إنشاء ملف تكوين مثال لتعريف توزيع CNF. قم بإصدار هذا الأمر لإنشاء input.json ملف تحتاج إلى تعبئته بتكوين معين.

    az aosm nfd generate-config
    
  • صور ل CNF الخاص بك - فيما يلي الخيارات:

    • مرجع إلى سجل حاويات Azure موجود يحتوي على الصور ل CNF الخاص بك. حاليا، يتم دعم ACR واحد فقط ومساحة الاسم لكل CNF. يتم ملء الصور التي سيتم نسخها من ACR هذا تلقائيا استنادا إلى مخطط حزمة helm. يجب أن يكون لديك أذونات Reader/AcrPull على ACR هذا. لاستخدام هذا الخيار، املأ source_registry الملف input.json واختياريا source_registry_namespace .
    • اسم صورة صورة docker المصدر من الجهاز المحلي. اسم الصورة هذا لحالة استخدام محدودة حيث يتطلب CNF فقط صورة docker واحدة موجودة في مستودع docker المحلي. لاستخدام هذا الخيار، املأ source_local_docker_image ملف input.json. يتطلب تثبيت docker. يرشدك هذا التشغيل السريع خلال تنزيل صورة nginx docker لاستخدامها في هذا الخيار.
  • اختياري: تعيين ملف (path_to_mappings): اختياريا، يمكنك توفير ملف (على القرص) يسمى path_to_mappings. يجب أن يعكس values.yamlهذا الملف ، مع استبدال القيم المحددة بمعلمات النشر. يؤدي القيام بذلك إلى كشفها كمعلمات ل CNF. أو يمكنك ترك هذا فارغا في input.json وإنشاء CLI الملف. بشكل افتراضي في هذه الحالة، يتم عرض كل قيمة داخل values.yaml كمعلمة نشر. بدلا من ذلك، استخدم وسيطة --interactive CLI لإجراء الاختيارات بشكل تفاعلي. يرشدك هذا التشغيل السريع خلال إنشاء هذا الملف.

عند تكوين input.json الملف، تأكد من إدراج حزم Helm بالترتيب الذي يجب نشره. على سبيل المثال، إذا كان يجب نشر الحزمة "A" قبل الحزمة "B" input.json ، يجب أن تشبه البنية التالية:

"helm_packages": [
    {
        "name": "A",
        "path_to_chart": "Path to package A",
        "path_to_mappings": "Path to package A mappings",
        "depends_on": [
            "Names of the Helm packages this package depends on"
        ]
    },
    {
        "name": "B",
        "path_to_chart": "Path to package B",
        "path_to_mappings": "Path to package B mappings",
        "depends_on": [
            "Names of the Helm packages this package depends on"
        ]
    }
]

يضمن اتباع هذه الإرشادات نهجا منظما ومنظما بشكل جيد لنشر وظائف الشبكة المعبأة في حاويات (CNFs) مع حزم Helm والتكوينات المرتبطة بها.

نقطة بدء NSD

بالنسبة إلى NSDs، تحتاج إلى معرفة تفاصيل تعريفات وظائف الشبكة (NFDs) لتضمينها في تصميمك:

  • مجموعة موارد NFD Publisher
  • اسم ونطاق ناشر NFD
  • اسم مجموعة تعريف وظيفة الشبكة
  • موقع إصدار تعريف وظيفة الشبكة ونوعه وإصداره

يمكنك استخدام az aosm nfd الأوامر لإنشاء كل هذه الموارد.

أوامر Azure Operator Service Manager (AOSM)

استخدم هذه الأوامر قبل البدء:

  1. az login يستخدم لتسجيل الدخول إلى Azure CLI.

  2. az account set --subscription <subscription> يستخدم لاختيار الاشتراك الذي تريد العمل عليه.

أوامر NFD

الحصول على تعليمات حول وسيطات الأوامر:

  • az aosm -h

  • az aosm nfd -h

  • az aosm nfd build -h

أوامر نوع التعريف

تأخذ كل هذه الأوامر وسيطة --definition-type من vnf أو cnf.

إنشاء مثال ملف تكوين لإنشاء تعريف:

  • az aosm nfd generate-config

يقوم هذا الأمر إخراج ملف يسمى input.json، والذي يجب تعبئته. بمجرد ملء ملف التكوين في الأوامر التالية يمكن تشغيلها.

إنشاء تعريف NFD محليا:

  • az aosm nfd build --config-file input.json

مزيد من الخيارات حول إنشاء تعريف NFD محليا:

  • اختر أي من معلمات قالب VNF ARM التي تريد عرضها ك NFD deploymentParameters، مع خيار اختيار كل منها بشكل تفاعلي:

    • az aosm nfd build --config-file input.json --definition_type vnf --order_params
    • az aosm nfd build --config-file input.json --definition_type vnf --order_params --interactive

اختر أي من معلمات قيم CNF Helm التي تريد عرضها ك NFD deploymentParameters:

  • az aosm nfd build --config-file input.json --definition_type cnf --interactive

نشر تعريف تم إنشاؤه مسبقا:

  • az aosm nfd publish --config-file input.json

حذف تعريف منشور:

  • az aosm nfd delete --config-file input.json

حذف تعريف منشور والناشر ومخازن البيانات الاصطناعية ومجموعة NFD:

  • az aosm nfd delete --config-file input.json --clean

أوامر NSD

الحصول على تعليمات حول وسيطات الأوامر:

  • az aosm -h

  • az aosm nsd -h

  • az aosm nsd build -h

إنشاء مثال ملف تكوين لإنشاء تعريف:

  • az aosm nsd generate-config

يقوم هذا الأمر إخراج ملف يسمى input.json، والذي يجب تعبئته. بمجرد ملء ملف التكوين في الأوامر التالية يمكن تشغيلها.

إنشاء NSD محليا:

  • az aosm nsd build --config-file input.json

نشر تصميم تم إنشاؤه مسبقا:

  • az aosm nsd publish --config-file input.json

حذف تصميم منشور:

  • az aosm nsd delete --config-file input.json

حذف تصميم منشور والناشر ومخازن البيانات الاصطناعية ومجموعة NSD:

  • az aosm nsd delete --config-file input.json --clean

تحرير إخراج البنية قبل النشر

az aosm يهدف ملحق CLI إلى توفير الدعم لنشر تصميمات وتعريفات Azure Operator Service Manager. ويوفر كتل الإنشاء لإنشاء تصاميم وتعريفات مخصصة معقدة. يمكنك تحرير إخراج الملفات بواسطة build الأمر قبل تشغيل publish الأمر، لإضافة ميزات أكثر تعقيدا أو مخصصة.

مرجع API الكامل ل Azure Operator Service Manager هنا: Azure Hybrid Network REST API.

تصف الأقسام التالية بعض الطرق الشائعة التي يمكنك استخدامها لتحرير الملفات المضمنة قبل النشر.

تعريفات وظائف الشبكة (NFDs)

  • versionState قم بتغيير المورد من networkfunctiondefinitionversionsPreview إلى Active. NFDVs النشطة غير قابلة للتغيير بينما معاينة NFDVs قابلة للتغيير وفي حالة المسودة.
  • بالنسبة إلى CNFs، قم بتغيير releaseNamespacehelmMappingRuleProfile لتغيير مساحة اسم kubernetes التي يتم نشر المخطط إليها.

تصميمات خدمة الشبكة (NSDs)

  • أضف البنية الأساسية ل Azure إلى تصميم خدمة الشبكة (NSD). يمكن أن تتضمن إضافة البنية الأساسية ل Azure إلى ما يلي:
    • كتابة قوالب ARM لنشر البنية الأساسية.
    • إضافة مخططات مجموعة التكوين (CGSs) لقوالب ARM هذه.
    • إضافة ResourceElementTemplates (RETs) من النوع ArmResourceDefinition إلى NSD. تبدو RETs مماثلة ل NetworkFunctionDefinition RETs بصرف النظر عن type الحقل.
    • إضافة قوالب ARM للبنية الأساسية إلى artifact_manifest.bicep الملف.
    • تحرير الملفات configMappings لدمج أي مخرجات من قوالب البنية الأساسية كمدخلات إلى NetworkFunctionDefinition ResourceElementTemplates. على سبيل المثال: "customLocationId": "{outputparameters('infraretname').infraretname.customLocationId.value}"
    • dependsOnProfile تحرير ل NetworkFunctionDefinition ResourceElementTemplates (RETs) للتأكد من نشر RETs للبنية الأساسية قبل NF RETs.
  • versionState قم بتغيير المورد من networkservicedesignversionsPreview إلى Active. NSDs النشطة غير قابلة للتغيير بينما معاينة NSDs قابلة للتغيير وفي حالة المسودة.