Pregunta ¿Por qué usar Chef / Puppet over shell scripts?


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

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


78
2018-05-01 10:13


origen




Respuestas:


Un idioma específico del dominio hace una gran diferencia en la cantidad de código que escribes. 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é pasa si falla el wget? ¿Cómo manejará eso tu script? ¿Y qué sucede si hay algo después en el script que requiere que $ FILE esté allí con el contenido correcto?

Se podría argumentar que uno podría simplemente poner echo "Hello world" > $FILE en el 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 cambiará para todos los sistemas que desee. Y Puppet maneja las dependencias y los problemas de transferencia de forma automática.

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


55
2018-05-01 11:14



@Paul Gear, es una simplificación decir que las herramientas de administración de la configuración son el camino a seguir a largo plazo. Por ejemplo, al usar 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, cree una imagen. Luego, puede implementar esta imagen en una vista previa o en un entorno de prueba para realizar más pruebas, una vez que valide la imagen sea adecuada para sus propósitos y luego empiece a producir. Las herramientas de administración de configuración no ayudan en absoluto en este escenario. - Derek Litz
Ahora, si desea administrar cientos de servidores dedicados que la gente usa diariamente (y tiene poco control sobre lo que hacen, erróneamente o no), ahí es donde se deben usar las herramientas de administración de la configuración. - Derek Litz
Este no es un ejemplo muy convincente. Podría comenzar con wget y luego no terminaría en un estado extraño. ¿Es un archivo como una transacción que se deshará si alguno de los pasos no tiene éxito? - PSkocik


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.

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

Solo tuve un par de instancias en las que implementamos la administración de la configuración y se atascó. Siempre fue cuando había un gran número de sistemas con configuración repetitiva y la necesidad de realizar implementaciones configurables de cortador de galletas.


31
2018-05-01 14:58



Cuando el costo de administrar el ambiente es tan grande que administrar la automatización es realmente más barato. Si es más sencillo hacer un script de cambios administrados en Git o configurar cosas en un multiplexor ssh, lo hacemos. Lo más importante para mí es que controlo los sistemas y verifico que todo funciona como se espera. Siempre que me avisen cuando algo está mal configurado, no es tan importante cómo se configura. - kenchilada
@ewwhite "¿Cuándo decides automatizar y no" xkcd.com/1205 - MikeyB
Las herramientas más modernas, como Ansible, tienen considerablemente menos gastos de implementación / administración que Chef o Puppet, lo que requiere poca o ninguna dependencia (Ansible en particular no tiene agentes). Esto realmente baja el listón para la adopción. - GomoX
@ewwhite Usted automatiza cuando lo desea 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 una negativa. Progreso Técnico vs Deuda Técnica. - Derek Litz
@ A-B-B No, eso no está implícito. Ni siquiera menciono los scripts de shell, menciono la automatización como una práctica general. Puede automatizar cosas con shell scripts y aprender la abstracción de scripting en lugar de hacer las cosas manualmente, lo que no solo le ahorrará el tiempo de hacer esa tarea otra vez, sino que también evitará errores. Además, deberías poder escribir tu siguiente script un poco mejor que el anterior. Una bola de nieve positiva ... Sin embargo, si usted es un experto en la escritura de guiones y no está ejecutando secuencias de comandos, nunca lo ejecutará de nuevo, no le ayuda a aprender ni a ahorrar tiempo de ninguna manera. - Derek Litz


Has respondido tu propia pregunta ...

La automatización es cada vez más escalable y formalizada.. Títere y Chef son considerados estándares en estos días anuncios de empleo).

Los scripts de shell improvisados ​​tienen su lugar, pero son no Escalable en el contexto del movimiento DevOps. La legibilidad es parte de eso.


23
2018-05-01 10:40



¿Están los scripts de shell de alguna manera menos formalizados? ¿Citar anuncios de trabajo hace convincente un argumento? Y un devops es una vergüenza, ya que está subexplotado como desarrollador. El enlace no dice nada realmente acerca de la escalabilidad. ¿Es 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. - A-B-B
Los anuncios de empleo reflejan el mercado real de habilidades específicas. Sí, el uso de la administración de la configuración para el 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 manera tal que uno considere "calidad de producción" y esté organizado para manejar las excepciones. Vea la respuesta aceptada para entender por qué. - ewwhite
"Y un devops es una vergüenza, ya que está subexplotado como desarrollador". Esto simplemente no es cierto. DevOps es una especialización en desarrollo, al igual que el desarrollo web. Los patrones y prácticas de desarrollo de software todavía aplican. Deberías leer sobre DevOps. - Chaim Eliyah


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

El beneficio real (a menudo no reconocido) de Chef es idempotencia. Ser capaz de 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 de shell script. Si tiene shell scripts para la configuración ahora, pregúntese cuántos de ellos se pueden ejecutar varias veces sin consecuencias no deseadas / indeseables.

Una solución CM adecuada ayuda a garantizar el éxito a escala simplificando 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 organizados y mantenidos adecuadamente; tienes que preguntarte "por qué". Chef / Títere 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 propusieron darnos una mejor opción.

Piezas clave:

  • Idempotencia
  • Facilidad de gestión de la dependencia (control de versiones)
  • 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 (que garantiza abarcar todos los principios anteriores)

13
2018-05-03 19:11



La idempotencia es difícilmente imposible con ss. Las dependencias son bien administradas por yum / apt, etc. La aceptación es irrelevante. El conocimiento de la comunidad existe para ss. Acepto, sin embargo, que no tener que copiar sobre un montón de scripts, y también configurar los sistemas de forma centralizada, son útiles. Escucho que el títere requiere un agente del lado del cliente. - A-B-B


Las modernas herramientas de gestión de la configuración, como Puppet y Chef, le permiten definir estado de un sistema en lugar de preocuparse ocupaciones Necesario 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, y así sucesivamente. Por lo tanto, su script debe tener en cuenta todos estos requisitos previos.

Las herramientas de administración de la 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.


10
2018-05-20 02:19



En realidad mi chmod no asume que el archivo existe porque el archivo fue creado por o probado por el script. - A-B-B


Si los servidores son desechables para usted, o si tiene motivos para pararse 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 le gustan los servidores de comercio justo orgánicos de manera artesanal y artesanal), entonces hágalo simple.

Personalmente, después de haber utilizado a Chef en un concierto anterior, intenté "mantenerlo simple" en este concierto, pero realmente extrañé los primitivos, las abstracciones y el poder que brindaba Chef. Incluso si llegas a una situación en la que podrías obtener lo que necesitas con un par de comandos de shell, simplemente puedes ejecutarlos con un bloque de 'comando', ingresando tus comandos de shell exactamente como los escribirías en shell.

Dicho esto, puede ejecutar Chef sin servidor (chef-solo), y estoy bastante seguro de que Puppet tiene un análogo, en el que aún puede aprovechar los libros de cocina y 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 ampliamente de lo que lo habría hecho yo.


9
2018-05-01 22:32





Creé un framework de automatización de servidor basado en script 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, por lo que pensé que otros podrían encontrarlo útil. Solo tuve experiencia con Chef, pero cuando comencé a mirar a Ansible y a otros, quise darle una oportunidad a los scripts de shell y me gustó el resultado hasta ahora.


1
2017-12-25 01:15