Агент сборки Azure DevOps "Hosted 2017" не разрешает соединение SQL
У меня есть очень простой DacPac, который создается на основе сборки DevOps Azure и выпускается конвейером выпуска. Сборка работает нормально, но конвейер завершается с ошибкой подключения. Я проверил и перепроверил настройку. Правила брандмауэра правильно установлены на целевом сервере, учетные данные действительны, но выпуск просто не пройдет. Я пробовал много разных комбинаций, включая указание портов, но не могу подключить его. Если я пытаюсь инициировать соединение из PowerShell и Invoke-SqlCmd, я получаю похожую ошибку подключения.
Кто-нибудь может пролить свет?
Существуют ли какие-либо ограничения на порты (например, блокировка 1433) на агенте Hosted 2017?
Нужно ли обновлять агента?
Нужны ли дополнительные настройки для подключения SQL?
Спасибо
Я получаю ошибку:
Невозможно подключиться к целевому серверу.database.windows.net. Проверьте информацию о соединении, такую как имя сервера, учетные данные для входа и правила брандмауэра для целевого сервера. Ошибка входа для данных пользователя...
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. Сборка инфраструктуры /DBScripts/bin/Debug/MyProj.Database.dacpac" /Action:Publish /tcs:"Server=myprodsql.database.windows.net;Initial Catalog=OptimisedDb; Сохранять информацию о безопасности =False; ID пользователя ='$(adminUserEmail)';Password=' $(adminUserPassword)';MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False; Аутентификация = пароль Active Directory "
Я много боролся с той же проблемой. Мне удалось исправить это, выполнив следующие два шага
- Изменилось соединение с базой данных на другой сервер, и как только это будет успешным, я верну его обратно на текущий сервер.
- Уровень совместимости базы данных изменен до ниже 150.
- Создан свежий релиз
ниже ссылки мне помогли. Надеюсь это поможет.
Разрешение всех диапазонов IP-адресов для моей базы данных SQL Azure сделало это за меня. Теперь мне просто нужно выяснить и сузить, на каких IP-адресах работает мой агент сборки в моем конвейере сборки Azure DevOps.
Автоматическая установка правил брандмауэра в задаче сборки Azure DevOps не работает.
У меня была такая же проблема и раньше, самый простой способ обойти это - занести в белый список каждый 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 и установить на нее агент сборки. Не идеально, но это сработало.