This is one of the famous configuration management (Orchestration) tools in existence today. Ansible is an 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’s 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 - CFEngine etc.
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 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 http://www.winfaq.de/faq_html/Content/tip2000/onlinefaq.php?h=tip2495.htm
Note: 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 https://github.com/jborean93/ansible-windows/blob/master/scripts/Install-WMF3Hotfix.ps1
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 a production https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
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 documentation on how to create WinRM listener via PowerShell (ensure to provide the certificate thumbprint). https://docs.ansible.com/ansible/latest/user_guide/windows_setup.html#configuring-ansible-for-ssh-on-windows
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 are idempotent, meaning changes are only infected once and when run again, nothing changes.
– Ansible uses the declarative statement
Ansible Architecture https://www.youtube.com/watch?v=MfoAb50Br94
– Inventory file: This is simply 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 plays
– Uses WinRM for communication( installed by default in Windows System)
– Modules: This controls system resources, packages etc. they we are automating.
– Variables: Helps alter how playbook runs and can be used anywhere in the playbook. See moe here https://www.youtube.com/watch?v=BeYUQaFS-vg
Advanced playbooks capabilities
– Ansible Roles: These are unique kind of playbooks that are fully self-contained with tasks, variables, configuration template and other supporting files
- To run a playbook
$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
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).