Por favor, no lo llamemos how . Eso es incluso peor de leer que become: true . Pero la funcionalidad debajo se ve genial.

incluye arreglo para #10695

Excelente. En aras de la eliminación de bicicletas, tal vez llámelo looping: .

:+1:

+1

¡+1 especialmente para la paralelización dentro del host!

:+1:

:+1:
pero no lo llamemos "cómo"

así que aquí hay una solución para romper una tarea de bucle después de la primera falla

- hosts: localhost
  vars:
    myvar:
        - 1
        - 2
        - 3
        - 4
        - 5
  tasks:
    - name: break loop after 3
      debug: msg={{item}}
      failed_when: item == 3
      register: myresults
      when: not (myresults|default({}))|failed
      with_items: "{{myvar}}"

@bcoca no funciona desde el final (ansible 1.9.3 ubuntu)

TAREA: [romper bucle después de 3] * * * * * * * * * * * * * * * ** *
bien: [localhost] => (elemento=1) => {
"fallido": falso,
"failed_when_result": falso,
"Objeto 1,
"mensaje": "1"
}
bien: [localhost] => (elemento=2) => {
"fallido": falso,
"failed_when_result": falso,
"elemento": 2,
"mensaje": "2"
}
fallado: [localhost] => (elemento=3) => {"fallido": verdadero, "fallido_cuando_resultado": verdadero, "elemento": 3, "verbose_always": verdadero}
mensaje: 3
bien: [localhost] => (elemento=4) => {
"fallido": falso,
"failed_when_result": falso,
"elemento": 4,
"mensaje": "4"
}
bien: [localhost] => (elemento=5) => {
"fallido": falso,
"failed_when_result": falso,
"elemento": 5,
"mensaje": "5"
}

ah, sí, funcionará como está en 2.0 ya que en 1.9 el registro no ocurre hasta que se completa el bucle.

+1 en tenedores

+1
¿Quizás en lugar de "cómo", loop_details u opciones?

+1

+1, usar wait_for de localhost para esperar a que aparezcan 100 hosts EC2 me está matando...

+1 por motivo similar a senderista

+1

:+1:

Tanto squash como forks serían características increíbles que acelerarían enormemente la ejecución de Ansible.

También reemplazaría how con algo como loop_details , loop_settings , loop_options , o algo similar.

loop_control , ya en 2.1 con la parte label implementada.

squash podría desaparecer, ya que es fácil simplemente pasar una lista a los módulos que lo admiten:

apt: name={{listofpackages}}

y evitar el bucle por completo

http://docs.ansible.com/ansible/playbooks_loops.html#loop-control

+1 tenedores

+1 tenedores

Tuve un caso de uso para una nueva configuración para un descanso condicional break_when

+1 bifurcaciones y espero que también funcione para paralelizar secuencias de tareas para ejecutar como en:
- include: service.yml
with_items: "{{services|default([])}}"

De lo contrario, ya está el async/async_status .

+1 tenedores

Yo esperando módulos openstack para iterar a través de bucles with_ en más de 100 elementos...

+1 en horquillas. Podría usar esto para copiar AMI a todas las regiones de AWS.

+1 en horquillas. ¡Por favor! hazlo parte de loop_control

+1 en tenedores

+1 en tenedores

+1, también necesito tenedores :-)

+1 en tenedores

+1 en tenedores

Los tenedores serían geniales, +1

Siempre me siento en silencio sin querer contribuir al spam, porque es difícil evaluar entre proyectos si es bienvenido o no, ¡pero parece que el tren fork +1 ha salido de la estación!

+1 en tenedores

+1 en tenedores

+1 en tenedores

:+1: en tenedores

@bcoca Saludos! Gracias por tomarse el tiempo para abrir este problema. Para que la comunidad maneje su problema de manera efectiva, necesitamos un poco más de información.

Aquí están los artículos que no pudimos encontrar en su descripción:

• Tipo de problema
• versión ansible
• Nombre del componente

Establezca la descripción de este problema con esta plantilla:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

haga clic aquí para obtener ayuda con el bot

+1 en tenedores

+1 en tenedores!

¡+1 en Horquillas!

+1 en tenedores!

+1 en tenedores!

¿Alguna actualización sobre el tenedor? ¿Cuándo se supone que debe estar listo?
Mi caso de uso es instanciar alrededor de 20 contenedores en un servidor con with_sequence . Ahora toma demasiadas edades :(
Me encantaría ayudar, pero necesitaría algunos consejos sobre dónde poner las manos.

@bitliner nadie ha creado un PR para ello, si eso es lo que está preguntando, en realidad es muy difícil hacerlo correctamente.

en cuanto a su problema, simplemente declare X hosts en el inventario y recorra hosts: en lugar de with_ para crearlos en paralelo.

inventario:

[containers]
container[000:020]

hosts: containers
gather_facts: false
tasks:
   - container: state=present name={{inventory_hostname}}

es decir, el contenedor es un módulo 'inventado'.

@bcoca no me queda clara tu solución. Para estar seguro, ¿es esto lo que quieres decir?

archivo de hosts

[containers]
192.168.1.100
192.168.1.100
192.168.1.100
192.168.1.100
... and so on based on the degree of parallelism I want to get ...

archivo principal.yml

hosts: containers
gather_facts: false
tasks:
   - container: state=present name={{inventory_hostname}}

basado en un módulo contenedor que debería implementar, ¿correcto? En este caso, tendría todos los contenedores con el mismo nombre y eso no es aceptable, ¿correcto?

Además, ¿cuáles son los desafíos para implementar el bucle en paralelo correctamente?

Mi caso de uso necesita acelerar esta tarea:

- name: "Start clients"
  docker_container:
    name: "mycontainer-{{ item }}"
    image: myimage
    links: 
      - server-{{item}}:server-{{item}}
  with_sequence: count={{ scale }}

No puedo usar la escala docker-compose porque necesito enrutar el tráfico entre contenedores de una manera específica (es por eso que uso with_sequence para generar diferentes nombres de contenedores docker).

Podría crear un módulo que tome la declaración de un contenedor y, en función de un parámetro de escala , cree una instancia remota de varios contenedores en paralelo. ¿Tiene sentido? ¿Tiene alguna ayuda para comprender cómo llamar/reutilizar en myModule el módulo docker_container y cuáles son las API que ofrece Ansible para ejecutar algo en paralelo?

@bitliner , no seguiste mis instrucciones, tenía nombres únicos en el inventario (usando el rango para que funcionara como una secuencia). Como los nombres son únicos en el inventario, acaba de declarar el mismo nombre N veces, pero aún tiene un host, lo que no causa su segundo problema con los nombres falsos de los contenedores, ya que solo recorre 1 host.

En cualquier caso, si desea hacer un seguimiento de su problema, use ML o IRC, ya que estaría un poco fuera de tema para este ticket.

@bcoca ¿Cómo puedo tener un host si declaró 20 hosts?

[containers]
container[000:020]

se va a conectar a container001 , container002 , etc.

Funciona para tener nombres únicos, pero lo que no me queda claro es por qué dices que todavía tengo un host (en lugar de 20).
hosts:containers significa para mí 20 hosts, no solo uno. ¿Qué estoy ignorando en esta solución?

@bitliner causa esto:

[containers]
192.168.1.100
192.168.1.100
192.168.1.100
192.168.1.100

no son 4 hosts, sino 1

también en este punto esto está bastante fuera de tema, si desea continuar recibiendo ayuda sobre esto, vaya a IRC o ML

he resuelto usando

[containers]
ip[000:020] ansible_host=192.168.1.100

y

- name: "Start containers"
  docker_container:
    name: "my-container-{{ inventory_hostname }}"

Una pregunta: imagen para agregar una instrucción fork , ¿los cambios consistirían en reescribir el método run_loop para que administre el nivel de paralelismo y la asincronía?

y luego empieza a ponerse 'divertido'...:

• ¿La bifurcación de bucle cuenta contra el --forks global, lo hace por control remoto?
• ¿Qué hacer con los bucles cuando los elementos dependen de los elementos anteriores (no solo la ejecución de la tarea, sino también los condicionales, etc.)?
• ¿Cómo manejar los problemas de concurrencia cuando se ejecutan varias bifurcaciones en el mismo host? es decir, actualizan el mismo archivo
• ¿Cómo manejamos la limpieza? en este momento pueden reutilizar los directorios tmp ... pero cada ejecución se limpia después de sí misma, ahora esto puede causar problemas.

Y hay algunos otros problemas que conozco... seguro que hay muchos de los que no me daré cuenta hasta que alguien intente implementarlos. Tengo soluciones para algunos, pero empieza a salirse de control bastante rápido.

La bifurcación de @bcoca Loop no debe estar habilitada de forma predeterminada. Preferiría ver el valor predeterminado establecido en 1 e introducirlo como un parámetro forks o serial , pero incluir una advertencia. Es probable que rompa algún código existente. Habiendo dicho eso, espero con ansias esta función (especialmente para tareas que requieren delegate_to )

+1 para horquillas (falso por defecto)

+1 tenedores

+1 tenedores

+1 tenedores

+1 tenedores

+1 tenedores

+1 también para bifurcaciones, sin embargo, mientras tanto, también hay un nuevo complemento de estrategia de Ansible que brinda un gran aumento de rendimiento en general, y también para with_items bucles. Quizás para aquellos que buscan bifurcaciones por razones de rendimiento, valga la pena echarle un vistazo:

https://github.com/dw/mitogen
https://mitogen.readthedocs.io/en/latest/ansible.html

No puedo ver cómo esto mejorará exactamente con los bucles with_items. este complemento
mejora los problemas de rendimiento causados ​​por el uso de ssh como método de conexión.
Especialmente en largas distancias y redes latentes y con grandes números
de servidores

Esto no ayuda con las funciones de nube de AWS o Azure donde la ejecución
sucede en el controlador ansible y solo se ejecuta en un conjunto de elementos en
ese sistema en la nube y no se conecta a los hosts en absoluto, que es el
El problema principal con with_items es lento. No tiene nada que ver con un conjunto grande.
de máquinas o latencia o cualquier cosa relacionada con ssh. es simplemente el hecho
que ejecuta funciones en la nube en un bucle with_items en serie y nada
puede acelerar eso excepto que el proveedor de la nube mejore su velocidad o un
ejecución paralela de esas funciones en la nube por parte de ansible.

Tampoco menciona with_items en el artículo, así que no puedo ver cómo
esto ayudará incluso en lo más mínimo. puedes explicar un poco mas
¿Cómo podría ayudar esto? Me gustaría saber lo que me estoy perdiendo si me estoy perdiendo
algo aqui.

El sábado 10 de marzo de 2018 a las 21:58, NielsH [email protected] escribió:

+1 para bifurcaciones también, sin embargo, mientras tanto, también hay un nuevo Ansible
complemento de estrategia que brinda un gran aumento de rendimiento en general, y también
para bucles with_items. Quizás para aquellos que buscan horquillas para el rendimiento.
razones por las que vale la pena mirar:

https://github.com/dw/mitogen
https://mitogen.readthedocs.io/en/latest/ansible.html

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372070418 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AJd59qWI9n_DNmUqpmZYiIOMZAyjJy3uks5tdEyQgaJpZM4Fx8zF
.

De hecho, no ayudará en todos los casos. Sin embargo, la razón por la que estoy buscando bifurcaciones en with_items es por la lentitud con el procesamiento de cada elemento individualmente (incluso con canalización). A veces tengo que crear una gran cantidad (varios cientos) de directorios basados ​​en host_vars, o crear una plantilla de unos pocos cientos de archivos. Así que estoy recorriendo el módulo file y template principalmente.

Una vez probé la creación de plantillas de 100 archivos en 100 archivos separados a través de with_items en lugar de recorrer los elementos en la plantilla jinja y fusionar la plantilla en un solo archivo grande. Todo en un solo archivo toma 5 segundos, pero crear 100 archivos de configuración separados toma 30 minutos.

El complemento que mencioné me dio una mejora tan grande que pensé que valía la pena mencionarlo aquí.

dado que los bucles solo ejecutan la misma tarea una vez por elemento, cualquier mejora en la velocidad de ejecución de tareas debería traducirse en bucles más rápidos. Esto sucede solo para afectar las 'tareas remotas', por lo que cualquier cosa local no verá las ganancias.

Acordado. Estoy usando ansible para ejecutar solo tareas locales. En particular, para construir una docena de imágenes acoplables. Por el momento, ansible los compila en serie, por lo que lleva mucho tiempo y subutiliza la CPU multinúcleo. Me gustaría construir múltiples imágenes acoplables en paralelo.

@gjcarneiro entonces no los defina como datos, defínalos como hosts y diríjase a ellos, luego delegate_to: localhost para ejecutar las acciones en paralelo

Hah, gracias por el buen truco :) Pero aún así, incluso si funciona (no lo he probado), es una forma bastante complicada de ejecutar tareas en paralelo.

Por otra parte, es posible que esté usando ansible para un propósito completamente diferente al previsto, por lo que, en cierto modo, es mi culpa :(

no es realmente intrincado, es cómo Ansible debe usar la paralelización, por host, no por variable.

Sí, entiendo, no es culpa de Ansible, tiene sentido. Pero estoy usando Ansible como sistema de compilación (en lugar de, por ejemplo, hacer), porque Ansible es bueno como sistema de compilación en la mayoría de los sentidos. Pero, en mi estado de ánimo, pensando como un sistema de compilación, los "anfitriones" no tienen sentido. Un sistema de compilación como "make" no se preocupa por los "hosts", solo se preocupa por los archivos y las tareas. Estoy obligando a Ansible a usarse como sistema de compilación, y eso provoca un poco de disonancia cognitiva, eso es todo.

Ansible solo se preocupa por los hosts y las tareas, considere las imágenes que está creando como 'hosts' y, de repente, se ajusta a ambos paradigmas.

Ansible es una herramienta de gestión de configuración para muchas otras cosas, redes
dispositivos, tanto reales como virtuales, para una gran cantidad de servicios en la nube como
bases de datos, servicios web como eleastic beanstalk, lambda y todo el
componentes que se aplican a él como componentes de seguridad de IAM, mientras que Ansible es
bueno en los hosts si aún ejecuta principalmente máquinas virtuales/hosts, básicamente está en
TI de principios de la década de 2000. Sin ofender a nadie aqui hay aveces importantes
razones para ejecutar máquinas virtuales o incluso contenedores acoplables, pero todos se remontan a
motivos heredados. De hecho, cada vez más anfitriones van a ser menos
lo que automatiza. En mi opinión, si no nos ponemos en paralelo con_elementos, podríamos
así desechar ansible todos juntos.

Habiendo dicho eso, voy a pensar en positivo aquí y trataré de usar
delegar_to para algunos servicios en la nube Quiero decir que nunca intenté ejecutar en más de 200
Componentes de la nube que necesito de esta manera Supongo que solo consulta la lista
y volcarlo en un archivo de hosts en formato de hosts con ansible, luego intente
delegue_to: localhost Comentaré mis resultados aquí. Si funciona en
al menos podemos hacer una solicitud de extracción de documentación sobre cómo solucionarlo
with_item bucle problemas de serie de esta manera. Podemos asegurarnos de tener un enlace a
en las secciones de los módulos de la nube y en las secciones de la ventana acoplable.

El lunes 12 de marzo de 2018 a las 18:49, Brian Coca [email protected] escribió:

Ansible solo se preocupa por los hosts y las tareas, tenga en cuenta las imágenes que está
construyendo 'hosts' y de repente se ajusta a ambos paradigmas.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

@gjcarneiro entonces no los defina como datos, defínalos como hosts y apúntelos, luego delegue_to: localhost para ejecutar las acciones en paralelo

Este es un enfoque muy bueno, pero no parece funcionar dentro de la solución alternativa para reinicios continuos con simulación serial=1 (#12170). Entonces, una opción para la paralelización agregaría mucha más flexibilidad.

sin duda, pero también agrega una enorme capa de complejidad y la necesidad de lidiar con acciones simultáneas en un solo host hosts:all + lineinfile + delegate_to: localhost

Hrrm hasta ahora he creado una pequeña prueba para delegar_a: 127.0.0.1 para
las tareas de eliminación como esta también son un dolor en escala masiva.

Mi libro de jugadas se ve así:

• hosts: "{{ Grupo de implementación }}"

  Tareas:

  • nombre: eliminar vm y todos los recursos asociados
    azure_rm_máquina virtual:
    resource_group: "{{ host_vars[elemento]['resource_group'] }}"
    nombre: "{{ nombre_host_inventario }}"
    estado: ausente

  delegado_a: 127.0.0.1

Desafortunadamente, todavía intenta conectarse a las máquinas enumeradas en hosts para
ejecute la tarea azul azure_rm_virtualmachine.
¿Estoy haciendo esto correctamente? Parece que me estoy perdiendo algo, pero probé esto
anteriormente de muchas maneras diferentes, así que solo quiero saber si eres capaz de hacer
esta.

¿Esto realmente funciona? Esperemos que esto sea solo un problema de sintaxis.

El lunes 12 de marzo de 2018 a las 19:55, Isaac Egglestone < [email protected]

escribió:

Ansible es una herramienta de gestión de configuración para muchas otras cosas,
dispositivos de red, tanto reales como virtuales, para una gran cantidad de servicios en la nube
servicios como bases de datos, servicios web como eleastic beanstalk, lambda
y todos los componentes que se le aplican como componentes de seguridad de IAM, mientras que
Ansible es bueno en los hosts si aún ejecuta principalmente máquinas virtuales/hosts
básicamente en TI a principios de la década de 2000. Sin ofender a nadie aquí hay aveces
razones importantes para ejecutar máquinas virtuales o incluso contenedores acoplables, pero todos ellos
se remontan a razones heredadas. De hecho, cada vez más anfitriones van a
convertirse en menos de lo que automatiza. En mi opinión, si no nos ponemos en paralelo
with_items también podríamos desechar ansible todos juntos.

Habiendo dicho eso, voy a pensar en positivo aquí y trataré de usar
delegar_to para algunos servicios en la nube Quiero decir que nunca intenté ejecutar en más de 200
Componentes de la nube que necesito de esta manera Supongo que solo consulta la lista
y volcarlo en un archivo de hosts en formato de hosts con ansible, luego intente
delegue_to: localhost Comentaré mis resultados aquí. Si funciona en
al menos podemos hacer una solicitud de extracción de documentación sobre cómo solucionarlo
with_item bucle problemas de serie de esta manera. Podemos asegurarnos de tener un enlace a
en las secciones de los módulos de la nube y en las secciones de la ventana acoplable.

El lunes 12 de marzo de 2018 a las 18:49, Brian Coca [email protected] escribió:

Ansible solo se preocupa por los hosts y las tareas, tenga en cuenta las imágenes que está
construyendo 'hosts' y de repente se ajusta a ambos paradigmas.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

De acuerdo, deshabilitar la recopilación de datos soluciona este problema, sin embargo, causa
otro, host_vars ya no contiene el inventario dinámico azul de
estándar en

Entonces resource_group: "{{ host_vars[item]['resource_group'] }}" no
funciona en lo anterior y debe estar codificado de forma rígida en un nombre de grupo de recursos.

El domingo 18 de marzo de 2018 a las 11:14, Isaac Egglestone <
[email protected]> escribió:

Hrrm hasta ahora he creado una pequeña prueba para delegar_a: 127.0.0.1 para
las tareas de eliminación como esta también son un dolor en escala masiva.

Mi libro de jugadas se ve así:

• hosts: "{{ Grupo de implementación }}"

  Tareas:

  • nombre: eliminar vm y todos los recursos asociados
    azure_rm_máquina virtual:
    resource_group: "{{ host_vars[elemento]['resource_group'] }}"
    nombre: "{{ nombre_host_inventario }}"
    estado: ausente

  delegado_a: 127.0.0.1

Desafortunadamente, todavía intenta conectarse a las máquinas enumeradas en hosts para
ejecute la tarea azul azure_rm_virtualmachine.
¿Estoy haciendo esto correctamente? Parece que me estoy perdiendo algo, pero probé esto
anteriormente de muchas maneras diferentes, así que solo quiero saber si eres capaz de hacer
esta.

¿Esto realmente funciona? Esperemos que esto sea solo un problema de sintaxis.

El lunes 12 de marzo de 2018 a las 19:55, Isaac Egglestone <
[email protected]> escribió:

Ansible es una herramienta de gestión de configuración para muchas otras cosas,
dispositivos de red, tanto reales como virtuales, para una gran cantidad de servicios en la nube
servicios como bases de datos, servicios web como eleastic beanstalk, lambda
y todos los componentes que se le aplican como componentes de seguridad de IAM, mientras que
Ansible es bueno en los hosts si aún ejecuta principalmente máquinas virtuales/hosts
básicamente en TI a principios de la década de 2000. Sin ofender a nadie aquí hay aveces
razones importantes para ejecutar máquinas virtuales o incluso contenedores acoplables, pero todos ellos
se remontan a razones heredadas. De hecho, cada vez más anfitriones van a
convertirse en menos de lo que automatiza. En mi opinión, si no nos ponemos en paralelo
with_items también podríamos desechar ansible todos juntos.

Habiendo dicho eso, voy a pensar en positivo aquí y trataré de usar
delegar_to para algunos servicios en la nube Quiero decir que nunca intenté ejecutar en más de 200
Componentes de la nube que necesito de esta manera Supongo que solo consulta la lista
y volcarlo en un archivo de hosts en formato de hosts con ansible, luego intente
delegue_to: localhost Comentaré mis resultados aquí. Si funciona en
al menos podemos hacer una solicitud de extracción de documentación sobre cómo solucionarlo
with_item bucle problemas de serie de esta manera. Podemos asegurarnos de tener un enlace a
en las secciones de los módulos de la nube y en las secciones de la ventana acoplable.

El lunes 12 de marzo de 2018 a las 18:49, Brian Coca [email protected]
escribió:

Ansible solo se preocupa por los hosts y las tareas, tenga en cuenta las imágenes que está
construyendo 'hosts' y de repente se ajusta a ambos paradigmas.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

De acuerdo, he modificado el Libro de jugadas a continuación para probar varias cosas.

Primero intenté configurar delegar_facts: True en caso de que esto ayudara, pero por supuesto
incluso según la documentación, realmente no esperaba que eso funcionara.
En segundo lugar, configuré Recolectar_facts: no e intenté ejecutar la configuración para reducir el hecho.
reuniendo a nada con la esperanza de que opte por no conectarse en absoluto, pero de
Por supuesto, como se esperaba, todavía intentó conectarse a la máquina.
3. Intenté configurar la conexión: localhost pero extrañamente todavía quiere
conectarse de forma remota a la máquina para recopilar los datos a pesar de que lo sabe
ejecutará el juego localmente, un poco molesto allí, pero entiendo la lógica como
¿De qué otra forma conocerá los detalles del host en cuestión sin hacer
esta..

Probablemente pueda usar el libro de jugadas para encender las máquinas primero y luego dejar que
ansible inicie sesión en ellos y recopile los datos innecesarios. Esto seria para que
Puedo hacer que host_vars funcione y luego eliminar las máquinas. Me gustaría saber
si alguien tiene una mejor solución aquí, ya que también consume mucho tiempo
esfuerzo cuando tengo cien o más máquinas y tengo que alimentarlas
todo arriba solo para luego eliminarlos.

Hasta ahora veo usar esto como una solución en lugar de un paralelo with_items
solución como si tuviera potencial, pero las máquinas en cuestión todavía necesitan ser
arriba y accesible si necesita algún tipo de información de azure_rm.py mientras
haz esto para que haya al menos una advertencia allí. Eso es a menos que alguien sepa
cómo obtener acceso a host_vars desde Azure que se pasan a través del estándar en
cuando reunir_hechos: no

En realidad, por supuesto, tengo el mismo problema cuando ejecuto todo esto usando un
with_items lista, sin embargo, esperaba evitar ese trabajo si estoy
va a utilizar hosts de nuevo. La solución consiste en volcar azure_rm.py en un
json en la línea de comando y luego cargarlo en una variable para obtener
acceder a ellos de nuevo.

Si espero mi objetivo final aquí para modificar cientos o incluso miles
de componentes sin servidor en paralelo, tal vez esto esté bien ya que puedo
usa cosas como azure_rm_functionapp_facts
http://docs.ansible.com/ansible/latest/azure_rm_functionapp_facts_module.html
para
recopilar hechos sobre ellos y usarlos en la obra en teoría, aunque esto
aún no se ha probado.

Todavía no tengo una gran lógica sobre cómo hacer esto correctamente para crear un
solicitud de extracción de documentación al respecto, ya que el método parece hasta ahora en gran medida
depende de lo que esté haciendo y no estoy seguro de querer sugerir el uso de
json dump hack en la documentación.

Esperaré los comentarios de cualquiera a quien le importe esto en
esta lista de problemas para decidir mi siguiente paso. Mientras tanto, usaré mi truco para obtener
mi trabajo inmediato hecho.

• hosts: "{{ Grupo de implementación }}"
  reunir_hechos: no
  Tareas:
  
  
  
  • configuración:
    
    reunir_subconjunto=!todos,!min
  
  
  • nombre: eliminar vm y todos los recursos asociados
    
    azure_rm_máquina virtual:
    
    resource_group: "{{ host_vars[inventario_hostname]['resource_group']
    
    }}"
    
    nombre: "{{ nombre_host_inventario }}"
    
    estado: ausente
    
    delegado_a: localhost
    
    

    delegar_facts: Verdadero

  
  

El domingo 18 de marzo de 2018 a las 12:04 p. m., Isaac Egglestone <
[email protected]> escribió:

De acuerdo, deshabilitar la recopilación de datos soluciona este problema, sin embargo, causa
otro, host_vars ya no contiene el inventario dinámico azul de
estándar en

Entonces resource_group: "{{ host_vars[item]['resource_group'] }}"
no funciona en lo anterior y debe codificarse de forma rígida en un grupo de recursos
nombre.

El domingo 18 de marzo de 2018 a las 11:14, Isaac Egglestone <
[email protected]> escribió:

Hrrm hasta ahora he creado una pequeña prueba para delegar_a: 127.0.0.1 para
las tareas de eliminación como esta también son un dolor en escala masiva.

Mi libro de jugadas se ve así:

• hosts: "{{ Grupo de implementación }}"

  Tareas:

  • nombre: eliminar vm y todos los recursos asociados
    azure_rm_máquina virtual:
    resource_group: "{{ host_vars[elemento]['resource_group'] }}"
    nombre: "{{ nombre_host_inventario }}"
    estado: ausente

  delegado_a: 127.0.0.1

Desafortunadamente, todavía intenta conectarse a las máquinas enumeradas en hosts
para ejecutar la tarea azul azure_rm_virtualmachine.
¿Estoy haciendo esto correctamente? Parece que me estoy perdiendo algo, pero lo intenté.
esto anteriormente de muchas maneras diferentes, así que solo quiero saber si eres capaz de
hacer esto.

¿Esto realmente funciona? Esperemos que esto sea solo un problema de sintaxis.

El lunes 12 de marzo de 2018 a las 19:55, Isaac Egglestone <
[email protected]> escribió:

Ansible es una herramienta de gestión de configuración para muchas otras cosas,
dispositivos de red, tanto reales como virtuales, para una gran cantidad de servicios en la nube
servicios como bases de datos, servicios web como eleastic beanstalk, lambda
y todos los componentes que se le aplican como componentes de seguridad de IAM, mientras que
Ansible es bueno en los hosts si aún ejecuta principalmente máquinas virtuales/hosts
básicamente en TI a principios de la década de 2000. Sin ofender a nadie aquí hay aveces
razones importantes para ejecutar máquinas virtuales o incluso contenedores acoplables, pero todos ellos
se remontan a razones heredadas. De hecho, cada vez más anfitriones van a
convertirse en menos de lo que automatiza. En mi opinión, si no nos ponemos en paralelo
with_items también podríamos desechar ansible todos juntos.

Habiendo dicho eso, voy a pensar en positivo aquí y trataré de usar
delegar_to para algunos servicios en la nube Quiero decir que nunca intenté ejecutar en más de 200
Componentes de la nube que necesito de esta manera Supongo que solo consulta la lista
y volcarlo en un archivo de hosts en formato de hosts con ansible, luego intente
delegue_to: localhost Comentaré mis resultados aquí. Si funciona en
al menos podemos hacer una solicitud de extracción de documentación sobre cómo solucionarlo
with_item bucle problemas de serie de esta manera. Podemos asegurarnos de tener un enlace a
en las secciones de los módulos de la nube y en las secciones de la ventana acoplable.

El lunes 12 de marzo de 2018 a las 18:49, Brian Coca [email protected]
escribió:

Ansible solo se preocupa por los hosts y las tareas, tenga en cuenta las imágenes que está
construyendo 'hosts' y de repente se ajusta a ambos paradigmas.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

También tengo un caso de uso para horquillas, lo que haría esto mucho más fácil. El libro de jugadas está implementando un montón de instancias openstack a través de terraform con ips flotantes elegidas al azar. Luego itero sobre los ips para verificar que el puerto 22 esté abierto en cada host creado. El método actual para hacer esto es con un libro de jugadas multijugador:

- hosts: localhost
  connection: local
  gather_facts: no
  tasks:
...
  - name: Run terraform
    terraform:
      plan_file: '{{tf_plan | default(omit)}}'
      project_path: '{{terraform_path}}/{{infra}}'
      state: '{{state}}'
      state_file: '{{stat_tfstate.stat.exists | ternary(stat_tfstate.stat.path, omit)}}'
      variables: '{{terraform_vars | default(omit)}}'
    register: tf_output

  - name: Add new hosts
    with_items: '{{tf_output.outputs.ip.value}}' # configued this in terraform to output a list of assigned ips.
    add_host:
      name: '{{item}}'
      groups: new_hosts

- hosts: new_hosts
  gather_facts: no
  connection: local
  tasks:
   - name: Wait for port 22 to become available
     wait_for:
       host: '{{ansible_host}}'
       port: 22
       state: started
       timeout: 60

Esto se ejecuta con: ansible-playbook -i localhost, deploy-test-clients.yml --extra-vars="infra=terraform_os_instances state=present"
Esta es, por supuesto, una solución limitada, ya que no siempre tiene una lista de direcciones IP que se pueda analizar ordenadamente en el inventario para trabajar.

Dado que muchas personas parecen tener problemas con el rendimiento de los archivos de plantillas localmente, tal vez se podría crear un módulo template_local específico para resolver este problema específico. Al menos sería un comienzo... Lo intentaría yo mismo, pero no tendré tiempo para el futuro previsible.

Más de 30 minutos para crear una plantilla de 100 archivos que se pueden hacer en 5 segundos con jinja es ridículo.

La creación de plantillas de @saplla siempre ocurre localmente, lo único que ocurre de forma remota es copiar la plantilla y configurar los permisos.

Solo para aclarar, estoy hablando de aquellos usuarios que desean crear plantillas de archivos como tareas locales, por ejemplo, para alimentar otros sistemas de compilación o, en mi caso, para implementar recursos de k8s usando kubectl.

Lo que quiero decir es descargar el bucle y las plantillas a jinja a través de un módulo que es un contenedor simple. El módulo podría tomar algo de contexto y la definición del bucle (lo que normalmente se colocaría en with_nested y amigos) y simplemente eliminar ansible por completo para esta tarea (tal vez el contenedor podría ejecutar jinja en paralelo si acelera las cosas) .

Se podría invocar así:

    template_parallel:
      src: "{{ item[0] }}"
      dest: "{{ tempdir }}/{{ item[1] }}-{{ item[0] | basename }}"
      context: "{{ hostvars[inventory_hostname] }}"
      nested:
      - "{{ templates.stdout_lines }}"
      - "{{ namespaces.stdout_lines }}"

El ejemplo anterior toma todas las variables definidas por ansible como contexto, pero se puede pasar cualquier dict.

Como digo, no tengo tiempo para trabajar en esto ahora, pero ¿suena factible el enfoque @bcoca ?

Eso supone que cada elemento es independiente, ese no es siempre el caso, puede hacer que los valores de los elementos actuales dependan de los anteriores y/o de los resultados de las iteraciones anteriores, o simplemente pueden ser acumulativos.

La mayor parte del tiempo dedicado a la creación de plantillas tiene que ver con los vars, no con las plantillas en sí, ya que deben ser consistentes, no ganaría mucho en la paralelización a menos que esté dispuesto a cambiar los comportamientos que romperían las suposiciones actuales.

Además, las plantillas ya son paralelas, por host, pero no por elemento.

Bien, gracias por los pensamientos. De hecho, sería lo suficientemente bueno para mi caso de uso y parece que también podría serlo para otras personas en este hilo. Solo estoy usando ansible para cargar configuraciones jerárquicas y archivos de plantilla localmente antes de invocar algún binario que los implemente (kubectl, helm, etc.). Estaría feliz con un módulo de plantillas liviano y extremadamente simple si tuviera tanto rendimiento que redujera los tiempos de creación de plantillas de minutos a segundos.

Trataré de ver esto cuando se convierta en un problema para nosotros, a menos que alguien se me adelante.

Originalmente presenté el n.º 10695, pero al ver que tomará un tiempo resolverlo, terminé abordando estos casos de uso con scripts de shell (por ejemplo, solo diga que tengo que hacer algo en 50 repositorios de Git en un solo host, uso Ansible para ejecutar un solo script una vez que hace lo mismo 50 veces). Desafortunadamente, esto significa renunciar a algunas de las cosas que obtiene gratis con Ansible, como informes de cambios muy granulares, y también tiene que implementar toda la lógica "ejecutar solo si" usted mismo y tener mucho cuidado con el manejo de errores, pero es probablemente dos órdenes de magnitud más rápido. Como tal, incluso si terminamos obteniendo una opción "paralela" en el futuro, es posible que no sea tan rápido como mis scripts personalizados y probablemente no me molestaré en cambiar a ella.

@wincent, un bucle paralelo probablemente siempre será más lento que un script de shell/programa dedicado, ya que Ansible hace mucho más que simplemente 'aplicar la acción'.

@bcoca : sí, eso confirma mi entendimiento.

@saplla k8s_raw es mejor que usar una plantilla para esto, puede incluir el yaml en su inventario si es necesario :) (no es el tema de este PR)
¿Cuál es el estado actual de esto? ¿Podemos esperar algo en 2.6 @bcoca ?
Estoy administrando miles de privilegios de postgresql en mis clústeres de bases de datos y 25 minutos es dolorosamente lento

@nerzhul Gracias, pero no es mejor para nosotros. Demasiada magia. Necesitamos plantillas.

@sapila , siempre puede crear un objetivo de host por plantilla para paralelizar las plantillas tanto como sea posible y luego usar reproducciones o delegaciones subsiguientes para entregar a los hosts reales adecuados.

@bcoca un poco raro :)

para nada, es MUY raro, pero funciona hoy

cierre a favor de https://github.com/ansible/proposals/issues/140