"Done"
This commit is contained in:
parent
a96e2f01b1
commit
ad989ef1ee
37
README.md
37
README.md
|
@ -8,6 +8,7 @@
|
||||||
* De Ansible container
|
* De Ansible container
|
||||||
* Ansible-vault voor opslag secrets
|
* Ansible-vault voor opslag secrets
|
||||||
* Dynamische inventory
|
* Dynamische inventory
|
||||||
|
* Het gebruik van facts
|
||||||
* Playbook roles structuur and handige aliases
|
* Playbook roles structuur and handige aliases
|
||||||
* Container bootstrapping vanuit Ansible
|
* Container bootstrapping vanuit Ansible
|
||||||
* Installatie van het Galera cluster
|
* Installatie van het Galera cluster
|
||||||
|
@ -745,3 +746,39 @@ Hiermee genereren we direct een crypted string en het plain text wachtwoord is
|
||||||
zelfs onbekend, omdat het nergens op het scherm verschijnt. Als je wilt weten
|
zelfs onbekend, omdat het nergens op het scherm verschijnt. Als je wilt weten
|
||||||
welk wachtwoord het is geworden, dan is dat uiteindelijk natuurlijk wel binnen
|
welk wachtwoord het is geworden, dan is dat uiteindelijk natuurlijk wel binnen
|
||||||
Ansible recipes opvraagbaar.
|
Ansible recipes opvraagbaar.
|
||||||
|
|
||||||
|
|
||||||
|
# Dynamische inventory
|
||||||
|
Ansible maakt gebruik van een inventory, waarin alle te beheren hosts, een
|
||||||
|
groepen-indeling en extra attributen voor hosts / groepen zijn oipgenomen.
|
||||||
|
|
||||||
|
Waar we al heel snel tegenaan liepen bij het inrichten van de Ansible omgeving
|
||||||
|
voor het voice platform, was dat de standaard manieren om een inventory in
|
||||||
|
te richten vrij beperkt waren. Bovendien kriebelde steeds het gevoel dat we
|
||||||
|
een laag van abstractie misten, omdat alle gegevens door elkaar in bestanden
|
||||||
|
terecht kwamen, wat het overzicht om zeep hielp.
|
||||||
|
|
||||||
|
De oplossing hiervoor was het implementeren van een dynamische inventory.
|
||||||
|
Het principe is heel simpel: op de plek waar je normaal gesproken het `hosts`
|
||||||
|
bestand voor Ansible neerzet, zet je nu een script neer dat een inventory
|
||||||
|
bestand op STDOUT uitpoept. Hiermee ben je in het script volledig in control
|
||||||
|
voor de manier waarop de inventory wordt gebouwd.
|
||||||
|
|
||||||
|
In het voice platform gebruiken we een aantal losse yaml bestanden (node_types,
|
||||||
|
nodes, networks, lxd, credentials), die elk hun eigen type informatie bevatten
|
||||||
|
en die door het `hosts` script worden gecombineerd tot een inventory met
|
||||||
|
zeer verrijkte host entries.
|
||||||
|
|
||||||
|
Dezelfde strategie kan natuurlijk ook worden gebruikt om de Ansible inventory
|
||||||
|
op te bouwen vanuit een database, een webservice die de data aan kan leveren,
|
||||||
|
etc.
|
||||||
|
|
||||||
|
|
||||||
|
# Het gebruik van facts
|
||||||
|
Simpel: wij gebruiken geen facts in het voice platform.
|
||||||
|
|
||||||
|
Facts zijn leuk, maar het verzamelen van facts voor een Ansible run kost
|
||||||
|
aardig wat tijd (en ik hou niet van wachten). Bovendien suggereert het
|
||||||
|
dat ik de nodes in het platform niet volledig zelf onder controle zou
|
||||||
|
hebben (maar ik ben een control freak).
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue