Our web application will only allow configuration to be performed from a management instance that we create. We will restrict access to the management instance through the use of a security group. Other instances, which will be deployed in later labs, will only have read-access to the database. These instances will be unable to add any content to the website.
Note: As previously mentioned, this application is contrived and is only for the purpose of demonstrating various features of AWS. Don't design your application like this.
Estimated time to complete: 45 minutes
Cost: The services in this lab all incur a cost. Consult the EC2 Pricing Website for complete information about EC2 costs. The cost websites for other services were provided in previous labs.
Perform the following from the EC2 console.
- Launch an instance with the following attributes:
- AMI: Amazon Linux
- Instance size: t2.micro
- Specify the following Instance Details:
- Network: specify your lab VPC
- Subnet: specify the public subnet
- Auto-assign public IP: Use subnet setting (Enable) -
- The subnet default should be set to "enable" because we configured auto assignment during the VPC lab
- Leave the storage settings at their default values
- Set the name to be something descriptive, like "App Master"
- Configure a new security group with the following attributes:
- Name: Application-Admin
- Description: Provide something descriptive for the security group
- Add rules to allow SSH and HTTP from only your IP address
- Launching the instance will require you to generate an SSH key pair, or use an existing key pair. Explanations of key pairs are out of the scope of this lab. If you need some extra help with understanding SSH key pairs and their operation in AWS, please review the AWS documentation.
Now that we have an EC2 instance, we need to configure it to host our web application. We will eventually build an Amazon Machine Image (AMI) based on this configuration.
Connect to your instance over SSH and perform the following.
- Become root:
sudo su
- Perform system updates:
yum update -y
- Install NTFS utilities:
yum install -y ntfs-utils
- This is probably already installed
- Install web software:
yum install -y httpd php php-mysql
- Install mysql:
yum install -y mysql
- MySQL is used to remotely connect to the RDS instance and create a new table
- Enable the EPEL repository:
yum-config-manager --enable epel
- The stress tool is located in the EPEL repositories
- Install CPU stress testing tool:
yum install -y stress
- We will use stress to run CPU stress tests on the instances in our Auto Scaling Group (ASG)
- Install Git:
yum install -y git
- Git is needed for downloading the source code for our web app
We need to mount the Elastic File System created during Lab 3. We must also configure the instance to automatically mount the EFS on boot.
Perform the following as the root user.
- Create a directory for the mount:
mkdir /mnt/efs
- Mount the EFS:
mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs
- Be sure to replace the hostname with the DNS name of your EFS
- Add an entry to
/etc/fstab
to ensure that the EFS is automatically mounted on boot:fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2
- Add the line above to the
/etc/fstab
file
- Add the line above to the
Our web application uses MySQL as its backend database. Before the web app can use the previously configured RDS instance, a table must be added to the database.
Perform the following from your SSH session.
- Log into your RDS instance:
mysql -u <Master Username> -p -h <RDS Endpoint>
- Enter your master password when prompted
- Use the database that was already created during RDS provisioning:
USE testapp;
- Add a table for the web app:
CREATE TABLE images (url TEXT);
Now that all of the backend infrastructure has been built and configured, we can begin to configure the actual webserver to host our application.
Perform the following as the root user.
- Change directories to the EFS:
cd /mnt/efs
- Create a directory for the app code:
mkdir /mnt/efs/testapp
- Obtain a copy of the web app code
git clone https://github.com/acritelli/aws-labs.git
- Move the web app code into your newly created directory
mv aws-labs/webApp/* testapp/
rm -rf aws-labs
- Delete the default web directory:
rm -rf /var/www/html
- Change ownership of the app directory to the apache user:
chown -R apache:apache /mnt/efs/testapp
- Create a symbolic link for the web directory to the EFS:
ln -s /mnt/efs/testapp /var/www/html
- Move the configuration file for the web application:
mv /mnt/efs/testapp/
- Our configuration file will be unique to our admin and public instances. Our admin instance will point to the writeable MySQL database, while our public instances will point to a Read Replica. By playing the configuration file outside of our EFS share, we can have a unique copy on each instance.
- Modify the
config.php
file to reflect the RDS instance details that were created previously.vim /var/www/config.php
- Start the web server:
service httpd start
- Configure the web server to start on boot:
chkconfig httpd on
The premise of our web application is a photography website. We use an administrative interface to add photos to the site, and they appear on the home page. Now that we have our instance deployed, we need to ensure that the web app is functioning properly.
Perform the following from a web browser.
- Navigate to the public DNS name or IP address of your instance. You should see something like the screenshot below. Welcome to the world's worst web application!
- Navigate to the "Admin" page of the web app.
- The interface accepts URLs for photos that we wish to add to our page. The URL for these photos is stored in the database.
- Find the link for a picture that you wish to upload. The link should be a direct link to the photo.
- Pixabay is a useful resource for finding photos that can be used.
- Submit the URL to be added to the site.
- Navigate to the home page of the site. You should now be able to see the image that was just added.
Document the information below about your environment. This documentation will be useful during later labs.
Name | Instance ID | IPv4 Public IP |
---|---|---|
You will incur fees if you do not delete the EC2 instance created during this lab. The teardown process is below.
- Terminate the EC2 instance from the EC2 console
-
We manually performed all of the above configuration steps after our instance launched. How could this have been performed automatically during the instance provisioning process?
-
How would you obtain the public IP address of your instance while logged into the instance and without using the EC2 console?
- Hint: This will involve making a web request to a specific URL
-
Explain the difference between user data and metadata.
-
Consider the following scenario: while working on your instance, you make a mistake and determine that terminating and recreating the instance is the best resolution. The instance has only been on for 5 minutes. How will you be charged?
-
Does rebooting your instance incur charge for a full hour? In other words, if you reboot a single instance, are you charged for two hours?