intive Argentina Blog

Chef Server y OpsWorks: infraestructura automatizada y escalable

Hace poco, Rodolfo Cordero -DevOps en intive-FDV- nos brindó una serie de charlas para explicar cómo funcionan Chef y AWS OpsWorks respectivamente, y las ventajas y desventajas de utilizar una u otra herramienta, a la hora de automatizar procesos de infraestructura. A continuación, compartimos con ustedes todo lo que aprendimos.

Chef y Chef Server

La administración de documentación manual se complejiza rápidamente ante la necesidad de cambios que surgen en el día a día, y está expuesta permanentemente al error humano. Para solucionar estos inconvenientes, las áreas de Operaciones o Infraestructura suelen utilizar scripts como Bash -en el caso de Linux- o Powershell -en el caso de Windows-. También se pueden realizar snapshots (imágenes o pantallazos básicos de la situación actual).

Pero al aumentar la cantidad de servidores, o existir pequeños cambios (como, por ejemplo, en las direcciones IP, variables de entorno), la documentación queda desactualizada. Para resolver estas dificultades, se utilizan variadas herramientas. Entre ellas:

  • Puppet: está más enfocada los integrantes del área de Operaciones;escrita en Ruby, con una capa personalizada.
  • Ansible: está escrito en Python y usa YAML o Json. No tiene soporte para Windows.
  • Saltstack: tiene una base en Python y usa YAML para su código.
  • Chef: está pensada más para developers que pasan a Operaciones. Usa Ruby de base.

En este artículo hablaremos en particular de esta última, que permite usar todo el potencial del lenguaje, integración con Chef Spec, Rubocop y demás librerías de Ruby, y tiene soporte para Linux y Windows Server.

Chef es una herramienta hecha en Ruby que automatiza los procedimientos de aprovisionamiento. Tiene un servicio que se localiza en supermarket.chef.io, que funciona a modo de foro con el objetivo de que la gente comparta sus cookbooks con la comunidad y empresas.

Existen tres versiones que la empresa Chef Software Inc pone a disposición:

  • Solo: Es una versión que funciona como un cliente de Chef sin la necesidad de tener un servidor de Chef, utiliza un modo local.
  • Zero: Tiene la finalidad de ser usado para testing. Es ideal para probar los diferentes cookbooks en diferentes sistemas operativos.
  • Server: Es un producto enterprise, en el cual se centralizan cookbooks y variables. Además, sirve para configurar diferentes servidores con solamente una línea de comando, y brinda un dashboard para visualizar en tiempo real el estado de los nodos.

Chef Server funciona de la siguiente manera:

 

Screen Shot 2017-06-02 at 6.27.34 PM

En el gráfico solamente podemos observar un nodo o servidor, pero Chef Server es escalable a la cantidad de servidores que necesitemos configurar. A continuación, les dejamos una explicación gráfica sobre cómo es el proceso de aprovisionamiento de un nodo con Chef:

Screen Shot 2017-06-02 at 6.27.50 PMScreen Shot 2017-06-02 at 6.28.19 PM

 

OpsWorks

Las soluciones que brinda Amazon para infraestructura varían en complejidad. Ofrecen alternativas que permiten definir absolutamente todo y obtener mayor control – como AWS Cloud Formation y EC2 – y opciones que posibilitan solamente desplegar apps – como Elastic Beankstalk -. OpsWorks es una solución intermedia entre ambos niveles.

Chef Server permite:

  • Un servidor de Chef completamente administrado.
  • Un conjunto de herramientas de automatización para flujos de trabajo que logran una implementación continua, pruebas automáticas para lograr conformidad y seguridad, y una interfaz de usuario que provee visibilidad de sus nodos y estados.
  • El servidor de Chef almacena de manera central las tareas y configuraciones y las ofrece a cada nodo del entorno de computación en cualquier escala, desde unos pocos nodos a miles.
  • OpsWorks for Chef Automate es totalmente compatible con las herramientas y guías de la comunidad de Chef y registra de manera automática nodos nuevos con su servidor de Chef.

AWS OpsWorks Stacks 

  • Permite administrar aplicaciones y servidores en AWS y on-premise.
  • Se diseña su aplicación como una pila para contener diferentes capas, como balanceo de cargas, bases de datos y servidor de aplicaciones.
  • Puede implementar y configurar instancias de Amazon EC2 en cada capa, o conectar otros recursos como bases de datos de Amazon RDS.
  • OpsWorks Stacks te permite definir escalado automático para los servidores, en base a programas preestablecidos o en respuesta a niveles de alertas, ya sea por uso de CPU y/o memoria, entre otros, usando la herramienta CloudWatch.

Ventajas:

  • Chef Server funciona en la etapa de creación de máquinas y de aprovisionamiento, pero no llega a completar el proceso de lanzamiento de la aplicación. En cambio, OpsWorks Stacks llega a finalizar todo el camino usando otros servicios de amazon.
  • No se cobran cargos adicionales por el uso de OpsWorks Stacks for Amazon EC2, sólo se paga por los recursos subyacentes que se crean por el uso de OpsWorks Stacks.  En cambio, con OpsWorks for Chef Automate, los cobros se basan en el número de nodos conectados a tu servidor de Chef y en el tiempo de ejecución de dichos nodos. Se debe tener un Elastic IP disponible, y también hay que pagar por la instancia de Amazon Elastic Compute Cloud (Amazon EC2) que ejecuta el servidor de Chef.

Desventajas:

  • No se pueden hacer configuraciones para servidores híbridos. Hay que elegir entre Windows y Linux. En cambio, en Chef Server sí se puede.
  • OpsWorks Stacks tienen disponibilidad sólo en: US East (N. Virginia), US West (Oregon) y EU (Ireland).

En conclusión, Rodolfo nos comentó que la decisión depende de cada proyecto. Utilizar una u otra alternativa dependerá de si ya llevamos un camino utilizando Chef -en cuyo caso nos será más conveniente Chef Server-; o si vamos a empezar recién en este momento el camino de la automatización, y en ese caso nos convendrá optar por OpsWorks Stacks.

 

 

Paula Becchetti

Paula es la editora del blog de intive – FDV. Licenciada en Comunicación Audiovisual de la Universidad Nacional de San Martín (UNSAM), se destaca como Content Manager especializada en blogs, contenido web, email marketing y social media. Su amplia experiencia en la industria del software la hace muy valiosa a la hora de traducir contenidos técnicos a un lenguaje coloquial. Según sus propias palabras: “Me conecto con el mundo por medio de la tecnología, pero también a través de todo aquello que respira, del deporte, de la música y de mis viajes”.

Rodolfo Cordero

Rodolfo Cordero es desarrollador en la compañía desde junio de 2016. Es Licenciado en Desarrollo de Software, graduado de la Universidad Latina de Costa Rica, país del cual es oriundo. Asiduo lector y melómano, hizo cursos de coctelería y barismo, habilidades con las que deleita al staff de intive-FDV en los afters organizados por la compañía.

Deja un comentario