Recientemente, durante nuestras labores de soporte hemos recibido una petición de un cliente que solicitaba la creación de un usuario en IAM para, a su vez, usarlo para el envío de correo a través del servicio SES de AWS. 

Por si no lo sabes, en este caso el usuario de SMTP será el Access Key del usuario IAM, mientras que la contraseña SMTP se obtiene a partir de la Secret Access Key, la  cual solo puede verse durante la creación de la Access Key.

La documentación oficial de AWS nos enseña dos formas de abordar esta situación.

Conseguir despliegues automáticos sin caídas en producción es el sueño de todo desarrollador experto, o mejor aún, que exista un despliegue continuo donde no se “lanzan despliegues”.

¡Ojo!, no es algo imposible y hay muchas formas de conseguirlo sin mucha sofisticación, pero a veces supone un sobreesfuerzo del desarrollador que para “aplicar un parchecito”, no siempre compensa.

La solución a este problema, aplicable a muchos otros, es integrar el mecanismo de despliegue en la propia infraestructura. De esta forma, se consigue hacer transparente el proceso al equipo de desarrolladores sin hacerles pasar un mal rato cada vez que aplican una mejora o nueva funcionalidad en el software de producción.

En varias ocasiones algunos de nuestros clientes nos han planteado la misma inquietud: "¿Por qué si hay varias réplicas de un pod y hay varios nodos, la pérdida de un nodo ha llegado a provocar la caída de algún servicio? ¿Por qué se pierde servicio si hay alta disponibilidad y tengo varios nodos y varias réplicas?"

Un error muy común es pensar que el planificador de kubernetes va a distribuir sí o sí todas las réplicas de un pod en diferentes nodos. Esto suele ir seguido de una breve explicación por nuestra parte sobre kubernetes y la planificación de pods.

Loki es un sistema de agregación de logs creado por GrafanaLabs, es escalable horizontalmente, puede contar con alta disponibilidad y está inspirado en Prometheus.

Una de las cosas que realizamos en STR con mucha frecuencia es la migración de sistemas, ya sea entre distintos proveedores o dentro de un mismo proveedor por cambio de versión, servicio o cualquier otra razón.

Recientemente se nos ha presentado un reto con el siguiente contexto:

Nuestra historia con kubernetes empezó a ser un poco más seria un sábado 16 de enero de 2016 en las oficinas de ShuttleCloud.

¿Quién no ha tenido caídas de un servidor web de Apache por saturación de conexiones en una campaña de publicidad masiva sin previo aviso?

Cuando esto pasa suelen empezar las preguntas al olvidado equipo de sistemas, sobre todo de la dirección de la empresa, ¡siempre tan atenta!

• ¿Tenemos recursos hardware suficientes?
• ¿Se están aprovechando los recursos disponibles en el servidor web?
• ¿Puedes estimar cuántas peticiones se pueden atender de forma concurrente con dichos recursos?
• ¿Qué direcciones IP son las que más peticiones hacen?

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.