Ansible vs solución personalizada

Oct 30 2020

Tengo un grupo de alrededor de una docena de estaciones de trabajo que ejecutan Linux y necesito un sistema para mantenerlas sincronizadas de alguna manera (el mismo software instalado, la misma configuración, los mismos usuarios, ...) y también me permite evolucionarlas en el tiempo (piense en cambios de configuración , actualizaciones de controladores, nuevo software ...). El truco es que a veces, algunos de ellos se desconectan y solo se reactivan después de semanas, incluso meses y, a veces, se agregan nuevas estaciones de trabajo y deben configurarse desde cero.

Estaba considerando usar Ansible y parece genial, pero para mi caso de uso tiene dos desventajas:

  • no tiene una función de actualización automática (cuando se inicia una caja después de un largo período de inactividad, necesito ejecutar manualmente el libro de jugadas en la estación del controlador)
  • después de años en producción, el libro de jugadas sería realmente largo. Tener que ejecutarlo en una estación de trabajo que solo perdió algunas actualizaciones sería muy ineficiente. Incluso si todas las tareas son idempotentes, cada una de ellas tendría que enviarse a la estación de trabajo solo para ver si se ejecutó o no. Dividir el libro de jugadas en partes más pequeñas tampoco es ideal, ya que requeriría hacer un seguimiento de lo que se ejecutó y dónde.

La alternativa que estoy pensando es tener un repositorio de scripts y usar GNU Make para ejecutarlos. Make se usa para actualizar destinos de fuentes, básicamente ejecuta un comando en un archivo fuente para producir una salida (por ejemplo, compilar un programa C en un binario). Si trato los scripts como fuentes, entonces un Makefile como este haría el trabajo:

TASKS= \
    install_apps \
    start_services \
    add_users

TARGETS=$(TASKS:=.done) all: $(TARGETS)

%.done: %.sh
    echo "running $<" ./$<
    touch $@

Cuando una de las estaciones de trabajo se inicia, puede extraer automáticamente el repositorio de scripts y ejecutar make . Con este sistema en su lugar, las tareas se ejecutan solo una vez y en el orden en que se enumeran.

Preguntas

  • ¿Crees que las desventajas que enumeré son falsas? Tal vez haya una forma / solución alternativa para lograr mi objetivo usando Ansible
  • ¿Ves algún problema con la alternativa que propuse? Tenga en cuenta que el Makefile anterior está simplificado y no está listo para producción.

Respuestas

3 HenrikPingel Oct 30 2020 at 18:19

La primera desventaja, Ansible es un sistema basado en push, se puede mitigar utilizando ansible-pull .ansible-pull

extrae libros de jugadas de un repositorio de VCS y los ejecuta para el host local

ansible-pull podría ser activado por cron o un script de inicio.

La segunda desventaja de los libros de jugadas de larga duración es cierta. Ansible no es el sistema de gestión de configuración más rápido del mercado. Sin embargo, el tiempo de ejecución de Ansible se puede reducir usando mitógeno y es relativamente fácil implementar condicionales para omitir partes de un libro de jugadas con el fin de acelerar el juego de esta manera:

  - name: Register a variable
    ansible.builtin.shell: cat /etc/motd
    register: motd_contents

  - name: Use the variable in conditional statement to run long running play
    include: otherplays.yaml
    when: motd_contents.stdout.find('hi') != -1

Si escribe libros de jugadas teniendo en cuenta el tiempo de ejecución, puede ser tan rápido como bash.

En general, Ansible proporciona muchas herramientas útiles para configurar sistemas. Probablemente no haya nada en Ansible que no se pueda implementar usando algo como Makey Bash. La ventaja de Ansible sobre Bash es que a muchas personas les resulta más fácil trabajar y el código es más legible.