Adrian Cantrill’s SAA-C02 study course, 60 minutes: HA & Scaling section: [ADVANCED DEMO] Stage five, part 1: Enable elasticity via a ASG & ALB and fix wordpress (hardcoded WPHOME)
[Advanced Demo] Architecture Evolution Stage 5 Part 1
The focus of this part of the demo was to add a load balancer and auto-scaling group to provision to provision and terminate instances automatically based on the load of the system. It was emphasized that by adding a load balancer we would be able to abstract connections away from individual instances, which would allow elastic scaling and self-healing if any of the instances had problems.
To start this process, we created the load balancer. To do this, we navigated to EC2, scrolled toward the bottom to the ‘Load Balancing’ section, and clicked on ‘load balancers’, and clicked on ‘create load balancer’. We opted for an application load balancer.
After clicking on create, we gave it a specific name, chose to make it internet-facing, meaning that the nodes of the load balancer would be allocated with public IP addressing, choosing Ipv4 as our type. From here, we selected which subnets the load balancer nodes would be placed into.
For this, we picked the specific VPC we wanted to use, selected the specific AZ’s, and specified which subnets would be used in each AZ. With this part now finished, this meant that the the subnets were configured which the load balancer nodes would be place into. Because they were public subnets and because the scheme was set to internet-facing, these nodes were provided with public IP addressing.
After this we removed the default security group, clicked on the security groups dropdown, and picked the specific security group we wanted to use.
It was explained that the load balancer would be listening on port 80 because the website was using normal HTTP, not HTTPS. The load balancer protocol was set to HTTP and the load balancer port was set to 80.
It was explained that application load balancers work using target groups, so we need to create one. There was a specific name applied to the target group, set the type to instance, because we would be registering instances with the load balancer. For protocol, the load balancer would be connecting to instances in these target groups using HTTP, and the port was set to 80. We verified that the VPC we wanted was selected, and left the protocol version as HTTP1.
Moving on, we set the health checks to be based on HTTP as the protocol, and forward slash as the path. Continuing from here, we decided not to register any targets at this time, as the only thing running is the website instance that was launched using the launch template, and we did not want to register that particular instance. From here, we clicked on ‘create target group’.
After this we navigated back to the load balancer tab, clicked Refresh, and then clicked in the default action dropdown. Selected the load balancer we wanted, and clicked on create load balancer.
We clicked on the load balancer name to move to the load balancer console for this particular load balancer, and proceeded to created another parameter in the parameter store. For this we needed to copy the DNS name of the load balancer, which we copied into our clipboard. After this we moved back to the systems manager parameter store, and navigated to the parameter store.
Because we were automating the environment, we needed a way for all the EC2 instances to know the DNS name of the load balancer, because this would be used as a workaround to the fact that the IP addresses are hardcoded into the database. To deal with this, we needed and automatic way of exposing the load balancer DNS name to the EC2 instances.
For this, we navigated to the parameter store, clicked on create parameter, set a specific name for the parameter which was set to a specific path, input a description, set the tier as standard, type as string, data type as text, and pasted in the DNS name in for the value. From here we created the parameter.
From here our task was to update the launch template. It was explained that this would be a complex process, and so we first broke down the process in detail. It was explained that the IP address of the first EC2 instance that’s used for deployment is hard-coded into the database. This would be fine if the IP address were static. If it’s not, or you’re using multiple EC2 instances, then you can’t use IP addresses because they can be changed both on an individual EC2 instance and if you’re scaling using multiple instances. So we would be replacing the hardcoded IP address with the DNS name of the load balancer. So, we would be updating the launch template with some final configuration so that this configuration could be adjusted, replacing the IP address with the DNS name of the load balancer.
For this, we navigated back to the EC2 console, clicked on launch templates, selected the website launch template, clicked on actions, modify template, create new version. In the template version description we chose app only, uses EFS filesystem defined in a certain path, and then ALB home added to the website database. This way it would be easy to recall this information. This would allow for on-the-fly adjustments to be made every time an instance would be provisioned, to make sure that the load balancer DNS name is set to be the home url for the website.
After this we navigated to the Advanced Details section and expanded it. From there we navigated to user data, added in the applicationload balancer DNS name into an environment variable using systems manager parameter store. Now, when the instance would be provisioning, it would have the DNS name of the load balancer. After this we added some information at the bottom of the user data section. This would add in a final action whereby when the instance was provisioning it would perform an update of the database.
This block of code would bring in the website configuration file, to get the current authentication details for the database. The top lines were configured to get the DB information, including DB name, DB user, and DB password. Another set of lines pulled in the original hardcoded IP address. After this, the script would take in the load balancer DNS name, and run a series of SQL commands, to update the database, moving from the hard-coded IP to using the ALB DNS name. For this the block of code would be creating a script file, and it would port into the script file everything until a certain EOF directive. Basically, the end result would be that the hard-coded IP for the instance would be replaced with the ALB load balancer DNS name, and this change would happen the first time an instance was created. From here we created the new version of the launch template. After this, we selected the launch template and updated the default version using the specific dropdown.
CloudMastermind 