Started documentation.
This commit is contained in:
parent
0b0a485f19
commit
a799148f63
|
|
@ -0,0 +1 @@
|
|||
**/*.sw*
|
||||
|
|
@ -0,0 +1,494 @@
|
|||
# Mini-omschrijving voice platform
|
||||
|
||||
* 3 hardware LXD hosts, met tig geheugen en tig CPU
|
||||
* verspreid over 3 lokaties
|
||||
* alle applicaties draaien in LXD containers op deze hosts
|
||||
* naasts deze hosts nog een paar SBC clusters, die zorgen
|
||||
voor goede en veilige interconnectie met externe partijen
|
||||
(onze uplink naar het KPN netwerk en alle connecties met
|
||||
de klantapparatuur / softphones)
|
||||
* puppet beheert een stuk van de LXD host configuratie
|
||||
* Ansible beheert andere stukken van de LXD host configuratie,
|
||||
plus alle LXD containers in volledigheid (dus geen 2 kapiteins
|
||||
op 1 schip, maar een strakke verdeling in taken)
|
||||
|
||||
Het op te lossen vraagstuk voor Ansible was vooral: hoe beheren
|
||||
we de LXD containers die op de 3 hardware nodes staan eenvoudig
|
||||
vanuit 1 Ansible omgeving?
|
||||
|
||||
Taken van Ansible:
|
||||
|
||||
* Nieuwe LXD containers optrekken indien nodig (one-shot runs)
|
||||
* Alle LXD containers en LXD hosts configureren (one-shot runs)
|
||||
* Onderhoudstaken op regelmatige basis (periodieke runs in cron)
|
||||
|
||||
|
||||
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
|
||||
- Ubuntu 18.04 LTS
|
||||
|
||||
Na installatie:
|
||||
|
||||
sidn-demo-0X# apt update && apt upgrade -y
|
||||
|
||||
|
||||
LXD snap versie installeren
|
||||
===========================
|
||||
|
||||
Standaard gebruikt 18.04 een apt-package voor LXD.
|
||||
Deze is prima bruikbaar, maar voor een meer up-to-date feature set
|
||||
is het beter om de snap installatie te gebruiken. Snap is op dit moment
|
||||
de aanbevolen method voor het draaien van LXD.
|
||||
|
||||
sidn-demo-0X# snap refresh
|
||||
sidn-demo-0X# snap install lxd
|
||||
sidn-demo-0X# lxd.migrate ("no" voor automatisch verwijderen LXD)
|
||||
sidn-demo-0X# apt remove --purge lxd lxd-client (want zo zie ik wel hoe ver deze is)
|
||||
|
||||
|
||||
LXD initialiseren
|
||||
=================
|
||||
|
||||
Voor deze demo:
|
||||
|
||||
sidn-demo-0X# lxd init
|
||||
> clustering: no
|
||||
> storage pool: yes, default, dir
|
||||
> connect to MAAS: no
|
||||
> network bridge: no
|
||||
> available over the network: yes, all interfaces, port 8443, password
|
||||
|
||||
Op productie doen we het (uiteraard) anders:
|
||||
|
||||
- ZFS als filesystem
|
||||
- "Available over network" alleen op een private space mgmt VLAN
|
||||
|
||||
|
||||
Netwerk volledig op basis van LXD host bridges
|
||||
==============================================
|
||||
|
||||
Belangrijkste keuze qua netwerk: elk netwerk interface in de LXD host
|
||||
is ondergebracht in een bridge interface. Voordeel is dat elke LXD
|
||||
container daarmee "ingeplugd" kan worden op alle ontsloten netwerken.
|
||||
Twee LXD containers op twee verschillende hosts die in eenzelfde
|
||||
bridge netwerk zitten, kunnen simpel op layer 2 bij elkaar.
|
||||
|
||||
** Dit lijkt dus op hoe je het met hardware switches zou regelen**
|
||||
|
||||
Daarom wordt tijdens lxd init niet automatisch een bridge aangemaakt.
|
||||
Je kunt natuurlijk de standaard lxdbr0 bridge maken en gebruiken,
|
||||
maar dat netwerk is alleen voor intern gebruik binnen de host.
|
||||
In een multi-host setup zou je netwerk-trucs moeten uithalen om
|
||||
te zorgen dat hosts bij elkaar kunnen komen.
|
||||
|
||||
Netplan-config op productie ziet er ongeveer zo uit:
|
||||
|
||||
network:
|
||||
version: 2
|
||||
ethernets:
|
||||
eno1: {} # management network (untagged)
|
||||
eno2: {} # SIP network (SIP signalling & services, tagged)
|
||||
eno3: {} # public interface (untagged)
|
||||
vlans:
|
||||
# SIP core: proxy & SBC signalling
|
||||
vlan.6
|
||||
id: 6
|
||||
link: eno2
|
||||
# SIP applications (voicemail, mediaserver, class5 services)
|
||||
vlan.9
|
||||
id: 9
|
||||
link: eno2
|
||||
bridges:
|
||||
br-mgmt:
|
||||
dhcp4: no
|
||||
dhcp6: no
|
||||
interfaces: ["eno1"]
|
||||
addresses: ["172.17.4.10/24"]
|
||||
br-public:
|
||||
dhcp4: no
|
||||
dhcp6: no
|
||||
interfaces: ["eno3"]
|
||||
gateway4: 194.109.16.129
|
||||
addresses: ["194.109.16.132/26"]
|
||||
nameservers:
|
||||
addresses: ["194.109.6.66", "194.109.9.99"]
|
||||
br-sipcore:
|
||||
dhcp4: no
|
||||
dhcp6: no
|
||||
interfaces: ["vlan.6"]
|
||||
addresses: ["10.160.64.132/24"]
|
||||
br-sipapp:
|
||||
dhcp4: no
|
||||
dhcp6: no
|
||||
interfaces: ["vlan.9"]
|
||||
addresses: ["10.116.1.132/24"]
|
||||
|
||||
Met een dergelijke setup is het heel eenvoudig om de LXD containers
|
||||
beschikbaar te maken binnen bepaalde netwerksegmenten. De containers kunnen
|
||||
een of meer netwerk interfaces krijgen, die verbonden kunnen worden met de
|
||||
benodigde netwerken. Dat zien er dan bijvoorbeeld zo uit (afwijkende
|
||||
bridge-namen ivm de ruimte):
|
||||
|
||||
GATEWAY
|
||||
|
|
||||
|
|
||||
+-------------------------+------+----------public--+
|
||||
| | |
|
||||
| +-------------------------+----------SIP------------+
|
||||
| | | | | |
|
||||
| | +-------------------------+---mgmt------------------+
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
+---O------O------O----+ +---O------O------O----+ +---O------O------O----+
|
||||
| eno3 eno2 eno1 | | eno3 eno2 eno1 | | eno3 eno2 eno1 |
|
||||
| | | | | | | | | | | | | | |
|
||||
| | | | | | | | | | | | | | |
|
||||
| br3 br2 br1 | | br3 br2 br1 | | br3 br2 br1 |
|
||||
| | | \ | | | | | | | | | |
|
||||
| | | | | | | \ | | | | | |
|
||||
| CONTAINER1 | | | | `--CONTAINER3 | | | CONTAINER4 |
|
||||
| | | | | | | | |
|
||||
| CONTAINER2 | | | | CONTAINER5 |
|
||||
| | | | | |
|
||||
+----------------------+ +----------------------+ +----------------------+
|
||||
LXD Host 1 LXD Host 2 LXD Host 3
|
||||
|
||||
|
||||
Voor de demo gebruiken we een simpeler opzet:
|
||||
|
||||
network:
|
||||
version: 2
|
||||
ethernets:
|
||||
enp1s0: {}
|
||||
bridges:
|
||||
br-demo:
|
||||
dhcp4: no
|
||||
dhcp6: no
|
||||
interfaces: ["enp1s0"]
|
||||
addresses: ["192.168.56.150/24"] # of 151 voor sidn-demo-02
|
||||
gateway4: "192.168.56.1"
|
||||
nameservers:
|
||||
addresses: ["192.168.56.1"]
|
||||
|
||||
Dus maar 1 bridge en het "fysieke" interface enp1s0 van de VM zit
|
||||
"ingeplugd" in deze bridge. In een plaatje:
|
||||
|
||||
KVM host
|
||||
192.168.56.1 (gateway + DHCP + DNS)
|
||||
|
|
||||
|
|
||||
+------192.168.56.0/24----+
|
||||
| |
|
||||
+------O---------------+ +------O---------------+
|
||||
| enp1s0 | | enp1s0 |
|
||||
| | | | | |
|
||||
| +---O------------+ | | +---O------------+ |
|
||||
| | br-demo | | | | br-demo | |
|
||||
| | 192.168.56.150 | | | | 192.168.56.151 | |
|
||||
| +--O---O---------+ | | +--O--O----------+ |
|
||||
| | | | | | | |
|
||||
| | CONTAINER2 | | | CONTAINER4 |
|
||||
| | | | | |
|
||||
| CONTAINER1 | | CONTAINER3 |
|
||||
| | | |
|
||||
+----------------------+ +----------------------+
|
||||
KVM guest: sidn-demo-01 KVM guest: sidn-demo-02
|
||||
|
||||
|
||||
Netwerkinterfaces op LXD containers
|
||||
===================================
|
||||
|
||||
Met bovenstaande setup is het dus mogelijk om een LXD container netwerk
|
||||
interfaces te geven die "ingeplugd" worden in een of meer van de br-* bridge
|
||||
interfaces. Een SIPproxy server bijvoorbeeld, krijgt drie netwerk interfaces
|
||||
in drie verschillende bridges:
|
||||
|
||||
- br-mgmt: voor host management, o.a. Ansible aansturing
|
||||
- br-public: op een SIPproxy voor SSH toegang en OS updates
|
||||
- br-sipcore: voor SIP signalling verkeer richting SBC's
|
||||
|
||||
Om op een container eenvoudig het doel voor de verschillende interfaces te
|
||||
herkennen, wordt in de naamgeving de bridge-naamgeving gevolgd. Een interface
|
||||
dat in "br-public" wordt geplugd heet bijvoorbeeld "if-public". Veel handiger
|
||||
dan "eth0" o.i.d.
|
||||
|
||||
Om bij het optrekken van een LXD container de benodigde netwerk interfaces
|
||||
aan te maken, wordt gebruik gemaakt van profielen. Er zijn verschillende
|
||||
profielen gemaakt voor verschillende netwerkbehoeftes:
|
||||
|
||||
# lxc profile list
|
||||
+---------------+---------+
|
||||
| NAME | USED BY |
|
||||
+---------------+---------+
|
||||
| ansible-acc | 1 |
|
||||
+---------------+---------+
|
||||
| default | 11 |
|
||||
+---------------+---------+
|
||||
| sipproxy | 2 |
|
||||
+---------------+---------+
|
||||
| voicemail | 2 |
|
||||
+---------------+---------+
|
||||
| voiceservices | 2 |
|
||||
+---------------+---------+
|
||||
|
||||
Hier het stuk van het profiel wat voor het bovenstaande SIPproxy netwerk wordt gebruikt.
|
||||
|
||||
productie# lxc profile show sipproxy
|
||||
config:
|
||||
---8<-------
|
||||
devices:
|
||||
if-mgmt:
|
||||
name: if-mgmt
|
||||
nictype: bridged
|
||||
parent: br-mgmt
|
||||
type: nic
|
||||
if-public:
|
||||
name: if-public
|
||||
nictype: bridged
|
||||
parent: br-public
|
||||
type: nic
|
||||
if-sipcore:
|
||||
name: if-sipcore
|
||||
nictype: bridged
|
||||
parent: br-sipcore
|
||||
type: nic
|
||||
---8<-------
|
||||
|
||||
|
||||
Noot:
|
||||
Voor het voice platform is dit een handige setup. Uiteraard kan elke mogelijk
|
||||
setup worden gemaakt op basis van de behoefte. Als de behoefte alleen maar
|
||||
een lokaal werkende bridge met private IP space was, dan zou ik het geheel nog
|
||||
steeds wel handmatig inrichten zoals hierboven, alleen dan met een loopback
|
||||
bridge met een naam als "br-local".
|
||||
|
||||
|
||||
Voorbeeldprofiel voor de demo
|
||||
=============================
|
||||
|
||||
Op basis van de gevolgde lxd init methode, is er een default profiel aangemaakt
|
||||
voor LXD. Deze is heel erg basaal, omdat we geen netwerk hebben geconfigureerd:
|
||||
|
||||
sidn-demo-0X# lxc profile show default
|
||||
config: {}
|
||||
description: Default LXD profile
|
||||
devices:
|
||||
root:
|
||||
path: /
|
||||
pool: default
|
||||
type: disk
|
||||
|
||||
name: default
|
||||
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.
|
||||
|
||||
sidn-demo-0X# lxc profile create demo
|
||||
sidn-demo-0X# lxc profile edit demo
|
||||
|
||||
config:
|
||||
user.user-data: |
|
||||
# cloud-config
|
||||
package_upgrade: true
|
||||
packages:
|
||||
- python3
|
||||
timezone: Europe/Amsterdam
|
||||
description: SIDN demo profile
|
||||
devices:
|
||||
if-demo:
|
||||
name: if-demo
|
||||
nictype: bridged
|
||||
parent: br-demo
|
||||
type: nic
|
||||
root:
|
||||
path: /
|
||||
pool: default
|
||||
type: disk
|
||||
|
||||
sidn-demo-0X# lxc profile show demo
|
||||
|
||||
In deze config zijn wat cloud-init statements toegevoegd om te laten zien dat
|
||||
cloud-init te gebruiken is in een profiel. De installatie van Python is handig,
|
||||
omdat daarmee de container klaar is voor Ansible. Echter, in het voice platform
|
||||
wordt dit niet zo gedaan. Daar worden wat bootstrapping Ansible recipes gebruikt
|
||||
om Python op een vers systeem te krijgen. Voordeel is dat de Ansible-methode
|
||||
ook voor oudere versies van Ubuntu en voor niet cloud-init images te gebruiken is.
|
||||
|
||||
Noot:
|
||||
In de praktijk hebben wij tot op heden alleen maar timezone en netwerkconfiguratie
|
||||
gepusht met de cloud-init configuratie. En zelfs de netwerkconfguratie slechts
|
||||
deels, omdat deze met de cloud-init van Ubuntu 14.04 nog niet mogelijk was.
|
||||
|
||||
|
||||
Geen LXD clustering
|
||||
===================
|
||||
|
||||
Het klinkt heel goed: LXD clustering. Functioneel heb ik er echter nog
|
||||
weinig nuttigs in gevonden voor onze setup. Bovendien heb ik op clustersystemen
|
||||
regelmatig problemen gezien met het goed werkend houden van het cluster,
|
||||
door het uit sync raken van de quorum database bijvoorbeeld.
|
||||
|
||||
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.
|
||||
Daarna krijg je met bijvoorbeeld "lxc list" geen inzicht in de containers die
|
||||
op de lokale host draaien, maar inzicht in alle containers die op alle hosts
|
||||
draaien.
|
||||
|
||||
Voordat clustering bestond in LXD liepen wel al wel tegen het probleem aan
|
||||
wat clustering probeert op te lossen: containers verspreid over meerdere hosts.
|
||||
Onze aanpak:
|
||||
|
||||
- De LXD daemon kan luisteren op het netwerk (zoals hierboven aangezet)
|
||||
- Je kunt vanuit de ene LXD host een andere LXD host als "remote" toevoegen
|
||||
onder een bepaalde naam.
|
||||
- Vanaf dan kunnen lxc commando's de naam van de remote gebruiken om
|
||||
operaties op de andere host te doen.
|
||||
- We hebben alle LXD hosts op deze manier kruislings gekoppeld, zodat vanuit
|
||||
elke host elke andere host aangesproken kan worden.
|
||||
|
||||
Zorg eerst dat alle LXD hosts remote access actief hebben, mocht dat nog
|
||||
niet geconfigureerd zijn vanuit lxd init. Doe het volgende op elke host:
|
||||
|
||||
sidn-demo-0X# lxc config set core.https_address [::]:8443
|
||||
sidn-demo-0X# lxc config set core.trust_password SuperGeheimGoedWachtwoordHorseStaple
|
||||
|
||||
Nu kunnen de remotes op elke LXD host worden aangemaakt.
|
||||
Merk op dat we ook voor de lokale LXD daemon een remote aanmaken.
|
||||
Dat maakt een aantal zaken vanuit Ansible een stuk simpeler.
|
||||
Als wachtwoord gebruiken we uiteraard het bovenstaande wachtwoord.
|
||||
|
||||
sidn-demo-0X# lxc remote add --accept-certificate sidn-demo-01 192.168.56.150
|
||||
sidn-demo-0X# lxc remote add --accept-certificate sidn-demo-02 192.168.56.151
|
||||
|
||||
Vanaf nu kun je vanaf elk van de twee LXD hosts commando's uitvoeren
|
||||
op alle LXD hosts, bijv:
|
||||
|
||||
sidn-demo-0X# lxc list -cns sidn-demo-01:
|
||||
sidn-demo-0X# lxc list -cns sidn-demo-02:
|
||||
sidn-demo-0X# lxc launch ubuntu:18.04 sidn-demo-02:test
|
||||
|
||||
|
||||
Een eerste container: Ansible management host
|
||||
=============================================
|
||||
|
||||
De Ansible management host is een container op het voice platform zelf. Vanwege de
|
||||
kip/ei problematiek en het feit dat deze container niet steeds opnieuw gebouwd
|
||||
gaat worden, bootstrappen we deze container met de hand.
|
||||
|
||||
De handigste manier voor de netwerkconfiguratie van deze container is gebruik
|
||||
maken van een user.network-config.
|
||||
|
||||
sidn-demo-01# vi /tmp/config
|
||||
|
||||
version: 1
|
||||
config:
|
||||
- type: physical
|
||||
name: if-demo
|
||||
subnets:
|
||||
- type: static
|
||||
address: 192.168.56.160
|
||||
netmask: 255.255.255.0
|
||||
gateway: 192.168.56.1
|
||||
dns_nameservers: [192.168.56.1] # zodat dezelfde resolving als de KVM host wordt gebruikt
|
||||
|
||||
Bouw de container op en start hem:
|
||||
|
||||
sidn-demo-01# H=ansible
|
||||
sidn-demo-01# lxc init --storage default --no-profiles ubuntu:18.04 $H
|
||||
sidn-demo-01# lxc config device add $H if-demo nic name=if-demo nictype=bridged parent=br-demo
|
||||
sidn-demo-01# lxc config set $H volatile.if-demo.hwaddr 00:16:3e:00:00:a0 # mainly for VirtualBox
|
||||
sidn-demo-01# lxc config set $H user.network-config - < /tmp/config
|
||||
|
||||
sidn-demo-01# lxc config show $H
|
||||
sidn-demo-01# lxc start $H
|
||||
sidn-demo-01# lxc exec $H bash
|
||||
|
||||
ansible# apt update && apt upgrade -y && apt autoclean -y && apt autoremove -y
|
||||
|
||||
Noot:
|
||||
Voor deze setup zou ook het eerder aangemaakte "demo" profiel gebruikt kunnen
|
||||
worden. Echter, op het voice platform doen we het op deze manier, omdat we
|
||||
de profielen vanuit Ansible opzetten en het benodigde profiel daarom niet
|
||||
noodzakelijkerwijs al bestaat op de LXD host.
|
||||
|
||||
Op de container is nu te zien dat het layer 2 netwerk bereikbaar is
|
||||
vanuit de container:
|
||||
|
||||
ansible# ip a (laat zien dat er nu een if-demo interface bestaat)
|
||||
ansible# ping 192.168.56.150 (een ping naar de eigen LXD host)
|
||||
ansible# ping 192.168.56.151 (een ping naar de andere LXD host)
|
||||
|
||||
|
||||
Connectie Ansible -> managed hosts
|
||||
==================================
|
||||
|
||||
Even een uitstapje naar de manier waarop we vanuit Ansible verbinding
|
||||
gaan maken naar de LXD hosts en de LXD containers, voor het uitvoeren
|
||||
van de nodige commando's.
|
||||
|
||||
In Ansible zit support voor het gebruik van lxc in plaats van ssh voor
|
||||
het verbinden met de te configureren hosts. Aanvankelijk zijn we daar
|
||||
100% voor gegaan, maar helaas bleek dat dit een behoorlijke impact op
|
||||
de snelheid heeft. Met een SSH koppeling, kan de SSH verbinding open
|
||||
worden gehouden en kunnen commando's in rap tempo's naar een host worden
|
||||
gestuurd. De lxc connector _doet dit helemaal niet_. Voor elk commando
|
||||
wordt een nieuwe connectie opgezet.
|
||||
|
||||
Om de zaken te versnellen, gebruiken we nu een hybride setup:
|
||||
|
||||
- Management van de LXD hosts wordt volledig met SSH gedaan vanuit
|
||||
de Ansible container.
|
||||
|
||||
- Het bootstrappen van nieuwe containers wordt gedaan door met SSH
|
||||
naar een LXD host te gaan (delegate), en vervolgens worden van
|
||||
daaruit (met de hierboven geconfigureerde remotes) met lxc
|
||||
connecties de containers opgetrokken en geconfigureerd tot het
|
||||
niveau dat de Ansible container er met SSH bij kan.
|
||||
|
||||
- Het verder configureren van containers wordt volledig met SSH
|
||||
gedaan, direct vanuit de Ansible container.
|
||||
|
||||
|
||||
Ansible SSH toegang Ansible -> LXD hosts
|
||||
============================================
|
||||
|
||||
Om de LXD hosts te kunnen beheren met SSH, is het nodig dat er een SSH key
|
||||
wordt gegenereerd en dat deze naar de hosts wordt gekopieerd.
|
||||
|
||||
ansible# ssh-keygen -b 2048 -N '' -f /root/.ssh/id_rsa
|
||||
|
||||
sidn-demo-0X# mkdir -p /root/.ssh
|
||||
sidn-demo-0X# chmod 700 /root/.ssh
|
||||
sidn-demo-0X# touch /root/.ssh/authorized_keys
|
||||
sidn-demo-0X# chmod 600 /root/.ssh/authorized_keys
|
||||
sidn-demo-0X# lxc exec sidn-demo-01:ansible cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
|
||||
|
||||
Hierna moet het volgende werken:
|
||||
|
||||
ansible# ssh 192.168.56.150 touch .hushlogin
|
||||
ansible# ssh 192.168.56.151 touch .hushlogin
|
||||
|
||||
|
||||
Installatie van de Ansible software
|
||||
===================================
|
||||
|
||||
De basis infrastructuur staat. Nu kan de benodigde software op de
|
||||
Ansible host worden geïnstalleerd.
|
||||
Op het voiceplatform wordt overal gebruik gemaakt van Python3 voor Ansible.
|
||||
|
||||
ansible# apt install -y python3 python3-pip
|
||||
ansible# pip3 install ansible
|
||||
|
||||
The Ansible configuration is managed in a git repository. Go get!
|
||||
|
||||
ansible# apt install -y git
|
||||
ansible# REPO=https://git.makaay.nl/mauricem/sidn-lxd-ansible-demo.git
|
||||
ansible# git clone $REPO /etc/ansible
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue