Commit 09051e93 authored by k.elaammari's avatar k.elaammari
Browse files

Todo, Readme

parent 95cc1a94
......@@ -22,7 +22,9 @@ Um diesen Workflow ausführen zu können müssen die folgenden Programme install
Im Weiteren wird vorausgesetzt, dass Sie sich auf einem Linux basierten Betriebssystem befinden. Der Workflow funktioniert auch auf Windows, hierbei ist aber zu beachten, dass unter Windows standardmäßig Zeilenumbrüche mit CR & LF kodiert werden. Im Gegensatz zum einfachen LF Zeilenumbruch unter Linux. Da die Dateien mit dem File-Provisionierer übertragen werden, muss darauf geachtet werden, dass die Dateien mit einem einfachen LF gespeichert werden. In der Git-Konfiguration sollte demensprechend folgende Funktion abgeschaltet werden.
```$ git config --global core.autocrlf false```
```
$ git config --global core.autocrlf false
```
Diese ist normalerweise unter Windows eingeschaltet und ersetzt beim auschecken ein LF mit einem CRLF.
......@@ -35,7 +37,7 @@ Um direkt zu starten, kopieren Sie mit folgendem Befehl das Projekt auf ihren Re
git clone git@git.gsi.de:k.elaammari/monitorsetup.git
```
Bevor die VMs gestartet werden, müssen die nötigen X509-Zertifikate erzeugt werden. Hierfür führen Sie folgenden Befehl aus.
Bevor die VMs gestartet werden, müssen die nötigen TLS-Zertifikate erzeugt werden. Hierfür führen Sie folgenden Befehl aus.
```shell
./scripts/openssl_generate.sh
......@@ -66,7 +68,7 @@ Nachdem die Maschinen gestartet und die Provisionierung korrekt ausgeführt wurd
Wenn auf ihrem Betriebssystem diese Ports schon in Verwendung sind, können Sie in der Vagrantfile eine andere Zuordnung konfigurieren.
Da die Dienste Grafana und Chronograf ein signiertes X509-Zertifikat besitzen, können Sie ihrem Browser das unter ```./openssl/data/certificates/cacert.pem``` gespeicherte Root-Zertifikat als Zertifizierungsstelle eintragen, um Warnungen und mögliche Zweifel beim Aufruf der Seiten zu vermeiden. Und mit folgendem Befehl können Sie die Fingerprints der erzeugen Zertifikate anzeigen lassen, um Sie beim Hinzufügen zu verifizieren.
Da die Dienste Grafana und Chronograf ein signiertes TLS-Zertifikat besitzen, können Sie ihrem Browser das unter ```./openssl/data/certificates/cacert.pem``` gespeicherte Root-Zertifikat als Zertifizierungsstelle eintragen, um Warnungen und mögliche Zweifel beim Aufruf der Seiten zu vermeiden. Und mit folgendem Befehl können Sie die Fingerprints der erzeugen Zertifikate anzeigen lassen, um Sie beim Hinzufügen zu verifizieren.
```shell
./scripts/openssl_fingerprint.sh
......
9.8.19
Test: prometheus without daemon-reload
# Dokumentation
## Openssl
Um den Datenverkehr zu verschlüsseln und die Dienste authentifizieren zu können, benötigen wir TLS-Zertifikat die wir dem Openssl-Toolkit erzeugen. ( https://www.openssl.org/ ) Hierfür wird zuerst ein Root-Zertifikat (cacert.pem) erzeugt und anschließend die Zertifikate für die Dienste Grafana, Influx und Chronograf. Diese werden von dem Root-Zertifikat signiert, sodass mit dem Root-Zertifikat die Authentifizierung erfolgen kann. Wichtig zu beachten ist, dass zu jedem Zertifikat auch ein Private-Key existiert, z.B. cacert.pem und cakey.pem oder influxcert.pem und influxkey.pem.
### Struktur
```
./openssl
./config
./data
./certificates
./csrdb
```
Im Config Verzeichnis befinden sich die Konfigurationsdateien für die Zertifikate und das Data Verzeichnis wird erst nachdem ausführen von ```./scripts/openssl_generate.sh``` erstellt. Data enthält die Zertifikate im Ordner certificates sowie den Zustand der Openssl-Textdatenbank im Ordner csrdb die für das Signieren gebraucht wird.
### Zertifikat-Seriennummer und neu erzeugung
Todo
### Private-Key verloren
Wenn ein Private-Key auf irgendeine Art an Dritte verloren gegangen ist, müssen Sie reagieren. In diesem Fall ist zu unterscheiden, ob es der cakey.pem, also der Root-Key oder der Key eines Dienstes wie grafanakey.pem ist.
1. Root-Key: In diesem Fall müssen alle Zertifikate neu erzeugt werden. Zusätzlich müssen sie jeden informieren, dem Root-Zertifikat cacert.pem das Vertrauen zu entziehen. Da durch den Verlust des Private-Keys belibig erzeugte Zertifikate mit cakey.pem Signiert werden können, welche dann vom aktuellen cacert.pem als gültig verifiziert werden würden. Führen Sie ```./scripts/openssl_generate.sh``` neu aus und verteilen die Zertifikate mit dem vagrant provisionierer neu auf die Maschinen.
### Manuelles verteilen der Zertifikate
Todo
## Dateistruktur des Projekts
### Klassifizierung von Dateien
Um eine überschaubare Umgebung zu schaffen wird versucht die hier verwendeten Daten und Dateien in in drei Kathegorien zu unterteilt.
#### 1. Executable:
In die Kategorie Executable fallen alle Binären oder Ausführbaren Dateien. In unserem Fall werden alle Programme von den jeweiligen Paketmanagern installiert. Nur Skripte wie z.B. die für den Backup- und Restore-Workflow werden per File-Provisionierer kopiert. Unit-files und -timer, gehören in diesem Projekt, auch in die Kategorie Executable.
#### 2. Konfigurations-Daten:
Dateien die beim Start der Executables zur Konfiguration benötigt werden, wie z.B. Ini- und Conf-files.
#### 3. Benutzer-Daten:
Hiermit sind alle Daten die bei Inbetriebnahme und während dem Betrieb entstehen gemeint. Im Projektverzechniss enthalten folgende Ordner Benutzerdaten:
```
.vagrant-prometheus/
./backup
./openssl/data
```
Weiter Benutzerdaten befinden sich auf den VMs.
* Chronograf:
```
/var/lib/chronograf/chronograf-v1.db
```
Chronograf speichert hier in einer Datenbank die übers das Web-Interface eingegebenen Daten.
* Grafana:
```
/var/lib/grafana/
./grafana.db
./token/apitoken.json
```
Grafana speichert auch seinen Zustand in einer sqlite3 Datenbank. Und der aktuellen Bearer Token für die HTTP-API wird hier abgelegt.
* Influxdb:
```
/var/lib/influxdb/
./data
./meta
./wal
```
Im Data- und Wal-Verzeichnis speichert Influx die Datenbanken, '_internal' und 'prom'. WAL steht für Write-ahead-log und enthält somit Daten, die nachträglich in das Data-Verzechnis übertragen werden.
* Prometheus:
```
/var/lib/prometheus/data
```
Prometheus speichet hier die gesammelten Daten zwischen, da die Daten aber direkt in die Influx-Datenbank weitergeleitet werden, gibt es hier keinen Backup- und Restore-Workflow.
## Aufbau
Die Monitoring-Infrastruktur besteht im Kern aus vier Server: Grafana, Influx, Prometheus und Chronograf. Wobei Chronograf kein Integraler Bestandteil von diesem Workflow ist und nur für die graphische Administrierung von InfluxDB eingesetzt wird. Zusätzlich sind zu Demonstratonszwecken in diesem Workflow noch 10 Debian Nodes konfiguriert, die seperat getartet werden können.
Die Pfeile zwischen den Servern, stellen da Wer
Die Kommunikation der Server untereinander, wird anhand der der Pfeile dargestellt.
Die Richtungen der Pfeile zwischen den Servern/Nodes's geben die Kommunikationsrichtung an. Beispielsweise Prometheus und Node-Set: Hier ist prometheus der aktive Partner und stellt eine anfrage an den Node (passiv/wartend). Dabei symbolisiert die Fabe des Pfeiles ob es sich um eine HTTP (rot) oder HTTPS (grün) Verbindung handelt, zusätzlich dargestellt durch das jeweilige Vorhängeschloss.
![overview](./diagramme/overview.jpg)
## Motivation
Das Aufsetzen von Servern bestehet in der Praxis aus vielen einzelnen Schritten wie Installationen, Konfigurationen, Datei/Rechte-Management und Sicherheitseinstellungen. Diese einzelnen Schritte werden in der Regel einmal ausgeführt und so lange der Server einwandfrei läuft nicht mehr benötigt. Jedoch kommt irgendwann der Zeitpunkt, an dem am Server etwas verändert werden muss oder noch schlimmer der Server nicht mehr korrekt funktioniert. Das Problem jedoch ist oft, dass einem die Schritte, die ausgeführt wurden, gar nicht mehr alle klar sind, weil man das nur einmal vor Jahren gemacht hat. Somit steigt mit der Zahl der Änderungen das Risiko, den Server zu verlieren bzw. in einen Zustand zubringen, der nicht wiederherzustellen ist. In diesem Fall wäre es wünschenswert einen Workflow zu haben, welcher einem den funktionierenden Zustand vollautomatisch erzeugt, um keine Angst bei Änderungen am Server zu haben oder den Server einfach neu zu Installieren.
Wie in der Einleitung schon erwähnt wird hier die Installation einer Prometheus/Influx/Grafana-Instanz gezeigt. Zu Demonstrationszwecken werden 10 zusätzliche Nodes erzeugt, die mit dem Prometheus-node-exporter ihre Metriken bereitstellen und damit die überwachten Server darstellen. Es existieren zusätzlich eine Vielzahl weiterer Exporter für verschiedenste Systeme, sodass die hier erzeugte Instanz vielseitig einsetzbar ist. Interessant hierbei auch das OpenMetric Project. ( https://openmetrics.io/ )
## Provisionierung und synchronisierte Ordner
Dieses Setup benutzt den Vagrant Shell-Provisionierer um die virtuellen Maschinen bzw. genauer gesagt die Gastbetriebssysteme zu konfigurieren. Die für die Provisionierung angegebenen Skripte werden hierbei von Vagrant per SSH auf die Maschine geladen und dort lokal ausgeführt. Bevor jedoch Vagrant die Shell-Provisionierung durchführen kann, werden von Vagrant folgende Vorbereitungen ausgeführt.
### Startablauf
Beim ersten Aufruf von ```vagrant up <machinename>```, bereite Vagrant das Gastbetriebssystem (%vm_name%.vm.box) vor und verbindet sich mit jenem um einen neuen SSH-Key zu platziert der für spätere Interaktion mit dem Gastsystem benutzt wird. Nachdem Vagrant sich mit dem neuen Key erfolgreich mit dem Gastsystem verbunden hat, gibt Vagrant folgende Meldung aus: ```"Machine booted and ready!"```. Anschließend konfiguriert Vagrant die im Vagrantfile definierten Netzwerkeinstellungen(%name%.vm.network) und führt im nächsten Schritt die Synchronisation von Ordnern (%name%.vm.synced_folder) mit dem Gastsystem aus.
In diesem Setup wird Rsync (https://rsync.samba.org/) benutzt um Konfigurationsdateien, Zertifikate und User-Daten mit dem Gastsystem zu synchronisieren. Vagrant installiert hierfür auf dem Gastbetriebssystem Rsync sofern es noch nicht installiert ist und führt den im Vagrantfile angegeben Rsync Befehl aus. Unter dem Pfad ```provision/*``` hat jeder Maschinen-Typ in diesem Setup (prom, graf, flux, chron, node) einen Ordner mit den notwenigen Daten die synchronisiert werden sollen.
Nachdem alles vorbereitet ist, wird die Provisionierung ausgeführt. Vagrant verbindet sich mit SSH und führt die im Vagrantfile (%vm_name%.vm.provision) definierten Skripte aus und gibt die Ausgabe im Terminal zurück.
### Vagrant Befehle
Vagrant bietet neben dem Up/Destroy-Befehl noch weitere Befehle, um die Maschinen zu administrieren. Da das verhalten dieser Befehle abhängig ist von dem wie die Skripte zum Beispiel geschrieben sind, werden die Befehle im Bezug auf dieses Projekt erläutert.
* ```vagrant up <machinename>```
Startet die Maschine und führt beim ersten Aufruf die oben beschrieben Schritte aus.
* ```vagrant reload <machinename>```
Startet die Maschine neu, ohne Sie zu erstellen und führt alle Konfigurationsschritte aus dem Vagrantfile aus (network, synced_folders) bis auf die Provisionierung. Diese kann aber mit der Option ```--provision``` auch mit ausgeführt werden. Nur das Erstellen der Maschine muss vorher schonmal mit ```Vagrant up <machinename>``` durchgeführt worden sein, ansonsten kann die Maschine sich in jedem Zustand befinden: laufend, runtergefahren oder schlafend. Wobei bei einer schlafenden Maschine der Zustand verworfen wird und ein Neustart ausgeführt wird.
* ```vagrant provision <machinename>```
Mit diesem Befehl führen Sie bei einer laufenden Maschine die Provisionierung (%vm_name%.vm.provision) neu aus, Die Skripte sind so geschrieben, dass die Provisionierung sich überschreibt. Beispielsweise wenn die Provisionierung von Prometheus wiederholt wird, wird der alte Stand von Prometheus gelöscht und eine neue saubere Installation durchgeführt, so dass der funktionierende ausgangszustand wiederhergestellt ist. Der restliche Zustand der Maschine wird hierbei nicht zurückgesetzt, hierfür sollten die Maschine zerstört(destroy) und neu aufgebaut werden(up).
* ```vagrant rsync <machinename>```
Führt die Rsync Synchronisierung für die Maschine nochmal aus.
* ```vagrant ssh <machinename>```
SSH Verbindung zum Gastsystem.
## Backup und Restore
### Automatisches Backup
Da in diesem Aufbau die Influx Datenbank die wichtigsten Daten speichert, wird diese durch ein automatisches inkrementelles Backup gesichert. Hierfür ist auf der Maschine ein Systemd service (backup.service) eingeschaltet mit einem dazugehörigem Timer. In der Datei ```./provision/influx/config/backup.timer``` ist der Zeitpunkt eingestellt zudem die Sicherung auslöst. In dem Backup-Skript ```./provision/influx/backup.sh``` ist der standartmäßige Speichertort des Backups auf der Influx-Maschine der geteite Ordner vom VirtualBox-Provider.
### Manuelles Backup
### Projektverzeichnis
#### ```./backup```
Wird bei der flux (InfluxDB) VM als geteilter Ordner eingebunden für das speichern von Backups.
* ```./snapshot```
Speicherort des Backup's
#### ```./docu```
Dokumentation und Diagramme.
#### ```./openssl```
Dieser Ordner enthält die nötigen Skripte und Dateien zur Erstellung von Zertifikaten.
* ```./config```
Hier liegen die Zertifikat-Konfigurationen für Openssl.
* ```./data```
Ausgabeordner der Zertifikate und wird bei jedem ausführen von ```openssl_generate.sh``` neu erstellt.
#### ```./provision```
Wird bei allen VM's als geteilter Ordner eingebunden und enthält die für die Provisionierung nötigen Skripte und Dateien.
* ```./chronograf```
* ```./grafana```
* ```./influx```
* ```./node```
* ```./prometheus```
* ```./shell```
#### ```./scripts```
* influx_backup.sh
Startet per Vagrant SSH innerhalb von "flux" das Backup-Skript.
* influx_restore.sh
Startet per Vagrant SSH innerhalb von "flux" das Restore-Skript.
* openssl_generate.sh
Openssl.sh muss vor dem ersten Start der Maschinen ausgeführt werden! Das Skript generiert aus den im ```./config/*``` Ordner liegenden Konfigurationen ein CA-Zertifikat und für die jeweiligen Dienste signierte Zertifikate. Im Anschluss werden die Zertifikate in einen Deployment Ordner gelikt.
#### Vagrantfile
Enthält die Definition der einzelnen Virtuellen-Maschinen, die erstellt werden sollen (Image, Network, Provision, Share).
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment