Подключение контейнерной сетевой функции (CNF) к Диспетчеру служб операторов Azure (AOSM)

Статья
05/22/2024

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

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

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

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

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

Примечание.

Настоятельно рекомендуется протестировать, что helm install пакет Helm успешно выполнен в целевой среде Kubernetes, подключенной к Arc.

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

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

Пакеты Helm

Пакеты Helm, которые вы планируете подключить, должны присутствовать в локальном хранилище компьютера, с которого выполняется интерфейс командной строки.
- Расширение AOSM Azure CLI будет использовать values.yaml файл в пакете helm по умолчанию. Интерфейс командной строки поддерживает переопределение этого поведения с помощью альтернативы values.yaml. Этот альтернативный файл должен существовать в локальном хранилище компьютера, из которого выполняется интерфейс командной строки.

Примечание.

Настоятельно рекомендуется, чтобы пакет Helm содержал схему для значений helm и что шаблоны пакетов Helm, как ожидается, когда helm template выполняется использование значения.yaml, которое вы планируете использовать при подключении к AOSM.

Образы контейнеров

Образы контейнеров присутствуют в существующем ACR или альтернативном реестре контейнеров, поддерживающем API Docker. Образы контейнеров должны храниться в исходном реестре в структуре, которая соответствует расположению изображения, определенному в диаграммах helm. Это требование описано в обнаружении и отправке изображений CLI CNF.
docker login Используйте команду для входа в реестр контейнеров, отличный от Azure, на котором размещаются образы контейнеров перед выполнением любых az aosm команд. Этот шаг не требуется, если вы используете ACR: расширение AOSM Azure CLI автоматически войдет в систему.

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

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

Скачивание и установка 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".

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

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

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

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

az extension add --name aosm

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

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

Создайте входной файл расширения AOSM Azure CLI для CNF.
```
az aosm nfd generate-config --definition-type cnf --output-file <filename.jsonc>
```

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

Примечание.

Расширение AOSM Azure CLI предоставляет только необходимые параметры без значений по умолчанию в входных данных values.yaml . Можно задать expose_all_parameters для true предоставления всех значений helm в версии определения сетевой функции (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.
  // You should create this before running the publish command
  "publisher_resource_group_name": "contoso",
  // Name of the ACR Artifact Store resource.
  // Will be created if it does not exist.
  "acr_artifact_store_name": "contoso-artifact-store",
  // Name of NF definition.
  "nf_name": "contoso-cnf-nfd",
  // Version of the NF 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,
  // List of registries from which to pull the image(s).
  // For example ["sourceacr.azurecr.io/test", "myacr2.azurecr.io", "ghcr.io/path"].
  // For non Azure Container Registries, ensure you have run a docker login command before running build.
  "image_sources": ["contoso.azuercr.io/contoso", "docker.io"],
  // List of Helm packages to be included in the CNF.
  "helm_packages": [
      {
          // The name of the Helm package.
          "name": "contoso-helm-package",
          // The file path to the helm chart on the local disk, relative to the directory from which the command is run.
          // Accepts .tgz, .tar or .tar.gz, or an unpacked directory. Use Linux slash (/) file separator even if running on Windows.
          "path_to_chart": "/home/cnf-onboard/contoso-cnf-helm-chart-0-1-0.tgz",
          // The file path (absolute or relative to this configuration file) of YAML values file on the local disk which will be used instead of the values.yaml file present in the helm chart.
          // Accepts .yaml or .yml. Use Linux slash (/) file separator even if running on Windows.
          "default_values": "",
      }
  ]
}

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

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

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

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

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

Выполните следующую команду, чтобы опубликовать группу определений и версию сетевой функции. Если у вас нет подписки область Contributor и AcrPush ролей, включите --no-subscription-permissions в команду.

Примечание.

Если вы используете Windows, на этапе публикации необходимо запустить Docker Desktop.

az aosm nfd publish --build-output-folder cnf-cli-output --definition-type cnf

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

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

Создайте входной файл NSD расширения AOSM Azure CLI.
```
az aosm nsd generate-config --output-file <nsd-output-filename.jsonc>
```

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

{
    // 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",
    // Name of the ACR Artifact Store resource.
    // Will be created if it does not exist.
    "acr_artifact_store_name": "contoso-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-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-cnf 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",
                // 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-cnf-nfd",
                // 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": "cnf"
            }
        }
    ]
}

Примечание.

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

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

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

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

Публикация группы разработки и версии сетевой службы

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

Выполните следующую команду, чтобы опубликовать группу разработки и версию сетевой службы. Если у вас нет подписки область Contributor и AcrPush ролей, включите --no-subscription-permissions в команду.

az aosm nsd publish --build-output-folder nsd-cli-output

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

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

Подключение контейнерной сетевой функции (CNF) к Диспетчеру служб операторов Azure (AOSM)

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

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

Пакеты Helm

Образы контейнеров

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

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

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

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

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

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

Публикация группы разработки и версии сетевой службы

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

Обратная связь

Дополнительные ресурсы