POC IOMETRICS® – Introducción y Despliegue

POC IOMETRICS® – Introducción y Despliegue

POC IOMETRICS® – Introducción y Despliegue

Tiempo de lectura: 7

Hoy en día, debido a la competencia que hay en el mercado, los clientes quieren ver los productos antes de contratarlos. De este requerimiento, por parte de los clientes, surgió la necesidad de crear un entorno temporal para mostrar nuestro producto, os contamos todo en este artículo.

Introducción

¿Qué es el entorno de PoC?

El entorno de PoC surge por la necesidad de entregar a los clientes por un tiempo determinado una muestra de nuestro producto en el que puedan meter datos reales de su infraestructura y que así puedan ver con mayor detalle lo que les podemos aportar desde Datadope.

¿Cuáles son los requerimientos básicos para la creación de este entorno?

Rápido de desplegar y eliminar

Necesitábamos que pudiese crearse y destruirse de forma rápida y ágil

Multicliente

Poder crear varias PoC independientes para distintos clientes simultáneamente

Accesible desde la infraestructura del cliente

Que se pudiesen enviar datos y acceder a ellos desde la infraestructura de los clientes

Solución Adoptada

Infraestructura

Para la infraestructura nos decidimos por la cloud de Google, ya que disponíamos de experiencia con ella y teníamos un nivel de costes bastante aceptable.

Herramientas de despliegue

JENKINS: Usamos Jenkins para lanzar tanto la creación de imágenes como la creación o destrucción de un entorno de POC

TERRAFORM: para crear los distintos elementos en GCP

Ansible: para lanzar los playbooks que ya disponemos de los distintos componentes del producto y dejarlos configurados

Arquitectura

Arquitectura alto nivel

En GCP tenemos los distintos componentes de IOMETRICS® y en el CPD del cliente desplegamos una VM (máquina virtual), que llamaremos appliance, que es la que se comunicará con los distintos endpoint que exponemos en GCP.

APPLIANCE

El appliance es un servidor que se debe desplegar del lado del cliente, para ello hacemos entrega de una imagen de VMWare are. Esta imagen contiene los siguientes componentes:

AWX: Lo usamos para hacer los automatismos en el lado del cliente que son los que poblaran la CMDB e instalarán los agentes de monitorización

Hashicorp vault: guarda las credenciales que usa AWX de forma segura

Redis y Logstash: se encargan de recoger todas las métricas de los agentes y las envían a GCP

Elastic APM: Para recolectar datos de performance

Synthetix Agent

Un agente de Synthetix que lanza las sondas sintéticas en la intranet del cliente

ARQUITECTURA GCP

En GCP desplegamos todo IOMETRICS®, para ello primero se crea una red para cada POC que se despliega, así conseguimos aislar las POC para distintos clientes, luego desplegamos todos los componentes que se intercomunican por esta red, los podemos dividir en dos grandes bloques, por un lado, SYNTHETIX el cual desplegamos usando los siguientes elementos:

CLOUD SQL – es la bbdd autogestionada de Google, en ella desplegamos el postgresql que usa synthetix

GKE: el cluster de kubernetes de Google, lo utilizamos para desplegar los componentes de synthetix

Bucket de cloud storage: para guardar los logs y resultados de las probes de synthetix

Key management: un servicio de claves en el que guardamos las keys para desencriptar el Vault de Synthetix

Balanceadores que usamos de dos tipos, los externos para exponer los servicios a internet y los internos para exponer servicios hacia las vms que tenemos en GCP

Firewall para restringir el acceso desde las IPs del cliente a los puertos que exponemos en los balanceadores externos

Y, por otro lado, el Core de IOMETRICS® que usa los siguientes elementos de GCP:
Compute para albergar las máquinas virtuales que contienen los distintos componentes de IOMETRICS®.

Balanceadores para exponer los servicios a internet.

Firewall para restringir el acceso desde las IPs del cliente a los puertos que exponemos en los balanceadores.

IAP es un servicio que establece una capa de autorización central para las aplicaciones a las que se accede a través de HTTPS, lo usamos para exponer servicios sin restricción de IP de acceso.

Despliegue de la PoC

Para desplegar la PoC como hemos indicado usamos Jenkins, para ello tenemos 3 Jobs que se encargan del despliegue en GCP:

1

Build de IOMETRICS® – Appliance

Tenemos este Job que construye imágenes de las VMs con el software de IOMETRICS® instalado y configurado para que el despliegue de una PoC sea más rápido, los pasos de este Job son:
  • Formulario: Introducción de variables
  • Docker: Levanta un contenedor
  • Credenciales: Traducción de las credenciales de Jenkins para acceder a los recursos necesarios
  • Git: Descarga el código del repositorio indicado
  • Terraform: Planifica y levanta la infraestructura indicada
  • Ansible: Configura las máquinas levantadas por terraform
  • Image Creator: Crea una imagen de las máquinas configuradas
  • Terraform Destroy: Destruye la infraestructura levantada previamente

Variables Build-IOMETRICS®

Para configurar el job que construye las imágenes de las máquinas que se levantaran en al POC son:
  • Versión: versión de IOMETRICS® a definir
  • Appliance: Si queremos hacer imagen del appliance
  • Appliance cloud: Para qué entorno va a ser la imagen del appliance. Actualmente, puede ser GCP o OST
  • Terraform plan: Terraform hace un plan de ejecución. Necesario para cualquier acción que necesite de terraform
  • Terraform create: Terraform levanta la infraestructura detectada en el plan
  • Ansible: Opción de no configurar las máquinas creadas.
  • Terraform destroy: Terraform destruye la infraestructura que esté levantada y coincida con lo que terraform plan mostró

2

POC Create

Este es el Job que despliega la PoC para un cliente, los pasos de este Job son:

  • Formulario: Introducción de variables
  • Docker: Levanta un contenedor
  • Credenciales: Traducción de las credenciales de Jenkins para acceder a los recursos necesarios
  • Git: Descarga el código del repositorio indicado
  • Terraform: Planifica y levanta la infraestructura indicada
  • Comprobar endpoints: El job espera a que los endpoints expuestos respondan para dar por buena la ejecución
Variables POC Create
Para configurar una POC para un cliente a la hora de ejecutar el job necesitaremos las siguientes variables a definir:
  • Client: Nombre del cliente
  • Version: versión de IOMETRICS® a utilizar
  • POC days: Estimación de días que la POC estará levantada, se utiliza para calcular el tamaño de los discos a asignar a cada máquina
  • GKE: Si queremos desplegar synthetix
  • Backend allow IPs: IPs del cliente a las que se le permitirá acceder al firewall

3

POC Destroy

“POC destroy “es un job muy simple en el que solo tenemos que indicarle el nombre del cliente y automáticamente se encarga de detectar la infraestructura ligada a ese cliente y hacer un terraform destroy.

Pese a que en el job de la creación de la POC le indicamos el número de días que va a estar levantada, eso no indica que en ese número de días se vaya a ejecutar este job. Es completamente manual.

Conexión Appliance - GCP

Tras el despliegue de la parte de GCP hay que desplegar el appliance en el CPD del cliente, para ello Datadope proporcionará una URL en donde poder descargar un fichero que contendrá el disco virtual del appliance, en formato .vmdk. Los requisitos mínimos de este appliance son:

  • 4 x vCPU
  • 8 GB RAM
  • 40 GB de disco

La máquina virtual que despliega el cliente tiene un usuario y contraseña proporcionados por Datadope. Dicho usuario tiene configurados permisos de root y, tras el primer login, se solicitará un cambio de la contraseña para mayor seguridad, dejando de estar dichas credenciales custodiadas por Datadope.

Configuración del appliance

Tras desplegar este appliance el cliente tendrá que lanzar el siguiente comando acabar de configurar AWX:

				
					$ sudo iometrics-provision  -c poc_name -u linux_user -kr ssh_rsa.key  -ke ssh_ecdsa.key  -wu windows_user -wp windows_pass_file -n network -vv
				
			

Donde:
poc_name (req): Nombre de la PoC, proporcionado por Datadope.
linux_user (req): Usuario para acceder a servidores Linux.
ssh_rsa.key (req): Fichero con la clave privada SSH de cifrado RSA, configurada para acceder mediante intercambio de claves con servidores Linux.
ssh_ecdsa.key (req): Fichero con la clave privada SSH de cifrado ECDSA, configurada para acceder mediante intercambio de claves con servidores Linux.
network (req): Red a escanear y monitorizar, en formato IP/mask (por ejemplo: 192.168.0.1/24).
windows_user (opc): Usuario para acceder a servidores Windows
windows_pass_file (opc): Fichero de texto que contiene la contraseña del usuario Windows.

Despliegue

Una vez el cliente haya configurado el appliance significa que ya está todo listo para hacer el despliegue de agentes en su red y que se vayan enviando datos, para ello se ejecutarán o se esperará la ejecución programada de los Jobs de AWX que se encargan de:

  • Descubrimiento de redes e IPs.
  • Descubrimiento de servidores y software.
  • Instalación y configuración de agentes de monitorización.

Al tener una conexión establecida entre su red y la montada en GCP todos los datos que rescatemos del despliegue de agentes ya llegarán a nuestros sistemas (CMDB, Elasticsearch…)

Conclusión

Partiendo de las herramientas que usamos habitualmente y el código que teníamos de desplegar los componentes, hemos conseguido desplegar en cloud y de forma ágil un entorno de pruebas lo más parecido a uno de producción, lo cual nos ayuda a dar una visión real del producto a nuestros futuros clientes.

Javi Martín

Ernesto Sánchez

Ana Ramírez

Ana Ramírez

¿Te ha resultado interesante?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

SÍGUENOS

CATEGORÍAS

ÚLTIMAS ENTRADAS