Introduction

An inventory is in most cases a collection of variables that when brought together, describe an environment where a server with specific specs will be deployed. These servers defined in this inventory are all managed by Ansible Automation Platform.

As the inventory grows and the number of systems increases, the chances of someone making an error also increases.
This is one of the callenges of central management, keeping this organized and secure.
Sharing all variables with all teams in AAP is probably not the best or most secure option, this is where constructed inventories can help.
Be aware that there are a lot of other options, this is but one and might not be the best fr your organization.

In the description below we describe a possible solution to reduce complexity for teams working is AAP and still leaving the resposibilities where they belong.

This is possible by splitting the inventory in (from a team view) 2 parts, each team has its own inventory specific part, in which they have full rights to change anything.
There is also the base corporate part, controlled by the automation management team, that holds all company wide(global) variables.

Global (automation part)

This part of the inventory holds all variables needed to deploy machines or devices, except the machines the teams control themselves. All infrastructural variables are already defined in the correct groups, so these can be easily used.

This inventory is stored in a git repository,that will be loaded into AAP as a project sourced inventory.

Below the ppossible structure of the base inventory:

── group_vars
│   ├── all
│   │   ├── env.yml
│   │   └── satellite.yml
│   ├── dev.yml
│   ├── test_env.yml
│   ├── org_1.yml
│   ├── org_2.yml
│   └── vmware.yml
├── inventory.yml
└── host_vars
    ├── controller.localdomain.yml
    ├── gitlab.localdomain.yml
    ├── automationhub.localdomain.yml
    ├── reposerver.localdomain.yml
    ├── nameserver.localdomain.yml
    ├── satellite.localdomain.yml
    ├── virtserver.localdomain.yml
    └── gitrunner.localdomain.yml

As previously stated, this is only the deployment environment definition.
The hosts defined in here, are just the hosts that define a environment to deploy a host in.

How can this be used for a team?

Team part

Each team wil have a separate repository in which thier part of the inventory is stored, they are in full controll of this part of the inventory.
The structure of this inventory is this:

├── inventory.yml
├── group_vars
└── host_vars
    ├── host1.localdomain.yml
    └── host2.localdomain.yml

In this structure, the team can create new group_vars files to contain their own group variables and host_vars files to define new hosts to be deployed. There are a few rules all teams must obide to: - Hostnames must be unique - Group_vars files must be unique (prefix the filename with your teamname)

The inventory.yml wil look like this:

org_1:
  hosts:
    host1.localdomain.yml
    host2.localdomain.yml

In case of some extra groups:

org_1:
  children:
    org_1_group1:
      hosts:
        host1.localdomain.yml
        host2.localdomain.yml

this way extra variables can be defined in the file group_vars/org_1_group1.yml and automaticly loaded from the inventory.

How do we add these

Option 1 By defining an inventory for each team that uses 2 inventory sources: - 1 the base inventory - 2 the own inventory of the team using an inventory file "org_1.yml" (rename inventory.yml to org_1.yml)

This wil not create a functioning inventory, to make this work, in the base inventory, the inventory yml must be adapted for each new team that is added:

dev:
  children:
    org_1:
    org_2:
    test_env:
      hosts:
        git.example.com
        vcenter.example.com
...

The number of layers in this inventory is kept low for clarity reasons.
Adding more organizations is simply add a new group entry into the children for the environment in inventory.yml.

Pros and cons

A split inventory has some pros and cons, below youll find a few:

Pros: - a team has only a view of the enviroment part that theyare responsible for.

Cons: - In case of an update to the base inventory, all combined invntories is AAP need to be refreshed, this is added overhead. - updates are not implemented by default in a static inventory.
- For system patching a full inventory is needed to be able to patch all systems.

Option 2 In AAP 2.4 and up there is a new inventory type is added, the constructed inventory.
This requires both inventories must be created separately and combined through a "contructed" inventory.
This way all variables are availlable to jobs.

Back

Backto Site