For #AskAnsible posts, we interview Ansible experts on IT automation topics and ask them to share their direct experiences building automation solutions.
In this post, I’ve asked Matt Davis five questions about Ansible for Windows automation.
Matt Davis is a Senior Principal Software Engineer for Ansible, focused on Ansible's Windows support. He has over 20 years experience in software engineering, architecture and operations at companies large and small. An avid musician, maker and home hacker, Matt lives with his wife and daughter in Beaverton, Oregon. You can follow him on Twitter at @mattdavispdx.
1. How is Ansible for Windows different than System Center Configuration Manager (SCCM) or Powershell Desired State Configuration (DSC)?
Matt: SCCM is generally considered a legacy workstation-flavored management technology, dating from the mid 1990s (though many places use it for server management, too). It requires agents on the managed hosts, which must be installed, configured and kept up-to-date. SCCM executes many operations locally and asynchronously from the server, so it's often difficult to orchestrate interdependent changes across hosts, and to reason about the overall system state at any point in time as part of larger deployments.
DSC is a much more modern management technology, supporting both an agent-based "pull" architecture (the agent is built into Powershell 5+ so is generally kept up-to-date with Windows) as well as a synchronous "push" architecture, similar to Ansible (but without the great inventory and cross-platform automation concepts that Ansible provides). DSC resources are a close analogue to Ansible's modules for managing specific things in Windows -- in fact, with Ansible 2.4, you'll be able to apply DSC resource configurations from Ansible Playbooks via the win_dsc module.
Ansible, on the other hand, is a "zero footprint" automation platform that builds on the native management technologies that ship with the target system (Powershell and WinRM, in the Windows case). These management tools are kept up-to-date by simply keeping the OS patched. There is no third-party agent to deploy or maintain. When Ansible goes to manage a target Windows system, it initiates a WinRM connection, sends and executes the module code to enforce a particular state, then exits. No code is left behind on the target host, and once Ansible has disconnected, there is no additional CPU or memory overhead for having used Ansible.
2. Can I run an Ansible controller on Windows?
Matt: Not yet - we still require a "UNIX-y" host for the Ansible controller (e.g., Linux, Mac, FreeBSD). However, if you've got Windows 10, there's already a Linux environment in the box: Microsoft's new Windows Subsystem for Linux (WSL), aka "Bash on Ubuntu on Windows." It can run Ansible quite capably. While we don't officially support Ansible under WSL for production workloads (nor does Microsoft), it's a great way to develop and test Playbooks directly on your Windows host. We haven't committed to a native Windows version of the Ansible controller yet, but we're always looking at ways to make it feasible.
3. How does Ansible work with Windows domains?
Matt: In general, quite well! The various methods of WinRM domain authentication (NTLM/Kerberos/CredSSP) are supported, and we have some basic modules for managing domain membership and creating new domains from scratch (great for CI environments where you just need to stand up a quick throwaway domain to test against). In upcoming releases, we'll be expanding our support for managing domain objects, including users/groups, OUs, and other common domain-related tasks.
4. Is there anything that Ansible is not great for on Windows?
Matt: Ansible isn't always great at ongoing remote workstation management. While many folks use Ansible to set up new workstations from scratch, its "push" architecture (meaning that management sessions are initiated by a central controller) isn't always a great fit for ongoing management of state on those workstations. Servers are pretty much always connected, and easily reached by management hosts. Workstations, on the other hand, are frequently configured to "sleep", and, in the case of laptops, are often disconnected from corporate networks entirely. These factors make it difficult to perform scheduled Ansible update jobs on workstations. While we've seen some very clever niche solutions to some of these problems by dedicated Ansible users, it's just not at a point that we can really recommend it for general workstation management.
5. Is Ansible "ready for primetime" on Windows?
Matt: Absolutely! Ansible blends an easy-to-use common automation language (Playbooks) with proven management technology built by Microsoft (Powershell+WinRM) to provide an awesome systems management experience that's used daily by companies and governments, large and small. Contractual agreements often prevent us from sharing their names, but rest assured, Ansible powers the infrastructure behind a lot of names you know.
If you haven't tried out Ansible on Windows yet, it's really easy to get started in a matter of minutes. Just visit our Introduction to Windows docs page to see the steps necessary to get going.
Read more about Ansible for Windows.
Register for an upcoming Ask an Expert webinar to join an open discussion with Ansible staff.
If you have any comments or ideas for future interviews, feel free to tweet at @Ansible.