Ansible allows structuring inventory vars and tasks in many ways. Develop your own opinions on where to put things in a logical way, based on what various Ansible plugins expect.
The lab is in a secured VLAN meaning that in order to run scripts from
remote I need to connect to the machine with their IP and not with
their FQDN and supply credentials.
False. DNS is possible for every environment. Perhaps delegate a zone hiddai.lab.example.net to a test lab DNS server, and hosts use FQDNs in this zone.
That said, ansible_host variable can be provided override host names or IP addresses for the connection plugins to use.
Do not use IP addresses that are allocated for other users. 1.1.1.1 is not yours, it is Cloudflare DNS. Use either your real IP addresses, or documentation test nets like 192.0.2.0/24 198.51.100.0/24 203.0.113.0/24.
In addition, I need to decide if my product will installed secure or
not in my lab (which protocol - HTTPS or HTTP?)
Always secure, so HTTPS. Lab setting can be more relaxed on PKI, personal simple CA, self signed certs.
Except of list of host and IP addresses in inventories ansible yaml
file, is it expectable to add variables or Keys such as:
"credentials", "protocol", "files", "machine-type", etc...
No, separate host list from the role-level application configuration data. This allows for multiple inventories. Minimal duplication of data between multiple labs, staging, and production inventories.
Limit inventory to what is needed for connecting to a host: host name, user, maybe credentials, connection plugin. Put application details somewhere else, for example group_vars.
cred:
user: a
pass: 1
Speaking of credentials, I consider a one character password unacceptably short. Don't even have it as a fake example. Ideally replace password auth with something better like key or cert based auth. Or at least long word-based passphrases, such as unluckily-pretense-occupy-quartered.
Your file paths appear to be Windows. Read Ansible's winrm documentation and consider your options for auth.
Storing creds in inventory means anyone with the inventory file can run commands. Secure the file appropriately. Consider storing creds in separate key files, or in some secret system you can access with an Ansible lookup.
Your vars file is YAML, but not in a structure Ansible's static YAML inventory plugin expects. Perhaps something like this as inventory/lab.yml I have changed some values to actual examples per internet RFCs.
---
all:
children:
windows:
# Group containing only Windows hosts allow for
# Windows-specific auth and connection variables
vars:
ansible_user: a
ansible_password: unluckily-pretense-occupy-quartered
ansible_connection: winrm
ansible_winrm_transport: credssp
children:
db:
# FQDN as inventory_hostname should resolve if in DNS
# Ansible pieces out the top label for you as special var inventory_hostname_short
hosts:
center-db.hiddai.lab.example.net:
# ansible_host overrides what to connect to
# Such as when there is no DNS
ansible_host: 203.0.113.23
children:
queue:
hosts:
center-queue.hiddai.lab.example.net:
ansible_host: 203.0.113.83
children:
app:
hosts:
center-app.hiddai.lab.example.net:
ansible_host: 203.0.113.62
children:
client:
hosts:
client-app.hiddai.lab.example.net:
ansible_host: 203.0.113.28
db: center-db
I am unclear what "center" is in this example, software product, deployment name, client name? As Ansible inventory is actually flat internally, I've collapsed that out. Add it back as a variable or group if desired.
Regarding host specific application configuration data, consider group_vars. These can be relative to your inventory file, with file name matching group name.
inventory/group_vars/windows.yml
---
base_dir: 'C:\folder\'
files_common:
- Server.msi
inventory/group_vars/app.yml
---
files_additional:
- files
- Center-Client.msi
inventory/group_vars/client.yml
---
files_additional:
- Client-Client.msi
Note I invented a couple variables for the files. Being different named, you can combine them later into one list, so {{ files_common + files_additional }}
Ideally, write and use Ansible roles, which have their own variables and tasks. Consider role default values suitable for most use cases. For example, win_package tasks to install these msi packages, and by default downloading them from an https server. But make the source package file a variable, so it can be overridden.
And the plays are what maps these host patterns to roles. I am unsure what to call your app given only generic names, so I've prefixed the roles with "thing". play.yml:
---
hosts: db
roles:
- thingdb
hosts: queue
roles:
- thingqueue
hosts: app
roles:
- thingapp
hosts: client
roles:
- thingclient
Run such a playbook with ansible-playbook play.yml -i inventory/lab.yml
Not included: the roles. I don't know what you want to accomplish, and this answer is getting a little long.
