Artisanal Craft Brewery’s Dynamic Beverage Website

Artisanal Craft Brewery is famous for its selection of artisanal beers while continuously introducing its latest offerings, including limited edition brews and seasonal favorites.

For this crucial requirement, Artisanal brew is highly focused on creating a website that’s highly available to its customers specially when the new flavors are introduced weekly while also monitoring the website performance to be prepared for any action to take in high traffic scenarios. The company chooses none other than AWS services to efficiently run its business with minimum overhead.

There were six members in this team (Cameron Butler, Hadia Noor, Jeff Vaval, Diana Mackaya, and Dorian Clark, and Elizabeth Amanquah) who worked efficiently to accomplish the business needs while also discussing the challenges they faced and how they resolved them.

• Cameron Butler deployed EC2 instance while taking care of security group configurations for the instance.
• Hadia Noor installed NGINX webserver, customized the website, and pushed webserver logs to CloudWatch log groups.
• Jeff Vaval created an S3 bucket that holds website images, while keeping in mind the public access to the bucket.
• Dorian Clark created dashboards in CloudWatch to quickly monitor the significant metrics for our website.
• Diana Mackaya created alarms for those metrics to act when certain thresholds are breached.
• Elizabeth Amanquah installed CloudWatch agent and configured to push EC2 metrics to Cloudwatch.

Let’s jump into each team member’s part one by one, focusing on the assigned task, challenges associated with it, and how they were overcome.

Create an EC2 instance and configure security group settings

by Cameron Butler

First, I created an EC2 Instance server to host incoming traffic to the website. We decided to use ubuntu as the server of choice. And the instance type a t2.micro as recommended.

Next, I made a key pair so other members could SSH into the EC2 instance from the terminal. Which will be needed later to install NGINX. Everything for creating the key pair is default no changes only added a name (BeerCompanyPod).

Thirdly, create a security group to check any traffic coming into the instance. All boxes have been checked marked especially (allow SSH traffic from, and HTTP access). By checking all boxes, we will be able to test the website from an open browser later.

Lastly, I launched instance and informed another member of its completion and sent them the key pair to start on the nginx installation. *All members received the key pair via email*

Creating NGINX server on Amazon EC2 and customizing your website

by Hadia Noor

In this guide, I will take you step by step with configuring a NGINX server on Ubuntu EC2 instance and customizing your website.

Prerequisite

1. Amazon Linux Ubuntu EC2 instance with a key pair.
2. Security group attached to your instance with SSH and HTTP access.

Install NGINX

1. SSH into your instance and switch to root user

sudo -su

2. We would update our local package, so we have access to the most recent package listings.

apt update

3. Now we will install NGINX server on our machine with this command.

apt install nginx

4. You can check the version of NGINX with this command to ensure that it has successfully installed on your machine.

nginx -v

To re-enable the service to start up at boot, type this command

systemctl enable nginx

Once NGINX is installed, you can simply copy the public IPV4 address of your EC2 instance and paste it in another tab. You will see the default NGINX page. Great, your NGINX server is successfully installed.

Configuring NGINX to serve your website

We will need to tell NGINX about our website and how it can be served.

Below is the breakdown of file configuration of NGINX. You need to type these commands below to see all these configuration files.

1. cd /etc/nginx 
2. ll

Importat Files in NGINX:

etc/nginx: The NGINX configuration directory. All the configuration files for NGINX.

etc/nginx/nginx.conf: This is the main configuration file. Right now, this is where our content is being served from. (showing the default webserver page).

etc/nginx/sites-available/: The directory where per-site “server blocks” can be stored. NGINX will not use the configuration files found in this directory unless they are linked to the sites-enabled directory (see below). Typically, all server block configuration is done in this directory, and then enabled by linking to the other directory.

/etc/nginx/sites-enabled/: This is the directory where enabled per-site “server blocks” are stored. Typically, these are created by linking to configuration files found in the sites-available directory.

The directory we are interested in is “sites-enabled”. So, we will navigate into this directory.

cd /etc/nginx/sites-enabled

Open this folder and type ‘ll’ you will see the file name ‘default’. You must edit this file and paste the code below. You can choose your favorite editor; I used vi editor.

server {
 listen 80 default_server;
 listen [::]:80 default_server; 
 root /var/www/html; 
 index index.html; 
 server_name _; 
 location / {
 try_files $uri $uri/ =404;
 }
}

What does it mean?

It’s telling the NGINX to….

1. Serve the webpage from /var/www/html with the filename ‘index.html’. (Don’t worry we are going to create a webpage in this folder later in the guide).

2. Requests made should be served by this server block.

To test your config file, type this:

nginx -t

Creating an index.html page:

1. Navigate into the html folder using the following command.

cd /var/www/html

2. Type ls and you won’t see any index.html page, that’s because you must create one. Type below command to open the file in vi editor

vi index.html

3. Press ‘i’ to go into the INSERT mode, paste the code from index.html file while opening it in Edit mode.

https://drive.google.com/file/d/1qzA2YGeEbm2mfJvYP7CCmGX2Gn2bvkt8/view?usp=sharing

4. Replace the plugins with your S3 bucket URL where it says “[insert s3 url]”. (Don’t worry, the later section will cover creation of your S3 bucket. Copy the bucket name below to create a complete url).

https://<bucket-name>.s3.amazonaws.com/<key>

5. Save your file by pressing ‘:wq!” (means write and quit with saving).

Now, if you restart NGINX, and refresh your tab you should see your site!

systemctl restart nginx

HINT: Right click on the image and open the image in the new tab, you’ll be able to see your bucket URL this image is served from.

Congratulations! You successfully configured your NGINX webserver with custom webpage. Onto the next part of creating S3 bucket.

How To Create an S3 Bucket with Public Access:

by Jeff Vaval

In this section, we will focus on how to create an s3 bucket with public access. S3 is an object based, simple storage service provided by AWS. S3 is a cheaper option to store big chunks of data and it’s also durable and highly available.

First thing first is logging on to your AWS account.

1. Type S3 in the Services at the top or if you been on it recently it should be under recently visited.
2. Click “create bucket” and choose a name for your bucket. Always remember your bucket name must be unique or it will not work.

3. Leave all the default settings as is and scroll down to create bucket. Open your newly created bucket.

4. Click “upload” to start uploading objects in your bucket. After the upload click on the file that you added, and it should give you information on your file and you should see an Object URL. If we use that URL, it should give us access denied as such.

5. After you get the error message go back into your bucket and click on ‘Permissions”. You should see ‘Block Public Access”, click on edit and enable all public access and save changes.

6. Finally, create a bucket policy. Go to permissions tab, scroll down, and click ‘Edit’ on bucket policy, then you are going to click on policy generator. Select ‘S3 bucket policy’ for policy type, Effect as ‘Allow’ and Principal as (*) to allow access to all users. For the actions, look for (GetObject) and select it that will allow every user access to get objects from your bucket. Finally, copy the bucket Amazon Resource Name (ARN) (you can get it from bucket policy page) paste it into the policy generator and add “/*” that represents all the objects in this bucket. Click add statement and generate the policy, copy, and paste the policy into bucket policy and save changes.

7.After the bucket policy is created, you are going to go back to that URL refresh the page or open the link in incognito mode and VOILAS 👌, that is how you create an S3 bucket with public access.

🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂️🙋🏾‍♂

Amazon CloudWatch dashboards:

by Dorian Clark

Now that our instance is up and running, we are going to use CloudWatch to set up a dashboard. This dashboard will allow us to keep track of important metrics we need to track on our instance.

What is CloudWatch?

CloudWatch is an observability and monitoring service offered by AWS. It allows you to gather and track metrics, collect, and monitor log files, set alarms, and respond to changes in your AWS resources.

1. First, you will log into your AWS account and locate the CloudWatch section by searching for it in the search bar.
2. Navigate to the dashboard section. Here, you will create a dashboard by clicking “Create Default Dashboard.”

3. We will title the dashboard “CloudWatch-Default”, and this will be our default dashboard. For this project requirement, we will add the metrics “CPU-Utilization, Network In/Out, and Network Packets In/Out, CPU Credit Usage” This information will allow us to be aware of the volume of incoming traffic and the usage of the CPU.

When adding these metrics, be sure to click on the right instance ID. When completed, the metrics will show in the default dashboard.

Now, you have successfully created a CloudWatch dashboard with metrics tracking the CPU utilization and incoming network traffic.

CloudWatch Alarms:

by Diana Mackaya

In the world of cloud computing, proactive monitoring is key to maintaining optimal performance and preventing potential issues before they escalate. In this guide, we’ll walk through the process of setting up CloudWatch alarms in AWS, specifically focusing on monitoring high CPU usage.

Before creating an alarm, we must create our SNS topic we would like to receive notification on.

Steps to create SNS topic:

1. Login to Amazon account and search for service ‘SNS’.

2. Click ‘Create Topic’ and name it. We named it ‘Artisanal-Brewery-Topic’.

3. Keep all the defaults and create topic.

4. We need to add subscribers to our topic. Go to Subscription, select your topic, and select email. Enter the email address you want to receive notifications about your services. Create Subscription.

You’ll receive an email if you want to receive notifications about AWS services. Confirm via email.

Now you’re ready to create alarms and receive notifications on your topic.

Steps to create Alarms:

• Log into the AWS Management Console and navigate to the CloudWatch service. Click on “Dashboard” and choose the dashboard that corresponds to the resources you want to monitor. Once selected, navigate to the graph displaying CPU utilization. This will serve as the basis for creating our alarm.

• Hover over the CPU Utilization graph, and a menu will appear. Click on “Create alarm” to initiate the alarm creation process.

• In the alarm configuration page, you’ll set up the parameters for your alarm. This includes defining the threshold for CPU utilization that will trigger the alarm, as well as additional settings such as the evaluation period and actions to take when the alarm is triggered.

• On the “Configure actions” step, you can define actions to take when the alarm state changes. We will choose the topic we created in the last step.

(Remember, an email was added as an endpoint to where we can receive alarm).

Click “Next” to step 3 to add a name and description.
Name: AWS/EC2 CPUUtilization InstanceId=i-0ba4f7761af8ef209

. Review the settings you’ve configured for the alarm on ‘Preview and Create’ and ensure everything looks correct. Click on “Create alarm” to finalize the setup.

Our alarm was created!

As an additional thing, we also put stress on our system using the command below to see the CPU Utilization go up.

stress --cpu 2 --timeout 900

Exporting EC2 Logs to CloudWatch using CloudWatch logs agent:

By Elizabeth Amanquah

This post serves as a guide in configuring CloudWatch agent on an EC2 instance and configuring it to push logs and metrics generated by the system services to gain better insights on the performance and security of a webserver. Initially we were not able to install it but after several attempts we were able to install the CloudWatch Agent Logs.

Cartoon Image of the team working tirelessly to complete the project by VectorStock

What are Logs & Metrics?

Monitoring and logging for our Nginx web server ensures that we can troubleshoot any issues and understand the web traffic patterns using CloudWatch. Metrics help to evaluate service performance. Logs record the progress of the execution of an app as well as the system events (application logs/system logs).

What you’ll need to do:

1. Create/Edit IAM Roles (Prerequisite)
2. Add CloudWatch Role to Instance (Prerequisite)
3. Install CloudWatch Logs Agent
4. Configure CloudWatch Agent

Steps:

1. IAM role was created by internal IT team and assigned to our instance. This is how the IAM permission policy should look like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams"
    ],
      "Resource": [
        "arn:aws:logs:*:*:*"
    ]
  }
 ]
}

Afterthe IAM role is created, attach it to your instance and be prepared to install CloudWatch logs Agent on your machine.

Install CloudWatch Logs Agents

Follow the steps below after you SSH into the EC2 Instance

1. Download the agent installation file. For Ubuntu instance, download the latest package and install using the commands below

1. wget https://s3.amazonaws.com/amazoncloudwatch-
agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
2. sudo dpkg -i amazon-cloudwatch-agent.deb

2. After installing, the CloudWatch agent-related config files and executables in the following location can be found here:

/opt/aws/amazon-cloudwatch-agent

Configure CloudWatch Agent:

1. For starters, it is best to run the cloud watch agent wizard that aids in creating the log agent configurations. Execute the following command to begin the wizard.

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-
wizard

1. A series of agent related questions will be prompted
2. Keep the defaults. For ‘Do you want to store the config in the SSM parameter store?’: select No.
3. For file paths, I gave ‘/var/log/nginx/access.log’ and ‘/var/log/nginx/error.log’to monitor.

The final config files get stored in the following location:

/opt/aws/amazon-cloudwatch-agent/bin/config.json

If you want to collect the system metrics, install collecteD on your server.

sudo apt-get update -y
sudo apt-get install collectd

Now, CW agent has been configured, we can start the service using the following:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a f
etch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-
agent/bin/config.json -s

The agent status can be checked using the following command

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a 
status

The status shows “Configured” and “Running”, means we are all good and should be able to see the metrics and log group created in CloudWatch.

Go to CloudWatch console and click Metrics. You will see able to see CWAgent under ‘All Metrics”

Now, I’m going to check the Log Groups to see my log groups created for access and error log.

Uh, oh!

Blockers

The only blocker we faced while doing this project was being able to view the Log Groups. We were not able to view them under the CloudWatch Counsel after serveral attempts. We’ll post updates in our main documentation ! However, everything else was a success !

Mission to get logs in CloudWatch Log groups: (Previously a blocker)

by Hadia Noor

I know how it feels when you are too close to something and still unable to achieve it.

I dig a lot deeper, there were countless attempts in my test environment to get to it. Then finally something worked for me.

I noticed that my configuration file has an agent running as ‘cwagent’ and not as root user, you need to change it to ‘root’.

Use the command below to edit the configuration.

sudo nano /opt/aws/amazon-cloudwatch-agent/bin/config.json

At the top of the file, you will see:

"agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "cwagent"
},

You need to change run_as_user to root, like:

"agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "root"
},

Once you have changed that, you simply reload the config file using the same command as before:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s

And then restart the service:

sudo systemctl restart amazon-cloudwatch-agent.service

Now, go to CloudWatch log groups, and you’ll see the magic :)

Scroll down to see Log streams generated for your webserver:

Log streams generated for your selected instance.

What I learnt from this task is to keep looking for all the viable options and resources you have. You might be missing something very basic, so focus on all the details.

Conclusion and Teamwork:

This concludes our project of successfully creating a NGINX webserver, configuring it to serve our customized website, using appropriate bucket permissions to serve the website images, monitoring the performance of website using metrics, log groups, and alarms.

In this rollercoaster ride, we all learnt to be patient :) and most importantly ‘keep trying until you get it’. We helped each other out in the best possible way and were able to put all the pieces together. Shout out to the teamwork :)