Esta semana hemos cerrado definitivamente nuestra tercera, y de momento, última oficina. Un espacio que tenía más de punto de encuentro social, que de lugar de trabajo.

Antes de fundar STR Sistemas, estuvimos trabajando para una empresa cuya directiva nos permitió conocer las bondades y ventajas del teletrabajo puntual. Nos quedábamos en casa todos los viernes, los días intermedios entre festivos, o si un día alguien tenía una necesidad personal.

Como fruto de aquella experiencia, en STR fuimos pioneros, sin saberlo, de lo que hoy conocemos como cultura de trabajo remoto. 

No es ningún secreto que en nuestro día a día trabajamos con Ansible e intentamos automatizar el 100% de todos los sistemas. Dentro de nuestra metodología, en muchas ocasiones, utilizamos listas para invocar reiteradamente una tarea, un role, etc.

Si has mantenido algún proyecto en AWS es muy probable que estés familiarizado con los Application Load Balancer (ALB). Se trata de un servicio administrado de AWS que facilita un balanceador elástico que actúa como la capa de aplicación, es decir, la séptima capa del modelo de interconexión de sistemas abiertos (OSI). Es ampliamente utilizado junto a los grupos de autoscaling (ASG) para ofrecer un servicio web con alta disponibilidad.

¿Quién no ha tenido que lidiar con un ataque contra sus aplicativos web o API?

En Amazon Web Services (AWS), uno de los servicios encargados de mitigar los ataques web y de bots es AWS Web Application Firewall (AWS WAF). Este tipo de ataques comunes pueden generar problemas de seguridad o un consumo elevado de los recursos de la arquitectura afectando a la disponibilidad del servicio.

AWS WAF permite controlar el tráfico que llega a las aplicaciones. Crea reglas de seguridad para limitar las peticiones que puedan ser potencialmente peligrosas como patrones de ataque comunes (ejemplo las inyecciones SQL). También permite crear reglas personalizadas que posibilita filtrar patrones específicos que conozcamos de nuestros aplicativos que puedan ser susceptibles de ser explotados por agentes externos.

Recientemente, durante nuestras labores de soporte hemos recibido una petición de un cliente que solicitaba la creación de un usuario en IAM para, a su vez, usarlo para el envío de correo a través del servicio SES de AWS. 

Por si no lo sabes, en este caso el usuario de SMTP será el Access Key del usuario IAM, mientras que la contraseña SMTP se obtiene a partir de la Secret Access Key, la  cual solo puede verse durante la creación de la Access Key.

La documentación oficial de AWS nos enseña dos formas de abordar esta situación.

Conseguir despliegues automáticos sin caídas en producción es el sueño de todo desarrollador experto, o mejor aún, que exista un despliegue continuo donde no se “lanzan despliegues”.

¡Ojo!, no es algo imposible y hay muchas formas de conseguirlo sin mucha sofisticación, pero a veces supone un sobreesfuerzo del desarrollador que para “aplicar un parchecito”, no siempre compensa.

La solución a este problema, aplicable a muchos otros, es integrar el mecanismo de despliegue en la propia infraestructura. De esta forma, se consigue hacer transparente el proceso al equipo de desarrolladores sin hacerles pasar un mal rato cada vez que aplican una mejora o nueva funcionalidad en el software de producción.

En varias ocasiones algunos de nuestros clientes nos han planteado la misma inquietud: "¿Por qué si hay varias réplicas de un pod y hay varios nodos, la pérdida de un nodo ha llegado a provocar la caída de algún servicio? ¿Por qué se pierde servicio si hay alta disponibilidad y tengo varios nodos y varias réplicas?"

Un error muy común es pensar que el planificador de kubernetes va a distribuir sí o sí todas las réplicas de un pod en diferentes nodos. Esto suele ir seguido de una breve explicación por nuestra parte sobre kubernetes y la planificación de pods.

Loki es un sistema de agregación de logs creado por GrafanaLabs, es escalable horizontalmente, puede contar con alta disponibilidad y está inspirado en Prometheus.