Adding support for Aspire mountBinds #3790
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vhvb1989
requested review from
ellismg,
wbreza,
hemarina and
weikanglim
as code owners
weikanglim
reviewed
May 1, 2024
weikanglim
reviewed
May 1, 2024
weikanglim
reviewed
May 1, 2024
weikanglim
reviewed
May 1, 2024
weikanglim
reviewed
May 1, 2024
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSIDocumentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
ellismg
reviewed
Jun 6, 2024
There was a problem hiding this comment.
Let's put this behind an alpha flag for now. I really love the direction here and I think it's right, but want a little more time for us to think about this operations thing and how we want to model it on disk.
I also wonder if long term our model of "do this after provision" is right or we are going to want to move to a world where the uploading is more tied to the deployment of the individual service that has the mount, instead of the shared infrastructure. I wonder if folks are going to expect that if they update the content they need to run azd deploy instead of azd provision.
| if _, err := os.Stat(path); err != nil { | ||
| if os.IsNotExist(err) { | ||
| // File does not exist | ||
| return azdOperationsModel{}, nil |
There was a problem hiding this comment.
NIT: You might consider just using errors.Is to test for os.ErrNotFound on the return value from os.ReadFile instead of doing the check and then then the read.
| } | ||
|
|
||
| // resolve environment variables | ||
| expString := osutil.NewExpandableString(string(data)) |
There was a problem hiding this comment.
Just wondering if instead of expanding the entire document like this we should scope it to specific fields of specific operations.
|
|
||
| shareUrl := fmt.Sprintf("https://%s.file.%s/%s", storageAccount, cloud, fileShareName) | ||
|
|
||
| return filepath.WalkDir(source, func(path string, info fs.DirEntry, err error) error { |
There was a problem hiding this comment.
Given that fileShareService.UploadPath uploads the entire tree rooted at path, do we need the filepath.WalkDir here?
| {{range $name, $value := .ContainerApps -}} | ||
| {{range $bMount := $value.BindMounts -}} | ||
| - type: FileShareUpload | ||
| description: Upload files for {{$name}} |
There was a problem hiding this comment.
NIT: you might want to include the name of the bind-mount in addition to the name of the service?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Aspire - mount binds brings one special requirement for azd to perform data-plane operations in between Provision and Deploy.
Case: azd creates an FileShare and a Volume using that FileShare. But, before deploying a containerApp using that volume, there are some files which needs to be uploaded from the local repo to the FileShare to ensure the initial state for deploying and starting the service. For example, for starting a database, we want to upload some initial data or bootstrap scripts to set up the DB when it starts.
To support this requirement, this PR is introducing azd operations.
Azd Operations are common data-plane interactions with Azure Services, exposed as azd built-in features. One way to see azd operations is like IaC extensions. In the example above, creating a FileShare (and uploading local files into it) is not something possible by using bicep, because the deployment is sent and executed by Azure, where the local files are not reachable.
Customers can create postprovision hooks to implement data-plane operations, but it requires adding the same hook to any template/repos where you need this. With the introduction of
azd operations, customers will benefit from leveraging azd to execute common scenarios.To set up an azd operation, folks would create a file azd.operations.yaml within the IaC folder (regardless of using bicep or terraform).
The file contains the operations to execute, which are described in terms or IaC outputs.
This PR creates and implements the azd operation FileShareUpload, which looks like:
Note how the configuration references the IaC outputs directly.
After provision, azd finds the azd.operations file and replaces the output references for their actual value. Then execute the operation.
For
FileShareUpload, azd uploadspathin thefileShareNamefrom thestorageAccount. When it completes, it displays thedescriptionin the output like:On top of this feature, Aspire just generates the
azd.operations.yamlas part of producing the infrastructure.Not covered on this PR, but pending to implement:
fix: #3873