Giter Club home page Giter Club logo

container-apps-deploy-pipelines-task's Introduction

Azure Container Apps Build and Deploy (Release Candidate)

Important note

The AzureContainerAppsRC task found in this repository is the Release Candidate (RC) version of the AzureContainerApps task that ships out of the box with Azure Pipelines, which can be found here. The intended purpose of this Release Candidate task is to offer users immediate early access to features, bug fixes and patches that will eventually be rolled out in the official AzureContainerApps task at the end of every three week sprint.

Description

This Azure Pipelines Task allows users to easily deploy their application source to an Azure Container App in their Azure Pipelines workflow by either providing a previously built image, a Dockerfile that an image can be built from, or using a builder to create a runnable application image for the user.

If no Dockerfile is found or provided in the provided application source, the following steps are performed by this task:

  • Uses the Oryx++ Builder to build the application source using Oryx to produce a runnable application image
  • Pushes this runnable application image to the provided Azure Container Registry
  • Creates or updates a Container App based on this image

If a Dockerfile is found or discovered in the application source, the builder won't be used and the image will be built with a call to docker build and the Container App will be created or updated based on this image.

If a previously built image has already been pushed to the ACR instance and is provided to this task, no application source is required and the image will be used when creating or updating the Container App.

A YAML configuration file can also be provided to modify specific properties on the Container App that is created or updated; please see the section below on the yamlConfigPath argument.

Running this task on Microsoft-hosted agents

If you are running this task on a Microsoft-hosted agent, you may find that this task is not able to run successfully with the following operating systems:

  • macOS
    • The macOS runners provided by Microsoft do not come installed with Docker (more information here); as a result, this task is not able to run any docker commands, such as pushing the built runnable application images to ACR.
  • Windows
    • The Windows runners provided by Microsoft comes with Docker installed, but by default, Linux-based images are unable to be pulled down; as a result, this task is not able to pull down the Oryx builder to create runnable application images from provided application source.

Please see the below Docker prerequisite section for more information.

Data/Telemetry Collection Notice

By default, this Azure DevOps Task collects the following pieces of data for Microsoft:

  • The Container App build and deploy scenario targeted by the user
    • i.e., used the Oryx++ Builder, used a provided/found Dockerfile, or provided a previously built image
    • Note: the image name is not collected
  • The processing time of the task, in milliseconds
  • The result of the task
    • i.e., succeeded or failed
  • If the Oryx++ Builder is used, events and metrics relating to building the provided application using Oryx

If you want to disable data collection, please set the disableTelemetry argument to true.

Prerequisites

Prior to running this task, Azure resources and an Azure DevOps service connection are either required or optional depending on the arguments provided to this task.

Azure DevOps Service Connection

To deploy to Azure, an Azure subscription has to be linked to Team Foundation Server or to Azure Pipelines using the Services tab in the settings section. Add the Azure subscription to use in the Build or Release Management definition by opening the Account Administration screen (gear icon on the top-right of the screen) and then click on the Services Tab.

Create the ARM service endpoint and use the 'Azure Resource Manager' endpoint type and choose Service Principal authentication method; for more information on creating service connections, please follow this document.

Azure CLI

This task requires that the Azure CLI is installed on the Azure Pipelines agent to execute a variety of commands throughout the execution of the task. For more information on how to install the Azure CLI on the agent, please see this document. If an agent is already running on the machine on which the Azure CLI is installed, ensure that you restart the agent so that all relevant environment variables are updated.

Docker

This task requires that Docker is installed on the Azure Pipelines agent to push images to the provided Azure Container Registry. For more information on how to install Docker on the agent, please see this document.

In addition, users running this task with a Windows agent may encounter an issue with not being able to pull down Linux-based images; to resolve this, please visit this site or located the DockerCli.exe file on your agent (typically in the Program Files\Docker\Docker folder) and run

& `.\DockerCli.exe` -SwitchDaemon

If Docker is not installed on the agent running this task, the following scenario(s) are still enabled:

  • Providing a previously built image to the imageToDeploy argument that the Container App deploys with

If Docker is on the agent, but unable to work with Linux-based images, the following scenario(s) are still enabled:

  • Providing a previously built image to the imageToDeploy argument that the Container App deploys with
  • Providing a Dockerfile as a part of your application source that will be built and deployed with the Container App
    • Note: the Dockerfile cannot have any Linux-based image layers

pack CLI

The pack CLI is maintained by the Cloud Native Buildpacks project and is used by this task to create runnable application images for the user when the application source code is provided and no additional Dockerfile is provided or found. A builder was created by Oryx to take in the application source code provided to this task and produce an image that could then be pushed to an image registry and used within a Container App to build and run the application.

A stable version of the pack CLI is installed on the Azure Pipelines agent executing the task, and depending on the base OS of this agent, different tools will be leverage to assist with the installation:

  • On Windows runners:
    • A set of PowerShell commands are executed to do the following:
      • Creates a pack folder in the agent's temporary folder, if the pack folder doesn't already exist
      • Downloads the pack CLI .zip into this pack folder
      • Unzips the content from this .zip and places them in the pack folder
      • Deletes the .zip
  • On non-Windows runners:
    • curl will be used to pull down the .tgz containing the pack executable
    • tar will be used to unzip the .tgz and place the pack executable in /usr/local/bin

Azure Container Registry

An Azure Container Registry must exist that the user is able to push container images to. This task will leverage the Azure Container Registry to either push a built runnable application image to and/or deploy a Container App from.

The name of the Azure Container Registry is required via the acrName argument.

The user can also provide values for the acrUsername and acrPassword arguments that will authenticate calls to the Azure Container Registry instance; if not provided, an access token will be generated via the Azure CLI that will authenticate the calls instead.

Azure Container App environment

An Azure Container App environment is recommended to have been previously created by the user to improve the performance of the task. If no environment has been created before, or if an environment cannot be found in the resource group that is being used to host the created Container App, then an environment will be created by as a part of the az containerapp up command, which may take additional time.

Arguments

Below are the arguments that can be provided to the Azure Container Apps Build and Deploy Azure DevOps Task.

Note: Although no argument is officially marked as "required" in the metadata of this task, some arguments will need to be provided in order for this task to successfully run using one of the two main scenarios.

Argument name Required Description
acrName Yes (for this scenario) The name of the Azure Container Registry that the runnable application image will be pushed to.
appSourcePath Yes (for this scenario) Absolute path on the Azure Pipelines agent of the source application code to be built.

Arguments required for using an already pushed application image

Argument name Required Description
imageToDeploy Yes (for this scenario) The name of the image that has already been pushed to a registry and will be deployed to the Container App by this task. If this image is found in an ACR instance that requires authentication to pull, the acrName argument, or the acrUsername and acrPassword arguments, can be provided to authenticate requests to the ACR instance.

Arguments required for using a YAML configuration file

Argument name Required Description
yamlConfigPath Yes (for this scenario) Full path (on the executing Azure Pipelines agent) to the YAML file detailing the configuration of the Container App.

Important notes on the YAML configuration file

The resourceGroup property in the YAML configuration file will not be used; the value for this either comes from the resourceGroup argument provided to the task, or the default resource group name generated by the task. All other properties provided in the YAML configuration file will override the values provided as arguments to this task; for example, if the containerAppName argument is provided to the task, and the name property is set in the YAML configuration file, the name property in the YAML file will be used when creating or updating the Container App.

Image and application source arguments (e.g., appSourcePath, imageToDeploy) will still be used to first build and/or push an image that is used by the Container App; in this case, the provided YAML configuration file will need to reference the image specified by imageToDeploy (or imageToBuild, depending on your scenario).

When creating a new Container App, all properties listed in the YAML configuration file (except resourceGroup as mentioned above) will be set when the Container App is created. When updating an existing Container App, only the properties listed in the file will be updated on the Container App.

Currently, the YAML file does not support setting up managed identity authentication for the container registry used; for more information on this issue, please see this GitHub issue.

In cases where the yamlConfigPath argument is provided, the YAML file will be passed through to the corresponding az containerapp command, either create or update depending on your scenario. For more information on the intended behavior when the YAML configuration file is provided, please see the documents linked for the corresponding commands.

For more information on the structure of the YAML configuration file, please visit this site.

Additional arguments

Argument name Required Description
connectedServiceNameARM Yes Service connection linked to the user's Azure Subscription where the Container App will be created/updated. This service connection must have proper permissions to make these changes within the subscription (e.g., Contributor role).
acrUsername No The username used to authenticate push requests to the provided Azure Container Registry. If not provided, an access token will be generated via "az acr login" and provided to "docker login" to authenticate the requests.
acrPassword No The password used to authenticate push requests to the provided Azure Container Registry. If not provided, an access token will be generated via "az acr login" and provided to "docker login" to authenticate the requests.
dockerfilePath No Relative path (without file prefixes, see example below) to the Dockerfile in the provided application source that should be used to build the image that is then pushed to ACR and deployed to the Container App. If not provided, this task will check if there is a file named Dockerfile in the provided application source and use that to build the image. Otherwise, the Oryx++ Builder will be used to create the image.
imageToBuild No The custom name of the image that is to be built, pushed to ACR and deployed to the Container App by this task. Note: this image name should include the ACR server; e.g., <acr-name>.azurecr.io/<repo>:<tag>. If this argument is not provided, a default image name will be constructed in the form of <acr-name>.azurecr.io/ado-task/container-app:<build-id>.<build-number>
containerAppName No The name of the Container App that will be created or updated. If not provided, this value will be ado-task-app-<build-id>-<build-number>.
resourceGroup No The existing resource group that the Azure Container App will be created in. If not provided, this value will be <container-app-name>-rg and its existence will first be checked before attempting to create it.
containerAppEnvironment No The name of the Container App environment to use with the application. If not provided, an existing environment in the resource group of the Container App will be used, otherwise, an environment will be created in the form of <container-app-name>-env.
runtimeStack No The platform version stack used in the final runnable application image that is deployed to the Container App. The value should be provided in the form of <platform>:<version>. If not provided, this value is determined by Oryx based on the contents of the provided application. Please refer to this document for more information on supported runtime stacks for Oryx.
targetPort No The designated port for the application to run on. If no value is provided and the builder is used to build the runnable application image, the target port will be set to 80 for Python applications and 8080 for all other platform applications. If no value is provided when creating a Container App, the target port will default to 80. Note: when using this task to update a Container App, the target port may be updated if not provided based on changes to the ingress property.
location No The location that the Container App (and other created resources) will be deployed to. To view locations suitable for creating the Container App in, please run the following: az provider show -n Microsoft.App --query "resourceTypes[?resourceType=='containerApps'].locations"
environmentVariables No A list of environment variable(s) for the container. Space-separated values in 'key=value' format. Empty string to clear existing values. Prefix value with 'secretref:' to reference a secret.
ingress No Possible options: external, internal, disabled. If set to external (default value if not provided when creating a Container App), the Container App will be visible from the internet or a VNET, depending on the app environment endpoint configured. If set to internal, the Container App will be visible from within the app environment only. If set to disabled, ingress will be disabled for this Container App and will not have an HTTP or TCP endpoint.
disableTelemetry No If set to true, no telemetry will be collected by this Azure DevOps Task. If set to false, or if this argument is not provided, telemetry will be sent to Microsoft about the Container App build and deploy scenario targeted by this Azure DevOps Task.

Usage

Below are a set of examples outlining how to use this task in different scenarios.

Minimal - Build application image for Container App

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      acrName: 'mytestacr'

This will create a new Container App named ado-task-app-<build-id>-<build-number> in a new resource group named <container-app-name>-rg. The Container App will be based off of an image that was built from the provided appSourcePath and pushed to the provided ACR instance. An access token will be generated to authenticate the push to the provided ACR instance.

Minimal - Use previously published image for Container App

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      imageToDeploy: mcr.microsoft.com/azuredocs/containerapps-helloworld:latest

This will create a new Container App named ado-task-app-<build-id>-<build-number> in a new resource group named <container-app-name>-rg where no new image is built, but an existing image named mcr.microsoft.com/azuredocs/containerapps-helloworld:latest will be used for the Container App.

Minimal - Use YAML configuration file with previously published image for Container App

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      yamlConfigPath: simple-image-container-app.yaml

This will create a new Container App named ado-task-app-<build-id>-<build-number> in a new resource group named <container-app-name>-rg where no new image is built, but an existing image named mcr.microsoft.com/azuredocs/containerapps-helloworld:latest will be used for the Container App. Additional properties about the Container App will be pulled from the simple-image-container-app.yaml file and will override any additional values that would've been provided to the task as arguments excluding resourceGroup.

The simple-image-container-app.yaml file has the following structure:

properties:
  managedEnvironmentId: /subscriptions/SUBSCRIPTION_ID/resourceGroup/RESOURCE_GROUP/providers/Microsoft.App/managedEnvironments/CONTAINER_APP_ENVIRONMENT
  configuration:
    ingress:
      external: true
      allowInsecure: false
      targetPort: 80
  template:
    containers:
      - image: mcr.microsoft.com/azuredocs/containerapps-helloworld:latest
        name: mysampleimagecontainer

The values for SUBSCRIPTION_ID, RESOURCE_GROUP and CONTAINER_APP_ENVIRONMENT must be updated to point to the full resource ID of the existing Container App environment that the Container App will use.

Using ACR credentials to authenticate

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      acrName: 'mytestacr'
      acrUsername: $(ACR_USERNAME_SECRET)
      acrPassword: $(ACR_PASSWORD_SECRET)

This will create a new Container App named ado-task-app-<build-id>-<build-number> in a new resource group named <container-app-name>-rg. The Container App will be based off of an image that was built from the provided appSourcePath and pushed to the provided ACR instance. The provided ACR credentials will be used to authenticate calls to the ACR instance.

Container App name provided

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      acrName: 'mytestacr'
      containerAppName: 'my-test-container-app'

This will create a new Container App named my-test-container-app in a new resource group name my-test-container-app-rg.

Resource group provided

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      acrName: 'mytestacr'
      resourceGroup: 'my-test-rg'

This will create a new Container App named ado-task-app-<build-id>-<build-number> in a resource group named my-test-rg. If the my-test-rg resource group does not exist, it will be created as a part of this task.

Container App name and resource group provided

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      acrName: 'mytestacr'
      containerAppName: 'my-test-container-app'
      resourceGroup: 'my-test-rg'

This will create a new Container App named my-test-container-app in a resource group named my-test-rg. If the my-test-rg resource group does not exist, it will be created as a part of this task.

Container App environment provided

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      acrName: 'mytestacr'
      containerAppEnvironment: 'my-test-container-app-env'

This will create a new Container App named ado-task-app-<build-id>-<build-number> in a new resource group named <container-app-name>-rg with a new Container App environment named my-test-container-app-env.

Runtime stack provided

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      acrName: 'mytestacr'
      runtimeStack: 'dotnetcore:7.0'

This will create a new Container App named ado-task-app-<build-id>-<build-number> in a new resource group named <container-app-name>-rg where the runnable application image is using the .NET 7 runtime stack.

Dockerfile provided

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      acrName: 'mytestacr'
      dockerfilePath: 'test.Dockerfile'

This will create a new Container App named ado-task-app-<build-id>-<build-number> in a new resource group named <container-app-name>-rg where the runnable application image was created from the test.Dockerfile file found in the provided application source path directory.

Note: for values provided to dockerfilePath, no file prefixes should be included (e.g., ./test.Dockerfile should be passed as just test.Dockerfile). The provided appSourcePath and dockerfilePath arguments will be concatenated inside of the task.

Image to build provided

steps:

  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'azure-subscription-service-connection'
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      acrName: 'mytestacr'
      imageToBuild: 'mytestacr.azurecr.io/app:latest'

This will create a new Container App named ado-task-app-<build-id>-<build-number> in a new resource group named <container-app-name>-rg where the image built and pushed to ACR is named mytestacr.azurecr.io/app:latest

Contributing

This project welcomes contributions and suggestions from all users; however, we advise that any changes made to the AzureContainerAppsRC task be made instead to the AzureContainerApps task, which will later be migrated over to this Release Candidate task and published immediately.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Issues and feedback

For any issues and feedback for the Release Candidate AzureContainerAppsRC task, please create a new issue in this container-apps-deploy-pipelines-task repository.

For any issues and feedback for the official AzureContainerApps task, please create a new issue in the azure-pipelines-tasks repository.

Do you think there might be a security issue? Have you been phished or identified a security vulnerability? Please don't report it here - let us know by sending an email to [email protected].

container-apps-deploy-pipelines-task's People

Contributors

cormacpayne avatar harryli0108 avatar microsoft-github-operations[bot] avatar microsoftopensource avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

container-apps-deploy-pipelines-task's Issues

Azure Container app deploy container to existing app not working

Hi

I am trying to use AzureContainerApps task as mentioned on https://learn.microsoft.com/en-us/azure/container-apps/azure-pipelines to deploy a new container image in the existing container app. But got the error "Error: Unable to create Container App Environment."

We are using a self-hosted Linux agent. Below is YAML

steps:
- task: AzureContainerApps@0
  displayName: 'Azure Container Apps Deploy'
  inputs:
    azureSubscription: 'OUR_SUBSCRIPTION'
    imageToDeploy: 'XXX.azurecr.io/rlb-pulse-api/:$(Build.BuildId)'
    containerAppName: 'conatainer_app_name'
    resourceGroup: 'resource_group_name'
    disableTelemetry: false

We are not creating a new environment, not sure why this task tries to create an environment. However, as per the logs it seems that it it getting wrong location of the resource group. Our current resource group is in Australiaeast instead of westus.

2023-05-26T06:52:28.7898458Z [command]/usr/bin/az provider show -n Microsoft.App --query resourceTypes[?resourceType=='containerApps'].locations[] | [0]
2023-05-26T06:52:29.3898822Z "West US 2"

Unable to provide ImageToDeploy and AcrName for docker token authentication.

It is no longer possible to provide ImageToDeploy and AcrName arguments for a pre built image that requires authentication to access.
According to the documentation, if ImageToDeploy requires authentication, then ArcName can be provided to authenticate to the registry using token authentication (if AcrUserName and AcrPassword are not provided).
This is also in the code:

CA_ADO_TASK_ACR_ACCESS_TOKEN=$(az acr login --name $(acrName)--output json --expose-token --only-show-errors | jq -r '.accessToken');
 docker login acrName.azurecr.io -u 00000000-0000-0000-0000-000000000000 -p $CA_ADO_TASK_ACR_ACCESS_TOKEN > /dev/null 2>&1'.

With the new changes made, both appSourcePath and acrName are now required together. When these 2 are provided, the tasks attempts to builds the image from source and deploys to the registry.

This does not seem like an intended change. It should be that if appSourcePath is provided, then acrName is required, but if acrName is provided, appSourcePath is not required.

Cannot use Container apps deploy task with background service

I have a background service worker that I've dockerized and pushed to Azure Container Registry. I've found that I cannot use the container app deploy task in my pipeline because the task has a default for targetPort which updates the app to have an ingress. When the app has an ingress, a new revision is unable to finish provisioning. I suspect there is some background probe even though the container settings have all probes disabled.

If I disable ingress on the container app for my background worker and deploy to the container app with the Azure CLI containerapp command, then my app will complete it's provisioning and be available.

Perhaps I need to add some custom health check to my background service, but I'm wondering if the container-app-deploy-task can be updated to work with apps which do not have an ingress?

Multiple Projects in Solution with .Net SDK Build

Hi, I am hoping you can help.

I have 3 projects in my solution. 2 projects that contain .net core apis that I wish to push to ACA and a 3rd common project that are referenced by both. However, I cant work out the correct syntax to use build and deploy one of these apis to ACA.
I have tried to set the
1-To set the appSourcePath to be the root of the solution but got the below error
Error: Ambiguity in selecting a project to build. Found multiple projects
2-To set the appSourcePath to be the folder containing one of the projects I want to build as a container but got an error as the
common .csproj could not be found
Skipping project "/xxx.csproj" because it was not found
error CS0234: The type or namespace name 'xxx' does not exist in the namespace 'xxxx' (are you missing an assembly reference?)
3-To set the dockerfilePath to be the folder containing the project that I wish to build into a container. However, not unexpectedly, I get an error that states that it is a directory and not a file. I am wanting to build without using a dockerfile and instead using a .net sdk build.

Hopefully, I am just missing something and you can point me in the right direction. Otherwise could I request an enhancement that a new input be added that works like the dockerfilePath so that I can define which project is to be built if there are multiple

Any help greatly received

Add support for images from docker hub

It would be cool to have support for images from docker hub.

I could imagine that to look something like this (for public images):

- task: AzureContainerAppsRC@0
  inputs:
    azureSubscription: 'azureSubscription'
    imageToDeploy: 'docker.io/user/image:$(Build.BuildId)'
    useDockerHub: true
    containerAppName: 'containerAppName'
    resourceGroup: 'resourceGroup'

Using docker hub could be implied by the imageToDeploy and/or the missing acrName and/or a useDockerHub property.

imageToBuild seems to be ignored

Hi all,

In the build phase i keep getting the following message and the default image name is being used:

No imageToBuild argument was provided; setting the image to be built to '***.azurecr.io/ado-task/container-app:43.20240409.12'.
No imageToDeploy argument was provided; setting the image to deploy to '***.azurecr.io/ado-task/container-app:43.20240409.12'.

imageToBuild is being used in the pipeline config, but it doesnt like it's being picked up:

trigger:
- master
pool:
  vmImage: ubuntu-latest
steps:
  - task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: 'arm-service-connection-dev'
      acrName: 'xxx'
      dockerfilePath: 'xxx.Test.Api/Dockerfile'
      imageToBuild:: 'xxx.azurecr.io/xxx.test.api:234'
      acrUsername: $(ACR_USERNAME_SECRET)
      acrPassword: $(ACR_PASSWORD_SECRET)
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      resourceGroup: 'rg-aca-dev-001'
      containerAppEnvironment: 'xxx'

Tagging @harryli0108

Is supporting the Java runtime stack on the roadmap?

Is supporting the Java runtime stack on the roadmap? I noticed that Java is not in the list of supported Oryx versions that can be pulled from MCR.

Before I was aware of the Java limitation, I tried to deploy a Java-based image and got the following error:

ERROR: failed to build: invalid run-image 'mcr.microsoft.com/oryx/:': invalid reference format

I also noticed this in the log:

No runtimeStack argument was provided; using the runtime stack that was found for the app ':'.

More context:

Status: Downloaded newer image for cormtestacr.azurecr.io/oryx/cli:latest
:
/usr/bin/bash -c rm /agent/_work/1/my/oryx-runtime.txt
No runtimeStack argument was provided; using the runtime stack that was found for the app ':'.
No Dockerfile was provided or found for the application source; attempting to create a runnable application image using the Oryx++ Builder.
/usr/local/bin/pack config default-builder cormtestacr.azurecr.io/builder:latest
Builder 'cormtestacr.azurecr.io/builder:latest' is now the default builder
/usr/local/bin/pack build mylabcr.azurecr.io/mytag:latest --path /agent/_work/1/my --builder cormtestacr.azurecr.io/builder:latest --run-image mcr.microsoft.com/oryx/: --env CALLER_ID=azure-pipelines-v0
ERROR: failed to build: invalid run-image 'mcr.microsoft.com/oryx/:': invalid reference format

An error message indicating that I attempted to use an unsupported runtime stack would have been helpful to me.

Provide option to provide log destination when creating container apps environment

This is my setup

  - task: AzureContainerApps@1
    inputs:
      appSourcePath: '$(Build.SourcesDirectory)/src'
      azureSubscription: '$(azureSubscription)'
      acrName: '$(acrName)'
      resourceGroup: '$(resourceGroup)'
      location: '$(location)'

When i provide the above and run the pipeline i get the following error

2023-07-25T12:26:46.9172078Z [command]/usr/bin/az containerapp env create -n ado-task-app-155-20230725-7-env -g xxxx -l eastus2
2023-07-25T12:26:48.6034004Z WARNING: No Log Analytics workspace provided.
2023-07-25T12:26:48.6035077Z WARNING: Generating a Log Analytics workspace with name "workspace-xxxx"
2023-07-25T12:26:48.6036673Z ERROR: (AuthorizationFailed) The client 'xxxxxxxxx' with object id 'xxxxxxxx' does not have authorization to perform action 'Microsoft.OperationalInsights/workspaces/write' over scope '/subscriptions/xxxxxxx/resourcegroups/xxxxxx/providers/Microsoft.OperationalInsights/workspaces/workspace-xxxxxx' or the scope is invalid. If access was recently granted, please refresh your credentials.
2023-07-25T12:26:48.6037574Z Code: AuthorizationFailed
2023-07-25T12:26:48.6038818Z Message: The client 'xxxxxx' with object id 'xxxxxx' does not have authorization to perform action 'Microsoft.OperationalInsights/workspaces/write' over scope '/subscriptions/xxxxxxx/resourcegroups/xxxx/providers/Microsoft.OperationalInsights/workspaces/workspace-xxxxx' or the scope is invalid. If access was recently granted, please refresh your credentials.

I had a look a the az containerapp env create commands and for log destination if a value is not provided(in this case) the default selected is log-analytics.
https://learn.microsoft.com/en-us/cli/azure/containerapp/env?view=azure-cli-latest#az-containerapp-env-create

--logs-destination
Logs destination.

accepted values: azure-monitor, log-analytics, none
default value: log-analytics

At the moment a workaround is i gave the service principal permission to create the log analytics workspace and i'm fairly okay with it. Especially because has an associated cost it would be good to provide an option to not provide it

Unable to deploy to Container Apps

I am trying to deploy an image from DockerHub. Is this supported? I am getting the same error that others are having. I created a service connection to it and can push an image, but I run into problems when I try to deploy a new container version. I have connections to ARM and Dockerhub set up and verified.

ERROR: (InvalidParameterValueInContainerTemplate) The following field(s) are either invalid or missing. Field 'template.containers.album-backend-api.image' is invalid with details: 'Invalid value: "adamcodes716/album-backend-api:13": GET https:: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:adamcodes716/album-backend-api Type:repository]]';.
##[error]Error: Unable to update Azure Container App via 'az containerapp update' command.
##[debug]Processed: ##vso[task.issue type=error;]Error: Unable to update Azure Container App via 'az containerapp update' command.
- stage: Deploy
  displayName: Deploy to Container Apps
  jobs:
  - job: Deploy
    displayName: Deploy
    pool:
      vmImage: ubuntu-latest
    steps:

    - task: AzureContainerApps@1
      displayName: Deploy new container version
      inputs:
        azureSubscription: 'azure-connection'
        imageToDeploy: '$(IMAGE_NAME):$(TAG)'
        containerAppName: '$(CONTAINERAPPS_APP)'
        resourceGroup: '$(RESOURCE_GROUP)'
        containerAppEnvironment: '$(CONTAINERAPPS_ENVIRONMENT)'
        targetPort: '3500'
        ingress: 'external'

[enhancement] Ability to Specify AZ containerapp Command in AzureContainerApps@1 Task

I am creating a pipeline and using this task to create/update my containers. However, due to a bug in the az containerapp up command of AZ CLI, I am unable to use only one Azure Container Registry (ACR), for example, if I have 2 subscription I need to have 2 ACRs. Would it be possible to add support for allowing me to specify which az containerapp command I want to use?

Cannot run AzureContainerAppsV0 tasks on Win32 agents

I'm unable to run this task on a Windows agent due to a dependency on bash. Please create a pwsh invocation for the same with a Win32 check and download package

Starting: AzureContainerAppsRC
==============================================================================
Task         : Azure Container Apps Deploy (Release Candidate)
Description  : An Azure DevOps Task to build and deploy Azure Container Apps.
Version      : 0.1.7
Author       : Microsoft Corporation
Help         : [Learn more about this task](http://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/AzureContainerAppsV0/README.md)
==============================================================================
##[error]`Unable to run provided bash command '(curl -sSL "[https://github.com/buildpacks/pack/releases/download/v0.27.0/pack-v0.27.0-linux.tgz"](https://github.com/buildpacks/pack/releases/download/v0.27.0/pack-v0.27.0-linux.tgz%22) | tar -C /usr/local/bin/ --no-same-owner -xzv pack)'.
##[error]Unable to install pack CLI.
##[error]Unable to locate executable file: 'bash'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also verify the file has a valid extension for an executable file.
Finishing: AzureContainerAppsRC

FQDN output

Greetings,

This is more of a question regarding approach and whether there's a way to get the FQDN using this task. It doesn't appear to be the case so I've also tried using a AzurePowerShell@5 task like so but that results in the error:

- task: AzurePowerShell@5
          inputs:
            azureSubscription: 'm445435'
            ScriptType: 'InlineScript'
            Inline: '(Get-AzContainerApp -Name workbench -ResourceGroupName $vResourceGroup).IngressFqdn'
            azurePowerShellVersion: 'LatestVersion'

Get-AzContainerApp: /home/vsts/work/_temp/ebff7ec8-4ee1-446d-8018-5911ebc58d17.ps1:5
Line |
   5 |  (Get-AzContainerApp -Name workbench -ResourceGroupName $vResourceGrou …
     |   ~~~~~~~~~~~~~~~~~~
     | The term 'Get-AzContainerApp' is not recognized as a name of a cmdlet,
     | function, script file, or executable program. Check the spelling of the
     | name, or if a path was included, verify that the path is correct and try
     | again.

Thanks!

Why task is downloading aditional code?

I run this task as a step within a pipeline which is using self-hosted agent (Ubuntu). Task crashes with log:

Unable to run provided bash command '(
curl -sSL "https://github.com/buildpacks/pack/releases/download/v0.27.0/pack-v0.27.0-linux.tgz" | tar -C /usr/local/bin/ --no-same-owner -xzv pack)'.
##[error]Unable to install pack CLI.
##[error]The process '/bin/bash' failed with exit code 2

After digging to your code I saw this.

Don't understand why it was done this way and I don't like this.
IMHO please add prerequisites entry about Cloud Native Buildpacks and in your code just check if package is aviable.

Error when creating the container app

Hi,

I've got an error when using the task and if the application container is not already created. These are the inputs for the task:

  - task: AzureContainerApps@1
    inputs:
      azureSubscription: ${{ parameters.service_connection }}
      acrName: $(acr_name)
      appSourcePath: '$(System.DefaultWorkingDirectory)'
      dockerfilePath: docker/conf/Dockerfile
      imageToBuild: '$(acr_name).azurecr.io/$(conf):$(build.buildid)'
      containerAppName: $(conf)
      resourceGroup: $(resource_group)
      containerAppEnvironment: $(container_app_environment)
      location: $(location)
      ingress: external
      environmentVariables: 'OPENAI_API_BASE=$(OPENAI_API_BASE)'

The error comes when the task tries to execute the following command:

[command]/usr/bin/az containerapp create -n conf -g rg-i xxx.azurecr.io/conf:222173 --environment conf_environment --target-port 8080   
ERROR: (InvalidParameterValueInContainerTemplate) The following field(s) are either invalid or missing. Field 'template.containers.conf.image' is invalid with details: 'Invalid value: "xxx.azurecr.io/conf:222173": GET https:?scope=repository%3Aconf%3Apull&service=xxx.azurecr.io: UNAUTHORIZED: authentication required, visit https://aka.ms/acr/authorization for more information.';.
##[error]Error Code: [1]
##[error]Error: Unable to create Azure Container App via 'az containerapp create' command.

I tested the command on my dev machine, and I got the same result. But I've got it working when adding the parameter --registry-server to the command:

az containerapp create -n conf -g rg -i xxx.azurecr.io/conf:222173 --environment conf_environment --ingress external --target-port 8080 --env-vars OPENAI_API_BASE=https://api.com/ --registry-server xxx.azurecr.io

Can't seem to deploy a container from an ACR outside of the sub with credentials

Hi,

We have an ACR in a totally different subscription to the ACA environment. For example

Subscription: Shared Services
RG: rg-sharedservices
ACR: acrsharedservices.azurecr.io

Subscription: MyApplication
RG: rg-myapp
Env: aca-myenv-myapp
ImageToDeply: acrsharedservices.azurecr.io/mycompany.myapp:1.0

This is because a couple of reasons:

  • You look for the acr inside the sub passed in for the ACA when
  • We cant use ACR username and ACR password without acrname because it tries to login to undefined.azureacr.io
  • We cant set the env variable of CA_ADO_TASK_ACR_ACCESS_TOKEN with the key without a login failure

Here's the various combos we've tried:

- task: AzureContainerAppsRC@0
    displayName: "Deploying Container"
    env:
      CA_ADO_TASK_ACR_ACCESS_TOKEN: "{{parameters.acrAccessKey}}"
    inputs:
      azureSubscription: "${{parameters.appServiceConnectionName}}"
      acrName: "${{parameters.acrName}}"
      # acrUsername: "${{parameters.acrUserName}}"
      # acrPassword: "${{parameters.acrAccessKey}}"
      containerAppName: "${{parameters.containerAppName}}"
      containerAppEnvironment: "${{parameters.containerAppEnvironment}}"
      imageToDeploy: "${{parameters.acrName}}.azurecr.io/${{parameters.containerName}}:${{parameters.containerTag}}"
      targetPort: "443"

Extend task to support single revision with suffix

Hi,

It would be great to support scenario, where single revision is used for the Azure Container App. In this case we could specify the "revisionSuffix" together with the image from the Azure Container Registry, here is example:

  - task: AzureContainerApps@0
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: connection-to-azure
      acrName: 'acrazure'
      containerAppName: 'test-aca'
      imageToBuild: 'mytestacr.azurecr.io/app:latest'
      revisionSuffix: $(Build.BuildId)

This would enable scenario where we can define revision suffix and also indicate which Docker image to use from the container registry.

Deployment is not working when there are multiple containers in a container app

Description

When updating a container app with multiple containers you have to specify which container you want to update via --container-name. This settings is not available in the task for azure container apps.

Expected Behavior

Azure pipelines via azure container apps task are working for apps with multiple containers

Actual Behavior

The task stops with the following error message:

/usr/bin/az containerapp update -n *** -g *** -i ***/imagename:v1
ERROR: Usage error: --container-name is required when adding or updating a container
##[error]Error Code: [1]
##[error]Error: Unable to update Azure Container App via 'az containerapp update' command.

Steps to Reproduce the Problem

  1. Create container app env and container app
  2. Deploy second container via: az containerapp update -n mytest -g myrg -i nginx
  3. Update the container via azure container apps task

Unable to update Azure Container App via 'az containerapp update' command

I have a .net (api) solution comprised of a few projects setup as a container app. I can build and run locally all fine.

I am using AzureContainerAppsRC@1 with the following yaml

steps:
- task: AzureContainerAppsRC@1
  displayName: Build and deploy Container App XXXXXXProcessor
  inputs:
    connectedServiceNameARM: 'XXXXXX_AzureResourceManager_Staging'
    runtimeStack: mcr.microsoft.com/oryx/dotnetcore:6.0
    appSourcePath: '$(Build.SourcesDirectory)'    
    acrName: 'xxxxxxappstagingcontainerregistry'    
    containerAppName: 'xxxxxxprocessor-staging'
    resourceGroup: 'rg-WUS-XXXXXX-General-Staging'

When running this pipeline, it builds all fine however it appears that there is issue updating the container app xxxxxxprocessor-staging when the pipeline log shows the failure

ERROR: (WebhookInvalidParameterValue) The following field(s) are either invalid or missing. Invalid value: "xxxxxxappstagingcontainerregistry.azurecr.io/ado-task/container-app:31422.20230412.11": GET https:?scope=repository%3Aado-task%2Fcontainer-app%3Apull&service=xxxxxxappstagingcontainerregistry.azurecr.io: **UNAUTHORIZED: authentication required,** 
visit https://aka.ms/acr/authorization for more information.: template.containers.simple-hello-world-container.image.
##[error]Error Code: [1]
##[error]Error: Unable to update Azure Container App via 'az containerapp update' command.

I have setup XXXXXX_AzureResourceManager_Staging (to be a contributor in this resource group) but still seeing this issue.

What context is this running in? (I assumed it was XXXXXX_AzureResourceManager_Staging which is the azure resource manager)

When I created the container app, i selected the sample hello world app "simple-hello-world-container".

The pipeline above would put in another container app (is there some name conflict) as I am pushing in new app into the container?

appSourcePath and dockerfilePath join not working

Used version 0.1.7 and was able to correctly specify both path and dockerpath with a specific name
ex yaml:
appSourcePath: '$(Build.SourcesDirectory)'
dockerfilePath: 'my-component.dockerfile'
(my-component.dockerfile is in the root folder)

With version 0.1.9 instead:
appSourcePath: '$(System.DefaultWorkingDirectory)'
dockerfilePath: 'my-component.dockerfile'
the result is: "A Dockerfile was provided or found for the application source; attempting to build the image from Dockerfile '/home/vsts/work/1/s/home/vsts/work/1/s/my-component.dockerfile'"
it seems to merge the absolute path of the docker file with appSourcePath

So, to make it work i have to specify:
appSourcePath: './'
dockerfilePath: 'my-component.dockerfile'

The documentation is misleading. Should I use $(System.DefaultWorkingDirectory) (and therefore there is a bug) or should the documentation just be updated?

Enhancement request: Add parameter to specify container name

Would it be possible to add a parameter for specifying the target container?

This would support scenarios where a single container app has:

  1. multiple containers
  2. a single container that is named differently than the container app

The task appears to assume that the target container app will contain a single container named the same as the container app itself. So, when I run the task against container app "X" that has a single container "Y", it creates a second container named "X" alongside "Y" rather than updating container "Y"'s image.

Exit code from docker and az cli are ignored

Non-zero exit codes from docker and az should fail this task in the pipeline, however currently they are simply ignored and pipeline is successful. Example output where 2 problems occurred:

Logging in to Azure Container Registry using access token to be generated via Azure CLI.
/usr/bin/bash -c CA_ADO_TASK_ACR_ACCESS_TOKEN=$(az acr login --name xxxacr --output json --expose-token --only-show-errors | jq -r '.accessToken'); docker login xxxacr.azurecr.io -u 00000000-0000-0000-0000-000000000000 -p $CA_ADO_TASK_ACR_ACCESS_TOKEN > /dev/null 2>&1
No imageToDeploy argument was provided; setting the image to deploy to 'xxxacr.azurecr.io/backend:539.20230202.18'.
A Dockerfile was provided or found for the application source; attempting to build the image from Dockerfile '/home/vsts/work/1/s/home/vsts/work/1/s/Dockerfile'.
/usr/bin/docker build --tag xxxacr.azurecr.io/backend:539.20230202.18 --file /home/vsts/work/1/s/home/vsts/work/1/s/Dockerfile /home/vsts/work/1/s
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/vsts/work/1/s/home: no such file or directory
/usr/bin/docker push xxxacr.azurecr.io/backend:539.20230202.18
The push refers to repository [xxxacr.azurecr.io/backend]
An image does not exist locally with the tag: xxxacr.azurecr.io/backend
/usr/bin/az containerapp up --name xxx-api --resource-group xxx1 --image xxxacr.azurecr.io/backend:539.20230202.18 --target-port 8080
WARNING: The command requires the extension containerapp. It will be installed first.
WARNING: The installed extension 'containerapp' is in preview.
WARNING: Using resource group 'xxx1'
WARNING: Using ContainerAppEnvironment 'xxx-managedEnvironment' in resource group xxx1
WARNING: Updating Containerapp xxx-api in resource group xxx1
ERROR: (WebhookInvalidParameterValue) The following field(s) are either invalid or missing. Invalid value: "xxxacr.azurecr.io/backend:539.20230202.18": GET https:: MANIFEST_UNKNOWN: manifest tagged by "539.20230202.18" is not found; map[Tag:539.20230202.18]: template.containers.xxx-api.image.
/usr/bin/az account clear
Finishing: Deploy to Container App

First problem is here
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/vsts/work/1/s/home: no such file or directory
this is an exit code 1 from docker.

Second problem is here
ERROR: (WebhookInvalidParameterValue) The following field(s) are either invalid or missing. Invalid value: "xxxacr.azurecr.io/backend:539.20230202.18": GET https:: MANIFEST_UNKNOWN: manifest tagged by "539.20230202.18" is not found; map[Tag:539.20230202.18]: template.containers.xxx-api.image.

Staging vs. Production etc. how to set environment variable

I am using the following pipeline to deploy asp.net api to container. The solution builds a dockerfile.

I have 2 environments (and container app in production and same one in staging).

What is the best approach to ensure ASPNETCORE_ENVIRONMENT variable is set as Staging or Production with each deployment?

a) do i setup a docker file for each environment and 2 pipelines?
b) do i set environment variable within the azure container app resource?
c) can I use the same pipeline and set some variable with each

The goal is to setup easiest approach for setting this environment variable as part of the deployment preferrably? (setting a container app env variable is very manual)

steps:

  • task: AzureContainerAppsRC@1
    displayName: Build and deploy Container App XXXXXXProcessor
    inputs:
    connectedServiceNameARM: 'XXXXXX_AzureResourceManager_Staging'
    runtimeStack: mcr.microsoft.com/oryx/dotnetcore:6.0
    appSourcePath: '$(Build.SourcesDirectory)'
    acrName: 'xxxxxxappstagingcontainerregistry'
    containerAppName: 'xxxxxxprocessor-staging'
    resourceGroup: 'rg-WUS-XXXXXX-General-Staging'

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.