Una de las tareas que estamos realizando en algunos de los clientes que tenemos en Azure, es la migración de Mysql Single Server a Flexible Server. Esto se debe a que por parte de Azure van a dejar de dar soporte el 16 de septiembre de 2024 a los Single Server. 

Dentro de las recomendaciones de migración que ofrece Azure y la que mejor se adapta a nuestros clientes es la opción Online con Database Migration Service (DMS). Tienes más información sobre la migración en este enlace.

La seguridad a nivel de red y de sistema no era la prioridad en los inicios de Kubernetes en sus primeras versiones. Esto ya lo comentamos anteriormente, así como su evolución y mejora más que relevante en versiones modernas, pero no todo acaba aquí.

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.

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?

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.

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.