OpsWorks

AWS OpsWorks: automatizando la creación de servidores

2016-10-14 - Categorías: Amazon Web Services / General / GNU/Linux / Magento / Symfony
OpsWorks Logo

Las nubes por definición son sistemas informáticos que crecen o decrecen según la necesidad. Son conjuntos de servidores/servicios que se adaptan a la demanda. Con todo esto, llegamos a una de las cosas más interesantes de AWS, el auto-escalado o la tolerancia a fallos, además de la personalización de los servidores. Podemos controlar la carga de los servidores que haya. Además automatizar el arranque y parada a ciertas horas de algunos de los servidores. O podemos duplicar los sistemas para evitar los ‘single point of failure como una casa’.

En OpsWorks tenemos herramientas muy interesantes relacionadas con esto. Algo rústicas, quizá clásicas dirían algunos. Pero gracias a ello, sin límites en la flexibilidad para configurar. Y si lo llevamos al extremo, este mismo sistema nos puede servir para automatizar la creación de nuestros servidores con herramientas como Chef y Kitchen. Todo esto y mucho más es lo que se puede hacer con el clásico OpsWorks.

Primero tendremos que ver qué son las AMIs. Cómo crear una manualmente o automáticamente. Y finalmente veremos cómo se usan, para hacernos una buena idea de qué podemos hacer en OpsWorks, y si es o no lo que necesitamos. Quizá es interesante ir a Docker con el EC2 Container Service o a CloudFormation, pero esto son otros temas..

No voy a entrar al detalle de cómo hacer cada cosa, no terminaría nunca. Así que si buscas una guía general para enfrentar después cada detalle poco a poco, este es tu post.

Continuar leyendo..

Creando custom AMI con OpsWorks y Chef 12

2016-05-22 - Categorías: Amazon Web Services
Chef Software Inc company logo

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.

© 2024 JnjSite.com - MIT license

Sitio hecho con WordPress, diseño y programación del tema por Jnj.