Merge branch 'master' of https://git.makaay.nl/mauricem/sidn-lxd-ansible-demo

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 vs LXD remotes
-# LXD clustering
+Wij gebruiken __geen__ LXD clustering.
-Of beter gezegd: __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.
+# Ansible vault voor opslag secrets
-Met vault is het mogelijk om geheime informatie (normaliter: wachtwoorden)
+
-op te slaan in gecrypte vorm. Het te gebruiken symmetrische wachtwoord is
+De bovengenoemde `vault_password_file` wordt gebruikt als password file voor
-opgeslagen in de password file. Bijvoorbeeld:
+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##" \
+ansible# echo -n "My very secret 1337 super passw0rd##" > /root/.ansible-vault-password
-    > /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).