Glossary

Terms commonly used throughout the documentation.

A C D E G H I M O P R S T V

Ansible

Ansible is an open-source automation platform developed by Red Hat, used for IT tasks such as configuration management, application deployment, task automation, and orchestration. The term can refer specifically to Ansible Core, the community-driven engine, or the broader ecosystem, including the Ansible Automation Platform (AAP), Ansible Galaxy for sharing Ansible collections (and Ansible roles), and related tools.

Ansible Automation Platform

Ansible Automation Platform, also abbreviated as AAP, is Red Hat’s enterprise-grade platform for automating IT operations, built on open-source Ansible. It provides tools for scaling automation across teams and infrastructures, with features like role-based access control, job scheduling, and centralized management.

Key components include:

Automation Controller, the core orchestration engine (open-source version known as AWX), which manages playbook execution and workflows.
Automation Hub, a private content repository for Ansible collections and Ansible roles (open-source version known as Galaxy NG), enabling secure sharing within organizations.

AAP enhances Ansible’s capabilities for large-scale, secure, and compliant automation in enterprise environments.

Ansible collection

An Ansible collection is a standardized packaging and distribution format in Ansible, an open-source IT automation tool. It bundles related automation content—such as roles, modules, plugins, playbooks, and other resources—into a reusable unit that simplifies organization, sharing, and reuse of automation logic across projects. These collections can be published, discovered, and installed using Ansible Galaxy.

Ansible content

The term Ansible content or content or refers to Ansible roles, modules, plugins, playbooks, and other resources. This Ansible content is packaged in a standardized distribution format called the Ansible collection, making it easier to organize, share, and reuse automation logic.

Ansible Core

Ansible Core includes the Ansible language and runtime, a set of built-in modules and command-line tools, and a framework for extending automation with Ansible collections.

Ansible documentation

Ansible documentation refers primarily to the standard documentation provided in accordance with Ansible practices and standards. This includes README.md files within Ansible collections and roles, as well as Ansible module documentation in the form of YAML files. It can also encompass accompanying documentation in wikis, static websites, or other formats.

Ansible engineer

See Ansible engineering.

Ansible engineering

Ansible engineering, also known simply as engineering, refers to the practice of developing and maintaining reusable Ansible content, such as Ansible collections and Ansible roles, often shared via Ansible Galaxy, to build standardized automation solutions. This focuses on creating modular, scalable automation artifacts, in contrast to Ansible operations, which involves applying these artifacts to configure and manage infrastructure through desired state configuration.

The practitioner of Ansible engineering is often called an Ansible engineer, who creates, tests, and validates the inventory project using the Ansible development environment. The Ansible engineer does not typically manage production infrastructure, except possibly the hosts of the Ansible development environment.

Ansible environment group

The term ansible environment group, also abbreviated as environment group, refers to a special type of Ansible group that corresponds to a specific environment, such as development, test, staging, or production. It is part of a group-based environments strategy. In a GitOps approach, an environment group is associated with a corresponding environment branch.

Ansible Galaxy

Ansible Galaxy (often just called Galaxy) is the official community hub and repository hosted by Red Hat for discovering, sharing, and downloading Ansible content, specifically Ansible collections, see Ansible collection. It’s like a package manager for Ansible content—users can publish their collections to Galaxy for others to install. Galaxy ensures content is searchable, versioned, and accessible, promoting collaboration in the Ansible ecosystem.

Ansible group

An Ansible group is a collection of servers or hosts defined in the inventory file within the inventory project. It allows referencing multiple associated hosts for automation or defining variables in bulk. Once defined, you can use patterns to select the hosts or groups for Ansible to run against.

Ansible inventory project

An Ansible inventory project, also known as an inventory project, is a structured collection of files used in Ansible for managing hosts and configurations as part of a GitOps approach. It serves as the complete, single source of truth for the system’s desired state configuration, defining all environments through a group-based environments strategy. This includes specifying which hosts belong to each environment group (e.g., development, test, staging, production), along with their associated Ansible roles, configurations, and variables.

It typically includes an inventory file (hosts.ini), playbooks, group variables, host variables, and Ansible Vault files for secret variables. As a GitOps repository, changes are managed through environment branches and merge requests to promote configurations across environments. This type of project is sometimes referred to as a playbook project or configuration project.

See also Ansible mirror inventory project for a specialized variant used in development and testing.

Ansible mirror inventory project

An Ansible mirror inventory project, also known as an Ansible mirror project, is a specialized type of Ansible inventory project that integrates Vagrant project functionality to mimic real-world infrastructure locally. It combines Ansible automation with Vagrant for virtual machine orchestration, enabling development and testing of Ansible content and configurations in a controlled, local setup.

It mirrors an inventory project in the government domain or data center, providing an open-source counterpart for prototyping and validation. An Ansible mirror inventory project is a key part of the Ansible development environment—and, as a consequence, also a key part of the C2 Platform’s open, unless approach.

See also reference implementation for related concepts used in development and testing.

Ansible operations

Ansible operations, also known simply as operations, refers to the practice of applying and managing automation using existing Ansible content, such as Ansible collections and Ansible roles, to configure and manage infrastructure through desired state configuration. This focuses on deploying and maintaining systems in various environments, in contrast to Ansible engineering, which involves developing and maintaining reusable automation artifacts. The practitioner of Ansible operations is often called an Ansible operator, who utilizes the Ansible inventory project to apply these configurations.

Ansible operator

See Ansible operations.

Ansible role

An Ansible role is a structured and reusable set of Ansible tasks, variables, files, templates, and other resources organized in a predefined directory layout. It encapsulates automation logic for specific purposes, such as configuring a web server, allowing for modularity and reuse across playbooks.

Ansible roles are often included as part of Ansible collections, which is the preferred packaging and distribution format in modern Ansible practices. However, they can also exist independently as standalone units. In this case, an Ansible role serves as its own distribution format for sharing Ansible content, typically via Ansible Galaxy. This standalone approach is considered somewhat deprecated and outdated, as collections provide better organization and versioning. Within C2 Platform projects, standalone roles are not used, favoring collections for better maintainability and scalability.

Ansible Vault

Ansible Vault refers to a feature in Ansible that allows users to encrypt sensitive data, such as passwords, keys, or variables, within files. This ensures secure storage and handling of confidential information in Ansible projects, using tools like ansible-vault for encryption, decryption, and editing. In the context of C2 Platform’s projects that use AAP, the vault is realized using a secret_vars folder that is part of an Ansible inventory project.

current state

See desired state configuration.

desired state

See desired state configuration.

desired state configuration

Desired state configuration (DSC) is a declarative approach in configuration management tools like Ansible, where users define the intended end-state—also called the desired state or declared state—of a system or infrastructure. In the context of Ansible, playbooks utilize this desired state, and the tool idempotently applies changes to ensure the current state (also called the actual state) matches it. This handles tasks such as package installation, file management, and service configuration without manual intervention. Within C2 Platform projects, the desired state is captured in an inventory project.

development desktop

The term development desktop, or Ansible development desktop, refers to the primary workstation used within an Ansible development environment for creating, testing, and managing Ansible automation. In the default open-source C2 Platform approach, the development desktop serves as the entire development environment, leveraging tools like Vagrant, LXD, and VirtualBox for local development. In this setup, the inventory project includes a Vagrantfile that defines nodes, networks etc.

In customer domains, the development desktop is typically a virtual machine, and the Ansible development environment comprises this desktop along with nodes provisioned via tools like vRealize Automation (vRA).

development environment

A development environment, also known as an Ansible development environment, refers to the configured setup where Ansible engineers create, test, and manage Ansible content, inventories, and related automation artifacts. It is the second key concept of the C2 Platform approach, following the open, unless principle.

It centers around a primary development desktop, which serves as the main workstation for these tasks. In the default open-source C2 Platform approach, the development desktop forms the entire development environment. This setup leverages Ansible mirror inventory projects as reference implementations to simulate real-world infrastructure locally for development and testing.

In customer domains, a similar setup may exist, often comprising a virtual machine desktop paired with provisioned nodes. However, this is typically not a true development environment in the C2 Platform sense but rather a pseudo development environment, suitable only for light Ansible engineering work due to constraints like security policies and limited resources.

DSC

See desired state configuration.

environment branch

The term environment branch refers to a Git branch that corresponds to a specific environment (such as development, test, staging, or production) in a GitOps approach. It is associated with an environment group in the inventory file, allowing for environment-specific configurations, variables, and deployments as part of a group-based environments approach within an inventory project.

Gitlab Open Source Program

The GitLab Open Source Program is an initiative by GitLab that provides free access to premium features of GitLab Ultimate for qualifying open-source projects and organizations. It supports the open-source community by offering advanced tools for collaboration, CI/CD, security, and project management at no cost, fostering innovation and growth in open-source development. The C2 Platform is part of the GitLab Open Source Program, leveraging these features to enhance its open-source automation and infrastructure projects.

GitOps

GitOps is an operational framework and methodology for managing infrastructure and applications using Git as the single source of truth. It emphasizes declarative configurations stored in Git repositories, where changes are applied automatically through reconciliation processes to ensure the actual system state matches the desired state. See also desired state configuration.

group variables

Group variables (often abbreviated as group_vars) are variables in Ansible that are associated with a group of hosts defined in the inventory file within an inventory project. They are typically stored in files within a group_vars directory or directly in the inventory file, and are applied to all hosts within that group. This allows for efficient management of shared configurations across multiple hosts, promoting modularity and reuse in Ansible automation.

See also host variables and secret variables.

group-based environments

The term group-based environments refer to an Ansible inventory strategy within an inventory project, where hosts are organized into groups representing different environments (e.g., dev, test, staging, prod). This allows for environment-specific variables and configurations to be managed efficiently using group variables.

handler

An Ansible handler, also known simply as a handler, is a special type of task in Ansible that is executed only when notified by another task, typically for actions like restarting services after configuration changes. Handlers are commonly defined within an Ansible role as part of an Ansible collection. While they can technically be included in a play within a playbook, this is not common in C2 Platform projects unless used temporarily for development, testing, or debugging purposes.

host variables

Host variables (often abbreviated as host_vars) are variables in Ansible that are associated with a specific host defined in the inventory file within an inventory project. They are typically stored in files within a host_vars directory or directly in the inventory file, and are applied only to that host. This allows for fine-grained customization of configurations for individual hosts, enabling tailored automation in Ansible projects.

See also group variables and secret variables.

IaC

Infrastructure as Code (IaC) is a methodology for provisioning and managing computing infrastructure through machine-readable definition files, rather than physical hardware configuration or interactive tools. It treats infrastructure as software, enabling version control, automation, and collaboration. Unlike simple scripts (e.g., a Bash script that performs one-time infrastructure changes), IaC emphasizes declarative, idempotent practices where configurations are defined in code and tools ensure consistent application, handling changes only when necessary.

IaC is closely related to desired state configuration (DSC), which is a key principle in tools like Ansible, focusing on defining and maintaining a desired state. Similarly, GitOps builds on IaC by using Git repositories as the single source of truth for declarative configurations, automating reconciliation to match the actual state with the defined one.

inventory

The term inventory refers to different concepts in Ansible depending on the context. It most commonly means the Ansible inventory project. In the C2 Platform context, this is the primary meaning, referring to a structured collection of files for managing hosts and configurations. It may alternatively refer to the inventory file itself, a specific file within the project that defines hosts and Ansible groups.

inventory file

An inventory file is a file used in Ansible to define the managed nodes (hosts) that you automate, along with variables associated with those hosts. You can also specify groups of hosts.

Ansible supports multiple inventory files, but in the C2 Platform approach, there is typically one inventory file per inventory project, named hosts.ini. While it is possible to define group variables (and host variables) directly in the hosts.ini file, this is not recommended. Instead, use group variables in its dedicated directory group_vars to keep the desired state in one place as much as possible. This approach promotes better organization, maintainability, and adherence to best practices in Ansible automation.

merge request

A merge request, also known as an MR, is a feature in version control systems that allows developers to propose changes from one branch to another, facilitating code review, discussion, and integration. It is similar to a pull request in platforms like GitHub. In the context of an Ansible inventory project with a group-based environments approach, merge requests are particularly significant for promoting changes from one environment branch to the next, ensuring controlled progression through environments like development, test, staging, and production. Merge requests often include approval processes to maintain quality and compliance, supported by tools such as GitLab and Azure DevOps.

module

An Ansible module, also known simply as a module, is a self-contained script or program that performs a specific action on a managed node in Ansible. Modules are the building blocks of Ansible automation, invoked by tasks in playbooks or Ansible roles, handling operations such as file manipulation, package management, service control, or cloud resource provisioning. They are typically packaged within Ansible collections for organized distribution, versioning, and reuse via Ansible Galaxy.

open, unless

Open, unless, also known as open approach, is the first key concept of the C2 Platform approach. It is a principle that emphasizes transparency, collaboration, and reuse in software development and automation. It promotes sharing code, ideas, and solutions openly by default, unless specific constraints (e.g., security or legal requirements) necessitate otherwise. In the context of the Dutch government and the C2 Platform, this approach leverages open source software (OSS) to enhance productivity, flexibility, and innovation in automation projects.

play variable

A play variable, also known simply as a play var, is a variable defined within the vars section of a play in an Ansible playbook. It is part of an inventory project and specifies configuration values or data applied to all hosts targeted by that play. Play variables have higher precedence than group variables, meaning they override those if the same variable name if used, according to Ansible’s variable precedence rules. However, in the C2 Platform approach, which emphasizes storing the complete desired state in group variables, the use of play variables is minimized to keep configurations centralized and maintainable.

See also task and handler.

playbook

An Ansible playbook, also known simply as a playbook, is a YAML file that defines a series of automation steps in Ansible. It consists of one or more plays, where each play specifies a set of hosts (from the inventory) to target. It can contain directly in the play play variables (in other words desired state), tasks, and even handlers.

However, in the context of a C2 Platform approach that utilizes an inventory project, most playbooks are simple: they contain only one play and only include roles. In this setup, the desired state is completely stored in one location as group variables.

precedence

Precedence, also known as variable precedence, refers to the rules in Ansible that determine the order in which variables from different sources are applied or overridden. When the same variable is defined in multiple places, such as play variables, group variables, or host variables, Ansible follows a specific precedence hierarchy to decide which value takes effect. This ensures consistent behavior in automation, with higher-precedence sources overriding lower ones. Understanding precedence is crucial for managing complex configurations in an inventory project.

project variable

A project variable, also known as an inventory project variable, is a variable defined and introduced within an inventory project. Unlike variables in Ansible roles, project variables are not tied to specific Ansible tasks or role logic, meaning no tasks directly act upon them. They serve primarily as helper variables for various purposes, such as simplifying logic to ultimately set a role variable, deduplicating code and configuration (following the DRY principle), or ensuring consistent settings across Ansible groups. For example, in a project managing Confluence and an Apache reverse proxy, a project variable like px_confluence_web_port=443 (with px_ as the prefix for project variables in the inventory project) can be placed in the all group. This allows its use in both the confluence group and the reverse_proxy group, promoting consistency and reuse.

pseudo development environment

A pseudo development environment is a suboptimal variant of the Ansible development environment, commonly found in constrained customer domains (e.g., government settings) where security, resource limitations, or policies restrict flexibility. It prioritizes shared resources and controlled access over individual engineer autonomy, leading to inefficiencies in testing and automation compared to open-source setups.

reference implementation

A reference implementation is an open-source, fully functional example of a system that mirrors a closed-source setup, typically in a government domain or data center. It is designed for local deployment on a developer’s machine, enabling rapid prototyping, testing, and development in realistic environments.

In the C2 Platform, a reference implementation is realized through an Ansible mirror inventory project, which is an open-source Ansible inventory project that mirrors a closed-source Ansible inventory project within the customer domain. It integrates Ansible inventory project structure with Vagrant project elements for automation and simulation. This setup is a key component of the Ansible development environment, allowing Ansible engineers to create and validate these example systems locally. This concept aligns with the open, unless principle, promoting productivity, collaboration, and reuse by providing adaptable examples for customer domains.

role variable

A role variable, also known as an Ansible role variable, is a variable defined within an Ansible role to provide configurable parameters for its tasks, templates, and handlers. These variables are typically stored in files like defaults/main.yml (for default values that can be overridden) or vars/main.yml (for values that should not be overridden) within the role’s directory structure. Role variables promote modularity and customization, allowing users to adapt the role’s behavior without modifying its core logic. Role variables should be prefixed with the role name (e.g., myrole_varname). This convention, part of Ansible community guidelines, helps prevent variable name conflicts across different roles and improves maintainability. In the context of an inventory project, when overriding or setting role variables in group variables, this is especially important.

Role variables in vars/main.yml cannot be overridden, so they should only be used for very specific reasons. In principle, a role should avoid using non-overridable values to remain flexible, configurable, and adaptable to as many applications as possible. For example, use vars to prevent users from changing a setting that could cause harm or break functionality.

secret variables

Secret variables (often abbreviated as secret_vars) are variables in Ansible that contain sensitive information, such as passwords or keys, and are encrypted using Ansible Vault. The concept of secret variables and the associated secret_vars directory is not a standard part of Ansible, unlike the standard group_vars and host_vars directories. As a result, unlike group variables or host variables, they are not automatically associated with groups or hosts because they are stored outside the standard group_vars or host_vars directories, typically in a custom secret_vars directory within an inventory project.

secret_vars

See secret variables

task

An Ansible task, also known simply as a task, is the fundamental unit of action in Ansible. It defines a single step or operation, such as installing a package, copying a file, or restarting a service, executed using an Ansible module. Tasks are typically organized within an Ansible role as part of an Ansible collection, promoting modularity and reuse in automation workflows. They can also appear directly in a playbook, though this is less common in structured projects like those in the C2 Platform.

Vagrant

Vagrant is an open-source tool developed by HashiCorp for building, managing, and provisioning virtual machine environments in a repeatable and portable way. It simplifies the creation of consistent development setups by using a declarative configuration file called a Vagrantfile to define virtual machines, networks, and provisioning steps. Vagrant uses pre-packaged vagrant boxes that can be sourced from Vagrant Cloud or custom repositories, ensuring portability and consistency across different host systems.

In the C2 Platform context, with the open, unless approach, Vagrant is a key tool within the open-source development environment. It enables Ansible engineers to locally simulate infrastructure for developing and testing Ansible content ( Ansible collections, Ansible roles etc.), and Ansible mirror inventory projects. This Ansible content is then shared and published to Ansible Galaxy.

Vagrant box

A Vagrant box is a packaged virtual machine image used by Vagrant to create and configure portable, reproducible development environments. It includes a base operating system, pre-installed software, and configurations, allowing users to quickly provision consistent virtual machines for development and testing. Vagrant boxes can be shared and downloaded from repositories like Vagrant Cloud.

In the C2 Platform, Vagrant boxes for Windows (based on VirtualBox) and Linux (based on LXD) are hosted on Vagrant Cloud to support local development and testing in Ansible development environments. This enables Ansible engineers to simulate infrastructure for developing and maintaining Ansible content and Ansible mirror inventory projects.

Vagrant cloud

Vagrant Cloud is a public, searchable index of Vagrant boxes hosted by HashiCorp. It allows users to discover, share, and manage pre-configured virtual machine images for consistent development environments. In the C2 Platform, several boxes are hosted there, based on VirtualBox for Windows and LXD for Linux.

Vagrant project

A vagrant project is a directory structure that uses Vagrant to define and manage virtual development environments, typically including a Vagrantfile for declarative configuration of virtual machines, networks, and provisioning steps. In the C2 Platform context, a vagrant project integrates with Ansible automation, such as within an Ansible mirror inventory project, to simulate real-world infrastructure locally for testing Ansible content ( Ansible collections, Ansible roles, etc) and mirror inventory projects. It promotes consistency and repeatability in development environments, allowing Ansible engineers to prototype and validate automation. This Ansible content is then published to Ansible Galaxy to enable its utilization in automation across Dutch government domains and data centers.

Vagrantfile

A Vagrantfile is a Ruby-based configuration file used by Vagrant to define and manage virtual development environments in a declarative manner. It specifies details such as the virtual machine provider (e.g., VirtualBox, LXD), base Vagrant box, networking settings, provisioning scripts (often integrating Ansible playbooks), and shared folders. In the C2 Platform context, the Vagrantfile is a key component of a Vagrant project or Ansible mirror inventory project, enabling local simulation of infrastructure for testing Ansible content and configurations as part of the Ansible development environment. This promotes consistency, repeatability, and alignment with the open, unless principle.

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Last modified September 22, 2025: move c2platform/c2/website C2-889 (519ee43)