Traigo una pequeña receta de Chef 12 que he usado para crear un servidor virtual usando una pila de OpsWorks. He tenido que pegarle unas cuantas vueltas ya que el proyecto estaba con la versión 11, y era mi primera AMI completa creada 100% desde OpsWorks. Después de unas horas navegando, comprendiendo cómo funciona todo esto. He conseguido comprender, como dice un colega de trabajo, «uno de los pilares básicos sobre los que se basa Amazon Web Services».
La idea es tener una pila completa de OpsWorks, que cree completamente un servidor desde cero. Le vamos instalando todo lo que vayamos a necesitar, desde actualizaciones a todas las herramientas para el proyecto. En la última receta de creación de la instancia se limpia la instancia, se para, y podremos guardar nuestra propia AMI para lanzarla desde otra pila de OpsWorks, EC2, etc..
Ahí va el código en ruby para la receta de Chef que tanta guerra me ha dado. En la documentación oficial me faltaban algunos detalles que hacían que no funcionara con Chef 12 al arrancar de nuevo la instancia en otra pila de OpsWorks. Esto se puede poner en la última receta:
bash "clean_before_create_ami" do user "root" code <<-EOH sudo /etc/init.d/monit stop sudo /etc/init.d/opsworks-agent stop sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ \ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ \ /etc/monit.d/opsworks-agent.monitrc \ /etc/monit/conf.d/opsworks-agent.monitrc \ /var/lib/cloud/ /var/chef /opt/chef sudo dpkg -r opsworks-agent-ruby sudo dpkg --purge opsworks-agent-ruby sudo dpkg -r chef sudo dpkg --purge chef EOH end
También se puede ejecutar esto desde línea de comandos conectando por SSH a la instancia.
Como cita la documentación oficial, si no hacemos esto, la nueva AMI quedará con las configuraciones de Chef y del agente de OpsWorks desde el que fue lanzada. Esto hará que no pueda hacer el setup si la arrancamos desde otra pila de OpsWorks creando servidores desde una «Custom AMI».
Espero que sirva.
Saludos.
