Persistent container support

[danegsta]

Description

Adds a new annotation and API to support marking container resources with a persistent lifetime. This will allow Aspire to use container resources with a longer lifetime than the AppHost (in addition to the current behavior that creates and tears down all container resources with the AppHost). Opening this as a draft PR as there is additional work to finalize the API and add tests required.

This PR adds a new ContainerLifetimeAnnotation annotation and WithContainerLifetime resource builder API to allow configuring the expected lifetime of container resources. With this initial implementation, a container would be able to have one of two lifetime settings, Default or Persistent.

Container Lifetime Modes

Default Lifetime

This lifetime mode is the same as the existing behavior for container resources. Default lifetime resources will be created when the AppHost starts based on the resource builder configuration and shut down when the AppHost terminates.

Persistent Lifetime

This is a new optional lifetime mode for container resources. A persistent container resource is identified by the assigned container/resource name. When the AppHost is started, if no running containers are found that match the specified service name, a new container resource will be created, just like for AppHost lifetime resources. However, if a container is found with the specified service name, Aspire will use that resource instead of creating a new one. When the AppHost shuts down, this container resource will not be terminated. This will allow a container to be re-used across multiple runs of the AppHost.

Example

var catalogDb = builder.AddPostgres("postgres")
                       .WithContainerLifetime(ContainerLifetimeType.Persistent)
                       .WithDataVolume()
                       .WithPgAdmin()
                       .AddDatabase("catalogdb");

Caveats

With this initial design, a persistent container resource will never be recreated if a matching container is found, even if the resource builder definition has been modified in such a way that the existing container is no longer compatible with the new configuration. Users will need to manually terminate their existing container via the Docker/Podman CLI or management GUI to trigger a recreation of the resource matching the new configuration.

Granularity of container lifetime is limited to matching that of the AppHost or running as a globally persistent resource; we don't yet have a mechanism to spin up or tear down longer running sets of container services as part of a development session, this means that users that want longer running resources, but not constantly running resources will have to implement their own scripts or manually cleanup individual resources when they're not longer needed.

Both of these scenarios are cases that we'd like to improve on in future PRs, but we still feel this initial design should help reduce pain points related to container startup that we've heard from users of Aspire.

Finally, this initial API is marked as Experimental as we may need to revisit the design as we look to improve some of the identified limitations of the experience in future PRs.

Fixes # (issue)

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue:
  • No

Microsoft Reviewers: Open in CodeFlow

[davidfowl]

@ReubenBond we need to make sure this doesn't regress testing scenarios right?

[danegsta]

I've been hesitant to add tests to this PR for persistent resources as I don't want to introduce any test instability by leaving resources behind after a test run.

[davidfowl]

@mitchdenny how do you feel about merging this so we can start kicking the tires?

[mitchdenny]

Let's get it in. Would be good to socialise this with some of the other changes for 9.0