Add support for a Dockerfile resource

[raffaeler]

trafficstars

As for #1326

That said, having support in Aspire.Hosting to add a resource via a Dockerfile to simplify using custom containers seems like a reasonable suggestion. Feel free to log that issue

The scenario of the linked issue is about Keycloak container whose image is almost always customized depending on the deployment environment (for example to add certificates to the java keystore inside the container image).

That said, there are many other examples for enterprise images that makes sense to define via a dockerfile.

[DamianEdwards]

@mitchdenny @davidfowl thoughts on this one? We could do this all in the Aspire.Hosting layer couldn't we, calling docker build when running locally and just emitting the path to the Dockerfile in the manifest when publishing?

[mitchdenny]

We kinda have some of this already on the deployment side with AsDockerfile but I agree this would be useful.

[josephaw1022]

is the AsDockerfile just for the node apps or for project resources as well? @mitchdenny

[mitchdenny]

It's for executable resources. What we are thinking here is a resource in its own right that we could build and run.

[davidfowl]

We don't support building docker images today for running, we only support publishing them.

[mitchdenny]

This is bubbling up towards the top of the list for the 8.1 milestone. There are a few different approaches we could take here. We could do something like this:

+ public IResourceBuilder<DockerfileResource> AddDockerfile(
+    this IDistributedApplicationBuilder builder,
+    string name,
+    string contextPath,
+    string? dockerfilePath = null)

+ public class DockerfileResource : IResourceWithEnvironment, IResourceWithEndpoints
+ {
+ }

This would have corresponding changes in ApplicationExecutor that look for Dockerfile resources specifically and start them as a container, but with the new DCP build settings.

Or alternatively we could just leverage the existing container resource and do something like this:

+ public IResourceBuilder<ContainerResource> FromDockerfile(
+    this IResourceBuilder<ContainerResource> builder,
+    string contextPath,
+    string? dockerfilePath= null)

+ public class DockerfileBuildAnnotation : IAnnotation {}

In this scenario, a container built from a Dockerfile would be treated as a container. The only thing that would change is that the application executor would look for the presence of the DockerfileBuildAnnotation and inject the appropriate values into the DCP resource when creating it so that DCP can take over building the container.

For the manifest we would replace container.v0 with dockerfile.v0 if the FromDockerfile method is applied to a container so that deployment tools know to build the container first before publishing it to the target registry.

/cc @davidfowl @DamianEdwards @vhvb1989 @prom3theu5 @danegsta @karolz-ms

[karolz-ms]

FWIIW, on the DCP side we modeled it as a Container with some extra (image build) data. We look if the image exists with the container orchestrator, and if not, we build it as part of the Container startup sequence. The rest of the Container lifecycle is pretty much unchanged. So more like option 2 than option 1.

[davidfowl]

I think you are right @mitchdenny. It does mean that we need to change the dockerfile resource in the manifest though. Do we deprecate it or do we expand support to be a superset of container resource?

[mitchdenny]

Good question. I think we could deprecate it and just add to container.v0

[davidfowl]

I like this plan.

[danegsta]

An important consideration is making sure that all the standard runtime annotations (and builder extensions) for containers work the same whether you start with a Dockerfile or a pre-built image.

[mitchdenny]

Yeah. We really just want the fact that a container build occurred to just be a step in the process. Everything should just work. I think we've got a solid plan for this feature so we can probably go ahead and start implementing it.

David ... I noticed you had yourself assigned to this one. Were you going to do it or did you want me to tackle it?

[davidfowl]

Assigned to you @mitchdenny 😄

[prom3theu5]

I like the idea of treating as a container like this.

While unifying these two resource types, would you be open to expanding project extensions?

Currently from a deployment point of view projects ultimately become containers but we currently don't allow overriding entry point or commands for them directly

Maybe everything that's a deployable resource in oci world should be writable AsContainer?

[davidfowl]

@mitchdenny Can you file the follow up items?

• Replacing PublishAsDockerFile with something based on this new API
• https://github.com/dotnet/aspire/issues/4522