Merge branch 'master' of https://git.makaay.nl/mauricem/sidn-lxd-ansible-demo
This commit is contained in:
commit
0a60c5ff9b
138
README.md
138
README.md
|
@ -4,10 +4,11 @@
|
|||
* Doel van de demo: LXD + Ansible + Galera cluster
|
||||
* Installatie VM's voor de demo
|
||||
* Netwerktopologie
|
||||
* LXD clustering
|
||||
* LXD clustering vs LXD remotes
|
||||
* De Ansible container
|
||||
* Ansible-vault voor opslag secrets
|
||||
* Dynamische inventory
|
||||
* Het gebruik van facts
|
||||
* Playbook roles structuur and handige aliases
|
||||
* Container bootstrapping vanuit Ansible
|
||||
* Installatie van het Galera cluster
|
||||
|
@ -65,9 +66,39 @@ maar die kunnen zonder blikken of blozen naar de slachtbank.
|
|||
|
||||
# Installatie VM's voor de demo
|
||||
* 2 VM's: sidn-demo-01, sidn-demo-02
|
||||
* virtual machine met NAT netwerk: 192.168.56.0/24, gateway/DNS 192.168.56.1
|
||||
* virtual machine met 2 KVM netwerken gekoppeld:
|
||||
* NAT netwerk: 192.168.56.0/24, gateway/DNS 192.168.56.1
|
||||
* Host-only netwerk: 10.0.0.0/24
|
||||
* Ubuntu 18.04 LTS
|
||||
|
||||
#### Host-only netwerk
|
||||
|
||||
Het NAT netwerk is standaard beschikbaar, maar het host-only netwerk moest ik
|
||||
nog met de hand aanmaken.
|
||||
|
||||
```text
|
||||
# sudo apt-get install bridge-utils
|
||||
# vi /etc/network/interfaces (onderstaande daaraan toegevoegd)
|
||||
|
||||
auto br-host
|
||||
iface br-host inet static
|
||||
address 10.0.0.1
|
||||
netmask 255.255.255.0
|
||||
pre-up brctl addbr br-host
|
||||
post-down brctl delbr br-host
|
||||
|
||||
# echo '<network><name>host-only</name><bridge name="bg-host" /></network>' > /tmp/net.xml
|
||||
# virsh net-define /tmp/net.xml
|
||||
# virsh net-start host-only
|
||||
# virsh net-autostart host-only
|
||||
|
||||
# virsh net-list --all (om te controleren of het er goed uitziet)
|
||||
Name State Autostart Persistent
|
||||
------------------------------------------------
|
||||
nat active yes yes
|
||||
host-only active yes yes
|
||||
```
|
||||
|
||||
#### Upgrade na installatie
|
||||
|
||||
```text
|
||||
|
@ -349,7 +380,7 @@ steeds wel handmatig inrichten zoals hierboven, alleen dan met een loopback
|
|||
bridge met een duidelijk naam als "br-local" of "br-private".
|
||||
|
||||
|
||||
#### Aanmaken LXD profile voor de demo
|
||||
#### Gebruik van LXD profiles voor de netwerk device configuratie
|
||||
|
||||
Op basis van de gevolgde lxd init methode, is er al een default profiel aangemaakt
|
||||
voor LXD. Deze is heel erg basaal, omdat we geen netwerk bridge hebben geconfigureerd:
|
||||
|
@ -370,7 +401,8 @@ used_by: []
|
|||
```
|
||||
|
||||
Het beheer van profielen regelen we primair vanuit Ansible, maar op dit punt
|
||||
van de demo maak ik met de hand een profiel aan.
|
||||
van de demo maak ik met de hand een profiel aan, om te laten zien wat
|
||||
Ansible hier onder water doet.
|
||||
|
||||
```text
|
||||
sidn-demo-0X# lxc profile create demo
|
||||
|
@ -416,9 +448,8 @@ gepusht met de cloud-init configuratie. En zelfs de netwerkconfguratie slechts
|
|||
deels, omdat demodeze met de cloud-init van Ubuntu 14.04 nog niet mogelijk was.
|
||||
|
||||
|
||||
|
||||
# LXD clustering
|
||||
Of beter gezegd: __geen__ LXD clustering.
|
||||
# LXD clustering vs LXD remotes
|
||||
Wij gebruiken __geen__ LXD clustering.
|
||||
|
||||
Een cluster zorgt er voornamelijk voor dat je een aantal LXD hosts aan elkaar
|
||||
koppelt, die onderling gaan uitwisselen welke containers er op de hosts draaien.
|
||||
|
@ -659,14 +690,95 @@ jinja2_extensions = jinja2.ext.do
|
|||
pipelining = True
|
||||
```
|
||||
|
||||
De vault_password_file wordt gebruikt als password file voor Ansible vault.
|
||||
Met vault is het mogelijk om geheime informatie (normaliter: wachtwoorden)
|
||||
op te slaan in gecrypte vorm. Het te gebruiken symmetrische wachtwoord is
|
||||
opgeslagen in de password file. Bijvoorbeeld:
|
||||
# Ansible vault voor opslag secrets
|
||||
|
||||
De bovengenoemde `vault_password_file` wordt gebruikt als password file voor
|
||||
Ansible vault. Met vault is het mogelijk om geheime informatie (normaliter: wachtwoorden)
|
||||
op te slaan in gecrypte vorm. Het te gebruiken symmetrische wachtwoord is opgeslagen in
|
||||
de password file.
|
||||
|
||||
Bijvoorbeeld:
|
||||
|
||||
```text
|
||||
ansible# echo "My very secret 1337 super passw0rd##" \
|
||||
> /root/.ansible-vault-password
|
||||
ansible# echo -n "My very secret 1337 super passw0rd##" > /root/.ansible-vault-password
|
||||
ansible# chmod 600 /root/.ansible-vault-password
|
||||
```
|
||||
Hierna is het mogelijk om met het `ansible-vault` commando bestanden of losse strings
|
||||
te encrypten. Ansible herkent automatisch dit soort crypted informatie bij het lezen
|
||||
van de recipe yaml bestanden en decrypt ze automatisch voor gebruik in een run.
|
||||
|
||||
Wij maken alleen gebruik van de losse string encryptie op de volgende manier:
|
||||
|
||||
```text
|
||||
# ansible-vault encrypt_string 'SECRET!'
|
||||
Reading plaintext input from stdin. (ctrl-d to end input)
|
||||
!vault |
|
||||
$ANSIBLE_VAULT;1.1;AES256
|
||||
64663430316333633466353834343736333634666137653034323538316536376435616339313539
|
||||
3536373866656238393031663665353364346530313933610a616233386234323363346266643262
|
||||
37613963346134313461396130643939353037323835383132663864636266623736393361393636
|
||||
3533613531353763610a303633323961366361333165393339343464336335653162663963393837
|
||||
646
|
||||
```
|
||||
|
||||
De complete string vanaf `!vault ...` kun je in een yaml value plakken, bijv:
|
||||
|
||||
```yaml
|
||||
---
|
||||
user:
|
||||
username: john
|
||||
password: !vault |
|
||||
$ANSIBLE_VAULT;1.1;AES256
|
||||
64663430316333633466353834343736333634666137653034323538316536376435616339313539
|
||||
3536373866656238393031663665353364346530313933610a616233386234323363346266643262
|
||||
37613963346134313461396130643939353037323835383132663864636266623736393361393636
|
||||
3533613531353763610a303633323961366361333165393339343464336335653162663963393837
|
||||
646
|
||||
```
|
||||
|
||||
Om wachtwoorden te genereren voor onze systemen, gebruiken we pwgen op deze manier:
|
||||
|
||||
```text
|
||||
# ansible-vault encrypt_string $(pwgen 32 -c -n -1)
|
||||
```
|
||||
|
||||
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
|
||||
welk wachtwoord het is geworden, dan is dat uiteindelijk natuurlijk wel binnen
|
||||
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