Агент сборки Azure DevOps "Hosted 2017" не разрешает соединение SQL

Question

У меня есть очень простой DacPac, который создается на основе сборки DevOps Azure и выпускается конвейером выпуска.Сборка работает нормально, но конвейер завершается с ошибкой подключения.Я проверил и перепроверил настройку.Правила брандмауэра правильно установлены на целевом сервере, учетные данные действительны, но выпуск просто не пройдет.Я пробовал много разных комбинаций, включая указание портов, но не могу подключить его.Если я пытаюсь инициировать соединение из PowerShell и Invoke-SqlCmd, я получаю похожую ошибку соединения.

Может кто-нибудь пролить свет?

Существуют ли какие-либо ограничения для портов, которые могут мешать (например, блокировка 1433) агента Hosted 2017?

Нужно ли обновлять агента?

какая-то дополнительная конфигурация, необходимая для подключения SQL?

Спасибо

Я получаю ошибку:

Невозможно подключиться к целевому серверу '.database.windows.net.Проверьте информацию о соединении, такую ​​как имя сервера, учетные данные для входа и правила брандмауэра для целевого сервера.Ошибка входа в систему для данных пользователя ...

Answer 1

Разрешение всех диапазонов IP-адресов для моей базы данных SQL Azure сделало это для меня.Теперь мне просто нужно выяснить и сузить, на каких IP-адресах работает мой агент компоновки в моем конвейере компоновки DevOps Azure.

Автоматическая настройка правил брандмауэра в задаче сборки Azure DevOps не работает.

Answer 2

Кажется, AD Auth не поддерживается стандартным действием публикации SQL.Пользовательский интерфейс позволяет вам предоставлять учетные данные только для пользователя SQL.Существует возможность предоставить строку подключения через параметр /TargetConnectionString для SqlPackage.exe, однако это не работает, поскольку пользовательский интерфейс требует учетные данные SQL, и их нельзя использовать вместе с параметром /TargetConnectionString.

Я решил эту проблему, запустив SqlPackage.exe из стандартного сценария выпуска PowerShell.

& "C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ Common7 \ IDE \ Extensions \ Microsoft \ SQLDB \ DAC \ 140 \ SqlPackage.exe" / SourceFile: "$ (System.DefaultWorkingDirectory) / _ MyProj.Infrastructure build / DBScripts / bin / Debug / MyProj.Database.dacpac "/ Action: Publish /tcs:"Server=myprodsql.database.windows.net;Initial Catalog = OptimisedDb; Сохранять информацию о безопасности= Ложь; ID пользователя = '$ (adminUserEmail)'; Пароль = '$ (adminUserPassword)'; MultipleActiveResultSets = False; Encrypt = True; TrustServerCertificate = False; Аутентификация = Пароль Active Directory "

Answer 3

У меня раньше была такая же проблема, самый простой способ обойти это - занести в белый список каждый IP-адрес, который есть у DevOps - к сожалению, этот список довольно большой в зависимости от вашей географии и меняется еженедельно.

Я написал сценарий PS1, чтобы проанализировать список и убедиться в наличии необходимых правил.

https://www.microsoft.com/en-nz/download/details.aspx?id=41653

Однако есть несколько очевидных (ина один меньше) проблемы с этим ...

Список IP-адресов для некоторых регионов огромен, настолько велик, что база данных Azure не может иметь их все, он превышает предел.

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

Поэтому я попытался установить 0.0.0.0/allow доступ к настройке Azure, но на самом деле это не помогло DevOps..

Моим конечным решением было раскрутить виртуальную машину в Azure и установить на нее агент сборки.Не идеально, но это сработало.

Answer 4

Вам необходимо указать порт: xxx.database.windows.net,1433.