This is one of the famous configuration management (Orchestration) tools in existence today. Ansible is agentless, powerful automation that enables you to deliver configurations, deployment across your IT environment. Configuration management systems are designed to make controlling large numbers of servers easy for administrator teams. They allow you to control many different systems in an automated way from one central location. Here are examples of other configuration Tools: Chef, Puppet, Salt and CFEngine, etc. See the following link. Here are some related contents: How to install Ansible on Windows, how to view installed packages in Cygwin in Windows, how to configure Kerberos for Ansible Authentication, and how to determine Cygwin version.
Cygwin is free software that provides a Unix-like environment and software toolset to users of any modern x86 32-bit and 64-bit versions of Microsoft Windows. Cygwin consists of a Unix system call emulation library, cygwin1.dll, together with a vast set of GNU and other free software applications organized into a large number of optional packages. Among these packages are high-quality compilers and other software development tools, an X11 server, a complete X11 development toolkit, GNU emacs, TeX and LaTeX, OpenSSH (client and server), and much more, including everything needed to compile and use PhysioToolkit software under MS-Windows.
Traditionally, Ansible is more focused on Linux, but with Microsoft support of Open Source and adoption lately, Windows Support for Ansible is possible. Ansible’s native Windows support uses Windows PowerShell remoting to manage Windows in the same way that Ansible manages Linux. Ansible allows the administration of Windows using local or domain users. Here is Ansible’s native Windows support; you can, out of the box.
- Gather facts on Windows hosts - Manage and install Windows updates - Fetch files from remote sites - Push and execute any PowerShell scripts you write - Install and uninstall MSIs - Enable and disable Windows Features - Start, stop, and manage Windows services - Create and manage local users and groups - Manage Windows packages via the Chocolatey package manager https://chocolatey.org/
Ansible’s easy extensibility enables you can write your own modules in PowerShell and extend Ansible for whatever other functionality you need for your environment.
Host requirements: For Ansible to manage Windows effectively, the following has to be followed.
– Windows version: Supports Windows 10, Windows Server 2016, and 2019.
– Ansible requires PowerShell 3.0 or newer and at least .NET 4.0 to be installed on the OS.
– It requires WinRM listener to be created and activated. Note: If your base image (OS images) does not meet PowerShell 3.0, this can be upgraded.
What is WinRM: Windows Remote Management (WinRM) is the Microsoft implementation of the WS-Management Protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that allows hardware and operating systems, from different vendors, to interoperate. The WS-Management protocol specification provides a common way for systems to access and exchange management information across an IT infrastructure. In other terms, WinRM is a management protocol used by Windows to remotely communicate with other servers.
Note: WinRM does everything which can be performed remotely by WMI and RPC. With this distinction that there are no proprietary RPC calls over TCP, but are handled via HTTP port 80 or 443. You can configure additional listeners, which then accept connections by default on ports 5985 HTTPS 5986. For the administration “over the Internet” exactly one port is sufficient and even via proxy server a connection is usually possible. For more information, see this link.
– When running PowerShell 3.0, ensure you pay attention to the known bug, (that limits the memory available to WinRM that result in Ansible failing to execute certain code on Windows devices) by applying the hot-fix. See link to the fix.
Setup the WinRM: When the PowerShell prerequisite is met; ensure to install the WinRM in order to allow Ansible to connect to it. The WinRM service has two components that enable Ansible to interface with Windows, the configuration settings are as follow;
– Listener and
See an example setup script to configure HTTP and HTTPS Listeners. This script as stated by Ansible uses a self-signed certificate and enables basic authentication only. Therefore it is not a good solution for production. See this link for more information.
WinRM Listener: This service listens to request on one or more ports.
Note: This one or more port can have the listener created and configured on them. This is how to view the current listeners that are running on the WinRM service, run the cmd execute the command without the quotes included. “ winrm enumerate winrm/config/Listener”. See the documentation on how to create a WinRM listener via PowerShell (ensure to provide the certificate thumbprint).
How does Ansible work?
Ansible works by configuring remote devices from a central device that has Ansible software installed. It has a simple architecture and communicates over normal SSH channels for Unix systems or WinRM for Windows systems in order to retrieve information from remote machines, to execute the automation tasks, and YAML files to define provisioning details (issue commands), etc. Ansible is idempotent, meaning changes are only infected once and when to run again, nothing changes. Ansible uses the declarative statement
Ansible Architecture: See this link for more information
– Inventory file: This is simply a list of hosts (targets)
– Playbooks: Commands that describes the desired actions (plain text YAML files)
YAML means Yet Another Markup Language.
- Playbook contains plays
- Plays contain tasks
- Tasks call Modules
– Tasks run sequentially as configured and defined
– Handlers are triggered by tasks and run once at the end of each play
– Uses WinRM for communication( installed by default in Windows System)
– Modules: This controls system resources, packages, etc. they are automating.
– Variables: Helps alter how the playbook runs and can be used anywhere in the playbook. See this link and link2 for more information.
Advanced playbooks capabilities
– Ansible Roles: These are unique kinds of playbooks that are fully self-contained with tasks, variables, configuration templates, and other supporting files. To run a playbook, run the command below.
$ansible-playbook –I inventory playbook.yml
Ansible Installation on Windows OS: Installing Ansible generally is pretty straight forward but on windows, it is a little bit complicated. If you wish to install Ansible on Windows, follow these steps here “how to install Ansible on Windows with Cygwin“.
– Note: On the control node needs to have Ansible installed.
- When updates are already applied (Target stage changed) and Ansible is run, Ansible will report that these updates have been applied already (i.e., no state changes made and target system is in the desired state).
I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.