Deploy WordPress on AWS Using OpenEBS

Deploy WordPress on AWS using OpenEBS

A Content Management System (CMS) simplifies the creation, management and modification of websites using a straightforward, easy to use GUI. A CMS typically consists of two components: The Content Management Application (CMA) and the Content Delivery Application (CDA), that together aid in implementing various core functions of a website, including: 

  • Seamless indexing, search and retrieval
  • Formatting documents into HTML
  • Content Revision & Updates
  • Content Publishing

WordPress is a free, open-source CMS that was founded as a blogging platform but has grown to support the creation of all kinds of websites. The platform allows customizable backends and frontends, making it ideal for creating blogs, e-commerce sites, business websites, portfolios, event websites and more. It's popularity is also owed to its free offering, simplicity, flexibility and plugins that make it extendable. 

Amazon Web Services (AWS) offers a large-scale cloud platform that enhances performance, control, scalability and reliability for WordPress websites. The AWS Elastic Kubernetes Service (EKS) allows organizations to create, manage and scale Kubernetes clusters on AWS cloud or local machines. This article explores available approaches for migrating a WordPress website to AWS, and the architecture components for AWS-hosted WordPress. While doing so, the article also delves through the practical steps of provisioning Read-Write Many (RWx) dynamic persistent volumes for a WordPress application running on AWS EKS using the OpenEBS Dynamic NFS Provisioner. 

This guide covers how OpenEBS NFS PV can be used to provide shared storage on the AWS EKS platform for a WordPress CMS. 

Launching and Configuring WordPress on AWS

AWS accelerates the delivery of WordPress content and improves user experience by leveraging Content Delivery Networks that rely on replicated edge locations. By deploying websites and blogs on AWS, organizations can improve performance and cost-efficiency by making use of high availability, static content offload, bytecode caching, and other cloud-native benefits. This section explores the various options for hosting WordPress on AWS and the architecture of a scalable AWS WordPress deployment.  

Options for Migrating and Managing WordPress on AWS

WordPress has grown to include CMS capabilities that integrate with modern elastic, scalable and cloud-native architecture. The WordPress community has worked to develop modules that enable the creation of WordPress websites that take advantage of AWS Cloud offerings. As use cases vary, following are some of the options in AWS when opting for a WordPress hosting:

Amazon Lightsail

Amazon Lightsail is an easy-to-use, single-instance virtual private server that abstracts all instances needed to run a simple workload or quick deployment. Lightsail acts, therefore, as the perfect starting point for a small WordPress website that can scale later with its growth. Lightsail instance costs start at $3.50 per month, with a 3-month free-tier offering, that allows easy setup options to get started with WordPress.

Amazon EC2

Amazon Elastic Compute Cloud (EC2) enables the provision of secure, scalable compute infrastructure to simplify web-scale cloud computing. The straightforward web service offers developers completedevelopers with complete control of computing resources in AWS while acquiring and configuring these resources with minimal friction. The offering comes with the highest level of flexibility in the choice of networking, OS, storage, processor and purchase models.

EC2 is mostly considered ideal for medium to large-scale WordPress websites in production. 

AWS Marketplace

The Amazon Marketplace includes different pre-configured WordPress images that can be deployed into AWS EC2 in minutes. These one-click deployments are tailored to specific tasks and come in a flexible combination of plugins and packages for efficient use of computing resources. These packages are highly recommended for enterprise-grade WordPress since they are production-ready, stable and include updates & long-term support.

Architecture Components for Hosting Wordpress on AWS

While most WordPress deployments use quick starts to enable automated deployments based on best practices, it is important to understand the components that make up a functioning WordPress application in AWS cloud. At its basic, a WordPress application needs components to perform four functionalities:

  • Host dynamic content
  • Host static content
  • Store blog or site content/data
  • Store uploaded files and images on the file system

This section explores how each of these functionalities can be achieved for AWS. 

The Scaling Web Tier

AWS includes a number of compute instances that can be used to evolve single-server applications into scalable architecture. The scalable web tier includes five key components to handle scaling for dynamic content:

  • Amazon EC2 Instances
  • Amazon Machine Images (AMIs)
  • LoadBalancing
  • Automatic Scaling
  • Health Checks

The AWS Cloud is highly elastic, and uses the auto scaling feature to launch more compute capacity when needed and trim it down when it is not needed. AWS also includes Elastic LoadBalancers that support dynamic addition and removal of hosts from clients in response to application changes. 

Stateless Web Tier

Some parts of a WordPress application are built to return the same response to all end-users regardless of the server that processes their requests. These applications are stateless, in that they don't store session information or have any knowledge of previous interactions. The WordPress core is stateless since sessions are maintained by cookies on the end-users’ web browsers. 

Shared Storage

All WordPress Installation files and user customizations should be managed in a shared platform as this eases the strain on web servers. AWS has the Elastic File System (EFS) which provides a scalable, highly networked file system for different compute instances. Once all installation files are moved into a shared EFS, the WordPress site and all its data is placed on distributed storage independent of server instances. Static assets of the site, such as CSS and JavaScript files, are stored in shared S3 storage, allowing web servers to focus on processing dynamic content. 

Data Tier

Once the WordPress installation files and configurations are moved into a shared Network File System (NFS), and static assets are being served on S3, stateful components are hosted on WordPress Databases. One of the top solutions for running stateful workloads for AWS applications is Amazon Aurora. This platform is compatible with both MySQL and PostgreSQL, combining the simplicity of open-source databases with the performance and availability of enterprise database solutions.

The Architecture for configuring WordPress on AWS would look similar to: 

WordPress Architecture on AWS

A typical architecture of WordPress on AWS

Deploying WordPress on AWS using OpenEBS

Kubernetes enables rapid scaling of web applications using on-demand Horizontal Pod Autoscaling (HPA) policies. An increase in traffic or workload triggers Kubernetes to schedule additional replicas using additional PODs hosting similar data content. Kubernetes also uses rollback deployment strategies to aid in seamless updates for contents, user-uploaded files or plugins. This is why hosting a WordPress application on the AWS Elastic Kubernetes Service simplifies the deployment of scalable, high availability (HA) websites.This section explores various concepts needed to understand how to provide shared storage to a WordPress website running on EKS that requires access to shared volumes. 

Quick Introduction to Kubernetes Access Modes 

An Access Mode is a specification of a Persistent Volume that defines how it is mounted on a host. Different storage providers support different capabilities and the mode for each Persistent Volume is set to the specific combination of access modes it supports. Starting version 1.22+, Kubernetes Supports four types of access modes:

  • ReadWriteOnce (RWO) - volume is mounted to be consumed by a single node
  • ReadOnlyMany (ROX) - volume is mounted as read-only on multiple nodes
  • ReadWriteMany (RWX) - the volume is mounted as read-write on multiple nodes
  • ReadWriteOncePod (RWOP) - the volume is mounted as a single read-write by one POD (v 1.22+)

Introduction to OpenEBS Dynamic PV Provisioning

OpenEBS provides third-party plugins to expose new storage volumes to Kubernetes through the Container Storage Interface (CSI). OpenEBS uses Container Attached Storage (CAS) methods to dynamically provision storage as requested by users, eliminating the need for cluster-administrators to pre-configure storage volumes. The platform also comes with out-of-the-box storage classes for the creation of local and replicated volumes with custom parameter sets. 

OpenEBS uses the LocalPV CAS engine to create PVs either using hostPaths on worker nodes or local disks. With LocalPV, administrators can easily manage disks as Persistent Volumes, facilitating cloud-centric storage features such as clones, snapshots and replication. OpenEBS LocalPV offers plenty of storage benefits for Kubernetes clusters, including:

  • Dynamic provisioning of Local Persistent Volumes
  • OpenEBS performs disk management and support
  • The Volumes are provisioned using Kubernetes standards
  • Local PV Guarantees POD rescheduling after restarts

The OpenEBS NFS PV Provisioner

OpenEBS comes with a Dynamic Network File System (NFS) provisioner that creates a new kernel instance for each PV, allowing for multiple applications to access shared data. This is crucial in ensuring that any updates of WordPress content are synchronously available to all instances, as outline in the following section.

Providing RWX Volumes for AWS Block Storage using OpenEBS NFS

AWS Elastic Block Storage Volumes are only mounted as Read-Write Once on a single-node (RWO). AWS EKS-hosted WordPress web servers scale dynamically on demand due to Kubernetes’ orchestration capabilities. WordPress requires volumes that should be Read-Write by many nodes (RWX) since all replica PODs running wordpress should share the same data content. A Network File System (NFS) solution sets up a new Kernel instance for each PV over the user’s choice of backend storage. The OpenEBS NFS provisioner creates a PVC for this PV in RWX mode so that different replicas can access shared data. 

Solution Guide

To get a scalable WordPress website running on AWS EKS, the OpenEBS solution guide can be followed for detailed steps. The guide outlines the installation of the OpenEBS Dynamic NFS Provisioner, how to install WordPress, and gaining observability into the application using Prometheus and Grafana. 

Kubernetes can be used to provide seamless updates and replication across multiple instances of a WordPress application. Deploying WordPress on EKS brings in scalability, high availability and cost savings on account of AWS’s computing power combined with the features of Kubernetes. To help set up a WordPress instance on AWS EKS, the OpenEBS solution guide outlines detailed steps of the OpenEBS NFS Local PV Provisioner for deploying WordPress on EKS. 

To know more on how OpenEBS can help to manage your organization’s stateful workloads, please contact us .

Related Blogs:

https://blog.mayadata.io/deploy-datastax-cassandra-on-eks-using-openebs-lvm-localpv

https://blog.mayadata.io/wordpress-on-digitalocean-kubernetes-using-openebs-shared-storage

 

Kiran Mova
Kiran evangelizes open culture and open-source execution models and is a lead maintainer and contributor to the OpenEBS project. Passionate about Kubernetes and Storage Orchestration. Contributor and Maintainer OpenEBS projects. Co-founder and Chief Architect at MayaData Inc.
Murat Karslioglu
VP @OpenEBS & @MayaData_Inc. Murat Karslioglu is a serial entrepreneur, technologist, and startup advisor with over 15 years of experience in storage, distributed systems, and enterprise hardware development. Prior to joining MayaData, Murat worked at Hewlett Packard Enterprise / 3PAR Storage in various advanced development projects including storage file stack performance optimization and the storage management stack for HPE’s Hyper-converged solution. Before joining HPE, Murat led virtualization and OpenStack integration projects within the Nexenta CTO Office. Murat holds a Bachelor’s Degree in Industrial Engineering from the Sakarya University, Turkey, as well as a number of IT certifications. When he is not in his lab, he loves to travel, advise startups, and spend time with his family. Lives to innovate! Opinions my own!
Kiran Mova
Kiran evangelizes open culture and open-source execution models and is a lead maintainer and contributor to the OpenEBS project. Passionate about Kubernetes and Storage Orchestration. Contributor and Maintainer OpenEBS projects. Co-founder and Chief Architect at MayaData Inc.