In today’s fast-paced digital landscape, deploying and managing web applications efficiently is crucial for businesses aiming to stay ahead. Drupal, a powerful and flexible content management system (CMS), is a popular choice for building dynamic websites and applications. However, hosting and scaling Drupal can be challenging without the right infrastructure.

Azure Container Instances (ACI) – a simple, yet powerful, service offered by Microsoft Azure that allows you to run Docker containers without managing virtual machines or orchestrators. ACI provides an easy and cost-effective way to host containerized applications, making it an ideal choice for developers looking to streamline their deployment processes.

Why to Use Drupal or CMS

A content management system (CMS) is a software tool that lets users add, publish, edit, or remove content from a website, using a web browser on a smartphone, tablet, or desktop computer. Typically, the CMS software is written in a scripting language, and its scripts run on a computer where a database and a web server are installed. The content and settings for the website are usually stored in a database, and for each page request that comes to the web server, the scripts combine information from the database and assets (JavaScript files, CSS files, image files, etc. that are part of the CMS or have been uploaded) to build the pages of the website.
Here are some of the reasons you might choose to use Drupal:

1. Building a small, simple site with static HTML pages is not difficult, and you can get a simple site up very quickly. Setting up a site in a CMS generally requires more time initially, but brings you the benefits of on-line editing (easier for less experienced content maintainers), uniformity (harder to maintain using static HTML for larger sites), and the possibility of more complex features requiring a database.
2. Some CMS software is special-purpose; for instance, there are packages and hosted services that you can use to build a blog or a club membership website. Drupal, in contrast, is a general-purpose CMS. If you are building a special-purpose site, you might choose to use a special-purpose CMS; however, if your site falls even slightly outside the intended purpose, you will probably be better off using a general-purpose CMS rather than trying to adapt a special-purpose CMS.
3. Building your own CMS-type software can seem attractive. However, using a general-purpose CMS like Drupal as a starting point is usually a better idea, because the basic CMS functionality (such as user accounts and content management) has thousands of developer hours behind it, including many years of user testing, bug fixing, and security hardening.

Introduction to Container Instance

Containers have become a preferred way to package, deploy, and manage cloud applications. Azure Container Instances offers the fastest and simplest way to run a container in Azure, without having to manage any virtual machines and without having to adopt a higher-level service.

Pros and Cons of using Container Instance

Among key advantages of this service we can indicate:

• Fast startup time (usually couple seconds)
• Billing only for real usage (payment per second of service activeness) without any initial costs
• No need for complex orchestration implementation
• Providing container isolation level similar to security level provided by running applications on different virtual machines
• Availability of public IP addresses for containers which can be accessible from Internet using FQDN (Fully Qualified Domain Name)
• Option to integrate with Azure Kubernetes Service
• Option to deploy a group of containers (ACI Container Groups) on one host machine using shared storage space, shared network and other resources between containers working together towards one goal

Some of ACI disadvantages are:

• Limited scalability – in terms of scaling up – ACI provides options to define resources allocated for a container. However, scaling out requires manual creation and management of ACI instances. It also does not provide auto-scaling.
• Basic configuration – in certain scenarios it becomes a drawback (i.e. lack of port mapping functionality can force us to modify the code of the container to make it play well with ACI).

Deploying Drupal On Container Instance

Prerequisites

1. Container Registry
2. SQL Database Server

Creating Dockerfile with Drupal Requirements

1. Drupal Requires the following component
   • Web server(Nginx)
   • Database
   • PHP
   • Custom init.sh
   • Custom settings.php
   • Custom Server.conf
   • Custom Service.yml
2. Dockerfile
   Example: https://raw.githubusercontent.com/tothenew/ttn-toolkit/main/Docker/Drupal-Nginx/Dockerfile
   Highlights :
   • Ubuntu:22:04
   • DRUSH_VERSION 11.4.0
   • Php8.1
3. Custom init.sh
   Example: https://raw.githubusercontent.com/tothenew/ttn-toolkit/main/Docker/Drupal-Nginx/init.sh
   Note:
   • Pm.max_children value will change according to how many process your application needs to start for PHP-FPM(FastCgi)
4. Nginx Configuration
   Example: https://raw.githubusercontent.com/tothenew/ttn-toolkit/main/Docker/Drupal-Nginx/nginx.conf
   Note:
   • client_max_body_size parameter is set to 200M
5. server.conf file
   Example: https://raw.githubusercontent.com/tothenew/ttn-toolkit/main/Docker/Drupal-Nginx/server.conf
6. settings.php
   Example: https://raw.githubusercontent.com/tothenew/ttn-toolkit/main/Docker/Drupal-Nginx/settings.php
   Note:
   • Update MySql Connection strings in $databases[‘default’][‘default’]
   • (Optional) Update Redis Connection strings under
7. Service.yml
   Example: https://raw.githubusercontent.com/tothenew/ttn-toolkit/main/Docker/Drupal-Nginx/services.yml

Prebuild Steps:

1. Create an empty repository with above content or use the following commands

   git clone https://github.com/tothenew/ttn-toolkit.git
   cd ttn-toolkit/Docker/Drupal-Nginx

2. Copy application code in the same directory

Building with application code and pushing to Container Registry

1. Build Docker Image with tag
   • To Build Docker image Copy paste above file in root directory of your application and use the following command

     docker build -t myapp:latest .

Setting up container instance

1. Prerequisites for Container Instance
   • CPU and Memory Size for your container instance
   • Application Port
   • Log Analytics Workspace for Monitoring
2. Define Required environment Variables

   # Define variables
   RESOURCE_GROUP="MyResourceGroup"
   LOCATION="eastus"
   TAG="ENV=non-prod"
   WORKSPACE_NAME="MyWorkspace"
   ACR_NAME="myblogdemoacr"
   CONTAINER_NAME="myblogcontainer"
   IMAGE_NAME="myapp:latest"
   DNS_NAME_LABEL="mycontainerdnsname114313"
   FRONT_DOOR_NAME="MyFrontDoor"
   APP_PORT="80"

   Note:

   • Change any environment variables accordingly
3. Create an Resource Group

   # Create a Resource Group
   az group create --name $RESOURCE_GROUP --location $LOCATION --tags $TAG

4. Create Log Analytics workspace

   # Create a Log Analytics Workspace
   az monitor log-analytics workspace create --resource-group $RESOURCE_GROUP --workspace-name $WORKSPACE_NAME --location $LOCATION --tags $TAG
   
   # Get the Log Analytics Workspace Resource ID
   workspace_id=$(az monitor log-analytics workspace show --resource-group $RESOURCE_GROUP --workspace-name $WORKSPACE_NAME --query customerId --output tsv)

5. Create a Container Registry

   # Create Azure Container Registry (ACR)
   az acr create --resource-group $RESOURCE_GROUP --name $ACR_NAME --sku Basic --location $LOCATION --admin-enabled true --tags $TAG
   
   # Get the ACR Login Server
   acr_login_server=$(az acr show --name $ACR_NAME --query loginServer --output tsv)

6. Push Application Docker Image to Azure Container Registry

   #Tagging application image 
   docker tag app:latest $ACR_NAME:latest
   
   #Login to ACR
   az acr login
   
   #Push image to ACR
   docker push $ACR_NAME:latest

7. Create an Container instance

   # Create a Container Instance
   az container create \
     --resource-group $RESOURCE_GROUP \
     --name $CONTAINER_NAME \
     --image $acr_login_server/$IMAGE_NAME \
     --location $LOCATION \
     --dns-name-label $DNS_NAME_LABEL \
     --ports $APP_PORT \
     --registry-login-server $acr_login_server \
     --registry-username $ACR_NAME \
     --registry-password $(az acr credential show --name $ACR_NAME --query passwords[0].value --output tsv) \
     --log-analytics-workspace $workspace_id

Setting up FrontDoor as CDN

Create FrontDoor:

# Create Azure Front Door
az network front-door create \
  --resource-group $RESOURCE_GROUP \
  --name $FRONT_DOOR_NAME \
  --backend-address $DNS_NAME_LABEL.$LOCATION.azurecontainer.io \
  --tags $TAG

Limitation with Azure Container Instance

1. Resource Constraints:
   1. Memory and CPU Limits: Azure Container Instances have specific limits on memory (up to 14 GB) and CPU (up to 4 vCPUs) per container group.
   2. Storage: Each container group has a maximum of 100 GB of storage, which may not be sufficient for all workloads.
2. Networking:
   1. VNet Integration: While ACI can integrate with Azure Virtual Networks, there are limitations such as lack of support for custom DNS and limited subnet configuration.
   2. IP Addressing: Each container group is assigned a single IP address, which can be a limitation if you need multiple IP addresses.
   3. Security: Only public container instances directly be added in backend pool of front door which will expose container instance to public network
3. Scaling:
   1. Auto-scaling: Unlike Azure Kubernetes Service (AKS), ACI does not support auto-scaling natively. You need to manage scaling manually or use additional services like Azure Logic Apps or Azure Functions.
4. Deployment:
   1. Orchestration: ACI does not support advanced orchestration capabilities like AKS or other Kubernetes services. This makes it less suitable for complex, multi-container applications.
   2. Stateful Applications: ACI is more suited for stateless applications. Running stateful applications may require additional configurations and resources.
5. Service Integration:
   1. Limited Service Bindings: Integrating ACI with other Azure services (e.g., Azure Functions, Azure Logic Apps) may require additional setup and does not have native support for some integrations.
6. Pricing:
   1. Cost Efficiency: For long-running workloads, ACI may be more expensive compared to other options like AKS or Virtual Machines due to its pricing model based on the allocated resources.

Conclusion

While Azure Container Instances (ACI) provide quick and easy container deployment, they may not be suitable for production environments due to limitations in resource capacity, networking, and scaling. ACI lacks advanced orchestration features and native auto-scaling, making it less ideal for complex, high-demand applications. For robust production needs, solutions like Azure Kubernetes Service (AKS) offer greater scalability, control, and integration capabilities, ensuring better performance and reliability.