A menudo el performance de PostgreSQL se degrada con el tiempo cuando existe un alto volumen de lectura/escritura, lo que acaba provocando lentitud. Esto en muchas ocasiones es debido a que se produce el efecto conocido como “bloat”. No obstante, una correcta configuración y mantenimiento de PostgreSQL puede evitar estas situaciones y mantener nuestra base de datos con un rendimiento óptimo.

Al igual que muchos otros sistemas de base de datos, PostgreSQL está diseñado para permitir consultas de solo lectura de forma concurrente mientras se realizan actualizaciones de los datos. Esto es posible gracias al Multi-Version Concurrency Control (MVCC), un sistema que permite lecturas continuas generando múltiples snapshots de las transacciones y consolidándose finalmente. De esta manera se produce un mayor uso de disco para almacenar dichos snapshots, conociéndose como bloat.

En nuestro día a día, donde la tecnología y los sistemas informáticos desempeñan un papel fundamental en la operación empresarial, es esencial contar con herramientas de monitorización y observabilidad robustas que nos permitan garantizar la eficiencia y la disponibilidad de nuestros sistemas críticos. En esta ocasión, nos sumergimos en el mundo de la gestión de la monitorización, donde el Percona Monitoring y Management (PMM) ha emergido como una solución valiosa.

Esta semana hemos explorado un problema que ha capturado nuestra atención durante las últimas actualizaciones de PMM, llevándonos a descubrir un obstáculo que merece un análisis. A través de este artículo, os hablamos sobre los desafíos encontrados al realizar actualizaciones de PMM y otros problemas detectados.

Una de las herramientas con las que trabajamos diariamente es Terraform, pero ¿qué es?

Terraform es una herramienta de infraestructura como código (IaC) desarrollada por HashiCorp, siendo su objetivo principal permitirnos automatizar y gestionar la infraestructura de nuestros clientes de manera eficiente.

Una de las principales preguntas que hay que plantearse antes de comenzar a trabajar con Terraform es la organización del código, ya que lo normal en las arquitecturas es tener varios entornos: producción, preproducción, desarrollo o los que en cada caso existan.

Pues bien, para tener el código organizado por cada entorno pueden existir infinitas formas de plantearlo, pero hoy nos centraremos en dos:

• Opción 1: Mediante directorios.
• Opción 2: Uso de workspaces.

El pasado 10 de junio se publicó Debian 12, que viene bajo el nombre de “Bookworm”. Esta versión del popular sistema operativo tendrá soporte hasta 2028, y tras su salida, Debian 11 “Bullseye” ha pasado a ser oldstable aunque su soporte se mantiene hasta 2026. Mientras, Debian 10 “Stretch” pasa a ser oldoldstable y ya no recibe actualizaciones de seguridad, aunque aún tiene soporte LTS hasta el año que viene.

En este artículo vamos a comentar algunos de los cambios que más nos han llamado la atención y que creemos que se deben tener en cuenta para aquellos que vayan a actualizar a esta nueva versión. Os incluimos una guía de cómo realizar dicha actualización

¡Comenzamos!

En entornos de Kubernetes, los volúmenes persistentes desempeñan un papel crucial en el almacenamiento de datos de aplicaciones. Tener un entorno dinámico donde los recursos se crean y se destruyen de forma automática, es tan útil como peligroso si nuestros datos persistentes están entre estos recursos del cluster.

Uno de los almacenamientos más utilizados en entornos AWS es Amazon Elastic Block Store (EBS). En entornos de Kubernetes, gracias al controlador de almacenamiento externo EBS-CSI (EBS Container Storage Interface), tenemos la opción de utilizar volúmenes persistentes de EBS de manera eficiente y segura. La base radica en la capacidad de crear snapshots de volúmenes asociados a recursos de Kubernetes para manejarlos con facilidad.

Elasticsearch es un motor de búsqueda y analítica distribuido, gratuito y abierto para todos los tipos de datos, incluidos textuales, numéricos, geoespaciales, estructurados y no estructurados. Está desarrollado a partir de Apache Lucene y fue presentado por primera vez en 2010. Elasticsearch es el componente principal del Elastic Stack (ELK Stack), compuesto por Elasticsearch, Logstash y Kibana, que permite la ingesta, el enriquecimiento, el almacenamiento, el análisis y la visualización de datos.

Por su parte, Kibana es una aplicación de frontend que proporciona capacidades de visualización de datos y de búsqueda para los datos indexados en Elasticsearch, además de otras tareas de administración. Logstash es el software encargado de la ingesta, transformación y envío de los datos, en este caso a Elasticsearch.

En un artículo anterior vimos cómo realizar la instalación de un plugin en Jenkins (SSH Agent) y un pipeline con el objetivo de testar esta conexión remota por SSH.

En esta ocasión, vamos a crear un pipeline en 3 pasos: clonación de código, build y deploy. En éste, vamos a desplegar el código de sencilla aplicación node en una instancia remota.

Los englobaremos en 2 fases, la fase "sources" y la fase "deploy".

Para ello, utilizaremos un simple "Hello-world" en NodeJS cuyo código fuente puedes encontrar en este repositorio.

Según lo indicado, la definición del pipeline será la siguiente:

Unos meses atrás hicimos una pequeña introducción al servicio de WAF donde, además de hablar superficialmente de que trata este servicio y algunas configuraciones básicas, también comentamos muy brevemente que uno de sus atractivos eran las reglas administradas por AWS.

Pues bien, hoy hablaremos de estas reglas administradas y cómo podemos activarlas en nuestras WAF ACL. Algunas nociones y configuraciones básicas no las explicaremos en esta ocasión para no alargarnos mucho, pero las puedes consultar en este otro post que publicamos. 

Bien, comenzamos …