Deploy existing docker container from Azure Container Registry to Azure App Service

[Nick Ganter (nickyg91)]

Is it possible to deploy an existing container that was built in a separate CI pipeline and pushed to an existing ACR? When using the AddContainer extension the Azure App Service and the corresponding prepare slot are not created.

Is this by design? Am I thinking about this all wrong? Or am I trying to use .NET Aspire in a way it isn't meant to be used?

I want to build the container separately and have aspire orchestrate the azure resource creation and deploy the docker image built in a CI pipeline to the Azure App Service it configures.

Below is an example of what I am doing in Aspire. This deploys "successfully" but does not actually deploy the App Service in the resource group that is created. I've omitted the slot configuration code for brevity.

var service = builder
	.AddContainer("my-container", $"{acrLoginServer}/my-container")
	.WithImage($"my-container")
	.WithImageTag(imageTag)
	.WithHttpEndpoint(targetPort: 8080, name: "http")
	.WithHttpHealthCheck(path: "/health", endpointName: "http");
	
	service
	.WithExternalHttpEndpoints()
	.PublishAsAzureAppServiceWebsite();

Edit: I forgot to mention I do have a workaround for this, but it isn't super ideal.
I have a base dockerfile that actually tags an ARG as the source image from the existing ARC source - this gets around the App Service not deploying but still requires some container to be built by Aspire during aspire deploy.

The workaround uses the AddDockerfile().WithBuildArg(...) extension calls and a dockerfile with the below contents in it.

ARG SOURCE_IMAGE
FROM ${SOURCE_IMAGE}

[Max (Maxaubert)]

This is by design in the current App Service integration: it only creates a website for .NET projects and for containers that have a Dockerfile build (AddDockerfile, or AddProject). A plain AddContainer with a prebuilt image is skipped when the environment generates its App Service resources, so nothing is created and the deploy "succeeds" without an App Service.

The filter is here:

aspire/src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentResource.cs

Lines 215 to 220 in 9360f2c

	// Support SDK-published .NET programs and containers with Dockerfiles.
	if (!resource.SupportsDotnetProgramPublishing() &&
	!(resource.IsContainer() && resource.TryGetAnnotationsOfType<DockerfileBuildAnnotation>(out _)))
	{
	continue;
	}

// Support SDK-published .NET programs and containers with Dockerfiles.
if (!resource.SupportsDotnetProgramPublishing() &&
    !(resource.IsContainer() && resource.TryGetAnnotationsOfType<DockerfileBuildAnnotation>(out _)))
{
    continue;
}

Also note that PublishAsAzureAppServiceWebsite() with no arguments throws "configure or configureSlot must be provided" in current main, so pass at least an empty configure lambda:

aspire/src/Aspire.Hosting.Azure.AppService/AzureAppServiceComputeResourceExtensions.cs

Lines 42 to 45 in 9360f2c

	if (configure == null && configureSlot == null)
	{
	throw new ArgumentException("configure or configureSlot must be provided.");
	}

So the pass-through Dockerfile you already use is currently the supported way to get an App Service for an existing image. It is a bit heavier than ideal because Aspire builds and pushes a thin image, but it does give you the App Service and slot:

builder.AddAzureAppServiceEnvironment("appservice");

builder.AddDockerfile("my-container", "./passthrough")
    .WithBuildArg("SOURCE_IMAGE", $"{acrLoginServer}/my-container:{imageTag}")
    .WithHttpEndpoint(targetPort: 8080, name: "http")
    .WithHttpHealthCheck("/health")
    .WithExternalHttpEndpoints()
    .PublishAsAzureAppServiceWebsite((infra, site) => { });

I could not find an open issue or PR for prebuilt-image support in the App Service environment, so if you want it natively, opening a feature request for "AddContainer with existing image on Azure App Service" would be the way to track it.