Этот пост переведён автоматически. Чтобы прочитать оригинал, нажмите здесь.
Честно говоря: каждый раз, когда в туториале вижу «требует контейнер», где-то внутри вздыхаю. Контейнеры великолепны — пока у вашей команды нет стратегии контейнеризации, и функция, казавшаяся простой, вдруг упирается в неожиданную оркестрационную сложность, которую никто не планировал.
Именно поэтому это привлекло моё внимание. SQL MCP Server теперь может работать на Azure App Service — без Docker, без Kubernetes, только с тем же конфигурационным файлом Data API Builder (DAB), который открывает ваш SQL-датабаз через MCP, REST и GraphQL.
Что такое SQL MCP Server?
Кратко для тех, кто ещё не знаком. SQL MCP Server располагается между вашим AI-агентом и SQL-базой данных. Вместо того чтобы давать агенту прямой доступ к базе данных (ужасная идея), он открывает ваши таблицы и представления как уровень абстракции — сущности с определёнными правами доступа.
Построен на Data API Builder, что означает: один конфигурационный файл управляет MCP и REST и GraphQL одновременно. Ваш агент общается с MCP-эндпоинтом. Традиционное приложение общается с REST или GraphQL. Одна конфигурация, одна среда выполнения, разные интерфейсы.
Это действительно удобно. Не нужно поддерживать два отдельных API-слоя.
Проблема контейнеров (и её решение)
Изначальная модель развёртывания SQL MCP Server использовала контейнеры. Это хорошо работает во многих командах — но не во всех. Многие .NET-команды стандартизировались на Azure App Service или виртуальных машинах. Требовать контейнерный runtime только ради одного SQL-эндпоинта — это лишнее трение, которого никто не просил.
Новое руководство показывает, как обойтись без контейнера вовсе. Всё работает через команду dab start, запущенный как стандартный .NET 8 веб-процесс на App Service.
# Установка Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g
# Инициализация конфигурации
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"
# Добавление сущности
dab add products --source dbo.products --permissions "authenticated:*"
# Настройка провайдера аутентификации App Service
dab configure --runtime.host.authentication.provider AppService
# Запуск сервера
dab start
На этом этапе у вас есть MCP по адресу /mcp, REST и GraphQL из того же процесса — и ничего в контейнере.
Аутентификация без общих API-ключей
Это та часть, которую я ценю больше всего. При развёртывании на App Service вы настраиваете Microsoft Entra ID в качестве провайдера аутентификации. Никаких общих секретов в конфигурационных файлах, никаких API-ключей для ротации.
Строка подключения хранится в переменных среды App Service (не в dab-config.json), а MCP-эндпоинт защищён платформенной аутентификацией. Если ваши Azure-нагрузки уже используют Entra ID, интеграция происходит органично.
Для локальной разработки переключайтесь в режим Simulator и STDIO-транспорт. Возвращайтесь к режиму AppService перед развёртыванием. Чисто и явно.
Развёртывание на App Service
az appservice plan create \
--name <plan-name> \
--resource-group <resource-group> \
--sku B1 \
--is-linux
az webapp create \
--name <app-name> \
--resource-group <resource-group> \
--plan <plan-name> \
--runtime "DOTNETCORE:8.0"
az webapp config set \
--name <app-name> \
--resource-group <resource-group> \
--startup-file "dab start"
Затем разверните свой DAB-проект методом, который уже использует ваша команда. Ключевой момент: это развёртывание кода, а не контейнера.
Почему это важно для .NET-разработчиков
Если вы создаёте AI-агентов на .NET, рано или поздно им нужно будет работать с базой данных. SQL MCP Server предоставляет структурированный способ сделать это — без открытия сырых строк подключения или написания собственных API-слоёв.
Ознакомьтесь с полным руководством в оригинальной статье и примере на GitHub.
Итог
SQL MCP Server на App Service — практичный выбор для .NET-команд, которые хотят дать агентам структурированный доступ к SQL-данным без контейнерной стратегии. Попробуйте — ваши агенты оценят чистый API-интерфейс.
