Deploy serverless Drupal applications using AWS Fargate and Amazon EFS

Application modernization involves building applications that are faster than ever, with the ability to scale quickly to potentially millions of users, respond to change faster, and manage petabytes of data. An example of application modernization is building scalable digital experiences, such as corporate websites or external websites. Such applications require content management systems (CMS) such as WordPress and Drupal to share uploads, plugins, and templates across multiple instances. They also require high availability, performance, and the ability to scale up and down to meet business demands.

Organizations need to be able to stand up a website in minutes, automatically scale to meet demand, maintain quality of service at scale, and deploy changes in an agile way. Another key aspect to web serving and CMS is the requirement of shared data access across multiple containerized application instances, or serverless functions, with data persistence and data durability. Without this, it’s hard for a website to respond to the needs of users efficiently and quickly.

By using containers, serverless, and elastic shared storage services, you let AWS handle infrastructure and operational burden while you reduce risk and focus on building business logic and delivering value to your customers. With a centralized file system that provides shared data access across multiple containerized application instances, you can ensure consistent high performance even at peak scale.

In this blog post, we show you how to build a highly available, cost-effective, scalable Drupal-based website on AWS Cloud. The architecture uses serverless compute, serverless storage, and a serverless database, with no infrastructure to manage.

Architecting the solution

AWS container services offer the broadest choice of services to run your applications. You can choose AWS Fargate if you want a serverless compute engine for containers. You can also choose a managed container orchestrator offering such as Amazon Elastic Container Service (Amazon ECS) or Amazon Elastic Kubernetes Service (Amazon EKS).

The Drupal architecture requires persistent, shared file storage. Amazon Elastic File System (Amazon EFS) provides a simple, serverless, elastic file system that lets you share file data without provisioning or managing storage. With Amazon EFS, your file system grows and shrinks automatically as you add and remove files. It eliminates the need to provision and manage capacity to accommodate growth. Amazon EFS is ideal for workloads like content management, web serving, DevOps, and data analytics. It provides low-latency, persistent storage, with high throughput, and a large number of concurrent connections.

Amazon EFS Access Points allow you to share the specific directory in an Amazon EFS file system instead of mounting the root Amazon EFS file system. Using EFS Access Points, you can manage application access to the shared file system by specifying a POSIX user and group to use when accessing the file system, and restrict access to a directory within a file system. You can also manage Amazon EFS client access using Amazon EFS resource policies, which are similar to bucket policies for Amazon S3. With these resource policies, you can disable root access, enforce read-only access, or enforce in-transit encryption for all clients and set an AWS principal to mount the file system using the IAM identity.

We also cover how to use Amazon ECS on AWS Fargate to run a serverless Drupal application using Amazon EFS, with no infrastructure to manage. Drupal is an open-source content management framework written in the PHP server-side scripting language. Drupal provides a backend framework for many enterprise websites, with standard features such as content authoring, reliable performance, and robust security. For this architecture, we use Amazon Aurora Serverless MySQL compatible database (DB), which offers an on-demand, automatic scaling configuration, as the database for our Drupal application. It also scales capacity up or down based on your application’s needs. You can build modern, serverless, and scalable digital experiences using ECS on Fargate, Amazon EFS for persistent file storage, and Amazon Aurora serverless MySQL compatible DB. The Drupal architecture is highly available, enabling transparent application failover to another Availability Zone. It’s also scalable, which means you can scale down to zero without losing state, saving on compute costs.

Solution overview

We deploy the sample Drupal application on an Amazon ECS container with AWS Fargate by completing the following steps:

1. Clone the “drupal-on-ecs-fargate” repository from GitHub, this repository contains an AWS CloudFormation template to deploy the resources required to build this solution.
2. Deploy the cloned CloudFormation template from the CloudFormation console.
3. Configure the sample Drupal application.

The following illustration shows the architecture of the solution:

For this solution, you deploy an AWS CloudFormation template (provided in the “Solution walkthrough” section). The template creates the following resources:

• An Amazon VPC configured across three Availability Zones. In each Availability Zone, it creates a public and private subnet.

• In the public subnets, an internet gateway for application access through Application Load Balancer (ALB) and NAT gateway for the Amazon ECS task to download the image.

• An Amazon ECS cluster with Amazon CloudWatch Container Insights enabled for cluster performance monitoring.

• A Fargate task in the private subnet and an ECS service configured to autoscale the number of tasks based on the service average CPUUtilization threshold of 75%.

• An Amazon Aurora serverless MySQL-Compatible DB cluster. DB instances autoscale in the private subnet group.

• A new Amazon EFS file system with General Purpose performance mode and Bursting Throughput mode. Optionally, performance/throughput mode can be changed while creating the stack using the parameters.

• Four Amazon EFS Access Points for the Drupal application, with a user identity mapped to user id “33;” these EFS Access Points will be mounted with encryption in transit on the Fargate task. The Drupal application saves the site configuration, application modules, theme files, and user profiles in the /var/www/html/sites, /var/www/html/modules, /var/www/html/themes, and /var/www/html/profiles directories, respectively. The application accesses the files as “www-data” user, with the user-id as “33.”

• An EFS access policy to allow access from only the ECS task IAM role identity.

In the following CloudFormation template snippet, the Amazon EFS file system policy is configured to allow mounting only from the Amazon ECS task. The file system is mounted with write and root access permissions using the ECS task role identity. EFS Access Points are configured to User/Group ID “33.” This configuration is for the Drupal application user “www-data” to access the EFS file system within the Fargate task. The root directories for each access point are also mapped to User/Group ID “33” to create the access point directory with the User/Group ownership “33.”

  EFSFileSystem:
    Type: AWS::EFS::FileSystem
    Properties:
      Encrypted: true
      PerformanceMode: !Ref PerformanceMode
      FileSystemPolicy:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Action:
               - elasticfilesystem:ClientMount
              - elasticfilesystem:ClientRootAccess
              - elasticfilesystem:ClientWrite
            Principal:
                AWS: !GetAtt ECSTaskRole.Arn
….  
  ECSTaskRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Join ['-',[!Ref ClusterName, TaskRole]]
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service: ecs-tasks.amazonaws.com
            Action: 'sts:AssumeRole'
      Policies:
        - PolicyName: EFSAccess
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action: 
                 - elasticfilesystem:ClientMount
                 - elasticfilesystem:ClientRootAccess
                 - elasticfilesystem:ClientWrite
                Resource: '*'
….
  AccessPointSites:
      Type: 'AWS::EFS::AccessPoint'
      Properties:
        AccessPointTags: 
          - Key: "Name"
            Value: "sites"
        FileSystemId: !Ref EFSFileSystem
        PosixUser:
          Uid: "33"
          Gid: "33"
        RootDirectory:
          CreationInfo:
            OwnerGid: "33"
            OwnerUid: "33"
            Permissions: "0755"
          Path: "/sites"  

Scalability and availability

The Amazon ECS, AWS Fargate, Amazon EFS, and Amazon Aurora services used in this solution are scalable, fault tolerant, and highly available without needing you to manage the infrastructure.

• The Fargate task scales based on the minimum and maximum task count set during the CloudFormation stack initialization. The service is configured to run on three private Availability Zones, it automatically scales the Fargate task based on the average CPUUtilization threshold of 75%.

• The Amazon EFS file system stores the data in multiple Availability Zones for redundancy and scales the file system operation and throughput. EFS offers two performance modes, General Purpose and Max I/O. General Purpose mode supports 35,000 file operations per second, and Max I/O mode can scale to higher levels of aggregate throughput and operations per second. For throughput, Bursting Throughput and Provisioned Throughput are the two modes. The baseline throughput is 50 KiB/s per GiB of storage in Amazon EFS Standard storage class. Bursting throughput mode offers the burst credit to scale the file system more than its baseline. In Provisioned Throughput mode, you can provision the throughput of your file system (in MiB/s) independent of the amount of data stored.

For more detail about EFS performance and throughput modes and limits, refer to the following Amazon EFS user guide sections:

• • Amazon EFS performance
  • Amazon EFS quotas and limits

• Amazon Aurora Serverless MySQL-Compatible DB cluster scales capacity as per the cluster minimum and maximum Aurora Capacity Unit (ACU) parameter. Based on settings, Aurora Serverless automatically creates scaling rules for thresholds for CPUUtilization, connections, and available memory. Aurora Serverless manages a warm pool of resources in an AWS Region to minimize scaling time. When Aurora Serverless adds new resources to the Aurora DB cluster, it uses the router fleet to switch active client connections to the new resources. At any given time, you are charged only for the ACUs that are being actively used in your Aurora DB cluster.

Solution walkthrough

Follow these steps to deploy the solution into your AWS account.

1. Download the repository: To download the repository to your local workstation, run the following git clone command to clone the “drupal-on-ecs-fargate” repo from the “aws-sample” repo.

git clone https://github.com/aws-samples/drupal-on-ecs-fargate

2. Provide CloudFormation parameters to deploy the stack: Launch the downloaded template, drupal-on-ecs-fargate/template/template.yaml, from the AWS CloudFormation console.

Input the required CloudFormation parameters to configure VPC resources.

Also add the ECS, Aurora, and EFS parameters. Please note the DBPassword, which you will use when you configure the Drupal application.

3. Deploy the CloudFormation stack: Choose Next and deploy the CloudFormation stack.
4. Verify stack deployment: Once the stack has deployed successfully, the Outputs section of the stack will list ALBEndpoint and DBEndpoint. To access the application, select the ALBEndpoint. Please note the DBEndpoint, which will be used when you configure the Drupal application.

5. Configure the Drupal application: Configure the demo Drupal application that you want to build. The application landing page redirects to the installation page after selecting Save and continue.

On the installation page, Select an installation profile. Here, we select the Demo option.

On the Database configuration page, enter the following:

• Database type: “MySQL, MariaDB, Percona Server, or equivalent.”
• Database name: “drupal”
• Database username: “admin”
• Database password: provide the DBPassword that you set when deploying the CloudFormation stack
• Host: provide the DBEndpoint that you saved after the stack was deployed.

Complete the final step to configure the website. Set up the SITE MAINTENANCE ACCOUNT to log in to the admin page, then choose Save and continue after you are done.

6. Deploy the Drupal application: Success! Your Drupal application has been configured and deployed. The sample website will look like the following:

Cleaning up

To clean up the deployed resources, navigate to the AWS CloudFormation and delete the stack.

Conclusion

Organizations must be able to stand up a website in minutes, automatically scale to meet peak user load and scale down later, maintain the same quality of service irrespective of user load, and deploy changes in an agile way. With a highly available, cost-effective, and scalable Drupal-based website on the AWS Cloud, you can meet your business demands quickly and efficiently.

In this blog post, we showed you how you can modernize your Drupal content management system using serverless compute, serverless storage, and a serverless database, with no infrastructure to manage. By using AWS Fargate integration with Amazon EFS file systems and Amazon ECS, you can build digital experiences that automatically scale, are cost-effective, and allow you to focus on delivering value to your customers. You can get started by deploying Drupal on AWS here.

Thanks for reading this blog post! If you have any questions or suggestions, please leave your feedback in the comments section. If you need any further assistance, contact your AWS account team or a trusted AWS Partner.