/starterkit-devops-ansible-playbooks

Post Windows installation playbooks for different Windows environments.

MIT LicenseMIT

starterkit-devops-ansible-playbooks

Post Windows installation playbooks for different Windows environments.

All Contributors

Built With

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.

Features

  • 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

Getting Started

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.

Prerequisites

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

Installation

Prepare the host where to run the Playbook

In both hosts the approach is the same but it uses different commands. Requirements are:

  • python3

Debian 10 WSL

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

Prepare a Windows host to apply the recipe locally from WSL

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

Structure

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

Run the playbooks

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"
}

Test the playbook(s)

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

Run the playbook(s)

Once the configuration is tested and everything works as expected, apply the configuration:

ansible-playbook -i hosts.yml localhost devops.yml

Troubleshooting and resources

Contributing

Please see our Contribution Guide to learn how to contribute.

License

MIT

(LICENSE) © 2022 ERNI - Swiss Software Engineering

Code of conduct

Please see our Code of Conduct

Stats

https://repobeats.axiom.co/api/embed/6d0c51994bd8584be9d34473b53945b99ab65e23.svg

Follow us

Twitter Follow Twitch Status YouTube Channel Views Linkedin

Contact

📧 esp-services@betterask.erni

Alberto Martín - @albertinisg - alberto.mcasado@erni-espana.es

Contributors ✨

Thanks goes to these wonderful people (emoji key):


Alberto Martín

💻 🖋 📖 🎨 🤔 🚧 ⚠️ 💡 👀

This project follows the all-contributors specification. Contributions of any kind welcome!