Adrian Cantrill’s SAA-CO2 study course, 60 minutes: HA & Scaling section: [Advanced Demo] Architecture Evolution: stage 1, part 2
[Associate Shared] Architecture Evolution STAGE 1 – Part 2
Continuing on from part one, after creating all of that architecture, the next step was to install WP on the EC2 instance. To do this, we navigated to instances in the EC2 console, and connected via Session Manager, which was a new connection option for us. The reason for connecting this way was to connect without needing to worry about direct network access or having an SSH key pair.
After this we opened bash and typed in several Linux terminal commands to perform a manual WP install. This included settings some environment variables from the parameter store, then updating the operating system on the instance, making sure it was still running with all the patches, and update the package repositories.
Continuing on, we ran more Linux commands to install prerequisites, including the MariaDB server, the Apache web server, Wget, some libraries, and a stress utility. We discussed how this whole process would be automated later in the demo, but we were going through this now to gain experience with the inner workings of the application we were building, and also to gain appreciation for the later automation process.
Once we verified that everything was properly installed, we ran commands to start up the web server and the database server and ensure that both start up automatically when the instance operating system is first started, so if the instance is restarted, both of the services will start up automatically.
This was followed up with running commands to set the root password for the MariaDB server; this was MySQL admin, and we were setting the password for the root user, and using the environment variable that was created earlier with values taken from the parameter store, so this sets the root password for the local database instance.
Continuing on, we downloaded and installed WP, which was completely by running more commands in Bash. We downloaded the WP pacakge, moved into the webroot directory, expanded the package, and then cleaned up after itself.
The next step was to run more commands in Bash that replaced some of the placeholders in the WP-config.php file, the configuration for WP, and it replaced the placeholders with values taken earlier from the parameter store; this is how we were configuring WP to be able to connect to the local MariaDB database server.
Continuing on, we ran more commands in Bash to fix up the permissions of all of the directory structure so there aren’t any problems accessing the files or any other security issues.
Lastly, we ran more commands to actually create the WP database, create the WP database user, set the password, and then grant permission on that database to that user. We needed to complete all these steps because we were using a self-managed MariaDB database instance.
We created a DB.setup file with a number of SQL commands, and then it used the MySQL utility to run those commands, which have created the database, the database user, and set permissions, and it cleared up the temporary file after everything has been done, and at this point, this was all the configuration needed. We installed WP, we installed MariaDB, we started them up, corrected permissions and adjusted the configuration files. It was pointed out that typing/pasting in all these commands by hand was both time consuming and prone to errors.
After this, we navigated backed to the EC2 console, verified that the specific WP instance we were working with was selected, and copied the IPv4 version for public IP address into the clipboard, and did not click on the ‘open address link’, because that uses HTTPS, which we were not using at that time. We opened that on a new tab, ran through a quick setup on the startup screen for WP, and installed WP. Then we logged in with the username and password we used when creating the site.
To verify that the WP instance was working properly, we navigated to the posts section, deleted the dummy post, and created a new, simple post. We learned that the images we used were uploaded into a local image store called WP-content, and in addition to that, the metadata for the post was being stored in the local MariaDB database. So the data was stored in two places: the local content store along with the database. Then we clicked on View Post to verify that the post worked.
Continuing on, we discussed the limitations of our present configuration. The first was that the application and database were built manually, which takes time and doesn’t allow automation. It was a slow and tedious process, which was the stated intention.
Along with this the database and the application were running on the same instance, which means that neither can scale without the other. The database for the application was stored on an EC2 instance, and that means that scaling in or out risks data in this database. The application media, so the content, is also stored local to the instance, in the WP-content folder, and this means that any scaling events in or out risks this media. Also, customer connections are direct-linked to an instance, which prevents us from doing any form of scaling, automatic healing, or any health checks.
Lastly, it was discussed about the WP is that the IP address of the instance is actually hard-coded into the database. Where this starts exhibiting problems is when running inside AWS because EC2 instances don’t have static IP addresses. To look at this, we forced stopped and then re-started the EC2 instance. We took note of how the instance lost the specific public IP it was using, and once restarted, it had acquired a new public IP address. We copied the new IP address, navigated to the tab where the website was opened, and first tried refreshing the website. The website did not properly load for obvious reasons. After this we tried pasting in the new IP and resolving to that, which also did not work. It was pointed out that the reason for this was that the application was hard-coded with the IP address that was used to install WP, so now the application was attempting to reference the old IP address, trying to contact the previous EC2 instance. This is crucial because it would prevent scalability of the application. If new EC2 instances were created, they would all point back at the instance, so even if the database and content issues were fixed, there would still be the problem of WP to scale, which would be covered later in the demo series.
To recap, in stage one of this demo, we had created the WP instance with the application and database running on the same instance. Coming up, we will be automating this process.
CloudMastermind 