Cloud | The .NET Blog

Обновления Azure Developer CLI (azd) за апрель 2026

Emiliano Montesdeoca — Fri, 08 May 2026 00:00:00 +0000

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

Azure Developer CLI (azd) выпустил пять релизов в апреле 2026 года (с 1.23.14 по 1.24.2). Главная тема — хуки, которые теперь работают на Python, JavaScript, TypeScript и .NET, а не только на Bash и PowerShell.

Многоязычные хуки в azure.yaml

Хуки теперь могут указывать на файлы .py, .js, .ts или .cs в дополнение к shell-скриптам. Для каждого языка выполняется автоматическое разрешение зависимостей:

Python — обнаруживает requirements.txt или pyproject.toml, создаёт virtualenv и устанавливает зависимости перед запуском. Имя окружения настраивается через virtualEnvName.
JavaScript / TypeScript — обнаруживает package.json и автоматически запускает npm install. TypeScript выполняется через npx tsx без шага компиляции. Менеджер пакетов выбирается в блоке конфигурации packageManager.
.NET — запускает файлы .cs с помощью dotnet run. Однофайловые скрипты поддерживаются на .NET 10+. Целевой фреймворк настраивается через блок configuration/framework.

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

azd update переходит в публичную предварительную версию

azd update теперь доступен в публичной предварительной версии на всех платформах. Одна команда обновляет azd независимо от способа его первоначальной установки — больше не нужно отслеживать пути Homebrew, WinGet или MSI по отдельности.

Неинтерактивный режим через AZD_NON_INTERACTIVE

Установка AZD_NON_INTERACTIVE=true (или использование --non-interactive / --no-prompt) теперь вызывает последовательные, детерминированные ошибки в пайплайнах CI/CD, когда необходимый ввод не может быть разрешён автоматически. Ранее поведение было непоследовательным для разных команд.

Предварительная проверка квоты моделей ИИ

azd provision проверяет квоту Azure Cognitive Services перед попыткой выделить ресурсы моделей ИИ. Развёртывания, которые завершились бы ошибкой из-за превышения лимитов квоты, теперь показывают ошибку в начале процесса, а не в середине провизионинга.

«Исправить эту ошибку» в устранении неполадок Copilot

Интеграция устранения неполадок Copilot в azd получает возможность напрямую применять предложенное исправление — не только описывать его. Когда агент выявляет исправимую проблему, он может внести изменение на месте.

Пользовательские провайдеры провизионинга и резолвер секретов Key Vault

Авторы расширений теперь могут регистрировать альтернативные инфраструктурные бэкенды с помощью WithProvisioningProvider(). Кроме того, azd автоматически разрешает ссылки @Microsoft.KeyVault(...) перед передачей конфигурации расширениям, устраняя необходимость ручного разрешения секретов в пользовательских провайдерах.

Исключения для шаблонов и режима наблюдения

Два новых файла ignore обеспечивают более точный контроль над обработкой файлов:

.azdignore — исключает файлы только для контрибьюторов (документация, конфигурации CI) из копий шаблонов, чтобы конечные пользователи получали чистый каркас проекта.
.azdxignore — исключает директории из триггера пересборок во время azd x watch, снижая шум при итеративной разработке.

Предварительная проверка зарезервированных имён и опция docker.network

azd теперь предупреждает, когда прогнозируемые имена ресурсов будут содержать зарезервированные слова Azure (MICROSOFT, WINDOWS или префикс LOGIN), до начала провизионинга. Новая опция docker.network передаёт --network в docker build, что полезно в корпоративных прокси-средах, требующих определённой сети Docker.

Исправления безопасности

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

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

Ваши AI-эксперименты в Azure сжигают деньги — Вот как это исправить

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

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

Если вы сейчас создаёте приложения на базе ИИ в Azure, вы, вероятно, заметили кое-что: ваш счёт за облако выглядит иначе, чем раньше. Не просто выше — странно. Скачкообразно. Трудно предсказать.

Microsoft только что опубликовал отличную статью о принципах оптимизации облачных затрат, которые по-прежнему актуальны, и, честно говоря, момент не мог быть лучше. Потому что AI-нагрузки изменили правила игры, когда речь идёт о затратах.

Почему AI-нагрузки — это другая история

Вот в чём дело. Традиционные .NET-нагрузки относительно предсказуемы. Вы знаете свой уровень App Service, знаете свои SQL DTU, можете довольно точно оценить ежемесячные расходы. AI-нагрузки? Не совсем.

Вы тестируете несколько моделей, чтобы понять, какая подходит. Вы поднимаете инфраструктуру с GPU для дообучения. Вы делаете API-вызовы к Azure OpenAI, где потребление токенов сильно варьируется в зависимости от длины промпта и поведения пользователей. Каждый эксперимент стоит реальных денег, и вы можете провести десятки, прежде чем найдёте правильный подход.

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

Управление vs. оптимизация — знайте разницу

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

Управление — это отслеживание и отчётность. Вы настраиваете бюджеты в Azure Cost Management, получаете оповещения, смотрите дашборды. Это базовый минимум.

Оптимизация — это когда вы действительно принимаете решения. Вам правда нужен этот уровень S3, или S1 справится с вашей нагрузкой? Та постоянно работающая вычислительная инстанция простаивает по выходным? Можно ли использовать спот-инстансы для задач обучения?

Как .NET-разработчики, мы склонны сосредотачиваться на коде и оставлять решения по инфраструктуре «команде эксплуатации». Но если вы деплоите в Azure, эти решения — тоже ваши решения.

Что действительно работает

Основываясь на статье и собственном опыте, вот что реально даёт результат:

Знайте, на что и где вы тратите. Тегируйте свои ресурсы. Серьёзно. Если вы не можете определить, какой проект или эксперимент поедает ваш бюджет, вы не сможете ничего оптимизировать. Azure Cost Management с правильным тегированием — ваш лучший друг.

Установите ограничения перед экспериментами. Используйте Azure Policy для ограничения дорогих SKU в средах dev/test. Установите лимиты расходов на ваши развёртывания Azure OpenAI. Не ждите, пока придёт счёт, чтобы обнаружить, что кто-то оставил GPU-кластер работать на выходных.

Постоянно подбирайте правильный размер. Та VM, которую вы выбрали при прототипировании? Она, вероятно, не подходит для продакшена. Azure Advisor даёт рекомендации — реально посмотрите на них. Пересматривайте ежемесячно, а не ежегодно.

Думайте о жизненном цикле. Ресурсы разработки должны выключаться. Тестовые среды не должны работать 24/7. Используйте политики автоматического выключения. Для AI-нагрузок в частности рассмотрите бессерверные варианты, где вы платите за выполнение, вместо того чтобы держать вычислительные мощности включёнными.

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

Итог

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

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