I have a problem on my build/release pipeline with Azure Container Reigstry.
I use a Azure Resource Group Deployment task to deploy Azure Container Registry (and other stuff) and it works perfectly.
I have the loginServer, username and password in output variables to reuse it.
Then I want to build and push image to ACR but I can't set the name of the registry (that I get from output variable) with a variable. I have to choose the registry when I setup the definition, but it is not created at this moment.
Is there a way to do this ?
As a workaround, I use the Azure Resource Group Deployment the create the registry and then I send output variables to a powershell script which build, tag and push my images to the registry.
If nobody has a better way, I think I will post a uservoice to change that.
When you say you use an Azure Resource Group Deployment task, are you referring to VSTS?
If you could provide more specific repro steps, I might be more helpful.
I'd also suggest you might take a look at https://aka.ms/acr/build as easy way to natively docker build images with your registry. ACR Build is now available in all regions and simplifies may of the experiences you may be hitting.
Daniel just made this post that helps with the VSTS integration: https://www.danielstechblog.io/building-arm-based-container-images-with-vsts-and-azure-container-registry-build/
Steve
Sorry for the delay, I was off the office.
I just retry to fix my problem and it seems that I can now enter a free text (and so, a release variable) to the VSTS docker task to specify the ACR I just created before with a Azure Resource Group Deployment task.
So no problem anymore.
Thank you for your response, I will take a look to ACR build :)
Bastien
Related
I'm using Azure AD app registration principles to deploy resources via Azure Resource Manager to deploy via Pipelines.
During the deployment I need to set some permissions to the deployment user to ensure it has enough permission to - for example - upload files.
As I'm using different principles, and I'm not managing those in the code, I would like to know if there is a way to reference the "current user-principals - ID" during the deployment.
Something like:
deployment().properties.xx
or
environment()
https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/template-functions-deployment
https://learn.microsoft.com/en-us/azure/templates/microsoft.authorization/roleassignments?tabs=bicep
Otherwise, I would need to inject this information via parameter, I think. I could get that information by script - or there is a variable even present from azure dev ops.
Any ideas, help appreciated. Thanks.
Currently, it's not possible to get the objectId of the user deploying the template... we do have a backlog item for it.
I was trying to do this in Pulumi where I had a local Dockerfile and wanted it to be sent to build the same as the command 'az acr build' sadly it kept erroring as it wanted a full url.
I did some digging but I can't quite figure it out. I'm not a developer as such, just a dabbler.
what is az acr build doing under the hood and can this be replicated using the APIs ?
This is the build command
https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/azure/cli/command_modules/acr/build.py
And it also calls this as part of it
https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/azure/cli/command_modules/acr/_archive_utils.py
What it seems to be doing is calling the api to get a storage account and sas that lives behind the ACR and then Tar/gzip and uploading to it and then referencing it?
But I can't find any documented behaviour for that for ACR. Like how do you see that zip and remove it once it's built. That kind of thing.
https://learn.microsoft.com/en-us/rest/api/containerregistry/registries%20(tasks)/get-build-source-upload-url
If anyone can explain what's going on there that would be great thanks.
I want to pass in --isolation process to the az acr build, but cannot find a way to do it from Azure docs, what is the right way to do it?
According to this case with similar problem, it seems that you cannot pass the isolation parameter to az acr build command. No isolation parameter is provided in az acr build.
As workaround , you can define a task's steps in a YAML file. You can then run the task manually by passing the file to the az acr run command.
Multi-step task definition in ACR Tasks provides a container-centric compute primitive focused on building, testing, and patching containers. ACR Tasks supports multi-step task declaration in standard YAML syntax.
The build step type supports isolation property. For a detailed guide, please refer to this document.
I have been looking into the "logic apps designer' of Microsoft azure for a couple of days. Thank you for your help! I am stuck on the following:
Context
I wanted to perform some actions interacting between multiple files in a Dropbox. The logic app was not proposing an off-the-self solution, hence I created a python script that did exactly what I wanted.
I then decided to create an image of this script in order to be able to use it from the azure platform within the Logic Apps.
The containers registry contains the image I pushed to Azure and I created the container instance that includes only one image which is the python script.
Everything works.
Current structure
From what I read, it seems that we can run the container instance by using the action called create group container then adding a until action (run until state is equal to Succeeded) and finally using delete the container group.
I have a trigger that has been tested and that works.
Issue
When running the Logic App, the action create group container is failing:
"code": "InaccessibleImage",
"message": "The image '<name_of_the_image>' in container group '<name_of_the_group>' is not accessible. Please check the image and registry credential."
Question
How can I correct what seems to be a basic error on my part?
Where can this registry credential be appropriately corrected?
Update
I have tried removing everything, assigning myself "owner" role in the container registry, then adding the container instance, assigning myself "owner" role in the container instance, then rebuilt the logic app. I ran it again and I get the same error.
I figured the issue.
Since in my case, it is a private container registry, I needed to add the following the the action 'create group container': properties.imageRegistryCredentials.
In this, you will be required to enter the following information that are available in the Access keys of the container registry:
[
{
"password": "<yourpassword>",
"server": "<yourloginserver>",
"username": "<yourusername>"
}
]
So glad and I hope it helps others!
To set the credentials of ACI inside Create or update container group task in logic app you need to add a parameter (See the picture).
add parameter for ACI credentials
I'm using Azure DevOps pipelines to update our deployment in K8s cluster in Azure. It used to be working fine until yesterday, as for some reason the Pods in the cluster remain in their previous state. I can see that the image was successfully updated in ACR (container registry) and has a label 'latest'. However, the release pipeline doesn't seem to be doing anything useful. I use 'set' command in the task to update the Pod (it is well described in the Kubernetes docs and cheatsheet here)
This is the command sample extracted from the log:
kubectl set image deployments/identityserver identityserver='myacr'/identityserver:latest -n identityserver-dev
As it indicates, I'm getting the latest image from ACR and trying to roll an update. It executes well (both in cmd and Azure DevOps). no errors, although, the Pod remains unaffected. Have I missed something in the docs? Should I raise the ticket with Microsoft?
why do you have ' in image name? also, latest wont work if you already have latest on the image, you need to be specific https://github.com/kubernetes/kubernetes/issues/33664.
This is not an Azure issue
Please check here answers to similar question on SO, on why it is not a good option to use :latest tag in your Deployment spec, along with workarounds provided.