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

Подключение виртуализированной сетевой функции (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)

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

  • Для создания новой группы ресурсов вам потребуется роль участника в вашей подписке, или же используйте существующую группу ресурсов, в которой у вас есть роль участника.
  • Вам требуются 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

Установка расширения интерфейса командной строки 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. Откройте входной файл, созданный на предыдущем шаге, и используйте встроенные примечания, чтобы ввести необходимые значения. В этом примере показан входной файл расширения CLI Az AOSM для вымышленного VNF Contoso, который выполняется на платформе Azure Operator 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. Это не требуется при внедрении виртуальной сетевой функции (VNF); его можно удалить. В этом примере показан входной файл расширения Az CLI AOSM для вымышленного NSD Contoso, который можно использовать для развертывания вымышленного VNF Contoso на экземпляр Azure 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, и вы готовы к выполнению потока оператора.

Дальнейшие шаги

  • Last updated on