Конфликт между выпуском конвейера и временем выполнения интеграции

Question

Этот вопрос относится к тому, как распространять фабрику данных через CI (в VSTS), если в фабрике данных определена среда автономного размещения интеграции.

У меня настроено 3 среды - Dev / UAT / Prod, каждая со своей фабрикой данных.

В Dev размещена основная ветка для совместной работы. Я использую VSTS для извлечения артефактов из ветви adf_publish и развертывания шаблона в UAT (prod будет сделан позже). Я следовал многому из того, что в этом руководстве здесь .

При развертывании в пустой UAT с автономной средой выполнения (IR) IR, развернутый в UAT, является копией общего IR из dev (не связанного типа), и это вызывает ошибку, поскольку используются учетные данные ИР не будет правильным. Я ожидаю этого, поскольку на самом деле мы просто развертываем точную копию шаблона группы ресурсов с переопределенным именем фабрики, однако IR не будет работать без повторной аутентификации на собственных виртуальных машинах IR.

Если я предварительно зарегистрировал связанный IR в среде UAT (связанный с dev IR), то развертывание завершится неудачно с конфликтом, потому что IR в шаблоне группы ресурсов совпадает с именем, которое я только что создал в UAT , Если это другое имя - нет конфликта, но связанные службы будут указывать на шаблон IR, а не тот, который я создал для UAT

В документах есть примечание, в котором говорится, что время выполнения IR должно быть одинаковым на всех платформах, но я не думаю, что это может быть правдой - одна из них (предположительно, источник / dev) должна быть общего типа, а другие связаны и авторизован.

Один вариант, который я мог видеть (не проверенный), состоит в том, чтобы привязка IR каждой среды представляла собой отдельное соединение с фактической IR, но тогда должен быть какой-то способ переопределения связанных служб для указания на ссылку IR текущей среды (посредством переопределение параметра шаблона?). В этом сценарии нам нужно заблокировать развертывание шаблонов IR, так как оно не понадобится и не будет работать.

У кого-нибудь был успех в получении CI, работающем в этой ситуации? Я чувствую, что документ был написан с глобальным ИК. Либо это, либо мне нужно лучше понять цель настройки автоматической интеграции в определении связанных служб.

Большое спасибо. Марк.

Answer 1

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

В двух словах, это влияет только на вас, если

1. у вас есть интегрированная среда выполнения (IR) и
2. вы пытаетесь развернуть шаблон в новой фабрике данных из существующей фабрики данных (как это было бы в Dev-> UAT-> Prod)
3. у вас есть связанная служба данных (ADL), определенная и использующая собственный IR.

Если в шаблоне имеется автономный IR, вновь развернутая копия не будет зарегистрирована ни на одном сервере (связанном или уникальном с новым ADF), поскольку шаблон только записывает IR, он не создает его экземпляр.

Хотя это можно исправить в конфигурации или сценариях после развертывания, но это не может исправить зависимость от ADL. Это связано с тем, что связанная служба ADL хочет зашифровать субъект-службу с помощью IR .... но IR не существует во время развертывания шаблона (т.е. не настроен на сервере и не активен).

Не лучше, если вы выберете Идентификатор управляемой службы в качестве аутентификации в связанной службе ADL вместо субъекта службы, тогда шаблон не будет развернут, потому что нет учетных данных для шифрования, и похоже, что ресурс ожидает что-то для шифрования .

Обходной путь сейчас заключается в том, чтобы использовать размещенный в Azure IR для соединений с данными. К сожалению, для нас это вызывает проблемы с безопасностью, поскольку общие IR не могут быть внесены в белый список в нашем ADL Gen 1.

Я буду держать вас в курсе.