Category: Uncategorized

Microsoft представила одно из самых захватывающих нововведений в .NET — новую команду dotnet run.
Эта функция доступна в .NET и полностью меняет подход к написанию и запуску кода на C#.

Теперь больше не нужно создавать полноценный проект, чтобы просто протестировать идею или вывести «Hello World». Всё стало гораздо проще, легче и дружелюбнее для новичков.

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

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

Начнём с полностью пустой папки в Visual Studio Code — без файлов проекта, без решения, просто чистое рабочее пространство.

Обратите внимание: у вас должны быть установлены .NET 10 и C# Dev Kit для VS Code.

Создайте новый файл под названием hello.cs и вставьте в него следующий код:

Console.WriteLine("Hello from .NET 10! This is a cool feature.");

Без пространств имён, без класса, без метода Main() — один файл, одна строка, и всё работает.

Запуск файла

А вот и магия. Вместо создания проекта просто откройте терминал и введите:

dotnet run hello.cs

И программа запустится!
Результат на экране:

Hello from .NET 10! This is a cool feature.

.NET компилирует и запускает файл напрямую — без дополнительной настройки и без проекта.
Под капотом код собирается в памяти и выполняется как скрипт.

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

Добавляем функциональность: работа с датами

Теперь сделаем шаг дальше.
Допустим, мы хотим вывести дату публикации, например — 3 дня назад.

Добавим такой код:

var postedDate = DateTime.UtcNow.AddDays(-3);
Console.WriteLine($"Posted date: {postedDate}");

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

Исправим это.

Использование NuGet-пакетов без проекта

Теперь можно использовать NuGet-пакеты даже без создания проекта.

Возьмём пакет Humanizer, который форматирует даты в удобном виде — например, вместо отметки времени покажет «3 дня назад».

В начале файла добавим:

#r "nuget: Humanizer, 2.14.1"

Далее подключим пространство имён:

using Humanizer;

Теперь изменим вывод в консоль:

var postedDate = DateTime.UtcNow.AddDays(-3);
Console.WriteLine($"Posted {postedDate.Humanize()}");

Запустите снова:

dotnet run hello.cs

При первом запуске может потребоваться немного времени, чтобы загрузить пакет, но затем всё выполняется мгновенно.
Теперь результат выглядит так:

Posted 3 days ago

Просто, красиво и читаемо — именно то, что нужно.

Создание минимального API в одном файле

Теперь пойдём ещё дальше. Что, если нужно создать небольшой API, но без полноценного проекта?
Это теперь тоже возможно.

Создайте новый файл api.cs и добавьте в него:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();app.MapGet("/testapi", () => "Hello from .NET 10!");
app.Run();

Попробуйте запустить:

dotnet run api.cs

Вы получите ошибку: WebApplication не существует в текущем контексте.
Это логично — мы используем функции минимального API, но не указали, что работаем с Web SDK.

Подключаем Web SDK

Чтобы всё заработало, добавим в начало файла строку:

#sdk "Microsoft.NET.Sdk.Web"

Теперь снова запустим:

dotnet run api.cs

И всё работает! API запущен и слушает по адресу http://localhost:5000.

Откройте Postman или браузер и перейдите по маршруту /testapi.
Ответ:

Hello from .NET 10!

Минимальный API полностью работает — и всё это в одном файл

Преобразование файла в полноценный проект

Если файл становится слишком большим — вы добавляете больше эндпоинтов или middleware — можно легко преобразовать его в полноценный проект.
Достаточно выполнить команду:

dotnet project convert api.cs

.NET автоматически:

• создаёт новую папку проекта,
• переносит туда api.cs,
• генерирует файл .csproj,
• добавляет все необходимые SDK и ссылки на пакеты.

Пример созданного .csproj:

<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
</PropertyGroup>
</Project>

Теперь можно собирать, восстанавливать и запускать проект как обычно.

Конвертация Hello World в проект

То же самое можно сделать с файлом hello.cs:

dotnet project convert hello.cs

.NET создаст консольный проект и автоматически добавит зависимости, которые использовались, включая Humanizer.

Пример .csproj:

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Humanizer" Version="2.14.1" />
</ItemGroup>
</Project>

Всё готово к запуску — и ни одной ручной настройки.

Заключение

Мы прошли путь от одного C#-файла с несколькими строками кода до:

• запуска его напрямую через dotnet run,
• использования NuGet-пакетов,
• создания минимального API в одном файле,
• и конвертации всего в полноценный проект.

И всё это — без ручной настройки.
.NET 10 действительно меняет то, как мы начинаем работать с C#.
Будь вы новичком, создающим прототип, или опытным разработчиком, пишущим скрипт, новый процесс стал чище, быстрее и удобнее.
Если статья оказалась полезной — ставьте лайк и следите за новыми материалами о .NET 10, минимальных API, AI-интеграции и других обновлениях экосистемы .NET.

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

В этой статье показано, как добавить обязательный этап проверки безопасности (security-scan) в файл .gitlab-ci.yml любого .NET-проекта, используя стандартные инструменты из комплекта .NET SDK.

Добавляем этап Security Scan в .gitlab-ci.yml

Ниже приведён YAML-фрагмент, который можно напрямую включить в ваш CI/CD-конвейер:

security-scan:
stage: security-scan
image: mcr.microsoft.com/dotnet/sdk:8.0
before_script:
- dotnet tool install --global dotnet-outdated-tool
script:
# Step 1: Check for known vulnerabilities in packages. This is mandatory.
- echo "Searching for KNOWN vulnerabilities in packages..."
- dotnet list package --vulnerable --include-transitive

# Step 2: Check for outdated packages. Important for maintenance and security.
- echo "Checking for outdated (non-secure) packages..."
- dotnet-outdated
allow_failure: true
only:
- main
- develop
- merge_requests

stage: security-scan

Проверка безопасности вынесена в отдельный этап, чтобы подчеркнуть её значимость.
Такой подход гарантирует, что сканирование выполняется регулярно — обычно после сборки и тестов.

image: mcr.microsoft.com/dotnet/sdk:8.0

Использование официального Docker-образа .NET SDK от Microsoft обеспечивает доступ к актуальным CLI-инструментам, необходимым для надёжного анализа и отчётности.

before_script

Этот блок подготавливает окружение для сканирования.

Команда

dotnet tool install --global dotnet-outdated-tool

устанавливает утилиту dotnet-outdated-tool.
Хотя основная проверка уязвимостей выполняется встроенным инструментом, этот пакет помогает отслеживать устаревшие зависимости — важная часть поддержания «гигиены» проекта.
Игнорирование обновлений со временем превращается в технический долг и повышает риски безопасности.

script

Здесь выполняются команды, которые фактически защищают ваш код.

• Шаг 1: Поиск известных уязвимостей
  Команда dotnet list package --vulnerable анализирует все зависимости (включая транзитивные) и выводит список небезопасных пакетов.

• Шаг 2: Проверка устаревших пакетов
  Команда dotnet-outdated показывает зависимости, которые больше не актуальны или потенциально уязвимы.

allow_failure: true

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

only

Этот блок задаёт, для каких веток выполняется проверка — main, develop и merge requests.
Так вы можете выявить риски ещё до попадания потенциально опасного кода в основную ветку.

Заключение

Представленная конфигурация — это не «опция» и не «дополнение», а базовый стандарт безопасности для любого .NET-проекта.
Она автоматически выполняет две ключевые задачи:

1. Находит активные угрозы — пакеты с известными уязвимостями.

2. Управляет техническим долгом — устаревшими зависимостями, которые могут стать причиной проблем в будущем.

Пропуская этот этап, вы фактически оставляете дверь открытой для атак.
Добавьте эти проверки сегодня, чтобы защитить свой проект завтра.

Сегодня мы погружаемся во что-то совершенно новое и действительно захватывающее для всех .NET-разработчиков — это Microsoft Agent Framework. Этот предварительный релиз выводит интеграцию искусственного интеллекта и .NET на совершенно новый уровень.

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

Что такое агенты

Агент — это, по сути, ИИ-работник, который может думать, принимать решения и действовать, чтобы достичь цели. Представьте его как цифрового коллегу — у него есть конкретная задача, собственная «личность», и он может использовать инструменты или API при необходимости.

Согласно Microsoft, агент — это не просто система запрос–ответ. Он умеет:

• рассуждать и планировать,

• вызвать API,

• использовать память,

• взаимодействовать с другими агентами.

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

Понимание рабочих процессов

Рабочий процесс (workflow) определяет, как агенты соединяются между собой и работают совместно для выполнения задачи. Его можно представить как блок-схему — сначала перевод, потом проверка, затем итог.

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

Если коротко:

• Агенты приносят интеллект — они понимают контекст, рассуждают и создают результат.

• Рабочие процессы приносят структуру — определяют порядок, зависимости и ветвления.

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

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

Знакомство с Microsoft Agent Framework

Теперь поговорим о звезде сегодняшнего видео — Microsoft Agent Framework.

Это новый SDK с открытым исходным кодом от Microsoft, пока ещё находящийся в предварительной версии, который объединяет агентов, рабочие процессы, инструменты и память в единую платформу для разработчиков .NET и Python.

Он основан на идеях Semantic Kernel и Autogen, но был переработан, чтобы сделать создание многоагентных систем простым и масштабируемым.

С помощью этого фреймворка вы можете:

• легко создавать агентов,

• соединять их через типобезопасные рабочие процессы,

• интегрировать Azure OpenAI или локальные модели,

• выполнять шаги параллельно или с участием человека (human checkpoints).

Подготовка проекта

Теперь мы создадим последовательный рабочий процесс перевода, используя четыре агента:

1. French Translator Agent — переводит английский на французский;

2. Spanish Translator Agent — переводит английский на испанский;

3. Quality Reviewer Agent — проверяет оба перевода на точность и тон;

4. Summary Agent — объединяет результаты в итоговый отчёт.

Это простой пример, но он чётко демонстрирует, как несколько агентов могут сотрудничать.

Я уже создал консольное приложение .NET 9. Сначала очищу файл Program.cs.

Установка необходимых пакетов

Далее установим пакеты Microsoft Agent Framework.

Откройте NuGet Package Manager и выполните поиск следующих библиотек:

1. Microsoft.Agents.AI — установите этот пакет.

2. Microsoft.Agents.AI.Workflows — помогает строить и связывать агентов через рабочие процессы.

3. Microsoft.Extensions.AI.OpenAI — позволяет интегрировать модели OpenAI или размещённые на GitHub.

После установки все они появятся в разделе Dependencies вашего проекта. Теперь мы готовы реализовывать агентов и рабочий процесс.

Добавление клиента чата

Клиент чата позволяет агентам взаимодействовать с моделью ИИ.

В нашем случае используется модель GitHub — GPT-4.0 Mini, лёгкая, но очень мощная, идеально подходящая для демонстраций. Чтобы получить к ней доступ, понадобится GitHub API key.

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

Этот клиент чата соединяет наше приложение .NET с моделью OpenAI, размещённой на GitHub, чтобы мы могли создавать агентов поверх неё.

Создание French Translator Agent

Наш первый агент — French Translator.

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

Мы создаём экземпляр агента через класс ChatClientAgent и называем его French Agent.

В параметрах указываем:

• Name = “French Agent”

• Instructions = “Переводи любой предоставленный текст на французский язык, сохраняя естественность и точность.”

Готово — первый агент настроен.

Создание Spanish Translator Agent

Чтобы не писать всё заново, скопируйте код French Agent и внесите несколько изменений:

• Переименуйте переменную в SpanishAgent;

• Задайте имя “Spanish Agent”;

• Измените инструкции: “Ты — переводчик, который переводит текст на испанский язык.”

Теперь у нас есть два агента:

• один для французского,

• другой для испанского.

Создание Quality Reviewer Agent

Далее копируем код Spanish Agent и адаптируем его для Quality Reviewer Agent.

Переименовываем переменную в QualityReviewerAgent и задаём имя “Quality Reviewer Agent”.

Чтобы сделать код чище, создаём отдельную строковую переменную с инструкцией:
string qualityReviewerAgentInstructions = "...";

Этот агент будет проверять переводы и давать оценку качества с помощью простой системы рейтингов.

Создание Summary Agent

Теперь создаём Summary Agent по аналогии.

Копируем код Quality Reviewer Agent и вносим изменения:

• Переименовываем переменную в SummaryAgent;

• Имя — “Summary Agent”.

Создаём новую строку summaryAgentInstructions и прописываем назначение:

“Объедини все рецензии переводов в единый итоговый отчёт.”

Вот и всё — Summary Agent готов.

Построение рабочего процесса

Теперь нужно связать всех четырёх агентов в один процесс.

Создаём новый AI-агент WorkflowAgent с помощью класса AgentWorkflowBuilder и вызываем метод BuildSequential.

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

1. French Translator

2. Spanish Translator

3. Quality Reviewer

4. Summary Agent

В конце вызываем .AsAgentAsync(), чтобы объединить всю цепочку в одного агента, с которым можно взаимодействовать напрямую.

Внутри фреймворка результат одного агента автоматически передаётся следующему — так создаётся единый конвейер взаимодействия.

Запуск рабочего процесса

Теперь добавим ввод текста от пользователя для теста.

Попросим пользователя ввести английское предложение и передадим его агенту через workflowAgent.Run(userInput).

Текст пройдёт весь конвейер:

1. French Translator

2. Spanish Translator

3. Reviewer

4. Summary Agent

Каждый этап обрабатывает результат и передаёт его дальше.

Для красивого вывода:

• имя агента выводим жёлтым,

• результат работы — зелёным.

Теперь запускаем приложение.

В консоли появится приглашение ко вводу. Введите, например, “Hello world” и нажмите Enter.

Вы увидите:

• French Agent переведёт фразу на французский;

• Spanish Agent — на испанский;

• Quality Reviewer Agent проверит оба перевода на тон, грамматику и точность;

• Summary Agent создаст краткий отчёт о качестве перевода.

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

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

Заключение

Мы только что создали полноценный многоязычный конвейер перевода с использованием Microsoft Agent Framework.

Вот что мы сделали:

• Создали четыре агента — French Translator, Spanish Translator, Quality Reviewer и Summary Agent;

• Объединили их в последовательный рабочий процесс;

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

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

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

Вы можете расширить этот рабочий процесс:

• добавить новые языки,

• создать дополнительные этапы проверки,

• интегрировать внешние API для более глубокого анализа или улучшенного перевода.

В этом руководстве мы подробно разберём одну из самых полезных функций Entity Framework Core (EF Core) — глобальные фильтры запросов (Global Query Filters).

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

В этой статье мы разберём, что такое глобальные фильтры, когда их стоит использовать, как их реализовать и какие улучшения появились в EF Core 10 благодаря появлению именованных фильтров (Named Filters). Мы также создадим практический пример реализации на .NET 10 с использованием SQLite.

Что такое глобальные фильтры запросов

Проще говоря, глобальный фильтр запроса — это условие, которое EF Core автоматически применяет ко всем запросам для конкретной сущности. Можно считать его постоянным WHERE-условием, определённым один раз в модели и применяемым EF Core ко всем выборкам.

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

• Мягкое удаление (soft delete) — скрытие записей, помеченных как удалённые.

• Мультиарендность (multi-tenancy) — обеспечение изоляции данных для разных клиентов (тенантов).

• Архивация — хранение старых записей без отображения их в обычных запросах.

Практические примеры

1. Мягкое удаление (Soft Delete)

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

2. Мультиарендность (Multi-Tenancy)

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

3. Архивация

Некоторые данные нужно сохранять для аудита или отчётности, но не отображать в ежедневных операциях. Глобальный фильтр позволяет скрывать такие записи, сохраняя при этом возможность их извлечения при необходимости.

Реализация глобальных фильтров в .NET 10

Рассмотрим, как реализовать мягкое удаление с помощью глобальных фильтров запросов EF Core в новом проекте .NET 10 Web API.

Шаг 1: Настройка проекта

Создаём новый проект и устанавливаем необходимые пакеты EF Core:

• Microsoft.EntityFrameworkCore

• Microsoft.EntityFrameworkCore.Sqlite

• Microsoft.EntityFrameworkCore.Tools

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

Шаг 2: Создание сущности

В папке Entities создаём класс Blog:

Флаг IsDeleted будет использоваться для пометки записей как удалённых, без физического удаления из базы.

Шаг 3: Настройка DbContext

В папке Data создаём класс ApplicationDbContext, наследующий DbContext.
Используем primary constructor для передачи параметров в базовый класс.

Добавляем свойство DbSet<Blog> — оно указывает EF Core, что нужно создать таблицу Blogs в базе данных.

Переопределяем метод OnModelCreating и добавляем глобальный фильтр:

Теперь при каждом запросе к таблице Blogs EF Core будет автоматически исключать мягко удалённые записи.

Шаг 4: Настройка API-эндпоинтов

Создаём несколько API-методов для работы с блогами:

• GET /api/blogs — возвращает все блоги (без удалённых).

• GET /api/blogs/all — возвращает все блоги, включая удалённые (.IgnoreQueryFilters()).

• GET /api/blogs/{id} — возвращает блог по ID.

• POST /api/blogs — создаёт новый блог.

• DELETE /api/blogs/{id} — выполняет мягкое удаление блога.

Шаг 5: Настройка SQLite и DI

В файле appsettings.json добавляем строку подключения:

В Program.cs регистрируем контекст базы данных:

Шаг 6: Создание миграций

В консоли диспетчера пакетов выполняем:

После этого создастся база данных SQLite и таблица Blogs с полями Id, Name и IsDeleted.

Тестирование API

С помощью Postman или .http файла выполняем тестовые запросы:

1. GET /api/blogs → возвращает пустой массив.

2. POST /api/blogs → создаёт новый блог (ответ 201 Created).

3. GET /api/blogs → возвращает созданный блог.

4. GET /api/blogs/all → показывает те же данные (удалённых пока нет).

Реализация мягкого удаления

Теперь изменим поведение метода Delete, чтобы он не удалял записи физически.

Переопределим метод SaveChangesAsync в ApplicationDbContext:

Теперь при удалении запись не удаляется, а просто помечается как удалённая.

После выполнения удаления:

• GET /api/blogs → возвращает пустой массив.

• GET /api/blogs/all → показывает удалённый блог с IsDeleted = true.

Улучшения в EF Core 10: Именованные фильтры

До версии EF Core 10 глобальные фильтры имели два серьёзных ограничения:

1. Можно было задать только один фильтр на сущность.

2. Метод .IgnoreQueryFilters() отключал все фильтры сразу.

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

Именованные фильтры решают эту проблему

Теперь можно:

• Определять несколько фильтров для одной сущности.

• Отключать конкретный фильтр, не трогая остальные.

Пример:

Чтобы обойти только этот фильтр:

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

Использование констант для имён фильтров

Чтобы избежать опечаток и сделать код более читаемым, создайте статический класс с константами:

Теперь вы можете ссылаться на фильтр так:

Если имя фильтра изменится, его нужно будет обновить только в одном месте.

Финальное тестирование

После добавления именованных фильтров:

• GET /api/blogs → показывает только активные блоги.

• POST /api/blogs → создаёт новый блог.

• GET /api/blogs/all → показывает все блоги, включая мягко удалённые.

Так EF Core автоматически применяет глобальные фильтры, а при необходимости вы можете временно их отключать.

Заключение

Глобальные фильтры запросов — это мощный инструмент EF Core, который помогает автоматизировать логику выборки данных и повышает безопасность приложения.

В этом руководстве мы разобрали:

• Что такое глобальные фильтры запросов.

• Как реализовать мягкое удаление.

• Какие улучшения появились в EF Core 10 с именованными фильтрами.

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

В современном цифровом мире всё больше организаций переходят к мультиоблачным стратегиям, используя возможности нескольких облачных провайдеров для достижения гибкости, отказоустойчивости и глобального охвата. Обычно сюда входит Microsoft Azure, но также активно применяются Amazon Web Services (AWS), Google Cloud Platform (GCP), Oracle Cloud Infrastructure (OCI) и другие.

Однако управление несколькими облаками создаёт целый ряд вызовов: вопросы управления (governance), безопасности, идентификации, архитектуры приложений, размещения данных, эксплуатации и DevOps — все эти аспекты необходимо учитывать одновременно. В данной статье основное внимание уделено сетевой связности между облаками и внутри них, при этом важно помнить, что полноценная мультиоблачная стратегия невозможна без унифицированного управления безопасностью и политиками.

Сетевые основы в Azure

Базовым элементом сетевой инфраструктуры Azure является Virtual Network (VNet). Каждая виртуальная сеть:

• существует в рамках конкретной подписки и не может охватывать несколько подписок;

• располагается в одном регионе Azure, то есть не может быть распределена между регионами;

• определяется одним или несколькими диапазонами IPv4 (и, при необходимости, IPv6).

Внутри VNet разворачиваются ресурсы — виртуальные машины (VM), контейнеры и сервисы. Хотя не все сервисы Azure изначально входят в VNet, многие можно интегрировать для приватного подключения, обходя публичные точки доступа и снижая риски взаимодействия с интернетом.

Подсети и интеграция сервисов

Каждая VNet делится на подсети (subnets), в которых размещаются ресурсы. Существует два основных способа интеграции сервисов Azure в VNet:

1. Delegated Subnets — некоторые сервисы (например, базы данных) можно разворачивать в подсетях, делегированных конкретному сервису. Это обеспечивает доступ к ним через приватные IP-адреса внутри сети.

2. Private Endpoints — специальные сетевые интерфейсы, подключающие PaaS-сервисы Azure к вашей подсети. Это позволяет безопасно обращаться к ним через внутреннюю сеть, без выхода в интернет.

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

DNS и безопасность

DNS играет ключевую роль в обеспечении корректного подключения. Поскольку большинство соединений защищены с помощью TLS, правильное разрешение имён (DNS resolution) необходимо для соответствия сертификатов TLS именам доменов. Azure предлагает Private DNS Zones и поддержку conditional forwarding для корректного разрешения имён между связанными сетями и локальными средами.

Гибридная облачная связность

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

• Публичное подключение

• Приватное подключение

Глобальная сеть Microsoft

Microsoft управляет одной из крупнейших частных сетей в мире:

• более 165 000 миль оптоволоконных и подводных кабелей, соединяющих свыше 60 регионов Azure;

• более 185 глобальных точек присутствия (PoP), где осуществляется взаимодействие с другими сетями и интернетом.

Эта сеть используется как для публичных, так и для приватных подключений.

Приватное подключение: ExpressRoute

Для высокопроизводительных и надёжных соединений Azure предлагает ExpressRoute.
Как это работает:

1. Организация подключается от своего дата-центра к точке присутствия (PoP), где доступна глобальная сеть Microsoft.

2. Провайдер связи организует кросс-подключение к маршрутизаторам Microsoft.

3. В Azure разворачивается ExpressRoute Gateway, управляющий обменом трафика между облаком и локальной сетью.

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

Публичное подключение: Site-to-Site VPN

Более доступной альтернативой ExpressRoute является Site-to-Site VPN — защищённый туннель через интернет между локальным VPN-устройством и Azure VPN Gateway.
Это дешевле, но менее стабильно — возможны задержки и потери пакетов.
Обычно используется как резервный канал для ExpressRoute.

Соединение между виртуальными сетями

Так как каждая VNet ограничена регионом и подпиской, крупные компании создают десятки таких сетей.
Azure предлагает несколько способов их объединить:

• VNet Peering — прямое соединение двух сетей без перекрытия адресов.

• Hub-and-Spoke — центральная сеть-хаб подключает несколько «спиц» (spokes). Хаб содержит общие сервисы — DNS, файрвол, шлюзы и т.д.

• Azure Virtual WAN — управляемый сервис, упрощающий масштабное подключение.

• Azure Virtual Network Manager — централизованное управление маршрутами и связностью.

Связь между облаками (Multicloud Connectivity)

Теперь перейдём к межоблачным соединениям — например, между Azure, AWS, GCP или OCI.
Каждый крупный провайдер использует схожую сетевую модель:

• AWS — VPC (Virtual Private Cloud)

• GCP — VPC (Virtual Private Cloud)

• OCI — VCN (Virtual Cloud Network)

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

VPN-соединение между облаками

Самый простой способ соединить Azure с другим облаком — это Site-to-Site VPN, создающий зашифрованный туннель между двумя шлюзами.
Метод безопасный, но ограничен скоростью (~1 Гбит/с) и нестабилен по задержкам.

Приватное межоблачное подключение

У каждого провайдера есть собственное решение, аналогичное ExpressRoute:

• AWS Direct Connect

• Google Cloud Interconnect

• Oracle FastConnect

Эти сервисы подключаются через те же PoP-центры, что и Microsoft, обеспечивая прямую межоблачную связь.
Главное правило — выбирать географически близкие регионы (например, Azure London и AWS London), чтобы снизить задержки.

Варианты подключения

1. Прямое подключение (Dedicated)

   • Используются собственные маршрутизаторы.

   • До 100 Гбит/с пропускной способности.

   • Подходит для крупных предприятий.

2. Cloud Exchange-провайдеры (например, Equinix, Megaport)

   • Управляют маршрутизацией и кросс-подключениями за вас.

   • Идеально для компаний, предпочитающих управляемые решения.

Также можно настроить VPN как резервное соединение для повышения отказоустойчивости.

Особый случай: Azure – Oracle Interconnect

Microsoft и Oracle предоставляют совместное решение Oracle Interconnect for Azure, объединяющее ExpressRoute и FastConnect.
Оно обеспечивает сверхнизкую задержку (например, между Azure London и OCI London).

Производительность и оптимизация

Для максимальной производительности:

• Включите ExpressRoute FastPath для обхода шлюза.

• Настройте единое DNS-разрешение.

• Используйте резервные каналы в разных PoP для отказоустойчивости.

Безопасность, управление и мониторинг

Мультиоблачная связность невозможна без:

• Централизованного мониторинга безопасности (логи, метрики, оповещения);

• Единого управления и соответствия политикам (например, с помощью Azure Arc);

• Единой системы идентификации и контроля доступа во всех средах.

Заключение

Мультиоблачная связность строится не на «магических» технологиях, а на проверенных сетевых принципах.
Подключая Azure к локальной инфраструктуре или другим облакам (AWS, GCP, OCI), организации выбирают два основных подхода:

• Зашифрованный VPN-туннель через интернет — проще, но с ограниченной скоростью.

• Приватное подключение через выделенные каналы — сложнее, но с уровнем надёжности предприятия.

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

Сегодня, когда искусственный интеллект развивается стремительно, ещё никогда не было лучшего времени, чтобы быть .NET-разработчиком, работающим с AI. Благодаря современным библиотекам и API-интерфейсам, интеграция больших языковых моделей (LLM) в приложения .NET стала простой, быстрой и надёжной.

Одним из ключевых инструментов, который делает этот процесс таким удобным, является библиотека Microsoft.Extensions.AI. Она предоставляет чистые абстракции для работы с разными AI-провайдерами.
В этой статье мы подробно рассмотрим, как использовать GitHub Models в .NET 9: настроим OpenAI-адаптер, создадим чат-клиент и подключим приложение напрямую к модели всего за несколько строк кода.

1. Настройка консольного приложения .NET 9

Начнём с создания базового консольного приложения .NET 9. Когда оно готово, добавим необходимые библиотеки.

Установка библиотек

1. Откройте NuGet Package Manager.

2. В поле поиска введите Microsoft.Extensions.AI.

3. Вместо установки этой библиотеки напрямую установите Microsoft.Extensions.AI.OpenAI — именно она нужна для подключения к GitHub Models.

4. Пакет OpenAI уже включает в себя основную библиотеку Microsoft.Extensions.AI как зависимость, поэтому устанавливать её отдельно не нужно.

После установки убедитесь, что библиотека добавлена в проект. Очистите Program.cs, чтобы перейти к следующему этапу.

2. Создание и настройка чат-клиента

Интерфейс IChatClient — это главная абстракция, предоставляемая библиотекой Microsoft.Extensions.AI, которая позволяет взаимодействовать с большими языковыми моделями в .NET.

Создаём экземпляр чат-клиента

Создайте переменную типа IChatClient и присвойте ей новый экземпляр чат-клиента.

• Имя модели:
  Указывает, какую модель GitHub Models вы хотите использовать. Укажем его позже.

• API-ключ:
  Этот ключ аутентифицирует ваше приложение в GitHub Models. Без него запросы не будут выполняться. Пока оставим его пустым — позже добавим реальный ключ.

• Endpoint:
  В OpenAIClientOptions есть свойство Endpoint. Так как мы подключаемся к GitHub Models, укажите URL:

  https://api.github.com/models


  Это позволит клиенту отправлять все запросы напрямую в GitHub Models.

После этого вызовите .AsChatClient(), чтобы преобразовать клиент конкретного провайдера в стандартный интерфейс IChatClient.
Это важно: такой подход делает код чистым, гибким и независимым от провайдера. Если вы решите сменить поставщика AI, логику приложения менять не придётся.

3. Создание API-ключа GitHub

Теперь создадим API-ключ GitHub, чтобы получить доступ к моделям.

1. Перейдите на GitHub Models Marketplace.

2. В выпадающем списке выберите модель.

3. Для примера используем GPT-4.1 Mini.

4. Нажмите «Use this model».

5. Если вы используете бесплатный тариф, нажмите «Create personal access token», чтобы сгенерировать API-ключ.

Создание токена

• Установите срок действия (по умолчанию 30 дней).

• Укажите имя токена, например YouTube GitHub Model Token.

• Нажмите «Generate token» для создания.

Скопируйте токен сразу — он отображается только один раз. Храните его в надёжном месте и никогда не вставляйте напрямую в код. Для демонстрации мы вставим его в примере, но в реальном приложении используйте переменные окружения или Secret Manager.

После вставки токена добавьте имя модели ("gpt-4.1-mini") — на этом настройка чат-клиента завершена.

4. Реализация логики чат-приложения

Теперь, когда клиент готов, создадим логику самого чата.

Приветственное сообщение

При запуске приложения отобразите короткое приветствие и инструкцию, как выйти из чата.

История диалога

Чтобы модель могла поддерживать контекст, создайте список для хранения всех сообщений между пользователем и моделью.
В нём будут как сообщения пользователя, так и ответы ассистента.

Основной цикл чата

Чат должен работать непрерывно, пока пользователь не введёт exit.

1. Используйте цикл while (true).

2. Отобразите приглашение ко вводу в консоли.

3. Считайте сообщение пользователя.

4. Если строка пустая — пропустите итерацию.

5. Если введено exit — выйдите из цикла.

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

5. Потоковые ответы модели в реальном времени

Перед тем как вывести ответ модели, добавьте метку «Assistant:», чтобы было видно, от кого сообщение.

Метод GetStreamingResponseAsync() позволяет получать ответ постепенно, токен за токеном, то есть вы будете видеть текст по мере его генерации — как в настоящем чате.

Используйте Console.Write() для вывода каждого токена сразу, создавая эффект живого диалога.
Параллельно сохраняйте ответ в переменную assistantResponse, добавляя каждый фрагмент текста.
Когда модель закончит, добавьте полный ответ в историю чата, чтобы сохранить контекст.

6. Улучшение интерфейса

Пока что и пользователь, и модель выводятся одинаковым цветом, что не очень удобно.
Исправим это:

• Приветствие: жёлтый

• Сообщения пользователя: белый

• Ответ ассистента: зелёный

Теперь чат стал нагляднее и приятнее визуально.

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

7. Тестирование чат-приложения

Проверим, как работает наш чат:

• Введите: What’s .NET?
  → Ассистент мгновенно объясняет, что такое .NET.

• Затем попробуйте: Write a story about a superhero.
  → Модель начинает стримить креативную историю прямо в консоль.

• Проверим контекст:

  1. Введите Add 10 and 5.
     → Ответ: 10 + 5 = 15.

  2. Затем введите Minus 4.
     → Ответ: 15 - 4 = 11.

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

8. Заключение

Вы только что увидели, насколько просто .NET может взаимодействовать с AI и большими языковыми моделями с помощью библиотеки Microsoft.Extensions.AI.

Всего за несколько строк кода мы:

• Подключили консольное приложение .NET 9 к GitHub Models

• Реализовали потоковую генерацию ответов

• Добавили историю диалога

• Создали интерактивный чат

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

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

Для B2C-разработчиков понимание Onion Architecture — важный шаг к освоению современных принципов проектирования. Для B2B-лидеров её внедрение помогает ускорить разработку критически важных систем и повысить их устойчивость к изменениям.
Мы специализируемся на современных архитектурных подходах и помогаем компаниям находить экспертов, способных внедрять эффективные архитектурные решения, такие как Onion Architecture.

Что такое Onion Architecture

Onion Architecture альтернатива классическим многоуровневым архитектурам, где дизайн часто диктовался пользовательским интерфейсом или инфраструктурой, что приводило к избыточным связям и сложности.
Onion Architecture, напротив, ставит бизнес-логику в центр системы, следуя принципам Domain-Driven Design (DDD).

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

Слои Onion Architecture

1. Core Domain Layer (внутренний слой)

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

2. Application Layer

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

3. Adapter Layers (внешние слои)

Внешние слои, или адаптеры, обеспечивают взаимодействие с внешним миром: базами данных, интерфейсами, API и другими сервисами. В их состав входят:

• Infrastructure Layer: отвечает за доступ к данным, работу с файлами и интеграцию с инфраструктурой. Позволяет менять базу данных или другие технологии без затрагивания основной логики.

• Presentation Layer: реализует пользовательское взаимодействие — будь то веб-интерфейс, мобильное приложение или API. Этот слой передаёт запросы пользователей в приложение и отображает результаты.

• External Services Layer: интегрирует внешние сервисы — платёжные шлюзы, API и микросервисы. Абстрагирует взаимодействие с внешними системами и обеспечивает устойчивую интеграцию.

Основные принципы Onion Architecture

1. Принцип инверсии зависимостей (Dependency Inversion Principle, DIP)

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

2. Инверсия управления (Inversion of Control, IoC)

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

3. Разделение ответственности (Separation of Concerns)

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

Преимущества Onion Architecture

1. Поддерживаемость

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

2. Тестируемость

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

3. Гибкость

Система легко адаптируется к изменениям: можно заменить базу данных, API или фреймворк интерфейса без переписывания ядра приложения.

4. Масштабируемость

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

5. Улучшенное взаимодействие команд

Чёткое разделение слоёв позволяет разным командам — разработчикам, дизайнерам, DevOps-инженерам — работать параллельно, не мешая друг другу.

Где применяется Onion Architecture

Эта архитектура идеально подходит для крупных и сложных систем, таких как:

• Корпоративные приложения: ERP, CRM и другие системы, требующие долгосрочной поддержки.

• Веб-приложения: SaaS и e-commerce проекты, где важно разделение логики и интерфейса.

• Микросервисы: каждый сервис можно строить как независимую “луковицу” со своей бизнес-логикой и инфраструктурой.

• Финансовые системы: особенно полезна там, где важна безопасность и строгая изоляция бизнес-правил от внешних сервисов.

Как мы помогает внедрить Onion Architecture

Мы знаем, что архитектура — это фундамент надёжного ПО. Мы помогаем компаниям проектировать и внедрять Onion Architecture и другие современные паттерны, адаптированные под их цели.

1. Архитектурный консалтинг

Наши эксперты помогают организациям спроектировать и внедрить архитектуру, обеспечивая устойчивость, гибкость и масштабируемость. Мы работаем как с новыми проектами, так и с миграцией устаревших систем.

2. Подбор специализированных специалистов

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

Заключение

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

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

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

1. Основные принципы и компоненты платформенной инженерии

В своей основе внутренняя платформа разработчика (IDP) — это единая среда, сочетающая цифровые инструменты и общую инфраструктуру для достижения бизнес-целей через повторяемые и стандартизированные процессы. Главная задача IDP — объединить разработчиков и специалистов по IT-операциям вокруг безопасного, масштабируемого и надежного фундамента.

1.1. Четыре «C» облачно-нативной архитектуры

Современная стратегия облачных технологий опирается на четыре ключевых слоя:

• Cloud (Облако) — базовая инфраструктура, где выполняются рабочие процессы (AWS, Azure, Google Cloud или частные облака).

• Cluster (Кластер) — группа физических или виртуальных машин, управляемых контроллером. Стандартом стали Kubernetes и Docker.

• Container (Контейнер) — лёгкие изолированные единицы, в которых упаковано приложение с зависимостями, обеспечивающими стабильную работу в любой среде.

• Code (Код) — логика и инструкции, созданные разработчиками и запускаемые внутри контейнеров.

1.2. Принципы проектирования

Дизайн платформы базируется на проверенных методологиях, таких как SOLID, обеспечивающих масштабируемость и поддержку микросервисных систем. Также учитываются сетевые модели (например, средние уровни модели OSI), которые определяют, как сервисы взаимодействуют между собой.

1.3. Ключевые элементы платформы

Компоненты делятся на две основные группы:

• Инструменты для сотрудничества – IDE, системы контроля версий (GitHub, GitLab), таск-трекеры (Jira, Aha!), коммуникационные сервисы (Slack, Mattermost), а также панели управления с SSO. Важную роль играют интегрированные средства безопасности: анализ кода, проверка зависимостей и т.п.

• Инфраструктура для деплоя – формируется через Infrastructure as Code (IaC): Terraform, Kubernetes-манифесты, Docker-конфигурации. CI/CD пайплайны (Jenkins, GitHub Actions, GitLab CI/CD, ArgoCD, Flux) обеспечивают быстрый и автоматизированный релиз без «узких мест».

2. Масштабируемость, безопасность и устойчивость

Эти три качества являются базовыми для любой платформы.

• Масштабируемость – гибкость системы под изменяющуюся нагрузку. Kubernetes и Terraform играют ключевую роль в автоматизации масштабирования.

• Безопасность – должна закладываться на старте: шифрование данных «в движении» и «в покое», многофакторная аутентификация (MFA), строгий контроль доступа через OAuth или LDAP.

• Устойчивость – способность восстанавливаться при сбоях. Оптимальной считается модель резервного копирования 3-2-1.

2.1. Архитектурные модели

Существуют три основных подхода:

1. Постоянные – всегда работающие кластеры (dev, test, prod). Предсказуемы и стабильны.

2. Переходные – динамически выделяемые ресурсы с автоскейлингом и ограничением времени жизни. Выгодны по затратам.

3. Эфемерные – временные кластеры под конкретную задачу (например, запуск тестов), после чего уничтожаются.

3. Экосистема инструментов платформы

Эффективная платформа строится на автоматизации:

• Infrastructure as Code (IaC) – Terraform, Chef, Puppet, позволяющие описывать инфраструктуру кодом.

• Configuration Management (CM) – Ansible, Puppet, Chef для автоматизации настройки систем.

• VCS – Git как стандарт. Подход GitOps позволяет управлять инфраструктурой через репозиторий.

3.1. Оркестрация и наблюдаемость

• Kubernetes – стандарт для контейнеров: балансировка, самовосстановление, авторазвёртывание.

• Service Mesh (Istio, Linkerd) – контроль трафика и безопасности между сервисами.

• Мониторинг и логи – Prometheus и стек ELK для централизованной аналитики.

• OpenTelemetry – открытый стандарт для сбора метрик, логов и трассировок.

3.2. CI/CD пайплайны

CI/CD — это двигатель, превращающий идею в готовое приложение.

• Популярные инструменты: Jenkins, GitLab, CircleCI.

• Пайплайны включают стадии: разработка → сборка → тест → деплой.

4. Безопасность, соответствие и управление

Защита должна быть частью архитектуры:

• Secure-by-Default – безопасность закладывается по умолчанию.

• Шифрование данных – обязательно в хранении и передаче.

• RBAC и SSO – ограничение прав доступа.

• Vulnerability Management – регулярное сканирование CVE, генерация SBOM для отслеживания зависимостей.

Инструменты безопасности интегрируются прямо в CI/CD пайплайн (SAST, dependency scanning).

5. Искусственный интеллект в платформенной инженерии

ИИ кардинально меняет управление платформами:

• Автоматизация разработки – GitHub Copilot, Google Gemini помогают писать код и ускоряют рутину.

• Интеллектуальная инфраструктура – предиктивный скейлинг и оптимизация ресурсов.

• Усиление безопасности – обнаружение аномалий и анализ угроз.

• Вызовы – защита данных, регуляторные ограничения (GDPR), этические вопросы прозрачности и занятости.

6. Управление данными в платформенной инженерии

Данные – топливо для ИИ и бизнеса.

• Значение данных – платформы дают инфраструктуру для обработки больших объёмов информации.

• Стратегии – выбор между data lakes и data warehouses, автоматизация пайплайнов.

• Архитектура данных – должна учитывать 5 V Big Data: объём, скорость, ценность, разнообразие и достоверность.

• DataOps – применение принципов DevOps к управлению данными.

Заключение

Платформенная инженерия — это не просто техническое решение, а стратегический инструмент бизнеса. Она является продолжением DevOps, позволяя управлять сложностью, не лишая команды автономии, и повышает продуктивность за счёт улучшения опыта разработчиков (DX).

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

Управление Kubernetes-инфраструктурой часто похоже на жонглирование множеством задач. Это отнимает у разработчиков драгоценное время и внимание, которые лучше потратить на создание приложений. Чтобы решить эту проблему, Microsoft представила AKS Automatic — новый режим развертывания для Azure Kubernetes Service, который сейчас доступен в режиме предварительного просмотра. Его цель — снять с команд значительную часть операционной нагрузки и передать её на платформу Azure, позволяя сосредоточиться на коде, а не на кластерах.

В этой статье мы разберём, что такое AKS Automatic, какие преимущества он даёт и как развернуть свой первый автоматизированный кластер.

Что такое AKS Automatic?

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

Ключевые возможности и преимущества

1. Интеллектуальное управление узлами и масштабирование

Главное достоинство — полностью автоматизированное управление узлами с помощью Node Autoprovisioning (NAP), основанного на проекте Karpenter с открытым исходным кодом. Система анализирует требования ожидающих запуска pod’ов и автоматически подбирает оптимальный тип виртуальной машины для баланса производительности и стоимости.

Кроме того, AKS Automatic сразу включает несколько механизмов масштабирования:

• Horizontal Pod Autoscaler (HPA): масштабирует количество pod’ов в зависимости от нагрузки.

• KEDA (Kubernetes Event-driven Autoscaling): изменяет масштаб приложений на основе внешних событий (например, сообщений из очередей или триггеров базы данных).

• Vertical Pod Autoscaler (VPA): динамически корректирует запросы ресурсов pod’ов (CPU, память).

Дополнительно:

• Автоматический ремонт узлов: при сбое система пытается восстановить узел.

• Автоматические обновления кластера: обеспечивают актуальные версии и патчи безопасности с возможностью планирования технических окон.

Важно: пока AKS Automatic поддерживает только узлы на Azure Linux, Windows-узлы недоступны.

2. Встроенная безопасность по умолчанию

Безопасность интегрирована изначально и соответствует лучшим практикам Microsoft:

• Azure RBAC: управление доступом через роли и разрешения Azure.

• Microsoft Entra Workload ID: безопасное подключение приложений к сервисам Azure без секретов и ключей.

• Политики развёртывания: автоматическая проверка на соответствие стандартам Kubernetes с помощью Azure Policy.

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

3. Полностью управляемая сеть

Сетевые настройки в Kubernetes часто становятся проблемой, но AKS Automatic упрощает этот процесс, предоставляя готовую оптимизированную инфраструктуру:

• Azure CNI Overlay с Cilium: высокопроизводительная и безопасная связь между pod’ами.

• Управляемый Nginx Ingress: интеграция с Azure DNS для автоматической настройки доменов и Azure Key Vault для управления SSL/TLS-сертификатами.

• Управляемый NAT Gateway: надёжное и масштабируемое исходящее интернет-соединение.

Практическое руководство: создание кластера AKS Automatic

Шаг 1. Настройка Azure CLI

Установите расширение и включите необходимые флаги:

az extension add --name aks-preview az extension update --name aks-preview az feature register --namespace "Microsoft.ContainerService" --name "AKS-Automatic" az feature register --namespace "Microsoft.ContainerService" --name "NodeAutoProvisioningPreview" az provider register --namespace Microsoft.ContainerService

Шаг 2. Создание кластера через Azure Portal

1. Откройте Kubernetes Services → Create.

2. В поле «Cluster preset configuration» выберите Automatic.

3. Заполните базовые параметры (ресурсная группа, имя, регион).

4. (Опционально) Настройте мониторинг с Azure Monitor, Prometheus и Grafana.

5. Нажмите Review + Create.

Шаг 3. Подключение и проверка

Получите учётные данные:

az aks get-credentials --resource-group <ResourceGroup> --name <ClusterName>

kubectl get nodes kubectl get pods -n kube-system

Шаг 4. Развёртывание тестового приложения

Создайте пространство имён:

kubectl create namespace demo-app

kubectl apply -f your-app.yaml -n demo-app

kubectl get ingress -n demo-app

Итог

AKS Automatic — это серьёзный шаг вперёд в упрощении работы с Kubernetes. Автоматизация инфраструктуры, масштабирования, обновлений и безопасности снимает с команд рутинные задачи и позволяет сосредоточиться на создании бизнес-ценности. Несмотря на то, что функция пока в режиме предварительного просмотра, она уже демонстрирует огромный потенциал для пользователей Azure Kubernetes Service.