S'il vous plaît, ne l'appelons pas how . C'est encore pire à lire que become: true . Mais la fonctionnalité en dessous a l'air géniale.

inclut le correctif pour # 10695

Excellent. Dans l'intérêt du bikeshedding, appelez-le peut-être looping: .

:+1:

+1

+1 en particulier pour la parallélisation intra-hôte !

:+1:

:+1:
mais ne l'appelons pas "comment"

voici donc une solution de contournement pour interrompre une tâche de boucle après le premier échec

- 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 ne fonctionne pas à partir de la fin (ansible 1.9.3 ubuntu)

TÂCHE : [interrompre la boucle après 3] * * * * * * * * * * * * * * * ** *
ok : [localhost] => (élément=1) => {
"échec": faux,
"failed_when_result": faux,
"objet 1,
"message": "1"
}
ok : [localhost] => (élément=2) => {
"échec": faux,
"failed_when_result": faux,
"article": 2,
"message": "2"
}
échoué : [localhost] => (item=3) => {"failed": vrai, "failed_when_result": vrai, "item": 3, "verbose_always": vrai}
msg : 3
ok : [localhost] => (item=4) => {
"échec": faux,
"failed_when_result": faux,
"article": 4,
"message": "4"
}
ok : [localhost] => (item=5) => {
"échec": faux,
"failed_when_result": faux,
"article": 5,
"message": "5"
}

ah, oui, cela fonctionnera tel quel en 2.0 comme en 1.9 l'enregistrement ne se produit qu'après la fin de la boucle.

+1 sur les fourches

+1
peut-être au lieu de "comment", loop_details ou options ?

+1

+1, utiliser wait_for partir de localhost pour attendre que 100 hôtes EC2 arrivent me tue...

+1 pour une raison similaire à senderista

+1

:+1:

squash et forks seraient des fonctionnalités géniales qui accéléreraient énormément l'exécution d'Ansible.

Je remplacerais également how par quelque chose comme loop_details , loop_settings , loop_options , ou quelque chose de similaire.

loop_control , déjà en 2.1 avec la partie label implémentée.

squash peut simplement disparaître car il est facile de simplement transmettre une liste aux modules qui le prennent en charge :

apt: name={{listofpackages}}

et éviter complètement la boucle

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

+1 fourchettes

+1 fourchettes

J'ai eu un cas d'utilisation pour une nouvelle configuration pour une pause conditionnelle break_when

+1 fourches et j'espère que cela fonctionnera également pour la parallélisation des séquences de tâches à exécuter comme dans :
- include: service.yml
with_items: "{{services|default([])}}"

Sinon, il y a déjà les async/async_status .

+1 fourchettes

J'attends que les modules openstack parcourent les boucles with_ sur plus de 100 éléments...

+1 sur les fourches. Pourrait l'utiliser pour copier des AMI dans toutes les régions AWS.

+1 sur les fourches. S'il te plaît! faites-en une partie de loop_control

+1 sur les fourches

+1 sur les fourches

+1, besoin de fourches aussi :-)

+1 sur les fourches

+1 sur les fourches

Forks serait génial, +1

Je reste toujours assis en silence ne voulant pas contribuer au spam, car il est difficile d'évaluer entre les projets s'il est bien accueilli ou non, mais il semble que le train fourche +1 ait quitté la gare !

+1 sur les fourches

+1 sur les fourches

+1 sur les fourches

:+1: sur fourches

@bcoca Salutations ! Merci d'avoir pris le temps d'ouvrir ce sujet. Pour que la communauté puisse gérer efficacement votre problème, nous avons besoin d'un peu plus d'informations.

Voici les articles que nous n'avons pas pu trouver dans votre description :

• type de probleme
• version ansible
• Nom du composant

Veuillez définir la description de ce problème avec ce modèle :
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

cliquez ici pour l'aide du bot

+1 sur les fourches

+1 sur les fourches !

+1 sur Fourchettes !

+1 sur les fourches !

+1 sur les fourches !

Une mise à jour sur la fourche? Quand est-il censé être prêt ?
Mon cas d'utilisation instancie environ 20 conteneurs sur un serveur avec with_sequence . Maintenant ça prend trop de temps :(
Je serais heureux de vous aider, mais j'aurais besoin de conseils pour savoir où mettre les mains

@bitliner personne n'a créé de PR pour cela, si c'est ce que vous demandez, c'est en fait très difficile à faire correctement.

en ce qui concerne votre problème, déclarez simplement X hôtes dans l'inventaire et bouclez sur hosts: au lieu de with_ pour les créer en parallèle.

inventaire:

[containers]
container[000:020]

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

c'est-à-dire que le conteneur est un module 'constitué'.

@bcoca votre solution n'est pas claire pour moi. Pour être sûr, est-ce ce que vous voulez dire?

fichier 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 ...

fichier principal.yml

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

basé sur un module de conteneur que je devrais implémenter, n'est-ce pas ? Dans ce cas, j'aurais tous les conteneurs avec le même nom, et ce n'est pas acceptable, n'est-ce pas ?

De plus, quels sont les défis pour implémenter correctement la boucle en parallèle ?

Mon cas d'utilisation doit accélérer cette tâche :

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

Je ne peux pas utiliser l' échelle docker-compose car j'ai besoin d'acheminer le trafic entre les conteneurs d'une manière spécifique (c'est pourquoi j'utilise with_sequence pour générer différents noms de conteneur docker).

Je pourrais construire un module qui prend la déclaration d'un conteneur et basé sur un paramètre d' échelle , il instancie à distance plusieurs conteneurs en parallèle. Est-ce que ça fait du sens? Avez-vous de l'aide pour comprendre comment appeler/réutiliser dans myModule le module docker_container et quelles sont les API qu'Ansible propose pour exécuter quelque chose en parallèle ?

@bitliner vous n'avez pas suivi mes instructions, j'avais des noms uniques dans l'inventaire (en utilisant la plage pour fonctionner comme une séquence). Comme les noms sont uniques dans l'inventaire, vous venez de déclarer le même nom N fois, mais vous avez toujours un hôte, ce qui ne cause pas votre deuxième problème sur les noms de conteneurs dupliqués car vous ne bouclez que sur 1 hôte.

Dans tous les cas, si vous souhaitez suivre votre problème, utilisez ML ou IRC car ce serait un peu hors sujet pour ce ticket.

@bcoca Comment puis-je avoir un hôte si vous avez déclaré 20 hôtes ?

[containers]
container[000:020]

va se connecter à container001 , container002 , etc.

Cela fonctionne pour avoir des noms uniques, mais ce qui n'est pas clair pour moi, c'est pourquoi vous dites que j'ai toujours un hôte (au lieu de 20).
hosts:containers signifie pour moi 20 hôtes, pas un seul. Qu'est-ce que j'ignore dans cette solution ?

@bitliner cause ceci:

[containers]
192.168.1.100
192.168.1.100
192.168.1.100
192.168.1.100

n'est pas 4 hôtes, mais 1

également à ce stade, c'est à peu près hors sujet, si vous voulez continuer à obtenir de l'aide à ce sujet, allez sur IRC ou ML

j'ai résolu en utilisant

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

et

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

Une question : imager pour ajouter une instruction fork , les changements consisteraient-ils à réécrire la méthode run_loop afin de lui faire gérer le niveau de parallélisme et l'asynchronisme ?

et puis ça commence à devenir 'amusant'...:

• la fourche de boucle compte-t-elle par rapport au --forks global, faites-le par télécommande?
• que faire des boucles lorsque les éléments dépendent des éléments précédents (pas seulement l'exécution de la tâche, mais les conditions, etc.) ?
• comment gérer les problèmes de concurrence lorsque plusieurs forks s'exécutent sur le même hôte ? c'est-à-dire qu'ils mettent à jour le même fichier
• comment gérons-nous le nettoyage? pour le moment, ils peuvent réutiliser les répertoires tmp .. mais chaque exécution se nettoie après elle-même, cela peut maintenant causer des problèmes.

Et il y a quelques autres problèmes que je connais .. bien sûr, il y en a beaucoup dont je ne serai pas conscient jusqu'à ce que quelqu'un essaie de le mettre en œuvre. J'ai des solutions pour quelques-uns, mais cela commence à devenir incontrôlable assez rapidement.

@bcoca Loop forking ne doit pas être activé par défaut. Je préférerais voir la valeur par défaut définie sur 1 et l'introduire en tant que paramètre forks ou serial , mais inclure un avertissement. Cela cassera probablement du code existant. Cela dit, j'attends avec impatience cette fonctionnalité (surtout pour les tâches qui nécessitent delegate_to )

+1 pour les fourches (faux par défaut)

+1 fourchettes

+1 fourchettes

+1 fourchettes

+1 fourchettes

+1 fourchettes

+1 pour les fourches également, mais en attendant, il existe également un nouveau plugin de stratégie Ansible qui donne une grande augmentation des performances en général, ainsi que pour les boucles with_items . Peut-être que pour ceux qui veulent des fourches pour des raisons de performances, cela vaut la peine de regarder :

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

Je ne vois pas comment cela améliorera exactement les boucles with_items. Ce plugin
améliore les problèmes de performances causés par l'utilisation de ssh comme méthode de connexion.
Surtout sur de longues distances et des réseaux latents et avec un grand nombre
de serveurs.

Cela n'aide pas avec les fonctions cloud AWS ou Azure où l'exécution
se produit sur le contrôleur ansible et s'exécute simplement sur un ensemble d'éléments dans
ce système cloud et ne se connecte pas du tout aux hôtes, ce qui est le
problème principal avec with_items étant lent. Cela n'a rien à voir avec un grand ensemble
des machines ou la latence ou tout ce qui concerne ssh. C'est simplement le fait
qu'il exécute des fonctions cloud dans une boucle with_items en série et rien
peut accélérer cela, sauf si le fournisseur de cloud améliore sa vitesse ou un
exécution parallèle de ces fonctions cloud par ansible.

Il ne mentionne pas du tout with_items dans l'article, donc je ne vois pas comment
cela aidera même dans un tout petit peu. Pouvez-vous expliquer un peu plus
comment cela pourrait aider? J'aimerais savoir ce qui me manque si je manque
quelque chose ici.

Le samedi 10 mars 2018 à 21h58, NielsH [email protected] a écrit :

+1 pour les fourches également, mais en attendant, il y a aussi un nouvel Ansible
plugin de stratégie qui donne une grande augmentation des performances en général, et aussi
pour les boucles with_items. Peut-être pour ceux qui veulent des fourches pour la performance
raisons pour lesquelles cela vaut la peine d'être examiné :

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

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372070418 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AJd59qWI9n_DNmUqpmZYiIOMZAyjJy3uks5tdEyQgaJpZM4Fx8zF
.

En effet, cela n'aidera pas dans tous les cas. Cependant, la raison pour laquelle je recherche des fourchettes dans with_items est due à la lenteur du traitement de chaque élément individuellement (même avec le pipelining). Parfois, je dois créer un grand nombre (plusieurs centaines) de répertoires basés sur host_vars, ou modéliser quelques centaines de fichiers. Donc, je boucle principalement sur les modules file et template .

Une fois, j'ai testé la création de modèles de 100 fichiers dans 100 fichiers séparés via with_items par rapport à une boucle sur les éléments du modèle jinja lui-même et à la fusion du modèle dans un seul fichier volumineux. Tout dans un seul fichier prend 5 secondes, mais la création de 100 fichiers de configuration distincts prend 30 minutes.

Le plugin que j'ai mentionné a apporté une telle amélioration pour moi que j'ai pensé qu'il valait la peine de le mentionner ici.

étant donné que les boucles exécutent simplement la même tâche une fois par élément, toute amélioration de la vitesse d'exécution des tâches devrait se traduire par des boucles plus rapides. Cela n'affecte que les «tâches distantes», de sorte que tout ce qui est local ne verra pas les gains.

D'accord. J'utilise ansible pour exécuter uniquement des tâches locales. Notamment pour construire une dizaine d'images docker. Pour le moment, ansible les construit en série, cela prend donc beaucoup de temps et sous-utilise le processeur multicœur. Je souhaite créer plusieurs images Docker en parallèle.

@gjcarneiro alors ne les définissez pas comme des données, définissez-les comme des hôtes et ciblez-les, puis delegate_to: localhost pour exécuter les actions en parallèle

Hah, merci pour l'astuce :) Mais quand même, même si cela fonctionne (je n'ai pas testé), c'est une manière plutôt compliquée d'exécuter des tâches en parallèle.

Là encore, j'utilise peut-être ansible à des fins complètement différentes de celles pour lesquelles il était prévu, donc d'une certaine manière, c'est de ma faute :(

pas vraiment compliqué, c'est ainsi qu'Ansible est censé utiliser la parallélisation, par hôte, pas par variable.

Oui, je comprends, ce n'est pas la faute d'Ansible, c'est logique. Mais j'utilise Ansible comme système de construction (au lieu de make, par exemple), car Ansible est agréable en tant que système de construction à bien des égards. Mais, dans mon état d'esprit, en pensant comme un système de construction, les "hôtes" n'ont pas de sens. Un système de construction comme "make" ne se soucie pas des "hôtes", il ne se soucie que des fichiers et des tâches. Je force Ansible à être utilisé comme système de construction, et cela provoque un peu de dissonance cognitive, c'est tout.

Ansible ne se soucie que des hôtes et des tâches, considérez les images que vous créez des «hôtes» et tout à coup, cela correspond aux deux paradigmes.

Ansible est un outil de gestion de configuration pour bien d'autres choses, les réseaux
appareils, réels et virtuels, pour une énorme quantité de services cloud tels que
bases de données, services Web tels que eleastic beanstalk, lambda et tous les
composants qui s'y appliquent comme les composants de sécurité IAM, tandis qu'Ansible est
bon chez les hôtes si vous utilisez toujours principalement des machines virtuelles / hôtes, vous êtes essentiellement dans
Informatique du début des années 2000. N'offenser personne ici, il est parfois important
raisons d'exécuter des machines virtuelles ou même des conteneurs Docker, mais elles découlent toutes de
raisons héritées. En fait, de plus en plus d'hébergeurs vont devenir moins
ce qu'il automatise. IMO Si nous n'obtenons pas de parallèle avec_items, nous pourrions aussi
bien scrap ansible tous ensemble.

Cela dit, je vais penser positif ici et essayer d'utiliser
délégué_to pour certains services cloud, je veux dire que je n'ai jamais essayé d'exécuter sur 200+
Composants cloud dont j'ai besoin de cette façon, je suppose qu'il suffit d'interroger la liste
et videz-le dans un fichier hosts au format hosts avec ansible, puis essayez
délégué_à: localhost Je ferai part de mes résultats ici. Si ça marche à
au moins, nous pouvons faire une demande d'extraction de documentation sur la façon de contourner
with_item boucle des problèmes de série de cette façon. Nous pouvons nous assurer d'avoir un lien vers
les sur les sections des modules cloud et les sections pour docker.

Le lundi 12 mars 2018 à 18h49, Brian Coca [email protected] a écrit :

Ansible ne se soucie que des hôtes et des tâches, considérez les images que vous êtes
construire des « hôtes » et tout à coup, cela correspond aux deux paradigmes.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

@gjcarneiro alors ne les définissez pas en tant que données, définissez-les en tant qu'hôtes et ciblez-les, puis délégué_à : localhost pour exécuter les actions en parallèle

C'est une très bonne approche mais cela ne semble pas fonctionner dans la solution de contournement pour les redémarrages progressifs avec la simulation serial=1 (#12170). Ainsi, une option de parallélisation ajouterait beaucoup plus de flexibilité.

sans aucun doute, mais cela ajoute également une énorme couche de complexité et la nécessité de gérer des actions simultanées sur un seul hôte ala hosts:all + lineinfile + delegate_to: localhost

Hrrm jusqu'à présent, j'ai créé un petit test pour delegation_to : 127.0.0.1 pour
tâches de suppression, car elles sont également pénibles à grande échelle.

Mon playbook ressemble à ceci :

• hôtes : "{{ DeploymentGroup }}"

  Tâches:

  • name : supprimer la machine virtuelle et toutes les ressources associées
    azure_rm_virtualmachine :
    resource_group : "{{ host_vars[item]['resource_group'] }}"
    nom : "{{ nom_hôte_inventaire }}"
    état : absent

  délégué_à : 127.0.0.1

Malheureusement, il essaie toujours de se connecter aux machines répertoriées dans les hôtes pour
exécutez la tâche azure azure_rm_virtualmachine.
Est-ce que je fais ça correctement ? Il me semble qu'il me manque quelque chose, mais j'ai essayé ceci
auparavant de différentes manières, alors je veux juste savoir que vous êtes capable de faire
ce.

Est-ce que cela fonctionne réellement? J'espère que ce n'est qu'un problème de syntaxe.

Le lundi 12 mars 2018 à 19 h 55, Isaac Egglestone < [email protected]

a écrit:

Ansible est un outil de gestion de configuration pour beaucoup d'autres choses,
périphériques réseaux, réels et virtuels, pour une énorme quantité de cloud
des services tels que des bases de données, des services Web tels que eleastic beanstalk, lambda
et tous les composants qui s'y appliquent comme les composants de sécurité IAM, tandis que
Ansible est bon pour les hôtes si vous exécutez toujours principalement des machines virtuelles/hôtes votre
essentiellement dans l'informatique du début des années 2000. N'offensant personne ici il y a parfois
des raisons importantes pour exécuter des machines virtuelles ou même des conteneurs Docker, mais ils sont tous
revenir à des raisons héritées. En fait, de plus en plus d'hôtes vont
devenir moins de ce qu'il automatise. IMO Si nous n'obtenons pas de parallèle
with_items, nous pourrions tout aussi bien supprimer ansible tous ensemble.

Cela dit, je vais penser positif ici et essayer d'utiliser
délégué_to pour certains services cloud, je veux dire que je n'ai jamais essayé d'exécuter sur 200+
Composants cloud dont j'ai besoin de cette façon, je suppose qu'il suffit d'interroger la liste
et videz-le dans un fichier hosts au format hosts avec ansible, puis essayez
délégué_à: localhost Je ferai part de mes résultats ici. Si ça marche à
au moins, nous pouvons faire une demande d'extraction de documentation sur la façon de contourner
with_item boucle des problèmes de série de cette façon. Nous pouvons nous assurer d'avoir un lien vers
les sur les sections des modules cloud et les sections pour docker.

Le lundi 12 mars 2018 à 18h49, Brian Coca [email protected] a écrit :

Ansible ne se soucie que des hôtes et des tâches, considérez les images que vous êtes
construire des « hôtes » et tout à coup, cela correspond aux deux paradigmes.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

D'accord, la désactivation de la collecte des faits résout ce problème, mais cela provoque
un autre, host_vars ne contient plus l'inventaire dynamique azur de
norme en.

Alors resource_group : "{{ host_vars[item]['resource_group'] }}" ne fonctionne pas
fonctionne dans ce qui précède et doit être codé en dur avec un nom de groupe de ressources.

Le dimanche 18 mars 2018 à 11 h 14, Isaac Egglestone <
[email protected]> a écrit :

Hrrm jusqu'à présent, j'ai créé un petit test pour delegation_to : 127.0.0.1 pour
tâches de suppression, car elles sont également pénibles à grande échelle.

Mon playbook ressemble à ceci :

• hôtes : "{{ DeploymentGroup }}"

  Tâches:

  • name : supprimer la machine virtuelle et toutes les ressources associées
    azure_rm_virtualmachine :
    resource_group : "{{ host_vars[item]['resource_group'] }}"
    nom : "{{ nom_hôte_inventaire }}"
    état : absent

  délégué_à : 127.0.0.1

Malheureusement, il essaie toujours de se connecter aux machines répertoriées dans les hôtes pour
exécutez la tâche azure azure_rm_virtualmachine.
Est-ce que je fais ça correctement ? Il me semble qu'il me manque quelque chose, mais j'ai essayé ceci
auparavant de différentes manières, alors je veux juste savoir que vous êtes capable de faire
ce.

Est-ce que cela fonctionne réellement? J'espère que ce n'est qu'un problème de syntaxe.

Le lundi 12 mars 2018 à 19 h 55, Isaac Egglestone <
[email protected]> a écrit :

Ansible est un outil de gestion de configuration pour beaucoup d'autres choses,
périphériques réseaux, réels et virtuels, pour une énorme quantité de cloud
des services tels que des bases de données, des services Web tels que eleastic beanstalk, lambda
et tous les composants qui s'y appliquent comme les composants de sécurité IAM, tandis que
Ansible est bon pour les hôtes si vous exécutez toujours principalement des machines virtuelles/hôtes votre
essentiellement dans l'informatique du début des années 2000. N'offensant personne ici il y a parfois
des raisons importantes pour exécuter des machines virtuelles ou même des conteneurs Docker, mais ils sont tous
revenir à des raisons héritées. En fait, de plus en plus d'hôtes vont
devenir moins de ce qu'il automatise. IMO Si nous n'obtenons pas de parallèle
with_items, nous pourrions tout aussi bien supprimer ansible tous ensemble.

Cela dit, je vais penser positif ici et essayer d'utiliser
délégué_to pour certains services cloud, je veux dire que je n'ai jamais essayé d'exécuter sur 200+
Composants cloud dont j'ai besoin de cette façon, je suppose qu'il suffit d'interroger la liste
et videz-le dans un fichier hosts au format hosts avec ansible, puis essayez
délégué_à: localhost Je ferai part de mes résultats ici. Si ça marche à
au moins, nous pouvons faire une demande d'extraction de documentation sur la façon de contourner
with_item boucle des problèmes de série de cette façon. Nous pouvons nous assurer d'avoir un lien vers
les sur les sections des modules cloud et les sections pour docker.

Le lundi 12 mars 2018 à 18h49, Brian Coca [email protected]
a écrit:

Ansible ne se soucie que des hôtes et des tâches, considérez les images que vous êtes
construire des « hôtes » et tout à coup, cela correspond aux deux paradigmes.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

D'accord, j'ai modifié le Playbook ci-dessous pour essayer un certain nombre de choses.

1er, j'ai essayé de définir le délégué_facts : Vrai au cas où cela aiderait, mais bien sûr
même sur la base de la documentation, je ne m'attendais pas vraiment à ce que cela fonctionne.
2ème j'ai mis "collecte_facts: non" et j'ai essayé d'exécuter la configuration pour réduire le fait
rassemblant à rien en espérant qu'il choisirait de ne pas se connecter du tout, mais de
bien sûr comme prévu il a quand même essayé de se connecter à la machine.
3ème Connexion de configuration essayée: localhost mais étrangement, il veut toujours
se connecter à distance à la machine pour recueillir les faits même s'il les connaît
exécutera le jeu localement, un peu ennuyeux là-bas mais je comprends la logique comme
sinon, comment connaîtra-t-il les détails de l'hôte en question sans faire
ce..

Je peux probablement utiliser le playbook pour allumer d'abord les machines, puis laisser
ansible se connecter à eux et rassembler les faits inutiles. Ce serait pour que
Je peux faire fonctionner host_vars, puis supprimer les machines. J'aimerais savoir
si quelqu'un a une meilleure solution ici car cela prend aussi beaucoup de temps
effort lorsque j'ai une centaine de machines ou plus et que je dois les alimenter
tous juste pour ensuite les supprimer.

Jusqu'à présent, je vois utiliser ceci comme solution au lieu d'un parallèle with_items
solution comme ayant du potentiel, mais les machines en question doivent encore être
up et accessible si vous avez besoin de tout type de faits de azure_rm.py pendant que vous
faites-le pour qu'il y ait au moins une mise en garde. C'est à moins que quelqu'un sache
comment accéder aux host_vars d'azur qui sont transmises via standard dans
quand rassemble_faits : non

En fait, j'ai bien sûr le même problème lorsque je lance tout cela à l'aide d'un
with_items list, mais j'espérais éviter ce travail si je suis
va utiliser à nouveau des hôtes. Le contournement consiste à vider azure_rm.py dans un
json sur la ligne de commande, puis chargé dans une variable pour obtenir
y accéder à nouveau.

Si j'attends avec impatience mon objectif final ici pour modifier des centaines voire des milliers
de composants sans serveur en parallèle, peut-être que cela ira comme je peux
utiliser des choses comme azure_rm_functionapp_facts
http://docs.ansible.com/ansible/latest/azure_rm_functionapp_facts_module.html
pour
rassembler des faits à leur sujet et les utiliser dans la pièce en théorie bien que cela
reste à tester.

Je n'ai toujours pas de grande logique sur la façon de le faire correctement pour créer un
demande d'extraction de documentation à ce sujet car la méthode semble jusqu'à présent largement
dépend de ce que vous faites et je ne suis pas sûr de vouloir suggérer d'utiliser le
json dump hack dans la documentation.

J'attends des retours de tous ceux qui s'en soucient sur
cette liste de problèmes pour décider de ma prochaine étape. En attendant, je vais utiliser mon hack pour obtenir
mon travail immédiat fait.

• hôtes : "{{ DeploymentGroup }}"
  rassemble_faits : non
  Tâches:
  
  
  
  • mettre en place:
    
    rassemble_sous-ensemble=!tout,!min
  
  
  • name : supprimer la machine virtuelle et toutes les ressources associées
    
    azure_rm_virtualmachine :
    
    resource_group : "{{ host_vars[inventory_hostname]['resource_group']
    
    }}"
    
    nom : "{{ nom_hôte_inventaire }}"
    
    état : absent
    
    délégué_à : hôte local
    
    

    délégué_facts : Vrai

  
  

Le dimanche 18 mars 2018 à 12 h 04, Isaac Egglestone <
[email protected]> a écrit :

D'accord, la désactivation de la collecte des faits résout ce problème, mais cela provoque
un autre, host_vars ne contient plus l'inventaire dynamique azur de
norme en.

Alors resource_group : "{{ host_vars[item]['resource_group'] }}"
ne fonctionne pas dans ce qui précède et doit être codé en dur dans un groupe de ressources
Nom.

Le dimanche 18 mars 2018 à 11 h 14, Isaac Egglestone <
[email protected]> a écrit :

Hrrm jusqu'à présent, j'ai créé un petit test pour delegation_to : 127.0.0.1 pour
tâches de suppression, car elles sont également pénibles à grande échelle.

Mon playbook ressemble à ceci :

• hôtes : "{{ DeploymentGroup }}"

  Tâches:

  • name : supprimer la machine virtuelle et toutes les ressources associées
    azure_rm_virtualmachine :
    resource_group : "{{ host_vars[item]['resource_group'] }}"
    nom : "{{ nom_hôte_inventaire }}"
    état : absent

  délégué_à : 127.0.0.1

Malheureusement, il essaie toujours de se connecter aux machines répertoriées dans les hôtes
pour exécuter la tâche azure azure_rm_virtualmachine.
Est-ce que je fais ça correctement ? Il me semble qu'il me manque quelque chose, mais j'ai essayé
cela auparavant de différentes manières, alors je veux juste savoir que vous êtes capable de
fais ça.

Est-ce que cela fonctionne réellement? J'espère que ce n'est qu'un problème de syntaxe.

Le lundi 12 mars 2018 à 19 h 55, Isaac Egglestone <
[email protected]> a écrit :

Ansible est un outil de gestion de configuration pour beaucoup d'autres choses,
périphériques réseaux, réels et virtuels, pour une énorme quantité de cloud
des services tels que des bases de données, des services Web tels que eleastic beanstalk, lambda
et tous les composants qui s'y appliquent comme les composants de sécurité IAM, tandis que
Ansible est bon pour les hôtes si vous exécutez toujours principalement des machines virtuelles/hôtes votre
essentiellement dans l'informatique du début des années 2000. N'offensant personne ici il y a parfois
des raisons importantes pour exécuter des machines virtuelles ou même des conteneurs Docker, mais ils sont tous
revenir à des raisons héritées. En fait, de plus en plus d'hôtes vont
devenir moins de ce qu'il automatise. IMO Si nous n'obtenons pas de parallèle
with_items, nous pourrions tout aussi bien supprimer ansible tous ensemble.

Cela dit, je vais penser positif ici et essayer d'utiliser
délégué_to pour certains services cloud, je veux dire que je n'ai jamais essayé d'exécuter sur 200+
Composants cloud dont j'ai besoin de cette façon, je suppose qu'il suffit d'interroger la liste
et videz-le dans un fichier hosts au format hosts avec ansible, puis essayez
délégué_à: localhost Je ferai part de mes résultats ici. Si ça marche à
au moins, nous pouvons faire une demande d'extraction de documentation sur la façon de contourner
with_item boucle des problèmes de série de cette façon. Nous pouvons nous assurer d'avoir un lien vers
les sur les sections des modules cloud et les sections pour docker.

Le lundi 12 mars 2018 à 18h49, Brian Coca [email protected]
a écrit:

Ansible ne se soucie que des hôtes et des tâches, considérez les images que vous êtes
construire des « hôtes » et tout à coup, cela correspond aux deux paradigmes.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

J'ai aussi un cas d'utilisation pour les fourches, ce qui rendrait cela beaucoup plus facile. Le playbook déploie un tas d'instances d'openstack via terraform avec des ips flottantes choisies au hasard. Ensuite, j'itère sur les ips pour vérifier que le port 22 est ouvert sur chaque hôte créé. La méthode actuelle pour ce faire est avec un playbook multiplay :

- 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

Ceci est exécuté avec : ansible-playbook -i localhost, deploy-test-clients.yml --extra-vars="infra=terraform_os_instances state=present"
Il s'agit bien sûr d'une solution de contournement limitée, car vous ne disposez pas toujours d'une liste d'ips parfaitement analysable dans l'inventaire avec laquelle travailler.

Étant donné que de nombreuses personnes semblent avoir du mal avec les performances des fichiers de modèles locaux, un module template_local spécifique pourrait peut-être être créé pour résoudre ce problème spécifique à la place. Au moins, ce serait un début... J'essaierais moi-même, mais je n'aurais pas le temps dans un avenir prévisible.

Plus de 30 minutes pour modéliser 100 fichiers qui peuvent être réalisés en 5 secondes avec jinja, c'est ridicule.

La création de modèles @saplla se produit toujours localement, la seule chose qui se produit à distance est la copie du modèle et la définition des autorisations.

Juste pour clarifier, je parle des utilisateurs qui souhaitent créer des modèles de fichiers en tant que tâches locales, par exemple pour alimenter d'autres systèmes de construction ou, dans mon cas, pour déployer des ressources k8s à l'aide de kubectl.

Ce que je veux dire, c'est de décharger les boucles et les modèles vers jinja via un module qui est un simple wrapper. Le module pourrait prendre un peu de contexte et la définition de la boucle (ce qui serait normalement mis dans with_nested et ses amis) et simplement couper ansible entièrement pour cette tâche (peut-être que le wrapper pourrait exécuter jinja en parallèle s'il accélère les choses) .

Il pourrait être invoqué comme ceci :

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

L'exemple ci-dessus prend toutes les variables définies par ansible comme contexte, mais n'importe quel dict peut être transmis.

Comme je l'ai dit, je n'ai pas le temps de travailler là-dessus pour le moment, mais l'approche semble-t-elle faisable @bcoca ?

Cela suppose que chaque élément est indépendant, ce qui n'est pas toujours le cas, vous pouvez faire dépendre les valeurs actuelles des éléments des précédentes et/ou des résultats des itérations précédentes, ou elles peuvent simplement être cumulatives.

La plupart du temps passé à créer des modèles concerne les vars, pas les modèles eux-mêmes, car ils doivent être cohérents, vous ne gagnerez pas beaucoup en parallélisation à moins que vous ne souhaitiez modifier des comportements qui briseraient les hypothèses actuelles.

De plus, les modèles sont déjà parallèles, par hôte, mais pas par élément.

OK merci pour les pensées. Ce serait en fait assez bon pour mon cas d'utilisation et il semble que cela pourrait l'être aussi pour d'autres personnes dans ce fil. J'utilise simplement ansible pour charger localement des configurations hiérarchiques et des fichiers de modèle avant d'invoquer un binaire qui les déploie (kubectl, helm, etc.). Je serais satisfait d'un module de modélisation simple et léger s'il était si performant qu'il réduisait les temps de création de modèles de quelques minutes à quelques secondes.

J'essaierai de regarder cela quand cela deviendra un problème pour nous, à moins que quelqu'un ne me devance.

J'ai déposé à l'origine # 10695 mais voyant que cela va prendre un certain temps, j'ai fini par traiter ces cas d'utilisation avec des scripts shell (par exemple, dites simplement que je dois faire quelque chose sur 50 repos Git sur un seul hôte, j'utilise Ansible pour exécuter un seul script une fois qui fait la chose 50 fois). Malheureusement, cela signifie abandonner certaines des choses que vous obtenez gratuitement avec Ansible, comme des rapports de modification très granulaires, et vous devez également implémenter vous-même toute la logique "exécuter uniquement si" et faire très attention à la gestion des erreurs, mais il est probablement deux ordres de grandeur plus rapide. En tant que tel, même si nous finissons par avoir une option "parallèle" à l'avenir, ce ne sera peut-être pas aussi rapide que mes scripts personnalisés et je ne prendrai probablement pas la peine d'y passer.

@wincent, une boucle parallèle sera probablement toujours plus lente qu'un script shell/programme dédié, car Ansible fait bien plus que simplement "appliquer l'action".

@bcoca : oui, ça confirme ma compréhension.

@saplla k8s_raw est mieux que d'utiliser un modèle pour cela, vous pouvez intégrer le yaml dans votre inventaire si nécessaire :) (ce n'est pas le sujet de ce PR)
quel est l'état actuel à ce sujet ? Peut-on s'attendre à quelque chose en 2.6 @bcoca ?
Je gère des milliers de privilèges postgresql sur mes clusters DB et 25 minutes, c'est terriblement lent

@nerzhul Merci mais ce n'est pas mieux pour nous. Trop de magie. Nous avons besoin de modèles.

@sapila , vous pouvez toujours créer une cible d'hôte par modèle pour paralléliser autant que possible les modèles, puis utiliser des lectures ou une délégation ultérieures pour les livrer aux hôtes réels appropriés.

@bcoca un peu hacky :)

pas du tout, c'est BEAUCOUP hacky, mais ça marche aujourd'hui

clôture en faveur de https://github.com/ansible/proposals/issues/140