-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aspire: Add support for dockerfile.v0
#3075
aspire: Add support for dockerfile.v0
#3075
Conversation
I suspect that there are future refactoring we can do to exploit how similar the handling of |
a73c398
to
e10afdc
Compare
e10afdc
to
5c7c44f
Compare
b2fc791
to
c3515ef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! One thing I'm noticing is that "dotnet containerapp service target" is slowly becoming much more than a service target. To me, it feels like the horizontal concepts like "framework service" and "service target" seems rather limiting in this regard, and I yearn for something more vertical.
As part of Preview 2, Aspire is adding support for a new resource, `dockerfile.v0`. This represents an image that should be built (from a Dockerfile) and deployed. Consider the following AppHost: ```csharp var builder = DistributedApplication.CreateBuilder(args); builder.AddNodeApp("nodeapp", "../NodeApp/index.js") .WithServiceBinding(3000, scheme: "http", env: "PORT") .AsDockerfileInManifest(); builder.Build().Run(); ``` The resulting manifest looks like this: ```json { "resources": { "nodeapp": { "type": "dockerfile.v0", "path": "../NodeApp/Dockerfile", "context": "../NodeApp", "env": { "NODE_ENV": "development", "PORT": "{nodeapp.bindings.http.port}" }, "bindings": { "http": { "scheme": "http", "protocol": "tcp", "transport": "http", "containerPort": 3000 } } } } } ``` From a high level, these are very similar to `project.v0` resources. The image needs to be built and pushed (either via `dotnet publish` or `docker build` + `docker push`) and then we need to create an Azure Container Apps App from it. When doing `azd infra synth` we write the manifests for these types of services in a `manifests` folder that is SxS with the `Dockerfile`. This mimics the strategy for projects in spirit (where we use the `.csproj` file as the "project" file)
c3515ef
to
743a9c8
Compare
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
WindowsPowerShell install
MSI install
Standalone Binary
MSIContainer
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
As part of Preview 2, Aspire is adding support for a new resource,
dockerfile.v0
. This represents an image that should be built (from a Dockerfile) and deployed.Consider the following AppHost:
The resulting manifest looks like this:
From a high level, these are very similar to
project.v0
resources. The image needs to be built and pushed (either viadotnet publish
ordocker build
+docker push
) and then we need to create an Azure Container Apps App from it.When doing
azd infra synth
we write the manifests for these types of services in amanifests
folder that is SxS with theDockerfile
. This mimics the strategy for projects in spirit (where we use the.csproj
file as the "project" file)