Ansible is adding support for Windows, using PowerShell as the underlying technology. Ansible 1.7, which should be released in a few weeks time, will feature Windows integration in "beta" status. InfoQ talked with Michael DeHaan, Ansible's creator, to know more about this development.
Keeping in line with Ansible's philosophy of using native OS features to manage them, PowerShell and Windows Remote Management (WinRM) are the underlying technologies that Ansible will use to manage Windows. Both are natively available on the most recent versions of Windows and can be installed on earlier versions. WinRM is somewhat equivalent to SSH, allowing Ansible to maintain its agentless approach. All the Ansible's Windows modules are written in PowerShell, to "allow people to write modules with tools that Windows users know and use".
There are already a number of modules that target Windows, whose names starts with "win". These modules offer basic capabilities, such as executing arbitrary PowerShell scripts, installing MSI's and Windows features, or managing users. There are also some existing modules that support Windows, such as slurp, raw or setup.
Ansible tries to make Linux and Windows management as seamless as possible. The same Ansible playbook can have steps that configure Linux machines and other steps that manage Windows boxes.
Despite the new Windows support, Ansible will still need a Linux control machine, as stated in the documentation:
Running Ansible from a Windows control machine is NOT a goal of the project. Refrain from asking for this feature, as it limits what technologies, features, and code we can use in the main project in the future. A Linux control machine will be required to manage Windows hosts.
On the installation front, besides the need for a Linux control machine, there are some other hurdles to surpass, such as the remote execution policy, firewall configurations or HTTPS listeners for PowerShell remoting, if additional security is needed. On the flip side, those hurdles are common to any scenario that uses PowerShell and WinRM.
Windows support "should be considered alpha-level but quite usable", with the code still living in the development branch. Asked about the release date for Ansible 1.7, Michael replied:
There is no date set in this time, but we expect it will be in about a month. This will include the Windows release being in 'beta' status, with we'd expect a reasonable amount of new modules, and also a script that makes the setup process even easier.
InfoQ: It seems you opted not to use PowerShell Desired State Configuration (DSC), altough that's the recommended route by Microsoft. Why not DSC?
Michael: We're actually pretty open to supporting DSC, but various things Ansible gets used for are in the "orchestration" and "task workflow" kind of spaces. Cases where you want to "do X now", rather than just "apply this policy". DSC right now is about applying a specific policy via a MOF file, but doesn't fit into some of those ad hoc management cases.
As such, we're supporting Powershell, which many admins know, and will probably have a module for applying a dsc configuration as well.
The important thing to remember though is that Ansible is designed to make concepts more accessible, so you should be able to use Ansible and it's windows modules without having to learn too much around DSC.
We're talking quite frequently with various folks at Microsoft and the ability to use DSC for more stepwise tasks may be something DSC can do in the future, in which case, using it as an implementation layer might make more sense.
InfoQ: What are the main differences between the Linux/Unix world and the Windows world when it comes to IT Automation and Configuration Management?
Michael: One popular phrase is "Would you buy a car with the hood welded shut", but that's not exactly fair to Linux. It should rather be that Linux is essentially a framework for doing whatever you want, and as a result, it has created an entire ecosystem of tools to wrangle it (like Ansible). Windows is a bit more homogenous, but it also has less flexibility - in general, there's one logical way to do most anything, rather than 50 options with different properties.
Things get interesting of course when you want to manage both in the same environment. I want Windows to feel like Windows, and Linux to feel like Linux, but Ansible to still not feel wrongly applied in either case.
InfoQ: You stated that PowerShell is inconsistent at times. What are the main inconsistencies you find?
Michael: Just little things like casing or how it uses hyphens and little things, how it treats hashes versus a programming language that's used to them. Powershell is quite capable, and the great thing is a lot of admins in the windows world already know.
The cool thing is an Ansible user won't need to know powershell, it's just how the modules are written. However, if users want to write powershell modules or even just push powershell scripts with the win_script module, that's good too.
InfoQ: When announcing this development, you mentioned that you "talked to a ton of users who had experience with a lot of automation platforms that were trying to be cross platform and not delivering". Do these platforms have any weaknesses in common with each other? How are you avoiding that trap?
Michael: Using native powershell remoting is one of those things. Not having to install any special software and just being able to use native Microsoft solutions means we can continue to keep Ansible from having to maintain it's own agents. We're just using the Windows remoting feature Microsoft already wrote, which makes this very accessible to all Windows admins - it's not doing anything special or unusual, it's just using features in the OS.
To us, I want to not treat Windows like an unusual customer, we are really treating it like another OS in ansible, and not trying to force Linux abstractions and the ways of doing things upon it.
Writing modules in powershell instead of Python is also one of those things, so Windows admins have full access to anything they want to do, because of that powerful standard library already provided by Microsoft.
Michael also urged the community to contribute: "Many users are contributing things and if folks are interested in expanding support, stop by the ansible-development mailing list and say hi!"