¿En qué se diferencia Ansible de simplemente ejecutar un shell bash de aprovisionamiento en Vagrant?

39

Un equipo de administradores de sistemas de TI que tienen experiencia usando scripts de shell para resolver sus problemas, están contemplando comenzar a usar Ansible en su lugar.

¿Existen diferencias sustanciales y buenas razones para comenzar a usar Ansible vs. para continuar escribiendo scripts de shell?

Evgeny
fuente

Respuestas:

29

Nunca usé Ansible, pero desde hace unas semanas, trato de descubrir qué tan bueno podría ser Ansible en comparación con los scrips de shell, lo que demuestra, al menos en mi caso, que las inquietantes campañas publicitarias que ejecutan son efectivas. Después de muchos intentos fallidos, lo que demuestra cómo su documentación no responde a una de las preguntas más obvias, creo que finalmente lo entendí:

Ahora, veamos el video de introducción y veamos al azar como un nuevo usuario potencial a través del material de introducción a Ansible y comparémoslo con lo que un programador experto puede producir de inmediato.

Mi conclusión es que sobre las secuencias de comandos de shell, Ansible esencialmente ofrece 1. La posibilidad de verificar que un sistema esté de acuerdo con un estado deseado, 2. la capacidad de integrarse con Ansible Tower, que es un sistema de pago que parece incluir habilidades de monitoreo. En algunos casos importantes, como cuando se implementa el patrón de servidor inmutable, el punto 1 probablemente no sea muy útil, por lo que la lista es bastante delgada.

Mi conclusión es que los beneficios ofrecidos por Ansible sobre las secuencias de comandos de shell, como los presenta la documentación, podrían ser sensibles en algunos pocos casos optimistas bien cubiertos por los módulos disponibles, pero son pequeños o incluso hipotéticos en el caso general. Para un programador de shell experto, estos beneficios probablemente se vean contrarrestados por otros aspectos de la compensación.

¡Pero esto tal vez solo pruebe cuán malo es el material de introducción!

El video de inicio rápido:

Hay un video de inicio rápido . Comienza con una página que dice que ... bueno, estas no son realmente afirmaciones, son listas de viñetas, un artefacto comúnmente utilizado para suspender el juicio crítico en las presentaciones (ya que la lógica no se muestra, ¡no se puede criticar!)

1. Ansible es simple:

1.1 Automatización legible por humanos - Las especificaciones son documentos técnicos, ¿cómo podrían

  name: upgrade all packages
  yum:
    name: '*'
    state: latest

ser más fácil de leer que la invocación yum correspondiente encontrada en un shell-script? Además, cualquiera que haya tenido contacto con AppleScript muere de risa cuando lee "automatización legible por humanos".

1.2 No se requieren habilidades especiales de codificación: ¿qué es la codificación si no se escriben especificaciones formales? Tienen condicionales, variables, entonces, ¿cómo es que no está codificando? ¿Y por qué necesitaría algo que no puedo programar, que en adelante sería inflexible? ¡La afirmación es felizmente inexacta!

1.3 Tareas ejecutadas en orden: Bueno, tal vez algunos aficionados al codegolf conocen los lenguajes que ejecutan tareas en desorden, pero ejecutar tareas en orden difícilmente parece excepcional.

1.4 Sea productivo rápidamente: los programadores expertos de shell son productivos ahora. Este contraargumento es tan serio como el argumento inicial.

2. Ansible es poderoso

Un truco popular del vendedor para vender artefactos es engañar a las personas para que crean que adquirirán el "poder" de estos artefactos. La historia de la publicidad de automóviles o bebidas isotónicas debería proporcionar una lista convincente de ejemplos.

Aquí Ansible puede hacer "implementación de la aplicación", pero el script de shell seguramente lo hace, "administración de la configuración", pero esta es una mera declaración del propósito de la herramienta, no una característica, y la "orquestación del flujo de trabajo" que parece un poco pretenciosa, pero no hay ningún ejemplo más allá de lo que GNU Parallel puede hacer.

3. Ansible es sin agente

Para llenar la columna, escribieron de tres maneras diferentes que esto solo necesita ssh, que, como todos saben, es un demonio y no tiene nada que ver con estos agentes que impregnan la gestión de la configuración mundial.

El resto del video

El resto del video presenta inventarios, que son listas estáticas de recursos (como servidores) y muestra cómo implementar Apache en tres servidores simultáneamente. Esto realmente no coincide con mi forma de trabajar, donde los recursos son muy dinámicos y pueden enumerarse mediante herramientas de línea de comandos proporcionadas por mi proveedor de la nube y consumidas por mis funciones de shell utilizando el |operador de canalización . Además, no implemento Apache en tres servidores simultáneamente, sino que construyo una imagen de instancia maestra que luego uso para iniciar 3 instancias que son réplicas exactas una de la otra. Por lo tanto, la parte de "orquestación" de la argumentación no parece muy pertinente.

Documentación aleatoria paso 1: Integración con EC2

EC2 es el servicio informático de Amazon, la interacción con él es compatible con algún módulo Ansible . (También se proporcionan otros proveedores populares de computación en la nube):

# demo_setup.yml

- hosts: localhost
  connection: local
  gather_facts: False

  tasks:

    - name: Provision a set of instances
      ec2:
         key_name: my_key
         group: test
         instance_type: t2.micro
         image: "{{ ami_id }}"
         wait: true
         exact_count: 5
         count_tag:
            Name: Demo
         instance_tags:
            Name: Demo
      register: ec2

El script de shell correspondiente sería esencialmente idéntico con YAML reemplazado por JSON:

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --image-id …   
}

o la versión JSON

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"  
}

provision_a_set_of_instances__json()
{
  cat <<EOF
{
    "ImageId": … 
}
EOF
}

Ambas versiones son esencialmente idénticas, la mayor parte de la carga útil es la enumeración de los valores de inicialización en estructuras YAML o JSON.

Documentación aleatoria paso 2: Entrega continua y actualizaciones continuas

La mayor parte de esta guía no muestra ninguna característica realmente interesante: ¡presenta variables (IIRC, los scripts de shell también tienen variables)! Y un módulo Ansible maneja mysql, de modo que si en lugar de buscar después “¿cómo creo un usuario mysql? con privilegios en XY "y termina con algo como

# Create Application DB User
mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF

busca "cómo creo un usuario de mysql con privilegios en XY en ansible " y termina con

- name: Create Application DB User
  mysql_user: name={{ dbuser }} password={{ upassword }}
              priv=*.*:ALL host='%' state=present

La diferencia probablemente todavía no sea muy significativa. En esa página también descubrimos que Ansible tiene un lenguaje de meta-programación de plantillas.

{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}

Cuando veo esto, estoy realmente en mi zona de confort. ¡Este tipo de metaprogramación simple para lenguajes declarativos es exactamente el mismo paradigma teórico que BSD Makefiles! Lo que he programado extensamente Este extracto nos muestra que la promesa de trabajar con el archivo YAML está rota (por lo que no puedo ejecutar mis libros de jugadas a través de un analizador YAML, por ejemplo ). También nos muestra que Ansible debe analizar el arte sutil del orden de evaluación: tenemos que decidir si las variables se expanden en la "parte declarativa" del lenguaje o en la metaparte "imperativa" del lenguaje. Aquí la programación de shell es más simple, no hay metaprogramación, aparte de la fuente de script explícito eval o externo. El extracto hipotético de concha equivalente

enumerate_group 'monitoring' | {
  while read host; do
    …
  done
}

cuya complejidad en comparación con la variante Ansible es probablemente tolerable: solo utiliza las construcciones simples, regulares y aburridas del lenguaje.

Documentación aleatoria paso 3: estrategias de prueba

Por último, nos encontramos con lo que resulta ser la primera característica realmente interesante de Ansible: “Los recursos de Ansible son modelos del estado deseado. Como tal, no debería ser necesario probar que los servicios se inician, los paquetes están instalados u otras cosas similares. Ansible es el sistema que asegurará que estas cosas sean declarativamente verdaderas. En lugar de eso, afirma estas cosas en tus libros de jugadas ”. Ahora comienza a ser un poco interesante, pero:

  1. Además de un puñado de situaciones estándar implementadas fácilmente por los módulos disponibles, tendré que alimentar los bits que implementan la prueba yo mismo, lo que probablemente involucrará algunos comandos de shell.

  2. La comprobación de la conformidad de las instalaciones puede no ser muy relevante en el contexto donde se implementa el patrón de servidor inmutable: donde todos los sistemas en ejecución generalmente se generan a partir de una imagen maestra (imagen de instancia o imagen de acoplador, por ejemplo) y nunca se actualizan; se reemplazan por nuevo en su lugar.

Preocupación no abordada: la mantenibilidad

El material introductorio de Ansible ignora la cuestión de la mantenibilidad. Básicamente, sin un sistema de tipos, el scripting de shell tiene la facilidad de mantenimiento de JavaScript, Lisp o Python: las refactorizaciones extensas solo se pueden lograr con éxito con la ayuda de un extenso conjunto de pruebas automatizado, o al menos diseños que permiten pruebas interactivas fáciles. Dicho esto, si bien las secuencias de comandos de shell son la lengua franca de la configuración y el mantenimiento del sistema, casi cada lenguaje de programación tiene una interfaz con el shell. Por lo tanto, es totalmente factible aprovechar la ventaja de mantenimiento de los lenguajes avanzados, utilizándolos para unir los diversos bits de bits de configuración de shell. Para OCaml, escribí Rashell eso esencialmente proporciona una mano de patrones de interacción comunes para subprocesos, lo que hace que la traducción de scripts de configuración a OCaml sea esencialmente trivial.

Por el lado de Ansible, la estructura muy débil de los libros de jugadas y la presencia de una función de metaprogramación hacen que la situación sea esencialmente tan mala como lo es para las secuencias de comandos de shell, con los puntos negativos de que no es obvio cómo escribir pruebas unitarias para Ansible , y el argumento de introducir ad-hoc un lenguaje de nivel superior no se puede imitar.

Idempotencia de los pasos de configuración

La documentación de Ansible llama la atención sobre la necesidad de escribir pasos de configuración idempotentes. Más precisamente, los pasos de configuración deben escribirse de modo que la secuencia de pasos aba pueda simplificarse a ab , es decir, no necesitamos repetir el paso de configuración. Esta es una condición más fuerte que la idempotencia. Dado que Ansible permite que los libros de jugadas utilicen comandos de shell arbitrarios, Ansible no puede garantizar que se respete esta condición más fuerte. Esto solo se basa en la disciplina del programador.

Michael Le Barbier Grünewald
fuente
Esto parece un manual ... ¡impresionante!
Pierre.Vriens
44
No podría estar mas de acuerdo. Usamos Ansible por más de 1 año y ahora estamos usando contenedores Docker, construidos con buenos y simples scripts de bash. Definir el estado también es, en mi opinión, la característica más interesante, pero como ya lo mencionó, hay tantos servicios que no tienen un módulo Ansible correspondiente, por lo que siempre debe recurrir a los comandos bash de todos modos. Y sí, también solo implementamos contenedores inmutables en los servidores, por lo que definir el estado no es realmente una ventaja en este caso.
Andreas
1
Después de usar ansible a fondo, puedo confirmar todos los puntos que hice a priori. La idempotencia es posible pero no se aplica por ansible (consulte el módulo vmware_guest para un mal ciudadano), trabajar con su sistema macro es un verdadero dolor y es cada vez más difícil realizar incluso los tratamientos más básicos en datos estructurados, algunas cosas básicas están funcionando mal (el formato de libro de jugadas no puede comer un modo de archivo Unix sin una terapia) y lo único realmente bueno es la carga de funciones útiles escritas para ansible. Entonces, si no fuera por Red Hat promocionando ese producto, no puedo entender la amplia adopción.
Michael Le Barbier Grünewald
1
@Andreas Estoy de acuerdo en que todavía tiene muchos casos en los que necesita recurrir al shell o los módulos de comando que no significa que su juego ansible no pueda ser idempotente. Los módulos centrales en sí mismos mantienen la idempotencia simplemente comprobando si la acción debe realizarse. Puede hacer lo mismo con el shell o el módulo de comando ejecutando primero una tarea que verifique si se debe hacer algo y registrando su salida, luego haciendo un condicional en la segunda tarea en función de la salida de la primera tarea.
Levi
1
@ MichaelLeBarbierGrünewald, tengo que estar de acuerdo en general, cuando trabajé con Ansible, fue un verdadero dolor correr y su trabajo lleva semanas reunir un libro de jugadas para conectarse a la infraestructura de mi antigua empresa basada en la nube, aprovisionar Linux distro, instale LAMP / LEMP o lo que sea. Una vez que se completó, nos ahorró tiempo, pero tardó como un mes en ponerlo en funcionamiento. Ninguno de nosotros era maestro de scripters de bash, por lo que no era una alternativa.
Daniel
22

Cuando lo pones de esta manera, incluso si Ansible tiene algunas ventajas inherentes, los beneficios de usar herramientas familiares (en este caso, scripts de shell) deben ser mayores. No creo que haya una respuesta clara a eso.

Si el equipo puede lograr las cosas que Ansible ofrece con Shell:

  1. Gestión de configuración declarativa, idempotente
  2. Acceso a fragmentos reutilizables (es decir, libros de jugadas) para servicios populares de la industria.
  3. Gestión fiable de la ejecución remota, con reintentos, lógica continua, etc.

entonces probablemente podrían quedarse con lo que saben.

Después de todo, puedes implementar "guardias" en BASH. Puede encontrar un montón de trabajo BASH existente para resolver una variedad de tareas de configuración del servidor (esencialmente cualquier Dockerfile por ahí tiene un 90% de código de instalación bash). Puede acercarse bastante a lo que le ofrece Ansible / Salt / Chef-Zero, sin tener que transferir toda su solución existente a esas herramientas.

Es un acto de equilibrio entre las tendencias NIH (no inventadas aquí), y arrojar scripts buenos y establecidos a favor de una solución más sólida.

Una consideración final a tener en cuenta: ¿cómo se compara su tecnología cuando intenta reclutar más personas para el equipo? Encontrar personas que tengan experiencia Ansible es mucho más fácil que encontrar personas que tengan experiencia en su herramienta CM de creación de scripts local. Esto no es estrictamente una consideración técnica, más cultural. ¿Quieres ser la organización extraña que inventa su propio Ansible, o quieres ser la organización razonable que encuentre la herramienta adecuada para el trabajo? Esas decisiones afectan su capacidad para atraer talento.

Assaf Lavie
fuente
44
Me gustó tu respuesta; También mencionaría que, si el equipo de bash va por idempotencia, administración de ejecución y reutilización, básicamente escribiendo su propio marco de administración de configuración, hay un costo involucrado, y todos sabemos que esto puede ser realmente desagradable para proyectos internos .
ᴳᵁᴵᴰᴼ
También me suscribo a su respuesta, especialmente después de haber puesto la experiencia disponible en la balanza. Tengo dos pequeños críticos: el primero es la idempotencia. Por supuesto, este es un aspecto importante de los sistemas de configuración, pero dado que es posible usar cualquier comando de shell posible en los libros de jugadas ansibles , el sistema puede, en el mejor de los casos, incitar a usar idempotencia. (En realidad, queremos algo más poderoso que la idempotencia aba = ab .) En segundo lugar, la administración confiable de la ejecución remota puede ser totalmente irrelevante en algunos casos importantes, por ejemplo, al implementar el patrón de servidor inmutable utilizando imágenes de instancia.
Michael Le Barbier Grünewald
13

La respuesta anterior cubre parte de ella, pero pierde uno de los elementos importantes: el diseño convergente. Escribí algunas palabras hace un tiempo sobre esto en el contexto de Chef en https://coderanger.net/thinking/ pero la versión corta es que un script bash es un conjunto de instrucciones, mientras que un libro de jugadas Ansible (o receta de Chef, Salt estado, etc.) es una descripción del estado deseado. Al documentar el estado que desea en lugar de los pasos que desea seguir para llegar allí, puede hacer frente a muchos más estados iniciales. Este fue el corazón de Promise Theory como se describió en CFEngine hace mucho tiempo, y un diseño que nosotros (las herramientas de administración de configuración) acabamos de copiar desde entonces.

tl; dr El código Ansible dice lo que quieres, el código bash dice cómo hacer algo.

coderanger
fuente
2
¿Puede agregar también alguna referencia a la "teoría de la promesa", como libros o artículos, y cualquier otro material valioso si alguien quiere aprender al respecto?
Evgeny
1
Eso es en realidad a lo que aludí cuando dije que puedes escribir código bash idempotente (es decir, que puede comenzar en cualquier punto, ejecutarse varias veces y converger en el estado deseado). Pero su respuesta lo hizo mucho más claro.
Assaf Lavie
Sí, la idempotencia es una propiedad importante de los sistemas convergentes, pero los dos no siempre están directamente vinculados :) en cuanto a los materiales sobre Promise Theory, Mark Burgess (creador de CFEngine) tiene algunos libros, puedo encontrar enlaces cuando vuelvo a un ordenador portátil.
coderanger
1
@Evgeny, markburgess.org/TIpromises.html
Comodín
3

Una cosa que vale la pena señalar es que también tendrá menos problemas al ejecutar sus libros de jugadas ansibles en hosts remotos. Como es la razón principal para ejecutar ansible. Cuando está utilizando la secuencia de comandos de shell todavía necesita tener una forma de secuencia de comandos scp'ing en el host remoto.

Rudy Gevaert
fuente
¿No es Ansible solo una envoltura alrededor de ssh en este sentido?
Evgeny
Básicamente sí. Hace ssh, copia scripts de python de forma remota y los ejecuta. Eso significa, por cierto, que si su módulo ansible depende de alguna biblioteca de Python, esta biblioteca debería estar presente en la máquina remota, en algunas circunstancias.
Assaf Lavie
1
Y si estropea la configuración ssh, queda bloqueado de su máquina, inconveniente habitual de push vs pull.
Tensibai
1

Es 2019 y acabo de pasar unos días en una curva de aprendizaje ansible y aquí está la verdad absoluta: Ansible no vale la pena.

no está terminado, no se ejecuta en Windows y la combinación de configuración YAML y mensajes de error engañosos harán que sus ojos sangren. Parece casi deliberadamente terrible y lo digo en serio. Es claramente el producto de un proyecto del lado del desarrollador frustrado de los administradores de sistemas redhat. Probablemente un hipster.

Si no necesita ninguna de sus características más allá del aprovisionamiento, y solo está aprovisionando en un sistema operativo en particular. Por el amor de Dios, escribe un shell.script decente.

A partir de ahora, todo el proyecto me recuerda a los primeros foros de Linux donde los novatos se les dijo a RTFM y se burlaron de preguntar por qué alguien no podía escribir una GUI para configurar los gráficos. Simplemente no lo entiendes, ¿verdad? Deberías quedarte con Windows ... tal vez me aparearé ... feliz VI-ing.

Utiliza Docker. Preferencia a cualquier cosa. Docker es exageradamente simple y poderoso.

Pero, ¿qué pasa si absolutamente debe abastecerse de estaño preexistente? ¿Cuáles son las alternativas reales?

Bueno ... todavía no hay ninguno. Pero te prometo esto, a menos que ansible mejore, pronto lo habrá. Porque no importa cuán fuerte los fanboys lo presionen y perdonen sus fallas ... es un 5 de 10 por esfuerzo.

Escanea un script bash y ahórrate el problema.

Ricardo
fuente
Primero funciona en Windows a través de Win_RM o SSH. En segundo lugar, la sintaxis de yaml es muy buena y puede generarse mediante programación y, aunque algunos de los errores pueden ser engañosos, no es diferente de Java o Python vomitando sus entrañas durante una excepción. En tercer lugar, la noción de simplemente SCPing un script a un servidor no es aplicable en entornos de nube altamente dinámicos. ¿Cual servidor? Los servidores pueden cambiar todos los días. Ansible permite complementos de inventario fácilmente configurables con formas fáciles de agrupar servidores y les asigna variables. No creo que Ansible no valga la pena. Creo que es excesivo para tu entorno.
Levi
@Levi sí. Es mi culpa que Ansible no se ejecute en Windows, que tenga una configuración que no tenga esquema y que tenga una curva de aprendizaje más larga y mayores costos de mantenimiento que cualquier método a medida para lograr la misma tarea.
Richard
Para entornos de nube, existen otros enfoques para los tipos de empresas a gran escala que podrían justificar la curva de aprendizaje. Entiendo lo que hace ansible. Simplemente no veo su nicho.
Richard
El nicho es un marco de automatización fácil de usar para múltiples máquinas. No es tan bueno para Windows como para Linux. Tampoco es genial para msdos y netware. Es 2019, los servidores de Windows son el pequeño nicho inútil en estos días.
dyasny