En el anterior artículo de esta serie, describimos nuestra solución de Patroni con etcd y haproxy para desplegar un servicio de PostgreSQL en alta disponibilidad.

Ha llegado el momento de configurar los servicios planificados. En este artículo configuraremos todo lo relacionado con el cluster de PostgreSQL y, en el próximo, finalizaremos con la configuración de HAproxy para acceder al cluster de forma transparente.

PostgreSQL es el segundo sistema de gestión de base de datos más popular y el más querido por los desarrolladores según la encuesta anual de StackOverflow en 2022. Además está muy vinculado con el desarrollo en python.

En este artículo vamos a configurar un cluster de PostgreSQL con alta disponibilidad.

Para contar con alta disponibilidad en un sistema de base de datos son necesarios dos puntos: replicación entre instancias y un failover automático.

En su momento, cuando comenzamos a trabajar con Ansible como una de nuestras herramientas principales para la gestión de los sistemas y configuraciones de nuestros clientes, también implementamos el uso de repositorios para contener esta información. Así, nuestro equipo podría trabajar de forma dinámica con Ansible teniendo un control de versiones de los diferentes cambios que se iban realizando.

A pesar de ello, una parte importante de la información con la que trabajamos en nuestro día a día es delicada, ya sean contraseñas, certificados o ficheros con datos sensibles, y no podrían tratarse de cualquier forma.

A todos nos ha pasado que levantamos un pod y, cuando revisamos su estado en el dashboard de Kubernetes, vemos que tanto el liveness probe como el readiness probe están fallando:

Y ahora, ¿qué?

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.