What are we going to do?
In Part 1 Making DNS more Resilient with ansible automated etc/hosts (Part 1) | Veeam Community Resource Hub
- Setup our Ansible Controller on Ubuntu24.04
- Setup our Windows Proxy with Scripts
- Setup our Linux Proxy
In Part 2
- Setup our Ansible Inventory
- Create our centrally managed etc/hosts
- Create and verify our ansible playbook
Setup and Verify Ansible Inventory
The hard part is done. We configured our environment that we can SSH from our Ansible Controller to our Windows and Linux servers. Now let's setup our ansible inventory. Create an inventory file next to your ansible.cfg file.
[win]
vbr.srgls.lan
winproxy01.srgls.lan
[win:vars]
ansible_shell_type=cmd
[linux]
linproxy01.srgls.lan
linproxy02.srgls.lan
It is important that you specify windows variables so ansible does not try to use a linux shell on windows.
Let's check if ansible can reach these systems.
Starting with windows:
ansible win -m ansible.windows.win_ping -i inventory
Linux:
ansible linux -m ping -i inventory 
We have verified that ansible is able to ping our Windows and Linux servers. Now let's create aur hosts file and create our playbook
Hosts File
Create a template folder and within that folder a file named hosts.j2. Ansible is using jinja for templating, however we are not going to utilize jinja in depth here. Our hosts file is fairly simple and looks like this:
{# This is the template for the /etc/hosts file #}
#vbr
10.1.0.5 vbr.srgls.lan
#proxies
10.1.0.6 linproxy01.srgls.lan
10.1.0.8 linproxy02.srgls.lan
10.1.0.4 winproxy01.srgls.lan
#repositories
10.1.0.50 repo01.srgls.lan
10.1.0.51 dd01.srgls.lan
#virtual infrastructure
10.2.0.10 va01.srgls.lan
10.2.0.11 esx1.srgls.lan
10.2.0.12 esx2.srgls.lan
10.2.0.13 esx3.srgls.lan
10.2.0.14 esx4.srgls.lan
10.2.0.15 esx5.srgls.lan
Ansible Playbook
Since Ansible uses a different templating logic for windows and linux we are going to need two tasks; each one targeting only our windows and linux hosts. We are going to take a backup of the existing file in case we somehow clobbered it.
In our project directory we are creating a hosts.yml file
---
- name: Windows hosts file deployment
hosts: win
tasks:
- name: Copying to Windows hosts
ansible.windows.win_template:
src: /home/ansible/template/hosts.j2
dest: c:\Windows\System32\Drivers\etc\hosts
#create a backup of the old file
backup: true
- name: Linux hosts deployment
hosts: linux
#allow privilege elevation to modify the file
become: yes
tasks:
- name: Copying to Linux hosts
ansible.builtin.template:
src: /home/ansible/template/hosts.j2
dest: /etc/hosts
#create a backup of the old file
backup: true
For reference my directory structure looks like this:
Verify Playbook Run
We are done. Let’s see if it works.
ansible-playbook hosts.yml
Ansible is telling us it worked. Let's check some systems to see if the file was indeed changed:
On Windows we will have the .bak file including our hosts file
Opening it with notepad shows us our hosts file was correctly deployed:
Likewise, on Linux. If we ssh and cat the hosts file, we see our hosts file:
Summary
What have we learned
- It's always DNS
- How can we become less dependent on our DNS Server
- How we can centrally manage our hosts file with ansible
However, there are some possible issues with this guide
- Consider Security best practices. Following this guide will add a highly privileged user to your backup infrastructure.
- Consider only allowing specific tasks to the ansible user in the sudoers file
- Harden the ansible controller
- Etc/hosts is resolved first, make sure your configuration is correct!
- You are going to need to update etc/hosts in addition to general DNS entries whenever the environment expands or shrinks
Further Improvements
Setting up the proxies with the ansible user is a bit of a task. Thankfully Davide provided an ansible script for this also as a comment in part 1! Making DNS more resilient with ansible automated etc/hosts (Part 1) | Veeam Community Resource Hub
