The world of IT is dark and full of terrors.
One of those terrors is the idea of a giant commercial management application that tries to manage Windows like Linux, or Linux like Windows. The threat of such applications have led men to build giant walls between their Windows and Linux departments, though often, they are still unable to keep such applications away.
These applications are often forced upon users, doing nothing well. They are mandated to be used through the powers that be, much to the consternation of both Linux and Windows teams. THOU SHALT USE CROSS PLATFORM MANAGEMENT SOFTWARE. In truth, CIOs have been beheaded for making such mandates when the tools haven't lived up to the hype.
Knowing the problems of pushing a round peg into a square hole, at Ansible, we've been focusing on Linux and Unix fundamentals of the past couple of years, and building things to serve our core users best. However, we do encounter people that have had requirements to manage both - and legitimately have heard a lot of people looking for better tools than what Windows provides stock. There was a need to play in this space.
We didn't move into this area initially not because we assumed the land of Windows was full of Grumpkins and Snarks, but because we wanted to take time to do this right. And as we always do, we sent out our scouts and spiders and gathered a ton of data - and 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.
Ultimately, Linux and Windows are very different things. Can they be well-managed through the same tool, all part of the same kingdom, while maintaining their seperate identity and values? Can we add the ansible levels of simplicity and awesomeness to Windows, in a way that's really legitimate and useful? Yes they can!
In building Windows support for Ansible, we wanted to build a management solution that manages Linux in a way that feels like Linux, and Windows in a way that feels like Windows. And both must feel like Ansible.
And because Ansible is Ansible, such a solution should manage Windows through native OS means - without installing extra agents, or even using SSHd (as is the norm on Linux but not on Windows). And it should allow people to write modules with tools that Windows users know and use, allowing them to be easily inserted into existing Windows IT teams. For Windows, this means leveraging PowerShell remoting.
PowerShell is, at times, an inconsistent language, but it's native to Windows and intensely powerful at interacting with it. By using PowerShell, we don't have to do crazy things like install Ruby or Python on a Windows system, run new system services, or things like that.
Most importantly, we wanted the full power of Ansible to be usable, so Ansible adds value beyond simply latching on to PowerShell - Ansible's parallelism, variable systems, playbooks - everything - needed to be fully usable and not a second class citizen. Thankfully Ansilbe's connection and module system were well abstracted to enable this kind fo communication.
Once we had this vision properly established in our minds, we naturally decided it needed to be a thing. Having some conversations with a small council of key engineers at Rackspace, they were looking to do similar things, and we decided it would be best if we could do this in a cross-company effort, under the auspices of the Ansible project.
Initial implementations started with some herculean efforts from talented Ansible developer Chris Church, and this week, six of us met for a sprint at Rackspace in San Antonio, Texas (aka "The Castle") to expand and flesh out our initial efforts. The team included authors of Ansible Rackspace modules like Matt Martz and Paul Durivage (also author of "su" support in Ansible*), and Windows experts Craig Ackerman and Don Schenck. I primarily worked on docs :)
The result? Initial windows support is now available on the development branch, and should be considered alpha-level but quite usable, and will evolve rapidly, with the expectation of being a beta release when Ansible 1.7 is released in a few months.
Ansible Windows modules are all written in PowerShell, and pushed out from a Linux control host using the excellent "winrm" library for Python.
Currently, capabilities include the following and are rapidly growing:
- Gathering facts from Windows machines
- Pushing and running arbitrary powershell scripts
- Writing and running Ansible modules in Powershell
- Gathering file statistics with the "win_stat" module
- Verifying connectivity with the "win_ping" module
- Downloading files with the "win_get_url" module
- Installing MSI files with the "win_msi" module
- Adding and removing Windows features with the "win_feature" module
- Creating users, deleting users, and changing user passwords with the "win_user" module
So there are some modules available already, and it's also easily expandable - and users can even run arbitrary PowerShell scripts if you don't want to convert PowerShell scripts to ansible modules. Pretty cool.
A small amount of setup is required - first to enable PowerShell remoting on the Windows clients and to upgrade to PowerShell 3.0 or higher. However, no new agents need be installed on the remote system and all remote connectivity is provided by tools already developed by Microsoft.
Best of all, Linux and Windows hosts can be managed in the same playbooks, and both feel native and Ansible-like. It's possible to talk to Linux hosts, do something on Windows hosts, and jump back to the Linux hosts. It's not just configuration management, but all kinds of general purpose IT automation you'd like to do.
Since this is all done in core Ansible, this work is all open source, and the Ansible Tower user interface and REST API will be able to take advantage of Windows support instantly and without modification - just upgrade Ansible and set the appropriate host variables.
More about this feature can be found on the Ansible Windows Docs Page
It's important to stress this is an in-progress community effort - if you'd like to hop in and contribute a module, pull requests are very welcome, and we'd also invite you to join our development mailing list to talk about plans. How awesome this becomes depends a lot on users like you and what you'd like to see done with it. There's room for quite a few more Windows modules, and we expect to have a good dozen or so when Ansible 1.7 is released. Feel free to try it out now.
Footnotes:
1) Paul made me add this note for driving me to the Apple store. Ansible always pays their debts.
Related News
Introducing AnsibleWorks! | Ansible 1.2 Released, and Ansible 1.3 Begins! | Listen To Your Servers Talk | Tower 1.4.5 (Formerly AWX) Released | Ansible Community Momentum Continues With The Hiring Of Greg DeKoenigsberg
