Adrian Cantrill’s SAA-C02 study course, 70 minutes: [DEMO] Using EFS with WordPress
This demo lesson contained three main components:
1. We were going to deploy some infrastructure using one-click deployments
2. We walked through the CFN template to explore how the architecture was built
3. We would be able to see the benefits that EFS provides
To begin we logged into our general AWS account and verified that we were in us-east-1.
The lesson provided three one-click deployments, the first containing the based infrastructure, and the other two containing two different EC2 instances containing the WordPress blog we’ve been evolving.
To start, we deployed the base VPC, RDS, EFS template, which deployed the base VPC, EFS and Aurora database cluster. Before proceeding with provisioning the CFN stack, we needed to obtain the name of the Aurora DB cluster we had created in a prior demo. After pasting that into the appropriate box, we deployed the stack.
While the stack was provisioning we opened up the CFN code for this stack and studied it. We took note of the fact that this CFN stack was deploying the base VPC, EFS with mount targets and an Aurora DB cluster. We looked at all the VPC and networking resources, the subnets the VPC contained, IPv6 information, the RDS security group information, the database subnet group, the Aurora cluster, two Aurora instances, an instance security group which controlled access to all the resources in the VPC that we use that security group on, a rule which allowed anything with that security group attached to it to communicate with anything else, a role that the WordPress instance would use, which included permission on the elastic file system, the instance profile that the instance used, the automated CloudWatch configuration information, the elastic file system itself, and the mount targets for EFS located in each application subnet. So, this CFN template created the VPC, the database, and EFS.
After this we deployed the first WordPress CFN template, which we noted would use resources provided by the CFN infrastructure template we had just finished deploying. We then looked at the code for this CFN stack, focusing on the specific resource being created in this stack, a WordPress EC2 instance. This stack used crossstack references to import a lot of resources created in the first CFN stack, importing the instance profile to used, the specific subnet needed, so it would know where to place the instance, and also importing the instance security group that was created in the previous CFN stack. We also looked through the user data, taking note of the fact that one major difference is that the EFS file system was being mounted into a specific folder, /var/www/html/wp-content. This is the folder which WordPress used to store its media. So now this folder would be located in the EFS file system, because EFS was mapped into this folder on this WordPress instance.
What we would end up with is an EC2 instance which would use the services provided by the original stack. After the EC2 CFN stack finished provisioning, we navigated to the EC2 console, obtained the ipv4, and opened the WordPress EC2 instance in a new tab. Opening the main post on the blog, we took note of the fact that we were running into the same problem as before, that there were no images present on the blog post. We noted that this was to be expected, because the original post was created before we started using EFS and the images were stored locally on that original EC2 instance that was terminated already. So the restored snapshot only contained the host metadata, but not the media.
The solution to this problem was to add the media again. This time it would be stored on EFS. A benefit of this would be to be able to explore what additional capabilities this would provide.
To start, we edited the url for the EC2 instance to take us to the admin login page for the blog. Once we has successfully logged in, we navigated to posts, clicked on edit, closed down the block editor dialogue, clicked on the plus to open up editing options in the current editing block, clicked on the gallery option, clicked on upload, and chose the correct images we wanted from our computer harddrive. This uploaded the images to the wp-content folder in WordPress. We noted that this folder was now mounted using EFS, which meant that the images were now stored on EFS rather than the local instance file system. We clicked on update to update the post and then view to view the post. We were now able to see the images we had uploaded.
To validate the fact of EFS storage being accessible from multiple applications, we navigated back to instances, right-clicked on the running WordPress instance, and clicked on connect to use EC2 instance connect. Once we connected, we cd’d to /var/www/html, ran ls -la in that folder to see a long list of contents, located the wp-content folder, cd’d into that, and pressed enter. We then ran ls -la in that folder, located the uploads folder, and cd’d into that. We continued iterating on cd and ls through several more folders until we beheld the .jpeg images we had uploaded previously. Once we were in the images folder, we ran df -k and noted that /var/www/html/wp-content was mounted using EFS. This meant that the local instance file system was no longer critical, as it no longer stored the actual media. To Demonstrate this we navigated back to the CFN console, deleted the first WordPress CFN stack, and deployed a new WordPress CFN stack. After fully deploying this, we obtained the IPv4 from the EC2 console, opened that in a new tab, navigated to the blog post, and were able to see the images we had uploaded.
To reinforce this, we re-deployed the first WordPress CFN stack, and when it was fully deployed, we obtained the IPv4 for that instance, opened it in a new blog, and were able to view the blog post along with the images we had uploaded to EFS.
CloudMastermind 