¿Ansible tiene un componente similar a PuppetDB?

Sé Puppet por experiencia (limitada) y he notado que en la gestión de la configuración ahora hay una fuerte tendencia hacia Ansible.

Por un lado, entiendo que Ansible no requiere un agente, porque hace un uso inteligente de ssh.

Por otro lado, estas son características que le han gustado a Puppet:

acceso al estado y al historial de configuración de todo el sistema (PuppetDB) a través de la API REST
capacidad de mantener copias de seguridad de archivos sobrescritos (archivadores)
capacidad de encriptar parte de las configuraciones de Hiera ( .eyaml)

Entre estos, PuppetDB me parece el más importante y útil (por ejemplo, para la integración con otras herramientas). Por lo tanto, mi pregunta es la siguiente: ¿Ansible tiene algo similar a PuppetDB, es decir, un componente que ofrece una API donde, por ejemplo, se le podría preguntar "¿Qué paquetes están instalados en el host x ?" o "¿En qué hosts es el paquete y instalado?"

(Esta pregunta se migró desde StackOverflow ).

ACTUALIZACIÓN Una desventaja significativa de Puppet es mi experiencia hasta el momento: no tanto el hecho de que requiere un agente (por lo que he visto, el uso de Python por parte de Ansible también introduce un tipo de agente en forma de intérprete de Python ;-), pero que quiere que su agente actúe como rootúnico y siempre.

ansible configuration-management puppet

— Drux
fuente

Curioso: ¿cómo esperarías que una herramienta como Puppet (o Chef, o CFEngine) pueda hacer lo que hace sin ejecutarse como root? Reemplaza la necesidad de que una SA inicie sesión y haga las cosas manualmente, por lo tanto, debe poder hacer cualquier cosa que una SA pueda hacer.

— Cayo

@Gaius Por un lado, conozco a una persona que no tiene rootderechos de acceso en un clúster de servidores, pero que aún puede usar Ansible para administrar una gran aplicación web allí. Además, hay SA que no inician sesión como root, pero en su sudolugar usan más escasamente.

— Drux

Todavía necesitan ejecutar comandos como root entonces. Si el agente en ejecución es un factor decisivo para usted, entonces está aplicando mal la herramienta

— Gaius

La respuesta directa es "no".

Ansible no tiene ninguna base de datos, porque se supone que debe ser operado por diferentes operadores de diferentes computadoras y su propósito es asegurarse de que los sistemas de destino estén en el estado exacto, como se especifica en los libros de jugadas.

Hay una opción para adjuntar backends de caché de hechos externos a Ansible. Para que pueda configurar redis como su caché, Ansible lo rellenará con datos recopilados durante la ejecución del libro de jugadas y luego podrá consultarlos para obtenerlos. Pero es una solución muy limitada, ya que Ansible no recopila demasiados datos, por ejemplo, no hay información sobre los paquetes instalados; tendrá que recopilarlos usted mismo y usarlos set_factcon la cacheableopción de guardarlos en la memoria caché externa.

— Konstantin Suvorov
fuente

Gracias. No entiendo el "porque" en su segundo párrafo: Puppet IMO también afirmaría que "se supone que debe ser operado por diferentes operadores de diferentes computadoras y su propósito es asegurarse de que los sistemas de destino estén en el estado exacto" ( solo que hablaría de manifiestos en lugar de libros de jugadas), pero utiliza una base de datos.

— Drux

Quise decir "sin ningún componente central / compartido". Entonces, en Ansible no tiene ningún componente con estado, excepto el sistema de destino.

— Konstantin Suvorov

Ya veo, eso tiene sentido.

— Drux