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

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

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

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

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

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

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

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

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

Большое спасибо. Отметка.


person MarkD    schedule 30.10.2018    source источник
comment
Какие-нибудь обновления или решения по этому поводу? Я также пытаюсь установить другое время выполнения для каждой среды и изменить настройку времени выполнения при развертывании шаблона ARM с помощью настраиваемого развертывания. Я согласен с тем, что, похоже, они предполагают, что у вас будет одна среда выполнения, общая для всех сред, а не одна для каждой среды.   -  person AaronTC05    schedule 15.03.2019
comment
извините - был в отъезде какое-то время. Я решил, что разработчик должен создать IR, который используется в UAT и Prod. то есть самостоятельно размещенный, самостоятельно размещенный с подтипом общего доступа или самостоятельно размещенным / подтипом связанных. Затем я настроил фабрики UAT и Prod для использования среды выполнения интеграции с тем же именем и конфигурацией, что и dev. Теперь CI выполняет начальное развертывание и обновления. Другими словами, нижестоящим ADF требуется небольшая предварительная конфигурация для соответствия разработчику - тогда они принимают обновления. LMK, если вам нужны подробности. У меня это работает с 3 разными видами ИК.   -  person MarkD    schedule 18.04.2019
comment
Если соединение одинаково во всех средах, обходной путь - создать дополнительную фабрику данных для автономных сред выполнения интеграции, а затем использовать связанные среды выполнения интеграции хоста в фабриках данных dev, uat и production.   -  person mkstr    schedule 15.01.2020
comment
@mkstr, да, теперь это предпочтительный метод. Если мы используем MSI, мы тщательно следим за тем, чтобы в каждой среде был один локальный IR, а затем чтобы фабрики dev / uat / prod совместно использовали соответствующий локальный IR. Таким образом, разрешения каждого внутреннего IR могут быть установлены как соответствующие для доступа только к данным dev / uat / prod.   -  person MarkD    schedule 16.01.2020


Ответы (1)


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

Короче говоря, это влияет на вас, только если

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

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

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

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

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

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

person MarkD    schedule 07.11.2018
comment
Еще одно открытие, которое не решает эту проблему, но помогает безопасности. MSFT выпустила предварительную версию виртуальных сетей для ADL Gen1. Внимательно прочтите ограничения, но это может помочь нам обойти проблему безопасности, связанную с внесением в белый список, до тех пор, пока этот шаблон развертывания не будет исправлен. - person MarkD; 07.11.2018