az containerapp update -n hellocustomuser -g mygroupname \
    --image toolongregistryname.azurecr.io/hello-world:4cb5f89 \
    --secrets mypassword=verysecurepassword \
    --registry-login-server toolongregistryname.azurecr.io \
    --registry-username MYGUIDab-4a32-11ec-ba16-00155dbf35bc \
    --registry-password **********************************

Invalid value: "toolongregistrynameazurecrio-MYGUIDab-4a32-11ec-ba16-00155dbf35bc": Length must be no more than 63 characters: configuration.secrets.

So using Azure Container Registry along with a service principal login (which unfortunately uses a guid as username) the naming scheme takes up 46 characters by default, leaving only 16 characters max for the registry name, which in my test case was exceeded by a few characters.

Hi,

Any changes to the az cli in GitHub actions agents lately? Suddenly started getting the error below when doing az containerapp update in an action. The azure/login@v1 step succeds just fine. It's only the az containerapp update which fails.

ERROR: Could not retrieve credential from local cache for service principal . Please run 'az login' for this service principal.

Is there a plan to support Azure Functions like you do on AKS w/ KEDA?

Container Apps should include support for ephemeral volumes so that secrets from external vaults like hashicorp vault or azure key vault can be stored. This also applies to any configuration files/static content needed for the container app.

These volumes will be used for sharing data between init/sidecar container and main container.

To allow use cases where app runs on root and api's run on /api/apix.

API config:
{
...
"configuration": {
"ingress": {
"external": false,
"targetPort": 80,
"transport": auto,
"path": "/api/apix"
}
}
}

root config:
{
...
"configuration": {
"ingress": {
"external": true,
"targetPort": 80,
"transport": auto,
"path": "/"
}
}
}

For my custom applications I would like to ensure metrics scrapping of my own metrics endpoints in the application (see https://docs.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-prometheus-integration).

End goal would be to gain observability into my applications on both technical and business metrics.

Really awesome offering, but I'm wondering how can manage revisions via CLI.

Use Case: PR & Preview Deployments where we want to create (and later delete) a revision with each PR create / delete

Issue Description:

The default github workflow include these lines:
      - name: Checkout to the branch
        uses: actions/checkout@v2
        **with:
          path: main**

the lines to point to the "main" path generate an error when to build and push the docker images is required to use the context, anyway is not clear why there is this configuration at checkout time. Moreover I assume that this is related to this config:

in which the branch should be used to configure the trigger and which branch to point during the deployment time.

Desired Behavihour:
The out of the box github workflow should avoid to point to the path.

As far as I have tested, with traffic splitting, reloading randomly accesses a different revision. To achieve A/B testing, the same user is required to access the same revision, thus session affinity is necessary.

Do you have any plans to support it?

We have been using AKS Pod Identity for accessing Azure Services using AAD authentication. Adding support for User Managed Identity will simplify moving existing workloads on AKS to Azure Container Apps.

Provide support for emitting metrics through OpenTelemetry which are made available as custom metrics.

Might relate to #26

Every time I update the new image, it will replace it from the old to the latest version.
At that time, during the start-up time(during provisioning) of the new image, it stops receiving the new request from outside.
And new version may have some technical issues. The user may not want to show the issue to end-users.

At that time, if we can update the new image with traffic weight 0, we may solve the issue.

However, now it may be difficult to execute like this.
Because during the update of the new image, we can’t understand the new revision name look like follows.

Run az containerapp update --name name --resource-group rg-name --image test.azurecr.io/imagename:6 --target-port 8080 --traffic-weight 0
az containerapp update --name name --resource-group rg-name --image test.azurecr.io/imagename:6 --target-port 8080 --traffic-weight 0
shell: /usr/bin/bash -e 0
env:
DOCKER_CONFIG: /home/runner/work/_temp/docker_login_1635950822126
JAVA_HOME_11.0.13_x64: /opt/hostedtoolcache/jdk/11.0.13/x64
JAVA_HOME: /opt/hostedtoolcache/jdk/11.0.13/x64
JAVA_HOME_11_0_13_X64: /opt/hostedtoolcache/jdk/11.0.13/x64
AZURE_HTTP_USER_AGENT:
AZUREPS_HOST_ENVIRONMENT:
WARNING: Command group 'containerapp' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
ERROR: --traffic-weight: must be in format "=,=,..."

Are there plans to support monitoring of revisions via Health Checks similar to App Service (https://docs.microsoft.com/en-us/azure/app-service/monitor-instances-health-check)?

I can't get autoscaling to work with the KEDA azure-pipelines scaler. Here's my bicep configuration.

resource container_app 'Microsoft.Web/containerApps@2021-03-01' = {
  name: 'mycontainerapp'
  location: 'eastus'
  properties: {
    kubeEnvironmentId: container_app_environment.id
    configuration: {
      activeRevisionsMode: 'single'
      secrets: [
        {
          name: azure_devops_url_secret_name
          value: azure_devops_url
        }
        {
          name: azure_devops_pool_name_secret_name
          value: azure_devops_pool_name
        }
        {
          name: azure_devops_token_secret_name
          value: azure_devops_token
        }
        {
          name: container_registry_password_secret_name
          value: container_registry.listCredentials().passwords[0].value
        }
      ]
      registries: [
        {
          server: container_registry.properties.loginServer
          username: container_registry.listCredentials().username
          passwordSecretRef: container_registry_password_secret_name
        }
      ]
    }
    template: {
      containers: [
        {
          image: '${container_registry.properties.loginServer}/repo:123'
          name: 'mycontainerapp'
          env: [
            {
              name: 'AZP_URL'
              secretRef: azure_devops_url_secret_name
            }
            {
              name: 'AZP_TOKEN'
              secretRef: azure_devops_token_secret_name
            }
            {
              name: 'AZP_POOL'
              secretRef: azure_devops_pool_name_secret_name
            }
          ]
        }
      ]
      scale: {
        minReplicas: 1
        maxReplicas: 10
        rules: [
          {
            name: 'azure-pipelines'
            custom: {
              type: 'azure-pipelines'
              metadata: {
                poolId: azure_devops_pool_id
                targetPipelinesQueueLength: '1'
              }
              auth: [
                {
                  triggerParameter: 'organizationURL'
                  secretRef: azure_devops_url_secret_name
                }
                {
                  triggerParameter: 'personalAccessToken'
                  secretRef: azure_devops_token_secret_name
                }
              ]
            }
          }
        ]
      }
    }
  }
}

The container deploys successfully with 1 replica. However, it doesn't scale no matter how many jobs are waiting in the Azure Pipelines queue.

Hi,
May anyone provide an example of a file with scale rules used for example in an update command: az containerapp update --name $CONTAINER_APP_NAME --resource-group $RESOURCE_GROUP --scale-rules scale.yaml?

I've tried using output from az containerapp show --output yaml, but with no success:

scale:
      maxReplicas: 5
      minReplicas: 0
      rules:
      - azureQueue: null
        custom: null
        http:
          auth: null
          metadata:
            concurrentRequests: '1'
        name: httpscale

Thanks in advance

Azure Container Apps seems like a really interesting new service offering from Azure.

The documentation seems to be very dapr oriented. I'm wondering if hosting Orleans inside Azure Container Apps is going to be supported?

The connect multiple apps documentation (https://docs.microsoft.com/en-gb/azure/container-apps/connect-apps?tabs=bash) only mentions HTTP.

Will it be possible to have an Orleans silo host (with multiple instances) as a container app and an Orleans client as another app within the same container app environment.

For Orleans TCP connections on multiple ports would need to be possible, but there are no networking documentation yet.

So my guess right now is, no Orleans is not supported? But it is hard to know with the current documentation.

Hope someone can shed some light on the possibilities and maybe limitations.

Hello,

I'm trying to retrieve secrets from Azure Keyvault using the "secretstores.azure.keyvault" Dapr component.
The application uses the Dapr .NET SDK (1.4.0) and the DaprClient.

When trying to retrieve the secret, DaprClient throws exception.

Dapr.DaprException: Secret operation failed: the Dapr endpoint indicated a failure. See InnerException for details.
at Dapr.Client.DaprClientGrpc.GetSecretAsync(String storeName, String key, IReadOnlyDictionary`2 metadata, CancellationToken cancellationToken)
Grpc.Core.RpcException: Status(StatusCode="Unimplemented", Detail="Not Implemented")

Sometimes we also get connection refused from dapr sidecar.

Grpc.Core.RpcException: Status(StatusCode="Internal", Detail="Error starting gRPC call. HttpRequestException: Connection refused (127.0.0.1:50001) SocketException: Connection refused", DebugException="System.Net.Http.HttpRequestException: Connection refused (127.0.0.1:50001)

I can see in the dapr logs that the component is successfully loaded by the sidecar and no errors are reported there.
The secret store configuration works when running locally using Docker Compose and Dapr.

Is the secretstores.azure.keyvault currently not supported?

See attached ARM template used for deployment.

Best regards
Henrik

{
    "$schema": "https://schema.management.azure.com/schemas/2019-08-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "location": {
            "type": "String"
        },
        "environment_name": {
            "type": "String"
        }
    },
    "variables": {},
    "resources": [
        {
            "name": "myservice",
            "type": "Microsoft.Web/containerApps",
            "apiVersion": "2021-03-01",
            "kind": "containerapp",
            "location": "[parameters('location')]",
            "properties": {
                "kubeEnvironmentId": "[resourceId('Microsoft.Web/kubeEnvironments', parameters('environment_name'))]",
                "configuration": {
                    "ingress": {
                        "external": true,
                        "targetPort": 80
                    },
                    "secrets": [
                        {
                            "name": "container-registry-password",
                            "value": "**"
                        },
                        {
                            "name": "azure-client-secret",
                            "value": "**"
                        }
                    ],
                    "registries": [
                        {
                            "server":"myregistry.azurecr.io",
                            "username":"myregistryusername",
                            "passwordSecretRef":"container-registry-password"
                        }
                    ]
                },
                "template": {
                    "containers": [
                        {
                            "image": "myregistry.azurecr.io/myservice:latest",
                            "name": "myservice",
                            "env": [
                                {
                                    "name": "SECRETSTORE_NAME",
                                    "value": "secret-store"
                                }
                            ],
                            "resources": {
                                "cpu": 0.5,
                                "memory": "1Gi"
                            }
                        }
                    ],
                    "scale": {
                        "minReplicas": 1,
                        "maxReplicas": 1
                    },
                    "dapr": {
                        "enabled": true,
                        "appPort": 80,
                        "appId": "myservice",
                        "components": [
                            {
                                "name": "secret-store",
                                "type": "secretstores.azure.keyvault",
                                "version": "v1",
                                "metadata": [
                                    {
                                        "name": "vaultName",
                                        "value": "thevaultname"
                                    },
                                    {
                                        "name": "azureTenantId",
                                        "value": "**"
                                    },
                                    {
                                        "name": "azureClientId",
                                        "value": "**"
                                    },
                                    {
                                        "name": "azureClientSecret",
                                        "secretRef": "azure-client-secret"
                                    }
                                ]
                            }
                        ]
                    }
                }
            }
        }
    ]
}

Hi,
I'm trying to automate a pipeline to deploy container apps using a private ACR repo. I'm not being able to pass from authentication to pull the image.

I followed this:
https://t.co/cUqLnVTOwx

It creates everything except the last command because of permissions to pull the image.
"Error details: Code: 90712, ExtendedCode: 90712, Message: Error pulling the container image. Please check the image name or any registry credentials to access if required.."

This script it's being executed in a release pipeline in azure devops.

Are you able to help?

The ability to access environment variables from within the yaml files when used from azure cli would be very helpful.

We are unable/unwilling to store sensitive data in yaml files which get checked into source control, and so only make them available as environment variables. For example the <PasswordGoesHere> placeholder in the yaml file below, but also many other items such as <subscription>, <rg>, <image>, etc..

> az containerapp update --resource-group myresourcegroup --name myappname --yaml app.yaml

app.yaml:

kubeEnvironmentId: /subscriptions/<subscription>/resourceGroups/<rg>/providers/Microsoft.Web/kubeEnvironments/<environment name>
configuration:
  activeRevisionsMode: multiple
  registries:
  - server: myacr.azurecr.io
    username: someuser
    passwordSecretRef: acr-password
  secrets:
  - name: acr-password
    value: <PasswordGoesHere>
template:
  containers:
  - image: myacr.azurecr.io/myimage:tag
    name: myimage
    resources:
      cpu: 0.5
      memory: 1Gi
  scale:
    maxReplicas: 1
    minReplicas: 0

Perhaps the yaml file would allow placeholders ${SUBSCRIPTION} and ${REGISTRY_PASSWORD} which could be replaced by environment variables SUBSCRIPTION and REGISTRY_PASSWORD.

kubeEnvironmentId: /subscriptions/${SUBSCRIPTION}/resourceGroups/<rg>/providers/Microsoft.Web/kubeEnvironments/<environment name>
configuration:
  activeRevisionsMode: multiple
  registries:
  - server: myacr.azurecr.io
    username: someuser
    passwordSecretRef: acr-password
  secrets:
  - name: acr-password
    value: ${REGISTRY_PASSWORD}
template:
  containers:
  - image: myacr.azurecr.io/myimage:tag
    name: myimage
    resources:
      cpu: 0.5
      memory: 1Gi
  scale:
    maxReplicas: 1
    minReplicas: 0

When using the --yaml flag, the yaml fails unless it explicitly defines an activeRevisionsMode. I figured this would be an optional parameter and default to the default (multiple).

# az containerapp create -n my-store -g my-rg --yaml deploy.yaml
type: Microsoft.Web/containerApps
template:
  containers:
  - name: mystore
    image: ghcr.io/jeffhollan/container-app-aspnet:v0.2
kubeEnvironmentId: /subscriptions/xxxxx-xxxx-xxxx/resourceGroups/mechanics-aca/providers/Microsoft.Web/kubeEnvironments/mechanics-aca
configuration:
  ingress:
    external: true
    targetPort: 80

Fails with the following:

The command failed with an unexpected error. Here is the traceback:
'NoneType' object has no attribute 'lower'
Traceback (most recent call last):
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 231, in invoke
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 657, in execute
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 720, in _run_jobs_serially
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 712, in _run_job
File "C:\Users\jehollan.azure\cliextensions\containerapp\azext_workerapp_client_factory.py", line 38, in _polish_bad_errors
raise ex
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 691, in _run_job
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 328, in call
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/command_operation.py", line 121, in handler
File "C:\Users\jehollan.azure\cliextensions\containerapp\azext_workerapp\custom.py", line 423, in update_containerapp
return create_or_update_containerapp_yaml(cmd=cmd, client=client, name=name, resource_group_name=resource_group_name, file_name=yaml, is_update=True, no_wait=no_wait)
File "C:\Users\jehollan.azure\cliextensions\containerapp\azext_workerapp\custom.py", line 168, in create_or_update_containerapp_yaml
if containerapp_def.configuration.active_revisions_mode.lower() == "single":
AttributeError: 'NoneType' object has no attribute 'lower'

# az containerapp create -n my-store -g my-rg --yaml deploy.yaml
type: Microsoft.Web/containerApps
template:
  containers:
  - name: mystore
    image: ghcr.io/jeffhollan/container-app-aspnet:v0.2
kubeEnvironmentId: /subscriptions/xxxxx-xxxx-xxxx/resourceGroups/mechanics-aca/providers/Microsoft.Web/kubeEnvironments/mechanics-aca
configuration:
  activeRevisionsMode: multiple
  ingress:
    external: true
    targetPort: 80

Succeeds

I am having problems at the moment to create any additional revisions or even update the image in the existing revision. Is this supposed to work in the current preview version or am I missing some configuration?

For example my testing use case:

1. I have deployed new containerapp and revision created is using image pulled from ACR (let's say myapp:latest)
2. Execute command az containerapp update -n hello-js-app -g $RESOURCE_GROUP --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest
3. Check revisions from console or from cli and only single revision exist and it is still pointing to the original image.

At the moment, the only way I have found to update newer image version is to tag it with latest, push it to registry and then restart revision. Or then re-create whole containerapp resource with newer image configuration.

As an enterprise customer, having support for AKS like policy initiatives will help ensure security and compliance.

Namely,

• Deny containerapp creation with public endpoint
• Allow containerapp creation using images from allowed registries
• Ensure ContainerApp Environment is integrated with a specific LA workspace

I'd like to take a Docker Compose or Docker Swarm YAML file and deploy it to multiple container apps.

• I'd like any features that are not supported to be configurable via a series of environment variables.
• There should not be any features that are not configurable and no downsides to this approach.
• Docker Compose/Swarm easily connects up containers to each other and gives them simple DNS names to facilitate this. I'd like container apps to be given equally simple DNS names, so they can talk to each other internally without me having to re-configure my app in any way or to give my app any knowledge that its hosted by container apps.

Are there currently plans to allow for the use of custom DNS entries (internal and external domains) on Container Apps?

We are looking for a drop-in replacement for different services that currently can run only on VM or AKS, and the main issue seems to be the support for persistent volumes (mounts) with Azure Disks.

Long story short, we have a few services that can run inside a container but need reliable and performant storage to work properly, e.g. Seq, uptime-kuma.

Since AKS seems to be able to mount an Azure Disk as persistent storage, do you have plans on bring this feature on Container Apps?

For context: those scenario are not currently covered by App Services or ACI because they only support mounting Azure Files / Azure Blobs volumes

Hello,

I am trying to use an existing image from our Azure Container Registry and getting this error message when creating the ContainerApp resource in the Azure Portal. I also tried specifying this image as part of a revision to the ContainerApp but get the same error.

I'm following the quickstart here: https://docs.microsoft.com/en-us/azure/container-apps/get-started?ocid=AID3042118&tabs=bash

And when I get to the point where I need to create a container environment, it is failing with the following message:

~ ❯❯❯ az containerapp env create --name $CONTAINERAPPS_ENVIRONMENT --resource-group $RESOURCE_GROUP --logs-workspace-id $LOG_ANALYTICS_WORKSPACE_CLIENT_ID --logs-workspace-key $LOG_ANALYTICS_WORKSPACE_CLIENT_SECRET --location "westcentralus"
Command group 'containerapp env' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
Error occurred in request., RetryError: HTTPSConnectionPool(host='management.azure.com', port=443): Max retries exceeded with url: /subscriptions/[subscription-id-removed]/resourceGroups/container-apps-quickstart/providers/Microsoft.Web/kubeEnvironments/containerapps-env?api-version=2021-02-01 (Caused by ResponseError('too many 500 error responses'))

As a customer I would like to see metrics on CPU/ memory utilization, thread count, http metrics on the containers or network metrics (request per second, number of http errors...) from the ingress.

We retrieve secrets from hashicorp vault using vault-agent that runs as init/sidecar container. Does Azure Container Apps support running custom sidecar container? Please provide documentation for reference.

Visualization by 'Log Analytics' is very complex.

1. We need a simple screen that shows the real-time log stream

2. Creating a simple command to view the log
   => az containerapp logs ...
   kubectl logs -l app=myapp
   kubectl logs -f deployment/myapp

3. Evaluate compatibility with other tools like 'stern'. We need to view the continuous log.
   https://github.com/stern/stern

Hi,

I did some brief testing of the GitHub action CD approach, and have a question re traffic to revisions. I believe it works as expected with traffic being directed to the latest revision when setting it up OOB. However, I wanted to test setting traffic in the Azure Portal. So i set 100% traffic to an older revision in the UI. After doing that, there was no way to tell it to go back to always direct traffic to the latest revision for subsequent deploys. On new revsions, it would just keep the traffic to the old revision (which is understandable).

So, is there a parameter to az containerapp update to get back to "CD mode" (force traffic to the new revision from the image I'm setting right now)?

Any help appreciated.

Moving to this repo from Azure-Samples/container-apps-store-api-microservice#13 from @harkiratiiit

Please provide us with the following information:

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [X ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Deploy any container in Azure Container App Environment

Any log messages given by the failure

No
I am not able to monitor the container logs. Will we be getting rich telemetry on my hosted container as we get for any PaaS platform? Like Kudu in WebApp where we get a console of instance hosting a webApp.

Expected/desired behavior

More Enriched Logs and Insights and Logs.

OS and Version?

Linux/Windows

Versions

Mention any other details that might be useful

My Team is looking to move away from hosting and managing the Kubernetes cluster and wants to try Azure Container Apps. As we hosted our first container as POC on Container App, we are not able to get insights on the container logs which we can easily access in AKS. Please suggest
Thanks! We'll be in touch soon.

I would like to run grpc servcies with container apps, and so created a grpc service serving http2 cleartext and works with BloomRPC and Insomnia when run locally as docker container. However attempts to connect to the grpc service from public url when the image is deployed as a container app fail with error "14 UNAVAILABLE: TCP Read Failed"(bloom) and "13 Received RST_STREAM with code 2"(insomnia).

I believe I saw it mentioned in a video that via the dapr sidecar that grpc is supported. What's the status of GRPC support in container apps? Can GRPC be access from public url? Only when using dapr sidecar? Only within the subnet?

Being that with Bicep we can create for first time the complete stack for Azure Container Apps, is pending how to automate the deployment of new versions of our containers using Azure DevOps, so it would be great to have a task that helps the deployment using Azure Pipelines, some companies will still be using Azure DevOps so first class support will be appreciated.

I would like the following possible in Container Apps for referencing secrets from a key vault like in Web Apps
https://docs.microsoft.com/en-us/azure/app-service/app-service-key-vault-references#reference-syntax

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)

Hi Team,

I'm trying to pass my parameters as I already use in the docker but it's failing. I have the block called 'app' where I have my internal parameters.

Docker Sample
-e app= 'MyInternalValue=3,myname=true'
-e db= 'Load=true, othervalue=true'

az containerapp create -n $app -g $group -e $appenv -i $myimage --registry-login-server $myimagelogin
--registry-username $acrid --registry-password $acrkey --target-port 80 --ingress 'external' --query configuration.ingress.fqdn -v app='MyInternalValue=3,myname=true'

Result:
Environment variables must be in the format "=,=secretref:,...".

Note:
I believe the rule should not validate my internal value 'MyInternalValue=3,myname=true'

Hi Team

I'm try this command:
az containerapp create --yaml ...

The link is broken
"kubeEnvironmentId is required. Please see https://github.com/microsoft/k4apps/wiki/WorkerApps-ARM-API-Specification for a valid containerapps YAML spec."

Where can I find documentation?

We are looking for Docker replacement for hosting container workloads without the overhead of managing AKS cluster. Any plans to support integration with Customer VNet for deploying isolated workloads as Container Apps? All our services deployed on Azure are strictly accessible only from within Customer network (no Public IP).

TLS is terminated on ingress, and any communication from ingress controller to containerapp could be on plain HTTP. Is there a way to ensure end-to-end encryption in transit?

KEDA supports a pattern of ScaledJobs for containers or jobs that "run to completion". This is especially useful if you are pulling messages from a queue or event source and want to have it run to completion without scaling down

https://keda.sh/docs/2.4/concepts/scaling-jobs/

This could also be merged with the traditional "job" concept - and expose a "manual invoke" ability where you can kick off the job without it being tied to an event with something like az containerapp invoke-job -n myjob --image {}

I want it to have a mechanism like App Services KeyVault Reference.

https://docs.microsoft.com/en-us/azure/container-apps/secure-app?tabs=arm-template
Do you have any plans?

Is there a memory quota for the container runs?

Hi, would it be possible to explain what ingress options existing?

A question I have is : Is it possible to call an app from a private vnet without going through the internet and public endpoint?

This is a pretty weird bug, but I'm a bit stumped. I've been building some samples of calling services over gRPC in different languages. So far I have C#, go, and was working on python when I hit this but that only seems to repro for python. I don't know if it's something with the grpc libraries for python but I figured they call came from the same c++ set of binaries. But regardless, here's the deal. When I try to call the other gRPC service, I get an error that DNS Resolution failed. The DNS that fails is the FQDN of the downstream service.

What's strange is when I debug on my local machine (via code or the same container image), the DNS works fine and the gRPC connection works fine. It's only when the Python container runs in container apps it throws this error. I'm at a bit of a loss.

Steps to repro:

• Deploy the sample solution from here (steps in README) https://github.com/jeffhollan/grpc-sample-python
• Call the https-frontend container at the /hello path
• It throws a 500, logs show a DNS resolution failure

Full stack of the DNS error

debug_error_string = "{"created":"@1637787722.745891337","description":"Resolver transient failure","file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":1324,"referenced_errors":[{"created":"@1637787722.745888337","description":"DNS resolution failed for service: grpc-backend.internal.gentlemushroom-013cdb8d.canadacentral.azurecontainerapps.io:443","file":"src/core/ext/filters/client_channel/resolver/dns/c_ares/dns_resolver_ares.cc","file_line":359,"grpc_status":14,"referenced_errors":[{"created":"@1637787722.745858136","description":"C-ares status is not ARES_SUCCESS qtype=AAAA name=grpc-backend.internal.gentlemushroom-013cdb8d.canadacentral.azurecontainerapps.io is_balancer=0: DNS server returned answer with no data","file":"src/core/ext/filters/client_channel/resolver/dns/c_ares/grpc_ares_wrapper.cc","file_line":698,"referenced_errors":[{"created":"@1637787722.740638244","description":"C-ares status is not ARES_SUCCESS qtype=A name=grpc-backend.internal.gentlemushroom-013cdb8d.canadacentral.azurecontainerapps.io is_balancer=0: DNS server returned answer with no data","file":"src/core/ext/filters/client_channel/resolver/dns/c_ares/grpc_ares_wrapper.cc","file_line":698}]}]}]}"

When using Azure EventHubs there are 32 partitions possible. Would it make sense to allow the max value of maxReplicas to be 32 as well?

With this, each replica could process its own partition?

Add possibility to control the version of dapr used by environment and containerapp.
We want to be able to use the same version in all our environments, as well as our local docker-compose development environment.

Great work on container apps! 👍

I am testing a React + .Net Core 3.1 application on Container Apps and it seems to be working without issues except for persistent file storage. In my local container I was able to mount an Azure file instance by running the container in privileged mode. However I don't see an option in ACA for running the container in privileged mode or connect the container to an Azure files instance.

Are there plans to support this feature?

As a customer I care about zonal resiliency and would like to get automatic zonal distribution of replicas (assuming that I have enough replicas and the DC supports zones).

I would like to create/activate new revisions using the azure cli from within a bitbucket pipelines using a service principal. What role assignments/grant names are necessary for a user to deploy a new revision to container apps?

For example a user to push a new image to azure container registry is "AcrPush". Below is example creating such a principal and role.

> az ad sp create-for-rbac --name MyDeployUser
> az role assignment create --assignee GUIDOFMYDEPLOYUSER --role AcrPush

And here is an example of azure cli command currently used to deploy revisions.

> az containerapp update -n mycontainerappname -g myresourcegroup --image myregistryname.azurecr.io/myapp:mytag