Bluetab

an IBM Company

Practices

Hashicorp Boundary

by

Hashicorp Series Boundary

Javier Pérez

DevOps Engineer

Javier Rodriguez

Cloud DevOps

Jorge de Diego

Cloud DevOps Engineer

Después de la última HashiConf Digital, desde la Práctica Cloud os queremos enseñar una de las principales novedades que fueron presentadas: Boundary. En este post vamos a comentar qué es esta nueva herramienta, por qué es interesante, qué nos ha parecido y cómo lo hemos probado.

¿Qué es Hashicorp Boundary?

Hashicorp Boundary es, como ellos mismos declaran, una herramienta que permite acceder a cualquier sistema utilizando la identidad como pieza fundamental. ¿Esto qué significa? Tradicionalmente, cuando un usuario adquiere el permiso de acceder a un servicio remoto, también obtiene el permiso explícito a la red donde se encuentra ubicado. Sin embargo, Boundary nos proporcionará un sistema basado en el mínimo privilegio posible cuando los usuarios necesitan acceder a aplicaciones o máquinas. Por ejemplo, es una forma de acceder mediante SSH a un único servidor utilizando como método de autenticación unas claves efímeras.

Esto quiere decir que Boundary limita a qué recursos te puedes conectar y además gestiona los diferentes permisos y accesos a los recursos con una autenticación.

Es especialmente interesante porque en el futuro va a estar marcado por la fuerte integración que tendrá con otras herramientas de Hashicorp, especialmente con Vault para la gestión de credenciales, así como con sus funciones de auditoria.

Por si tenéis curiosidad, Hashicorp ha liberado el código fuente de Boundary el cual tenéis disponible en Github y la documentación oficial la podréis leer en su pagina web: boundaryproject.

¿Cómo hemos puesto a prueba Boundary?

Partiendo de un proyecto de Hashicorp de ejemplo, se ha desarrollado una pequeña prueba de concepto que despliega Boundary en un escenario hybrid-cloud en AWS y GCP. Aunque la arquitectura de referencia no decía nada con respecto a este diseño, nosotros hemos querido darle una vuelta y montar un pequeño escenario multi-cloud para ver cómo se comporta este nuevo producto.

La arquitectura final a grandes rasgos es:

Una vez desplegada la infraestructura y configurada la aplicación hemos probado a conectarnos a las instancias mediante SSH. Todo el código fuente se basa en terraform 0.13 y lo podréis encontrar en Bluetab-boundary-hybrid-architecture, en donde también encontraréis un README detallado que especifica las acciones que tenéis que seguir para reproducir el entorno, en particular:

  1. Autenticación con vuestro usuario (previamente configurado) en Boundary. Para ello apuntamos al endpoint correspondiente a los controladores de Boundary y ejecutamos el comando boundary authenticate.

  2. Ejecutar el comando boundary connect ssh con los argumentos necesarios para apuntar a nuestro target (El target representa una o más máquinas o endpoints).

En este escenario particualr, el target se compone de dos máquinas diferentes: una en AWS y otra en GCP. Si a Boundary no se le indica a qué máquina en concreto se quiere acceder de ese target, Boundary proporcionará acceso de forma aleatoria a una de ellas. De manera automática una vez seleccionada la máquina a la que se quiere acceder, Boundary enrutará la petición hacia el worker adecuado, que es el que tiene acceso a dicha máquina.

¿Qué nos ha gustado?

  • La facilidad de configuración. Boundary sabe perfectamente a qué worker tiene que dirigir la petición teniendo en cuenta a qué servicio o máquina se está solicitando el acceso. Como todo el despliegue (tanto infraestructura como aplicación) se ha hecho desde terraform, la salida de un despliegue sirve como entrada del otro y está todo perfectamente integrado.

  • Ofrece tanto interfaz gráfica como acceso CLI. Aunque aún está en una fase muy temprana del desarrollo, el mismo binario de Boundary ofrece (cuando es configurado como controller) una interfaz gráfica muy limpia, con el mismo estilo que las diferents herramientas de Hashicorp. Sin embargo, no todas las funcionalidades se pueden realizar actualmente desde la interfaz, por lo que es necesario utilizar la CLI.

¿Qué hemos echado en falta?

  • La integración con Vault y los indentity providers (IdPs) todavía esta en el roadmap y hasta siguientes versiones no es seguro que se incluya.

  • La gestión actual del JWT token del cliente de Boundary hacia el control-plane que implica instalar una herramienta para la gestión de secretos.

¿Qué nos falta por probar?

Teniendo en cuenta el nivel de avance del desarrollo del producto actual, nos faltaría por entender y probar para:

  • Gestión de accesos modificando políticas a diferentes usuarios.

  • Realizar una investigación más profunda en los componentes que sirven para gestionar los recursos (scopes, organizations, host sets, etc.)

¿Por qué creemos que este producto tiene potencial?

Una vez que el producto vaya cumpliendo fases en el roadmap que Hashicorp ha declarado, simplificará muchísimo la gestión de accesos a máquinas a través de bastiones en las organizaciones. Se podrá gestionar el acceso a una máquina simplemente añadiendo o modificando los permisos que un usuario posee, sin tener que distribuir claves ssh, realizar operaciones manuales en las máquinas, etc.

En resumen, este producto nos brinda una nueva forma de gestionar accesos a diferentes recursos. No solamente mediante SSH, sino que será una forma de gestionar accesos mediante roles a máquinas, bases de datos, portales, etc. minimizando el posible vector de ataque cuando se dan permisos a contratistas. Además se presenta como una herramienta gratuita y opensource, que se integrará muy eficazmente si se tiene el ecosistema de Hashicorp desplegado, pero también servirá en caso contrario sin necesidad del resto de herramientas de esta compañía.

Y una cosa más...

Nos surgió un problema causado por la forma en la que se persistía la información sobre las direcciones de red de los controllers y los workers para su posterior comunicación. Después de hacer funcionar la prueba de concepto mediante un workaround basado en iptables decidimos abrir una https://github.com/hashicorp/boundary/issues/758 en Github. En literalmente un día, nos resolvieron la incidencia actualizando su código. Nos descargamos la nueva versión del código, lo probamos y funcionó a la perfección. Punto a favor para Hashicorp por la rapidez de respuesta y la eficiencia que demostraron. Además, recientemente ha sido liberada la nueva release de Boundary, la cual incluye entre muchas otras cosas, el fix a esta issue Boundary v0.1.2.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Espiando a tu kubernetes con kubewatch

by

Espiando a tu Kubernetes con Kubewatch

Bluetab

Desde la Práctica Cloud queremos impulsar la adopción de la nube como forma de trabajo en el mundo de IT. Para ayudar en esta tarea, vamos a publicar multitud de artículos de buenas prácticas y casos de uso, otros hablarán aquellos servicios clave dentro de la nube.

En esta ocasión hablaremos de Kubewatch.

¿Qué es Kubewath?

Kubewatch es una utilidad desarrollada por Bitnami Labs que permite el envío de notificaciones a distintos sistemas de comunicación.

Los webhooks soportados son:

  • Slack
  • Hipchat
  • Mattermost
  • Flock
  • Webhook
  • Smtp

Integración de kubewatch con Slack

Las imágenes disponibles están publicadas en el GitHub de bitnami/kubewatch

Si queréis, podéis descargaros la última versión para probarla en vuestro entorno local:

$ docker pull bitnami/kubewatch

Una vez dentro del contenedor podéis jugar con las opciones:

$ kubewatch -h

Kubewatch: A watcher for Kubernetes

kubewatch is a Kubernetes watcher that publishes notifications
to Slack/hipchat/mattermost/flock channels. It watches the cluster
for resource changes and notifies them through webhooks.

supported webhooks:
 - slack
 - hipchat
 - mattermost
 - flock
 - webhook
 - smtp

Usage:
  kubewatch [flags]
  kubewatch [command]

Available Commands:
  config      modify kubewatch configuration
  resource    manage resources to be watched
  version     print version

Flags:
  -h, --help   help for kubewatch

Use "kubewatch [command] --help" for more information about a command.

¿De qué tipos de recursos podemos obtener notificaciones?

¿Cuándo recibiremos una notificación?

En cuanto haya una acción sobre algún objeto de kubernetes, así como creación, destrucción o actualización.

Configuración

En primer lugar, crearemos un canal de slack y le asociaremos un webhook. Para ello, iremos a la sección de Apps de Slack, buscaremos “Incoming WebHooks” y pulsaremos “Add to Slack”:

En el caso de no tener aún un canal creado para este propósito daremos de alta uno nuevo:

En este ejemplo, el canal a crear se llamará “k8s-notifications”. Posteriormente debemos configurar el webhook, yendo para ello al panel de “Incoming WebHooks” y añadiendo una nueva configuración donde tendremos que seleccionar el nombre del canal al que queremos enviar notificaciones. Una vez seleccionado, la configuración nos devolverá una «Webhook URL» que será la que utilicemos para configurar Kubewatch. Opcionalmente, tenemos la posibilidad de seleccionar el icono (opción «Customize Icon») con el que visualizaremos la recepción de eventos y el nombre con el que llegarán (opción “Customize Name”).

En este punto ya estamos listos para configurar los recursos de kubernetes. En el GitHub de Kubewatch tenemos algunos ejemplos de manifiestos y también la opción de instalación por Helm. Sin embargo, aquí construiremos los nuestros propios.

En primer lugar, crearemos un fichero “kubewatch-configmap.yml” con el ConfigMap que servirá para configurar el contenedor de kubewatch:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubewatch
data:
  .kubewatch.yaml: |
    handler:
      webhook:
        url: https://hooks.slack.com/services/<your_webhook>
    resource:
      deployment: true
      replicationcontroller: true
      replicaset: false
      daemonset: true
      services: true
      pod: false
      job: false
      secret: true
      configmap: true
      persistentvolume: true
      namespace: false

Simplemente tendremos que activar con “true” o desactivar con «false» los tipos de recursos sobre los que queremos recibir notificaciones. Asimismo, establecemos la url del Incomming Webhook que dimos de alta previamente.

Ahora, para que nuestro contenedor tenga acceso a los recursos de kubernetes a través de su api vamos a dar de alta el fichero “kubewatch-service-account.yml” con un Service Account, un Cluster Role y un Cluster Role Binding:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubewatch
rules:
- apiGroups: ["*"]
  resources: ["pods", "pods/exec", "replicationcontrollers", "namespaces", "deployments", "deployments/scale", "services", "daemonsets", "secrets", "replicasets", "persistentvolumes"]
  verbs: ["get", "watch", "list"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubewatch
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kubewatch
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubewatch
subjects:
  - kind: ServiceAccount
    name: kubewatch
    namespace: default

Por último, crearemos un fichero “kubewatch.yml” para desplegar la aplicación:

apiVersion: v1
kind: Pod
metadata:
  name: kubewatch
  namespace: default
spec:
  serviceAccountName: kubewatch
  containers:
  - image: bitnami/kubewatch:0.0.4
    imagePullPolicy: Always
    name: kubewatch
    envFrom:
      - configMapRef:
          name: kubewatch
    volumeMounts:
    - name: config-volume
      mountPath: /opt/bitnami/kubewatch/.kubewatch.yaml
      subPath: .kubewatch.yaml
  - image: bitnami/kubectl:1.16.3
    args:
      - proxy
      - "-p"
      - "8080"
    name: proxy
    imagePullPolicy: Always
  restartPolicy: Always
  volumes:
  - name: config-volume
    configMap:
      name: kubewatch
      defaultMode: 0755

Vemos que el valor de la clave “mountPath” será la ruta del fichero donde se escribirá la configuración de nuestro ConfigMap dentro del contenedor (/opt/bitnami/kubewatch/.kubewatch.yaml). Podemos ampliar aquí la información sobre cómo montar configuraciones en kubernetes. En este ejemplo, vemos que nuestro despliegue del aplicativo será a través de un único pod. Evidentemente, en un sistema productivo tendríamos que definir un Deployment con el número de réplicas que consideremos convenientes para tenerlo así siempre activo, aun en caso de pérdida del pod.

Una vez listos los manifiestos vamos a aplicarlos a nuestro clúster:

$ kubectl apply  -f kubewatch-configmap.yml -f kubewatch-service-account.yml -f kubewatch.yml

En unos pocos segundos tendremos listo el servicio:

$ kubectl get pods |grep -w kubewatch

kubewatch                                  2/2     Running     0          1m

El pod de kubewatch tiene asociado dos contenedores: kubewatch y kube-proxy, este último para atacar a la API.

$   kubectl get pod kubewatch  -o jsonpath='{.spec.containers[*].name}'

kubewatch proxy

Verificamos a través de los logs que ambos contenedores han levantado correctamente y sin mensajes de error:

$ kubectl logs kubewatch kubewatch

==> Config file exists...
level=info msg="Starting kubewatch controller" pkg=kubewatch-daemonset
level=info msg="Starting kubewatch controller" pkg=kubewatch-service
level=info msg="Starting kubewatch controller" pkg="kubewatch-replication controller"
level=info msg="Starting kubewatch controller" pkg="kubewatch-persistent volume"
level=info msg="Starting kubewatch controller" pkg=kubewatch-secret
level=info msg="Starting kubewatch controller" pkg=kubewatch-deployment
level=info msg="Starting kubewatch controller" pkg=kubewatch-namespace
... 
$ kubectl logs kubewatch proxy

Starting to serve on 127.0.0.1:8080

Podríamos igualmente acceder al contenedor de kubewatch para probar la cli, ver la configuración, etcétera:

$  kubectl exec -it kubewatch -c kubewatch /bin/bash

¡Ya tenemos listo nuestro notificador de eventos!

Ahora toca probar. Utilizaremos, por ejemplo, la creación de un deployment para testear el correcto funcionamiento:

$ kubectl create deployment nginx-testing --image=nginx
$ kubectl logs -f  kubewatch kubewatch

level=info msg="Processing update to deployment: default/nginx-testing" pkg=kubewatch-deployment

Los logs ya nos avisan que se ha detectado el nuevo evento, así que vamos a nuestro canal de slack para verificarlo:

¡El evento ha sido notificado correctamente!

Ya podemos eliminar el deployment de prueba:

$ kubectl delete deploy nginx-testing

Conclusiones

Evidentemente, Kubewatch no suple a los sistemas básicos de alerta y monitorización que todo orquestador productivo debe mantener, pero nos proporciona una manera fácil y eficaz de ampliar nuestro control sobre la creación y modificación de los recursos en kubernetes. En este caso de ejemplo, hemos realizado una configuración de kubewatch transversal a todo el clúster, “espiando” todo tipo de eventos, algunos quizá inservibles si mantenemos una plataforma como servicio, pues nos enteraríamos de cada uno de los pods creados, eliminados o actualizados por cada equipo de desarrollo en su propio namespace, lo cual es usual, legítimo y no aporta valor. Quizá sea más conveniente filtrar por los namespaces sobre cual queremos recibir notificaciones, como por ejemplo de kube-system, que es donde albergaremos generalmente nuestros servicios administrativos y donde solo los administradores deben tener acceso. En ese caso, simplemente tendremos que especificar el namespace en nuestro ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubewatch
data:
  .kubewatch.yaml: |
    namespace: "kube-system"
    handler:
      webhook:
        url: https://hooks.slack.com/services/<your_webhook>
    resource:
      deployment: true
      replicationcontroller: true
      replicaset: false

Otra utilidad interesante puede ser “escuchar” a nuestro clúster tras un ajuste signicativo de la configuración como, por ejemplo, de nuestra estrategia de autoescalado, herramientas de integración, etcétera, pues siempre nos notificará los scale up y scale down, pudiendo ser interesante sobre todo en un momento inicial. En definitiva, Kubewatch amplía el control sobre los clústeres, siendo nosotros quienes decidamos el alcance que le damos. En sucesivos artículos veremos cómo gestionar los logs y las métricas de forma productiva.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Introducción a los productos de HashiCorp

by

Introducción a los productos de HashiCorp

Jorge de Diego

Cloud DevOps Engineer

Desde la Práctica Cloud queremos impulsar el uso de los productos Hashicorp y por ello vamos a publicar artículos temáticos sobre cada uno de ellos.

Debido a la multitud de posibilidades que ofrecen sus productos, en éste artículo abordaremos una visión de conjunto y en publicaciones posteriores, entraremos en detalle de cada uno de ellos, aportando casos de uso no convencionales que muestren el potencial que tienen los productos de Hashicorp.

¿Por qué Hashicorp?

Durante estos últimos años, Hashicorp viene desarrollando diferentes productos Open Source los cuales ofrecen una gestión transversal de la infraestructura en entornos Cloud y on-premises. Estos productos, han marcado estándares en la automatización de infraestructura.

En la actualidad, sus productos aportan soluciones robustas en los ámbitos del aprovisionamiento, seguridad, interconexión y coordinación de cargas de trabajo.

El código fuente de sus productos está liberado bajo licencia MIT, lo cual ha tenido una gran acogida dentro de la comunidad Open Source (cuentan con más de 100 desarrolladores aportando mejoras de forma continua)

Además de los productos que expondremos en este artículo, disponen de interesantes soluciones Enterprise.

Respecto al impacto que tienen sus soluciones, poniendo como ejemplo Terraform, se ha convertido en un referente en el mercado. Esto significa que Hashicorp está haciendo las cosas bien, por lo que es conveniente entender y aprender a usar sus soluciones.

Aunque nos estemos centrando en su uso en el ámbito Cloud, sus soluciones tiene gran presencia en los entornos on-premises, pero alcanzan todo su potencial cuando trabajamos en la nube.

¿Cuáles son estos productos?

Hashicorp cuenta con los siguientes productos:

  • Terraform: infraestructura como código.
  • Vagrant: máquinas virtuales para entornos de pruebas.
  • Packer: construcción de imágenes de forma automatizada.
  • Nomad: “orquestador” de cargas de trabajo.
  • Vault: gestión de secretos y protección de datos.
  • Consul: gestión y descubrimiento de servicios en entornos distribuidos.


A continuación, resumimos las principales características de los productos. En próximas publicaciones entraremos en detalle de cada uno de ellos.

Terraform se ha posicionado como el producto más extendido en el ámbito del aprovisionamiento de Infraestructura como Código.

Utiliza un lenguaje específico (HCL) para desplegar infraestructura a través del uso de los diferentes proveedores de Cloud. Terraform también permite gestionar recursos de otras tecnologías o servicios, como Gitlab o Kubernetes.

Terraform hace uso de un lenguaje declarativo y se basa en tener desplegado exactamente lo que pone en el código.

El típico ejemplo que se muestra para entender la diferencia con el paradigma que sigue por ejemplo Ansible (procedimental) es:

En un primer momento queremos desplegar 5 instancias EC2 en AWS:

Ansible:

- ec2:
    count: 5
    image: ami-id
    instance_type: t2.micro

Terraform:

resource "aws_instance" "ejemplo" {
  count         = 5
  ami           = "ami-id"
  instance_type = "t2.micro"
}

Como puede observarse, no existen prácticamente diferencias entre los códigos. Ahora necesitamos desplegar dos instancias más para hacer frente a una carga de trabajo mayor:

Ansible:

- ec2:
    count: 2
    image: ami-id
    instance_type: t2.micro

Terraform:

resource "aws_instance" "ejemplo" {
  count         = 7
  ami           = "ami-id"
  instance_type = "t2.micro"
}

En este momento, podemos ver que mientras en Ansible estableceríamos en 2 el número de instancias a desplegar para que en total haya 7 desplegadas, en Terraform estableceríamos el número directamente a 7 y Terraform sabe que tiene que desplegar 2 más porque ya hay 5 desplegadas.

Otro aspecto importante es que Terraform no necesita un server Master como Chef o Puppet. Es una herramienta distribuida cuyo elemento común y centralizado es el tfstate (se explica en el siguiente párrafo). Se lanza desde cualquier sitio con acceso al tfstate (que puede ser remoto, guardado en un almacenamiento común como puede ser AWS S3) y terraform instalado, el cual se distribuye como un binario descargable desde la web de Hashicorp.

El último punto a comentar sobre Terraform es que se basa en un archivo denominado tfstate en el que va guardando y actualizando la información relativa al estado de la infraestructura, y el cual va a consultar para conocer si es necesario realizar cambios sobre la misma. Es muy importante tener en cuenta que este estado es lo que conoce Terraform. Terraform no va a conectarse a AWS para ver qué hay desplegado. Por ello es necesario no realizar cambios a mano sobre infraestructura desplegada por Terraform (ni nunca. Cambios a mano, nunca), ya que no se actualiza el tfstate y por tanto se crearán inconsistencias.

Vagrant permite desplegar entornos de test de manera local de forma rápida y muy simple, basados en código. Por defecto utiliza por debajo VirtualBox, pero es compatible con otros providers como por ejemplo VMWare o Hyper-V. Es posible desplegar máquinas sobre proveedores Cloud como AWS instalando plugins. Personalmente no encuentro la ventaja de usar Vagrant para esta función.

Las máquinas que despliega se basan en boxes, y desde el código se indica qué box se quiere desplegar. En este aspecto podría compararse en modo de funcionamiento con Docker. Sin embargo, la base es totalmente distinta. Vagrant levanta máquinas virtuales con una herramienta de virtualización por debajo (VirtualBox) mientras que Docker despliega contenedores y su soporte es una tecnología de contenerización Vagrant VS Docker.

Casos de uso típicos pueden ser probar playbooks de Ansible, recrear un entorno de laboratorio de manera local en muy pocos minutos, realizar alguna demo, etc.

Vagrant se basa en un archivo Vagrantfile. Una vez situado en el directorio donde se encuentra este Vagrantfile, con ejecutar vagrant up, la herramienta comienza a desplegar lo que se indique dentro de dicho archivo.

Los pasos para lanzar una máquina virtual con Vagrant son:

1- Instalar Vagrant. Se distribuye como un binario al igual que el resto de productos de Hashicorp.

2- Con un Vagrantfile de ejemplo:

Vagrant.configure("2") do |config|
  config.vm.box = "gbailey/amzn2"
end

PD: (el parámetro 2 dentro de configure se refiere a la versión de Vagrant, que me ha tocado mirarlo para el post)

3- Ejecutar dentro del directorio donde se encuentra el Vagrantfile

vagrant up

4- Entrar por ssh a la máquina

vagrant ssh

5- Destruir la máquina

vagrant destroy

Vagrant se encarga de gestionar el acceso ssh creando una clave privada y almacenándola en el directorio .vagrant, aparte de otros metadatos. Se puede acceder a la máquina ejecutando vagrant ssh. También es posible visualizar las máquinas desplegadas en la aplicación de VirtualBox.

Con Packer puedes construir imágenes de máquinas de forma automatizada. Puede utilizarse para, por ejemplo, construir una imagen en un proveedor Cloud como AWS con una configuración inicial ya realizada y poder desplegarla un número indeterminado de veces. De esta forma solo es necesario aprovisionar una sola vez y al desplegar la instancia con esa imagen ya tendrá la configuración deseada sin tener que invertir mayor tiempo en aprovisionarla.

Un pequeño ejemplo sería:

1- Instalar Packer. De la misma forma, es un binario que habrá que colocar en una carpeta que se encuentre en nuestro path.

2- Crear un archivo, por ejemplo builder.json. También se crea un pequeño script en bash (el link que se muestra en builder.json es dummy):

{
  "variables": {
    "aws_access_key": "{{env `AWS_ACCESS_KEY_ID`}}",
    "aws_secret_key": "{{env `AWS_SECRET_ACCESS_KEY`}}",
    "region": "eu-west-1"
  },
  "builders": [
    {
      "access_key": "{{user `aws_access_key`}}",
      "ami_name": "my-custom-ami-{{timestamp}}",
      "instance_type": "t2.micro",
      "region": "{{user `region`}}",
      "secret_key": "{{user `aws_secret_key`}}",
      "source_ami_filter": {
        "filters": {
            "virtualization-type": "hvm",
            "name": "amzn2-ami-hvm-2*",
            "root-device-type": "ebs"
        },
        "owners": ["amazon"],
        "most_recent": true
      },
      "ssh_username": "ec2-user",
      "type": "amazon-ebs"
    }
  ],
  "provisioners": [
    {
        "type": "shell",
        "inline": [
            "curl -sL https://raw.githubusercontent.com/example/master/userdata/ec2-userdata.sh | sudo bash -xe"
        ]
    }
  ]
}

Los proveedores utilizan software integrado y de terceros para instalar y configurar la imagen de la máquina después del arranque. Nuestro ejemplo ec2-userdata.sh

yum install -y \
  python3 \
  python3-pip \

pip3 install cowsay

3- Ejecutar:

packer build builder.json

Y ya tendríamos una AMI aprovisionada con cowsay instalado. Ahora nunca más será necesario que, como primer paso tras lanzar una instancia, sea necesario instalar cowsay porque ya lo tendremos de base, como debe ser.

Como es de esperar, Packer no solo funciona con AWS sino con cualquier proveedor Cloud como Azure o GCP. También funciona con VirtualBox y VMWare y una gran lista de builders. Además, se puede crear una imagen anidando builders en el archivo de configuración de Packer que sea igual para distintos proveedores _Cloud. Esto es muy interesante para entornos multi-cloud en los que haya que replicar diferentes configuraciones.

Nomad es un orquestador de cargas de trabajo. A través de sus Task Drivers ejecutan una tarea en un entorno aislado. El caso de uso más común es orquestar contenedores Docker. Tiene dos actores básicos: Nomad Server y Nomad Client. Ambos actores se ejecutan con el mismo binario pero diferente configuración. Los Servers organizan el cluster mientras que los Agents ejecutan las tareas.

Un pequeño “Hello-world” en nomad podría ser:

1- Descargar e instalar Nomad y ejecutarlo (en modo development, este modo nunca debe usarse en producción):

nomad agent -dev

Una vez hecho esto ya es posible acceder a la UI de nomad en localhost:4646

2- Ejecutar un job de ejemplo que lanzará una imagen de grafana

nomad job run grafana.nomad

grafana.nomad:

job "grafana" {
    datacenters = [
        "dc1"
    ]

    group "grafana" {
        task "grafana"{
            driver = "docker"

            config {
                image = "grafana/grafana"
            }

            resources {
                cpu = 500
                memory = 256

            network {
                mbits = 10

                port "http" {
                    static = "3000"
                }
            }
            }
        }
    }
}

3- Acceder a localhost:3000 para comprobar que se puede acceder a grafana y acceder a la UI de Nomad (localhost:4646) para ver el job

4- Destruir el job

nomad stop grafana

5- Parar el agente de Nomad. Si se ha ejecutado tal y como se ha indicado aquí, con pulsar Control-C en la terminal donde se está ejecutando bastará

En resumen, Nomad es un orquestador muy ligero, al contrario que Kubernetes. Lógicamente no tiene las mismas funcionalidades que Kubernetes pero ofrece la posibilidad de ejecutar cargas de trabajo en alta disponibilidad de forma sencilla y sin necesidad de usar gran cantidad de recursos. Se tratarán ejemplos con más detalle en el post de Nomad que se publicará en un futuro.

Vault se encarga de gestionar secretos. A través de su api los usuarios o aplicaciones pueden pedir secretos o identidades. Estos usuarios se autentican en Vault, el cual tiene conexión a un proveedor de identidad de confianza como un Active Directory, por ejemplo. Vault funciona con dos tipos de actores al igual que otras de las herramientas mencionadas, Server y Agent.

Al inicializar Vault, comienza en estado sellado (Seal) y se generan diferentes tokens para deshacer el sellado (Unseal). Un caso de uso real sería demasiado largo para este artículo y se verá en detalle en el artículo destinado únicamente a Vault. Sin embargo, se puede descargar y probar en modo dev al igual que se ha mecionado antes con Nomad. En este modo, Vault se inicializa en modo Unsealed , almacenando todo en memoria sin necesidad de autenticación, sin utilizar TLS y con una única clave de sellado. De esta forma podremos jugar con sus funcionalidades y explorarlo de una manera rápida y sencilla.

Consultar en este enlace para mayor información.

1- Instalar Vault. Al igual que el resto de productos de Hashicorp, se distribuye como un binario a través de su web. Una vez hecho, lanzar (este modo nunca debe usarse en producción):

vault server -dev

2- Vault mostrará el token de root que sirve para autenticarse contra Vault. También mostrará la única clave de sellado que crea. Ahora Vault es accesible a través de localhost:8200

3- En otra terminal, exportar las siguientes variables para poder hacer pruebas:

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_DEV_ROOT_TOKEN_ID="token-showed-when-running-vault-dev"

4- Crear un secreto (En la terminal en la que se han exportado las variables anteriores)

vault kv put secret/test supersecreto=iewdubwef293bd8dn0as90jdasd

5- Recuperar ese secreto

vault kv get secret/test

Estos pasos son el Hello World de Vault, para comprobar su funcionamiento. En el artículo de Vault veremos de forma detallada el funcionamiento y la instalación de Vault, así como más características como las policies, explorar la UI, etc.

Consul sirve para crear una red de servicios. Funciona de forma distribuida y un cliente de consul se ejecutará en una localización en la que existan servicios que se quieran registrar. Consul incluye Health Checking de servicios, una base de datos de clave valor y funcionalidades para securizar el tráfico de red. Al igual que Nomad o Vault, Consul tiene dos actores principales, Server y Agent.

De la misma manera que hemos hecho con Nomad y Vault, vamos a ejecutar Consul en modo dev para mostrar un pequeño ejemplo definiendo un servicio:

1- Instalar Consul. Crear una carpeta de trabajo y dentro de la misma crear un archivo json con un servicio a definir (ejemplo de nombre de carpeta: consul.d).

Archivo web.json (ejemplo de la web de Hashicorp):

{
  "service": {
    "name": "web",
    "tags": [
      "rails"
    ],
    "port": 80
  }
}

2- Ejecutar el agente de Consul indicándole el directorio de configuración creado antes donde se encuentra web.json (este modo nunca debe usarse en producción):

consul agent -dev -enable-script-checks -config-dir=./consul.d

3- A partir de ahora, aunque no hay nada realmente ejecutándose en el puerto indicado (80), se ha creado un servicio con un nombre DNS al que se puede preguntar para poder acceder al mismo a través de dicho nombre DNS. Su nombre será NAME.service.consul. En nuestro caso NAME es web. Ejecutar para preguntar:

dig @127.0.0.1 -p 8600 web.service.consul

Nota: Consul por defecto se ejecuta en el puerto 8600.

De la misma manera se puede preguntar por un record de tipo SRV:

dig @127.0.0.1 -p 8600 web.service.consul SRV

También se puede preguntar a través de los tags del servicio (TAG.NAME.service.consul):

dig @127.0.0.1 -p 8600 rails.web.service.consul

Y se puede consultar a través de la API:

curl http://localhost:8500/v1/catalog/service/web

Nota final: Consul se utiliza como complemento a otros productos, ya que sirve para crear servicios sobre otras herramientas ya desplegadas. Es por ello que este ejemplo no es demasiado ilustrativo. Aparte del artículo específico de Consul, se encontrará como ejemplo en otros artículos como en el de Nomad.

En futuros artículos se explicará también Consul Service Mesh para interconexión de servicios a través de sidecars proxies, la federación de Datacenters de Nomad en Consul para realizar despliegues o las intentions, que sirven para definir reglas de con qué servicios puede comunicarse otro servicio.

Conclusiones

Todos estos productos tienen un gran potencial en sus respectivos ámbitos y ofrecen una gestión transversal que puede ayudar a evitar el famoso vendor lock-in de los proveedores de Cloud. Pero lo más importante es su interoperabilidad y compatibilidad.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Jorge de Diego
Cloud DevOps Engineer

Mi nombre es Jorge de Diego y estoy especializado en entornos Cloud. Trabajo habitualmente con AWS aunque tengo conocimientos sobre GCP y Azure. Entré en Bluetab en septiembre de 2019 y desde entonces trabajo de Cloud DevOps y tareas de seguridad. Me interesa todo lo relacionado con la tecnología y en especial, los ámbitos de modelos de seguridad e Infraestructura. Podréis identificarme en la oficina por los pantalones cortos.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Conceptos básicos de AWS Glue

by

Conceptos básicos de AWS Glue

Álvaro Santos

Senior Cloud Solution Architect​

Desde la Práctica Cloud queremos impulsar la adopción de la nube como forma de trabajo en el mundo de IT. Para ayudar en esta tarea, vamos a publicar multitud de artículos de buenas prácticas y casos de uso, otros hablarán aquellos servicios clave dentro de la nube.

A continuación os vamos a presentar los conceptos básicos de AWS Glue.

¿Qué es AWS Glue?

AWS Glue es uno de esos servicios de AWS que son relativamente nuevos pero que tienen un enorme potencial. En especial este servicio puede ser muy beneficioso para todas aquellas empresas que trabajan con datos y que aún no posean una infraestructura de Big Data potente.

Básicamente, Glue es un servicio de ETLs totalmente administrado por AWS y de pago por uso sin necesidad de aprovisionar instancias. Para conseguirlo, combina la velocidad y potencia de Apache Spark con la organización de datos que ofrece Hive Metastore.

AWS Glue Data Catalog

El Catálogo de datos de Glue es donde se almacenan todos los orígenes y destinos de datos para los trabajos de Glue.

  • Table es la definición de una tabla de metadatos sobre las fuentes de datos y no los datos en sí. Las tablas de AWS Glue pueden referirse datos basados ​​en archivos almacenados en S3 (como Parquet, CSV…), tablas de RDBMS…

  • Database se refiere a una agrupación de fuentes de datos a las que pertenecen las tablas.

  • Connection es un enlace configurado entre AWS Glue y un cluster de RDS, Redshift u otra BBDD compatible con JDBC. Estas permiten que Glue acceda a sus datos.

  • Crawler es el servicio encargado de conectarse a un almacén de datos, avanza a través de una lista priorizada de clasificadores para determinar el esquema de los datos y de generar las tablas de metadatos. Son compatibles de determinar el esquema de datos complejos no estructurados o semi-estructurados. Ésto es especialmente importante cuando se trabajan con fuentes de datos de tipo Parquet, AVRO, …

ETL

Una ETL en AWS Glue está compuesta principalmente de los scripts y otras herramientas que utilizan los datos configurados en Data Catalog para extraer, transformar y cargar los datos en un sito definido.

  • Job es el motor principal de la ETL. Un trabajo consiste en un script que carga datos de las fuentes definidas en el catálogo y realiza transformaciones sobre ellos. Glue puede generar automáticamente un script, o se puede crear uno personalizado usando la API de Apache Spark en Python (PySpark) o Scala. Además, se permite el uso de bibliotecas externas que vinculara al trabajo mediante un archivo zip en S3.

  • Triggers se encargan de ejecutar los Jobs. Pueden ejecutarse según un cronograma, un evento de CloudWatch o incluso un comandos cron.

  • Workflows es un conjunto triggers, crawlers y jobs relacionados entre sí en AWS Glue. Con ellos se puede crear un flujo de trabajo para realizar una ETL compleja de varios pasos pero que AWS Glue puede ejecutar como entidad única.

  • ML Transforms son unos trabajos específicos que mediante modelos de Machine Learning crean transformaciones personalizadas para la limpieza de los datos como por ejemplo identificación de datos duplicados.

  • Finalmente, también es posible usar Dev Endpoints y Notebooks, que facilitan el desarrollo y probar los scripts de manera más rápida y sencilla.

Ejemplos

Script de ejemplo de ETL en Python:

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.dynamicframe import DynamicFrame
from awsglue.job import Job

args = getResolvedOptions(sys.argv, ['JOB_NAME'])

sc = SparkContext()

glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)

## Read Data from a RDS DB using JDBC driver
connection_option = {
"url": "jdbc:mysql://mysql–instance1.123456789012.us-east-1.rds.amazonaws.com:3306/database",
"user": "test",
"password": "password",
"dbtable": "test_table",
"hashexpression": "column_name",
"hashpartitions": "10"
}

source_df = glueContext.create_dynamic_frame.from_options('mysql', connection_options = connection_option, transformation_ctx = "source_df")

job.init(args['JOB_NAME'], args)

## Convert DataFrames to *AWS Glue* 's DynamicFrames Object
dynamic_df = DynamicFrame.fromDF(source_df, glueContext, "dynamic_df")

## Write Dynamic Frame to S3 in CSV format
datasink = glueContext.write_dynamic_frame.from_options(frame = dynamic_df, connection_type = "s3", connection_options = {
"path": "s3://glueuserdata"
}, format = "csv", transformation_ctx = "datasink")

job.commit()

Creación de un Job mediante línea de comandos:

aws glue create-job --name python-job-cli --role Glue_DefaultRole \

--command '{"Name" : "my_python_etl", "ScriptLocation" : "s3://SOME_BUCKET/etl/my_python_etl.py"}'

Ejecución de un Job mediante línea de comandos:

aws glue start-job-run --job-name my_python_etl

Además, AWS tiene publicado un repositorio con multitud de ejemplos de ETLs para AWS Glue.

Seguridad

Como todo servicio de AWS, está diseñado e implementado para ofrecer la mayor seguridad posible. Estas son algunas de las funcionalidades de seguridad que ofrece AWS GLUE:

  • Cifrado en Reposo: este servicio admite el cifrado de datos (SSE-S3 o SSE-KMS) en reposo para todos los objetos que trabaja (catálogo de metadatos, contraseña de conexiones, escritura o lectura de los datos de la ETL, …).

  • Cifrado en Tránsito: AWS ofrece cifrado de conexión segura (SSL) para todos los datos en movimiento, las llamadas a la API de AWS Glue y a todos los servicios de AWS como S3, RDS…

  • Registro y monitorización: está fuertemente integrado con AWS CloudTrail y AWS CloudWatch.

  • Seguridad de red: es capaz de habilitar conexiones dentro de una VPC privada y trabajar con Security Groups.

Precio

AWS factura por el tiempo de ejecución de los crawlers / jobs de ETLs y por el uso de Data Catalog.

  • Crawlers: se factura sólo por el tiempo de ejecución del crawler. El precio es de $0.44 (eu-west-1) por cada hora de DPU (4 vCPUs y 16 GB RAM) facturados en tramos de hora.

  • Data Catalog: se puede almacenar hasta un millón de objetos de manera gratuita y a partir de ahí $1.00 (eu-west-1) cada 100.000 objetos. Además, se factura $1 (eu-west-1) por cada 1.000.000 de peticiones al Data Catalog de las cuales el 1er millón es gratuito.

  • ETL Jobs: se factura sólo por el tiempo que el trabajo de ETL demore en ejecutarse. El precio es de $0.44 (eu-west-1) por cada hora de DPU (4 vCPUs y 16 GB RAM) facturados por segundo.

Beneficios

Pese a ser un servicio joven es bastante maduro y se está usando mucho por clientes del todo el mundo de AWS. Las características más importantes que nos aporta son:

  • Gestiona automáticamente el escalado de recursos, reintentos de tareas y gestión de errores automáticamente.

  • Es un servicio Serverless, AWS maneja el aprovisionamiento y escalado de los recursos para ejecutar los comandos o consultas en el entorno Apache Spark.

  • Los crawlers son capaces de rastrear tus datos, sugerir esquemas y almacenarlos en un catálogo centralizado. Además, son detectan cambios en los mismos.

  • El motor ETL de Glue genera automáticamente código Python / Scala y tiene un programador incluyendo dependencias. De este modo, facilita el desarrollo de las ETLs.

  • Usando el catálogo Glue, podemos consultar directamente los datos S3 usando Athena y Redshift Spectrum.

Conclusiones

Como toda Base de Datos, herramienta o servicio ofrecido, AWS Glue tiene ciertas limitaciones que habría que tener en cuenta para adoptarlo como servicio de ETLs. Por ello deberías tener presente que:

  • Está muy enfocado a trabajar con fuentes de datos en S3 (CSV, Parquet…) y JDBC (MySQL, Oracle…).

  • La curva de aprendizaje es alta. Si tu equipo viene del mundo de ETL tradicional, tendrás que esperar a que gane conocimientos de Apache Spark.

  • Al contrario que otras herramientas de ETLS, carece por defecto de compatibilidad con muchos servicios de terceros.

  • No es una herramienta de ETLs 100% al uso y, puesto que usa Spark, es necesario realizar optimizaciones en el código manualmente.

  • Hasta hace poco (abril 2020), AWS Glue no soportaba fuente de datos en streaming. Es demasiado prematuro usar AWS Glue como herramienta de ETLS para datos en tiempo real.
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Álvaro Santos
Senior Cloud Solution Architect

Mi nombre es Álvaro Santos y ejerzo como Solution Architect desde hace más de 5 años. Estoy certificado en AWS, GCP, Apache Spark y alguna que otras más. Entré a formar parte en Bluetab en octubre de 2018 y desde entonces estoy involucrado en proyectos cloud de Banca y Energía y además participo como Cloud Master Partitioner. Soy un apasionado de las nuevas patrones distribuidos, Big Data, Open-source software y cualquier otra cosa de mundo IT que mole.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

© 2025 Bluetab Solutions Group, SL. All rights reserved.