Cloud-Native | The .NET Blog

Хуки azd на Python, TypeScript и .NET: прощай, shell-скрипты

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

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

Если вы когда-нибудь вели проект полностью на .NET и всё равно писали Bash-скрипты для хуков azd — вы знаете эту боль. Зачем переходить к синтаксису shell в шаге pre-provisioning, когда весь остальной проект написан на C#?

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

Что такое хуки

Хуки — это скрипты, выполняемые в ключевых точках жизненного цикла azd — до провизионинга, после деплоя и не только. Они определяются в azure.yaml и позволяют внедрять пользовательскую логику без изменений в CLI.

Раньше поддерживались только Bash и PowerShell. Теперь можно использовать Python, JavaScript, TypeScript или .NET — остальное azd обрабатывает автоматически.

Как работает определение языка

Просто укажите хук на файл, и azd определит язык по расширению:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Дополнительная конфигурация не нужна. При неоднозначном расширении можно явно указать kind: python (или нужный язык).

Важные детали по языкам

Python

Разместите requirements.txt или pyproject.toml рядом со скриптом (или в родительской директории). azd автоматически создаёт виртуальное окружение, устанавливает зависимости и запускает скрипт.

JavaScript и TypeScript

Тот же принцип — package.json рядом со скриптом, и azd сначала выполнит npm install. Для TypeScript используется npx tsx без этапа компиляции и без tsconfig.json.

.NET

Два режима:

Режим проекта: если рядом со скриптом есть .csproj, azd автоматически выполнит dotnet restore и dotnet build.
Single-file режим: на .NET 10+ автономные .cs-файлы запускаются напрямую через dotnet run script.cs. Файл проекта не нужен.

Конфигурация по исполнителю

Каждый язык поддерживает опциональный блок config:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Почему это важно для .NET-разработчиков

Хуки были последним местом в проекте на базе azd, где приходилось менять язык. Теперь весь деплой-пайплайн — от кода приложения до lifecycle-хуков — может жить в одном языке. Можно переиспользовать существующие .NET-утилиты, ссылаться на общие библиотеки и забыть про поддержку shell-скриптов.

Итог

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

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 13.2 получает MongoDB EF Core и Azure Data Lake — Две интеграции, которые стоит попробовать

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Aspire 13.2 вышел с двумя новыми интеграциями баз данных, которые заслуживают внимания: MongoDB Entity Framework Core и Azure Data Lake Storage. Если вы хотели использовать EF Core с MongoDB в приложении Aspire или вам нужно было подключить рабочие нагрузки Data Lake с обнаружением сервисов, этот релиз предоставляет и то, и другое.

MongoDB встречает EF Core в Aspire

Это интеграция, которая радует меня больше всего. Aspire поддерживал MongoDB уже давно, но это всегда был сырой драйвер — никакого EF Core, никакого DbContext, никаких LINQ-запросов к документам. Теперь вы получаете полноценный EF Core с MongoDB, плюс автоматические проверки работоспособности и обнаружение сервисов от Aspire.

Настройка следует типичному паттерну Aspire. В вашем AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Затем в потребляющем проекте добавьте интеграцию EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

И зарегистрируйте свой DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Дальше — стандартный EF Core. Определяйте сущности, используйте DbContext как с любым другим провайдером. Интеграция берёт на себя пул соединений, трассировки OpenTelemetry и проверки работоспособности за кулисами.

Для .NET-разработчиков, которые использовали MongoDB с сырым драйвером и вручную настраивали строки подключения, это приятное улучшение качества жизни. Вы получаете полную абстракцию EF Core, не теряя обнаружение сервисов Aspire.

Azure Data Lake Storage присоединяется

Второе крупное дополнение — интеграция Azure Data Lake Storage (ADLS). Если вы строите конвейеры данных, ETL-процессы или аналитические платформы, теперь можно подключать ресурсы Data Lake так же, как любую другую зависимость Aspire.

В AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

В потребляющем проекте:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Никакого ручного управления строками подключения, никакой охоты за учётными данными. Aspire выделяет ресурсы и внедряет их. Для тех из нас, кто строит облачно-нативные .NET-приложения, работающие как с операционными данными, так и с аналитическими нагрузками, Data Lake теперь ощущается как полноценный участник модели Aspire.

Маленькие исправления, которые важны

Помимо основных функций, есть несколько улучшений, которые стоит отметить:

Исправление строки подключения MongoDB — косая черта перед именем базы данных теперь обрабатывается корректно. Если у вас был обходной путь, можете его убрать
Экспорт SQL Server — Aspire.Hosting.SqlServer теперь экспортирует дополнительные параметры конфигурации сервера для более тонкого контроля
Обновления эмуляторов — эмулятор ServiceBus 2.0.0, эмулятор App Configuration 1.0.2, предварительный эмулятор CosmosDB теперь включает проверку готовности
Azure Managed Redis — теперь по умолчанию использует rediss:// (Redis Secure), так что соединения шифруются из коробки

Последний пункт тонкий, но важный — шифрованный Redis по умолчанию означает на одну настройку меньше в продакшене.

Подводя итоги

Aspire 13.2 — инкрементальный релиз, но интеграции MongoDB EF Core и Data Lake заполняют реальные пробелы. Если вы ждали нормальную поддержку EF Core для MongoDB в Aspire или вам нужен Data Lake как полноценная зависимость, обновитесь до 13.2 и попробуйте. Команда aspire add создаст всё необходимое.

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

Azure Smart Tier вышел в GA — Автоматическая оптимизация стоимости Blob Storage без правил жизненного цикла

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Если вы когда-нибудь тратили время на настройку политик жизненного цикла Azure Blob Storage, а потом наблюдали, как они разваливаются при изменении паттернов доступа, эта статья для вас. Microsoft только что объявил о общей доступности smart tier для Azure Blob и Data Lake Storage — полностью управляемой возможности тиеринга, которая автоматически перемещает объекты между уровнями hot, cool и cold на основе реального использования.

Что на самом деле делает smart tier

Концепция проста: smart tier непрерывно оценивает время последнего доступа к каждому объекту в вашем аккаунте хранения. Часто используемые данные остаются в hot, неактивные данные перемещаются в cool через 30 дней, а затем в cold ещё через 60 дней. Когда к данным снова обращаются, они немедленно возвращаются в hot. Цикл начинается заново.

Никаких правил жизненного цикла для настройки. Никаких прогнозов паттернов доступа. Никакой ручной настройки.

Во время превью Microsoft сообщил, что более 50% ёмкости, управляемой smart tier, автоматически переместилось на более холодные уровни на основе реальных паттернов доступа. Это существенная экономия для крупных аккаунтов хранения.

Почему это важно для .NET-разработчиков

Если вы создаёте приложения, генерирующие логи, телеметрию, аналитические данные или любой растущий массив данных — а давайте будем честны, кто этого не делает? — затраты на хранение быстро накапливаются. Традиционный подход заключался в написании политик управления жизненным циклом, их тестировании, а затем перенастройке при изменении паттернов доступа вашего приложения. Smart tier полностью устраняет этот рабочий процесс.

Несколько практических сценариев, где это помогает:

Телеметрия и логи приложений — hot при отладке, почти не используются через несколько недель
Конвейеры данных и выходные данные ETL — интенсивно используются во время обработки, затем в основном cold
Контент, создаваемый пользователями — недавние загрузки hot, старый контент постепенно остывает
Данные резервного копирования и архивирования — иногда используются для соответствия требованиям, в основном простаивают

Настройка

Включение smart tier — это однократная настройка:

Новые аккаунты: Выберите smart tier как уровень доступа по умолчанию при создании аккаунта хранения (требуется зональная избыточность)
Существующие аккаунты: Переключите уровень доступа blob с текущего значения по умолчанию на smart tier

Объекты размером менее 128 КиБ остаются в hot и не облагаются платой за мониторинг. Для всего остального вы платите стандартные тарифы hot/cool/cold без платы за переход между уровнями, без штрафов за раннее удаление и без стоимости извлечения данных. Ежемесячная плата за мониторинг на объект покрывает оркестрацию.

Компромисс, о котором стоит знать

Правила тиеринга smart tier фиксированы (30 дней → cool, 90 дней → cold). Если вам нужны пользовательские пороги — например, перемещение в cool через 7 дней для конкретной рабочей нагрузки — правила жизненного цикла по-прежнему подходят лучше. И не смешивайте оба подхода: избегайте использования правил жизненного цикла для объектов, управляемых smart tier, так как они могут конфликтовать.

Заключение

Это не революция, но решает реальную операционную головную боль. Если вы управляете растущими аккаунтами blob storage и устали поддерживать политики жизненного цикла, включите smart tier и позвольте Azure заниматься этим. Доступно уже сегодня практически во всех зональных регионах публичного облака.

Где размещать AI-агентов в Azure? Практическое руководство по выбору

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Если вы сейчас создаёте AI-агентов с .NET, вы наверняка заметили: способов разместить их в Azure очень много. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — и все звучат разумно, пока вам не нужно действительно выбрать один. Microsoft только что опубликовала полное руководство по размещению AI-агентов в Azure, и я хочу разобрать его с практической точки зрения .NET-разработчика.

Шесть вариантов с первого взгляда

Вариант	Лучше всего для	Вы управляете
Container Apps	Полный контроль контейнеров без сложности K8s	Наблюдаемость, состояние, жизненный цикл
AKS	Корпоративный комплаенс, мультикластер, пользовательские сети	Всем (в этом и суть)
Azure Functions	Событийные краткосрочные задачи агентов	Почти ничем — настоящий serverless
App Service	Простые HTTP-агенты, предсказуемый трафик	Развёртывание, настройка масштабирования
Foundry Agents	Агенты без кода через портал/SDK	Почти ничем
Foundry Hosted Agents	Агенты с пользовательским фреймворком на управляемой инфраструктуре	Только ваш код агента

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

Foundry Hosted Agents — оптимальный выбор для .NET-разработчиков агентов

Вот что привлекло моё внимание. Foundry Hosted Agents находятся точно посередине: вы получаете гибкость запуска собственного кода (Semantic Kernel, Agent Framework, LangGraph — что угодно), а платформа управляет инфраструктурой, наблюдаемостью и управлением разговорами.

Ключевой элемент — Hosting Adapter — тонкий слой абстракции, который соединяет ваш фреймворк агентов с платформой Foundry. Для Microsoft Agent Framework это выглядит так:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Это вся ваша история хостинга. Адаптер обрабатывает трансляцию протоколов, стриминг через server-sent events, историю разговоров и трассировку OpenTelemetry — всё автоматически. Никакого пользовательского middleware, никакой ручной прокладки.

Развёртывание действительно простое

Я раньше развёртывал агентов в Container Apps, и это работает, но в итоге вы пишете много связующего кода для управления состоянием и наблюдаемости. С Hosted Agents и azd развёртывание — это:

# Установить расширение AI-агента
azd ext install azure.ai.agents

# Инициализировать из шаблона
azd ai agent init

# Собрать, отправить, развернуть — готово
azd up

Эта единственная команда azd up собирает ваш контейнер, отправляет его в ACR, создаёт проект Foundry, развёртывает endpoints моделей и запускает вашего агента. Пять шагов сжаты в одну команду.

Встроенное управление разговорами

Это та часть, которая экономит больше всего времени в продакшене. Вместо создания собственного хранилища состояния разговоров, Hosted Agents обрабатывают это нативно:

# Создать постоянный разговор
conversation = openai_client.conversations.create()

# Первый ход
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Второй ход — контекст сохранён
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Никакого Redis. Никакого хранилища сессий Cosmos DB. Никакого middleware для сериализации сообщений. Платформа просто справляется.

Мой фреймворк принятия решений

Пройдя все шесть вариантов, вот моя быстрая ментальная модель:

Нужен нулевой уровень инфраструктуры? → Foundry Agents (портал/SDK, без контейнеров)
Есть пользовательский код агента, но нужен управляемый хостинг? → Foundry Hosted Agents
Нужны событийные краткосрочные задачи агентов? → Azure Functions
Нужен максимальный контроль контейнеров без K8s? → Container Apps
Нужен строгий комплаенс и мультикластер? → AKS
Простой HTTP-агент с предсказуемым трафиком? → App Service

Для большинства .NET-разработчиков, работающих с Semantic Kernel или Microsoft Agent Framework, Hosted Agents — вероятно правильная отправная точка. Вы получаете scale-to-zero, встроенный OpenTelemetry, управление разговорами и гибкость фреймворка — без управления Kubernetes или создания собственного стека наблюдаемости.

Подводя итог

Ландшафт хостинга агентов в Azure быстро зреет. Если вы начинаете новый проект AI-агента сегодня, я бы серьёзно рассмотрел Foundry Hosted Agents, прежде чем по привычке тянуться к Container Apps или AKS. Управляемая инфраструктура экономит реальное время, а паттерн hosting adapter позволяет сохранить ваш выбор фреймворка.

Ознакомьтесь с полным руководством Microsoft и репозиторием Foundry Samples для рабочих примеров.

KubeCon Europe 2026: Что на самом деле важно для .NET-разработчиков

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

Знаете это чувство, когда выходит огромный пост с анонсами и вы листаете его, думая «круто, но что это на самом деле меняет для меня»? Это я каждый сезон KubeCon.

Microsoft только что опубликовала свой полный обзор KubeCon Europe 2026 — написанный лично Бренданом Бёрнсом — и честно? Здесь настоящая суть. Не просто чеклисты фич, а операционные улучшения, которые меняют подход к управлению в продакшене.

Давайте разберём, что действительно важно для нас, .NET-разработчиков.

mTLS без налога service mesh

Вот в чём дело с service mesh: все хотят гарантий безопасности, никто не хочет операционной нагрузки. AKS наконец закрывает этот разрыв.

Azure Kubernetes Application Network даёт вам mutual TLS, авторизацию с учётом приложения и телеметрию трафика — без развёртывания полного mesh с тяжёлыми sidecar. В сочетании с Cilium mTLS в Advanced Container Networking Services вы получаете зашифрованную связь между подами с использованием сертификатов X.509 и SPIRE для управления идентификацией.

Что это значит на практике: ваши ASP.NET Core API общаются с фоновыми воркерами, ваши gRPC-сервисы вызывают друг друга — всё зашифровано и верифицировано на сетевом уровне, без единого изменения в коде приложения. Это серьёзно.

Для команд, мигрирующих с ingress-nginx, есть также Application Routing с Meshless Istio с полной поддержкой Kubernetes Gateway API. Без sidecar. На основе стандартов. Плюс инструменты ingress2gateway для постепенной миграции.

Наблюдаемость GPU — не как запоздалая мысль

Если вы запускаете AI-инференс рядом с .NET-сервисами (а давайте честно, кто сейчас не начинает?), вы наверняка столкнулись со слепым пятном мониторинга GPU. У вас были отличные дашборды CPU/памяти, а потом… ничего для GPU без ручной настройки экспортёров.

AKS теперь показывает метрики GPU нативно в управляемых Prometheus и Grafana. Тот же стек, те же дашборды, тот же пайплайн алертов. Без кастомных экспортёров, без сторонних агентов.

На сетевой стороне добавлена видимость по потокам для HTTP, gRPC и Kafka-трафика с Azure Monitor в один клик. IP, порты, ворклоуды, направление потока, решения по политикам — всё во встроенных дашбордах.

А вот то, от чего я посмотрел дважды: agentic container networking добавляет веб-интерфейс, где можно задавать вопросы на естественном языке о состоянии сети кластера. «Почему под X не достигает сервис Y?» → диагностика только для чтения из live-телеметрии. Реально полезно в 2 часа ночи.

Кросс-кластерная сеть без учёной степени

Мульти-кластерный Kubernetes исторически был опытом «принеси свой сетевой клей». Azure Kubernetes Fleet Manager теперь обеспечивает кросс-кластерную сеть через управляемый Cilium cluster mesh:

Единая связность между кластерами AKS
Глобальный реестр сервисов для кросс-кластерного обнаружения
Конфигурация управляется централизованно, а не повторяется для каждого кластера

Если вы запускаете .NET-микросервисы в нескольких регионах для отказоустойчивости или соответствия требованиям, это заменяет много хрупкого кастомного клея. Сервис A в West Europe может обнаружить и вызвать Сервис B в East US через mesh, с согласованными политиками маршрутизации и безопасности.

Обновления, не требующие смелости

Давайте честно — обновления Kubernetes в продакшене — это стресс. «Обновить и надеяться» было стратегией по умолчанию для слишком многих команд и главной причиной, по которой кластеры отстают по версиям.

Две новые возможности меняют это:

Blue-green обновления пулов агентов создают параллельный пул нод с новой конфигурацией. Валидируйте поведение, постепенно переключайте трафик и сохраняйте чистый путь отката. Больше никаких мутаций на месте на продакшн-нодах.

Откат пула агентов позволяет вернуть пул нод на предыдущую версию Kubernetes и образ ноды после неудачного обновления — без пересборки кластера.

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

AI-рабочие нагрузки становятся полноценными гражданами Kubernetes

Upstream-работа в open source не менее важна. Dynamic Resource Allocation (DRA) только что стала GA в Kubernetes 1.36, сделав планирование GPU настоящей первоклассной функцией вместо обходного пути.

Проекты, за которыми стоит следить:

Проект	Что делает
AI Runway	Общий Kubernetes API для инференса — деплой моделей без знания K8s, с обнаружением HuggingFace и оценкой стоимости
HolmesGPT	Агентный troubleshooting для cloud-native — теперь проект CNCF Sandbox
Dalec	Декларативная сборка образов контейнеров с генерацией SBOM — меньше CVE на этапе сборки

Направление ясно: ваш .NET API, слой оркестрации на Semantic Kernel и ваши рабочие нагрузки инференса должны работать на одной согласованной платформенной модели. Мы приближаемся.

С чего бы я начал на этой неделе

Если вы оцениваете эти изменения для своей команды, вот мой честный список приоритетов:

Наблюдаемость в первую очередь — включите метрики GPU и логи сетевых потоков в непродакшен-кластере. Посмотрите, что вы упускали.
Попробуйте blue-green обновления — протестируйте workflow отката перед следующим обновлением продакшен-кластера. Постройте доверие к процессу.
Пилотируйте сеть с учётом идентичности — выберите один внутренний путь сервиса и включите mTLS с Cilium. Измерьте оверхед (спойлер: минимальный).
Оцените Fleet Manager — если у вас больше двух кластеров, кросс-кластерная сеть окупается за счёт сокращения кастомного клея.

Маленькие эксперименты, быстрая обратная связь. Это всегда правильный ход.

Подводя итог

Анонсы KubeCon могут быть ошеломляющими, но эта порция реально двигает стрелку для .NET-команд на AKS. Лучшая сетевая безопасность без оверхеда mesh, настоящая наблюдаемость GPU, более безопасные обновления и более прочные основы AI-инфраструктуры.

Если вы уже на AKS, сейчас отличный момент укрепить ваш операционный baseline. А если планируете перенести .NET-рабочие нагрузки на Kubernetes — платформа только что стала значительно более готовой к продакшену.