¿Por qué usar Chef / Puppet sobre scripts de shell?


81

Nuevo en las herramientas Puppet y Chef. Parece que el trabajo que están haciendo se puede hacer con scripts de shell. Tal vez se hizo en scripts de shell hasta que aparecieron.

Estoy de acuerdo en que son más legibles. Pero, ¿hay otras ventajas sobre los scripts de shell además de ser legibles?

Respuestas:


56

Un lenguaje específico de dominio hace una gran diferencia en la cantidad de código que escribe. Por ejemplo, podría argumentar que no hay mucha diferencia entre:

chmod 640 /my/file

y

file { "/my/file":
    mode => 640,
}

pero hay una gran diferencia entre estos:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

y

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

¿Qué sucede si el wget falla? ¿Cómo manejará eso tu script? ¿Y qué pasa si hay algo después de eso en su script que requiere que $ FILE esté allí con el contenido correcto?

Podría argumentar que uno podría simplemente poner echo "Hello world" > $FILEel script, excepto que en el primer ejemplo el script debe ejecutarse en el cliente, mientras que Puppet compila todo esto en el servidor. Entonces, si cambia el contenido, solo tiene que cambiarlo en el servidor y lo cambia para tantos sistemas como desee. Y Puppet maneja las dependencias y transfiere los problemas automáticamente.

Simplemente no hay comparación: las herramientas de administración de configuración adecuadas le ahorran tiempo y complejidad. Cuanto más intente hacer, más scripts de shell parecerán inadecuados y más esfuerzo ahorrará al hacerlo con títeres.


99
@Paul Gear, es una simplificación excesiva decir que las herramientas de administración de configuración son el camino a seguir a largo plazo. Por ejemplo, usando AWS, un script de shell puede construir el servidor desde cero, ejecutar algunas pruebas, y una vez que esté seguro de que las instancias de AWS están bien, haga una imagen. Luego, puede implementar esta imagen en una vista previa o en un entorno de ensayo para realizar más pruebas, una vez que valide que la imagen es buena para sus propósitos, luego pasará a producción. Las herramientas de gestión de la configuración no ayudan en absoluto en este escenario.
Derek Litz

Ahora, si desea administrar cientos de servidores dedicados que las personas usan a diario (y tiene poco control sobre lo que hacen, por error o no), ahí es donde deben usarse las herramientas de administración de configuración.
Derek Litz

66
Este no es un ejemplo muy convincente. Podría comenzar con wget y luego no terminaría en un estado extraño. ¿Es el archivo como una transacción que se revertirá si alguno de los pasos no tiene éxito?
PSkocik

33

Esta será una opinión impopular, pero los sistemas de gestión de la configuración no son necesariamente mejores. A veces, lo simple es lo mejor.

Hay una curva de aprendizaje definida y una sobrecarga administrativa asociada con el sistema de configuración que elija. Después de todo, está introduciendo una dependencia. Al igual que con cualquier automatización, también debe tener cuidado de mantener la seguridad en las configuraciones implementadas.

Solo he tenido un par de instancias donde implementamos la administración de configuración y se atascó. Siempre fue cuando había una gran cantidad de sistemas con configuración repetitiva y la necesidad de realizar implementaciones configurables de cortador de cookies.


10
Cuando el costo de administrar el entorno es tan grande que administrar la automatización es realmente más barato. Si es más sencillo realizar cambios de script administrados en Git o configurar las cosas en un multiplexor ssh, lo haremos. Lo más importante para mí es que monitorizo ​​los sistemas y verifico que todo funcione como se esperaba. Siempre que reciba una alerta cuando algo esté mal configurado, no es tan importante cómo se configura.
kenchilada

10
@ewwhite "cuándo decides automatizar o no" xkcd.com/1205
MikeyB

3
Las herramientas más modernas, como Ansible, tienen una carga de administración / implementación considerablemente menor que Chef o Puppet, y requieren poca o ninguna dependencia (Ansible en particular no tiene agente). Esto realmente baja el listón para la adopción.
GomoX

2
@ewwhite Automatizas cuando quieres para la productividad personal. Aprendes automatizando, no aprendes haciendo tareas mundanas. Aprendizaje = aumento de la productividad y mejora iterativa. La automatización se combina con esto para producir más positivos. Es una bola de nieve positiva en lugar de negativa. Progreso técnico vs Deuda técnica.
Derek Litz

2
@ABB No, eso no está implícito. Ni siquiera menciono los scripts de shell, menciono la automatización como práctica general. Puede automatizar las cosas con scripts de shell y aprender la abstracción de scripts en lugar de hacer las cosas manualmente, lo que no solo le ahorrará el tiempo de volver a realizar esa tarea, sino que evitará errores. Además, debería poder escribir su próximo script un poco mejor que el último. Una bola de nieve positiva ... Sin embargo, si eres un experto en escribir guiones y no estás escribiendo algo que volverás a ejecutar, no te ayudará a aprender ni a ahorrar tiempo de ninguna manera.
Derek Litz

23

Has respondido tu propia pregunta ...

La automatización se está volviendo más escalable y formalizada . Puppet y Chef se consideran estándares en estos días (verifique los anuncios de trabajo ).

Scripts de shell-juntos adoquinada tienen su lugar, pero son no escalable en el contexto del movimiento DevOps. La legibilidad es parte de eso.


77
¿Son los scripts de shell de alguna manera menos formalizados? ¿Citar anuncios de trabajo hace que un argumento sea convincente? Y un devops es una lástima, porque está poco explotado como desarrollador. El enlace no dice nada sobre la escalabilidad. ¿La afirmación de que los scripts de shell no son escalables? Creo que Puppet es interesante, pero no necesariamente por las razones en la respuesta.
Acumenus

Los anuncios de empleo reflejan el mercado real de habilidades específicas. Sí, el uso de la administración de configuración para su propósito previsto es más escalable, más robusto y más fácil de documentar que los scripts de shell. He estado en muchos entornos, y la mayoría de los scripts que veo no están construidos de una manera que uno considere "calidad de producción" y organizados para manejar excepciones. Vea la respuesta aceptada para entender por qué.
ewwhite

1
"Y un devops es una lástima, porque está poco explotado como desarrollador". Esto simplemente no es verdad. DevOps es una especialización de desarrollo, al igual que el desarrollo web. Los patrones y prácticas del desarrollo de software aún se aplican. Deberías leer sobre DevOps.
Chaim Eliyah

13

Chef hace que sea mucho más fácil administrar y versionar la configuración de una infraestructura compleja, especialmente en cualquier tipo de entorno en la nube en lugar de tener que ftp o scp manualmente un montón de scripts de shell organizados de manera no estandarizada. Dependiendo de cuántas dependencias necesite administrar, el tamaño de esta ganancia puede variar mucho, por lo que la decisión de pasar a una solución CM no es obvia para muchas personas.

El beneficio real (a menudo no reconocido) de Chef es la idempotencia . Poder estar seguro del estado de un recurso, independientemente de la combinación de recetas ejecutadas con intereses superpuestos, es un gran beneficio sobre la configuración del script de shell. Si tiene scripts de shell para la configuración ahora, pregúntese cuántos de ellos se pueden ejecutar varias veces sin consecuencias no deseadas / no deseadas?

Una solución CM adecuada ayuda a garantizar el éxito a escala al simplificar la automatización multiplataforma y la colaboración en equipo. Si bien es posible lograr todo esto con un grupo de scripts de shell bien organizado, bien mantenido y versionado; tienes que preguntarte "por qué". Chef / Puppet y tecnologías similares surgieron porque un grupo de talentosos SysOps estaban cansados ​​de tener que resolver estos mismos problemas una y otra vez y se dispusieron a darnos una mejor opción.

Piezas clave:

  • Idempotencia
  • Facilidad de gestión de dependencias (versionado)
  • Organización estandarizada (aceptada a nivel industrial)
  • Abstracción para separar las tareas de configuración del servidor de los detalles del nivel del sistema
  • Capacidad para aprovechar el conocimiento de la comunidad (se garantiza que abarca todos los principios anteriores)

3
La idempotencia es casi imposible con ss. Las dependencias se manejan bien con yum / apt, etc. La aceptación es irrelevante. El conocimiento comunitario existe para los ss. Sin embargo, acepto que no tener que copiar un montón de scripts, y también configurar los sistemas centralmente, son útiles. Escuché que la marioneta requiere un agente del lado del cliente.
Acumenus

10

Las herramientas modernas de administración de la configuración, como Puppet y Chef, le permiten definir el estado de un sistema en lugar de preocuparse por las actividades necesarias para lograr un servidor configurado.

Por ejemplo, su comando chmod asume que el archivo existe, que el usuario que posee el archivo existe, que los directorios se han creado, etc. Por lo tanto, su secuencia de comandos debe tener en cuenta todos estos requisitos previos.

Las herramientas de administración de configuración basadas en estado son más simples: solo le importa que el archivo tenga los permisos correctos. Cómo se logra eso es el problema de la herramienta.


1
En realidad, my chmodno asume que el archivo existe porque el archivo fue creado o probado por el script.
Acumenus

9

Si los servidores son desechables para usted, o si tiene motivos para resistir más de un par a la vez, un sistema CM completo satisfará sus necesidades mucho mejor que una serie de scripts de shell.

Si sus necesidades de construcción son modestas (o si le gusta hacer artesanalmente artesanalmente servidores de comercio justo orgánicos de rango libre), manténgalo simple.

Personalmente, después de haber usado ampliamente a Chef en un concierto pasado, intenté 'mantenerlo simple' en este concierto, pero realmente extrañé las primitivas, las abstracciones y el poder que Chef proporcionó. Incluso si llega a una situación en la que podría obtener lo que necesita de un par de comandos de shell, simplemente puede ejecutarlos con un bloque de 'comando', ingresando sus comandos de shell exactamente como los escribiría en shell.

Dicho esto, puede ejecutar Chef sin un servidor (chef-solo), y estoy bastante seguro de que Puppet tiene un análogo, donde aún puede aprovechar los libros de cocina y las recetas de otros sin ejecutar un servidor central.

Otro beneficio es la comunidad: hay muchas personas (muchas de las cuales serán más inteligentes y / o más experimentadas que usted). Personalmente, me encanta cuando alguien más ha hecho mi trabajo por mí, a menudo más extensamente de lo que yo hubiera hecho.


1

Creé un marco de automatización de servidor basado en script de shell: https://github.com/myplaceonline/posixcube

Estoy seguro de que no soy el primero en hacer este tipo de proyecto, pero no pude encontrar algo así para satisfacer mis necesidades, así que pensé que otros podrían encontrar esto útil. Solo tenía experiencia con Chef, pero cuando comencé a mirar a Ansible y a otros, quería darle una oportunidad a los guiones de shell, y hasta ahora me gusta el resultado.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.