POC: Adds Kustomize support with azd and AKS
#3048
Closed
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
wbreza
commented
Dec 2, 2023
| @@ -1,7 +1,7 @@ | |||
| // Copyright (c) Microsoft Corporation. All rights reserved. | |||
| // Licensed under the MIT License. | |||
|
|
|||
| package project | |||
| package osutil | |||
There was a problem hiding this comment.
Moving ExpandableString out of project package and into our more generic osutil to help avoid circular dependencies between packages.
Bumps [@adobe/css-tools](https://github.com/adobe/css-tools) from 4.0.1 to 4.3.2. - [Changelog](https://github.com/adobe/css-tools/blob/main/History.md) - [Commits](https://github.com/adobe/css-tools/commits) --- updated-dependencies: - dependency-name: "@adobe/css-tools" dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…ure#3009) * Make dashboard optional via name * Formatting * Formatting * With insert final new line
ellismg
reviewed
Dec 2, 2023
| // Another common scenario is to use the kustomize edit commands to modify the kustomization.yaml | ||
| // configuration before applying the manifests. | ||
| // Common scenarios for this would be for modifying the images or namespace used for the deployment | ||
| for _, edit := range serviceConfig.K8s.Kustomize.Edits { |
There was a problem hiding this comment.
Should we be adding the kustomize CLI to the list of required tools when Kustomize.Edits is not empty so we get our genialized "you need this tool but you don't have it" behavior?
There was a problem hiding this comment.
Still have some stuff to finish up - this being one of those thing :)
| } | ||
| } | ||
|
|
||
| // Finally apply manifests with kustomize using the -k flag |
There was a problem hiding this comment.
Will we need to bump the minimum version of kubectl we say we require or does it already support -k?
There was a problem hiding this comment.
It's been baked in for a while - I'll have to go back and check the release notes.
| "github.com/azure/azure-dev/cli/azd/pkg/exec" | ||
| ) | ||
|
|
||
| // Cli is a wrapper around the kustomize cli |
There was a problem hiding this comment.
Thanks for these small comments, it really does make this a joy to read.
* adding target for docker build --------- Co-authored-by: Victor Vazquez <vhvb1989@gmail.com>
This restores the init behavior prior to 1.4.0 regression. `azd init` simply considers the current working directory when initializing, without attempting to resolve a parent directory project which is counterintuitive. Fixes Azure#2946
Handle interrupt to unhide terminal cursor from a potentially active spinner Azure#2194
Our intention is to use Azure RBAC to secure access to the container registry, and the exchange our AAD token for a time limited access token that we use to log into the registry. That has worked for some users, but others have run into issues like what we see in Azure#2980 While we're still trying to root cause the actual issue, we have discovered that if the admin account is enabled, the end to end seems to work. This change enables the admin account to allow `azd` to fall back to that when the token exchange doesn't work. Contributes To: Azure#2980
When publishing an .NET Application, you have two choices as to how to reference the .NET Runtime. You can either publish as a framework dependent project, where your app will use a pre-deployed copy the .NET Runtime, or self contained, where your app will care the .NET Framework for your target platform with it. Framework dependent projects are the default, because they are smaller (you don't need to bring along an entire .NET runtime with your application). In Aspire, we were publishing as self contained because we needed the latest and greatest version of the .NET Runtime, since there were some breaking changes that impacted Aspire and it depended on, and the public base container images on MCR had `rc2` bits. Now that .NET 8 has shipped, this is no longer a problem, and we can publish as a framework dependent project once again. This results in smaller container images, because they can leverage the shared framework from the base container image instead of including yet another copy of the runtime in the application layer.
* adding rg as variable for pipeline config * azdo
…3071) Avoid a panic and provide a better error message when containerPort is missing in binding. This is a runtime check for what should normally be handled at compile-time. Related to: Azure#3070
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)
Fixes an issue where if AZURE_ENV_NAME does not exist within the .env file then downstream operations will fail when looking up resource group or service names.
When we started the Aspire work, we thought we might only support
simple binding expressions with a single reference, e.g.:
`"{api.bindings.http.url}"`. Over time, this allow grew to allow
literals (e.g.: `"true"`). In Preview 2, the manifests now supports
multiple replacements in a single expression, to support things like
connection strings where you need multiple parts:
`"Host={api.bindings.tcp.host},Port={api.bindings.tcp.port}"`
To prepare for this, I've split the string evaluation logic from the
value resolution logic and then enhanced the string evaluation logic
to support more complex strings, while adding some tests to ensure
things behave as expected.
Upgrade dotnet base images to be based on bullseye. Also, bump to 20131107.2 which is the current stable version and supports .NET 8. Fixes Azure#3108
- Update all .NET samples and tests from .NET 6 to .NET 8 (latest LTS)
* changelog * version file * notes --------- Co-authored-by: Victor Vazquez <vhvb1989@gmail.com>
Updating azure.yaml schema to support docker build target
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSIContainerDocumentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
Make "Retrieving locations..." ephemeral once again
Do not require `docker login` for Aspire apps The `dotnet` toolchain is able to build and push container images for Asprire apps via, `dotnet publish`. However, we still needed `docker` around so we could run `docker login` to log into the private ACR registry we intended to push the image to. To remove the dependency on `docker login` we can use the `SDK_CONTAINER_REGISTRY_UNAME` and `SDK_CONTAINER_REGISTRY_PWORD` environment variables as described in: https://github.com/dotnet/sdk-container-builds/blob/main/docs/RegistryAuthentication.md#authenticating-to-container-registries The caveats here do not apply to us. If they did, we could consider either editing the `~/.docker/config.json` directly, to add our auth information or setting `DOCKER_CONFIG` when running `dotnet publish` to a version that we write (just in time, in a temp dir) and clean up after. Note that the credentials fetched via the AAD flow are shortlived (~3hr of validity) and so caching them in `~/.docker/config.json` long term is less than ideal (our documentation for commands like `az acr login` mention that you should do this before each operation). --------- Co-authored-by: Wei Lim <weilim@microsoft.com>
This change relaxes the project detection logic during `azd init` to warn for projects unreferenced by the app host. With this change, for dotnet app detection, we also exclude wasm based projects such as BlazorAssembly as hostable. These projects can be referenced by a Blazor server and act as a library. Fixes Azure#3024
Fix the generation logic: emit a log analytics workspace when a container apps environment is required. Remove the dependency of container registry on log analytics workspace since that is actually extraneous based on the bicep template/ Fixes Azure#3141
Increase resiliency of devcontainer install scripts for function tools: - Install under `/opt/microsoft/azure-function-core-tools` - Symbolic link just `func` instead of installing binaries into `/usr/bin`
* update runtime version * update incompatible packages
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.14.0 to 0.17.0. - [Commits](golang/crypto@v0.14.0...v0.17.0) --- updated-dependencies: - dependency-name: golang.org/x/crypto dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…skip auto-browser opening. (Azure#3096)
* association for .bicept as go-template and extension for syntax * net aspire - support cosmos db * remove new line
This enables the admin user on the provisioned container registry so that `azd` can connect to it to push even if RBAC is not working because the user is not an owner of the resource. We've seen cases where users who's accounts where created a long while back are set as [classic administrators](https://learn.microsoft.com/en-us/azure/role-based-access-control/classic-administrators) and not Owners on their accounts and there is presently a service issue that prevents these users from exchanging their AAD creds for an access token. Fixes Azure#3157
* feat: add gha schema lint * checkout v4 and remove pull-requests permission
Bumps [follow-redirects](https://github.com/follow-redirects/follow-redirects) from 1.15.2 to 1.15.4. - [Release notes](https://github.com/follow-redirects/follow-redirects/releases) - [Commits](follow-redirects/follow-redirects@v1.15.2...v1.15.4) --- updated-dependencies: - dependency-name: follow-redirects dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
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.
Important
See #3196 that contains Kustomize support.