¿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.

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.

Una de las cosas que realizamos en STR con mucha frecuencia es la migración de sistemas, ya sea entre distintos proveedores o dentro de un mismo proveedor por cambio de versión, servicio o cualquier otra razón.

Recientemente se nos ha presentado un reto con el siguiente contexto:

¿Quién no ha tenido caídas de un servidor web de Apache por saturación de conexiones en una campaña de publicidad masiva sin previo aviso?

Cuando esto pasa suelen empezar las preguntas al olvidado equipo de sistemas, sobre todo de la dirección de la empresa, ¡siempre tan atenta!

• ¿Tenemos recursos hardware suficientes?
• ¿Se están aprovechando los recursos disponibles en el servidor web?
• ¿Puedes estimar cuántas peticiones se pueden atender de forma concurrente con dichos recursos?
• ¿Qué direcciones IP son las que más peticiones hacen?

Un punto importante de los sistemas en producción es el uso de los discos y su ocupación. Como no siempre trabajamos en arquitecturas desplegadas en proveedores que permiten modificar los discos en caliente, nosotros optamos por usar LVM para gestionar los puntos de montaje que requieren estar siempre montados, minimizando así pérdidas de servicio en operaciones sobre los mismos.

La forma más fácil y cómoda en estos casos es asignar un disco extra sobre la máquina y añadirlo al LVM para ampliar su capacidad. Pero esto, con el paso del tiempo ocasiona tener una gran cantidad de discos de diferentes tamaños e incluso de diferente rendimientos que puede afectar al performance de nuestro servicio o trabajos que requieran el uso de estos dispositivos de almacenamiento.