Bluetab

an IBM Company

Blog

Tenemos Plan B

by

Tenemos Plan B

Bluetab

El Reto Pelayo Vida patrocinado por /bluetab, siempre ha buscado lugares recónditos del planeta, localizaciones lejanas y paisajes extraordinarios, pero el mundo está viviendo una situación hasta ahora desconocida y ahora hay que velar por la seguridad de las expedicionarias. Para ello ha puesto en marcha un Plan B a la altura de las circunstancias:

Las expedicionarias partirán de Bilbao y en tres etapas, rodearán toda la península, pasando el Estrecho y parando en Málaga y Valencia para finalizar en Barcelona.

El Reto Pelayo Vida 2020 en números

millas naúticas
+ 0 mil
candidatas
0
campeona olímpica
0
de calado
0 m
pies de eslora
0
de manga
0 m

Un año más, en línea con nuestro Plan de Igualdad, los bluetabers, somos un apoyo vital para estas mujeres

¿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

Detección de Fraude Bancario con aprendizaje automático II

by

Detencción de fraude bancario con aprendizaje automático II

Bluetab

¡Un modelo para pillarlos a todos !

La creación de modelos descriptivos y predictivos se basa en la estadística y el reconocimiento de patrones de grupos con características similares. Hemos creado una metodología que permite la detección de anomalías usando el comportamiento histórico de transacciones del canal ATM para una de las entidades financieras más importantes en Latam.

Mano a mano con el cliente y un grupo de estadistas y expertos en tecnología, hemos creado una herramienta para los procesos de auditoría que facilita la detección de anomalías en los frentes más importantes y accionables para el negocio. Desde problemas operativos, de disponibilidad, errores tecnológicos, hasta fraude interno o externo.

El canal de ATMs representa una área de negocio que se encuentra sometida a contacto directo con el público usuario, y es vulnerable por razones como la conectividad y fallas de hardware. El número de transacciones diarias de una red de más de 2000 cajeros involucra una cantidad enorme de indicadores y métricas registradas tanto de carácter tecnológico, como también operativo. Actualmente un grupo de auditores se da a la tarea de muestrear y analizar de manera manual este stream de datos para identificar riesgos sobre la operativa del canal ATM.

Las características de la operativa, hacen que la tarea de reconocer patrones sea diferente para cada ATM dado que la tecnología en cada unidad y el volumen de transacciones está influenciada por factores como el fenómeno estacional, la demografía e incluso el estatus económico de la zona. Para hacer frente a este reto /bluetab desarrolló un framework alrededor de Python y SQL para la segmentación de las tipologías más adecuadas conforme a criterios variables, y la detección de anomalías sobre un conjunto de más de 40 indicadores clave para la operativa del canal. Para ello se  involucraron modelos de aprendizaje no supervisado, y  series de tiempo que nos permiten identificar entre grupos de cajeros comparables y lograr una detección de anomalías más certera.

Los resultados de este framework, puramente matemáticos, fueron condensados y traducidos en métricas de vulnerabilidad manejables para el negocio, y que desarrollamos de la mano del usuario final en Qliksense. De esta manera pusimos en manos del cliente un entorno de análisis que cubre todos los aspectos importantes de la operativa pero que además permite incorporar otras casuística a demanda.

Ahora los auditores pueden hacer análisis sobre meses de información que considera las situación temporal del mercado, la posición geográfica o las características tecnológicas y transaccionales, donde antes solo tenían capacidad para analizar muestras.

Trabajamos con nuestro cliente para impulsar iniciativas que permitan incorporar la tecnología y hacer más eficiente la operación y agilizar el tiempo de respuesta ante cualquier incidencia.

¿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

Detección de Fraude Bancario con aprendizaje automático

by

Detencción de fraude bancario con aprendizaje automático

Bluetab

El sector financiero se encuentra en la actualidad sumergido en una lucha contra el fraude bancario siendo uno de sus mayores retos. En el 2018, la banca española notificó un aumento del 17,7% de las reclamaciones producidas por cobros o transacciones indebidas con respecto al año anterior y sólo en 2017 hubo más de 123.064 fraudes online a empresas y particulares.

La banca española está encarando la batalla contra el fraude desde un punto de vista tecnoló-gico. Actualmente en pleno proceso de digitaliza-ción, con inversiones que rondan los 4.000 millo-nes de euros anuales, está dedicando sus esfuer-zos en la adopción de nuevas tecnologías como el Big Data y la Inteligencia Artificial. Con estas tecnologías se pretende mejorar y automatizar distintos procesos donde se incluye la gestión y detección del fraude.

En /bluetab estamos llevando a cabo distintas iniciativas dentro del marco tecnológico de Big Data e Inteligencia Artificial en el sector finan-ciero. En el marco de nuestras iniciativas de “Advanced Analytics & Machine Learning” nos encontramos actualmente colaborando en proyectos de Seguridad y Fraude donde, gracias al uso del Big Data y la Inteligencia Artifi-cial, somos capaces de ayudar a nuestros clien-tes a crear modelos predictivos más precisos.

Y, ¿cómo el aprendizaje automático puede ayudar a prevenir el fraude bancario?. Poniendo foco en las colaboraciones realizadas dentro del área de Fraude, /bluetab afronta este tipo de iniciativas partiendo de una serie de transferencias identificadas como fraude y de un set de datos con las sesiones de los usuarios en la banca electrónica. El reto consiste en generar un modelo capaz de predecir cuándo una sesión puede ser fraudulenta poniendo el “target” en los falsos positivos y negativos que el modelo pueda producir.

La comprensión del negocio y de los datos es de gran importancia para realizar una correcta modelación

Para la resolución de este tipo de retos tecnológicos, hemos observado cómo el uso de una meto-dología es de vital importancia para poder encarar estos retos. En /bluetab hacemos uso de una adaptación in-house y “ad-hoc” para Banca de la metodología CRISP-DM en la cual distinguimos las siguientes fases:

  • Comprensión del negocio
  • Comprensión de los datos
  • Calidad de los datos
  • Construcción de predictores inteligentes
  • Modelación


Consideramos que en los proyectos de detección de Fraude Online la comprensión del negocio y de los datos es de gran importancia para realizar una correcta modelación. Un buen análisis de los datos nos permite poder observar cómo éstos están relacionados con la variable objetivo (el fraude), así como otros aspectos estadísticos (distribución de los datos, búsqueda de outliers, etc.) de no menor importancia. En estos análisis se puede observar la existencia de variables con gran capacidad predictiva las cuales denominamos “variables diamante”. Atributos como: el número de visitas a la web, el dispositivo utilizado para la conexión, el sistema operativo o el navegador utilizado para la sesión (entre otras), suelen encontrarse fuertemente relacionadas con el fraude bancario. Además, el estudio de estas variables nos dice que, de manera individual, pueden llegar a reunir más del 90% de las transacciones fraudulentas. Es decir, el análisis y la comprensión del negocio y los datos, permite evaluar la mejor forma de plantear una solución sin vernos perdidos en un mar de datos.

Una vez se tiene el conocimiento del negocio y de los datos y tras haber obtenido aquellas varia-bles con mayor poder predictivo, es imprescindible contar con herramientas y procesos que aseguren la calidad de estas variables. Es indispensable realizar los entrenamiento de los modelos predictivos con variables y datos históricos fiables. Un entrenamiento con variables de baja calidad podría dar lugar a modelos erráticos con gran impacto dentro del negocio.

Tras asegurar la fiabilidad de las variables predictoras seleccionadas, la siguiente etapa pasa por construir variables predictoras inteligentes. Estas variables seleccionadas en los pasos anteriores, aún teniendo una fuerte relación con la variable a predecir (target) puede provocar ciertos problemas de comportamiento a la hora de realizar la modelación, es por eso que es nece-sario un paso de preparación de los datos. Esta preparación de datos pasa por realizar ciertas adaptaciones a las variables para poder ser utilizada dentro del algoritmo, como puede ser el tratamiento de nulos o el tratamiento de variables categóricas. Adicionalmente, se debe realizar un tratamiento correcto de los outliers identificados en los pasos previos, para no incluir información que pueda distorsionar el modelo.

De la misma manera, con el objetivo de “afinar” el resultado, es de vital importancia aplicar distintas transformaciones a las variables para mejorar el valor predictivo del modelo. Transformaciones matemáticas básicas como la exponencial, la logarítmica o la estandarización, junto con transformaciones más complejas como la WoE permiten poder mejorar de manera nota-ble la calidad de los modelos predictivos gracias al uso de variables más trabajadas facilitando la tarea al modelo.

Por último, la etapa de modelación se centra en enfrentar distintos tipos de algoritmos con distintas configuraciones de hiperparámetros para obtener aquél modelo que genere una mejor predicción. Aquí es donde herramientas como Spark nos ayudan en gran medida, al poder realizar entrenamientos de distintos algoritmos y configuraciones de manera rápida, gracias a la programación distribuida.

Para la sostenibilidad de su aplicación y evitar la obsolescencia del modelo, esta metodología se debe ir siguiendo de manera mensual en cada caso de uso y más a la hora de encarar una iniciativa como es el fraude bancario. Esto se debe a que pueden aparecer nuevas formas de fraude que no estén contempladas en los modelos entrenados. Por ello es importante tener entendimiento y seleccionar adecuadamente las variables con las que reentrenar los modelos, para que no se queden obsoletos con el tiempo, lo que podría perjudicar gravemente al negocio.

En definitiva, una buena metodología de trabajo es vital a la hora de enfrentarse a problemas dentro del mundo de la Inteligencia Artificial y Advanced Analytics, siendo esenciales las fases de comprensión del negocio y de los datos. Siendo un “must” en la actualidad el disponer de herramientas internas especializadas que permitan ejecutar este tipo de proyectos en pocas semanas, generando quick wins en nues-tros clientes y sus negocio

¿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

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