En artículos anteriores tratamos el tema de cómo auditar eventos en diferentes sistemas, y en el caso de Windows explicamos cómo hacer que estos quedasen reflejados en el Visor de Eventos. Ahora bien, como también hemos comentado en otras ocasiones, lo ideal es que todo log se envíe a un sistema centralizado para el visionado de los mismos en un único lugar, y para ello hay que hacer uso de un software específico para este fin.

En entornos Windows tenemos multitud de posibilidades, una de ellas es el uso del software NXLog, que es el que vamos a tratar en el artículo de hoy y cuyo funcionamiento veremos con un pequeño ejemplo.

La modernización de aplicaciones es un desafío constante para las empresas que desean mantenerse ágiles y competitivas. Uno de los mayores obstáculos suele ser la gestión de aplicaciones legacy: aquellas que han sido desarrolladas con tecnologías obsoletas pero que aún son vitales para el funcionamiento del negocio.

En este artículo, exploraremos cómo hemos abordado este desafío en STR Sistemas, llevando una aplicación legacy desarrollada en PHP 7 a un entorno moderno utilizando contenedores Docker y Kubernetes.

Introducción

Recuerdo que en un viaje con mi socio Sebastián volviendo de un AWSome Day en Barcelona (antes de que el AWS Summit llegase a la capital), veníamos charlando con unos amigos del sector sobre una colaboración con ellos como resultado de sus necesidades para el día a día y de que estaban en mitad de un proceso de migración de su infraestructura.

Para ellos dicho proceso estaba siendo muy duro, y nunca se nos olvidará la frase que nos dijeron: “Vosotros vivís continuamente en el infierno”, haciendo referencia a que nosotros realizábamos eso de manera continua en el día a día con un cliente detrás de otro :D.

Dentro de las tareas que desempeñamos en STR, está la optimización de costes de las plataformas de nuestros clientes. Hoy te vamos a mostrar un ejemplo de uno de nuestros clientes utilizando datos ficticios por la privacidad del mismo.

La empresa actualmente tiene una plataforma dimensionada para afrontar su mayor pico conocido de actividad. Esto, entre otras cosas, le genera unos costes muy elevados, ya que, en la mayor parte del tiempo la actividad en la plataforma es bastante baja en comparación con los picos de tráfico que debe gestionar.

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.