Host Website on Azure Container Instances

Introduction  

In this hands-on lab, I deployed a simple website using Azure Container Instances (ACI) with a Rocky Linux container image. I used Apache HTTP Server to host a basic HTML page and accessed the website through its public IP address.

Azure Container Instances allows us to run containers in Azure without managing virtual machines or Kubernetes clusters.

1. What is Azure Container Instances (ACI)?

Azure Container Instances (ACI) is a serverless container service provided by Microsoft Azure. It allows you to run Docker containers without managing virtual machines or setting up a Kubernetes cluster.

Serverless Containers:

ACI manages the underlying infrastructure, so you do not need to provision or maintain virtual machines for your containers.

Basic Workflow:

Docker Image -> Deploy to Azure Container Instances -> Running Container -> Application

You provide a container image, configure the required resources and ports, and deploy it to Azure. Azure starts the container and makes the application available according to your network configuration.

2. Key Use Cases and When to Use ACI

Short-Lived Tasks and Batch Jobs:

ACI is suitable for scripts, data processing, and batch jobs that run for a limited period and stop when the work is complete.

Testing and Development:

Developers can quickly test containerized applications without creating and maintaining virtual machines or a Kubernetes cluster.

Simple Workloads:

ACI is useful for standalone applications, simple web applications, and isolated container workloads that do not require complex orchestration.

Quick Container Deployment:

ACI allows you to deploy and run a container quickly without managing the underlying server infrastructure.

3. Comparison: ACI vs Virtual Machines vs AKS vs Azure Container Apps

ACI vs Virtual Machines:

Virtual machines require infrastructure provisioning, operating system maintenance, patching, and resource management. Azure Container Instances manages the underlying infrastructure, allowing you to focus on running your containerized application.

ACI vs Azure Kubernetes Service (AKS):

AKS is a managed Kubernetes service designed for applications that require container orchestration, multiple services, scaling, rolling deployments, and advanced networking.

ACI is more suitable for standalone containers and simple workloads that do not require Kubernetes orchestration.

ACI vs Azure Container Apps (ACA):

Azure Container Apps is designed for modern applications and microservices. It provides features such as application-level scaling, revisions, traffic splitting, and integration with event-driven workloads.

ACI is a good choice for straightforward container deployments when you want to run a container without managing a full orchestration platform.

Lab Environment

• Cloud Platform: Microsoft Azure
• Azure Service: Azure Container Instances
• Resource Group: 12Oct2026
• Container Group: myapp
• Container Image: vallabh/rocky:22-Aug
• Operating System: Rocky Linux
• Web Server: Apache HTTP Server 2.4.62
• Public IP Address: 72.152.41.209
• Website Port: TCP 80
• Container Status: Running

Step 1: Create Azure Container Instance

I created an Azure Container Instance named myapp in the 12Oct2026 resource group.

The container uses the image vallabh/rocky:22-Aug. Azure successfully downloaded the image and started the container.

The container configuration exposes the following ports:

• Port 80: HTTP web traffic.
• Port 22: SSH, if the SSH service is configured and running inside the container.

The container status was Running, and the provisioning state was Succeeded.

Step 2: Verify the Container Configuration

The container details showed the following public IP configuration:

• Public IP Address: 72.152.41.209
• Port: 80/TCP
• Port: 22/TCP
• Container Status: Running

Azure also confirmed that the container image was pulled successfully and the container started without restarting.

However, a running container does not automatically mean that a web server is working. We must verify that Apache is listening on port 80.

Step 3: Test Website Connectivity

I used the curl command to test the website from a terminal.

Command:

curl -v --connect-timeout 10 http://72.152.41.209

The connection was successful, and the server returned the following response:

Connected to 72.152.41.209 port 80

HTTP/1.1 200 OK
Server: Apache/2.4.62 (Rocky Linux)
Content-Type: text/html; charset=UTF-8

This confirms that the public IP is reachable over HTTP and Apache is serving the website.

Step 4: Verify the Website Content

The website returned the following HTML content:

<h1>Welcome to Darole.org</h1>
<h2>Today is 22-Aug-2026</h2>

This confirms that Apache is serving the HTML page from the Rocky Linux container.

The website can be accessed using the following URL:

http://72.152.41.209

Step 5: Troubleshooting Commands
During troubleshooting, I checked the website using curl.

Some minimal container images do not include commonly used Linux commands such as ps and ss.

These commands are provided by the following Rocky Linux packages:

# dnf install -y procps-ng iproute

• procps-ng provides commands such as ps and top.
• iproute provides commands such as ss and ip.

If these packages are unavailable or cannot be installed, container logs can be checked from Azure Cloud Shell:

# az container logs --resource-group 12Oct2026 --name myapp --container-name myapp

To test the website from Cloud Shell:

curl -v --connect-timeout 10 http://72.152.41.209

Conclusion
In this lab, I successfully hosted a simple website using Azure Container Instances, Rocky Linux, and Apache HTTP Server.

The container was running, the public IP address was accessible, and Apache returned an HTTP 200 OK response.

This exercise helped me understand container deployment, public IP access, port configuration, and basic web server troubleshooting in Microsoft Azure.