DEV Community: Christiana Otoboh

Deploying a Containerized WordPress App on AWS with Docker, EBS & S3 Backups

Christiana Otoboh — Fri, 20 Mar 2026 10:07:14 +0000

Introduction

In this project, I deployed a containerized WordPress application on an AWS EC2 instance using Docker. The setup includes a MySQL database, persistent storage with EBS, and automated backups to S3.
The goal wasn't just to get WordPress running; it was to understand how real-world deployments handle data persistence, networking, and automation.

Prerequisites

Before following along, make sure you have the following in place:

An active AWS account
Basic familiarity with the Linux command line
A key pair created in AWS (needed to SSH into your EC2 instance)
Basic understanding of what Docker is (you don't need to be an expert)

Note: Everything in this project is done on a free-tier eligible EC2 instance.
Just be mindful to stop or terminate resources when you're done to avoid unexpected charges.

Project Overview

Here’s what I built:

A Linux EC2 instance hosted on AWS
Docker installed and configured using a Bash script
WordPress and MySQL running as Docker containers
Persistent storage using an attached EBS volume
Automated MySQL backups uploaded to an S3 bucket
Secure access configured via Security Groups

⚙️Step 1: Provisioning the EC2 Instance and EBS Volume via the AWS Console

With the architecture in mind, the first step was setting up the core infrastructure.
Launching the EC2 Instance
(Not covered in detail here — the process is fairly straightforward. The default configuration suffices, with one exception: make sure to configure the security group as follows.)

Port 22 → for SSH access
Port 80 → for web access

Creating the EBS Volume
(Also not covered in detail, but equally straightforward — just ensure the volume is provisioned in the same region as your EC2 instance.)

Attaching the EBS Volume to the EC2 Instance
Once the volume is created, attach it to the instance by following these steps:

Select the EC2 instance in the AWS Console.
Click Actions, then navigate to Storage → Attach Volume.
From the dropdown, select the volume you just created.
Choose a device name from the dropdown — any available option works.
Click Attach Volume to confirm.

I then connected to the instance via SSH and handled everything else from the terminal.

🐳 Step 2: Installing Docker & Setting up Configurations

Using the Bash script below, I automated the entire environment setup. Specifically, the script:

Installed Docker and its plugins, including Docker Compose
Started and enabled the Docker service
Added the ubuntu user to the Docker group, allowing Docker commands to run without sudo
Mounted the EBS volume to the filesystem
Used a bind mount so MySQL writes data directly to the EBS volume, ensuring data survives container restarts and is not tied to the container lifecycle
Installed the AWS CLI in preparation for the S3 backup process

The goal of this script was to handle everything in one pass, Docker installation, EBS volume mounting, and AWS CLI setup so the instance is fully ready before any containers are launched.

#!/bin/bash
set -e

echo "============================================================"
echo "Provisioning script is now running"
echo "============================================================"

# Status of docker on the server

if  command -v docker &>/dev/null || sudo systemctl is-active --quiet docker; then
  echo "docker $(docker --version) is installed and running. Skip docker installation"
else
  echo "Docker is not installed, installing docker ................"

  #Update packages
    sudo apt update
    sudo apt install ca-certificates curl gnupg lsb-release -y

    #Add Docker's official GPG key
    sudo install -m 0755 -d /etc/apt/keyrings
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
    sudo chmod a+r /etc/apt/keyrings/docker.gpg

    # Set up the Docker apt repository
    echo \
      "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
      $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

    #Install the Docker Engine packages
    sudo apt update
    sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

    # Add dcoker user to docker group (so no sudo needed)
    sudo usermod -aG docker ubuntu

      # Enable and start Docker
    sudo systemctl enable docker
    sudo systemctl start docker
echo "docker $(docker -v) has been installed......"
fi



# Install aws cli

echo "============================================"
echo "Installing aws cli"
echo "============================================"

if command -v aws &>/dev/null; then
  echo "aws CLI $(aws --version) is installed"
else

  # Download the official AWS CLI v2 installer. I am using Ubuntu
  curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "/tmp/awscliv2.zip"

  # Unzip it
  sudo apt install unzip -y
  unzip /tmp/awscliv2.zip -d /tmp

  # Run the installer
  sudo /tmp/aws/install

  # Verify installation
  aws --version

  # Cleanup
  rm -rf /tmp/awscliv2.zip /tmp/aws
fi

# Format the EBS volume and make it a filesystem 
echo "==========================================="
echo "Mounting EBS Volume"
echo "==========================================="

if mountpoint -q /mnt/ebs; then
  echo "EBS Volume is mounted"
else
  echo "EBS Volume is not mounted.... Mounting EBS Volume"

  #Format the EBS volume
  sudo mkfs -t ext4 /dev/nvme1n1

  #Create a mount point where the EBS Volume will appear
  sudo mkdir -p /mnt/ebs

  #Mount the volume to the mount point (Folder), add the fstan to make the mount permanent (survives reboots)
  sudo mount /dev/nvme1n1 /mnt/ebs
  echo '/dev/nvme1n1 /mnt/ebs ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab
fi



# Create a folder on the mounted EBS volume for mysql to write to
sudo mkdir -p /mnt/ebs/mysql-data

# mysql runs as a user with UID:999,  grant it ownership to the volume directory so that it can write into it
sudo chown -R 999:999 /mnt/ebs/mysql-data

echo "Provisoning Script completed!"

Running the Script

Before executing, make the script executable by running:
chmod +x scriptname.sh

Then execute it:
./scriptname.sh

Once the script has finished running, verify that everything was set up correctly. These checks are not strictly necessary if your script runs successfully, but they are worth doing especially if you are just starting out, as they help build confidence that everything is set up correctly before moving on.

Confirm Docker is installed:
docker --version

Next, confirm the Docker daemon is accessible:

docker ps

On first run, docker ps might return the following error:

permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

Log out of your server and SSH back in, then run docker ps again, the error should be resolved.

Confirm the EBS volume is mounted:

Confirm the AWS CLI is installed:

▶️ Step 3: Getting the Containers Running

I defined the services using a Docker Compose file to run:

A WordPress container (frontend)
A MySQL container (database)

Both containers communicate over Docker's default network. I also ensured that the MySQL volume was mapped to the mounted EBS volume, so all database data is written to persistent storage.

For security reasons, I stored the database credentials in a .env file and referenced them as variables inside the Docker Compose file.

services:
  db:
    image: mysql:8.0
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - /mnt/ebs/mysql-data:/var/lib/mysql
  wordpress:
    depends_on:
      - db
    image: wordpress:php8.2-apache 
    ports:
      - "80:80"

    restart: unless-stopped
    environment:
      WORDPRESS_DB_HOST: db:3306                                                  
      WORDPRESS_DB_USER: ${MYSQL_USER}                                       
      WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}                                      
      WORDPRESS_DB_NAME: ${MYSQL_DATABASE}
networks:
  default: {}

I then started the containers by running:
docker compose up -d

To confirm the containers were created and running:
docker ps

If successful, your WordPress application should now be accessible via the EC2 instance's public IP address. Make sure the URL starts with http and not https. Only port 80 was configured and not port 443, using https will make the site unreachable.

☁️ Step 4: Automating Backups to S3

To improve reliability, I implemented a backup strategy that:

Exports the MySQL database using mysqldump
Compresses the backup file
Uploads it to an S3 bucket using the AWS CLI. This ensures data can be restored even if the instance fails.

Prerequisites: S3 Bucket & IAM Role
Before creating the backup script, I set up two things:

Created an S3 bucket to store the backups.
Created an IAM role for authentication, which I attached to the EC2 instance. This allows the instance to upload to S3 without needing to hardcode credentials — I find this the easiest and most secure approach.

When creating the IAM role, make sure:

Trusted entity type is set to AWS Service
Use case is set to EC2
The role is granted full S3 access or a custom S3 bucket policy — without this, the upload will fail.

To attach the IAM role to the instance, select the EC2 instance, go to Actions → Security → Modify IAM Role, select the role you created from the dropdown, and save.

The Backup Script

#!/bin/bash

echo "========================================"
echo        "Starting backup.sh script"
echo "========================================"

echo "Setting up environment variables"

set -e        # stop if anything fails
set -a        # start exporting variables
source .env   # load variables from .env
set +a        # stop exporting

DB_CONTAINER="ubuntu-db-1"
MYSQL_USER=${MYSQL_USER}                # mysql DB user
MYSQL_DATABASE=${MYSQL_DATABASE}        # mysql DB
MYSQL_PASSWORD=${MYSQL_PASSWORD}        # mysql Password
S3_BUCKET="s3://sca-wordpress-demo"     # s3 bucket name

# Create local Repository first to store the backup before uploading to s3
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="mysql-backup-${TIMESTAMP}.sql.gz" 
TEMP_DIR="/tmp"
FULL_BACKUP_PATH="$TEMP_DIR/$BACKUP_FILE"



# Run the docker exec to run the mysql dump
echo "================================================="
echo "Taking the mysql backup locally"
echo "================================================"

if 
docker exec "$DB_CONTAINER" sh -c \
 "exec mysqldump \
 --single-transaction --set-gtid-purged=OFF  --no-tablespaces  \
 -u$MYSQL_USER -p$MYSQL_PASSWORD $MYSQL_DATABASE" | gzip > "$FULL_BACKUP_PATH"; then
 echo "Dump taken successfully"
else
echo "Dump not successful"
exit 1
fi


# Upload to s3 bucket
# I created an IAM role with an s3 bucket access, attached it to the EC2 Instance. This takes care of verification

echo "================================================"
echo                "Uploading to s3 bucket"
echo "================================================"

if aws s3 cp "$FULL_BACKUP_PATH" "$S3_BUCKET/"; then
echo "Upload to s3 was completed succesfully"

#Confirm if the backup file is in s3 bucket
    if aws s3 ls "$S3_BUCKET/$BACKUP_FILE" &>/dev/null; then
        echo "$BACKUP_FILE is in $S3_BUCKET"
    else
        echo "Upload seemed to succeed but file not found in bucket"
        exit 1
    fi    
else 
  echo "Upload FAILED"
    exit 1
fi


echo "=================================================="
echo " Upload completed"
echo "=================================================="

Note: Replace the S3 bucket name with your own bucket name before running the script.

Make the script executable:
chmod +x backup.sh

Then run it:
./backup.sh

Confirm your backup was uploaded successfully:

📌 Key Takeaways

From this project, I learned:

How WordPress and MySQL communicate across containers using Docker's default network
Why databases need persistent storage and how a bind mount to an EBS volume keeps data alive beyond the container lifecycle
How to automate an entire server setup — Docker installation, volume mounting,and CLI configuration using a single Bash script
How to implement a real backup strategy using mysqldump, compression, and S3 uploads, authenticated securely via an IAM role
How Security Groups act as a firewall, and why only exposing the ports you actually need matters

Conclusion

This project gave me hands-on experience with deploying a real-world application using cloud and container technologies. More importantly, it helped me understand the why behind key concepts like persistence, networking, and security.

If you're learning DevOps or Cloud Engineering, I highly recommend building something like this, the lessons stick much better when things break and you fix them yourself.

💬 Feel free to share feedback or suggestions.

How I Fixed the “Large Files Detected” Error When Pushing a Terraform Project to GitHub

Christiana Otoboh — Sat, 22 Nov 2025 18:44:09 +0000

When working with Terraform, you may run into this GitHub error:

This message means GitHub is blocking your push because one or more files in your repository exceed its 100MB upload limit.

This error is common among Terraform beginners and even experienced engineers because of how Terraform organizes provider binaries. GitHub rejects any file larger than 100MB, and Terraform providers typically weigh between 200MB–500MB.

In this article, I’ll walk you through exactly why it happens, how I fixed it, and how you can prevent it from ever happening again.

Why This Happens

Terraform downloads provider binaries into:

.terraform/

If you run:
git add .

before adding .terraform to .gitignore, Git starts tracking these massive files.

Even if you delete the folder later, the large files remain in your Git history, and GitHub scans the entire history during a push.
If any file is over 100MB, GitHub blocks the push.

Step 1: Add .terraform to .gitignore

Then:

git add .gitignore
git commit -m "Add Terraform ignores files"

Step 2: Remove .terraform From Git History

Even after ignoring, GitHub still rejects the push because the massive files are stored in old commits. To fix this, we use a powerful tool:
git-filter-repo.

git filter-repo is a powerful and versatile tool for rewriting Git repository history. It is a Python script designed to be a faster, more capable, and more user-friendly alternative to git filter-branch

To install the git filter-repo on my machine (wsl on windows) I used the following commands

sudo apt update 
sudo apt install git-filter-repo

run:
git filter-repo --version
to check if the installation was successful, it should print a version like this

Then clean your history:

git filter-repo --force --path .terraform/ --invert-paths
This removes all .terraform files from all past commits.

Step 3: Force Push the Cleaned Repo

The commit history has changed, you need to force push to upload the cleaned repository to Github without the large files
git push --force
This takes care of the large file error.

Terraform Git Best Practices

Never commit:

.terraform/
terraform.tfstate
terraform.tfstate.backup
provider binaries

Conclusion

This error is very common for Terraform beginners and even experienced engineers.
The fix is straightforward:

Ignore .terraform
Clean the Git history with git filter-repo
Force-push the cleaned repository

Taking the time to clean your repo ensures you maintain a lightweight, secure, and professional Terraform project.

Automating Backups to S3 with Bash, Crontab & AWS CLI as a Beginner

Christiana Otoboh — Mon, 07 Jul 2025 09:46:06 +0000

As part of a learning assignment, I was tasked with creating an automated backup system.
The goal was to:

Backup a specific local directory on my Linux machine.
Compress the backup as a .tar.gz file.
Upload it to an Amazon S3 bucket.
Log each step with timestamps.
Automate the process with a cron job.

While this sounds straightforward for an experienced DevOps engineer, I had zero knowledge of Linux scripting or AWS CLI when I started. What followed was a rollercoaster of trial, error, and growth. This post documents my journey, what I learned, the final working solution, and how I overcame some tough beginner mistakes.

My Learning Roadmap

1. Learning Bash Scripting

I started with learning how to write a basic bash script. I needed it to:

Define a source and destination path.
Use tar to compress the files.
Log each step with a timestamp.

2. Understanding S3 Uploads

Initially, I installed the AWS CLI without configuring it. Later, I stumbled upon s3fs (a way to mount an S3 bucket as a local file system), but I got stuck for hours trying to make it work.

Thankfully, I reached out to a senior developer who advised me to use aws s3 cp instead, which was simpler and more appropriate for my use case.

3. Configuring AWS CLI

After some dependency issues related to Python (which AWS CLI uses), I was able to:

Create an IAM user with programmatic access.
Configure my AWS CLI with the IAM credentials (aws configure).
Successfully test uploads using aws s3 cp.

4. Automating with Crontab

Finally, I set up a cron job to run my script every day at 7:00 AM. I used crontab -e and added:
0 7 * * * /home/christiana/backup.sh

The Final Working Script

Here’s the working version of my backup script:

#!/bin/bash

SOURCE=/home/christiana/documents
DEST=/home/christiana/backupfolder
S3_BUCKET=s3://demosample-backupbucket/Backup/

NOW=$(date +"%Y-%m-%d_%H-%M-%S")
BACKUP_NAME="backup_$NOW.tar.gz"
BACKUP_PATH="$DEST/$BACKUP_NAME"
LOG="$DEST/backup_log.txt"

echo "[$NOW] Starting backup..." >> "$LOG"

# Create compressed backup
tar -czvf "$BACKUP_PATH" "$SOURCE"
if [ $? -eq 0 ]; then
  echo "[$NOW] Backup created: $BACKUP_NAME" >> "$LOG"
else
  echo "[$NOW] Backup FAILED" >> "$LOG"
  exit 1
fi 

# Upload to S3
aws s3 cp "$BACKUP_PATH" "$S3_BUCKET/"
if [ $? -eq 0 ]; then
  echo "[$NOW] Upload to S3 Successful" >> "$LOG"
else  
  echo "[$NOW] Upload to S3 FAILED" >> "$LOG"
  exit 1
fi 

echo "[$NOW] Backup completed" >> "$LOG"

Troubleshooting and Lessons Learned

Here are some common problems I faced and how I fixed them:

1.AWS CLI Installed but Not Working
Problem: I installed the AWS CLI but forgot to configure it.

Solution: Ran aws configure and entered my IAM credentials.

2.Python Dependency Errors
Problem: AWS CLI wasn't working due to missing Python dependencies.

Solution: I installed the required version of Python and ensured it was available in my PATH.

3.Using s3fs Instead of aws s3 cp
Problem: I wasted hours trying to mount S3 as a drive with s3fs.

_Solution: I learned it’s better to use aws s3 cp for one-off uploads. It's simpler, faster, and has fewer moving parts.
_
4.Crontab Didn't Run My Script
Problem: Cron job wasn’t running the script.

Fixes:

Ensured the script had execute permission (chmod +x backup.sh).
Used absolute paths in the script (cron doesn't know your environment).
Added full paths for tar, aws, etc., or sourced my environment manually.

Final Thoughts

This small project taught me a lot:

How to write bash scripts and use tar/gzip for compression.
The power and simplicity of AWS CLI.
The importance of reaching out when you're stuck.
How to schedule recurring tasks in Linux using cron.

I started as a complete beginner and ended with a working automation system that runs every morning at 7 AM, backing up my documents to the cloud.

If you’re starting your DevOps or scripting journey, don't be afraid to struggle just document everything, ask questions, and keep going. You'll figure it out. Just like I did.

✅ Tools Used:

Bash
AWS CLI
IAM User with S3 permissions
tar and gzip
crontab