Обзор оркестрации .NET.NET Aspire

Мақала
03/05/2025

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

Прежде чем продолжить, рассмотрим некоторые распространенные термины, используемые в .NET.NET Aspire:

модель приложений: коллекция ресурсов, составляющих распределенное приложение (DistributedApplication), определенное в пространстве имен Aspire.Hosting.ApplicationModel. Более формальное определение см. в разделе Определение модели приложения.
Хост приложения/проект Orchestrator: проект .NET, который оркестрирует модель приложения, названный с суффиксом *.AppHost (по договоренности).
ресурс: ресурс является зависимой частью приложения, например проекта .NET, контейнера, исполняемого файла, базы данных, кэша или облачной службы. Он представляет любую часть приложения, которую можно управлять или ссылаться.
Интеграция: Интеграция — это пакет NuGet для узла приложения, который моделирует ресурс, или пакет, который настраивает клиент для использования в приложении-получателе. Дополнительные сведения см. в обзоре интеграции .NET.NET Aspire.
Ссылка: Ссылка определяет соединение между ресурсами, выраженное как зависимость с помощью API WithReference. Дополнительные сведения см. в статье Справочные ресурсы или Ссылки на существующие ресурсы.

Ескерім

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

Определение модели приложения

.NET .NET Aspire позволяет легко создавать, подготавливать, развертывать, настраивать, тестировать, запускать и наблюдать за распределенными приложениями. Все эти возможности реализованы с помощью модели приложений, которая описывает ресурсы в решении .NET.NET Aspire и их отношениях. Эти ресурсы охватывают проекты, исполняемые файлы, контейнеры и внешние службы и облачные ресурсы, от которые зависит ваше приложение. В каждом решении .NET.NET Aspire есть назначенный проект "App host", где модель приложения точно описывается с помощью методов, доступных на IDistributedApplicationBuilder. Этот построитель создается вызовом DistributedApplication.CreateBuilder.

// Create a new app model builder
var builder = DistributedApplication.CreateBuilder(args);

// TODO:
//   Add resources to the app model
//   Express dependencies between resources

builder.Build().Run();

Проект хоста приложения

Проект узла приложения управляет выполнением всех проектов, которые входят в состав единого проекта .NET.NET Aspire. Другими словами, она отвечает за оркестрацию всех приложений в модели приложения. Сам проект представляет собой исполняемый проект .NET, который ссылается на пакет NuGet 📦Aspire.Hosting.AppHost, задаёт свойство IsAspireHost для значения true, и ссылается на .NET.NET Aspire из SDK.

XML

<Project Sdk="Microsoft.NET.Sdk">

    <Sdk Name="Aspire.AppHost.Sdk" Version="9.1.0" />
    
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net9.0</TargetFramework>
        <IsAspireHost>true</IsAspireHost>
        <!-- Omitted for brevity -->
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Aspire.Hosting.AppHost" Version="9.1.0" />
    </ItemGroup>

    <!-- Omitted for brevity -->

</Project>

Следующий код описывает хост приложения Program с двумя ссылками на проект, а также кэшем Redis.

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");

builder.AddProject<Projects.AspireApp_Web>("webfrontend")
       .WithExternalHttpEndpoints()
       .WithReference(cache)
       .WaitFor(cache)
       .WithReference(apiService)
       .WaitFor(apiService);

builder.Build().Run();

Предыдущий код:

Создает конструктор модели приложения, используя метод CreateBuilder.
Добавляет Rediscache ресурс с именем cache с помощью метода AddRedis.
Добавляет ресурс проекта с именем apiservice с помощью метода AddProject.
Добавляет ресурс проекта с именем webfrontend с помощью метода AddProject.
- Указывает, что проект имеет внешние конечные точки HTTP с помощью метода WithExternalHttpEndpoints.
- Добавляет ссылку на ресурс cache и ожидает его готовности с помощью методов WithReference и WaitFor.
- Добавляет ссылку на ресурс apiservice и ожидает его готовности с помощью методов WithReference и WaitFor.
Создает и запускает модель приложения с помощью методов Build и Run.

В примере кода используется .NET AspireRedis хостинговая интеграция.

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

Каждый ресурс должен иметь уникальное имя. На этой схеме показаны все ресурсы и связи между ними. Ресурс контейнера называется cache, а ресурсы проекта называются apiservice и webfrontend. Проект веб-интерфейса ссылается на проекты кэша и службы API. Когда вы выражаете ссылки таким образом, проект веб-интерфейса говорит, что он зависит от этих двух ресурсов — "кэш" и "api-сервис" соответственно.

Встроенные типы ресурсов

.NET .NET Aspire проекты состоят из набора ресурсов. Базовые типы ресурсов в 📦Aspire.Hosting.AppHost пакета NuGet описаны в следующей таблице.

Метод	Тип ресурса	Описание
AddProject	ProjectResource	Проект .NET, например, ASP.NET Core веб-приложение.
AddContainer	ContainerResource	Образ контейнера, например образ Docker.
AddExecutable	ExecutableResource	Исполняемый файл, например Node.js приложение.
AddParameter	ParameterResource	Ресурс параметра, который можно использовать для выражения внешних параметров.

Ресурсы проекта представляют .NET проекты, которые являются частью модели приложения. При добавлении ссылки на проект-хост приложения пакет SDK .NET.NET Aspire создает тип в пространстве имен Projects для каждого ссылаемого проекта. Дополнительные сведения см. в статье .NET.NET Aspire SDK: ссылки на проект.

Чтобы добавить проект в модель приложения, используйте метод AddProject:

var builder = DistributedApplication.CreateBuilder(args);

// Adds the project "apiservice" of type "Projects.AspireApp_ApiService".
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");

Проекты можно реплицировать и масштабировать, добавив несколько экземпляров одного проекта в модель приложения. Чтобы настроить реплики, используйте метод WithReplicas:

var builder = DistributedApplication.CreateBuilder(args);

// Adds the project "apiservice" of type "Projects.AspireApp_ApiService".
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
                        .WithReplicas(3);

Приведенный выше код добавляет три реплики ресурса проекта apiservice в модель приложения. Дополнительные сведения см. на панели мониторинга .NET.NET Aspire: реплики ресурсов.

Настройка явного запуска ресурсов

Ресурсы проекта, исполняемого файла и контейнера автоматически запускаются с распределенным приложением по умолчанию. Ресурс можно настроить для ожидания явной инструкции запуска с помощью метода WithExplicitStart. Ресурс, настроенный с WithExplicitStart, инициализируется при помощи KnownResourceStates.NotStarted.

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");

builder.AddProject<Projects.AspireApp_DbMigration>("dbmigration")
       .WithReference(postgresdb)
       .WithExplicitStart();

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

Ресурсы с явным началом можно запустить с панели управления .NET.NET Aspire, нажав кнопку "Пуск". Дополнительные сведения см. в разделе .NET.NET Aspire панели мониторинга: остановка или запускресурса.

Справочные ресурсы

Ссылка представляет зависимость между ресурсами. Например, можно представить сценарий, в котором веб-интерфейс зависит от Redis кэша. Рассмотрим следующий пример кода узла приложения Program C#:

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

builder.AddProject<Projects.AspireApp_Web>("webfrontend")
       .WithReference(cache);

Ресурс проекта "webfrontend" использует WithReference для добавления зависимости от ресурса контейнера "cache". Эти зависимости могут представлять строки подключения или сведения об обнаружении служб. В предыдущем примере переменная среды внедрена в ресурс webfrontend с именем ConnectionStrings__cache. Эта переменная среды содержит строку подключения, которую webfrontend использует для подключения к Redis через интеграцию .NET AspireRedis, например, ConnectionStrings__cache="localhost:62354".

Ожидание ресурсов

В некоторых случаях может потребоваться ждать, пока ресурс будет готов, прежде чем запускать другой ресурс. Например, вам может потребоваться дождаться готовности базы данных перед запуском API, который зависит от него. Чтобы выразить эту зависимость, используйте метод WaitFor:

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");

builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
       .WithReference(postgresdb)
       .WaitFor(postgresdb);

В приведенном выше коде ресурс проекта "apiservice" ожидает, пока ресурс базы данных "postgresdb" перейдет в состояние KnownResourceStates.Running. В примере кода показана интеграция .NET AspirePostgreSQL, но к другим ресурсам можно применить тот же шаблон.

В других случаях может потребоваться ожидать завершения ресурса, будь то KnownResourceStates.Exited или KnownResourceStates.Finished, прежде чем зависимый ресурс сможет запуститься. Чтобы ожидать завершения ресурса, используйте метод WaitForCompletion:

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");

var migration = builder.AddProject<Projects.AspireApp_Migration>("migration")
                       .WithReference(postgresdb)
                       .WaitFor(postgresdb);

builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
       .WithReference(postgresdb)
       .WaitForCompletion(migration);

В показанном выше коде ресурс проекта "apiservice" ожидает, пока ресурс проекта "миграция" полностью не завершится, прежде чем начать. Ресурс проекта "migration" ожидает, когда ресурс базы данных "postgresdb" перейдет в состояние KnownResourceStates.Running. Это может быть полезно в сценариях, когда необходимо выполнить миграцию базы данных перед запуском службы API, например.

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

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

API для добавления и выражения ресурсов

.NET .NET Aspire интеграции размещения и интеграции клиентов предоставляются как пакеты NuGet, но они служат разным целям. Хотя интеграции клиентских приложений предоставляют настройку библиотек для использования приложениями за пределами узла приложения, интеграции размещения предоставляют API для выражения ресурсов и зависимостей в пределах узла приложения. Для получения дополнительной информации см. раздел .NET.NET Aspire "Обзор интеграций: Интеграционные обязанности".

Ресурсы контейнера Express

Чтобы выразить ContainerResource, добавьте его в экземпляр IDistributedApplicationBuilder, вызвав метод AddContainer.

Docker
Podman

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddContainer("ollama", "ollama/ollama")
    .WithBindMount("ollama", "/root/.ollama")
    .WithBindMount("./ollamaconfig", "/usr/config")
    .WithHttpEndpoint(port: 11434, targetPort: 11434, name: "ollama")
    .WithEntrypoint("/usr/config/entrypoint.sh")
    .WithContainerRuntimeArgs("--gpus=all");

Дополнительные сведения см. в разделе поддержка GPU в Docker Desktop.

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddContainer("ollama", "ollama/ollama")
    .WithBindMount("ollama", "/root/.ollama")
    .WithBindMount("./ollamaconfig", "/usr/config")
    .WithHttpEndpoint(port: 11434, targetPort: 11434, name: "ollama")
    .WithEntrypoint("/usr/config/entrypoint.sh")
    .WithContainerRuntimeArgs("--device", "nvidia.com/gpu=all");

Дополнительные сведения см. в разделе о поддержке GPU в Podman.

Предыдущий код добавляет ресурс контейнера с именем "ollama" и изображением ollama/ollama. Ресурс контейнера настраивается с несколькими точками монтирования, с именованной конечной точкой HTTP, точкой входа, которая ссылается на скрипт оболочки Unix, и аргументами запуска контейнера с помощью метода WithContainerRuntimeArgs.

Настройка ресурсов контейнера

Все подклассы ContainerResource можно настроить в соответствии с конкретными требованиями. Это может быть полезно при использовании интеграции хостинга , которая моделирует ресурс контейнера, но требует модификаций. Если у вас есть IResourceBuilder<ContainerResource>, вы можете создавать цепочки вызовов с любым из доступных API и изменять ресурс контейнера. .NET .NET Aspire ресурсы контейнеров обычно указывают на закрепленные теги, но вы можете захотеть использовать тег latest вместо этого.

Чтобы иллюстрировать это, представьте сценарий, в котором вы используете интеграцию .NET AspireRedis. Если интеграция Redis использует тег 7.4 и вы хотите использовать тег latest вместо этого, можно создать цепочку вызовов к API WithImageTag:

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache")
                   .WithImageTag("latest");

// Instead of using the "7.4" tag, the "cache" 
// container resource now uses the "latest" tag.

Дополнительные сведения о доступных API см. в ContainerResourceBuilderExtensions.

Жизненный цикл ресурсов контейнера

При запуске хоста приложения ContainerResource используется для определения, какой образ контейнера создать и запустить. Под капотом .NET Aspire запускает контейнер, используя определенный образ контейнера, делегируя вызовы совместимой с OCI среде выполнения контейнеров, либо Docker, либо Podman. Используются следующие команды:

Docker
Podman

Сначала контейнер создается с помощью команды docker container create. Затем контейнер запускается с помощью команды docker container start.

docker container create: создает новый контейнер из указанного образа, не запуская его.
запуск контейнера Docker: запуск одного или нескольких остановленных контейнеров.

Эти команды используются вместо docker run для управления подключенными сетями контейнеров, томами и портами. При вызове этих команд в этом порядке любой IP-адрес (конфигурация сети) уже присутствует при первоначальном запуске.

Сначала контейнер создается с помощью команды podman container create. Затем контейнер запускается с помощью команды podman container start.

podman container create: создает записываемый слой контейнера по указанному изображению и подготавливает его к работе.
podman container start: запускает один или несколько остановленных контейнеров.

Эти команды используются вместо podman run для управления подключенными сетями контейнеров, томами и портами. При вызове этих команд в этом порядке любой IP-адрес (конфигурация сети) уже присутствует при первоначальном запуске.

Помимо базовых типов ресурсов, ProjectResource, ContainerResourceи ExecutableResource, .NET.NET Aspire предоставляет методы расширения для добавления общих ресурсов в модель приложения. Дополнительные сведения см. в интеграции хостинга.

Срок службы ресурса контейнера

По умолчанию ресурсы контейнеров используют время жизни контейнера сессии. Это означает, что при каждом запуске процесса узла приложения контейнер создается и запускается. Когда хост приложения останавливается, контейнер останавливается и удаляется. Ресурсы контейнеров могут выбрать постоянное время существования, чтобы избежать ненужных перезапусков и сохранить состояние контейнера. Для этого выполните цепочку вызовов API ContainerResourceBuilderExtensions.WithLifetime и передайте ContainerLifetime.Persistent.

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddContainer("ollama", "ollama/ollama")
    .WithLifetime(ContainerLifetime.Persistent);

Предыдущий код добавляет контейнерный ресурс с именем "ollama", используя образ "ollama/ollama" и обеспечивает его постоянное существование.

Ссылки на строку подключения и конечную точку

Обычно выражают зависимости между ресурсами проекта. Рассмотрим следующий пример кода:

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");

builder.AddProject<Projects.AspireApp_Web>("webfrontend")
       .WithReference(cache)
       .WithReference(apiservice);

Ссылки между проектами обрабатываются иначе, чем ресурсы с четко определёнными строками подключения. Вместо внедрения строки подключения в ресурс "webfrontend" внедряются переменные среды, поддерживающие обнаружение служб.

Метод	Переменная среды
`WithReference(cache)`	`ConnectionStrings__cache="localhost:62354"`
`WithReference(apiservice)`	`services__apiservice__http__0="http://localhost:5455"` `services__apiservice__https__0="https://localhost:7356"`

Добавление ссылки на проект apiservice приводит к добавлению переменных среды обнаружения служб в интерфейсную часть. Это связано с тем, что обычно обмен данными между проектами происходит по протоколу HTTP/gRPC. Дополнительные сведения см. в .NET.NET Aspire разделе «Обнаружение служб».

Чтобы получить определенные конечные точки из ContainerResource или ExecutableResource, используйте один из следующих API конечных точек:

Затем вызовите API GetEndpoint, чтобы получить конечную точку, которую можно использовать для ссылки на конечную точку в методе WithReference:

var builder = DistributedApplication.CreateBuilder(args);

var customContainer = builder.AddContainer("myapp", "mycustomcontainer")
                             .WithHttpEndpoint(port: 9043, name: "endpoint");

var endpoint = customContainer.GetEndpoint("endpoint");

var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
                        .WithReference(endpoint);

Метод	Переменная среды
`WithReference(endpoint)`	`services__myapp__endpoint__0=https://localhost:9043`

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

Формат переменной среды конечной точки службы

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

Если один ресурс зависит от другого ресурса, узел приложения внедряет переменные среды в зависимый ресурс. Эти переменные среды настраивают зависимый ресурс для подключения к ресурсу, от которого он зависит. Формат переменных среды зависит от .NET.NET Aspire и задаёт конечные точки службы в формате, совместимом с Service Discovery.

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

Рассмотрим следующие примеры переменных среды:

Environment

services__apiservice__http__0

Предыдущая переменная среды выражает первую конечную точку HTTP для службы apiservice. Значение переменной среды — URL-адрес конечной точки службы. Именованная конечная точка может быть выражена следующим образом:

Environment

services__apiservice__myendpoint__0

В предыдущем примере служба apiservice имеет именованную конечную точку с именем myendpoint. Значение переменной среды — URL-адрес конечной точки службы.

Ссылка на существующие ресурсы

Некоторые ситуации предполагают, что вы ссылаетесь на существующий ресурс, возможно, тот, который развернут у облачного провайдера. Например, может потребоваться ссылаться на базу данных Azure. В этом случае вы будете полагаться на Контекст выполнения для динамического определения того, работает ли хост приложения в режиме "run" или в режиме "publish". Если вы работаете локально и хотите использовать облачный ресурс, можно использовать свойство IsRunMode для условного добавления ссылки. Вместо этого можно создать ресурс в режиме публикации. Некоторые интеграции хостинга поддерживают предоставление строки подключения непосредственно, которую можно использовать для обращения к существующему ресурсу.

Аналогичным образом, могут возникнуть случаи, когда требуется интегрировать .NET.NET Aspire в существующее решение. Одним из распространенных подходов является добавление проекта хостинга приложений .NET.NET Aspire в существующее решение. В узле приложения вы выражаете зависимости, добавляя ссылки на проекты в узел приложения и сборку модели приложения. Например, один проект может зависеть от другого. Эти зависимости выражаются с помощью метода WithReference. Дополнительные сведения см. в статье Добавление .NET Aspire в существующее приложение .NET.

Жизненные циклы узла приложения

Хост приложения .NET.NET Aspire предоставляет несколько этапов жизненного цикла, в которые можно интегрироваться, реализуя интерфейс IDistributedApplicationLifecycleHook. Доступны следующие методы жизненного цикла:

Заказ	Метод	Описание
1	BeforeStartAsync	Выполняется до запуска распределенного приложения.
2	AfterEndpointsAllocatedAsync	Выполняется после того, как оркестратор выделяет конечные точки для ресурсов в модели приложения.
3	AfterResourcesCreatedAsync	Выполняется после создания ресурса оркестратором.

Хотя хост приложения предоставляет перехватчики жизненного цикла, может потребоваться зарегистрировать пользовательские события. Дополнительные сведения см. в разделе Мероприятия в .NET.NET Aspire.

Зарегистрируйте хук жизненного цикла

Чтобы зарегистрировать хук жизненного цикла, реализуйте интерфейс IDistributedApplicationLifecycleHook и зарегистрируйте хук на хосте приложения с помощью API AddLifecycleHook.

using Aspire.Hosting.Lifecycle;
using Microsoft.Extensions.Logging;

var builder = DistributedApplication.CreateBuilder(args);

builder.Services.AddLifecycleHook<LifecycleLogger>();

builder.Build().Run();

internal sealed class LifecycleLogger(ILogger<LifecycleLogger> logger)
    : IDistributedApplicationLifecycleHook
{
    public Task BeforeStartAsync(
        DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
    {
        logger.LogInformation("BeforeStartAsync");
        return Task.CompletedTask;
    }

    public Task AfterEndpointsAllocatedAsync(
        DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
    {
        logger.LogInformation("AfterEndpointsAllocatedAsync");
        return Task.CompletedTask;
    }

    public Task AfterResourcesCreatedAsync(
        DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
    {
        logger.LogInformation("AfterResourcesCreatedAsync");
        return Task.CompletedTask;
    }
}

Предыдущий код:

Реализует интерфейс IDistributedApplicationLifecycleHook в виде LifecycleLogger.
Регистрирует хук жизненного цикла с хостом приложения через API AddLifecycleHook.
Записывает сообщение для всех событий.

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

Output

info: LifecycleLogger[0]
      BeforeStartAsync
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 9.0.0
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: ..\AspireApp\AspireApp.AppHost
info: LifecycleLogger[0]
      AfterEndpointsAllocatedAsync
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17043
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17043/login?t=d80f598bc8a64c7ee97328a1cbd55d72
info: LifecycleLogger[0]
      AfterResourcesCreatedAsync
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.

Предпочтительный способ подключения к жизненному циклу узла приложения — использовать API событий. Дополнительные сведения см. в разделе Мероприятия в .NET.NET Aspire.

Контекст выполнения

IDistributedApplicationBuilder предоставляет контекст выполнения (DistributedApplicationExecutionContext), который подаёт сведения о текущем выполнении хоста приложения. Этот "контекст" можно использовать для оценки того, выполняется ли хост приложения в режиме "выполнения" или как часть операции публикации. Рассмотрим следующие свойства:

IsRunMode: возвращает true, если выполняется текущая операция.
IsPublishMode: возвращает true, если текущая операция — публикация.

Эти сведения могут быть полезны, если вы хотите условно выполнить код на основе текущей операции. Рассмотрим следующий пример, демонстрирующий использование свойства IsRunMode. В этом случае метод расширения используется для создания стабильного имени узла для RabbitMQ для локальных запусков разработки.

private static IResourceBuilder<RabbitMQServerResource> RunWithStableNodeName(
    this IResourceBuilder<RabbitMQServerResource> builder)
{
    if (builder.ApplicationBuilder.ExecutionContext.IsRunMode)
    {
        builder.WithEnvironment(context =>
        {
            // Set a stable node name so queue storage is consistent between sessions
            var nodeName = $"{builder.Resource.Name}@localhost";
            context.EnvironmentVariables["RABBITMQ_NODENAME"] = nodeName;
        });
    }

    return builder;
}

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

var builder = DistributedApplication.CreateBuilder(args);

var redis = builder.ExecutionContext.IsRunMode
    ? builder.AddRedis("redis")
    : builder.AddConnectionString("redis");

builder.AddProject<Projects.WebApplication>("api")
       .WithReference(redis);

builder.Build().Run();

В приведенном выше коде:

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

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

Маңызды

.NET .NET Aspire предоставляет общие API для управления модальность конструкторов ресурсов, что позволяет ресурсам вести себя по-разному в зависимости от режима выполнения. Интерфейсы API fluent имеют префикс RunAs* и PublishAs*. API RunAs* влияют на поведение локальной разработки (или режима выполнения), а API PublishAs* влияют на публикацию ресурса. Дополнительные сведения о том, как ресурсы Azure используют эти API, см. в статье Использование существующих ресурсов Azure.

Связи ресурсов

Связи ресурсов связывают ресурсы. Связи являются информационными и не влияют на поведение среды выполнения приложения. Вместо этого они используются при отображении сведений о ресурсах на панели мониторинга. Например, связи отображаются в сведениях о ресурсах панели мониторинга , а Parent связи управляют вложенностью ресурсов на странице ресурсов.

Связи автоматически создаются некоторыми API модели приложений. Рассмотрим пример.

WithReference добавляет связь к целевому ресурсу с типом Reference.
WaitFor добавляет связь к целевому ресурсу с типом WaitFor.
Добавление базы данных в контейнер базы данных создает связь из базы данных с контейнером с типом Parent.

Связи также можно явно добавить в модель приложения с помощью WithRelationship и WithParentRelationship.

var builder = DistributedApplication.CreateBuilder(args);

var catalogDb = builder.AddPostgres("postgres")
                       .WithDataVolume()
                       .AddDatabase("catalogdb");

builder.AddProject<Projects.AspireApp_CatalogDbMigration>("migration")
       .WithReference(catalogDb)
       .WithParentRelationship(catalogDb);

builder.Build().Run();

В предыдущем примере используется WithParentRelationship для настройки базы данных catalogdb в качестве родительского проекта migration. Связь Parent является особой, так как она управляет вложением ресурсов на странице ресурса. В этом примере migration находится под catalogdb.