Ruta 53 y búsqueda de AMI
Tutorial 2 de 5 acerca del uso de Terraform y Ansible para AWS. Tras finalizar el tutorial habrá creado mediante Terraform un VPC en AWS con una instancia EC2 conectadas a una base de datos MariaDB ejecutándose sobre RDS. Posteriormente se usa Ansible para configurar e instalar el software necesario.
Prerequisitos y código fuente:
- Configuración de Terraform y creación de la subred del VPC (1/5)
- AWS VPC Subredes, Tablas de Rutas y Acceso a Internet usando Terraform (2/5)
Servidor de DNS de AWS Route 53 con Terraform
El servicio Route 53 de AWS proporciona servicio de DNS con opciones avanzadas en el entorno Cloud de AWS. Vea más información en Elementos Básicos de AWS.
La configuración de Route 53 se realiza en terraform.tfvar, se muestra a continuación un ejemplo básico que no incluye registros MX para e-mail o los correspondientes a otros servicios.
#------------------------
# ROUTE53
#------------------------
#------------------------
# PUBLIC - PRO
#------------------------
aws_route53_delegation_set_reference_name = "ditwl-r53-del"
aws_route53_public = {
name = "demo.itwonderlab.com"
comment = "ditwl - Public DNS"
tags_environment = "pro"
}
aws_route53.tf crea un set de delegación (de zona) y los recursos propios de la zona autoritativa.
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.
Cambiar de servidores DNS autoritativos es problemático, se debe planificar con tiempo para evitar interrupciones de servicio y en algunos casos mantener los nuevos y los antiguos durante unas horas y incluso días. Algunos servidores DNS cachean y no respetan el TTL configurado.
Mientras que el set de delegación creado en el módulo aws_route53_delegation_set no se destruya, podemos recrear el servicio de DNS en el módulo aws_route53_public.
#------------------------
# Public
#------------------------
module "aws_route53_delegation_set" {
source = "./modules/aws/route53/delegation_set"
reference_name = var.aws_route53_delegation_set_reference_name
}
module "aws_route53_public" {
source = "./modules/aws/route53/public_zone"
name = var.aws_route53_public["name"]
delegation_set_id = module.aws_route53_delegation_set.id
comment = var.aws_route53_public["comment"]
#TAGS
tags_environment = var.aws_route53_public["tags_environment"]
}
En este ejemplo se crear un único servicio de DNS que se usará tanto para registros internos como externos.
En un entorno de infraestructura real de producción, se debe crear una zona privada dedicada exclusivamente a resolver las peticiones de los servidores internos. Los servidores a los que los usuarios no requieran acceso directo (back ends) deben registrarse exclusivamente en el servidor DNS privado ya que sus clientes son todos internos.
Las instancias EC2 obtienen el servidor DNS a utilizar durante el arranque mediante una opción del protocolo DHCP. Si un VPC tiene tanto zonas privadas como públicas, AWS primero consultará los servidores DNS de la zona privada.
Creación de una instancia EC2 con Terraform
Para la creación y el registro de una instancia EC2 se utiliza un módulo de Terraform, el módulo se encarga también de registrar la nueva máquina en los servidores DNS.
Se crean entradas tipo A para cada instancia utilizando la zona autoritativa creada con anterioridad.
Ejemplo de la configuración del registro en DNS de una máquina EC2 durante la llamada al módulo de creación. Se muestra parcialmente el fichero aws_ec2_pro_wp.tf:
# Create WP instance
module "aws_ec2_pro_wp" {
source = "./modules/aws/ec2/instance/add"
name = var.aws_ec2_pro_wp["name"]
...
register_dns_private = true
route53_private_zone_id = module.aws_route53_public.id
register_dns_public = true
route53_public_zone_id = module.aws_route53_public.id
...
}
Encontrando el AMI correcto en AWS con Terraform
AWS asigna un ID único a cada AMI que se publica en AWS, el ID es diferente en cada región.
El fichero aws_ds_aws_ami.tf utiliza un proveedor de datos apra encontrar el ID de AMI basado en filtros para una imagen Ubuntu 16.04 HVM sobre EBS SSD. Se muestran dos filtros:
- name es como «ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-*»
- virtualization-type es HVM (comentado al ser redundante)
Ya que deseamos usar la imagen oficial, creada por Canonical, utilizamos su identificador de propietario 099720109477. Se trata de un ID asignado por AWS a Canonical
#--------------------------------------------------------
# Ubuntu AMI
#--------------------------------------------------------
# Use this data source to get the ID of the latests AMI for selected OS
# "${data.aws_ami.NAME.id}"
# Ubuntu 16.04 HVM using EBS SSD
# registered AMI for use in other resources.
#----------------------
# Ubuntu AMI 16.04 LTS
#----------------------
data "aws_ami" "ubuntu1604" {
most_recent = true
filter {
name = "name"
values = ["ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-*"]
}
# filter {
# name = "virtualization-type"
# values = ["hvm"]
# }
owners = ["099720109477"] # Canonical
}
El ID del AMI se puede utilizar cuando se quiere crear una instancia EC2 con la última versión disponible. Se obtiene el AMI solicitando el ID a la fuente de datos data.aws_ami.ubuntu1604.id.
El ID deAMI ID cambia cada vez que Canonical sube una nueva versión de «Ubuntu 16.04 HVM image using EBS SSD», el módulo acepta una lista de propiedades en la variable ignore_changes cuyos cambios serán ignorados y por tanto no recrearán la instancia.
# Create WP instance
module "aws_ec2_pro_wp" {
source = "./modules/aws/ec2/instance/add"
name = var.aws_ec2_pro_wp["name"]
ami = data.aws_ami.ubuntu1604.id
instance_type = var.aws_ec2_pro_wp["instance_type"]
...
ignore_changes = ["ami"]
}
Continúe la demo de Terraform y Ansible para AWS:
- Tutoriales Terraform y AWS
- Tutoriales de Ansible
