Infraestructura como código

Es un método de aprovisionamiento y gestión de infraestructura IT y servicios a través del uso de código fuente, sustituyendo el procedimiento estándar de operación. Básicamente consiste en tratar los elementos de la infraestructura como si fuesen software.

Permite a las instancias gestionarse de manera programada, consiguiendo una infraestructura escalable y replicable y facilita que las definiciones de la infraestructura puedan estar en un sistema de control de versiones. Adicionalmente, facilita una construcción de la infraestructura más consistente y de mayor calidad, teniendo mejores capacidades de administración. Es la base de DevOps, combina pruebas automatizadas, validación e implementación, maximizando la eficiencia y evitando el error humano.

Beneficios:

  • Rapidez: Permite agilizar el despliegue posterior de una manera más rápida y segura, puesto que se puede desplegar toda la infraestructura con un solo script, siendo este reutilizable.
  • Automatización: Es posible tomar el diseño de una IaC para replicarla exactamente igual en otro entorno modificando únicamente los parámetros. Al estar definida la infraestructura como código se puede incluir en herramientas de Integración Continua y así estar integrada en todos los ciclos de pruebas de creación de entornos.
  • Minimizar riesgos: Con IaC se pueden realizar las comprobaciones necesarias antes de desplegar minimizando el riesgo de errores
  • Actualizaciones controladas y rollback: Permiten la actualización de los stacks proporcionando un fichero actualizado y pidiendo que en lugar de crear un nuevo stack procede a actualizar uno existente.
  • Declarativo vs Imperativo: Se indica cuál se quiere que sea el estado final de la arquitectura.
  • Reducción de costes: Al reducir el tiempo y los esfuerzos necesarios para provisionar la infraestructura se reduce el coste. Adicionalmente, las actividades de soporte y mantenimiento siempre implica menos coste y más satisfacción para los clientes.

Como contra se puede indicar que un modelo de IaC implica cambios importantes puesto que resulta imposible realizar esta transición sin tener una comprensión profunda de los conceptos de arquitectura en la nube y conocimientos en lenguajes de programación, así como de manejo de las API.

Servicios o Productos

Ansible

Las dos partes fundamentales de la Infraestructura como código son aprovisionamiento y configuración. En ellas se definen el contenido de los servidores, qué configuración deben tener, qué aplicaciones deben ser instaladas, cómo deben ser instaladas,…

Ansible modela la infraestructura al describir cómo se relacionan todos los sistemas, en lugar de administrar un solo sistema a la vez.

Ansible utiliza YAML, en forma de Ansible Playbooks.

Algunas de las características son:

  • Sin agente: No hay software o agente que instalar en el cliente que se comunica con el nuevo servidor.
  • Idempotente: Siempre tendrá el mismo resultado independientemente del número de veces que se invoque a la función.
  • Simple y extensible: Está escrito en Python y usa YAML como lenguaje de los playbooks, haciéndolo fácil de entender y extender.

Arquitectura de Ansible

arquitectura de Ansible

 

Los elementos que componen Ansible son:

  • Módulos: Pequeños programas que hacen alguna tarea en el servidor. Por ejemplo, tener el módulo: -name: instalar htop apt: name = htop sería equivalente a ejecutar: sudo apt-get install htop
  • Plugins: Piezas de código que aumentan la funcionalidad principal de Ansible
  • Inventory: Es dónde se definen y agrupan los hosts a ser administrados por Ansible.
 [dbservers]

 postgresqldb01.qa.mydomain.net

 [api]
 
 api01.qa.mydomain.net

 [webapp]

 app01.qa.mydomain
 app02.qa.mydomain

 [proxyservers]

 proxy01.qa.domain
 proxy02.qa.domain
  • Playbooks: El mecanismo que envía comandos a sistemas remotos de forma programada.

 

 ---

 # Play 1
 
 - host: dbservers
   task:
    - name: Install PostgreSQL

      package:

         name: {{ item }}

        state: present

     with_items:
  
         - postgresql
         - postgresql-contrib
         - libpq - dev


- name: Verificar que el servicio de PostgreSQL este corriendo

  service:

  name: postgresql

  state: started

enbaled: yes

 

Este playbook de ejemplo instala la base de datos Postgresql en los Host correspondientes.

  • Group_vars: Archivo que contiene conjunto de variables.
  • Roles: Forma de agrupar múltiples tareas en un contenedor para hacer una automatización de manera más efectiva con estructura de directorios limpias.
  • Handlers: Son listas de tareas diferentes de las normales, a las que se hace referencia con un nombre único global, y son notificadas por notificadores.
  • Etiquetas: Permite ejecutar una parte específica de la configuración sin ejecutar todo el playbook.
  • Conexión: No requiere de instalación de agentes en los servidores que administra, utiliza SSH para conectarse al servidor y ejecutar comandos.

Puppet

Es una solución de gestión de la configuración para administrar la infraestructura en máquinas físicas o virtuales, pudiendo reproducir las configuraciones tantas veces como sean necesarias. Estas configuraciones para todo el software y servidores se almacenan de manera centralizada.

Como características principales destacan:

  • Idempotencia: Siempre tendrá el mismo resultado independientemente del número de veces que se invoque a la función. Puppet verifica el estado actual de la máquina destino y sólo realizará cambios cuando haya algún cambio específico en la configuración.
  • Multiplataforma: Dispone de una capa de abstracción de recursos (RAL). Se puede apuntar a la configuración específica del sistema sin preocuparse por los detalles de la implementación.

Arquitectura Puppet

 

Arquitectura Puppet

Flujo de trabajo

 

Flujo de trabajo

Chef

Permite describir y gestionar la infraestructura en forma de código. Está pensado para conocer mediante código nuestra infraestructura y poder recrearla, reconfigurarla o replicarla. Chef configura y despliega aplicaciones y configuraciones, orquestando la configuración de ambientes compuestos por más de un nodo.

Es una herramienta escrita en Ruby que automatiza el procedimiento de aprovisionamiento. Trabaja con un modelo Maestro – Cliente en el que se requiere un equipo independiente desde el que controlar el nodo maestro.

Se integra perfectamente con plataformas en nube (Amazon, GoogleCloud, Azure, OpenStack)

No es agent-less. Requiere de la instalación de un agente en cada nodo gestionado. Los agentes pueden ser instalados desde el cliente usando knife que usa SSH para desplegar. Una vez hecho eso, todos los nodos gestionados se comunican con el servidor principal a través del uso de certificados y reciben el despliegue.

 

Componentes Chef

componentes Chef

  • Workstation: Uno o más workstations son configurados para crear, probar y mantener los cookbook. A menudo un Workstation se configura para usar un Chef Workstation como kit de herramientas de desarrollo.
  • Cookbook: Los cookbook se cargan en el Chef Infra Server desde un Workstation. Algunos son personalizados para la organización y otros se basan en la comunidad de cookbooks disponibles desde el Chef Supermarket.
  • Ruby: Lenguaje de programación que se utiliza en la sintaxis de los CookBook.
  • Node: Un nodo es una máquina que está bajo la administración de Chef.
  • Chef Client: Está instalado en cada nodo que está bajo la gestión de Chef. Realiza todas las tareas de configuración que están especificadas bajo una lista de ejecución que desplegará cualquier dato de configuración requerido del Chef Server.
  • Chef Server: Actúa como centro de información. Cookbooks y Policy Settings se cargan en el Chef Server por los usuarios de los Workstation. El Chef Client accede al Chef Server desde el nodo desde el que está instalado para obtener los datos de configuración, realiza búsquedas de datos históricos de ejecución de Chef Client, y descarga los datos de configuración necesarios. Cuando el Chef Client termina su ejecución, sube los datos de ejecución actualizados al Chef Server.
  • Chef Supermarket: Es la ubicación en la que se comparten y gestionan los Cookbooks de la comunidad.

Packer

Es una plataforma de infraestructura como código para automatizar y estandarizar la creación de máquinas virtuales en vario formatos.

Se configurará en un plantilla con formato JSON las características de la VM, como por ejemplo:

El proceso básico parar Packer incluye tomar una plantilla antigua o una imagen de máquina, aplicarle nuevos parches o software y crear una plantilla o AMI a partir de los resultados de esas dos acciones:

  • El ISO que lo creó.
  • La red a la que está conectada.
  • CPU y RAM.
  • Host, almacén de datos, cluster, carpeta en la que se implementará.

Los ficheros JSON se dividen en tres secciones:

  • Variables: Se pueden hacer cosas como pasar credenciales de AWS como una variable.
  • Constructores: Describe el entorno en el que se está trabajando
  • Aprovisionadores: Se define lo que se quiere que haga la máquina virtual una vez esté lista.

Terraform

Es un software de código libre que permite a partir de un lenguaje de alto nivel crear el plan de construcción de una infraestructura compleja. Permite a través de ficheros JSON definir, configurar y versionar infraestructura. La infraestructura se puede codificar atendiendo a las necesidades de nuestro servicio y ofrece un amplio abanico de proveedores donde desembarcar nuestra infraestructura.

Los archivos de configuración (.tf) describen en Terraform los componentes necesarios para ejecutar una sola aplicación o el centro de datos completo. Terraform genera un plan de ejecución que describe lo que hará para alcanzar el estado deseado y luego ejecuta para construir la infraestructura descrita.

Una vez codificada la infraestructura con el comando terraform apply se realizará el despliegue de la misma.

Arquitectura Terraform

Características:

  • Infraestructura como código: La infraestructura se describe utilizando una sintaxis de alto nivel. Estos archivos que describen la infraestructura pueden ser compartidos y reutilizados.
  • Planes de ejecución: Terraform tiene un paso de “planificación” donde genera un plan de ejecución. Este plan de ejecución muestra lo que hará Terraform cuando se ejecute.
  • Gráfico de recursos: Crea un gráfico con todos los recursos y paraleliza la creación y modificación de cualquier recurso. Se puede obtener información sobre las dependencias de la infraestructura.
  • Automatización de cambios: Los conjuntos de cambios complejos se pueden aplicar a su infraestructura con una mínima interacción humana.

Componentes:

  • Providers: Fuente de recursos. Es el responsable de entender las interacciones con la API y exponer los recursos. Proporciona recursos y datos. Generalmente son IaaS, PaaS o Saas Services.
  • Resource: Cualquier cosa que tenga un conjunto de atributos configurable y un ciclo de vida como creación, lectura, actualización, borrado. Implica identificación y estado. Bloque de construcción básico de los scripts de Terraform. La mayoría de tipos de infraestructura se puede representar como un Resource de Terraform.
  • Data: Información a leer por Providers. Data Sources permite recuperar o calcular datos para usar en cualquier parte de la configuración de Terraform. Son esencialmente un subconjunto de recursos de solo lectura
  • Provisioner: Inicializa un recurso desde un script local o remoto. Se agregan directamente a cualquier recurso. Son usados para ejecutar scripts en máquinas locales o remotas como parte de creación o destrucción de recursos, para arrancar un recurso, hacer limpieza tras destrucción, ejecutar gestión de la configuración,…
  • Terraform State: Almacena el estado de la gestión de la infraestructura y configuración. Es usado para mapear recursos en la configuración, hacer seguimiento de metadatos, y mejorar el rendimiento de grandes infraestructuras. El estado es almacenado por defecto en un fichero local llamado “terraform.tfstate”, pero también se puede almacenar remotamente.

 

Estos servicios y productos complementan a otros servicios de implantación y administración como puede ser el Administrador de Recursos de Azure (ARM) que veremos en el próximo artículo.

 

 

 

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA