Running Containers in Azure: High‑Level Overview

At a high level, running a container in Azure isn’t as difficult as it might seem. The core workflow is very similar to running containers on‑premises, you still build an image, store it in a registry, and deploy it to a compute environment. What changes in the cloud is mainly the terminology and the Azure services involved.

First, you need a place to store your container images. In Azure, this is typically Azure Container Registry (ACR). Once ACR is created and configured, you can push your local images to it just as you would with any other registry.

Next, you need a compute service to actually run the container. Instead of provisioning your own VM, Azure App Service can host containerized applications for you. This is a paid service, so it’s best to start with the lowest tier while experimenting. You can delete it afterward or switch to a free tier if available.

Finally, you create a Web App for Containers within App Service and point it to your image in ACR. Once configured, Azure pulls the image and runs your container, making your application accessible.

Since this walkthrough uses Pay‑As‑You‑Go resources, be sure to review the Cost Awareness section at the end of this guide so you understand how to avoid unnecessary charges.

Dive into the steps below to launch your container in Azure

This guide starts with the assumption that you already have a Docker image ready to deploy

Prerequisites: Tools and Azure Services You’ll Need

• Azure CLI

• Azure Container Registry (ACR)

• Azure App Service (Linux, Container)

1. Install Azure CLI

Install the Azure CLI using Winget if it isn’t already on your machine. This is a one‑time installation and is required for interacting with Azure.

winget install -e --id Microsoft.AzureCLI

2. Authenticate to Azure

If you have multiple tenants, you’ll need to log in to the specific tenant before retrieving its tenant ID. Start by running az login, then run az account show to view the tenant details. If you only belong to a single tenant, will automatically authenticate you into your default tenant.

az login --tenant <tenant-id>

3. Create a resource group to contain all deployment resources

Note: In Azure, a Resource Group acts like an organizational container that holds all the related services for a specific project or environment. You can create multiple resource groups such as dev, test, and prod, to keep environments separated and easier to manage. For this walkthrough, we’ll create a resource group that will contain all the Azure services used in this sample deployment.

az group create \
  --name <rg-resource-group-name> \
  --location <**region>

**Suggested regions: eastus, eastus2, centralus, westus, westus2

Best Practice: Your Resource Group name should begin with rg- . This naming convention makes it easier to identify and distinguish resource groups from individual services over the long term.

4. Register Required Azure Providers

Before creating any Azure Container Registry or App Service resources, you need to ensure that your subscription is enabled to use those service types. Azure requires certain resource providers to be registered before you can deploy related services. The commands below register the providers for Container Registry and App Service so the deployment steps that follow run without issues.

az provider register --namespace Microsoft.ContainerRegistry
az provider register --namespace Microsoft.App

5. Create Azure Container Registry (ACR)

Provision a Basic‑tier ACR instance, one of several ACR SKUs, and the most cost‑effective for this guide:

When you create your Azure Container Registry (ACR), the name you choose becomes your registry’s login server in the format <name>.azurecr.io. This is the address you’ll use when pushing your Docker images to Azure.

az acr create \
  --resource-group <resource-group-name> \
  --name <registry-name> \
  --sku Basic \
  --location <**region>

**Suggested regions: eastus, eastus2, centralus, westus, westus2

6. Build and Push Docker Image

Typically, you develop and test your container locally. Once you’re satisfied with the behavior, you’ll build the actual Docker image on your local machine—this image is the packaged application Azure will later run as a container. After the build completes, you’ll push the image to your Azure Container Registry, which becomes available at <register-name>.azurecr.io . This push step uploads the image so Azure services can pull and run it during deployment.

6.1 Build the image

docker build -t <registry-name>.azurecr.io/<image-name>:<tag> .

6.2 Authenticate to ACR

az acr login --name <registry-name>

6.3 Push the image

docker push <registry-name>.azurecr.io/<image-name>:<tag>

7. Create App Service Plan (Linux)

Now that your Azure Container Registry is configured, you need a compute service where your container can actually run. In Azure, this compute layer is provided by an App Service Plan. The plan defines the underlying compute resources—essentially the VM capacity—that will host your containerized application within your <resource-group-name> . Like any Azure resource, the plan must be named, and it’s a good practice to include the word plan in the name so you can easily distinguish it from other services in your environment.

az appservice plan create \
  --name <service-plan-name> \
  --resource-group <resource-group-name> \
  --sku B1 \
  --is-linux \
  --location <regions>

Recommended regions: eastus, eastus2, centralus, westus, westus2.

8. Create Web App (Container Enabled)

To run your container in Azure, you need to create a Web App resource configured for containers. This service is what actually executes your container in the cloud. After you run the creation command, Azure returns a JSON payload that includes useful metadata, including the defaultHostName attribute. You don’t need to manually look this up, though, Azure automatically generates the default hostname based on the name you assigned to your Web App. The resulting URL follows the format <application-name>.azurewebsites.net, which becomes the public endpoint for your containerized application.

az webapp create \
  --resource-group <resource-group-name> \
  --plan <service-plan-name> \
  --name <aplication-name> \
  --deployment-container-image-name <registry-name>.azurecr.io/<image-name>:<tag>

9. Enable ACR Admin & Retrieve Credentials

Once the Web App has been created, it needs credentials to pull your container image from your Azure Container Registry. By enabling the ACR admin account and retrieving its username and password, you provide the Web App with the authentication it needs to access <registry-name>.azurecr.io, pull the image, and run the container.

az acr update -n <registry-name> --admin-enabled true

Retrieve credentials:

az acr credential show -n <registry-name>

10. Configure Web App Container Settings

az webapp config container set \
  --name <application-name> \
  --resource-group <resource-group-name> \
  --container-image-name <registry-name>.azurecr.io/<image>:<tag> \
  --container-registry-url https://<registry-name>.azurecr.io \
  --container-registry-user <registry-name> \
  --container-registry-password <YOUR-ACR-PASSWORD>

Replace <YOUR-ACR-PASSWORD> with the value returned from the previous step.

11. Restart the Web App

Apply configuration changes by restarting:

az webapp restart \
  --name <application-name> \
  --resource-group <resource-group-name>

11. Test Your Deployed Application

With your Web App created and your container successfully pushed to Azure, you can now test your application in the cloud. Azure automatically assigns a public URL to your Web App based on the name you provided during creation. Your site will be available at <application-name>.azurewebsites.net. Open this URL in your browser to confirm that your container is running as expected and that your deployment pipeline is working end‑to‑end.

12. Cost Awareness & Cleanup

This walkthrough was completed using a Pay‑As‑You‑Go subscription. If you’re following along, it’s worth checking whether you qualify for Azure’s free tier, which can significantly reduce costs while you practice. App Service Plans and Container Registries can incur charges, so it’s important to stay mindful of your usage to avoid unexpected billing. Once you’re done experimenting, you can delete the App Service or other resources you created to minimize ongoing costs.

Closing Thoughts

This hands‑on walkthrough is a great way to understand how container deployment works in Azure and to see all the configuration steps involved, from building images to pushing them into ACR and running them in App Service. In a real production environment, however, these manual commands would be automated through a CI/CD pipeline. Once a pull request is approved, your code would flow through the pipeline, build the container image, push it to your registry, and deploy it to your Web App automatically.