Поделиться через

Подключение виртуализированной сетевой функции (VNF) для развертывания в Операторе Azure Nexus к Диспетчеру служб операторов Azure (AOSM)

  • Статья

В этом руководстве издатели сетевых функций и конструкторы служб узнайте, как использовать расширение AOSM Azure CLI для подключения виртуализированной сетевой функции к AOSM. Эта виртуальная виртуальная машина впоследствии может быть развернута в Операторе Azure Nexus. Подключение — это многоэтапный процесс. После выполнения предварительных требований вы будете использовать расширение AOSM Azure CLI для следующих целей:

  1. Создайте файлы BICEP, определяющие группу определения сетевой функции и версию (NFD).
  2. Опубликуйте NFD и отправьте образ VNF в хранилище артефактов (управляемый AOSM Реестр контейнеров Azure (ACR).
  3. Добавьте опубликованный NFD в файлы BICEP, определяющие группу разработки и версию сетевой службы (NSD).
  4. Опубликуйте NSD.

Необходимые компоненты

Примечание.

Настоятельно рекомендуется проверить, успешно ли развертывание виртуальной машины в экземпляре Оператора Azure Nexus перед подключением виртуальной машины к AOSM.

Образы виртуальных машин в Операторе Azure Nexus и шаблоны Azure Resource Manager (ARM)

  • Вы создали образ для виртуальной машины Оператора Azure Nexus. Этот образ должен быть доступен в ACR.

  • Вы создали шаблон ARM, который развертывает виртуальную машину Оператора Azure Nexus.

  • Шаблон ARM виртуальной машины (для AzureCore и Оператора Azure Nexus) может развертывать только ресурсы ARM из следующих поставщиков ресурсов.

    • Microsoft.Compute;
    • Microsoft.Network.
    • Microsoft.NetworkCloud
    • Microsoft.Storage;
    • Microsoft.NetworkFabric
    • Microsoft.Authorization
    • Microsoft.ManagedIdentity

  • Шаблон VNF ARM должен развернуть одну виртуальную машину. Несколько виртуальных машин можно развернуть, включив несколько экземпляров NFDV в NSDV.

Настройка разрешений

  • Для создания группы ресурсов или существующей группы ресурсов, в которой у вас есть роль участника, требуется роль участника для подписки.
  • Вам требуются Reader/AcrPull назначения ролей в исходном ACR, содержащего изображения.
  • Вам требуются Contributor назначения ролей в AcrPush подписке, которая будет содержать управляемое хранилище артефактов AOSM. Эти разрешения позволяют расширению AOSM Azure CLI выполнять прямую копию ACR-to-ACR. Прямая копия — это самый быстрый метод передачи изображений из одного ACR в другой.
    • Политика вашей компании может предотвратить наличие разрешений на область подписки. Параметр--no-subscription-permissions, доступный в az aosm nfd publish командах и az aosm nsd publish командах, использует строго область разрешения, производные от службы AOSM, для оркестрации двухфакторной копии на локальный компьютер и с него. Это двухфакторная копия медленнее, но не требует область разрешений подписки.

Скачивание и установка Azure CLI

Чтобы установить Azure CLI локально, см. инструкции по установке Azure CLI.

Чтобы войти в Azure CLI, выполните az login команду и выполните запросы, отображаемые в терминале, чтобы завершить проверку подлинности. Дополнительные параметры входа см. в статье "Вход с помощью Azure CLI".

Примечание.

Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker. Вы также можете использовать среду Bash в облачной оболочке Azure. Дополнительные сведения см. в статье "Запуск Cloud Shell для использования среды Bash в Azure Cloud Shell".

Обработчик Helm и Docker

  • Установите интерфейс командной строки Helm на хост-компьютере. Необходимо использовать Helm версии 3.8.0 или более поздней версии.
  • Установите Docker на хост-компьютере.

Установка расширения интерфейса командной строки AOSM

Для расширения AOSM Az CLI требуется версия 2.54.0 или более поздняя версия Azure CLI.

  1. Запустите az version , чтобы просмотреть установленные версии и зависимые библиотеки.
  2. Выполните az upgrade обновление до текущей версии Azure CLI.

Установите расширение ИНТЕРФЕЙСА командной строки AOSM с помощью следующей команды:

az extension add --name aosm

Создание группы определений сетевой функции и версии

В этом разделе создается папка в рабочем каталоге vnf-cli-output с шаблонами BICEP ресурсов AOSM, определяющих группу определений и версию сетевой функции, а также хранилище артефактов. Эти ресурсы в конечном итоге будут включены в структуру сетевой службы

  1. Создайте входной файл расширения AOSM Azure CLI для VNF.

    az aosm nfd generate-config --definition-type vnf-nexus --output-file <filename.jsonc>

  2. Откройте входной файл, созданный на предыдущем шаге, и введите необходимые значения строковый комментарий. В этом примере показан входной файл расширения Az CLI AOSM для вымышленного VNF Contoso, который выполняется в Операторе Azure Nexus.

    Примечание.

    Расширение AOSM Azure CLI предоставляет только необходимые параметры без значений по умолчанию в входном шаблоне ARM. Можно задать expose_all_parameters для true предоставления всех параметров шаблона ARM в версии определения сетевой функции (NFDV) и схеме группы конфигурации (CGS). Дополнительные сведения см. в разделе "Параметр" с помощью расширения ИНТЕРФЕЙСА командной строки AOSM.

    {
    // Azure location to use when creating resources e.g uksouth
    "location": "eastus",
    // Name of the Publisher resource you want your definition published to.
    // Will be created if it does not exist.
    "publisher_name": "contoso",
    // Resource group for the Publisher resource.
    // Will be created if it does not exist.
    "publisher_resource_group_name": "contoso-vnf",
    // Name of the ACR Artifact Store resource.
    // Will be created if it does not exist.
    "acr_artifact_store_name": "contoso-vnf-artifact-store",
    // Name of the network function.
    "nf_name": "contoso-vnf",
    // Version of the network function definition in 1.1.1 format (three integers separated by dots).
    "version": "1.0.0",
    // If set to true, all NFD configuration parameters are made available to the designer, including optional parameters and those with defaults.
    // If not set or set to false, only required parameters without defaults will be exposed.
    "expose_all_parameters": false,
    // ARM template configuration. The ARM templates given here would deploy a VM if run. They will be used to generate the VNF.
    "arm_templates": [
        {
            // Name of the artifact. Used as internal reference only.
            "artifact_name": "contoso-vnf",
            // Version of the artifact in 1.1.1 format (three integers separated by dots).
            "version": "1.0.0",
            // File path (absolute or relative to this configuration file) of the artifact you wish to upload from your local disk.
            // Use Linux slash (/) file separator even if running on Windows.
            "file_path": "/home/contoso-vnf/contoso-vnf-arm-template.json"
        }
    ],
    // List of images to be pulled from the acr registry.
    // You must provide the source acr registry, the image name and the version.
    // For example: 'sourceacr.azurecr.io/imagename:imageversion'.
    "images": ["contoso-vnf.azurecr.io/contosovnf:1.0.0"]
}```

  3. Выполните следующую команду, чтобы создать группу определений сетевых функций и версию.

az aosm nfd build --definition-type vnf-nexus --config-file <filename.jsonc>

Публикация группы определений сетевых функций и версий

На этом шаге создаются ресурсы AOSM, определяющие определение сетевой функции и хранилище артефактов, которые будут использоваться для хранения образов виртуальных машин сетевой функции. Он также отправляет изображения в Хранилище артефактов либо путем копирования их непосредственно из исходного ACR, либо, если у вас нет подписки область Contributor и AcrPush ролей, переместив образы Docker локально и отправив их в хранилище артефактов с помощью строго область учетных данных, созданных из службы AOSM.

  1. Выполните следующую команду, чтобы опубликовать группу определений и версию сетевой функции. Если у вас нет подписки область Contributor и AcrPush ролей, включите --no-subscription-permissions в команду.
az aosm nfd publish --build-output-folder vnf-cli-output --definition-type vnf

Можно просмотреть структуру папок и файлов и внести изменения при необходимости.

Создание группы разработки и версии сетевой службы

В этом разделе создается папка в рабочем nsd-cli-outputкаталоге. Эта папка содержит шаблоны BICEP ресурсов AOSM, которые определяют группу и версию сетевой службы. Этот шаблон сетевой службы — это шаблон, используемый в ресурсе сетевой службы сайта, который будет развертывать сетевую функцию, подключенную в предыдущих разделах.

  1. Создайте входной файл NSD расширения AOSM Azure CLI.

    az aosm nsd generate-config --output-file <nsd-output-filename.jsonc>

  2. Откройте входной файл, созданный на предыдущем шаге, и введите необходимые значения строковый комментарий. Созданный входной файл содержит дополнительный resource_element_type тип ArmTemplate. Это не требуется при подключении виртуальной виртуальной машины; его можно удалить. В этом примере показан входной файл расширения Az CLI AOSM для вымышленного NSD Contoso, который можно использовать для развертывания вымышленного экземпляра Contoso Operator Nexus.

    {
    // Azure location to use when creating resources e.g uksouth
    "location": "eastus",
    // Name of the Publisher resource you want your definition published to.
    // Will be created if it does not exist.
    "publisher_name": "contoso",
    // Resource group for the Publisher resource.
    // Will be created if it does not exist.
    "publisher_resource_group_name": "contoso-vnf",
    // Name of the ACR Artifact Store resource.
    // Will be created if it does not exist.
    "acr_artifact_store_name": "contoso-vnf-artifact-store",
    // Network Service Design (NSD) name. This is the collection of Network Service Design Versions. Will be created if it does not exist.
    "nsd_name": "contoso-vnf-nsd",
    // Version of the NSD to be created. This should be in the format A.B.C
    "nsd_version": "1.0.0",
    // Optional. Description of the Network Service Design Version (NSDV).
    "nsdv_description": "An NSD that deploys the onboarded contoso-vnf NFD",
    // List of Resource Element Templates (RETs).
    // There must be at least one NF RET.
    // ArmTemplate RETs are optional. Delete if not required.
    "resource_element_templates": [
        {
            // Type of Resource Element. Either NF or ArmTemplate
            "resource_element_type": "NF",
            "properties": {
                // The name of the existing publisher for the NSD.
                "publisher": "contoso",
                // The resource group that the publisher is hosted in.
                "publisher_resource_group": "contoso-vnf",
                // The name of the existing Network Function Definition Group to deploy using this NSD.
                // This will be the same as the NF name if you published your NFDV using the CLI.
                "name": "contoso-vnf",
                // The version of the existing Network Function Definition to base this NSD on.
                // This NSD will be able to deploy any NFDV with deployment parameters compatible with this version.
                "version": "1.0.0",
                // The region that the NFDV is published to.
                "publisher_offering_location": "eastus",
                // Type of Network Function. Valid values are 'cnf' or 'vnf'.
                "type": "vnf"
            }
        }
    ]
}

    Примечание.

    Раздел шаблона элемента ресурса определяет, какой NFD включен в NSD. Свойства должны соответствовать тем, которые используются во входном файле, переданном команде az aosm nfd build . Это связано с тем, что расширение AOSM Azure CLI проверяет правильность подключения NFD при создании NSD.

  3. Выполните следующую команду, чтобы создать группу проектирования сетевых служб и шаблоны BICEP версии.

az aosm nsd build --config-file <nsd-output-filename.jsonc>

Можно просмотреть структуру папок и файлов и внести изменения при необходимости.

Публикация конструктора сетевой службы (NSD)

На этом шаге создаются ресурсы AOSM, определяющие группу разработки и версию сетевой службы. Он также отправляет артефакты, необходимые NSD, в хранилище артефактов (шаблон ARM сетевой функции).

  1. Выполните следующую команду, чтобы опубликовать группу разработки и версию сетевой службы. Если у вас нет подписки область Contributor и AcrPush ролей, включите --no-subscription-permissions в команду.
az aosm nsd publish --build-output-folder nsd-cli-output

Теперь у вас есть полный набор ресурсов издателя AOSM и готовы к выполнению потока оператора.

Следующие шаги