Route 53 and AMI Lookup

This is the continuation of a Terraform and Ansible demo to create a VPC in AWS with an EC2 instance connected to MariaDB database running in RDS using a single Terraform plan.

Continue the demo, see:

Download de the code from IT Wonder Lab public GitHub repository.

AWS DNS Server, Route 53 Service with Terraform

The Route 53 service provides DNS service with advanced options, see Route 53 in AWS Basic VPC Elements.

Route 53 configuration is done in terraform.tfvars, the configuration shown is basic and does not include mx records for e-mail or any other service.

aws_route53.tf creates an AWS Route 53 delegation set and the DNS hosted zone.

All domain zones hosted at route 53 get a random set of authoritative name servers, the registrar of the domain (AWS or other) has to be informed of the authoritative name servers that will be used to resolve addresses for the domain.

Changing authoritative name servers can be problematic as it has to be planned ahead and in order to avoid service interruption the new and old name servers have to overlap during some hours. Be aware that some caching DNS Server don’t honor configured TTL.

IT Wonder Lab recommends having a fixed set of authoritative name servers that don’t change overtime (as long as the set is not destroyed).

As long as the delegation set created in the module aws_route53_delegation_set is not destroyed, we can recreate the DNS service from the module aws_route53_public.

In this example a single DNS Services is created, it will be used for the public and private lookup of services.

In a real production infrastructure, a private zone should be created to host names for the internal servers, for example backends should not be registered in the public DNS as its clients are inside the VPC, not outside.

EC2 instances get the DNS to use as a DHCP option on startup, if a VPC has private and public zones, AWS will first query the private zone.

Registering EC2 instances in Route 53

The AWS Route 53 domain zone created before is used to create an A record for all the EC2 instances created in the demo.

An IT Wonder Lab recommendation for EC2 instance registration in Route 53 is to do the “basic” registration inside the EC2 module. This way we make sure that each AWS EC2 instance is registered in Route 53 and that it follows a pattern.

It is possible to the registration outside the EC2 instance module, but if we create many EC2 instances in different Terraform files and later decide to change the registration standar, then every file will need to be modified. In my experience having a separate registration process is prone to errors.

Example of EC2 creation and registration in file aws_ec2_pro_wp.tf

Finding the Right AMI with Terraform

AWS assigns an ID to each AMI that is uploaded to AWS, the assigned AMI ID differs in each region.

The aws_ds_aws_ami.tf file uses a data provider to find the AMI ID based on filters for an Ubuntu 16.04 HVM image using EBS SSD, two filters are shown:

  • name is like “ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-*”
  • virtualization-type is hvm (commented out as it is redundant)

As we want to use the official image from Canonical, the owners property is used with 099720109477 the ID assigned by AWS to Canonical.

The AMI ID can be used when creating an EC2 instance to use the latest available AMI by requesting the ID from the data source “${data.aws_ami.ubuntu1604.id}”.

Since the AMI ID changes as Canonical uploads new releases of the “Ubuntu 16.04 HVM image using EBS SSD”, the module accepts a list of properties in ignore_changes variable that will not trigger an instance destroy/create for changes in the provided list, in our case a change in ami will not recreate the instance.

Continue the Terraform and Ansible demo, see:


Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of