Aspire | The .NET Blog

Частные Endpoints, VNets, NSG — Aspire Теперь Управляет Сетью

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

Я видел этот сценарий слишком много раз. Приложение готово. Демонстрация великолепна. Затем появляется чеклист безопасности: убрать хранилище из публичного интернета, запустить внутри VNet, предоставить исходящие IP для allowlist партнёра, доказать, что только правильные подсети общаются с правильными сервисами.

В этот момент модель приложения и модель инфраструктуры начинают расходиться способами, которые болезненно поддерживать.

Новая поддержка корпоративных сетей Azure для Aspire решает это напрямую. Вы описываете форму сети рядом с ресурсами, которые её используют, в вашем AppHost.

Строительные блоки

Вот для чего предназначена каждая концепция сети Azure, в кратком изложении:

Функция	Используйте когда	Почему это важно
Виртуальная сеть	Вам нужно частное адресное пространство	Сетевая граница для подсетей, частных endpoints и маршрутизации
Подсеть	Вам нужно разделить рабочие нагрузки внутри VNet	Каждая часть системы получает свой собственный диапазон адресов и поверхность политики
Делегированная подсеть	Платформенный сервис (например, ACA) должен управлять подсетью	Позволяет сервису безопасно размещать управляемую инфраструктуру в вашей VNet
NAT-шлюз	Вам нужны предсказуемые исходящие публичные IP	Стабильный адрес для allowlist и аудита
Частный endpoint	Вы хотите, чтобы ресурс PaaS был доступен приватно	Помещает частный IP для этого сервиса внутри вашей VNet, убирает публичную экспозицию
NSG	Вам нужны правила трафика на уровне подсети	Явное разрешение/запрет для входящего и исходящего трафика на подсеть

Описание в AppHost

Ключевое изменение здесь состоит в том, что вы моделируете сеть вместе с ресурсами, которые её используют, а не в отдельном файле Bicep, который со временем расходится с моделью приложения.

Из AppHost вы можете:

Создавать VNet и подсети с AddVirtualNetwork() и AddSubnet()
Прикреплять NAT-шлюз к подсетям для стабильных исходящих IP
Создавать частные endpoints для хранилища, Key Vault, SQL и других PaaS-сервисов
Определять NSG с правилами входящей и исходящей безопасности
Настраивать периметры сетевой безопасности для межресурсных политик

В результате когда вы запускаете azd up, инфраструктура соответствует тому, что модель приложения говорит, что ей нужно. Не то, что говорит вручную поддерживаемый шаблон.

Почему Это Важно для Реальных Приложений

Несколько вещей, которые становятся значительно проще, как только сеть смоделирована в Aspire:

Частные endpoints для Key Vault и хранилища — вы описываете WithPrivateEndpoint() на этих ресурсах, и Aspire берёт на себя настройку DNS-зон и присоединение endpoints. Приложение никогда не меняется.

Стабильные исходящие IP — добавьте NAT-шлюз к соответствующей подсети, и каждый исходящий запрос вашего приложения проходит через известный, стабильный IP. Партнёры могут добавить его в allowlist. Аудиторы могут его отследить.

Правила NSG из кода — вместо того чтобы кликать по порталу или поддерживать фрагмент Bicep, ваши правила безопасности живут в AppHost рядом с ресурсами, которые они защищают.

Это тот тип интеграции, который не делает демонстрации захватывающими, но делает производственные системы обслуживаемыми.

Итог

Сетевая безопасность, появляющаяся поздно в жизненном цикле проекта, — решённая проблема, если вы моделируете её вместе с приложением с самого начала. Поддержка корпоративных сетей Aspire делает это возможным без необходимости отдельного инфраструктурного трека.

Полные подробности в оригинальном посте: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Поддержка Kubernetes, журналы браузера и навык Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Пять недель — небольшой срок для релиза, но Aspire 13.3 так не ощущается. Ключевые элементы весомые: первоклассное развёртывание Kubernetes и AKS с Helm, навык онбординга с помощью агента под названием Aspireify, захват журналов браузера прямо в дашборде и структурированные результаты команд. Плюс 45 новых функций, 134 улучшения и 93 исправления ошибок.

Давайте разберём основные моменты.

Aspireify: Онбординг с помощью агента

Добавление Aspire к существующему проекту звучит просто — добавьте AppHost, готово. На практике это требует немало исследований: какие порты важны, какие переменные окружения являются реальными зависимостями, какие сервисы Docker Compose должны отображаться на интеграции Aspire.

Новый навык Aspireify даёт вашему агенту кодирования управляемый рабочий процесс именно для этого. Когда aspire init создаёт скелетный AppHost, навык Aspireify помогает агенту проверить репозиторий, понять как он уже работает и подключить AppHost так, чтобы он соответствовал приложению — а не наоборот.

Позиция по умолчанию — “минимизировать изменения в вашем коде.” Если ваше приложение уже читает DATABASE_URL, агент сопоставляет это с WithEnvironment() вместо того, чтобы просить вас переписать конфигурацию. Если порт жёстко задан, навык указывает агенту, когда его сохранить.

Это именно тот тип ИИ-инструментов, который реально экономит время, а не генерирует больше работы для проверки.

Первоклассное развёртывание Kubernetes и AKS

Это было в списке пожеланий уже давно. Aspire 13.3 поставляется с первоклассной поддержкой развёртывания Kubernetes и AKS с Helm. Теперь вы можете указывать AKS в качестве целевого объекта развёртывания прямо из инструментов Aspire.

Для команд, которые уже запускают производственные нагрузки на AKS, это закрывает значительный пробел. Ваша модель приложения Aspire теперь имеет чёткий путь от локальной разработки до Kubernetes без ручного создания Helm-чартов.

Журналы браузера в дашборде

Это одна из тех функций, которые кажутся небольшими, пока вы не отлаживаете проблему с фронтендом.

Новый API WithBrowserLogs() прикрепляет отслеживаемый ресурс браузера к любому ресурсу, поддерживающему endpoint’ы. Aspire запускает Chromium с использованием приватного CDP-пайпа и передаёт журналы консоли, сетевые запросы и ошибки прямо в поток журналов ресурса:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost поддерживает то же самое:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Ошибки консоли, неудавшиеся сетевые запросы, исключения на стороне клиента — всё видно в том же дашборде, где вы уже следите за трассировками и метриками. Больше не нужно переключаться на DevTools браузера для базовых вещей.

Структурированные результаты команд

Команды ресурсов получили значительное обновление. До сих пор команды возвращали успех/неудачу. Теперь они возвращают структурированные результаты: текст, JSON или markdown, который проходит через модель, интерфейс дашборда, CLI и MCP-инструменты.

Дашборд связывает всё это с новым центром уведомлений в заголовке. Результаты команд отображаются как уведомления с временными метками с рендерингом markdown и действием “Просмотреть ответ”.

Это делает команды ресурсов по-настоящему компонуемыми. Интеграция теперь может предоставлять команду, которая возвращает значимый вывод — например, URL туннеля — вместо того, чтобы просто изменять состояние где-то.

Итог

Aspire 13.3 стоит обновления хотя бы ради поддержки Kubernetes. Журналы браузера и структурированные результаты команд — это тип улучшений качества жизни, которые быстро накапливаются в повседневном рабочем процессе разработки.

Полные заметки о выпуске: What’s New in Aspire 13.3

Aspire 13.2: Поддержка Bun, Улучшенные Контейнеры и Меньше Трений при Отладке

Emiliano Montesdeoca — Fri, 24 Apr 2026 00:00:00 +0000

Этот пост был автоматически переведён. Для оригинальной версии нажмите здесь.

Если вы строите .NET-бэкенды с JavaScript-фронтендами в Aspire, 13.2 — это обновление, которое тихо делает ваш день лучше.

Bun теперь первоклассный

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Если ваша команда уже использует Bun, Aspire больше не заставляет плыть против течения.

Yarn стал надёжнее

Пользователи Yarn получают меньше загадочных сбоев с withYarn() и addViteApp().

Улучшения контейнеров

ImagePullPolicy.Never для использования локального образа без обращения к registry. PostgreSQL 18+ с томами данных теперь работает корректно.

Улучшения отладки

DebuggerDisplayAttribute на основных типах, лучшие сообщения об ошибках для WaitFor, BeforeResourceStartedEvent срабатывает в нужный момент.

Оригинальный пост Дэвида Пайна: Aspire 13.2: Bun Support and Container Enhancements.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 проходит 18 апреля 2026 года в Kinépolis Diversia в Алькобендасе, Мадрид. Это крупнейшее сообщественное Azure-мероприятие в Испании, объединяющее 38 спикеров на 3 параллельных треках: ИИ-агенты, сети Azure, Cosmos DB, Fabric, IoT, безопасность и многое другое.

Мероприятие проходит с 08:30 до 18:30 и включает в себя кейноут, кофе-брейки, обед и заключительную сессию вопросов и ответов.

Основные моменты программы

Domando Agentes de IA: управление, инструменты и API с Azure AI Foundry и Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: мультиагентные системы в действии
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Билеты

Регистрация — символическое пожертвование. Вся стоимость билета направляется в Plan International на поддержку прав детей и равенства по всему миру. Количество мест ограничено, поэтому бронируйте заранее.

Azure Tour 2026

Помимо Мадрида, Global Azure Tour 2026 также проходит в Сарагосе, Тенерифе и Севилье.

Хватит нянчить терминал: отсоединённый режим Aspire меняет рабочий процесс

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Каждый раз, когда вы запускаете Aspire AppHost, ваш терминал пропадает. Заблокирован. Занят, пока вы не нажмёте Ctrl+C. Нужно быстро выполнить команду? Откройте ещё одну вкладку. Хотите проверить логи? Ещё одна вкладка. Мелкое неудобство, которое быстро накапливается.

Aspire 13.2 решает эту проблему. James Newton-King описал все подробности, и, честно говоря, это одна из тех фич, которая сразу меняет подход к работе.

Отсоединённый режим: одна команда — терминал свободен

aspire start

Это сокращение для aspire run --detach. Ваш AppHost запускается в фоне, и терминал сразу возвращается к вам. Никаких лишних вкладок. Никаких мультиплексоров терминала. Просто ваш промпт, готовый к работе.

Управление запущенными процессами

Суть в том, что запуск в фоне полезен только тогда, когда вы можете управлять тем, что работает. Aspire 13.2 поставляется с полным набором CLI-команд именно для этого:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Это превращает Aspire CLI в полноценный менеджер процессов. Вы можете запускать несколько AppHost, проверять их статус, отслеживать логи и останавливать их — всё из одной сессии терминала.

Сочетание с изолированным режимом

Отсоединённый режим естественно сочетается с изолированным. Хотите запустить два экземпляра одного проекта в фоне без конфликтов портов?

aspire start --isolated
aspire start --isolated

Каждый получает случайные порты, отдельные секреты и собственный жизненный цикл. Используйте aspire ps, чтобы увидеть оба, aspire stop, чтобы остановить ненужный.

Почему это важно для агентов кода

Вот тут становится по-настоящему интересно. Агент кода, работающий в вашем терминале, теперь может:

Запустить приложение с помощью aspire start
Запросить его состояние через aspire describe
Проверить логи через aspire logs для диагностики проблем
Остановить его командой aspire stop по завершении

Всё это без потери сессии терминала. До появления отсоединённого режима агент, запустивший ваш AppHost, блокировал сам себя в собственном терминале. Теперь он может запускать, наблюдать, итерировать и очищать — именно так, как должен работать автономный агент.

Команда Aspire серьёзно вложилась в это. Запуск aspire agent init настраивает файл навыков Aspire, который обучает агентов этим командам. Таким образом, инструменты вроде агента кода Copilot могут управлять вашими рабочими нагрузками Aspire из коробки.

Подводя итог

Отсоединённый режим — это улучшение рабочего процесса, замаскированное под простой флаг. Вы перестаёте переключаться между терминалами, агенты перестают блокировать сами себя, а новые CLI-команды дают реальную видимость того, что запущено. Это практично, это чисто, и это делает ежедневный цикл разработки заметно более плавным.

Прочитайте полный пост для всех подробностей и установите Aspire 13.2 командой aspire update --self.

.NET Aspire 13.2 хочет стать лучшим другом вашего ИИ-агента

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Знаете тот момент, когда ваш ИИ-агент пишет отличный код, вы воодушевляетесь, а потом всё разваливается, когда он пытается это запустить? Конфликты портов, процессы-призраки, неправильные переменные окружения — внезапно ваш агент сжигает токены на устранение проблем при запуске вместо создания функциональности.

Команда Aspire только что опубликовала очень продуманный пост именно об этой проблеме, и их ответ убедителен: Aspire 13.2 спроектирован не только для людей, но и для ИИ-агентов.

Проблема реальна

ИИ-агенты невероятны в написании кода. Но доставка работающего full-stack приложения включает куда больше, чем генерация файлов. Нужно запустить сервисы в правильном порядке, управлять портами, установить переменные окружения, подключить базы данных и получить обратную связь, когда что-то ломается. Сейчас большинство агентов справляется со всем этим методом проб и ошибок — выполняя команды, читая вывод ошибок, пробуя снова.

Мы нагружаем их Markdown-инструкциями, кастомными навыками и промптами, чтобы направить, но они непредсказуемы, не компилируются и стоят токенов даже для парсинга. Команда Aspire попала в точку с ключевым инсайтом: агентам нужны компиляторы и структурированные API, а не больше Markdown.

Aspire как инфраструктура для агентов

Вот что Aspire 13.2 приносит для агентной разработки:

Весь ваш стек в типизированном коде. AppHost определяет полную топологию — API, фронтенд, базу данных, кэш — в компилируемом TypeScript или C#:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Агент может прочитать это, чтобы понять топологию приложения, добавить ресурсы, настроить связи и скомпилировать для проверки. Компилятор сразу скажет, если что-то не так. Никаких догадок, никаких проб и ошибок с конфигами.

Одна команда, чтобы править ими всеми. Вместо того чтобы агенты жонглировали docker compose up, npm run dev и скриптами запуска баз данных, всё сводится к aspire start. Все ресурсы запускаются в правильном порядке, на правильных портах, с правильной конфигурацией. Долгоживущие процессы тоже не вешают агента — Aspire управляет ими.

Изолированный режим для параллельных агентов. С --isolated каждый запуск Aspire получает собственные случайные порты и отдельные пользовательские секреты. Несколько агентов работают в git worktrees? Они не столкнутся. Это огромное преимущество для инструментов вроде фоновых агентов VS Code, которые создают параллельные среды.

Глаза агента через телеметрию. Вот где становится действительно мощно. Aspire CLI предоставляет полные данные OpenTelemetry во время разработки — трейсы, метрики, структурированные логи. Ваш агент не просто читает вывод консоли и надеется на лучшее. Он может отследить неудавшийся запрос через сервисы, профилировать медленные эндпоинты и точно определить, где что ломается. Это наблюдаемость продакшен-уровня в цикле разработки.

Аналогия с бамперами на боулинге

Команда Aspire использует отличную аналогию: думайте об Aspire как о бамперах на дорожке боулинга для ИИ-агентов. Если агент несовершенен (а он таким и будет), бамперы не дают ему закатывать шар в жёлоб. Определение стека предотвращает неправильную конфигурацию, компилятор ловит ошибки, CLI управляет процессами, а телеметрия обеспечивает обратную связь.

Комбинируйте это с чем-то вроде Playwright CLI, и ваш агент может реально использовать ваше приложение — кликать по флоу, проверять DOM, видеть поломки в телеметрии, исправлять код, перезапускать и тестировать снова. Построить, запустить, наблюдать, исправить. Это тот автономный цикл разработки, к которому мы стремились.

Начало работы

Новичок в Aspire? Установите CLI с get.aspire.dev и следуйте руководству по началу работы.

Уже используете Aspire? Выполните aspire update --self для получения 13.2, затем наведите ваш любимый кодирующий агент на репозиторий. Вы можете удивиться, насколько дальше он продвинется с ограничителями Aspire.

Подведём итоги

Aspire 13.2 — это уже не просто фреймворк для распределённых приложений — он становится необходимой инфраструктурой для агентов. Структурированные определения стека, запуск одной командой, изолированные параллельные запуски и телеметрия в реальном времени дают ИИ-агентам именно то, что нужно для перехода от написания кода к поставке приложений.

Читайте полный пост от команды Aspire со всеми деталями и демо-видео.

Изолированный режим Aspire устраняет кошмар конфликтов портов при параллельной разработке

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Если вы когда-нибудь пытались запустить два экземпляра одного проекта одновременно, вы знаете эту боль. Порт 8080 уже используется. Порт 17370 занят. Убить что-то, перезапустить, жонглировать переменными окружения — настоящий убийца продуктивности.

Эта проблема не улучшается, а ухудшается. ИИ-агенты создают git worktrees для независимой работы. Фоновые агенты поднимают отдельные среды. Разработчики дважды клонируют один репозиторий для feature-веток. Каждый из этих сценариев упирается в одну и ту же стену: два экземпляра одного приложения борются за одни и те же порты.

Aspire 13.2 решает это одним флагом. James Newton-King из команды Aspire описал все детали, и это одна из тех фич «почему у нас этого не было раньше».

Решение: `--isolated`

aspire run --isolated

Вот и всё. Каждый запуск получает:

Случайные порты — больше никаких коллизий между экземплярами
Изолированные пользовательские секреты — строки подключения и API-ключи остаются раздельными для каждого экземпляра

Никакого ручного переназначения портов. Никакого жонглирования переменными окружения. Каждый запуск автоматически получает чистую среду без коллизий.

Реальные сценарии, где это сияет

Множественные checkout. У вас feature-ветка в одной директории и bugfix в другой:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Оба работают без конфликтов. Дашборд показывает, что где запущено.

Фоновые агенты в VS Code. Когда фоновый агент Copilot Chat создаёт git worktree для независимой работы с вашим кодом, ему может понадобиться запустить ваш Aspire AppHost. Без --isolated это конфликт портов с основным worktree. С ним оба экземпляра просто работают.

Навык Aspire, поставляемый с aspire agent init, автоматически инструктирует агентов использовать --isolated при работе в worktrees. Так что фоновый агент Copilot должен справляться с этим из коробки.

Интеграционные тесты параллельно с разработкой. Нужно запускать тесты против работающего AppHost, продолжая разрабатывать фичи? Изолированный режим даёт каждому контексту собственные порты и конфигурацию.

Как это работает под капотом

Когда вы передаёте --isolated, CLI генерирует уникальный ID экземпляра для запуска. Это управляет двумя поведениями:

Рандомизация портов — вместо привязки к предсказуемым портам, определённым в конфигурации AppHost, изолированный режим выбирает случайные доступные порты для всего — дашборда, эндпоинтов сервисов, всего. Service discovery автоматически подстраивается, чтобы сервисы находили друг друга независимо от назначенных портов.
Изоляция секретов — каждый изолированный запуск получает собственное хранилище пользовательских секретов, привязанное к ID экземпляра. Строки подключения и API-ключи одного запуска не утекают в другой.

Ваш код не нуждается в изменениях. Service discovery Aspire разрешает эндпоинты во время выполнения, так что всё подключается правильно независимо от назначения портов.

Когда использовать

Используйте --isolated при запуске нескольких экземпляров одного AppHost одновременно — будь то параллельная разработка, автоматизированные тесты, ИИ-агенты или git worktrees. Для разработки с единственным экземпляром, где вы предпочитаете предсказуемые порты, обычный aspire run по-прежнему отлично работает.

Подведём итоги

Изолированный режим — это маленькая фича, которая решает реальную и всё более распространённую проблему. По мере того как разработка с ИИ подталкивает нас к большему количеству параллельных рабочих процессов — множество агентов, множество worktrees, множество контекстов — возможность просто поднять ещё один экземпляр без борьбы за порты становится необходимой.

Прочитайте полный пост для всех технических деталей и попробуйте с aspire update --self для получения 13.2.

Aspire 13.2 получает CLI для документации — и ваш ИИ-агент тоже может им пользоваться

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинальную версию можно найти здесь.

Знаете тот момент, когда вы погружены в Aspire AppHost, подключаете интеграции, и вам нужно проверить, какие именно параметры ожидает интеграция Redis? Вы переключаетесь Alt-Tab на браузер, ищете на aspire.dev, вглядываетесь в документацию API, возвращаетесь в редактор. Контекст потерян. Поток прерван.

Aspire 13.2 только что выпустил решение этой проблемы. CLI aspire docs позволяет искать, просматривать и читать официальную документацию Aspire прямо из терминала. А поскольку за ним стоят переиспользуемые сервисы, ИИ-агенты и навыки могут использовать те же самые команды для поиска документации вместо того, чтобы галлюцинировать несуществующие API.

Проблема, которую это действительно решает

David Pine точно подмечает в оригинальном посте: ИИ-агенты были ужасны в помощи разработчикам при создании приложений на Aspire. Они рекомендовали dotnet run вместо aspire run, ссылались на learn.microsoft.com для документации, которая живёт на aspire.dev, предлагали устаревшие NuGet-пакеты, и — моё любимое — галлюцинировали API, которых не существует.

Почему? Потому что Aspire был специфичен для .NET гораздо дольше, чем является полиглотом, а LLM работают на тренировочных данных, которые предшествуют последним возможностям. Когда вы даёте ИИ-агенту возможность реально искать актуальную документацию, он перестаёт угадывать и начинает быть полезным.

Три команды, ноль вкладок браузера

CLI освежающе прост:

Показать всю документацию

aspire docs list

Возвращает каждую страницу документации, доступную на aspire.dev. Нужен машиночитаемый вывод? Добавьте --format Json.

Поиск по теме

aspire docs search "redis"

Ищет и по заголовкам, и по содержимому с взвешенной оценкой релевантности. Тот же поисковый движок, который используется внутренне в инструментах документации. Вы получаете ранжированные результаты с заголовками, слагами и оценками релевантности.

Чтение полной страницы (или только одного раздела)

aspire docs get redis-integration

Выводит полную страницу в формате markdown в ваш терминал. Нужен только один раздел?

aspire docs get redis-integration --section "Add Redis resource"

Хирургическая точность. Никакого прокручивания 500 строк. Только нужная часть.

Аспект ИИ-агентов

Вот где становится интересно для нас, разработчиков, работающих с ИИ-инструментами. Те же команды aspire docs работают как инструменты для ИИ-агентов — через навыки, MCP-серверы или простые CLI-обёртки.

Вместо того чтобы ваш ИИ-ассистент придумывал API Aspire на основе устаревших тренировочных данных, он может вызвать aspire docs search "postgres", найти официальную документацию по интеграции, прочитать нужную страницу и дать вам документированный подход. Актуальная документация в реальном времени — а не то, что модель запомнила шесть месяцев назад.

Архитектура за этим — намеренная. Команда Aspire создала переиспользуемые сервисы (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) вместо одноразовой интеграции. Это значит, что один и тот же поисковый движок работает для людей в терминале, ИИ-агентов в редакторе и автоматизации в CI-пайплайне.

Реальные сценарии

Быстрые справки в терминале: Вы на три файла в глубину и вам нужны параметры конфигурации Redis. Две команды, девяносто секунд, обратно к работе:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Разработка с помощью ИИ: Ваш навык VS Code оборачивает команды CLI. Вы спрашиваете «Добавь базу данных PostgreSQL в мой AppHost», и агент сначала смотрит реальную документацию, а потом отвечает. Никаких галлюцинаций.

Валидация CI/CD: Ваш пайплайн программно проверяет конфигурации AppHost по официальной документации. Вывод --format Json чисто передаётся в jq и другие инструменты.

Пользовательские базы знаний: Создаёте свои ИИ-инструменты? Направляйте структурированный JSON-вывод напрямую в свою базу знаний:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

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

Документация всегда актуальна

Это то, что я ценю больше всего. CLI не скачивает снимок — он обращается к aspire.dev с кэшированием на основе ETag. В момент обновления документации ваш CLI и любой навык, построенный на его основе, отражает это. Никаких устаревших копий, никаких моментов «но в вики было написано…».

Подводя итог

aspire docs — это одна из тех маленьких функций, которая решает реальную проблему чисто и элегантно. Люди получают доступ к документации прямо в терминале. ИИ-агенты получают способ перестать угадывать и начать ссылаться на реальные документы. И всё это подкреплено одним и тем же источником истины.

Если вы разрабатываете на .NET Aspire и ещё не попробовали CLI, запустите aspire docs search "ваша-тема" и почувствуйте, как это работает. Затем подумайте о том, чтобы обернуть эти команды в свои ИИ-навыки или настройки автоматизации — ваши агенты скажут вам спасибо.

Ознакомьтесь с глубоким разбором David Pine о том, как создавались инструменты документации, и с официальной справкой CLI для всех деталей.

Дашборд Aspire 13.2 теперь с API телеметрии — и это меняет всё

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинальную версию можно найти здесь.

Если вы создавали распределённые приложения на .NET Aspire, вы уже знаете, что дашборд — лучшая часть всего опыта. Все ваши трейсы, логи и метрики в одном месте — без внешнего Jaeger, без настройки Seq, без моментов «дай проверю другой терминал».

Aspire 13.2 значительно всё улучшил. James Newton-King объявил об обновлении, и честно? Функции экспорта телеметрии и API сами по себе стоят обновления.

Экспорт телеметрии по-человечески

Вот сценарий, который мы все пережили: вы отлаживаете распределённую проблему, наконец воспроизводите её после двадцати минут настройки, и теперь нужно показать команде, что произошло. Раньше? Скриншоты. Копирование ID трейсов. Обычный хаос.

Aspire 13.2 добавляет диалог Управление логами и телеметрией, где можно:

Очистить всю телеметрию (полезно перед попыткой воспроизведения)
Экспортировать выбранную телеметрию в ZIP-файл в стандартном формате OTLP/JSON
Повторно импортировать этот ZIP в любой дашборд Aspire позже

Последний пункт — это убийственная фича. Вы воспроизводите баг, экспортируете телеметрию, прикрепляете к рабочему элементу, и ваш коллега может импортировать её в свой дашборд, чтобы увидеть именно то, что видели вы. Больше никаких «можешь воспроизвести у себя?»

Отдельные трейсы, спаны и логи также получили опцию «Export JSON» в контекстных меню. Нужно поделиться конкретным трейсом? Правый клик, копируете JSON, вставляете в описание PR. Готово.

API телеметрии — настоящий прорыв

Вот чему я больше всего рад. Дашборд теперь предоставляет HTTP API по пути /api/telemetry для программного запроса данных телеметрии. Доступные эндпоинты:

GET /api/telemetry/resources — список ресурсов с телеметрией
GET /api/telemetry/spans — запрос спанов с фильтрами
GET /api/telemetry/logs — запрос логов с фильтрами
GET /api/telemetry/traces — список трейсов
GET /api/telemetry/traces/{traceId} — все спаны конкретного трейса

Всё возвращается в формате OTLP JSON. Это питает новые CLI-команды aspire agent mcp и aspire otel, но реальное значение больше: теперь можно создавать инструменты, скрипты и интеграции с ИИ-агентами, которые напрямую запрашивают телеметрию вашего приложения.

Представьте ИИ-агента для кодинга, который может видеть ваши реальные распределённые трейсы во время отладки. Это уже не гипотетически — именно это делает возможным этот API.

Телеметрия GenAI становится практичной

Если вы создаёте приложения с ИИ на Semantic Kernel или Microsoft.Extensions.AI, вам понравится улучшенный визуализатор телеметрии GenAI. Aspire 13.2 добавляет:

Описания ИИ-инструментов отображаются как Markdown
Специальная кнопка GenAI на странице трейсов для быстрого доступа
Улучшенная обработка ошибок для обрезанного или нестандартного JSON GenAI
Навигация с подсветкой по клику между определениями инструментов

Пост упоминает, что VS Code Copilot chat, Copilot CLI и OpenCode поддерживают настройку OTEL_EXPORTER_OTLP_ENDPOINT. Направьте их на дашборд Aspire, и вы буквально сможете наблюдать, как ваши ИИ-агенты думают в реальном времени через телеметрию. Такой опыт отладки вы больше нигде не найдёте.

Подведём итоги

Aspire 13.2 превращает дашборд из «приятного UI для отладки» в «программируемую платформу наблюдаемости». Рабочий процесс экспорта/импорта сам по себе экономит реальное время при распределённой отладке, а API телеметрии открывает дверь к диагностике с помощью ИИ.

Если вы уже на Aspire — обновляйтесь. Если нет — это хороший повод попробовать aspire.dev.

Aspire | The .NET Blog

Частные Endpoints, VNets, NSG — Aspire Теперь Управляет Сетью

Строительные блоки

Описание в AppHost

Почему Это Важно для Реальных Приложений

Итог

Aspire 13.3: Поддержка Kubernetes, журналы браузера и навык Aspireify

Aspireify: Онбординг с помощью агента

Первоклассное развёртывание Kubernetes и AKS

Журналы браузера в дашборде

Структурированные результаты команд

Итог

Aspire 13.2: Поддержка Bun, Улучшенные Контейнеры и Меньше Трений при Отладке

Bun теперь первоклассный

Yarn стал надёжнее

Улучшения контейнеров

Улучшения отладки

Global Azure Spain 2026

Основные моменты программы

Билеты

Azure Tour 2026

Хватит нянчить терминал: отсоединённый режим Aspire меняет рабочий процесс

Отсоединённый режим: одна команда — терминал свободен

Управление запущенными процессами

Сочетание с изолированным режимом

Почему это важно для агентов кода

Подводя итог

.NET Aspire 13.2 хочет стать лучшим другом вашего ИИ-агента

Проблема реальна

Aspire как инфраструктура для агентов

Аналогия с бамперами на боулинге

Начало работы

Подведём итоги

Изолированный режим Aspire устраняет кошмар конфликтов портов при параллельной разработке

Решение: --isolated

Реальные сценарии, где это сияет

Как это работает под капотом

Когда использовать

Подведём итоги

Aspire 13.2 получает CLI для документации — и ваш ИИ-агент тоже может им пользоваться

Проблема, которую это действительно решает

Три команды, ноль вкладок браузера

Показать всю документацию

Поиск по теме

Чтение полной страницы (или только одного раздела)

Аспект ИИ-агентов

Реальные сценарии

Документация всегда актуальна

Подводя итог

Дашборд Aspire 13.2 теперь с API телеметрии — и это меняет всё

Экспорт телеметрии по-человечески

API телеметрии — настоящий прорыв

Телеметрия GenAI становится практичной

Подведём итоги

Решение: `--isolated`