improve guideline dynamic inventory

---

categories: ["Guideline"]

tags: ["dynamic-inventory", "ansible-inventory"]

title: "Use Dynamic Inventory in Development"

title: "Simulate Dynamic Inventory in Development"

linkTitle: "Dynamic Inventory in Dev"

weight: 2

translate: false

coauthor:

  context:

    - rellink: /docs/guidelines/dev/dynamic-inventory/diagram

    - rellink: /docs/guidelines/dev/dynamic-inventory/table

    - rellink: /docs/guidelines/dev/dynamic-inventory/plugin

    # - rellink: /docs/guidelines/dev/dynamic-inventory/diagram

    # - rellink: /docs/guidelines/dev/dynamic-inventory/table

    # - rellink: /docs/guidelines/dev/dynamic-inventory/plugin

#     - url: https://gitlab.com/c2platform/phx/ansible/-/raw/master/plugins/inventory/vagrant.py?ref_type=heads

#     - url: https://gitlab.com/c2platform/phx/ansible/-/raw/master/Vagrantfile.yml?ref_type=heads

description: >

  Guideline for using [dynamic inventory](g) in Ansible development environments

  as a concrete example to illustrate future full automation for organizations

  new to Ansible.

  Guideline for using an *inventory plugin* in [Ansible](g) development

  environments as a concrete example to illustrate future full automation for

  organizations new to Ansible.

---

Projects:

{{< ansible_inventory_link "/docs/gitlab/c2platform/phx/ansible" "gitlab" "false" "true" >}}

{{< alert >}}

Adopt [dynamic inventory](g) in [development environments](g) to create a

concrete, working example that demonstrates how full automation will work in the

future, once all provisioning aspects are automated without manual steps. This

also optimizes the development setup as a secondary benefit.

Adopt an *inventory plugin* in [development environments](g) to simulate

how [dynamic inventory](g) works. This creates a concrete, working example that

demonstrates how full automation will function in the future, once all

provisioning aspects are automated without manual steps. As a secondary

benefit, this also optimizes the development setup.

{{< /alert >}}

## Problem

For organizations new to automation, [dynamic inventory](g) may offer limited

immediate value, as manual steps often need automation first.

Unfamiliarity with Ansible and inventory mechanics, like [precedence](g) rules,

can lead to suboptimal solutions. For instance, teams might automate adding

servers to the [inventory project](g) to ease tasks for

[Ansible operators](g).

This approach has two issues:

1. Managing the inventory file with Ansible groups and nodes is not overly

   complex, and the [Ansible operator](g) requires a thorough understanding of

   it regardless, as it forms the foundation of effective automation.

2. Automating this "complexity" is naturally resolved when adopting

   *dynamic inventory*.

For organizations new to automation, dynamic inventory may offer limited

immediate value, as manual steps often need automation first. Unfamiliarity with

Ansible and inventory mechanics, like [precedence](g) rules, can lead to

suboptimal solutions[^phx].

## Context

In Dutch government organizations starting with automation, familiarity with

Ansible is often limited, let alone with concepts like *dynamic inventory*. This

Ansible is often limited, let alone with concepts like dynamic inventory. This

is the primary context.

*Dynamic inventory* represents a future milestone. In a mature professional

Dynamic inventory represents a future milestone. In a mature professional

environment, a request in tools like vRA for a server or full environment

(multiple servers) could suffice. An *Ansible operator* would only need the

vRA portal to provision. The vRA setup applies labels that a *dynamic inventory*

(multiple servers) could suffice. An [Ansible operator](g) would only need the

vRA portal to provision. The vRA setup applies labels that a dynamic inventory

plugin uses for complete provisioning, without altering the

[inventory project](g).

## Solution

Start with *dynamic inventory* in the [development environment](g), where it

is simple to implement. Use this working example to explain and illustrate

benefits to organizations new to Ansible, showing how it enables fully automated

provisioning without manual steps. This demonstrates future scalability and

Start in the [development environment](g) with the [Vagrant inventory plugin](g)

for [Vagrant](g). This plugin is not dynamic inventory in the traditional

sense—it does not query an external cloud API or database. Instead, it reads the

`Vagrantfile.yml` YAML file from the C2 Platform and generates an inventory that

Ansible can use. In doing so, it simulates how dynamic inventory works: it

demonstrates how inventory can be generated from a data source rather than being

manually maintained.

Use this working example to explain and illustrate the benefits of dynamic

inventory to organizations new to Ansible. It shows how fully automated

provisioning works without manual steps, demonstrates future scalability, and

simplifies inventory management as automation matures.

### Benefits

### Example in Development

The [inventory plugin](g) for [Vagrant](g) illustrates how the vRA example would

work. It operates on the same fundamental principles, providing a concrete

example of how labels in the virtualization technology—vRA in production-like

domains or *Vagrant* in development—are used with a plugin to dynamically

generate host information and define [Ansible groups](g).

The *inventory plugin* for Vagrant illustrates how the vRA example would work.

It operates on the same fundamental principles, providing a concrete example

of how labels in the virtualization technology—vRA in production-like domains

or Vagrant in development—are used with a plugin to dynamically generate host

information and define [Ansible groups](g).

#### Inventory Plugin for Vagrant

The `Vagrantfile.yml` defines the `pxd-s3` node using the `ubuntu22-lxd` box,

assigns IP `192.168.60.14`, and specifies the [playbook](g) `mgmt/s3` for

provisioning. *Vagrant* uses this to create and configure the node.

provisioning. Vagrant uses this to create and configure the node.

{{% code

  project="/docs/gitlab/c2platform/phx/ansible"

  hash="931d5aba8b69189c367abc106cc4455d751c8b4aaab950fe8e5c29d81247b18d"

%}}

The *dynamic inventory* plugin assigns this node to the *Ansible groups*

`s3` and `s3_download_server` based on its labels. In this test setup, `pxd-s3`

The *inventory plugin* assigns this node to the Ansible groups `s3`

and `s3_download_server` based on its labels. In this test setup, `pxd-s3`

belongs to both groups, serving as both the S3 server and the test client. In

production-like scenarios, these roles would be separated.

#### Group Membership Example

This section demonstrates how *Ansible groups* are dynamically assigned to a

node using the *dynamic inventory* plugin and static definitions.

This section demonstrates how Ansible groups are dynamically assigned to a

node using the *inventory plugin* and static definitions.

Let's take the node `pxd-s3` as an example. Using the `debug` module, we can

query the `group_names` for `pxd-s3`. See below.

}

```

The *Ansible groups* are derived as follows:

The Ansible groups are derived as follows:

1. `lxd`, `ubuntu`, and `ubuntu22` originate from the definition of the

   [Vagrant box](g) `ubuntu22-lxd` in `Vagrantfile.yml`.

- For more information about the `pxd-s3` node:

  {{< rellink path="/docs/howto/phx/s3" >}}

- {{< rellink path="/docs/concepts/ansible/projects/inventory" desc=true >}}

[^phx]: In the context of the PHX project, a suboptimal solution was explored

  where the idea arose to automate the addition of servers to the static

  `hosts.ini` file in the correct [Ansible groups](g) to simplify the work of

  the [Ansible operator](g). At the time, the project used a traditional static

  [inventory file](g) rather than dynamic inventory, even though it also used

  vRA for provisioning. This approach is suboptimal for two reasons. First,

  managing the *inventory file* with Ansible groups and nodes is not overly

  complex, and the *Ansible operator* requires a thorough understanding of it

  regardless, as it forms the foundation of effective automation. Second, it

  would be more logical to create Ansible groups based on tags or labels in vRA

  and derive the inventory information from there—a challenge that is naturally

  resolved when adopting dynamic inventory, rather than automating updates to a

  static file.

---

title: Inventory Plugin for Vagrant

linktitle: Inventory Plugin

title: Vagrant Inventory Plugin

linktitle: Vagrant Plugin

categories: [Example]

tags: [Dynamic-Inventory]

translate: false

description: >-

  Example of a dynamic inventory plugin for Vagrant in the PHX reference

  implementation, demonstrating automated inventory generation from local

  development configurations.

coauthor:

  context:

    - rellink: /docs/guidelines/dev/dynamic-inventory

  Example of a custom inventory plugin for Vagrant in the PHX reference

  implementation. The plugin illustrates building inventory, and its use

  in the development environment simulates dynamic inventory using a static

  Vagrantfile.yml.

translate: false

toc_hide: true

hide_summary: true

The PHX [reference implementation](g)

{{< ansible_inventory_link "/docs/gitlab/c2platform/phx/ansible" "gitlab" "false" "true" >}}

contains an example of a plugin for [dynamic inventory](g). The plugin

`plugins/inventory/vagrant.py` reads `Vagrantfile.yml` to dynamically generate

the inventory. It adds hosts, sets variables like IP addresses, and assigns

groups based on prefixes, labels, and additional INI files. It can also export

the generated inventory to an INI file for debugging or integration.

contains an example of a custom inventory plugin.

The plugin `plugins/inventory/vagrant.py` reads `Vagrantfile.yml` to generate

the inventory.

It adds hosts, sets variables such as IP addresses, and assigns groups based

on prefixes, labels, and additional INI files.

It can also export the generated inventory to an INI file for debugging or

integration.

{{% code project="/docs/gitlab/c2platform/phx/ansible"

   file="plugins/inventory/vagrant.py"

   hash="db48fceac5a372c291e7fba25f1f5e1fc0022ee4b3b320368ae3ed3a45af3d58" %}}

The Vagrant inventory plugin is an Ansible inventory plugin used for the

development environment.

The purpose of this plugin is twofold.

First, it provides a single source of truth for both Vagrant and Ansible

during development.

This eliminates the need to duplicate information—such as IP addresses—across

Vagrant and Ansible configurations.

Second, it illustrates how inventory can be built for Ansible using a custom

module or plugin.

Its application in the development environment simulates

[dynamic inventory](g).

Many government organizations struggle with the concept of dynamic inventory.

This plugin serves as a practical example of a custom inventory plugin.

---

categories: ["Richtlijn"]

tags: ["dynamic-inventory", "ansible-inventory"]

title: "Gebruik dynamische inventaris in ontwikkeling"

title: "Dynamische inventaris simuleren in ontwikkeling"

linkTitle: "Dynamische inventaris in dev"

weight: 2

coauthor:

  context:

    - rellink: /docs/guidelines/dev/dynamic-inventory/diagram

    - rellink: /docs/guidelines/dev/dynamic-inventory/table

    - rellink: /docs/guidelines/dev/dynamic-inventory/plugin

    # - rellink: /docs/guidelines/dev/dynamic-inventory/diagram

    # - rellink: /docs/guidelines/dev/dynamic-inventory/table

    # - rellink: /docs/guidelines/dev/dynamic-inventory/plugin

#     - url: https://gitlab.com/c2platform/phx/ansible/-/raw/master/plugins/inventory/vagrant.py?ref_type=heads

#     - url: https://gitlab.com/c2platform/phx/ansible/-/raw/master/Vagrantfile.yml?ref_type=heads

description: >

  Richtlijn voor het gebruik van [dynamische inventaris](g) in Ansible-ontwikkelomgevingen

  als concreet voorbeeld om toekomstige volledige automatisering te illustreren voor organisaties

  die nieuw zijn met Ansible.

  Richtlijn voor het gebruik van een *inventaris-plugin* in [Ansible](g)-ontwikkelomgevingen

  als concreet voorbeeld om toekomstige volledige automatisering te illustreren voor

  organisaties die nieuw zijn met Ansible.

---

Projects:

{{< ansible_inventory_link "/docs/gitlab/c2platform/phx/ansible" "gitlab" "false" "true" >}}

{{< alert >}}

Neem [dynamische inventaris](g) over in [ontwikkelomgevingen](g) om een

concreet, werkend voorbeeld te creëren dat demonstreert hoe volledige automatisering in de

toekomst zal werken, zodra alle provisioning-aspecten zijn geautomatiseerd zonder handmatige stappen. Dit

optimaliseert ook de ontwikkelopzet als secundair voordeel.

Neem een *inventaris-plugin* op in [ontwikkelomgevingen](g) om te simuleren hoe

[dynamische inventaris](g) werkt. Dit creëert een concreet, werkend voorbeeld dat

demonstreert hoe volledige automatisering in de toekomst zal functioneren, zodra alle

provisioning-aspecten zijn geautomatiseerd zonder handmatige stappen. Als secundair

voordeel optimaliseert dit ook de ontwikkelopzet.

{{< /alert >}}

## Problem

Voor organisaties die nieuw zijn met automatisering, biedt [dynamische inventaris](g) mogelijk beperkte

directe waarde, omdat handmatige stappen vaak eerst moeten worden geautomatiseerd.

Onbekendheid met Ansible en de werking van inventarissen, zoals regels voor [variable precedence rules](g),

kan leiden tot suboptimale oplossingen. Teams kunnen bijvoorbeeld het toevoegen van servers aan het

[inventarisproject](g) automatiseren om taken voor [Ansible operators](g) te vereenvoudigen.

Deze aanpak heeft twee problemen:

1. Het beheren van het inventarisbestand met Ansible-groepen en nodes is niet overdreven complex, en de

   [Ansible operator](g) moet een grondig begrip ervan hebben, ongeacht, omdat het de basis vormt van

   effectieve automatisering.

2. Het automatiseren van deze "complexiteit" wordt natuurlijk opgelost bij het adopteren van

   *dynamische inventaris*.

Voor organisaties die nieuw zijn met automatisering biedt dynamische inventaris mogelijk beperkte

directe waarde, omdat handmatige stappen vaak eerst moeten worden geautomatiseerd. Onbekendheid met

Ansible en inventarismechanieken, zoals [precedence](g)-regels, kan leiden tot suboptimale oplossingen[^phx].

## Context

In Nederlandse overheidsorganisaties die beginnen met automatisering, is de vertrouwdheid met

Ansible vaak beperkt, laat staan met concepten zoals *dynamische inventaris*. Dit is de primaire context.

In Nederlandse overheidsorganisaties die beginnen met automatisering is de vertrouwdheid met

Ansible vaak beperkt, laat staan met concepten zoals dynamische inventaris. Dit is de primaire context.

*Dynamische inventaris* vertegenwoordigt een toekomstige mijlpaal. In een volwassen professionele

Dynamische inventaris vertegenwoordigt een toekomstige mijlpaal. In een volwassen professionele

omgeving kan een aanvraag in tools zoals vRA voor een server of volledige omgeving

(meerdere servers) voldoende zijn. Een *Ansible operator* zou alleen het

vRA-portal nodig hebben om te provisionen. De vRA-opzet past labels toe die een *dynamische inventaris*-plugin

(meerdere servers) voldoende zijn. Een [Ansible operator](g) zou alleen het

vRA-portal nodig hebben om te provisionen. De vRA-opzet past labels toe die een dynamische inventaris-plugin

gebruikt voor volledige provisioning, zonder het [inventarisproject](g) aan te passen.

## Solution

Begin met *dynamische inventaris* in de [ontwikkelomgeving](g), waar dit

eenvoudig te implementeren is. Gebruik dit werkende voorbeeld om voordelen uit te leggen en te illustreren aan

organisaties die nieuw zijn met Ansible, en toon hoe het volledig geautomatiseerde

provisioning mogelijk maakt zonder handmatige stappen. Dit demonstreert toekomstige schaalbaarheid en

Begin in de [ontwikkelomgeving](g) met de [Vagrant-inventaris-plugin](g) voor

[Vagrant](g). Deze plugin is geen dynamische inventaris in de traditionele zin — het bevraagt geen externe cloud-API of database. In plaats daarvan leest het het YAML-bestand `Vagrantfile.yml` van het C2 Platform en genereert het een inventaris die Ansible kan gebruiken. Hiermee simuleert het hoe dynamische inventaris werkt: het toont hoe een inventaris kan worden gegenereerd vanuit een gegevensbron in plaats van handmatig te worden onderhouden.

Gebruik dit werkende voorbeeld om de voordelen van dynamische inventaris uit te leggen en te illustreren aan

organisaties die nieuw zijn met Ansible. Het laat zien hoe volledig geautomatiseerde

provisioning werkt zonder handmatige stappen, demonstreert toekomstige schaalbaarheid en

vereenvoudigt het beheer van inventarissen naarmate de automatisering volwassener wordt.

### Benefits

### Example in Development

De [inventaris-plugin](g) voor [Vagrant](g) illustreert hoe het vRA-voorbeeld zou

De *inventaris-plugin* voor Vagrant illustreert hoe het vRA-voorbeeld zou

werken. Het werkt op dezelfde fundamentele principes en biedt een concreet

voorbeeld van hoe labels in de virtualisatietechnologie — vRA in productie-achtige

domeinen of *Vagrant* in ontwikkeling—worden gebruikt met een plugin om dynamisch

domeinen of Vagrant in ontwikkeling — worden gebruikt met een plugin om dynamisch

hostinformatie te genereren en [Ansible-groepen](g) te definiëren.

#### Inventory Plugin for Vagrant

#### Vagrantfile.yml

De `Vagrantfile.yml` definieert de `pxd-s3`-node met behulp van de `ubuntu22-lxd` box,

De `Vagrantfile.yml` definieert de `pxd-s3`-node met behulp van de `ubuntu22-lxd`-box,

wijst IP `192.168.60.14` toe en specificeert de [playbook](g) `mgmt/s3` voor

provisioning. *Vagrant* gebruikt dit om de node te creëren en te configureren.

provisioning. Vagrant gebruikt dit om de node te creëren en te configureren.

{{% code

  project="/docs/gitlab/c2platform/phx/ansible"

  hash="931d5aba8b69189c367abc106cc4455d751c8b4aaab950fe8e5c29d81247b18d"

%}}

De *dynamische inventaris*-plugin wijst deze node toe aan de *Ansible-groepen*

`s3` en `s3_download_server` op basis van de labels. In deze testopzet behoort `pxd-s3`

De *inventaris-plugin* wijst deze node toe aan de Ansible-groepen `s3`

en `s3_download_server` op basis van de labels. In deze testopzet behoort `pxd-s3`

tot beide groepen en dient als zowel de S3-server als de testclient. In

productie-achtige scenario's zouden deze rollen worden gescheiden.

#### Group Membership Example

Deze sectie demonstreert hoe *Ansible-groepen* dynamisch worden toegewezen aan een

node met behulp van de *dynamische inventaris*-plugin en statische definities.

Deze sectie demonstreert hoe Ansible-groepen dynamisch worden toegewezen aan een

node met behulp van de *inventaris-plugin* en statische definities.

Laten we de node `pxd-s3` als voorbeeld nemen. Met de `debug`-module kunnen we

de `group_names` voor `pxd-s3` opvragen. Zie hieronder.

}

```

De *Ansible-groepen* worden als volgt afgeleid:

De Ansible-groepen worden als volgt afgeleid:

1. `lxd`, `ubuntu` en `ubuntu22` zijn afkomstig van de definitie van de

   [Vagrant box](g) `ubuntu22-lxd` in `Vagrantfile.yml`.

- Voor meer informatie over de `pxd-s3`-node:

  {{< rellink path="/docs/howto/phx/s3" >}}

- {{< rellink path="/docs/concepts/ansible/projects/inventory" desc=true >}}

[^phx]: In de context van het PHX-project is een suboptimale oplossing onderzocht

  waarbij het idee ontstond om het toevoegen van servers aan het statische

  `hosts.ini`-bestand in de juiste [Ansible-groepen](g) te automatiseren om het werk van de

  [Ansible operator](g) te vereenvoudigen. Destijds gebruikte het project een traditioneel statisch

  [inventarisbestand](g) in plaats van dynamische inventaris, ook al werd vRA gebruikt voor provisioning.

  Deze aanpak is suboptimaal om twee redenen. Ten eerste is het beheren van het *inventarisbestand* met

  Ansible-groepen en nodes niet overdreven complex, en de *Ansible operator* moet er toch een grondig

  begrip van hebben, omdat het de basis vormt van effectieve automatisering. Ten tweede is het logischer

  om Ansible-groepen te creëren op basis van tags of labels in vRA en de inventarisinformatie daaruit af

  te leiden — een uitdaging die vanzelf wordt opgelost bij het adopteren van dynamische inventaris,

  in plaats van updates naar een statisch bestand te automatiseren.

 No newline at end of file

---

title: Vagrant inventory plugin

linktitle: Vagrant plugin

categories: [Voorbeeld]

tags: [Dynamic-Inventory]

description: >-

  Voorbeeld van een aangepaste inventory plugin voor Vagrant in de PHX-referentie-implementatie. De plugin illustreert het opbouwen van inventory, en het gebruik ervan in de ontwikkelomgeving simuleert dynamische inventory met behulp van een statisch `Vagrantfile.yml`.

toc_hide: true

hide_summary: true

---

De PHX [referentie-implementatie](g)

{{< ansible_inventory_link "/docs/gitlab/c2platform/phx/ansible" "gitlab" "false" "true" >}}

bevat een voorbeeld van een aangepaste inventory plugin.

De plugin `plugins/inventory/vagrant.py` leest `Vagrantfile.yml` om de inventory te genereren.

Het voegt hosts toe, stelt variabelen in zoals IP-adressen en wijst groepen toe op basis van prefixen, labels en aanvullende INI-bestanden.

Het kan de gegenereerde inventory ook exporteren naar een INI-bestand voor debugging of integratie.

{{% code project="/docs/gitlab/c2platform/phx/ansible"

   file="plugins/inventory/vagrant.py"

   hash="db48fceac5a372c291e7fba25f1f5e1fc0022ee4b3b320368ae3ed3a45af3d58" %}}

De Vagrant inventory plugin is een Ansible inventory plugin die wordt gebruikt voor de ontwikkelomgeving.

Het doel van deze plugin is tweeledig.

Ten eerste biedt het een enkele bron van waarheid voor zowel Vagrant als Ansible tijdens ontwikkeling.

Dit elimineert de noodzaak om informatie te dupliceren, zoals IP-adressen, in Vagrant- en Ansible-configuraties.

Ten tweede illustreert het hoe inventory voor Ansible kan worden opgebouwd met een aangepaste module of plugin.

De toepassing in de ontwikkelomgeving simuleert [dynamische inventaris](g).

Veel overheidsorganisaties worstelen met het concept van dynamische inventory.

Deze plugin dient als een praktisch voorbeeld van een aangepaste inventory plugin.

 No newline at end of file