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.

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:

Jenkins es un software de integración continua de código abierto que se utiliza para automatizar el proceso de construcción, prueba y despliegue de software. 

Permite a los equipos de desarrollo integrar el código de manera rápida y eficiente, lo que ayuda a detectar y resolver los errores de manera temprana en el ciclo de vida del software.

A través de plugins y configuración es altamente personalizable y extensible, lo que significa que los desarrolladores pueden adaptarlo a sus necesidades específicas. Se integra con una variedad de herramientas y tecnologías, lo que facilita su uso en una amplia gama de proyectos.

Todos conocemos (o deberíamos conocer) la recomendación de cambiar nuestras contraseñas cada cierto tiempo.

Sobre todo en entornos empresariales, esta sugerencia se extiende no sólo al cambio de contraseña de usuario, sino también de claves RSA para accesos SSH, cifrados, etc.

En este caso, venimos a hablaros de una necesidad de cambio de claves distinta, pero igualmente importante para nosotros. 

En STR Sistemas, intentamos automatizar el 100% de las infraestructuras (terraform) y configuración de Sistemas (ansible). En dichas automatizaciones, en ocasiones, es necesario incluir información sensible (contraseñas, certificados SSL, RSA's de usuarios, etc), la cual siempre ciframos para evitar tener en código/repositorio contraseñas en texto plano.

Dicho esto, en STR nos topamos con una situación la cual, una vez más, nos llevó a pensar en la automatización o en una solución programada.

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.

Como administradores de infraestructura cloud, una tarea que muchos de nosotros hemos tenido que realizar (y seguiremos realizando), es adaptarnos a los requisitos de nuestros clientes respecto a las necesidades de almacenamiento que se establecen y que evolucionan/cambian en el tiempo.

A la hora de realizar estas operaciones (añadir nuevos discos o redimensionar discos existentes) en una instancia, la mejor de las situaciones que podemos encontrar es que sin más acciones, la instancia virtualizada detecte dichos cambios de discos, ya sea un nuevo disco o el cambio de tamaño de uno ya existente.

No obstante, en nuestro día a día hemos topado con sistemas de virtualización y/o sistemas operativos que no han detectado automáticamente estos cambios en discos.