Complex Use Cases
As we enter more complex use cases for our application stacks, it is convenient to split a long YAML configuration files into specialized individual components.
The Wordpress demo is an example of a complex use case with a BOK split across multiple YAML files. This demo provisions
1 new VPC
1 Elastic Load Balancer in VPC
1 EC2 instance in VPC
1 RDS database in VPC
We include multiple BOKs using ruby include blocks leveraging the ERB templates. ERB is a feature of Ruby that enables you to conveniently generate any kind of text, in any quantity, from templates. The templates themselves combine plain text with Ruby code for variable substitution and flow control, which makes them easy to write and maintain.
The master.yml is the master BOK that is used with the mu-deploy command to provision this stack.
Lines 1:5 We introduce some ERB code (between <% and %> that:
Line 4: Invokes a Mu utility function to retrieve all available AWS availability zones from the current account and stores the result in a global $azs variable that will be available from any BOK component or include in this deploy. The ListAZs function is so often used that it's a top level call, usable without the MU:: namespace prefix.
Line 6:9 If a VPC_ID is not passed as a mu-deploy parameter, we include the vpc.yaml file that describes the specs for a new VPC to be created.
Line 11, 13, 15, 16 We're simply using include blocks to include individual YML files to construct a complete master BOK. The include blocks can be replaced with the actual contents of the files they're including and the master.yml BOK will still work.
Line 2:13
This is a standard pattern for creating route tables in a new VPC. We create 2 routes tables, a public route table that sends all outbound traffic to the internet gateway, and a private route table that routes all outbound traffic to the NAT instance. Note the dependency on the NAT instance on Line 11. The dependency block is an important component of mu BOKs and enforces an order of creation for the different cloud resources. In this particular case, we want to make sure the mu-deploy creates the NAT instances first before creating the route tables.
Line 15: 35
This is a standard pattern for creating subnets in a new VPC. Mu makes the $az global variable available to all the BOKs. In this common VPC pattern, we leverage this ruby array of availability zones to create a public and a private subnet in each availability zone in the region we are currently provisioning in.
Line 3 We specify the name of the VPC to provision the load balancer in. The name maps to Line 1 of vpc.yaml.
Line 5 We specify the name of the subnet of the VPC to launch the load balancer in. The subnet name maps to Line 19 of vpc.yaml
Line 7: 10 Specify the security group rules for the load balancer security group.
Line 11:16 Specify the ELB settings that the creation wizard of the AWS console asks for when creating a new load balancer. The parameters in this section should be pretty self-explanatory to anyone familiar with the ELB creation process through the AWS console.
Line 22: 24 As we have seen many times before, specifying dependencies is an important mu BOK component. Here we tell the mu-deploy command to provision and wait on the VPC to be created before creating an ELB in that VPC.
Line 3 Indicates that we’re launching a new RDS. Other options are launching from an existing snapshot. For launching from an existing snapshot, this setting would be set to existing.
Line 5: 6 The VPC to provision the RDS database in. The name of the VPC in line 6 maps to the name specified in line 1 of vpc.yaml
Line 11 Indicates that the RDS database should be publicly accessible. If this setting were set to false, the RDS endpoint would only be accessible to the machines within that VPC (no internet access).
Line 4: 5 The load balancer to associate this instance with.
Line 7: 8 Setting the static IP flag will allocate and associate an elastic IP with this server.
Line 12: 13 Both the VPC name and subnet name map to the names in the vpc.yaml.
Line 26: 27 Configuration Management section which specifies the recipe to run on the server after orchestration
Line 2 The standard amazon NAT AMI.
Line 5 Amazon recommends this setting be set to FALSE for NAT instances
Line 8: 10 Both the VPC name and subnet name map to the names in the vpc.yaml.
Line 14: 28 Security group rules for the NAT SG
Once the deploy succesfully finishes, use the ELB CNAME to access the wordpress site. You should see the wordpress homepage.
You can access the wordpress admin dashboard (/wp-login.php) using the following credentials:
username: admin
password: admin
