Post Windows installation playbooks for different Windows environments.
The main tools this repository will use are:
- Ansible, a tool that connects to the Windows machines using winRM protocol
- WSL, as Ansible just works in Unix machines
- Chocolatey, a Windows package manager.
- Ansible is a tool that manages the configuration of any host/server. It also handles states, so once a machine is configured using Ansible, any software and/or configuration MUST BE done through the playbook process (even configuration and/or application removal). This allows to have every transaction in the git repository, and avoids configuration drifts.
- Will speed-up the ramp-up role for your project
In the following section you will find out how to setup your enviroment so that later on you are able to clone this repository and run your playbooks.
Ansible works also under Windows Subsystem for Linux (WSL). Follow this guide to install it in Windows 10: https://docs.microsoft.com/en-us/windows/wsl/install-win10
In both hosts the approach is the same but it uses different commands. Requirements are:
- python3
Install python 3 and pip (python package manager) if not existing:
sudo apt-get update
sudo apt-get install python3 python3-pip -y
Start installing all the packages needed for running ansible against the windows hosts. You will need to install:
- ansible
- pywinrm
- pywinrm[credssp]
pip3 install ansible
pip3 install pywinrm
pip3 install pywinrm[credssp]
Make sure Ansible is installed by running:
ansible --version
To enable your Windows environment to be configured locally by using Ansible from WSL, you will need to follow the next steps:
# Configure Remoting for Ansible
iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1'))
# Enable WsMan
Enable-WSManCredSSP -Role Server -Force
After that, you should be able to connect from your WSL by using localhost
The playbooks are organized as follows:
├── roles
│ ├── packages
│ │ ├── defaults
│ │ │ └── main.yml
│ │ ├── files
│ │ ├── handlers
│ │ │ └── main.yml
│ │ ├── meta
│ │ │ └── main.yml
│ │ ├── README.md
│ │ ├── tasks
│ │ │ └── main.yml
│ │ ├── templates
│ │ ├── tests
│ │ │ ├── inventory
│ │ │ └── test.yml
│ │ └── vars
│ │ └── main.yml
│ ├── folders
│ ├── users_management
│ └── env_vars
├── devops.yml
├── hosts.yml
└── README.md
There is 1 main folder, and sub-groups inside it:
roles: where tasks and variables related to the group of tasks are defined.
Inside of each role folder, there is a subset of folders for the following purposes:
tasks: Contains the tasks which do the actual work.handlers: Contains handlers, which, when notified, trigger actions.defaults: Role specific variables, which have a default, but are intended to get overridden from the role user (a play in a playbook).vars: Role specific variables, which are not intended to get overridden.templates: The default directory for jinja2 templated files. The template module searches in that directory.files: The default directory for static files used by the copy module.meta: Meta information for this role. This is the place where you can define dependencies to other roles, for example.tests: Contains everything necessary to test this role in isolation. I haven’t yet used this like I should. I’m going to explore this in another post later.
Finally, there are main files grouping roles by type. Those files are:
devops.yml: groups the roles needed to be applied in the configuration for a DevOps role
Now that the setup is done in both sides, let's check that the desired host(s) can be reached to be configured.
First thing to do is set the credentials at hosts file. You need to set ansible_user and ansible_password at the <machine>:vars. Done that, run the following:
ansible -i hosts.yml locahost -m win_ping
This should return the following:
<machine_ip> | SUCCESS => {
"changed": false,
"invocation": {
"module_args": {
"data": "pong"
}
},
"ping": "pong"
}
At this point, we have to Run the whole playbook(s) in dry-run mode. It is MANDATORY to run this command prior to applying any change in the server, to avoid configuration drifts and/or issues. This command runs the playbook in "simulation mode", and returns the result without applying any change.
IMPORTANT Since now on we have encrypted variables in the repo, we need to run all the playbooks with the flag
--ask-vault-pass.
ansible-playbook -i hosts.yml localhost devops.yml --check
Once the configuration is tested and everything works as expected, apply the configuration:
ansible-playbook -i hosts.yml localhost devops.yml
- Ansible Windows remote management guide
- Understanding and troubleshooting WinRM connection and authentication: a thrill seeker's guide to adventure --> HIGHLY RECOMMENDED
- setting-up-wsl-ansible-to-control-windows-host
- Configure your dev Windows machine with Ansible
- Ansible playbook: Post Windows installation
- win_feature – Installs and uninstalls Windows Features on Windows Server
- win_chocolatey – Manage packages using chocolatey
- Desired State Configuration
- Windows Modules
- win_optional_feature – Manage optional Windows features
- Best Practices
Please see our Contribution Guide to learn how to contribute.
(LICENSE) © 2022 ERNI - Swiss Software Engineering
Please see our Code of Conduct
Alberto Martín - @albertinisg - alberto.mcasado@erni-espana.es
Thanks goes to these wonderful people (emoji key):
 Alberto Martín 💻 🖋 📖 🎨 🤔 🚧 |
This project follows the all-contributors specification. Contributions of any kind welcome!