Separate publishing to container registries with new azd publish command
#5663
Conversation
JeffreyCA
force-pushed
the
jeffreyca/5601/aca-publish
branch
from
ac3fc44 to
917e130
Compare
|
Hello, I don't know if it can be included in this PR or not but It could be great to be able to publish to another docker registry than ACR. Thanks for your work |
Thank you for the input! I'm testing this scenario out and it looks like it shouldn't be too hard to support in this PR given that azd deploy supports external registries already today. |
There was a problem hiding this comment.
A couple questions and issues to consider.
-
The
ServiceTargetinterface exposesPackageandDeployfunctions. Given this change we should consider addingPublishto this interface and implementing it on supported service targets like container app -
Given a new top level command we should also consider exposing new
publishproject & service hooks so users can more easily integrate with this new capability. -
Given the separation of publishing from deploy we should consider whether our default
upworkflow should still only calldeployor also includepublishas well. -
Consider adding
Publishsupport for AKS service target (future PR)
JeffreyCA
force-pushed
the
jeffreyca/5601/aca-publish
branch
from
c79efb0 to
690bc1f
Compare
JeffreyCA
force-pushed
the
jeffreyca/5601/aca-publish
branch
from
690bc1f to
4c53c10
Compare
JeffreyCA
changed the title
azd deployazd publish command
JeffreyCA
requested review from
tg-msft,
rajeshkamal5050 and
hemarina
as code owners
| ctx context.Context, | ||
| serviceConfig *ServiceConfig, | ||
| localImageTag string, | ||
| options *PublishOptions, |
There was a problem hiding this comment.
Does this feel unnatural? I was a little surprised to see RemoteTag() take in PublishOptions.
One observation I can offer: docker supports both local and remote contexts in the image tag.
I wonder if there's a line of thought we could apply here: What if packagePath had local vs. remote segments in the path itself?
There was a problem hiding this comment.
What if packagePath had local vs. remote segments in the path itself?
docker supports both local and remote contexts in the image tag.
Could you provide an example?
Are you suggesting ServicePackageResult.PackagePath be something like:
type PackagePath struct {
Local string
Remote string
}and have RemoteImageTag use that instead of generating the remote image tag from localImageTag and PublishOptions?
There was a problem hiding this comment.
I'm going to continue the discussion for the sake of idealization and education. I'm still working through a set of refactorings I could imagine taking place that can help shape these longer term payoff ideas.
In the most simplistic idealistic world, I would start with a URI.
The frontend (whether it goes through publishing, or via a remote image reference) would just produce a PackageService with Path: example.com:5000/team/my-app:2.0 OR myimage OR imageId.
The backend is agnostic to how this was done, the concept of "publishing options" wouldn't materialize at this layer.
There was a problem hiding this comment.
We do already have some prior art here around remote vs local tag in the container helper. Looks like we're reusing that here with docker.ContainerImage struct.
| ctx context.Context, | ||
| serviceConfig *ServiceConfig, | ||
| packageResult *ServicePackageResult, | ||
| publishResult *ServicePublishResult, |
There was a problem hiding this comment.
I'm personally a little nervous to consider "publish" a lifecycle with its own set of components, and having stack another layer here.
I could imagine a natural evolution here is to create proper data structure around PackagedService which perhaps looks like *ServicePackageResult, but either just by the path around, or some attribute, indicating whether it's remote. An interesting lead for me is to consider how docker image tags are already shaped today, in this other comment here
There was a problem hiding this comment.
We are really just teasing out work from deploy since it likely does too much today. I like the idea of have smaller incremental lifecycle events like build, package, publish, deploy that each have single responsibility per host/service target. It will also enable developers to provide more precise integration points from hooks/extensions to do what they want to do.
There was a problem hiding this comment.
Rephrasing question for clarity: Should Deploy() take in both ServicePackageResult and ServicePublishResult? What does it mean to have both set?
There was a problem hiding this comment.
Overall this looks amazing! I only have a couple open questions around the following:
- Default overrwrite behavior? Should be true/false if the image/tag already exists?
- Just need to ensure all our e2e tests cases still work to ensure we don't have any regressions.
| Flags | ||
| --all : Deploys all services that are listed in azure.yaml | ||
| -e, --environment string : The name of the environment to use. | ||
| --force-publish : Forcibly publishes service, overwriting any existing published artifacts. |
There was a problem hiding this comment.
I'm a bit confused by this flag. What is the use case. Prior to this azd deploy always publishes a new container to the registry. So is this the same behavior with a default value of true ? Or am I missing a new scenario?
There was a problem hiding this comment.
Yeah pretty much, say the user has a hardcoded image and tag in azure.yaml, which already exists in the remote container registry.
services:
svc:
...
docker:
image: 'web'
tag: latestIf the user runs the following sequence of commands, they'd need to set --force-publish in order to update the current image in the registry with the newly built one:
azd package web- producesweb:latestazd deploy web --from-package web:latest --force-publish
Or if using publish:
azd package web- producesweb:latestazd publish web --from-package web:latestazd deploy web --from-package web:latest
If we instead inverted the overwrite behaviour (deploy always publishes), then it might look like this instead:
azd package web- producesweb:latestazd deploy web --from-package web:latest
Or if using publish:
azd package web- producesweb:latestazd publish web --from-package web:latestazd deploy web --from-package web:latest --skip-publish
There was a problem hiding this comment.
If I needed to vote:
web:latestis antipattern, see https://learn.microsoft.com/en-us/azure/container-registry/container-registry-image-tag-version#unique-tags. This leans me to not introduce this behavior or flag until we need it later.- If we needed to address this as a user feature, do the smart thing -- not a configuration, not a flag. Is there a way to do a delta diff and publish the "most latest" image?
There was a problem hiding this comment.
From this week's earlier discussion, we agreed to change this so that: if the user runs azd deploy web --from-package with a fully qualified image reference like myacr.azurecr.io/web:20250918, that would instruct azd deploy to skip publishing (and packaging as well). That way we don't need to support any additional --skip-publish or --force-publish deploy flags.
Another suggestion that came up was for azd publish to have a single flag to be able to set the destination registry, image, and tag instead of separate --image and --tag. Something like:
# Override registry, repository, and tag
azd publish web --from-package web:20250918--to myacr.azurecr.io/aca/web:latest
# Override repository and tag
azd publish web --from-package web:20250918--to web:latest
# Override registry and repository
azd publish web --from-package web:20250918--to myacr.azurecr.io/aca/webHowever, it's a bit unclear how this would support overriding only the tag, or other combinations that separate --tag and --image supports.
Any thoughts?
cli/azd/internal/cmd/publish.go
Outdated
| "Publish the service named 'api' with image name 'app/api' and tag 'prod'.": output.WithHighLightFormat( | ||
| "azd publish api --image app/api --tag prod", | ||
| ), | ||
| "Publish the service named 'api' from a previously generated package.": output.WithHighLightFormat( | ||
| "azd publish api --from-package <image-tag>", | ||
| ), | ||
| }) |
There was a problem hiding this comment.
I wonder if we can leverage this new azd publish behavior to simplify some container based scenarios where it is now closer to gitops type flow where we can just publish a new "latest" tag for the same image and then the host/service target is responsible for the heavy lifting of fetching the updated container, restarting the instance... Only need a full deploy flow if your spec changes or has additional configuration/dependencies.
There was a problem hiding this comment.
That is interesting. Do you happen to have working scenarios to share?
At a glance, I suspect this may not be easy to do -- the secrets (for example, keyvault secrets) aren't stamped directly into the image.
| ctx context.Context, | ||
| serviceConfig *ServiceConfig, | ||
| localImageTag string, | ||
| options *PublishOptions, |
There was a problem hiding this comment.
We do already have some prior art here around remote vs local tag in the container helper. Looks like we're reusing that here with docker.ContainerImage struct.
| ctx context.Context, | ||
| serviceConfig *ServiceConfig, | ||
| packageResult *ServicePackageResult, | ||
| publishResult *ServicePublishResult, |
There was a problem hiding this comment.
We are really just teasing out work from deploy since it likely does too much today. I like the idea of have smaller incremental lifecycle events like build, package, publish, deploy that each have single responsibility per host/service target. It will also enable developers to provide more precise integration points from hooks/extensions to do what they want to do.
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
Closes #5601
This PR introduces a separate
azd publishcommand for publishing container images to a container registry. There are also some minor changes toazd deploy.TODO
azd publishazd publishsupports these flags:--all(similar toazd deploy)--from-package(similar toazd deploy)--image- override default container image namedocker.imageservice property in azure.yaml:--tag- override default tag nametagproperty in azure.yaml:Other changes/notes:
The default
azd upworkflow is unchanged and will still callprovisionanddeploy, butazd upcan be customized in azure.yaml withazd publishand the same image reference would be used throughout using theserviceManageroperation result cache--from-packageis compatible with--imageand--tag. So running the following command would publish the local imagetodo-nodejs-mongo-aca-web:azd-deploy-1757350123to<acr>.azurecr.io/web-override:override:azd publishsupports publishing to third-party container registries (likedocker.io) using thedocker.registryservice property in azure.yaml.Only services with host type
containerappandaksare currently supported. The command succeeds with a warning on unsupported host types:Supports local and remote build
Supports
prepublishandpostpublishproject and service hooks:The
IMAGE_NAMEservice property is still set in the environment for backwards compatibility, but becausepublishis now a top level action, thedeploylogic can get the published image fromServicePublishResultinstead of reading from theIMAGE_NAMEenvironment variable.azd deployazd deploynow by default skips publishing the image to the container registry if the image exists remotely. There's a new flag--force-publishthat forces azd to always publish the image duringdeploy. If the image does not exist remotely,deploystill publishes to the registry like previously.Note
Is this behavioural change okay, or should we keep the old behaviour, where
azd deployalways publishes and can potentially overwrite existing remote images? (Would then need something likeazd deploy --skip-publishinstead ofazd deploy --force-publish)azd deploy --from-packagenow supports fully qualified remote images, so one can run something like:azd publish <svc>--from-packageprovided)azd deploy <svc>--from-packageprovided)