Tip: Encuentre los errores de la aplicación y los problemas de rendimiento al instante con Stackify Retrace

La solución de problemas y la optimización de su código es fácil con los errores integrados, los registros y las perspectivas de rendimiento a nivel de código.

Similitudes

Chef y Puppet tienen similitudes en la forma de gestionar las configuraciones en los servidores. Aunque ambas herramientas funcionan internamente de forma diferente, el resultado es el mismo. Con ambas herramientas se puede definir el estado deseado a través de código. Ambas herramientas trabajan con una arquitectura maestro-nodo en la que el maestro se encarga de almacenar todos los datos, y los nodos se encargan de que los servidores tengan siempre la configuración del estado deseado.

Por ejemplo, uno de los principales objetivos de utilizar Chef o Puppet para la gestión de la configuración es que puedes definir como código cuál debe ser el estado deseado de un grupo de servidores. No debería importar si quieres aplicar la misma configuración a los servidores, Chef y Puppet se asegurarán de implementar cualquier cambio de forma independiente. Del mismo modo, todos pulsamos Ctrl + S varias veces para asegurarnos de que guardamos los cambios. Pero donde este tipo de herramientas brillan es que si alguien entra en el servidor manualmente, y cambia el estado deseado del servidor, estas herramientas pondrán al día los servidores reconfigurándolos.

Desde el punto de vista de la arquitectura, Chef y Puppet se parecen bastante ya que ambos utilizan una arquitectura de agente maestro. Un nodo maestro es donde se almacenan todas las configuraciones del servidor. Los maestros de ambas herramientas son de alta disponibilidad (HA), pero con ligeras diferencias-más adelante. Luego, para cada servidor que se quiere gestionar, hay un agente instalado que está sacando la configuración en períodos automáticamente. Los agentes siempre están comprobando que se cumple el estado deseado, no al revés. Ambas herramientas pueden gestionar servidores Linux y Windows.

Por último, ambas herramientas tienen una versión de código abierto y una versión de pago con más características como una mejor configuración de HA.

Diferencias

He dicho antes que la arquitectura de Chef y Puppet son similares, pero difieren ligeramente en cómo manejan HA. En Puppet, el maestro replica sus datos a otro servidor, y trabajan de forma activa/pasiva. En el caso de Chef, la HA se maneja con tres servidores en modo activo/activo con un front end de la API que puede escalar horizontalmente.

Una diferencia significativa entre Chef y Puppet está en cómo definen la configuración de estado deseada para los servidores. Cada herramienta tiene su propio lenguaje específico de dominio (DSL). Chef utiliza Ruby para el DSL. Tiene más libertad para crear configuraciones complejas porque utiliza un lenguaje de programación. Chef llama a estas configuraciones de estado deseadas que escribes recetas. Todo lo que puedes hacer con Ruby, lo puedes hacer en Chef para crear recetas como condiciones if o llamar a otras librerías. El beneficio de esto es que los desarrolladores pueden sentirse más cómodos escribiendo recetas de Chef. Además, los desarrolladores no se sentirán restringidos a un DSL solamente, añadiendo al definir una configuración.

Por otro lado, Puppet tiene su propio DSL, «que fue diseñado para ser accesible para los sysadmins». Y si tienes experiencia trabajando con archivos de configuración de Nagios, escribir manifiestos (su versión de las recetas de Chef) no será un problema. No tienes demasiada libertad aquí, pero eso también es bueno desde la perspectiva de tener un lenguaje universal. Por lo tanto, no es necesario tener una formación de desarrollador para utilizar y aprender Puppet.

Por último, estas herramientas difieren en la forma de desarrollar y probar las recetas o manifiestos. Chef tiene una estación de trabajo que incluye el SDK de Chef que puedes instalar en tu ordenador local como entorno de ensayo. Puede probar las recetas localmente y luego subirlas al nodo maestro. Puppet no tiene una estación de trabajo, pero tiene un SDK donde puedes probar los manifiestos mientras los desarrollas. Además, puedes aplicar manifiestos localmente con el comando puppet apply.

Ejemplos

Veamos un ejemplo de código para asegurarnos de que el agente de Stackify está instalado.

Una receta en Chef tendrá este aspecto (Ruby puro):

# ...# bunch of variables declared# ...# download and extract stackify agenttar_extract node do target_dir Chef::Config creates "#{Chef::Config}/#{stackify_agent_install_relative_path}/#{stackify_agent_install_script_name}" not_if { File.exist?(stackify_agent_jar_location) }endtemplate_file = "#{Chef::Config}/#{stackify_agent_install_relative_path}/stackify-agent.conf"template template_file do source "stackify-agent.conf.erb"end# run stackify agent install scriptbash 'agent_install' do user 'root' cwd "#{Chef::Config}/#{stackify_agent_install_relative_path}" code <<-EOH ./#{stackify_agent_install_script_name} #{stackify_agent_install_script_options} rm -rf #{Chef::Config}/Linux rm -rf #{Chef::Config}/#{stackify_agent_install_relative_path} EOH not_if { File.exist?(stackify_agent_jar_location) }end

Para Puppet, hay un módulo para instalar el agente de Stackify, y el manifiesto tendrá este aspecto:

 class { 'stackify': package_ensure => 'present', package_install_options_environment => 'development', package_install_options_activationkey => 'XXXXXXXXXXXXXXXXXXXXXXXXXX', file_download_directory => 'C:\Temp', service_manage => true, service_ensure => true, service_enable => true, }

Como puedes ver, los ejemplos de código anteriores confirman lo que he dicho antes. En Chef, tienes más libertad. Pero en Puppet, el código puede parecer más simple cuando hay un módulo que puedes usar.

Características Premium

Vamos a tomar la comparación, incluyendo las características premium, que incluyen otras cosas además de la gestión de la configuración.

Para Puppet, tienen Puppet Enterprise que incluye las siguientes capacidades:

• Informes que ayudan con las políticas de cumplimiento
• Orquestación de despliegues de aplicaciones e infraestructura
• Automatizar el aprovisionamiento de la infraestructura con la infraestructura como código
• Gestión de código para promover los cambios de infraestructura automáticamente
• Gestión de nodos para el control granular de los servidores
• Políticas de control de acceso basadas en roles para los usuarios
• .políticas de control de acceso basadas en roles para los usuarios
• Soporte por correo electrónico o teléfono

También tienen Puppet Remediate, que es una herramienta para la gestión de la vulnerabilidad de sus servidores. Puedes obtener mejores conocimientos sobre qué vulnerabilidades existen en tus servidores, y aplicar parches a escala a todos los servidores.

En Chef, además de la gestión de la configuración, la versión de pago incluye las siguientes capacidades:

• Gestión de la conformidad y la seguridad
• Crear pipelines CI/CD y gestionar los lanzamientos de todas las aplicaciones
• Visibilidad con cuadros de mando en toda su pila de infraestructura

Obtendrá más detalles en el sitio de cada proveedor, tienen recursos bastante buenos para ayudarle a empezar rápidamente.

Cómo elegir

Cómo elegir entre Chef y Puppet es una pregunta difícil, y la respuesta, como siempre, es … «depende».

Cualquiera que sea la herramienta que elijas, debe ser una decisión de equipo, especialmente de los que terminarán trabajando con la herramienta. Una buena aproximación podría ser considerar los antecedentes del equipo. La gente con experiencia en sysadmin podría encontrar más adecuado el uso de Puppet. Aunque tengan que aprender el DSL, nunca será como aprender un lenguaje de programación. Aunque, si tienen un fondo en el desarrollo, la gente podría gustar más Chef (incluso si no saben Ruby).

Pero también debe considerar las características premium de cada herramienta. ¿Cuál de esas características ayudará a su organización a reducir los silos y el desperdicio? De nuevo, todo depende de sus necesidades. He visto que ambos proveedores siempre tratarán de ponerse al nivel del otro con las características. Por ejemplo, en Puppet, puedes crear funciones personalizadas con Ruby.

Y por supuesto, otro aspecto esencial es el precio. No quiero incluir aquí los precios porque fluctúa mucho, y varía en función de las necesidades de cada cliente. Otra razón es que en el caso de Puppet, su página de precios no tiene un número público sino un botón de «Contacto». En cambio, en la página de precios de Chef hay números, pero hay que ponerse en contacto con ellos. Te aconsejo que te pongas en contacto con ellos directamente y busques una buena oferta. Dependiendo del número de servidores que necesites gestionar podrían ofrecerte un mejor precio.

No hay una bala de plata

Como recordatorio amistoso, no hay una bala de plata para una herramienta de gestión de configuración. Tanto Chef como Puppet son muy maduros hoy en día, y están constantemente mejorando su producto, haciendo inversiones en investigación, creando mejores formas para que la gente aprenda su herramienta, etc. Espero que esta comparación te haya ayudado a entender mejor el funcionamiento de ambas herramientas. Tal vez te estés preparando para una entrevista de trabajo, o tengas curiosidad por conocer las principales diferencias y similitudes.

Pero si estás decidiendo qué herramienta utilizar para tu empresa, asegúrate de tener una idea clara de los problemas que tienes y de cómo este tipo de herramientas pueden ayudarte a aliviar la carga. Siempre va a haber una curva de aprendizaje, y dependerá de los antecedentes del equipo y de qué herramienta es más adecuada para ellos. Además, mira las características y servicios premium además de la gestión de la configuración, ya que tu empresa puede necesitar más ayuda con las políticas de cumplimiento.

• Acerca del autor
• Últimos posts

Acerca de Christian Meléndez

Christian Meléndez es un tecnólogo que comenzó como desarrollador de software y más recientemente se ha convertido en un arquitecto de la nube centrado en la implementación de pipelines de entrega continua con aplicaciones en varios sabores, incluyendo .NET, Node.js y Java, a menudo utilizando contenedores Docker.

• Introducción a AWS Elastic Beanstalk .NET Core – 17 de enero de 2020
• AWS Batch: Una guía detallada para arrancar tu primer trabajo – 26 de diciembre de 2019
• Azure Container Service (AKS) – Una introducción detallada – 18 de diciembre de 2019
• Envío de métricas personalizadas de CloudWatch desde Lambda con ejemplos de código – 14 de noviembre de 2019
• Chef vs Puppet: Diferencias, similitudes y cómo elegir – 24 de septiembre de 2019