Ansible sporadische Fehler mit Windows-Computern

8

Bei der Verwendung von Windows-Hosts in meinen Ansible-Playbooks treten einige Probleme beim Ein- und Ausschalten auf. Ich verwende Ansible 2.3 mit installiertem pywinrm 0.2.2. Ich verwende die Basisauthentifizierung mit dem lokalen Administrator.

Manchmal erhalte ich dieses Problem, wenn ich eine Aufgabe ausführe:

 [WARNING]: FATAL ERROR DURING FILE TRANSFER: Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/ansible/plugins/connection/winrm.py", line 267, in _winrm_exec
  self._winrm_send_input(self.protocol, self.shell_id, command_id, data, eof=is_last)
File "/usr/local/lib/python2.7/dist-packages/ansible/plugins/connection/winrm.py", line 248, in _winrm_send_input
  protocol.send_message(xmltodict.unparse(rq))
File "/usr/local/lib/python2.7/dist-packages/winrm/protocol.py", line 207, in send_message
   return self.transport.send_message(message)
File "/usr/local/lib/python2.7/dist-packages/winrm/transport.py", line 191, in send_message
   raise WinRMTransportError('http', error_message) WinRMTransportError: (u'http', u'Bad HTTP response returned from server. Code 500')

In anderen Fällen scheint es bei temporären Dateien, die von Ansible erstellt wurden, fehlzuschlagen , wenn ich versuche, ein win_shell/win_command/raw moduleund with_itemsauf einer Gruppe von Windows-Hosts auszuführen .

Die Aufgabe, die ich ausführen möchte, ist:

- name: Check services up
  win_command: 'sc queryex {{ item }} | Findstr RUNNING'
  with_items: '{{ component_services }}'
  register: command_result
  ignore_errors: yes

Und der Fehler, den ich bekommen kann, ist:

changed: [172.16.104.169] => (item=Dnscache)
failed: [172.16.104.176] (item=Dnscache) => {"failed": true, "item": "Dnscache", 
  "module_stderr": "Exception calling \"Run\" with \"1\" argument(s): \"Exception calling \"Invoke\" with \r\n\"0\" 
     argument(s): \"The running command stopped because 
           the preference variable \r\n\"ErrorActionPreference\" 
           or common parameter is set to 
   Stop: (0) : cannot open \r\nC:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\RESB3FF.tmp 
  for writing\r\n(1) : 
     using System;\r\n\"\"\r\nAt line:45 char:1\r\n+ 
     $output = $entrypoint.Run($payload)\r\n+ 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n+ 
  CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordE \r\nxception\r\n+ 
  FullyQualifiedErrorId : ScriptMethodRuntimeException\r\n", 
  "module_stdout": "", "msg": "MODULE FAILURE", "rc": 1}
     changed: [172.16.104.141] => (item=Dnscache)
     changed: [172.16.104.168] => (item=Dnscache)
     changed: [172.16.104.145] => (item=Dnscache)

Beide Probleme sind absolut zufällig und treten möglicherweise gar nicht in einer Folge verschiedener Läufe auf.

Hilfe?

ansible windows powershell

— Asaf Haim
quelle

Wie viele Elemente, die Sie gegen diesen Host ausführen, haben fast das gleiche Problem mit zufälligen WinRM 500-Fehlern, wenn eine ansible-Schleife mit vielen Elementen auf einem bestimmten Host ausgeführt wird. Sie konnten es nicht auch herausfinden, Sie haben es in der Zwischenzeit gefunden?

— daBONDi

4 und mehr .. Ich fürchte, noch keine Lösung für mich :(

— Asaf Haim

2

Sie sollten wahrscheinlich ein Ansible-Problem dafür erstellen, da es höchstwahrscheinlich ein Fehler in Ansible ist.

Der erste Fehler lässt mich über WinRM-Pipelining nachdenken:

Ansible 2.3.0 hat eine WinRM-Pipelining-Funktion eingeführt, die immer aktiv ist (ähnlich wie SSH-Pipelining ), und die möglicherweise dahinter steckt.
SSH-Pipelining kann Probleme in Ansible für Linux verursachen, und es kann nützlich sein, es zu deaktivieren, aber dies ist für WinRM-Pipelining noch nicht möglich.

Dieses verwandte Problem enthält einige Git-Commits, die den "Nicht-Pipeline" -Modus in einer zukünftigen Version wieder aktivieren (sollte jetzt in 2.4 veröffentlicht werden, möglicherweise mit einem Backport als Teil von 2.3.2 - siehe diesen Kommentar ).

Versuchen Sie, ein Upgrade auf Ansible 2.4.1+ durchzuführen (was im Allgemeinen gut funktioniert), um das Problem zu beheben. Oder versuchen Sie ein Downgrade auf Ansible 2.2.3, um festzustellen, ob dies hilfreich ist. Dadurch wird das WinRM-Pipelining deaktiviert und andere Regressionsfehler in diesem Bereich werden möglicherweise vermieden.

Wenn Sie Ansible mit installiert haben pip, können Sie ein pip install ansible==2.4.1 Upgrade (oder ein ansible==2.2.3Downgrade) durchführen. Wenn dies nicht hilft, führen Sie dasselbe durch, 2.3.1um ein erneutes Upgrade durchzuführen.
Sie sollten auch auf die neueste Version aktualisieren, pywinrmwie in den obigen Ausgaben erwähnt

— RichVel
quelle

1

Ich habe festgestellt, dass Ansible 2.3.2 am stabilsten ist, obwohl ich noch nicht viel Zeit mit 2.4.1 verbracht habe. 2.4.0 hat definitiv einige Stabilitätsprobleme, wenn es um WinRM geht.

— Trondh
quelle