Containers in Azure Container Apps

Azure Container Apps manages the details of Kubernetes and container orchestration for you. Containers in Azure Container Apps can use any runtime, programming language, or development stack of your choice.

Azure Container Apps supports:

• Any Linux-based x86-64 (linux/amd64) container image
• Containers from any public or private container registry
• Optional sidecar and init containers

Features also include:

• Apps use the template configuration section to define the container image and other settings. Changes to the template configuration section trigger a new container app revision.
• If a container crashes, it automatically restarts.

Jobs features include:

• Job executions use the template configuration section to define the container image and other settings when each execution starts.
• If a container exits with a non-zero exit code, the job execution is marked as failed. You can configure a job to retry failed executions.

Configuration

Most container apps have a single container. In advanced scenarios, an app may also have sidecar and init containers. In a container app definition, the main app and its sidecar containers are listed in the containers array in the properties.template section, and init containers are listed in the initContainers array. The following excerpt shows the available configuration options when setting up an app's containers.

{
  "properties": {
    "template": {
      "containers": [
        {
          "name": "main",
          "image": "[parameters('container_image')]",
          "env": [
            {
              "name": "HTTP_PORT",
              "value": "80"
            },
            {
              "name": "SECRET_VAL",
              "secretRef": "mysecret"
            }
          ],
          "resources": {
            "cpu": 0.5,
            "memory": "1Gi"
          },
          "volumeMounts": [
            {
              "mountPath": "/appsettings",
              "volumeName": "appsettings-volume"
            }
          ],
          "probes": [
            {
              "type": "liveness",
              "httpGet": {
                "path": "/health",
                "port": 8080,
                "httpHeaders": [
                  {
                    "name": "Custom-Header",
                    "value": "liveness probe"
                  }
                ]
              },
              "initialDelaySeconds": 7,
              "periodSeconds": 3
            },
            {
              "type": "readiness",
              "tcpSocket": {
                "port": 8081
              },
              "initialDelaySeconds": 10,
              "periodSeconds": 3
            },
            {
              "type": "startup",
              "httpGet": {
                "path": "/startup",
                "port": 8080,
                "httpHeaders": [
                  {
                    "name": "Custom-Header",
                    "value": "startup probe"
                  }
                ]
              },
              "initialDelaySeconds": 3,
              "periodSeconds": 3
            }
          ]
        }
      ]
    },
    "initContainers": [
      {
        "name": "init",
        "image": "[parameters('init_container_image')]",
        "resources": {
          "cpu": 0.25,
          "memory": "0.5Gi"
        },
        "volumeMounts": [
          {
            "mountPath": "/appsettings",
            "volumeName": "appsettings-volume"
          }
        ]
      }
    ]
    ...
  }
  ...
}

Setting	Description	Remarks
image	The container image name for your container app.	This value takes the form of repository/<IMAGE_NAME>:<TAG>.
name	Friendly name of the container.	Used for reporting and identification.
command	The container's startup command.	Equivalent to Docker's entrypoint field.
args	Start up command arguments.	Entries in the array are joined together to create a parameter list to pass to the startup command.
env	An array of name/value pairs that define environment variables.	Use secretRef instead of the value field to refer to a secret.
resources.cpu	The number of CPUs allocated to the container.	See vCPU and memory allocation requirements
resources.memory	The amount of RAM allocated to the container.	See vCPU and memory allocation requirements
volumeMounts	An array of volume mount definitions.	You can define a temporary or permanent storage volumes for your container. For more information about storage volumes, see Use storage mounts in Azure Container Apps.
probes	An array of health probes enabled in the container.	For more information about probes settings, see Health probes in Azure Container Apps.

vCPU and memory allocation requirements

When you use the Consumption plan, the total CPU and memory allocated to all the containers in a container app must add up to one of the following combinations.

vCPUs (cores)	Memory
0.25	0.5Gi
0.5	1.0Gi
0.75	1.5Gi
1.0	2.0Gi
1.25	2.5Gi
1.5	3.0Gi
1.75	3.5Gi
2.0	4.0Gi
2.25	4.5Gi
2.5	5.0Gi
2.75	5.5Gi
3.0	6.0Gi
3.25	6.5Gi
3.5	7.0Gi
3.75	7.5Gi
4.0	8.0Gi

Multiple containers

In advanced scenarios, you can run multiple containers in a single container app. Use this pattern only in specific instances where your containers are tightly coupled.

For most microservice scenarios, the best practice is to deploy each service as a separate container app.

Multiple containers in the same container app share hard disk and network resources and experience the same application lifecycle.

There are two ways to run additional containers in a container app: sidecar containers and init containers.

Sidecar containers

You can define multiple containers in a single container app to implement the sidecar pattern.

Examples of sidecar containers include:

• An agent that reads logs from the primary app container on a shared volume and forwards them to a logging service.

• A background process that refreshes a cache used by the primary app container in a shared volume.

These scenarios are examples, and don't represent the only ways you can implement a sidecar.

To run multiple containers in a container app, add more than one container in the containers array of the container app template.

Init containers

You can define one or more init containers in a container app. Init containers run before the primary app container and are used to perform initialization tasks such as downloading data or preparing the environment.

Init containers are defined in the initContainers array of the container app template. The containers run in the order they're defined in the array and must complete successfully before the primary app container starts.

Container registries

You can deploy images hosted on private registries by providing credentials in the Container Apps configuration.

To use a container registry, you define the registry in the registries array in the properties.configuration section of the container app resource template. The passwordSecretRef field identifies the name of the secret in the secrets array name where you defined the password.

{
  ...
  "registries": [{
    "server": "docker.io",
    "username": "my-registry-user-name",
    "passwordSecretRef": "my-password-secret-name"
  }]
}

Saved credentials are used to pull a container image from the private registry as your app is deployed.

The following example shows how to configure Azure Container Registry credentials in a container app.

{
  ...
  "configuration": {
    "secrets": [
      {
        "name": "docker-hub-password",
        "value": "my-docker-hub-password"
      }
    ],
    ...
    "registries": [
      {
        "server": "docker.io",
        "username": "someuser",
        "passwordSecretRef": "docker-hub-password"
      }
    ]
  }
}

Managed identity with Azure Container Registry

You can use an Azure managed identity to authenticate with Azure Container Registry instead of using a username and password. For more information, see Managed identities in Azure Container Apps.

To use managed identity with a registry, the identity must be enabled in the app and it must be assigned acrPull role in the registry. To configure the registry, use the managed identity resource ID for a user-assigned identity, or system for the system-assigned identity in the identity property of the registry. Don't configure a username and password when using managed identity.

{
    "identity": {
        "type": "SystemAssigned,UserAssigned",
        "userAssignedIdentities": {
            "<IDENTITY1_RESOURCE_ID>": {}
        }
    }
    "properties": {
        "configuration": {
            "registries": [
            {
                "server": "myacr1.azurecr.cn",
                "identity": "<IDENTITY1_RESOURCE_ID>"
            },
            {
                "server": "myacr2.azurecr.cn",
                "identity": "system"
            }]
        }
        ...
    }
}

For more information about configuring user-assigned identities, see Add a user-assigned identity.

Limitations

Azure Container Apps has the following limitations:

• Privileged containers: Azure Container Apps doesn't allow privileged containers mode with host-level access.

• Operating system: Linux-based (linux/amd64) container images are required.

• Maximum image size:

  • Consumption workload profile supports container images totaling up to 8GB for each app or job replica.
  • Dedicated workload profiles support larger container images. Because a Dedicated workload profile can run multiple apps or jobs, multiple container images share the available disk space. The actual supported image size varies based on resources consumed by other apps and jobs.

Next steps