Ansible's windows support relies on a few standard variables to indicate the username, password, and connection type (windows) of the remote hosts. These variables are most easily set up in inventory. This is used instead of SSH-keys or passwords as normally fed into Ansible.
Ansible's windows support relies on a few standard variables to indicate the username, password, and connection type (windows) of the remote hosts. These variables are most easily set up in inventory. This is used instead of SSH-keys or passwords as normally fed into Ansible::
[windows]
winserver1.example.com
...
...
@@ -79,7 +79,7 @@ In the powershell session, run the following to enable PS Remoting and set the e
If your Windows firewall is enabled, you must also run the following command to allow firewall access to the public firewall profile:
.. code-block:: bash
.. code-block:: bash
# Windows 2012 / 2012R2
$ Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
...
...
@@ -99,12 +99,13 @@ Alternatively, a self-signed SSL certificate can be generated in powershell usin
@@ -171,10 +172,11 @@ Windows modules live in a "windows/" subfolder in the Ansible "library/" subtree
Modules (ps1 files) should start as follows::
#!powershell
# <license>
# WANT_JSON
# POWERSHELL_COMMON
# <license>
# code goes here, reading in stdin as JSON and outputting JSON
The above magic is neccessary to tell Ansible to mix in some common code and also know how to push modules out. The common code contains some nice wrappers around working with hash data structures and emitting JSON results, and possibly a few mpmore useful things. Regular Ansible has this same concept for reusing Python code - this is just the windows equivalent.