BKT En Producción: Cloud-init

Retomando la serie empezada el año pasado, en esta ocasión compartiré un poco sobre una herramienta que conocí en este proyecto y la cual permite hacer muchísimas cosas al crear instancias de máquinas virtuales en la nube.

En este proyecto(BKT), al salir a producción, se creó una AMI en AWS. Una AMI es una imagen de un sistema operativo la cual sirve para lanzar más instancias sin tener que volver a configurar todo. Al usarlas, uno se puede ahorrar un montón de pasos en procesos de despliegue automático.

Generalmente, los despliegues no tendrían ningún problema al ir a máquinas virtuales creadas a partir de una AMI. En realidad son pocas las actualizaciones que se harían al sistema operativo(en términos de software instalado), sin embargo, sí hay un problema cuando se trata de instancias que se crean en procesos de auto escalamiento.

AWS Auto Scaling y AMIs

Una AMI es una copia de un servidor base en determinado momento del tiempo. Si la máquina base tiene Ubuntu 16.04 con Nginx y el proyecto Ruby on Rails configurado y recibiendo peticiones en el puerto 80, al crear una AMI en base a esta máquina, pues toda nueva instancia de EC2 tendrá lo mismo… Inclusive el mismo código. Y ahí es donde radica el problema.

Si al crear la AMI en la carpeta del proyecto el código está en el commit, digamos, 500, y pasados unos días el proyecto se va actualizando y los commits llegan a 1000, pues la AMI seguirá teniendo 500 commits. Para actualizar esa cantidad habría que crear otra AMI.

Así ocurre que en un proceso de auto escalamiento, ya que cada instancia auto escalada necesita una AMI(sea las que ofrece AWS o las que creemos nosotros) para inicializar un nuevo servidor, si vamos por el commit 1200 y la AMI está en el commit 500, vamos a tener un serio problema con ese servidor. Va estar muy atrasado.

¿Y cómo resolvemos este lío? El título del artículo tiene la solución: Cloud-init.

¿Qué es Cloud-init?

Cloud-init es una herramienta que viene, generalmente, en instancias de máquinas virtuales en la nube(por norma no se instala el mismo Ubuntu 16.04 para un computador que en un servidor web) que sirve para personalizar la configuración de estas justo cuando están inicializándose, es decir, cuando se están creando.

Al usarla le podemos decir a un servidor web que está apenas creándose que ejecute ciertas tareas(mediante scripts o una sintaxis específica llamada cloud config) para que una vez concluya la creación, tenga todo lo necesario para operar según necesitemos.

En ese orden de ideas, podemos decirle a una máquina virtual con Ubuntu 18.04 que cree una serie de directorios, que instale ciertos paquetes de software, que configure algunos servicios según necesitamos, que descargue archivos desde internet usando otros comandos, etc.

Cloud-init o AMI

Sabiendo que existe esta herramienta nació en su momento la pregunta de si era mejor configurar todo al iniciar con Cloud-init que hacer AMIs y estar actualizándolas. La respuesta es que ninguno es mejor que el otro y todo depende del caso de uso.

En mi situación, una AMI seguía siendo mejor porque con Cloud-init el tiempo en el que estaría lista la máquina incrementaría(y en un proceso de auto escalado lo ideal es que esté lista pronto). También pasaba que necesitaba Cloud-init para unas tareas relativamente cortas y simples así que opté por usar ambas en conjunto.

Finalmente, ya después de todo el esfuerzo de configurar cloud-init para el proceso de auto escalamiento, sucede que al estar usando otra herramienta en los despliegues llamada Code Deploy, todos los comandos configurados con cloud-init eran innecesarios 😀

Vi la situación como un buen aprendizaje y conocí una herramienta muy útil que tal vez pueda usar en otra ocasión.

Detalle antes de cerrar

Sucede que los scripts de Cloud-init se ejecutan siempre que la máquina está arrancando. Esto no es un problema cuando se crea y borra pero cuando solo se apaga, puede que no sea lo deseado.

Para prevenir varias ejecuciones se puede modificar el archivo de configuración del servicio /etc/cloud/cloud.cfg (aplica para Ubuntu 11.10+) como indica la respuesta en Stack Overflow.

Autor: cesc1989

Ingeniero de Sistemas que le gusta escribir y compartir sobre recursos que considera útiles, además que le gusta leer manga y ver anime.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios .