-
Notifications
You must be signed in to change notification settings - Fork 170
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: Model container.v0
like project.v0
and dockerfile.v0
#3820
aspire: Model container.v0
like project.v0
and dockerfile.v0
#3820
Conversation
0530b48
to
3d9ee17
Compare
container.v0
like project.v0
and dockerfile.v0
container.v0
like project.v0
and dockerfile.v0
cli/azd/pkg/apphost/testdata/TestAspireContainerGeneration-resources.bicep.snap
Show resolved
Hide resolved
The test failures look like this:
So I am guessing I need to re-record this test, which makes sense - since we see new control plane operations. |
3d9ee17
to
92cb7f3
Compare
This changes the way that we model `container.v0` resources from an App Host project to be more in line with how `project.v0` and `dockerfile.v0`. When we started to explore what `azd` and Aspire looked like, we decided that since we didn't have to worry about building and pushing container images for a `container.v0` resource, we could just emit the bicep for the container app as part of the shared infrastructure for the application and not worry about trying to create these images at `deploy` time. As time has gone on, we've found that treating these special was the wrong call. They are very similar to the `project.v0` and `dockerfile.v0` resources and modeling them the same way makes the whole system easier to understand. With this change, we now treat these resources the same as `project.v0` and `dockerfile.v0`. This means that we don't emit bicep for these resources (instead we have `.tmpl.yaml` manifests) and that we don't create the container app resources until `azd deploy`. While creating the container app itself has moved into `deploy`, we still create any volumes needed in the managed environment during `provision`. The names of these volumes written as bicep outputs (using `SERVICE_<service_name>_VOLUME_<volume_name>_NAME` as a template) and then referred to via `.Env` references in our container app manifests.
92cb7f3
to
8bffb9f
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
…ml-for-container-v0-resources
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
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
WindowsPowerShell install
MSI install
Standalone Binary
MSIDocumentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
This changes the way that we model
container.v0
resources from an App Host project to be more in line with howproject.v0
anddockerfile.v0
. When we started to explore whatazd
and Aspire looked like, we decided that since we didn't have to worry about building and pushing container images for acontainer.v0
resource, we could just emit the bicep for the container app as part of the shared infrastructure for the application and not worry about tryingto create these images at
deploy
time.As time has gone on, we've found that treating these special was the wrong call. They are very similar to the
project.v0
anddockerfile.v0
resources and modeling them the same way makes the whole system easier to understand.With this change, we now treat these resources the same as
project.v0
anddockerfile.v0
. This means that we don't emit bicep for these resources (instead we have.tmpl.yaml
manifests) and that we don't create the container app resources untilazd deploy
.While creating the container app itself has moved into
deploy
, we still create any volumes needed in the managed environment duringprovision
. The names of these volumes written as bicep outputs (usingSERVICE_<service_name>_VOLUME_<volume_name>_NAME
as a template) and then referred to via.Env
references in our container app manifests.