En el dinámico mundo de la gestión de contenedores y orquestación, Kubernetes se destaca como una plataforma líder que permite desplegar, escalar y gestionar aplicaciones de manera eficiente.

Entender cómo adapta sus configuraciones de forma genérica para que sea versátil en todo tipo de entornos (EKS, AKS, GKE, sistemas virtualizados o baremetal...etc.), es fundamental para permitir hacer configuraciones avanzadas.

En este artículo, exploramos un concepto que afecta directamente a la gestión del tráfico en Kubernetes: externalTrafficPolicy.

Hace unos meses realizamos un interesante artículo titulado Auditar eventos y acciones en sistemas Linux y Windows, donde mostrábamos cómo dejar reflejadas en logs las diferentes llamadas al sistema en máquinas Linux y Windows. Al final de dicho artículo recalcábamos que esta solución sólo contemplaba el tener los logs en local, y que en entornos con varios servidores, lo más conveniente era poder enviar estos logs a un sistema centralizado. Este es el tema que vamos a tratar en el artículo de hoy, centrándonos concretamente en entornos Linux.

Puesto que este artículo es una continuación del mencionado anteriormente, explicaremos cómo centralizar logs del servicio audit, pero debemos destacar que esta solución también es válida para centralizar cualquier tipo de log, ya sea de Apache, Nginx, Tomcat, MySQL o lo que necesitéis.

En la continuación de la serie sobre Patroni que encontrarás en el blog, vamos a ver cómo escalar nuestro cluster. Para ello, partimos de la base tratada en el anterior post sobre la alta disponibilidad en PostgreSQL, que si no lo has visto o necesitas refrescar la memoria, aquí te lo dejamos.

Pero… ¿Por qué escalar?

Nos referimos a escalar a la capacidad de llevar a cabo una ampliación de los recursos del mismo, cuando hablamos de un sistema informático. Si este sistema es elástico podremos, además de ampliar, reducir los recursos. Esta ampliación puede ser de dos tipos: escalado horizontal o escalado vertical. El escalado horizontal consiste en añadir más instancias como las que está prestando ya el servicio, mientras que el escalado vertical consiste en ampliar los recursos de las instancias ya existentes.

En el dinámico mundo de la gestión de bases de datos, mantenerse al día es esencial para garantizar un rendimiento óptimo, una seguridad robusta y el acceso a las últimas características y mejoras. Una de las actualizaciones más esperadas y significativas en este ámbito es la transición de MySQL 5.7 a MySQL 8. Esta actualización no solo brinda mejoras de rendimiento, sino que también introduce una serie de nuevas funciones y características que pueden transformar la forma en que su aplicación interactúa con los datos.

Uno de los trabajos que hemos realizado esta semana ha sido la puesta en marcha de una replicación nativa activo-pasivo de MySQL de uno de los servidores que contiene las bases de datos de las herramientas que usamos en el día a día. En este caso, nos gustaría compartir uno de los métodos que solemos utilizar para ello teniendo en cuenta que no hay parada de servicio.

La automatización de tareas es una parte esencial de la administración de sistemas y la gestión de infraestructuras, ¿qué duda cabe? Sus ventajas están más que demostradas, tanto para la calidad de vida de las personas como para la optimización de procesos empresariales, sobre todo en empresas que desarrollan la cultura devops en sus equipos.

Pero no siempre es así. Automatizar sistemas tiene un coste en esfuerzo, a veces elevado, que debe ser recompensado en ahorro y optimización del tiempo global empleado en la implantación y mantenimiento de forma recurrente de dichos sistemas. ¿Cuántas veces nos hemos encontrado con automatizaciones anidadas de tareas, que provisionan y configuran sistemas que han ralentizado tanto su ejecución, que se llega a cuestionar su utilidad y la vuelta a la implantación manual por los equipos de sysadmin?

La seguridad informática es un pilar fundamental para los administradores de sistemas y para las empresas que quieren mantener a salvo sus datos. Tener bien securizados nuestros servidores y sistemas es esencial para garantizar esta seguridad ante posibles intrusiones, pero igual de importante es tener controlado qué hacen los usuarios dentro de estos servidores, sin importar que sean usuarios autorizados.

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.