Adrian Cantrill’s SAA-C02 study course, 60 minutes: HA & Scaling section: [ADVANCED DEMO]: Architecture Evolution Stage 2: Automate the build using a launch template
Architecture Evolution: Stage 2: Automate the Build using a Launch Template
Building from the two parts of stage 1, this stage was about recreating the work from stage 1, but this time automating the build of the WP site, database, storage, etc…. So as to gain some appreciation for automation and see how it is superior and less error-prone than doing everything by hand.
To begin this stage of the demo, we terminated the manually created WP instance we created in stage 1. We were going to set up the same single instance deployment of WordPress, so both the database and the application on the same instance, but instead of manually building this, we would utilize a launch template. To access this template we navigated to the EC2 console and clicked on the Launch Instances tab under Instances.
From here we proceeded to create a launch template, starting with clicking on ‘Create Launch Template’. It was explained that launch templates are actually a new version of launch configurations that were previously used with auto scaling groups. Launch templates allow to either launch instances manually using the template, or they can be part of auto scaling groups. What a launch template allows you to do is to specify all of the configuration in advance to launch an instance, and that template can be used to launch one or many instances.
Our focus here was to create a launch template that would automate the installation of WordPress, MariaDB, and perform all of the configuration. A launch template can actually have many different versions, a feature we were going to plan on using as the design evolved.
To start we named the template, edited the template version description, and enabled a box which would authorize for guidance to be provided for setting up a template that could be used with EC2 auto scaling. We didn’t want to immediately set it up as part of an auto scaling group, but this would help with highlighting any options that would be required if we wanted to use it with an auto scaling group.
Launch templates can be created from scratch or they can be based on a previous template version. If Source Template is expanded, you can specify a template upon which the new template will be based, but for the purposes of the demo we created our template from scratch.
Moving on, the next set of parameters we defined started with defining which AMI we wanted to use, which would be the same AMI that we used in the previous stage. This would an Amazon Linux 2 AMI, HVM SSD Volume Type and 64 bit x86 architecture. Moving on, we clicked on the instance type drop down and selected the T type series of instances, selecting the free tier version.
After this we scrolled down the key pair section, verifying that the it was set as ‘Don’t include in the launch template’. Continuing on, we scrolled down to network settings, and set the VPC. Continuing on to the security groups dropdown, and selected the relevant SG, which became the SG associated with any instances launched using the template. We left storage resources as default, didn’t set any resource tags, did not do any configuration of network interfaces, and proceeded to expand Advanced Details.
Working in Advanced Details, we set the IAM instance profile, which attached an instance role which provided all of the permissions required to interact with the parameter store and EFS, and anything else that this instance required. Continuing on, we scrolled down to the Credit Specification section, which we previously worked with when launching the other instance manually. This time we set it to ‘unlimited’, and were assured that for the purposes of this demo, there would not be any extra charges because it wouldn’t have been running for the entire day.
Continuing on, we scrolled all the way down to the bottom of the instance configuration details to the User Data Box section. The user data allows us to specify bootstrapping information to automatically configure our EC2 instance. Into this User Data box we pasted the entire code snippet from stage 2B, which was a bash configuration file in this case.
Then we created the launch template, and launched the instance from the template. For launch template, version and number of instance, everything was left as the default. Scrolling down we took note of how the Instance configuration console was pre-populating with information provided by the automation bash file we pasted into user Data section.
We opted to proceed without a key pair, specified a subnet to launch the instance into. It was explained that when we configured auto scaling groups, the autos scaling groups would automatically configure the subnets for us.
Moving on, we scrolled down to the resource tag section, added a tag, choosing name for the key, and a specific value for the value, which we did to specify that this instance was launched using the template. Then we launched the instance from the template, and because the instance was created with the template, it automated everything that we had to do manually in the previous stage.
We then clicked on the instance id in the success box, which brought us to the instances tab in the EC2 console, and kept an eye on the configuration progress. We then copied the IPv4 and opened that ip in a new tab. After the WP installation screen was successfully loaded, we followed the same process to create the blog site as was down in the prior stage of this demo. The configuration of the WP site was identical to the prior manual build, with everything stored locally on the same site, which put serious limitations on our ability to scale, perform health checks, and do many other things. Also, the IP address of the database was hard-coded into the database.
CloudMastermind 