Begrippenlijst

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

Ansible

Ansible is een open-source automatiseringsplatform ontwikkeld door Red Hat, gebruikt voor IT-taken zoals configuratiebeheer, applicatie-uitrol, taakautomatisering en orkestratie. De term kan specifiek verwijzen naar Ansible Core, de door de community gedreven engine, of het bredere ecosysteem, inclusief de Ansible Automation Platform (AAP), Ansible Galaxy voor het delen van Ansible-collecties (en Ansible-rollen), en gerelateerde tools.

Zie  details .

Ansible Automation Platform

Ansible Automation Platform, ook afgekort als AAP, is Red Hat’s enterprise-grade platform voor het automatiseren van IT-operaties, gebouwd op open-source Ansible. Het biedt tools voor het schalen van automatisering over teams en infrastructuren, met functies zoals role-based access control, job scheduling en centralized management.

Belangrijkste componenten zijn onder meer:

• Automation Controller, de kern van de orchestration engine (open-source versie bekend als AWX), die playbook-uitvoering en workflows beheert.
• Automation Hub, een private content repository voor Ansible-collecties en Ansible-rollen (open-source versie bekend als Galaxy NG), die veilige deling binnen organisaties mogelijk maakt.

AAP verbetert Ansible’s mogelijkheden voor grootschalige, veilige en conforme automatisering in enterprise-omgevingen.

Zie  details .

Ansible Core

Ansible Core omvat de Ansible-taal en runtime, een set ingebouwde modules en command-line tools, en een framework voor het uitbreiden van automatisering met Ansible-collecties.

Ansible engineer

Zie Ansible engineering.

Ansible engineering

Ansible engineering, ook wel gewoon engineering genoemd, verwijst naar de praktijk van het ontwikkelen en onderhouden van herbruikbare Ansible-content, zoals Ansible-collecties en Ansible-rollen, vaak gedeeld via Ansible Galaxy, om gestandaardiseerde automatiseringsoplossingen te bouwen. Dit richt zich op het creëren van modulaire, schaalbare automatiseringsartefacten, in tegenstelling tot Ansible operations, dat inhoudt dat deze artefacten worden toegepast om infrastructuur te configureren en te beheren via desired state configuration.

De beoefenaar van Ansible engineering wordt vaak een Ansible-engineer genoemd, die het Ansible-inventarisproject creëert, test en valideert met behulp van de Ansible-ontwikkelomgeving. De Ansible-engineer beheert doorgaans geen productie-infrastructuur, behalve mogelijk de hosts van de Ansible-ontwikkelomgeving.

Zie  details .

Ansible Galaxy

Ansible Galaxy (vaak gewoon Galaxy genoemd) is de officiële community hub en repository gehost door Red Hat voor het ontdekken, delen en downloaden van Ansible-content, specifiek Ansible collections, zie Ansible-collecties. Het is als een package manager voor Ansible content—gebruikers kunnen hun collections publiceren naar Galaxy zodat anderen ze kunnen installeren. Galaxy zorgt ervoor dat content doorzoekbaar is, versiebeheer heeft en toegankelijk is, en bevordert samenwerking in het Ansible-ecosysteem.

Zie  details .

Ansible operations

Ansible operations, ook wel gewoon operations genoemd, verwijst naar de praktijk van het toepassen en beheren van automatisering met behulp van bestaande Ansible-content, zoals Ansible-collecties en Ansible-rollen, om infrastructuur te configureren en te beheren door middel van desired state configuration. Dit richt zich op het uitrollen en onderhouden van systemen in verschillende omgevingen, in tegenstelling tot Ansible engineering, dat het ontwikkelen en onderhouden van herbruikbare automatiseringsartefacten inhoudt. De beoefenaar van Ansible operations wordt vaak een Ansible operator genoemd, die het Ansible-inventarisproject gebruikt om deze configuraties toe te passen.

Zie  details .

Ansible operator

Zie Ansible operations.

Ansible Vault

Ansible Vault verwijst naar een functie in Ansible die gebruikers in staat stelt om gevoelige gegevens, zoals wachtwoorden, sleutels of variabelen, binnen bestanden te versleutelen. Dit zorgt voor een veilige opslag en omgang met vertrouwelijke informatie in Ansible-projecten, met behulp van tools zoals ansible-vault voor versleuteling, ontsleuteling en bewerking. In de context van projecten van het C2 Platform die AAP gebruiken, wordt de vault gerealiseerd met een map secret_vars die deel uitmaakt van een Ansible-inventarisproject.

Zie  details .

Ansible-collecties

Een Ansible-collectie is een gestandaardiseerd formaat voor verpakking en distributie in Ansible, een open-source IT-automatiseringshulpmiddel. Het bundelt gerelateerde automatiseringsinhoud—zoals rollen, modules, plugins, playbooks en andere resources—in een herbruikbare eenheid die de organisatie, het delen en het hergebruik van automatiseringslogica over projecten vereenvoudigt. Deze collecties kunnen worden gepubliceerd, ontdekt en geïnstalleerd met behulp van Ansible Galaxy.

Zie  details .

Ansible-content

De term Ansible-content of content verwijst naar Ansible roles, modules, plugins, playbooks en andere resources. Deze Ansible-content is verpakt in een gestandaardiseerd distributieformaat genaamd Ansible-collecties, wat het makkelijker maakt om automatiseringslogica te organiseren, delen en hergebruiken.

Ansible-documentatie

Ansible-documentatie verwijst voornamelijk naar de standaard documentatie die wordt geleverd in overeenstemming met Ansible-praktijken en standaarden. Dit omvat README.md-bestanden binnen Ansible collecties en rollen, evenals Ansible-module documentatie in de vorm van YAML-bestanden. Het kan ook bijbehorende documentatie in wiki’s, statische websites of andere formaten omvatten.

Zie  details .

Ansible-groep

Een Ansible-groep, is een verzameling van servers of hosts die is gedefinieerd in het inventarisbestand binnen een inventarisproject. Hiermee kun je meerdere geassocieerde hosts tegelijk aanspreken voor automatisering of variabelen in bulk definiëren. Eenmaal gedefinieerd, kun je patronen gebruiken om de hosts of groups te selecteren waarop Ansible moet worden uitgevoerd.

Zie  details .

Ansible-inventarisproject

Een Ansible-inventarisproject, ook bekend als een inventarisproject, is een gestructureerde verzameling van bestanden die in Ansible worden gebruikt voor het beheren van hosts en configuraties als onderdeel van een GitOps-aanpak. Het dient als de complete, enige bron van waarheid voor de desired state configuration van het systeem, waarbij alle omgevingen worden gedefinieerd door een strategie van groepgebaseerde omgevingen. Dit omvat het specificeren van welke hosts bij elke Ansible-omgevingsgroep horen (bijv. ontwikkeling, test, staging, productie), samen met hun bijbehorende Ansible-rollen, configuraties en variabelen.

Het omvat typisch een inventarisbestand (hosts.ini), playbooks, groepsvariabelen, hostvariabelen, en Ansible Vault-bestanden voor geheime variabelen. Als een GitOps-repository worden wijzigingen beheerd door omgevings-branches en merge requests om configuraties over omgevingen te promoten. Dit type project wordt soms aangeduid als een playbook-project of configuratieproject.

Zie ook Ansible-mirror-inventarisproject voor een gespecialiseerde variant die wordt gebruikt in ontwikkeling en testen.

Zie  details .

Ansible-mirror-inventarisproject

Een Ansible-mirror-inventarisproject, ook bekend als een Ansible-mirror-project, is een gespecialiseerd type Ansible-inventarisproject dat Vagrant-project-functionaliteit integreert om infrastructuur in de echte wereld lokaal na te bootsen. Het combineert Ansible-automatisering met Vagrant voor de orkestratie van virtuele machines, waardoor ontwikkeling en testen van Ansible-content en configuraties mogelijk worden in een gecontroleerde, lokale opzet.

Het spiegelt een inventarisproject in het overheidsdomein of datacenter en biedt een open-source-tegenhanger voor prototyping en validatie. Een Ansible-mirror-inventarisproject is een sleutelonderdeel van de Ansible-ontwikkelomgeving—en, als gevolg daarvan, ook een sleutelonderdeel van de Open, tenzij-aanpak van het C2 Platform.

Zie ook Referentie-implementatie voor gerelateerde concepten die worden gebruikt in ontwikkeling en testen.

Zie  details .

Ansible-omgevingsgroep

De term Ansible-omgevingsgroep, ook afgekort als omgevingsgroep, verwijst naar een speciaal type Ansible-groep dat overeenkomt met een specifieke omgeving, zoals ontwikkeling, test, staging of productie. Het maakt deel uit van een strategie van groepgebaseerde omgevingen. In een GitOps-benadering is een omgevingsgroep geassocieerd met een bijbehorende omgevings-branch.

Zie  details .

Ansible-rol

Een Ansible-rol is een gestructureerde en herbruikbare set Ansible-taken, variabelen, bestanden, sjablonen en andere resources die zijn georganiseerd in een vooraf gedefinieerde directorystructuur. Het kapselt automatiseringslogica in voor specifieke doeleinden, zoals het configureren van een webserver, waardoor modulariteit en hergebruik in playbooks mogelijk wordt.

Ansible-rol worden vaak opgenomen als onderdeel van Ansible-collecties, wat de voorkeursmethode is voor verpakking en distributie in moderne Ansible-praktijken. Ze kunnen echter ook onafhankelijk bestaan als standalone eenheden. In dat geval dient een Ansible-rol als zijn eigen distributieformaat voor het delen van Ansible-content, meestal via Ansible Galaxy. Deze standalone benadering wordt als enigszins verouderd beschouwd, omdat collecties betere organisatie en versiebeheer bieden. Binnen C2 Platform-projecten worden standalone roles niet gebruikt; in plaats daarvan worden collecties verkozen voor betere onderhoudbaarheid en schaalbaarheid.

current state

Zie desired state configuration.

desired state

See desired state configuration.

desired state configuration

Desired state configuration (DSC) is een declaratieve benadering in configuratiebeheertools zoals Ansible, waarbij gebruikers de beoogde eindtoestand—ook wel de desired state of declared state—van een systeem of infrastructuur definiëren. In de context van Ansible maken playbooks gebruik van deze desired state, en past de tool idempotent wijzigingen toe om ervoor te zorgen dat de current state (ook wel de actual state genoemd) hiermee overeenkomt. Dit omvat taken zoals pakketinstallatie, bestandsbeheer en serviceconfiguratie zonder handmatige tussenkomst. Binnen C2 Platform-projecten wordt de desired state vastgelegd in een inventarisproject.

Zie  details .

DSC

See desired state configuration.

geheime variabelen

Geheime variabelen (vaak afgekort als secret_vars) zijn variabelen in Ansible die gevoelige informatie bevatten, zoals wachtwoorden of sleutels, en zijn versleuteld met Ansible Vault. Het concept van geheime variabelen en de bijbehorende secret_vars-map is geen standaard onderdeel van Ansible, in tegenstelling tot de standaard group_vars- en host_vars-mappen. Als gevolg hiervan worden ze, in tegenstelling tot groepsvariabelen of hostvariabelen, niet automatisch gekoppeld aan groepen of hosts omdat ze zijn opgeslagen buiten de standaard group_vars- of host_vars- mappen, meestal in een aangepaste secret_vars-map binnen een inventarisproject.

Zie  details .

Gitlab Open Source Program

Het Gitlab Open Source Program is een initiatief van GitLab dat gratis toegang biedt tot premium functies van GitLab Ultimate voor in aanmerking komende open-source projecten en organisaties. Het ondersteunt de open-source gemeenschap door geavanceerde tools aan te bieden voor samenwerking, CI/CD, beveiliging en projectbeheer zonder kosten, wat innovatie en groei in open-source ontwikkeling bevordert. Het C2 Platform maakt deel uit van het Gitlab Open Source Program en maakt gebruik van deze functies om zijn open-source automatisering en infrastructuurprojecten te verbeteren.

Zie  details .

GitOps

GitOps is een operationeel framework en methodologie voor het beheren van infrastructuur en applicaties met Git als de enige bron van waarheid. Het benadrukt declaratieve configuraties opgeslagen in Git-repositories, waarbij wijzigingen automatisch worden toegepast via reconciliatieprocessen om ervoor te zorgen dat de werkelijke systeemsstatus overeenkomt met de desired state. Zie ook desired state configuration.

Zie  details .

groepgebaseerde omgevingen

Het begrip Groepgebaseerde omgevingen verwijst naar een Ansible inventory-strategie binnen een inventarisproject, waarbij hosts zijn georganiseerd in groepen die verschillende omgevingen vertegenwoordigen (bijv. dev, test, staging, prod). Dit maakt het mogelijk om omgevingsspecifieke variabelen en configuraties efficiënt te beheren met behulp van groepsvariabelen.

Zie  details .

groepsvariabelen

Groepsvariabelen (vaak afgekort als group_vars) zijn variabelen in Ansible die zijn gekoppeld aan een groep hosts die zijn gedefinieerd in het inventarisbestand binnen een Ansible-inventarisproject. Ze worden doorgaans opgeslagen in bestanden binnen een group_vars-map of direct in het inventarisbestand, en worden toegepast op alle hosts binnen die groep. Dit maakt een efficiënt beheer van gedeelde configuraties over meerdere hosts mogelijk, en bevordert modulariteit en hergebruik in Ansible- automatisering.

Zie ook hostvariabelen en geheime variabelen.

Zie  details .

handler

Een Ansible-handler, ook wel gewoon een handler genoemd, is een speciaal type taak in Ansible dat alleen wordt uitgevoerd wanneer het wordt genotificeerd door een andere taak, typisch voor acties zoals het herstarten van services na configuratiewijzigingen. Handlers worden gewoonlijk gedefinieerd binnen een Ansible-rol als onderdeel van een Ansible-collecties. Hoewel ze technisch kunnen worden opgenomen in een play binnen een playbook, is dit niet gebruikelijk in C2 Platform-projecten tenzij gebruikt tijdelijk voor ontwikkeling, testen of debugging doeleinden.

Zie  details .

hostvariabelen

Hostvariabelen (vaak afgekort als host_vars) zijn variabelen in Ansible die zijn gekoppeld aan een specifieke host die is gedefinieerd in het inventarisbestand binnen een inventarisproject. Ze worden meestal opgeslagen in bestanden binnen een host_vars-map of direct in het inventarisbestand, en worden alleen toegepast op die host. Dit maakt een fijne aanpassing van configuraties voor individuele hosts mogelijk, wat op maat gemaakte automatisering in Ansible-projecten ondersteunt.

Zie ook groepsvariabelen en geheime variabelen.

Zie  details .

IaC

Infrastructure as Code (IaC) is een methode voor het inrichten en beheren van computerinfrastructuur door middel van machineleesbare definitiebestanden, in plaats van fysieke hardwareconfiguratie of interactieve tools. Het behandelt infrastructuur als software, waardoor versiebeheer, automatisering en samenwerking mogelijk worden. In tegenstelling tot eenvoudige scripts (bijv. een Bash-script dat eenmalige wijzigingen in de infrastructuur uitvoert), benadrukt IaC declaratieve, idempotente praktijken waarbij configuraties in code worden gedefinieerd en tools zorgen voor consistente toepassing, waarbij wijzigingen alleen worden afgehandeld wanneer dat nodig is.

IaC is nauw verwant aan desired state configuration (DSC), wat een belangrijk principe is in tools zoals Ansible, met de focus op het definiëren en behouden van een desired state. Op vergelijkbare wijze bouwt GitOps verder op IaC door Git-repositories te gebruiken als de enige bron van waarheid voor declaratieve configuraties, met automatisering van de afstemming om de werkelijke staat te laten overeenkomen met de gedefinieerde staat.

inventaris

De term inventory verwijst naar verschillende concepten in Ansible, afhankelijk van de context. Het verwijst meestal naar het Ansible-inventarisproject. In de context van het C2 Platform is dit de primaire betekenis, verwijzend naar een gestructureerde verzameling van bestanden voor het beheren van hosts en configuraties. Het kan alternatief verwijzen naar het inventarisbestand zelf, een specifiek bestand binnen het project dat hosts en Ansible-groepen definieert.

inventarisbestand

Een inventarisbestand is een bestand dat in Ansible wordt gebruikt om de beheerde nodes (hosts) te definiëren die je automatiseert, samen met variabelen die aan die hosts zijn gekoppeld. Je kunt ook groepen van hosts specificeren.

Ansible ondersteunt meerdere inventarisbestanden, maar in de C2 Platform-benadering is er typisch één inventarisbestand per inventarisproject, genaamd hosts.ini. Hoewel het mogelijk is om groepsvariabelen (en hostvariabelen) direct in het hosts.ini-bestand te definiëren, wordt dit niet aanbevolen. Gebruik in plaats daarvan groepsvariabelen in de daarvoor bestemde directory group_vars om de desired state zoveel mogelijk op één plaats te houden. Deze benadering bevordert betere organisatie, onderhoudbaarheid en naleving van best practices in Ansible-automatisering.

Zie  details .

merge request

Een merge request, ook bekend als een MR, is een functie in versiebeheersystemen die ontwikkelaars in staat stelt wijzigingen voor te stellen van de ene branch naar de andere, wat code review, discussie en integratie vergemakkelijkt. Het is vergelijkbaar met een pull request in platformen zoals GitHub. In de context van een Ansible-inventarisproject met een benadering van groepgebaseerde omgevingen, zijn merge requests bijzonder belangrijk voor het promoten van wijzigingen van de ene omgevings-branch naar de volgende, wat een gecontroleerde voortgang door omgevingen zoals development, test, staging en production waarborgt. Merge requests omvatten vaak goedkeuringsprocessen om kwaliteit en compliance te behouden, ondersteund door tools zoals GitLab en Azure DevOps.

Zie  details .

module

Een Ansible-module, ook wel eenvoudigweg een module genoemd, is een zelfstandig script of programma dat een specifieke actie uitvoert op een beheerde node in Ansible. Modules zijn de bouwstenen van Ansible-automatisering, aangeroepen door taken in playbooks of Ansible-rollen, en verwerken operaties zoals bestandsmanipulatie, pakketbeheer, servicecontrole of provisioning van cloudresources. Ze worden doorgaans verpakt binnen Ansible-collecties voor georganiseerde distributie, versiebeheer en hergebruik via Ansible Galaxy.

Zie  details .

omgevings-branch

De term omgevings-branch verwijst naar een Git-branch die overeenkomt met een specifieke omgeving (zoals ontwikkeling, test, staging of productie) in een GitOps-benadering. Deze is gekoppeld aan een Ansible-omgevingsgroep in het inventarisbestand, wat omgevingsspecifieke configuraties, variabelen en uitrollen mogelijk maakt als onderdeel van een groepgebaseerde omgevingen-benadering binnen een inventarisproject.

Zie  details .

ontwikkel-desktop

De term ontwikkel-desktop, of Ansible-ontwikkel-desktop, verwijst naar het primaire werkstation dat wordt gebruikt binnen een Ansible-ontwikkelomgeving voor het creëren, testen en beheren van Ansible-automatisering. In de standaard open-source C2 Platform-benadering dient de ontwikkel-desktop als de gehele ontwikkelomgeving, waarbij tools zoals Vagrant, LXD en VirtualBox worden gebruikt voor lokale ontwikkeling. In deze opzet bevat het Ansible-inventarisproject een Vagrantfile dat nodes, netwerken enzovoort definieert.

In klantdomeinen is de ontwikkel-desktop doorgaans een virtuele machine, en de Ansible-ontwikkelomgeving bestaat uit deze desktop samen met nodes die worden ingericht via tools zoals vRealize Automation (vRA).

Zie  details .

ontwikkelomgeving

Een ontwikkelomgeving, ook bekend als een Ansible-ontwikkelomgeving, verwijst naar de geconfigureerde opzet waarin Ansible engineers creëren, testen en beheren van Ansible-content, inventarissen en gerelateerde automatiseringsartefacten. Het is het tweede sleutelconcept van de C2 Platform-benadering, volgend op het Open, tenzij principe.

Het is gecentreerd rond een primaire ontwikkel-desktop, die dient als het hoofdwurkstation voor deze taken. In de standaard open-source C2 Platform-benadering vormt de ontwikkel-desktop de gehele ontwikkelomgeving. Deze opzet maakt gebruik van Ansible-mirror-inventarisprojecten als Referentie-implementaties om real-world infrastructuur lokaal te simuleren voor ontwikkeling en testen.

In klantdomeinen kan een vergelijkbare opzet bestaan, vaak bestaande uit een virtuele machine-desktop gepaard met geprovisioneerde nodes. Echter, dit is typisch geen echte ontwikkelomgeving in de zin van het C2 Platform, maar eerder een pseudo-ontwikkelomgeving, geschikt alleen voor lichte Ansible engineering werk vanwege beperkingen zoals beveiligingsbeleid en beperkte resources.

Zie  details .

Open, tenzij

Open, tenzij, ook bekend als open aanpak, is het eerste sleutelconcept van de C2 Platform-aanpak. Het is een principe dat de nadruk legt op transparantie, samenwerking en hergebruik in softwareontwikkeling en automatisering. Het bevordert het standaard openlijk delen van code, ideeën en oplossingen, tenzij specifieke beperkingen (bijv. veiligheids- of wettelijke vereisten) anders noodzakelijk maken. In de context van de Nederlandse overheid en het C2 Platform maakt deze aanpak gebruik van open source software (OSS) om de productiviteit, flexibiliteit en innovatie in automatiseringsprojecten te verbeteren.

Zie  details .

play-variabele

Een play-variabele, ook wel eenvoudigweg een play-var genoemd, is een variabele die is gedefinieerd binnen het vars-gedeelte van een play in een Ansible-playbook. Het maakt deel uit van een Ansible-inventarisproject en specificeert configuratiewaarden of data die worden toegepast op alle hosts die door die play worden getarget. Play-variabelen hebben een hogere prioriteit dan groepsvariabelen, wat betekent dat ze deze overschrijven als dezelfde variabelenaam wordt gebruikt, volgens Ansible’s variable precedence rules. Echter, in de C2 Platform-benadering, die de nadruk legt op het opslaan van de volledige desired state in groepsvariabelen, wordt het gebruik van play-variabelen geminimaliseerd om configuraties gecentraliseerd en onderhoudbaar te houden.

Zie ook taak en handler.

Zie  details .

playbook

Een Ansible-playbook, ook wel eenvoudigweg een playbook genoemd, is een YAML-bestand dat een reeks automatiseringsstappen definieert in Ansible. Het bestaat uit een of meer plays, waarbij elke play een set hosts specificeert (uit de inventaris) om te targeten. Het kan direct in de play play-variabelen bevatten (met andere woorden desired state), taken, en zelfs handlers.

In de context van een C2 Platform-aanpak die een Ansible-inventarisproject gebruikt, zijn de meeste playbooks echter eenvoudig: ze bevatten slechts één play en includeren alleen Ansible-rollen. In deze opzet wordt de desired state volledig opgeslagen op één locatie als groepsvariabelen.

Zie  details .

projectvariabele

Een projectvariabele, ook bekend als een inventarisprojectvariabele, is een variabele die wordt gedefinieerd en geïntroduceerd binnen een Ansible-inventarisproject. In tegenstelling tot variabelen in Ansible-rollen, zijn projectvariabelen niet gebonden aan specifieke Ansible-taken of rol-logica, wat betekent dat geen taken er direct op inwerken. Ze dienen voornamelijk als hulpmiddelen voor verschillende doeleinden, zoals het vereenvoudigen van logica om uiteindelijk een rolvariabele in te stellen, het vermijden van dubbele code en configuratie (volgens het DRY-principe), of het waarborgen van consistente instellingen over Ansible-groepen heen. Bijvoorbeeld, in een project dat Confluence beheert en een Apache reverse proxy, kan een projectvariabele zoals px_confluence_web_port=443 (waarbij px_ het voorvoegsel is voor projectvariabelen in het inventarisproject) worden geplaatst in de groep all. Dit maakt het mogelijk om deze te gebruiken in zowel de groep confluence als de groep reverse_proxy, wat consistentie en hergebruik bevordert.

Zie  details .

pseudo-ontwikkelomgeving

Een pseudo-ontwikkelomgeving is een suboptimale variant van de Ansible-ontwikkelomgeving, die vaak voorkomt in beperkte klantdomeinen (bijv. overheidsinstellingen) waar beveiliging, resourcebeperkingen of beleidsregels de flexibiliteit beperken. Zij geeft prioriteit aan gedeelde resources en gecontroleerde toegang boven individuele autonomie van engineers, wat leidt tot inefficiënties in testen en automatisering vergeleken met open-source setups.

Zie  details .

Referentie-implementatie

Een referentie-implementatie is een open-source, volledig functioneel voorbeeld van een systeem dat een closed-source opstelling nabootst, typisch in een overheidsdomein of datacenter. Het is ontworpen voor lokale uitrol op de machine van een ontwikkelaar, waardoor snelle prototyping, testen en ontwikkeling in realistische omgevingen mogelijk worden.

In het C2 Platform wordt een referentie-implementatie gerealiseerd door middel van een Ansible-mirror-inventarisproject, dat een open-source Ansible-inventarisproject is dat een closed-source Ansible-inventarisproject binnen het klantdomein nabootst. Het integreert de structuur van een Ansible-inventarisproject met elementen van een Vagrant-project voor automatisering en simulatie. Deze opzet is een kerncomponent van de Ansible-ontwikkelomgeving, die Ansible engineers in staat stelt om deze voorbeeldsystemen lokaal te creëren en te valideren. Dit concept sluit aan bij het principe van Open, tenzij, en bevordert productiviteit, samenwerking en hergebruik door aanpasbare voorbeelden te bieden voor klantdomeinen.

Zie  details .

rolvariabele

Een rolvariabele, ook bekend als een Ansible-rolvariabele, is een variabele die is gedefinieerd binnen een Ansible-rol om configureerbare parameters te bieden voor de taken, templates en handlers. Deze variabelen worden meestal opgeslagen in bestanden zoals defaults/main.yml (voor standaardwaarden die kunnen worden overschreven) of vars/main.yml (voor waarden die niet mogen worden overschreven) binnen de directorystructuur van de rol. Rolvariabelen bevorderen modulariteit en aanpasbaarheid, waardoor gebruikers het gedrag van de rol kunnen aanpassen zonder de kernlogica te wijzigen. Rolvariabelen moeten worden voorafgegaan door de rolenaam (bijv. mijnrol_variabelenaam). Deze conventie, onderdeel van de Ansible-communityrichtlijnen, helpt conflicten in variabelennamen tussen verschillende rollen te voorkomen en verbetert de onderhoudbaarheid. In de context van een Ansible-inventarisproject, bij het overschrijven of instellen van rolvariabelen in groepsvariabelen, is dit vooral belangrijk.

Rolvariabelen in vars/main.yml kunnen niet worden overschreven, dus ze mogen alleen worden gebruikt voor zeer specifieke redenen. In principe moet een rol het gebruik van niet-overschrijfbare waarden vermijden om flexibel, configureerbaar en aanpasbaar te blijven voor zo veel toepassingen als mogelijk. Gebruik bijvoorbeeld vars om te voorkomen dat gebruikers een instelling wijzigen die schade kan veroorzaken of de functionaliteit kan verstoren.

secret_vars

See geheime variabelen

taak

Een Ansible-taak, ook wel gewoon een taak genoemd, is de fundamentele eenheid van actie in Ansible. Het definieert een enkele stap of operatie, zoals het installeren van een pakket, het kopiëren van een bestand, of het herstarten van een service, uitgevoerd met behulp van een Ansible-module. Taken worden typisch georganiseerd binnen een Ansible-rol als onderdeel van een Ansible-collectie, wat modulariteit en hergebruik in automatiseringsworkflows bevordert. Ze kunnen ook direct verschijnen in een playbook, hoewel dit minder gebruikelijk is in gestructureerde projecten zoals die in het C2 Platform.

Zie  details .

Vagrant

Vagrant is een open-source tool ontwikkeld door HashiCorp voor het bouwen, beheren en inrichten van virtuele machine-omgevingen op een herhaalbare en draagbare manier. Het vereenvoudigt de creatie van consistente ontwikkelopstellingen door gebruik te maken van een declaratief configuratiebestand genaamd een Vagrantfile om virtuele machines, netwerken en inrichtingsstappen te definiëren. Vagrant gebruikt voorverpakte Vagrant boxes die afkomstig kunnen zijn van Vagrant Cloud of aangepaste repositories, om draagbaarheid en consistentie over verschillende hostsystemen te garanderen.

In de context van het C2 Platform, met de Open, tenzij aanpak, is Vagrant een belangrijk hulpmiddel binnen de open-source ontwikkelomgeving. Het stelt Ansible engineer in staat om lokaal infrastructuur te simuleren voor het ontwikkelen en testen van Ansible-content ( Ansible-collecties, Ansible-rollen etc.), en Ansible-mirror-inventarisprojecten. Deze Ansible-content wordt vervolgens gedeeld en gepubliceerd op Ansible Galaxy.

Zie  details .

Vagrant box

Een Vagrant box is een verpakte virtuele machine-image die wordt gebruikt door Vagrant om draagbare, reproduceerbare ontwikkelomgevingen te creëren en configureren. Het omvat een basisbesturingssysteem, voorgeïnstalleerde software en configuraties, waardoor gebruikers snel consistente virtuele machines kunnen inrichten voor ontwikkeling en testen. Vagrant boxes kunnen worden gedeeld en gedownload van repositories zoals Vagrant Cloud.

In het C2 Platform worden Vagrant boxes voor Windows (gebaseerd op VirtualBox) en Linux (gebaseerd op LXD) gehost op Vagrant Cloud om lokale ontwikkeling en testen te ondersteunen in Ansible-ontwikkelomgevingen. Dit stelt Ansible engineers in staat om infrastructuur te simuleren voor het ontwikkelen en onderhouden van Ansible-content en Ansible-mirror-inventarisprojecten.

Zie  details .

Vagrant Cloud

Vagrant Cloud is een openbaar, doorzoekbaar register van Vagrant-boxen gehost door HashiCorp. Het stelt gebruikers in staat om te ontdekken, delen en beheren van vooraf geconfigureerde virtuele machine-images voor consistente ontwikkelomgevingen. In het C2 Platform worden daar verschillende boxen gehost, gebaseerd op VirtualBox voor Windows en LXD voor Linux.

Zie  details .

Vagrant-project

Een Vagrant-project is een directorystructuur die Vagrant gebruikt om virtuele ontwikkelomgevingen te definiëren en te beheren, doorgaans inclusief een Vagrantfile voor declaratieve configuratie van virtuele machines, netwerken en provisioning-stappen. In de context van het C2 Platform integreert een Vagrant-project met Ansible-automatisering, zoals binnen een mirror-inventarisproject, om real-world infrastructuur lokaal te simuleren voor het testen van Ansible-content ( Ansible-collecties, Ansible-rollen, etc.) en mirror-inventarisproject. Het bevordert consistentie en herhaalbaarheid in ontwikkelomgevingen, waardoor Ansible engineers automatisering kunnen prototypen en valideren. Deze Ansible-content wordt vervolgens gepubliceerd naar Ansible Galaxy om het gebruik ervan in automatisering mogelijk te maken over Nederlandse overheidsdomeinen en datacenters heen.

Zie  details .

Vagrantfile

Een Vagrantfile is een configuratiebestand gebaseerd op Ruby dat door Vagrant wordt gebruikt om virtuele ontwikkelomgevingen op een declaratieve wijze te definiëren en te beheren. Het specificeert details zoals de provider voor virtuele machines (bijv. VirtualBox, LXD), de basis Vagrant box, netwerkconfiguraties, provisioning-scripts (vaak met integratie van Ansible-playbooks) en gedeelde mappen. In de context van het C2 Platform is het Vagrantfile een sleutelcomponent van een Vagrant-project of Ansible-mirror-inventarisproject, waardoor lokale simulatie van infrastructuur mogelijk is voor het testen van Ansible-content en configuraties als onderdeel van de Ansible-ontwikkelomgeving. Dit bevordert consistentie, herhaalbaarheid en afstemming op het principe van Open, tenzij.

Zie  details .

variable precedence rules

Precedence, ook bekend als variable precedence, verwijst naar regels in Ansible die de volgorde bepalen waarin variabelen uit verschillende bronnen worden toegepast of overschreven. Wanneer dezelfde variabele op meerdere plaatsen is gedefinieerd, zoals play-variabelen, groepsvariabelen of hostvariabelen, volgt Ansible een specifieke voorrang-hiërarchie om te beslissen welke waarde effect heeft. Dit zorgt voor consistent gedrag in automatisering, waarbij bronnen met hogere voorrang lagere bronnen overschrijven. Het begrijpen van voorrang is cruciaal voor het beheren van complexe configuraties in een inventarisproject.