Непрерывная интеграция и поставка для рабочей области Azure Synapse Analytics
Непрерывная интеграция (CI) — это процесс автоматизации сборки и тестирования кода каждый раз, когда член команды фиксирует изменения в системе управления версиями. Непрерывная доставка (CD) — это процесс создания, тестирования, настройки и развертывания из нескольких тестовых или промежуточных сред в рабочей среде.
В рабочей области Azure Synapse Analytics CI/CD обеспечивает непрерывное перемещение всех сущностей из одной среды (среды разработки, тестирования, рабочей среды) в другую. Процесс продвижения одной рабочей области в другую рабочую область состоит из двух частей. Сначала используйте шаблон Azure Resource Manager (шаблон ARM) для создания или обновления ресурсов рабочей области (пулов и рабочего пространства). Затем выполните миграцию артефактов, таких как скрипты и записные книжки SQL, определения заданий Spark, конвейеры, наборы данных и т. д., с помощью средств развертывания рабочей области Synapse в Azure DevOps или GitHub.
В этой статье описано, как использовать конвейер выпуска Azure DevOps и GitHub Actions для автоматизации развертывания рабочей области Azure Synapse в нескольких средах.
Необходимые компоненты
Для автоматизации развертывания рабочей области Azure Synapse в нескольких средах необходимо выполнить следующие предварительные требования и конфигурации. Вы можете использовать Azure DevOps или GitHub в соответствии с вашими предпочтениями или существующей настройкой.
Azure DevOps
Если вы используете Azure DevOps:
- Подготовьте проект Azure DevOps для запуска конвейера выпуска.
- Предоставьте всем пользователям, которые будут возвращать код Basic, доступ на уровне Организации, чтобы они могли просматривать репозиторий.
- Предоставьте привилегии владельца относительно репозитория Azure Synapse.
- Убедитесь, что вы создали локальный агент виртуальной машины Azure DevOps, или используйте размещенный агент Azure DevOps.
- Предоставьте разрешения на создание подключения к службе Azure Resource Manager для группы ресурсов.
- Администратор Microsoft Entra должен установить расширение агента развертывания рабочей области Azure DevOpse Synapse в организации Azure DevOps.
- Создайте или назначьте существующую учетную запись службы для запуска конвейера. Вместо учетной записи службы можно использовать личный маркер доступа, однако конвейеры перестанут работать после удаления учетной записи пользователя.
GitHub
Если вы используете GitHub:
- Создайте репозиторий GitHub, содержащий артефакты рабочей области Azure Synapse и шаблон рабочей области.
- Убедитесь, что вы создали локальное средство выполнения тестов, или используйте средство выполнения тестов, размещенное на GitHub.
Microsoft Entra ID
- Если вы используете субъект-службу в идентификаторе Microsoft Entra, создайте субъект-службу для развертывания.
- Для использования управляемого удостоверения необходимо включить управляемое удостоверение, назначаемое системой, на виртуальной машине в Azure в качестве агента или средства выполнения тестов, а затем добавить его в Azure Synapse Studio в качестве администратора Synapse.
- Используйте роль администратора Microsoft Entra для выполнения этих действий.
Azure Synapse Analytics
Примечание.
Приведенные ниже необходимые компоненты можно автоматизировать и развернуть с помощью одного конвейера, шаблона ARM или интерфейса командной строки Azure, однако эти процессы не описаны в данной статье.
Исходную рабочую область, используемую для разработки, необходимо настроить с помощью репозитория Git в Azure Synapse Studio. Дополнительные сведения см. в статье Система управления версиями в Azure Synapse Studio.
Настройка пустой рабочей области для развертывания со следующей целью:
- Создание новой рабочей области Azure Synapse.
- Предоставьте субъекту-службе следующие разрешения для новой рабочей области Synapse:
- Microsoft.Synapse/workspaces/integrationruntimes/write
- Microsoft.Synapse/workspaces/operationResults/read
- Microsoft.Synapse/workspaces/read
- В рабочей области не настраивайте подключение к репозиторию Git.
- В рабочей области Azure Synapse выберите Студия>Управление>Контроль доступа. Назначьте издателю Synapse Artifact субъекту-службе. Если конвейер развертывания потребуется развернуть управляемые частные конечные точки, вместо этого назначьте "Администратор Synapse".
- При использовании связанных служб, сведения о подключении которых хранятся в Azure Key Vault, рекомендуется хранить отдельные хранилища ключей для разных сред. Вы также можете настроить отдельные уровни разрешений для каждого из хранилища ключей. Например, вы не хотите, чтобы у участников вашей команды были разрешения на доступ к секретам рабочей среды. При таком подходе рекомендуем использовать одинаковые имена секретов на всех этапах. Если вы сохраняете одни и те же имена секретов, вам не нужно параметризовать каждую строку подключения в средах CI/CD, так как единственное, что изменяется — это имя хранилища ключей, которое является отдельным параметром.
Другие необходимые условия
- Пулы Spark и локальные среды выполнения интеграции не создаются в рабочей области при выполнении задачи по развертыванию. Если у вас есть связанная служба, использующая локальную среду выполнения интеграции, создайте ее вручную в новой рабочей области.
- Если элементы в рабочей области разработки подключаются к конкретным пулам, убедитесь в том, чтобы были созданы и параметризованы одинаковые имена пулов в целевой рабочей области в файле параметров.
- Если при попытке развертывания происходит приостановка подготовленных к работе пулов SQL, может произойти сбой.
Дополнительные сведения см. в статье Непрерывная интеграция и непрерывное развертывание в Azure Synapse Analytics. Часть 4. Конвейер выпуска.
Создание конвейера выпуска в Azure DevOps
В этом разделе вы узнаете, как развернуть рабочую область Azure Synapse в Azure DevOps.
В Azure DevOps откройте проект, созданный для выпуска.
В меню слева выберите Конвейеры>Выпуски.
Выберите Создать конвейер. При наличии существующих конвейеров выберите Создать>Новый конвейер выпуска.
Выберите шаблон Пустое задание.
В поле Имя этапа введите имя своей среды.
Выберите Добавить артефакт, а затем выберите репозиторий Git, настроенный с помощью Azure Synapse Studio в вашей среде разработки. Выберите репозиторий Git, в котором вы управляете пулами и шаблоном ARM рабочей области. Если вы используете GitHub в качестве источника, необходимо создать подключение к службе для учетной записи GitHub и выполнить извлечение данных из репозиториев. Дополнительные сведения см. в статье Подключения к службам.
Выберите ветвь шаблона ARM для ресурсов. Для поля Версия по умолчанию выберите Последний из ветви по умолчанию.
Для ветви по умолчанию артефактов выберите ветвь публикации репозитория или другие неопубликованные ветви, которые включают артефакты Synapse. По умолчанию ветвь публикации обозначена как
workspace_publish
. Для поля Версия по умолчанию выберите Последний из ветви по умолчанию.
Настройка задачи промежуточного этапа для шаблона ARM с целью создания и обновления ресурса
Если у вас есть шаблон ARM для развертывания ресурса, например рабочей области Azure Synapse, пула Spark и SQL или хранилища ключей, добавьте задачу развертывания Azure Resource Manager, чтобы создать или обновить эти ресурсы:
В представлении этапа выберите Просмотр задач этапа.
Создайте задачу. Найдите параметр Развертывание шаблона ARM, а затем щелкните Добавить.
На вкладке Задачи развертывания выберите подписку, группу ресурсов и расположение для рабочей области. При необходимости предоставьте учетные данные.
Для элемента Действие выберите Создание или обновление группы ресурсов.
В поле Шаблоннажмите кнопку с многоточием (...). Перейдите к шаблону ARM рабочей области.
Рядом с полем Параметры шаблона выберите ... для указания файла параметров.
В поле Параметры шаблона переопределения выберите ..., а затем введите значения параметров, которые необходимо использовать для рабочей области.
Для элемента Режим развертывания выберите Добавочный.
(Необязательно) Добавьте Azure PowerShell для предоставления и обновления назначения роли рабочей области. Если для создания рабочей области Azure Synapse используется конвейер выпуска, то по умолчанию субъект-служба конвейера добавляется в качестве администратора рабочей области. Вы можете запустить PowerShell, чтобы предоставить доступ к рабочей области другим учетным записям.
Предупреждение
При использовании полного режима развертывания ресурсы в группе ресурсов, которые не указаны в новом шаблоне ARM, будут удалены. Подробные сведения см. в статье Режимы развертывания Azure Resource Manager.
Настройка задачи промежуточного этапа для развертывания артефактов Azure Synapse
Используйте расширение развертывания рабочей области Azure Synapse для развертывания других элементов в рабочей области Azure Synapse. Элементы, которые можно развернуть, включают наборы данных, скрипты и записные книжки SQL, определения заданий Spark, среду выполнения интеграции, поток данных, учетные данные и другие артефакты в рабочей области.
Установка и добавление расширения развертывания
Выполните поиск и получите расширение из Visual Studio Marketplace.
Выберите организацию Azure DevOps, в которой необходимо установить расширение.
Убедитесь, что субъекту-службе конвейера Azure DevOps предоставлено разрешение подписки, а также что он назначен в качестве администратора рабочей области Synapse для целевой рабочей области.
Для создания новой задачи выполните поиск развертывания рабочей области Synapse и нажмите кнопку Добавить.
Настройка задачи развертывания
Задача развертывания поддерживает три типа операций, проверять только, развертывать и проверять и развертывать.
Примечание.
Это расширение развертывания рабочей области не имеет обратной совместимости. Убедитесь, что установлена и используется последняя версия. Заметки о выпуске см. в обзоре в Azure DevOps и описании последней версии действия GitHub.
Проверка заключается в проверке артефактов Synapse в непубликованной ветви с помощью задачи и создания шаблона рабочей области и файла шаблона параметров. Операция проверки работает только в конвейере YAML. Ниже приведен пример ФАЙЛА YAML:
pool:
vmImage: ubuntu-latest
resources:
repositories:
- repository: <repository name>
type: git
name: <name>
ref: <user/collaboration branch>
steps:
- checkout: <name>
- task: Synapse workspace deployment@2
continueOnError: true
inputs:
operation: 'validate'
ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
TargetWorkspaceName: '<target workspace name>'
Проверка и развертывание можно использовать для непосредственного развертывания рабочей области из неопубликованной ветви с корневой папкой артефакта.
Примечание.
Задача развертывания должна скачать файлы JS зависимостей из этой конечной точки web.azuresynapse.net при выборе типа операции в качестве проверки или проверки и развертывания. Убедитесь, что конечная точка web.azuresynapse.net разрешена, если политики сети включены на виртуальной машине.
Операция проверки и развертывания работает как в классическом, так и в конвейере YAML. Ниже приведен пример ФАЙЛА YAML:
pool:
vmImage: ubuntu-latest
resources:
repositories:
- repository: <repository name>
type: git
name: <name>
ref: <user/collaboration branch>
steps:
- checkout: <name>
- task: Synapse workspace deployment@2
continueOnError: true
inputs:
operation: 'validateDeploy'
ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
TargetWorkspaceName: 'target workspace name'
azureSubscription: 'target Azure resource manager connection name'
ResourceGroupName: 'target workspace resource group'
DeleteArtifactsNotInTemplate: true
OverrideArmParameters: >
-key1 value1
-key2 value2
Развертывание — входные данные развертывания операции включают шаблон рабочей области Synapse и шаблон параметров, которые можно создать после публикации в ветви публикации рабочей области или после проверки. Он совпадает с версией 1.x.
Типы операций выбираются в зависимости от варианта использования. Ниже приведен пример развертывания.
В задаче выберите Развертывание в качестве типа операции.
В задаче рядом с полем Шаблон выберите ..., чтобы выбрать файл шаблона.
Рядом с полем Параметры шаблона выберите ... для указания файла параметров.
Выберите подключение, группу ресурсов и имя рабочей области.
Рядом с полем Переопределить параметры шаблона выберите .... Введите необходимые значения параметров для рабочей области, включая строки подключения и ключи учетной записи, используемые связанными службами. Дополнительные сведения см. в разделе CI/CD в Azure Synapse Analytics.
Развертывание управляемой частной конечной точки поддерживается только в версии 2.x. Убедитесь, что выбрана правильная версия и проверьте управляемые управляемые частные конечные точки в шаблоне.
Для управления триггерами можно использовать переключатель триггеров, чтобы отключить триггеры перед развертыванием. Кроме того, можно добавить задачу для перезапуска триггеров после задачи развертывания.
Внимание
В сценариях CI/CD тип среды выполнения интеграции в разных средах должен совпадать. Например, если у вас есть локальная среда выполнения интеграции в среде разработки, та же среда выполнения интеграции должна использоваться в качестве локальной в других средах, таких как тестовая и рабочая. Аналогично, если вы совместно используете среды выполнения интеграции на разных этапах, среды выполнения интеграции должны быть связанными и локальными во всех средах, например, в средах разработки, тестирования и в рабочих средах.
Создание выпуска для развертывания
После сохранения всех изменений можно нажать кнопку Создать выпуск, чтобы вручную создать выпуск. Сведения об автоматизации создания выпуска см. в разделе Триггеры выпуска Azure DevOps.
Настройка выпуска в GitHub Actions
В этом разделе вы узнаете, как создавать рабочие процессы GitHub, используя GitHub Actions для развертывания рабочей области Azure Synapse.
Чтобы автоматизировать развертывание шаблона ARM в Azure для рабочей области и вычислительных пулов, воспользуйтесь шаблоном GitHub Actions для Azure Resource Manager.
Файл рабочего процесса
Определение рабочего процесса в GitHub Actions с помощью файла YAML (.yml), размещенного в репозитории по пути /.github/workflows/. Это определение содержит разные шаги и параметры рабочего процесса.
Этот файл .yml содержит два раздела:
Section | Задачи |
---|---|
Аутентификация | 1. Определение субъекта-службы. 2. Создание секрета GitHub. |
Развертывание | Разверните артефакты рабочей области. |
Настройка секретов GitHub Actions
Секреты GitHub Actions — это зашифрованные переменные среды. Любой пользователь, имеющий разрешение участника совместной работы для этого репозитория, может использовать эти секреты для взаимодействия с GitHub Actions в репозитории.
В репозитории GitHub перейдите на вкладку Параметры и выберите Секреты>Создать секрет репозитория.
Добавьте новый секрет для идентификатора клиента и добавьте новый секрет клиента, если вы используете субъект-службу для развертывания. Вы также можете сохранить в качестве секретов идентификатор подписки и идентификатор арендатора.
Добавление рабочего процесса
Перейдите в раздел Actions (Действия) в репозитории GitHub.
Выберите Set up your workflow yourself (Настроить рабочий процесс самостоятельно).
В файле рабочего процесса удалите все содержимое после раздела
on:
. После этого рабочий процесс должен выглядеть примерно так:name: CI on: push: branches: [ master ] pull_request: branches: [ master ]
Переименуйте рабочий процесс. На вкладке Marketplace выполните поиск действия развертывания рабочей области Synapse и добавьте действие.
Укажите необходимые значения и шаблон рабочей области:
name: workspace deployment on: push: branches: [ publish_branch ] jobs: release: # You also can use the self-hosted runners. runs-on: windows-latest steps: # Checks out your repository under $GITHUB_WORKSPACE, so your job can access it. - uses: actions/checkout@v2 - uses: azure/synapse-workspace-deployment@release-1.0 with: TargetWorkspaceName: 'target workspace name' TemplateFile: './path of the TemplateForWorkspace.json' ParametersFile: './path of the TemplateParametersForWorkspace.json' OverrideArmParameters: './path of the parameters.yaml' environment: 'Azure Public' resourceGroup: 'target workspace resource group' clientId: ${{secrets.CLIENTID}} clientSecret: ${{secrets.CLIENTSECRET}} subscriptionId: 'subscriptionId of the target workspace' tenantId: 'tenantId' DeleteArtifactsNotInTemplate: 'true' managedIdentity: 'False'
Теперь все готово для фиксации изменений. Выберите Start commit (Начать фиксацию), введите название и добавьте описание (необязательно). Затем выберите Commit new file (Зафиксировать новый файл).
Файл появится в папке . .github/workflows в репозитории.
Примечание.
Управляемое удостоверение поддерживается только на локально размещенных виртуальных машинах в Azure. Не забудьте установить локальное размещение для средства выполнения тестов. Включите управляемое удостоверение для виртуальной машины, назначаемое системой, и добавьте его в Azure Synapse Studio в качестве администратора Synapse.
Проверка развертывания
Перейдите в раздел Actions (Действия) в репозитории GitHub.
Откройте первый результат, чтобы проверить подробные журналы выполнения рабочего процесса:
Создание пользовательских параметров в шаблоне рабочей области
Если вы используете автоматизированную CI/CD и хотите изменить некоторые свойства во время развертывания, но свойства не параметризованы по умолчанию, можно переопределить шаблон параметров по умолчанию.
Чтобы переопределить шаблон параметров по умолчанию, необходимо создать пользовательский шаблон параметров template-parameters-definition.json в корневой папке вашей ветви Git. Необходимо использовать именно это имя файла. Если рабочая область Azure Synapse публикуется из ветви совместной работы или задача развертывания подтверждает артефакты в других ветвях, она считывает этот файл и использует его конфигурацию для генерирования параметров. Если рабочая область Azure Synapse не находит этот файл, используется шаблон параметров по умолчанию.
Синтаксис пользовательских параметров
Для создания файла пользовательских параметров можно использовать следующие рекомендации:
- Введите путь к свойству в соответствующем типе сущности.
- Присвоение для имени свойства значения
*
указывает, что необходимо параметризовать все свойства под ним (только до первого уровня, но не рекурсивно). В этой конфигурации можно задать исключения. - Установка значения свойства в виде строки указывает, что вы хотите параметризовать свойство. Используйте формат
<action>:<name>:<stype>
.<action>
может быть одним из следующих символов:=
означает сохранение текущего значения как значения по умолчанию для параметра.-
означает, что не следует хранить значение по умолчанию для параметра.|
используется для секретов из Azure Key Vault для строк подключения или ключей.
<name>
— это имя параметра. Если оно пустое, то принимает имя свойства. Если значение начинается со знака-
, то оно сокращено. Например,AzureStorage1_properties_typeProperties_connectionString
будет сокращено доAzureStorage1_connectionString
.<stype>
является типом параметра. Если параметр<stype>
пуст, используется тип по умолчаниюstring
. Поддерживаемые значения:string
,securestring
,int
,bool
,object
,secureobject
иarray
.
- При указании массива в файле можно указать, что соответствующее свойство в шаблоне является массивом. Azure Synapse выполняет итерацию по всем объектам в массиве, используя указанное определение. Второй объект, строка, становится именем свойства, которое используется в качестве имени параметра для каждой итерации.
- Определение не может быть указано для экземпляра ресурса. Любое определение применяется ко всем ресурсам этого типа.
- По умолчанию все защищенные строки (например, секреты Key Vault) и защищенные строки (например, строки подключения, ключи и маркеры) являются параметризованными.
Примеры определения шаблона параметров
Вот пример того, как выглядит определение шаблона параметров:
{
"Microsoft.Synapse/workspaces/notebooks": {
"properties": {
"bigDataPool": {
"referenceName": "="
}
}
},
"Microsoft.Synapse/workspaces/sqlscripts": {
"properties": {
"content": {
"currentConnection": {
"*": "-"
}
}
}
},
"Microsoft.Synapse/workspaces/pipelines": {
"properties": {
"activities": [{
"typeProperties": {
"waitTimeInSeconds": "-::int",
"headers": "=::object",
"activities": [
{
"typeProperties": {
"url": "-:-webUrl:string"
}
}
]
}
}]
}
},
"Microsoft.Synapse/workspaces/integrationRuntimes": {
"properties": {
"typeProperties": {
"*": "="
}
}
},
"Microsoft.Synapse/workspaces/triggers": {
"properties": {
"typeProperties": {
"recurrence": {
"*": "=",
"interval": "=:triggerSuffix:int",
"frequency": "=:-freq"
},
"maxConcurrency": "="
}
}
},
"Microsoft.Synapse/workspaces/linkedServices": {
"*": {
"properties": {
"typeProperties": {
"accountName": "=",
"username": "=",
"connectionString": "|:-connectionString:secureString",
"secretAccessKey": "|"
}
}
},
"AzureDataLakeStore": {
"properties": {
"typeProperties": {
"dataLakeStoreUri": "="
}
}
},
"AzureKeyVault": {
"properties": {
"typeProperties": {
"baseUrl": "|:baseUrl:secureString"
},
"parameters": {
"KeyVaultURL": {
"type": "=",
"defaultValue": "|:defaultValue:secureString"
}
}
}
}
},
"Microsoft.Synapse/workspaces/datasets": {
"*": {
"properties": {
"typeProperties": {
"folderPath": "=",
"fileName": "="
}
}
}
},
"Microsoft.Synapse/workspaces/credentials" : {
"properties": {
"typeProperties": {
"resourceId": "="
}
}
}
}
Ниже приведено описание конструкции предыдущего шаблона, упорядоченного по типу ресурсов.
notebooks
- Все свойства в пути
properties/bigDataPool/referenceName
параметризованы с использованием значений по умолчанию. Можно параметризовать подключенный пул Spark для каждого файла записной книжки.
sqlscripts
- В пути
properties/content/currentConnection
свойстваpoolName
иdatabaseName
параметризованы как строки без использования значений по умолчанию в шаблоне.
pipelines
- Все свойства в пути
activities/typeProperties/waitTimeInSeconds
параметризованы. Любое действие в конвейере, которое имеет свойство уровня кода с именемwaitTimeInSeconds
(например, действиеWait
) параметризовано как число с именем по умолчанию. Для свойств в шаблоне Resource Manager не будут использоваться значения по умолчанию. Вместо них необходимо вводить значения свойств во время развертывания Resource Manager. - Свойство
headers
(например, в действииWeb
) параметризовано с типомobject
(объект). Свойствоheaders
имеет значение по умолчанию, то есть то же значение, что и у исходной фабрики.
integrationRuntimes
- Все свойства в пути
typeProperties
параметризованы с использованием соответствующих значений по умолчанию. Например, два свойства находятся под свойствами типаIntegrationRuntimes
:computeProperties
иssisProperties
. Оба типа свойств создаются с соответствующими значениями по умолчанию и типами (объект).
triggers
В разделе
typeProperties
параметризованы два свойства:- Свойство
maxConcurrency
имеет значение по умолчанию и относится к типуstring
. Имя параметра по умолчанию для свойстваmaxConcurrency
—<entityName>_properties_typeProperties_maxConcurrency
. - Свойство
recurrence
также параметризовано. Все свойства под свойствомrecurrence
должны быть параметризованы как строки с использованием значений по умолчанию и имен параметров. Исключением является свойствоinterval
, параметризованное как типint
. Имя параметра имеет суффикс<entityName>_properties_typeProperties_recurrence_triggerSuffix
. Аналогичным образом свойствоfreq
— это строка, и параметризовано как строка. Однако свойствоfreq
параметризовано без значения по умолчанию. Имя сокращено и имеет суффикс, например<entityName>_freq
.
Примечание.
В настоящее время поддерживается не более 50 триггеров.
- Свойство
linkedServices
- Связанные службы уникальны. Так как связанные службы и наборы данных имеют широкий спектр типов, можно указать настройку для конкретного типа. В предыдущем примере для всех связанных служб типа
AzureDataLakeStore
применяется конкретный шаблон. Для всех остальных (идентифицируемых с помощью символа*
) применяется другой шаблон. - Свойство
connectionString
параметризовано как значениеsecurestring
. Оно не имеет значения по умолчанию. Имя параметра сокращено и имеет суффиксconnectionString
. - Свойство
secretAccessKey
параметризовано как значениеAzureKeyVaultSecret
(например, в связанной службе Amazon S3). Свойство автоматически параметризовано как секрет Azure Key Vault и получено из настроенного хранилища ключей. Вы также можете параметризовать само хранилище ключей.
datasets
- Можно настраивать типы в наборах данных, однако явная настройка на уровне * не требуется. В предыдущем примере все свойства набора данных в разделе
typeProperties
были параметризованными.
Рекомендации для CI/CD
В случае интеграции Git с рабочей областью Azure Synapse и использования конвейера CI/CD для перемещения изменений из среды разработки в тестовую и рабочую, следует придерживаться приведенных ниже рекомендаций:
- Интегрируйте только рабочую область разработки с Git. При использовании интеграции с Git интегрируйте в Git только рабочую область разработки Azure Synapse. Изменения в тестовую и рабочую рабочие области развертываются в рамках процесса CI/CD, и им не требуется интеграция Git.
- Подготовьте пулы перед миграцией артефактов. Если у вас есть скрипт или записная книжка SQL, присоединенные к пулам в рабочей области для разработки, используйте одно имя для пулов в разных средах.
- Синхронизируйте управление версиями в инфраструктуре как сценарии кода. Для управления инфраструктурой (сетями, виртуальными машинами, подсистемами балансировки нагрузки и топологией подключений) в описательной модели используйте то же средство управления версиями, которое использует команда DevOps для исходного кода.
- Ознакомьтесь с рекомендациями по работе с Фабрикой данных Azure. Если вы используете фабрику данных, ознакомьтесь с рекомендациями по использованию артефактов Фабрики данных.
Устранение неполадок при развертывании артефактов
Использование задачи развертывания рабочей области Synapse для развертывания артефактов Synapse
В Azure Synapse, в отличие от фабрики данных, артефакты не являются ресурсами Resource Manager. Для развертывания артефактов Azure Synapse нельзя использовать задачу развертывания шаблона ARM. Вместо этого используйте задачу развертывания рабочей области Synapse для развертывания артефактов и использования задачи развертывания ARM для развертывания ресурсов ARM (пулов и рабочей области). Тем временем эта задача поддерживает только шаблоны Synapse, где ресурсы имеют тип Microsoft.Synapse. И с помощью этой задачи пользователи могут автоматически развертывать изменения из любых ветвей без нажатия кнопки публикации в Студии Synapse. Ниже приведены некоторые часто возникающие проблемы.
1. Сбой публикации: файл arm рабочей области превышает 20 МБ
Существует ограничение размера файла в поставщике Git, например, в Azure DevOps максимальный размер файла составляет 20 МБ. После того как размер файла шаблона рабочей области превышает 20 МБ, эта ошибка возникает при публикации изменений в Студии Synapse, в которой файл шаблона рабочей области создается и синхронизируется с git. Чтобы устранить проблему, можно использовать задачу развертывания Synapse с проверкой или проверкой и развертыванием, чтобы сохранить файл шаблона рабочей области непосредственно в агент конвейера и без ручной публикации в synapse Studio.
2. Непредвиденная ошибка маркера в выпуске
Если файл параметров содержит значения параметров, которые не содержат escape-символов, конвейер выпуска не сможет выполнить синтаксический анализ файла и выдаст ошибку unexpected token
. Рекомендуется переопределить параметры или использовать Azure Key Vault для получения значений параметров. Для устранения проблемы можно также использовать двойные escape-символы.
3. Сбой развертывания среды выполнения интеграции
Если вы создали шаблон рабочей области из рабочей области с поддержкой управляемой виртуальной сети и попытаетесь развернуть ее в обычной рабочей области или наоборот, эта ошибка возникает.
4. При анализе значения непредвиденного символа
Не удается проанализировать файл шаблона. Попробуйте, экранируя косую черту, например \\Test01\Test01\Test
5. Не удалось получить сведения о рабочей области, не найдено
Сведения о целевой рабочей области настроены неправильно. Убедитесь, что созданное подключение службы распространяется на группу ресурсов, в которой находится рабочая область.
6. Сбой удаления артефакта
Расширение сравнивает артефакты, представленные в ветви публикации с шаблоном, и на основе разницы, в соответствии с которыми они будут удалены. Убедитесь, что вы не пытаетесь удалить артефакт, который присутствует в ветви публикации, и некоторые другие артефакты имеют ссылку или зависимость от него.
7. Сбой развертывания с ошибкой: позиция JSON 0
Если вы пытались вручную обновить шаблон, эта ошибка произойдет. Убедитесь, что вы не изменили шаблон вручную.
8. Сбой создания или обновления документа из-за недопустимой ссылки
Артефакт в synapse можно ссылаться на другой. Если вы параметризировали атрибут, на который ссылается артефакт, обязательно укажите правильное и непустое значение для него.
9. Не удалось получить состояние развертывания в развертывании записной книжки
Записная книжка, которую вы пытаетесь развернуть, подключена к пулу Spark в файле шаблона рабочей области, в то время как в развертывании пул не существует в целевой рабочей области. Если вы не параметризуете имя пула, убедитесь, что для пулов между средами одинаковые имена.