DEV Community

Cover image for V2: Build a Dynamic Online Ordering System for a Local Café
AWS Community Builders profile image Laura
Laura for AWS Community Builders

Posted on • Originally published at dev.to

V2: Build a Dynamic Online Ordering System for a Local Café

#devops #cloudarchitecture #aws #mariadb

Introduction

We already have the static website online, thanks to Amazon S3's static web hosting capabilities. Now it's time to go to the next step: adding an ordering system for the customers.

Environment Prep

It would be nice to give customers the ability to place orders online. With the current setup, as a static website, that's not possible.
To support this, we will move from S3 bucket static hosting to hosting our café website on an EC2 instance.

In this blog post we will focus on the following:

  • Connecting to an existing EC2.
  • Configuring the EC2 environment and confirming web server accessibility.
  • Installing a web application on an EC2 that also uses AWS Secrets Manager.
  • Testing the web application.
  • Creating an Amazon Machine Image (AMI).
  • Deploying a second copy of the web application to another AWS Region.

The following diagram shows the current status:

diagram aws 1

The goal isn't just to add online ordering capabilities. Martha, the owner, should also be able to view submitted orders. To support the new requirements, we need to move from the S3 bucket to an EC2.
First, create an EC2 (check the official docs) and wait until it's in the running state. Some things to keep in mind for your instance:

  • It should be in a public subnet.
  • It should have a public IPv4 address assigned to it.
  • It should have an inbound rule to allow TCP port 80 only, open to a specific range of IP addresses.
  • It should have an AWS Identity and Access Management (IAM) role associated with it.

For this setup, you'll need an IDE connected to the EC2 so you can edit files directly. Once connected, configure the environment to support the new requirements. In this case, the EC2 runs a LAMP stack.
On the EC2, install the database (MariaDB, in this case) and set it to start automatically after any future restarts:

#Install database
sudo dnf install -y mariadb105-server
sudo systemctl start mariadb
sudo systemctl enable mariadb
sudo mariadb --version
sudo service mariadb status
Enter fullscreen mode Exit fullscreen mode

Inside the EC2, create a file called index.html with some placeholder content:

<html>Hello from the café web server!</html>
Enter fullscreen mode Exit fullscreen mode

You'll need to make this website accessible from the internet. To do this, create a new inbound rule to allow inbound HTTP traffic on TCP port 8000 from anywhere, and add it to the security group of the EC2.

security group

To view your website, enter the public IPv4 address in a browser, specifying port 8000: http://<public-ip>:8000.

website accessible from internet

Time to Go Dynamic

In the previous section, we configured the EC2. At this point:

  • PHP is installed, and the environment has a running relational database (MariaDB).

  • The environment has a running web server accessible from the internet.

  • We have the basic setup needed to host a dynamic website for the café.

Now it's time to install the café app on the EC2.
For context, this is a PHP web application that creates a client to connect to Secrets Manager. The application retrieves several parameters from Secrets Manager, and those secrets need to be created ahead of time (typically through a setup script that automates their creation). You can confirm the secrets were created successfully in the AWS console, under the Secrets Manager resource.
At this stage, you should already have a working database, one you can authenticate to and query directly (for example, running commands like SHOW DATABASES or SHOW TABLES), with the tables and data the application needs already in place.

We also need to attach a role to the EC2 with the following permissions:

iam permissions secrets manager

To confirm the café website is working, head over to http://<public-ip>:8000/cafe, replacing <public-ip> with the public IPv4 address of the EC2.

At this point, you should be able to see your café website, submit orders, and view order history.

Setting up dynamic websites across multiple AWS Regions

It would be ideal to have a production environment that customers use and a development environment where new features and designs can be tested before release.

These two environments would live in different AWS Regions. This also results in a more robust disaster recovery (DR) strategy, in the unlikely event that an AWS Region becomes temporarily unavailable.

Creating an AMI to launch a second EC2 instance

Now that the website is working as expected, we can create a new AMI from the current instance.
On the console EC2 page, go to Actions > Images and templates > Create image. Wait until the image status becomes Available.

Once available, you'll see your newly created AMI.
From here, create a new EC2 based on it. One thing to note: if you switch to a different Region, you won't see the custom AMI you just created. AMIs are Region-specific, so you'll need to copy it to the new Region first.

Now create an instance from your AMI. Give it a name, choose an instance type, and for the network settings, choose a VPC, making sure the instance is placed in a public subnet. For the security group, open TCP port 22 and TCP port 8000 to anywhere.
Launch the instance and wait until it's ready and passes all checks. Connect to it and create the necessary secrets in AWS Secrets Manager for that Region.
Copy the instance's public IPv4 address and load it in your browser. Place an order to confirm the website is working as intended.

At this point, we've successfully created a dynamic website and a duplicate version of it running in a second AWS Region. The original instance becomes our development environment, while this new instance becomes our production environment, the one customers actually use. This way, developers can test enhancements on the development site without affecting the live production site.

Now the architecture should look like this:

aws diagram

Conclusion

We have successfully done the following:

✅ Connected to the VS Code IDE on an existing EC2

✅ Analyzed the EC2 environment and confirmed web server accessibility

✅ Installed a web application on an EC2 that also uses Secrets Manager

✅ Tested the web application

✅ Created an AMI

✅ Deployed a second copy of the web application to another AWS Region

And that's it. We successfully moved from static hosting to dynamic hosting. If you made it to the end, thank you!
In the next post, we'll walk through V3: Database Optimization. See you there.

Top comments (0)