Ansible and Git Submodules

Let's discuss a problem I faced, moving from Ansible to the Ansible Tower. The problem is how to maintain multiple inventories scattered all over new projects effectively.

All my new projects are tightly coupled with the corporate GitLab server. It allows me to keep code under control and maintain multiple projects with minimal effort, except the project inventory. When each project has its own tailored copy of the inventory, the original idea works only to some extent. After the sevenths project on Git, I realized that I'm going straight to the version maintenance hell.

The slightest change in the actual configuration requires review and update of the inventories for all affected repositories. Not to mention you have to remember which one is impacted. That's how I have turned my eye toward git submodules.

In a few words, it's a reference from one git project to another one. It does not mean much for Ansible Tower, but it works well for classical Ansible and keeps all project inventories in sync. The diagram below illustrates all Ansible project artifacts and relations.

The diagram requires some explanations, so let's walk it through. Each project copy on the Ansible Controller compiles from

• Project artifacts in the GitLab repository. Usually, projects have multiple protected branches to maintain environment-specific details: domain names, vaults, inventory references, etc.
• Role references in roles/requirements.yml. It points to separate role repositories and specific branch information. Technically, all roles should be environment agnostic, but I maintain the same branches to match the project repository, mainly to simplify automation activities.
• Project inventory cloned from a git submodule. It comes with the additional .gitmodule file with the description(-s) of the path and repository you want to clone to it.
• Non-Ansible files such as - project execution script -runs Ansible playbook, after updating project roles and project/inventory artifacts from GitLab server. Environment configuration file - to use Ansible command-line tools with project-specific setup.

Now the caveat - Ansible Tower doesn't support modules. I'm okay with that because Ansible Tower inventories could be sourced from a separate project, which I already have. As for the core Ansible - git submodules significantly reduce my efforts on maintaining environment knowledge up to date. It's essential because we keep all environment knowledge in the repository.