AWS Route 53, búsqueda de AMI y creación de EC2 con Terraform (3/5)

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:

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.

Mejores prácticas: No cambiar los servidores DNS autoritativos

Se recomienda disponer de servidores DNS autoriativos que no cambien con el tiempo (a no ser que sean destruidos).

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.

Mejores prácticas: Realice siempre un registro básico de EC2 en Route 53

Se recomienda realizar un registro “básico” dentro del módulo que crea las instancias EC2. De esta forma nos garantizamos que cada instancias AWS EC2 se registra en Route 53 y que sigue un patrón.
Es posible registrar instancias EC2 fuera del módulo que las crea, sin embargo si creamos diferentes instancias en varios ficheros de Terraform y más tarde decidimos cambiar o unificar los nombres o la forma de registrarlas, será necesario modificar cada fichero. Realizar todos los registros fuera del módulo genera errores.

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:

¿De cuánta utilidad te ha parecido este contenido?

¡Haz clic en una estrella para puntuar!

Promedio de puntuación 0 / 5. Recuento de votos: 0

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

¡Siento que este contenido no te haya sido útil!

¡Déjame mejorar este contenido!

Dime, ¿cómo puedo mejorar este contenido?

5 1 vote
Puntuación artículo
guest

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

0 Comentarios
Inline Feedbacks
View all comments

IT Wonder Lab - Las Mejores Prácticas para el Cloud