Since we launched the early public preview of Azure Container Apps on Arc enabled Kubernetes clusters last December, we have been working to continue to bring new features and capabilities to the preview (Container Apps on Azure Arc Overview | Microsoft Learn). One area we have been keen to improve is the onboarding process and steps required to deploy your first Azure Container App on an Arc enabled Kubernetes cluster.
The number of steps and number of CLI extensions required to get to the point of having an app up and running is quite extensive:
- Connect a Kubernetes cluster to Azure
- Create a Log Analytics Workspace for app logs
- Deploy the Azure Container Apps extension to the cluster
- Create a new or use an existing Custom Location and bind it to the extension on the cluster
- Create a new Azure Container Apps Connected Environment
- Create a new Azure Container App in the Connected Environment
- Using either a previously built container image from an existing registry or;
- Create a new container image and store it in a new or existing registry.
Quite a few steps and many resources to create! How would you respond if I was able to show you a way in which you could do all of this in two steps or one if you have already connected the Kubernetes cluster to Azure Arc?
Setup
To use this new functionality, you must
- have connected an AKS or AKS-HCI cluster to Azure Arc - Connect an existing AKS or AKS-HCI Cluster to Azure - Quickstart: Connect an existing Kubernetes cluster to Azure Arc - Azure Arc | Microsoft Learn
- Install the preview CLI extension for Azure Container Apps on Azure Arc enabled Kubernetes
az extension remove --name containerap
az extension add --source https://aka.ms/acaarccli/containerapp-latest-py2.py3-none-any.whl --yes
Option 1 – Deploy using a previously built container image
You can deploy a container app that uses an existing image in a public or private container registry. The example below deploys an existing image from a private container registry and you can see the required registry-server, registry-username and registry-password values in the example command.
In this example the command performs the following actions:
- Creates a Resource Group
- Creates a Log Analytics workspace for application logs
- Installs the Azure Container Apps extension on the Connected Cluster
- Creates a Custom Location and binds it to the Azure Container Apps extension on the Connected Cluster
- Creates a Connected Environment resource targetting the created Custom Location
- Creates and deploys a Container App that pulls the ima``ge from the specified registry
- Sets the container apps ingress to external with a target port set to the specified value
`
az containerapp up --name <CONTAINER_APP_NAME> --image <REGISTRY_SERVER>/<IMAGE_NAME>:<TAG> --registry-username <REGISTRY_USER> --registry-password <REGISTRY_PASSWORD> --registry-server <REGISTRY_SERVER> --ingress external --target-port <PORT_NUMBER> --connected-cluster-id <CONNECTED_CLUSTER_ID>
Option 2 – Deploy using local source code
This command can build the image with or without a Dockerfile. If building without a Dockerfile the following languages are supported:
- .NET
- .Node.js
- PHP
- Python
- Ruby
- Go
In this example the command performs the following actions:
- Creates a Resource Group
- Creates a Log Analytics workspace for application logs
- Creates an Azure Container Registry
- Builds the container image (using the Dockerfile if it exists).
- Pushes the image to the registry
- Installs the Azure Container Apps extension on the Connected Cluster
- Creates a Custom Location and binds it to the Azure Container Apps extension on the Connected Cluster
- Creates a Connected Environment resource targetting the created Custom Location
- Creates and deploys a Container App that pulls the image created from the new Container Registry
az containerapp up --name <CONTAINER_APP_NAME> --source <SOURCE_DIRECTORY> --connected-cluster-id <CONNECTED_CLUSTER_ID>
Option 3 – Deploy from a GitHub repository
This command deploys from a GitHub repository. A Dockerfile is required to build the image.
In this example the command performs the following actions:
- Creates a Resource Group
- Creates a Log Analytics workspace for application logs
- Creates an Azure Container Registry
- Builds the container image (using the Dockerfile if it exists).
- Pushes the image to the registry
- Installs the Azure Container Apps extension on the Connected Cluster
- Creates a Custom Location and binds it to the Azure Container Apps extension on the Connected Cluster
- Creates a Connected Environment resource targetting the created Custom Location
- Creates and deploys a Container App that pulls the image created from the new Container Registry
- Creates a GitHub Actions workflow to build the container image and deploy the container app when future changes are pushed to the GitHub repository.
az containerapp up --name <CONTAINER_APP_NAME> --source <SOURCE_DIRECTORY> --connected-cluster-id <CONNECTED_CLUSTER_ID> --repo <GitHub Repository Url> --ingress <external or internal> --target-port <PORT_NUMBER> --context-path <optional to be set if Dockerfile is not in root of repository>
Because the up command creates a GitHub Actions workflow, rerunning this command to deploy changes to your application’s image will create multiple workflows. To avoid this happening simply push your changes to your GitHub repository, and the GitHub Action workflow will automatically build and deploy your app.
Summary
In this post we have shared three examples of how, after connecting your cluster to Azure Arc, you can drastically cut down the number of steps required to setup and deploy your first Azure Container App to your Azure Arc enabled Kubernetes cluster. We hope this helps with onboarding to Azure Container Apps on Arc enabled Kubernetes, and this accelerates your time to deployment. We look forward to listening to and addressing any feedback you have with this functionality and the preview so far!