Skip to content

GitLab

Commit f179add9 authored by k.elaammari's avatar k.elaammari
Browse files

Readme, systemctl start instead of restart.

parent c14e9de2
Show whitespace changes
Inline Side-by-side
README.md
View file @ f179add9
......@@ -8,9 +8,9 @@ Mithilfe dieses Workflows können Sie mit Vagrant eine vollständige Monitoring-
* Prometheus (Node-Metriken abgreifen und an DB weiterleiten)
* InfluxDB (Time-Series DB, Langzeitspeicher, Backup/Restore)
* Chronograf (Graphisches Interface zu InfluxDB)
* Node-Set (Überwachete Dummy-Maschinen)
* Node-Set (Dummy-Maschinen)
Es ist auf jeder dieser virtuellen Maschinen (VMs) der Prometheus-node-exporter für das Bereitstellen der zu erfassenden Metriken installiert.
Für das Bereitstellen der Metriken, ist auf jeder virtuellem Maschine (VM) der Prometheus-node-exporter installiert.
![Infrastruktur](./docu/inkscape/infrastruktur_s.png)
......@@ -22,7 +22,7 @@ Um den Workflow ausführen zu können müssen folgenden Programme installiert se
* VirtualBox (<https://www.virtualbox.org/>) oder ein anderer unterstützter Hypervisor
* Git (<https://git-scm.com/>)
Im Weiteren wird vorausgesetzt, dass Sie sich auf einem Linux basierten Betriebssystem befinden. Der Workflow funktioniert auch auf Windows-Platformen, 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. Diese ist normalerweise unter Windows eingeschaltet und fügt beim auschecken ein CR zum LF hinzu.
Im Weiteren wird vorausgesetzt, dass Sie sich auf einem Linux basierten Betriebssystem befinden. Der Workflow funktioniert auch auf Windows-Platformen, 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. Diese ist normalerweise unter Windows eingeschaltet und fügt beim auschecken ein CR zum LF hinzu.
```shell
git config --global core.autocrlf false
......@@ -36,7 +36,7 @@ Um direkt zu starten, kopieren Sie mit folgendem Befehl das Projekt auf ihren Re
git clone git@git.gsi.de:dc/common/vagrant-prometheus.git
```
Bevor die VMs gestartet werden sollten, müssen die benötigten TLS-Zertifikate erzeugt werden. Hierfür führen Sie folgenden Befehl aus.
Bevor die VMs gestartet werden, müssen die benötigten TLS-Zertifikate erzeugt werden. Hierfür führen Sie folgenden Befehl aus.
```shell
./scripts/openssl_generate.sh
......@@ -64,7 +64,7 @@ Nachdem die Maschinen gestartet sind und die Provisionierung erfolgreich ausgef
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 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. Um beim hinzufügen das Zertifikat zu verifizieren, können Sie mit folgendem Befehl die Fingerprints der erzeugen Zertifikate anzeigen lassen.
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 beim Aufruf der Seiten zu vermeiden. Wenn Sie das Zertifikat hinzufügen, können Sie mit folgendem Befehl die Fingerprints der erzeugten Zertifikate anzeigen lassen, um diese zu verifizieren.
```shell
./scripts/openssl_fingerprint.sh
......@@ -72,26 +72,26 @@ Da die Dienste Grafana und Chronograf ein signiertes TLS-Zertifikat besitzen, k
## Vagrant Kommandos
* ```vagrant up <vm>```
: ```vagrant up <vm>```
Startet und erstellt falls nötig die Maschine. Wird die Maschine zum ersten Mal gestartet, wird auch die Provision ausgeführt, andernfalls muss mit der Option "--provision" die Provisionierung explizit gefordert werden.
* ```vagrant destroy <vm>```
: ```vagrant destroy <vm>```
Zerstört die Maschine unwiderruflich.
* ```vagrant provision <vm>```
: ```vagrant provision <vm>```
Mit diesem Befehl führen Sie bei einer laufenden Maschine die Provisionierung neu aus. Dabei werden die Befehle aus der Vagrantfile (%vm_name%.vm.provision) in absteigender Reihenfolge nacheinander ausgeführt. Das bedeutet, als erstes werden mit dem File-Provisionierer die aktuellen Dateien aus dem Projektverzeichnis erneut auf die VM kopiert und anschließend die Inline-Skripte ausgeführt.
* ```vagrant ssh <vm>```
: ```vagrant ssh <vm>```
Baut eine SSH Verbindung mit dem von Vagrant hinzugefügten Key auf.
## Klassifizierung von Dateien
Um eine überschaubare Umgebung zu schaffen, wird versucht die hier verwendeten Daten und Dateien in drei Kategorien zu unterteilt.
Um eine überschaubare Umgebung zu schaffen, werden die hier verwendeten Daten und Dateien in drei Kategorien zu unterteilt.
### 1. Executable
In die Kategorie Executable fallen alle Binären oder Ausführbaren Dateien. In diesem Projekt werden alle Programme von den jeweiligen Paketmanagern installiert, lediglich Skripte, wie z.B. die für den Backup- und Restore-Workflow werden mit dem File-Provisionierer kopiert. Zusätzlich gelten Unit- und Timer-Dateien in diesem Projekt auch in die Kategorie Executable, die auch je nach VM mit dem File-Provisionierer kopiert werden.
In die Kategorie Executable fallen alle binären oder ausführbaren Dateien. In diesem Projekt werden alle Programme von den jeweiligen Paketmanagern installiert, lediglich Skripte, wie z.B. die für den Backup- und Restore-Workflow werden mit dem File-Provisionierer kopiert. Zusätzlich gehören Unit- und Timer-Dateien in diesem Projekt auch in die Kategorie Executable, die auch je nach VM mit dem File-Provisionierer kopiert werden.
```shell
.vagrant-prometheus/
......@@ -128,7 +128,7 @@ In die Kategorie Executable fallen alle Binären oder Ausführbaren Dateien. In
### 2. Konfigurations-Daten
Konfigurationsdateien werden beim Start der Executables gebraucht. Hierrunter fallen z.B. Ini- oder Conf-Dateien. Einen Sonderfall in diesem Projekt haben die Text- und JSON-Dateien, diese enthalten Daten, die nicht direkt von den Executables interpretiert werden. Sondern werden z.B. die JSON-Dateien mittels CURL an die HTTP-API von Grafana gesendet, um einen Zustand zu erzeugen. Da der Workflow für Openssl bzw. Zertifikate in einer anderen Sektion beschrieben wird, übergehen wir hier diese Dateien.
Konfigurationsdateien werden beim Start der Executables gebraucht. Hierrunter fallen z.B. Ini- oder Conf-Dateien. Einen Sonderfall stellen in diesem Projekt die Text- und JSON-Dateien dar, Diese enthalten Daten, die nicht direkt von den Executables interpretiert werden, sondern z.B. die JSON-Dateien mittels CURL an die HTTP-API von Grafana gesendet werden, um einen Zustand zu erzeugen. Da der Workflow für Openssl bzw. Zertifikate in einer anderen Sektion beschrieben wird, übergehen wir hier diese Dateien.
```shell
.vagrant-prometheus/
......@@ -198,7 +198,7 @@ Weiter Benutzerdaten befinden sich auf den VMs.
### Backup
Die InfluxDB ist durch einen Backup- und Restore-Mechanismus ausgestattet, mit dem wir die gesammelten Daten des Monitoringsystems extern speichern und zurück spielen können. In diesem Workflow wird Standardmäßig um 1 Uhr täglich ein Vollbackup ausgelöst, das separat zu den vorherigen Backups in einem Ordner mit Zeitstempel abgelegt wird. Konfigurieren können Sie den Timer in der Datei: ```./provision/influx/config/backup.timer```. Wichtig zu beachten ist, dass das Backup in einem von VirtualBox geteilten Ordner zwischen VM ```/vagrant/backup``` und Projektverzeichnis ```./backup``` gespeichert wird! Wenn Ihr Hypervisor diese Funktion nicht unterstützt, müssen Sie die Backups von Hand aus der Influx-VM kopieren. Vagrant bietet hier alternativ Rsync oder SMB an.
Die InfluxDB ist durch einen Backup- und Restore-Mechanismus ausgestattet, mit dem wir die gesammelten Daten des Monitoringsystems extern speichern und zurück spielen können. In diesem Workflow wird standardmäßig um 1 Uhr täglich ein Vollbackup ausgelöst, das separat zu den vorherigen Backups in einem Ordner mit Zeitstempel abgelegt wird. Konfigurieren können Sie den Timer in der Datei: ```./provision/influx/config/backup.timer```. Wichtig zu beachten ist, dass das Backup in einem von VirtualBox geteilten Ordner zwischen VM ```/vagrant/backup``` und Projektverzeichnis ```./backup``` gespeichert wird! Wenn Ihr Hypervisor diese Funktion nicht unterstützt, müssen Sie die Backups von Hand aus der Influx-VM kopieren. Vagrant bietet hier alternativ Rsync oder SMB an.
Um ein manuelles Backup zu starten, führen Sie folgendes Skript aus.
......@@ -232,11 +232,11 @@ Für Grafana werden zwei Benutzer angelegt, ein Administrator und ein optionaler
#### Passwörter ändern
Das ändern von Benutzer Passwörter sollten nach Möglichkeit über das Grafna-UI erfolgen, entweder als Admin oder vom Benutzer selbst. Daneben besteht noch die Option die HTTP-API zu benutzen. Hierfür können Sie sich am ```setup_grafana.sh```-Skript von Grafana orientieren und den CURL Befehl entweder mit BasicAuth oder mit dem API-Token bauen.
Das Ändern von Benutzer Passwörter sollte nach Möglichkeit über das Grafna-UI erfolgen, entweder als Admin oder vom Benutzer selbst. Daneben besteht noch die Option die HTTP-API zu benutzen. Hierfür können Sie sich am ```setup_grafana.sh```-Skript von Grafana orientieren und den CURL Befehl entweder mit BasicAuth oder mit dem API-Token bauen.
#### Admin Passwort zurücksetzen
Sollten kein Zugriff auf den Admin-Benutzer bestehen, kann mit der Grafana-CLI das Passwort zurückgesetzten werden. Hierfür muss lokal auf der VM folgender Befehl ausgeführt werden.
Sollte kein Zugriff auf den Admin-Benutzer bestehen, kann mit der Grafana-CLI das Passwort zurückgesetzten werden. Hierfür muss lokal auf der VM folgender Befehl ausgeführt werden.
```shell
vagrant ssh graf # verbinden mit der VM
......@@ -245,7 +245,7 @@ sudo grafana-cli --homepath /usr/share/grafana admin reset-admin-password "newpa
### Influx
In der Influx-Datenbank werden drei Benutzer angelegt, ein Administrator und anschließend zwei weitere Benutzer für Grafana und Prometheus. Dabei ist festgelegt, dass der Prometheus Benutzer nur Schreib-Rechte und Grafana nur Lese-Rechte bekommt. Ausgeführt werden die Queries mit dem ```./provision/influx/setup_influx.sh```-Skript indem mit CURL die Queries an die HTTP-API von Influx gesendet werden. Beim ersten Start von Influxdb wird keine Authentifizierung für das erzeugen eines Administrators verlang. Anschließend schaltet sich die Authentifizierung automatisch für die folgende Queries ein. Die Standardpasswörter für die Benutzer sind in folgenden Dateien.
In der Influx-Datenbank werden drei Benutzer angelegt, ein Administrator und anschließend zwei weitere Benutzer für Grafana und Prometheus. Dabei ist festgelegt, dass der Prometheus Benutzer nur Schreib-Rechte und Grafana nur Lese-Rechte bekommt. Ausgeführt werden die Queries mit dem ```./provision/influx/setup_influx.sh```-Skript indem mit CURL die Queries an die HTTP-API von Influx gesendet werden. Beim ersten Start von Influxdb wird keine Authentifizierung für das Erzeugen eines Administrators verlang. Anschließend schaltet sich die Authentifizierung automatisch für die folgende Queries ein. Die Standardpasswörter für die Benutzer sind in folgenden Dateien gespeichert.
```shell
./provision/influx/
......@@ -270,7 +270,7 @@ result message...
Wenn Sie das Passwort von Prometheus oder Grafana ändern, müssen Sie auch die Konfiguration bzw. die Grafana-Datasource aktualisieren.
##### Prometheus
Tragen Sie die neuen Benutzerdaten in folgende Datei ein, führen die Provisionierung neu aus und laden Sie die Konfiguration neu.
Tragen Sie die neuen Benutzerdaten in folgende Datei ein, führen Sie die Provisionierung neu aus und laden Sie die Konfiguration neu.
```shell
nano ./provision/prometheus/config/prom.yml
......@@ -281,7 +281,7 @@ sudo curl -X POST http://localhost:9090/-/reload
```
##### Grafana
Tragen Sie die neuen Benutzerdaten in folgende Datei ein, führen die Provisionierung neu aus.
Tragen Sie die neuen Benutzerdaten in folgende Datei ein, führen Sie die Provisionierung neu aus.
```shell
./provision/grafana/config/datasources/ds_influx.json
......@@ -325,11 +325,11 @@ Um den Datenverkehr zu verschlüsseln und die Dienste authentifizieren zu könne
./csrdb
```
Im Config-Verzeichnis befinden sich die Konfigurationsdateien für die Zertifikate. In diesen können Sie die Standardwerte für organizationName, commonName, emailAddress, usw. ändern, die bei der Erzeugung in die Zertifikate eingetragen werden. Das Data-Verzeichnis wird erst nachdem ausführen von ```./scripts/openssl_generate.sh``` erstellt und enthält die Zertifikate im Ordner "certificates", sowie den Zustand der Openssl-Textdatenbank im Ordner "csrdb". Csrdb wird für das Signieren der Zertifikate gebraucht und enthält unteranderem die aktuelle Seriennummer.
Im Config-Verzeichnis befinden sich die Konfigurationsdateien für die Zertifikate. In diesen können Sie die Standardwerte für organizationName, commonName, emailAddress, usw. ändern, die bei der Erzeugung in die Zertifikate eingetragen werden. Das Data-Verzeichnis wird erst nachdem ausführen von ```./scripts/openssl_generate.sh```-Skript erstellt und enthält die Zertifikate im Ordner "certificates", sowie den Zustand der Openssl-Textdatenbank im Ordner "csrdb". Csrdb wird für das Signieren der Zertifikate gebraucht und enthält unteranderem die aktuelle Seriennummer.
### Zertifikat-Seriennummer
Zertifikate enthalten nach dem X.509 Standard eine Seriennummer, die bei der Signierung bestimmt wird. Die mit dem ```./scripts/openssl_generate.sh``` erstellten und signierten Zertifikate werden Standartmäßig mit der Seriennummer 0x2 aufwärts signiert. Manche Browser, wie z.B. der Firefox, melden aber einen Fehler, wenn vom Selben "Issuer: C, ST, L, O, OU, CN" eine vergebene Seriennummer nochmal an ein anderes Zertifikat vergeben wird. In diesem Fall können sie mit einem CLI-Argument die anfangs Seriennummer auf einen andere Wert setzen. Die Seriennummer wird als Hex-Zahl angegeben und die Anzahl der Ziffern muss grade sein. So würde z.B. 0F1 zu einem Fehler führen und sollte als F1 oder 00F1 eingegeben werden.
Zertifikate enthalten nach dem X.509 Standard eine Seriennummer, die bei der Signierung bestimmt wird. Die mit dem ```./scripts/openssl_generate.sh``` erstellten und signierten Zertifikate werden standartmäßig mit der Seriennummer 0x2 aufwärts signiert. Manche Browser, wie z.B. der Firefox, melden aber einen Fehler, wenn vom Selben "Issuer: C, ST, L, O, OU, CN" eine vergebene Seriennummer nochmal an ein anderes Zertifikat vergeben wird. In diesem Fall können sie mit einem CLI-Argument die Anfangsseriennummer auf einen andere Wert setzen. Die Seriennummer wird als Hex-Zahl angegeben und die Anzahl der Ziffern muss gerade sein. So würde z.B. 0F1 zu einem Fehler führen und sollte als F1 oder 00F1 eingegeben werden.
```shell
#./scripts/openssl_generate.sh 01
......@@ -346,7 +346,7 @@ Zertifikate enthalten nach dem X.509 Standard eine Seriennummer, die bei der Sig
Wenn ein Private-Key auf irgendeine Art an Dritte verloren gegangen ist, müssen Sie reagieren. In diesem Fall ist zu unterscheiden, ob es sich um den cakey.pem, also der Root-Key oder den Key eines Dienstes wie grafanakey.pem handelt. Sollten Sie ihren Root-Key verlieren, ist ihre Kommunikation zwischen den Diensten auch für 3.te weiterhin sicher verschlüsselt, aber mit dem Root-Key könnten fremde Zertifikate signiert werden, welche dann von Ihrem installierten Root-Zertifikat als gültig anerkannt werden würden. Im zweiten Fall, wenn Sie den Privat-Key eines Dienstes verloren haben, könnten zwar keine Zertifikate signiert werden, aber mit dem aktuellen Privat-Key, kann sich ein 3.ter als der Dienst ausgeben, für den das Zertifikat ausgestellt wurde. Des Weiteren sind die mit dem Zertifikat aufgebauten verschlüsselten Verbindungen auch nur noch bedingt sicher vor dem Mitlesen Dritter.
* Root-Key verloren, in diesem Fall müssen alle Zertifikate neu erzeugt werden. Zusätzlich müssen sie jeden informieren, dem aktuellen Root-Zertifikat cacert.pem das Vertrauen zu entziehen. Führen Sie ```./scripts/openssl_generate.sh``` neu aus und verteilen die Zertifikate mit dem Vagrant File-Provisionierer neu auf die Maschinen. Beachten Sie die Zertifikat-Seriennummer.
* Root-Key verloren, bedeutet, dass alle Zertifikate neu erzeugt werden müssen. Zusätzlich müssen sie jeden informieren, dem aktuellen Root-Zertifikat cacert.pem das Vertrauen zu entziehen. Führen Sie ```./scripts/openssl_generate.sh``` neu aus und verteilen die Zertifikate mit dem Vagrant File-Provisionierer neu auf die Maschinen. Beachten Sie die Zertifikat-Seriennummer.
```shell
./scripts/openssl_generate.sh
......
Vagrantfile
View file @ f179add9
......@@ -33,17 +33,16 @@ Vagrant.configure("2") do |config|
flux.vm.provision "shell", inline: "pacman -S --noconfirm influxdb"
flux.vm.provision "shell", inline: "cp #{FOLDER}/config/influxdb.conf /etc/influxdb/influxdb.conf && chown influxdb:influxdb /etc/influxdb/influxdb.conf && chmod 440 /etc/influxdb/influxdb.conf"
flux.vm.provision "shell", inline: "mkdir -p /var/lib/influxdb/https && cp -a #{FOLDER}/https/* /var/lib/influxdb/https && chown -R influxdb:influxdb /var/lib/influxdb/https && chmod 440 /var/lib/influxdb/https/* && chmod 550 /var/lib/influxdb/https"
flux.vm.provision "shell", inline: "systemctl enable influxdb && systemctl restart influxdb"
flux.vm.provision "shell", path: "provision/influx/setup_queries.sh"
flux.vm.provision "shell", inline: "mkdir -p /var/lib/influxdb/backup && cp -a #{FOLDER}/backup/* /var/lib/influxdb/backup && cp -a #{FOLDER}/config/admin.pw /var/lib/influxdb/backup"
flux.vm.provision "shell", inline: "systemctl enable influxdb && systemctl start influxdb"
flux.vm.provision "shell", path: "provision/influx/setup_influx.sh"
flux.vm.provision "shell", inline: "mkdir -p /var/lib/influxdb/backup && cp -a #{FOLDER}/backup/* /var/lib/influxdb/backup"
flux.vm.provision "shell", inline: "chown -R influxdb:influxdb /var/lib/influxdb/backup && chmod 550 /var/lib/influxdb/backup/* && chmod 550 /var/lib/influxdb/backup"
flux.vm.provision "shell", inline: "cp -a #{FOLDER}/config/admin.pw /var/lib/influxdb/backup"
flux.vm.provision "shell", inline: "cp -a #{FOLDER}/config/backup.* /etc/systemd/system/"
flux.vm.provision "shell", inline: "systemctl enable backup.timer && systemctl start backup.timer"
flux.vm.provision "shell", inline: "systemctl list-timers"
flux.vm.provision "shell", inline: "pacman -S --noconfirm prometheus-node-exporter"
flux.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl restart prometheus-node-exporter"
flux.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl start prometheus-node-exporter"
flux.vm.provision "shell", inline: "echo \"InfluxDB setup done. \""
flux.vm.provision "shell", inline: "rm -r -f #{FOLDER}"
......@@ -75,10 +74,10 @@ Vagrant.configure("2") do |config|
prom.vm.provision "shell", inline: "cp #{FOLDER}/config/prom.service /etc/systemd/system/prometheus.service"
prom.vm.provision "shell", inline: "cp #{FOLDER}/config/prom.yml /etc/prometheus/prometheus.yml && chown prometheus:prometheus /etc/prometheus/prometheus.yml && chmod 440 /etc/prometheus/prometheus.yml"
prom.vm.provision "shell", inline: "mkdir -p /var/lib/prometheus/https && cp -a #{FOLDER}/https/* /var/lib/prometheus/https && chown -R prometheus:prometheus /var/lib/prometheus/https && chmod 440 /var/lib/prometheus/https/* && chmod 550 /var/lib/prometheus/https"
prom.vm.provision "shell", inline: "systemctl daemon-reload && systemctl enable prometheus && systemctl restart prometheus"
prom.vm.provision "shell", inline: "systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus"
prom.vm.provision "shell", inline: "pacman -S --noconfirm prometheus-node-exporter"
prom.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl restart prometheus-node-exporter"
prom.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl start prometheus-node-exporter"
prom.vm.provision "shell", inline: "echo \"Prometheus setup done. \""
prom.vm.provision "shell", inline: "rm -r -f #{FOLDER}"
......@@ -108,11 +107,11 @@ Vagrant.configure("2") do |config|
graf.vm.provision "shell", inline: "pacman -S --noconfirm jq"
graf.vm.provision "shell", inline: "cp #{FOLDER}/config/graf_conf.ini /etc/grafana.ini && chown grafana:grafana /etc/grafana.ini && chmod 440 /etc/grafana.ini"
graf.vm.provision "shell", inline: "mkdir -p /var/lib/grafana/https && cp -a #{FOLDER}/https/* /var/lib/grafana/https && chown -R grafana:grafana /var/lib/grafana/https && chmod 440 /var/lib/grafana/https/* && chmod 550 /var/lib/grafana/https"
graf.vm.provision "shell", inline: "systemctl enable grafana && systemctl restart grafana"
graf.vm.provision "shell", inline: "systemctl enable grafana && systemctl start grafana"
# grafana setup
graf.vm.provision "shell", path: "provision/grafana/setup_grafana.sh"
graf.vm.provision "shell", inline: "pacman -S --noconfirm prometheus-node-exporter"
graf.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl restart prometheus-node-exporter"
graf.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl start prometheus-node-exporter"
graf.vm.provision "shell", inline: "echo \"Grafana setup done. \""
graf.vm.provision "shell", inline: "rm -r -f #{FOLDER}"
......@@ -147,10 +146,10 @@ Vagrant.configure("2") do |config|
chron.vm.provision "shell", inline: "su - vagrant -c \"cd /home/vagrant/chron_git && makepkg -s -i -f --noconfirm --needed\""
chron.vm.provision "shell", inline: "cp #{FOLDER}/config/chronograf.service /etc/systemd/system/chronograf.service"
chron.vm.provision "shell", inline: "mkdir -p /var/lib/chronograf/https && cp -a #{FOLDER}/https/* /var/lib/chronograf/https && chown -R chronograf:chronograf /var/lib/chronograf/https && chmod 440 /var/lib/chronograf/https/* && chmod 550 /var/lib/chronograf/https"
chron.vm.provision "shell", inline: "systemctl enable chronograf && systemctl restart chronograf"
chron.vm.provision "shell", inline: "systemctl enable chronograf && systemctl start chronograf"
chron.vm.provision "shell", inline: "pacman -S --noconfirm prometheus-node-exporter"
chron.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl restart prometheus-node-exporter"
chron.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl start prometheus-node-exporter"
chron.vm.provision "shell", inline: "echo \"Chronograf setup done. \""
chron.vm.provision "shell", inline: "rm -r -f #{FOLDER}"
......@@ -174,7 +173,7 @@ Vagrant.configure("2") do |config|
node.vm.provision "shell", inline: "timedatectl set-timezone Europe/Berlin"
node.vm.provision "shell", inline: "apt-get update && apt-get upgrade -y"
node.vm.provision "shell", inline: "apt-get install -y prometheus-node-exporter"
node.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl restart prometheus-node-exporter"
node.vm.provision "shell", inline: "systemctl enable prometheus-node-exporter && systemctl start prometheus-node-exporter"
node.vm.provision "shell", inline: "cp #{FOLDER}/config/stress.service /etc/systemd/system/stress.service"
node.vm.provision "shell", inline: "systemctl enable stress"
node.vm.provision "shell", inline: "echo \"Node setup done. \""
......
docu/README.md deleted 100644 → 0
View file @ c14e9de2
# Dokumentation 'vagrant-prometheus'
## Openssl
Um den Datenverkehr zu verschlüsseln und die Dienste authentifizieren zu können, benötigen wir TLS-Zertifikat die wir mit 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, wie z.B. cacert.pem und cakey.pem oder influxcert.pem und influxkey.pem.
### Struktur
```shell
./openssl
./config
./chronograf.cnf
./grafana.cnf
./influx.cnf
./openssl-ca.cnf
./data
./certificates
./csrdb
```
Im Config Verzeichnis befinden sich die Konfigurationsdateien für die Zertifikate. In diesen können Sie die Standardwerte für organizationName, commonName, emailAddress, usw. ändern, die bei der Erzeugen in die Zertifikate übernommen werden. Das Data Verzeichnis wird erst nachdem ausführen von ```./scripts/openssl_generate.sh``` erstellt und enthält die Zertifikate im Ordner "certificates", sowie den Zustand der Openssl-Textdatenbank im Ordner "csrdb". Csrdb wird für das Signieren der Zertifikate gebraucht und enthält unteranderem die aktuelle Seriennummer.
### Zertifikat-Seriennummer
Zertifikate enthalten nach dem X.509 Standard eine Seriennummer, die bei der Signierung bestimmt wird. Die mit dem ```./scripts/openssl_generate.sh``` erstellten und signierten Zertifikate werden Standartmäßig mit der Seriennummer 0x2 aufwärts signiert. Manche Browser, wie z.B. der Firefox, melden aber einen Fehler, wenn vom Selben "Issuer: C, ST, L, O, OU, CN" eine vergebene Seriennummer nochmal an ein anderes Zertifikat vergeben wird. In diesem Fall können sie mit einem CLI-Argument die anfangs Seriennummer auf eine andere Wert setzen. Die Seriennummer wird als Hex-Zahl angegeben und die Anzahl der Ziffern muss grade sein. So würde z.B. 0F1 zu einem Fehler führen und sollte als F1 oder 00F1 eingegeben werden.
```shell
#./scripts/openssl_generate.sh 01
#./scripts/openssl_generate.sh FF
#./scripts/openssl_generate.sh 0100
#./scripts/openssl_generate.sh FFFF
#./scripts/openssl_generate.sh 010000
#./scripts/openssl_generate.sh 0FFF8729
#./scripts/openssl_generate.sh 01FA55DEC3
...
```
### 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 sich um den cakey.pem, also der Root-Key oder den Key eines Dienstes wie grafanakey.pem handelt. Sollten Sie ihren Root-Key verlieren, ist ihre Kommunikation zwischen den Diensten auch für 3.te weiterhin sicher verschlüsselt, aber mit dem Root-Key könnten fremde Zertifikate signiert werden, welche dann von Ihrem installierten Root-Zertifikat als gültig anerkannt werden würden. Im zweiten Fall, könnten zwar keine Zertifikate signiert werden, aber mit dem aktuellen Privat-Key, kann sich ein 3.ter als der Dienst ausgeben, für den das Zertifikat ausgestellt wurde. Des Weiteren sind die mit dem Zertifikat aufgebauten verschlüsselten Verbindungen auch nur noch bedingt sicher vor dem Mitlesen 3.ter.
1. Root-Key verloren, in diesem Fall müssen alle Zertifikate neu erzeugt werden. Zusätzlich müssen sie jeden informieren, dem aktuellen Root-Zertifikat cacert.pem das Vertrauen zu entziehen. Führen Sie ```./scripts/openssl_generate.sh``` neu aus und verteilen die Zertifikate mit dem Vagrant File-Provisionierer neu auf die Maschinen. Beachten Sie die Zertifikat-Seriennummer.
```shell
./scripts/openssl_generate.sh && vagrant provision graf
```
2. Dienst-Key verloren, bedeutet, dass Sie nur das jeweilige Zertifikat ersetzen müssen.
```shell
./scripts/openssl_node.sh (flux | graf | chron)
vagrant provision (flux | graf | chron)
```
### Eigene Zertifikate
Wenn Sie eigene Zertifikate erzeugen und diese in diesem Workflow benutzen möchten, müssen Sie diese an die entsprechenden Pfade kopieren oder verlinken. Standardmäßig werden die erzeugten Zertifikate aus ```./openssl/data/certificates``` mit dem jeweiligen Provision-Verzeichnis der VMs verlinkt. Sie können an dieselben Stellen Ihre Dateien kopieren und mit dem Provisionierer diese übertragen lassen. Sollten ihre Zertifikate nicht wie unten benannt werden können, müssen Sie zusätzlich in den Konfigurationen die geänderten Dateinamen eintragen.
```shell
./provision
./chronograf
./config/chronograf.service # TLS_CERTIFICATE, TLS_PRIVATE_KEY
./https
./cacert.pem
./chronografcert.pem
./chronografkey.pem
./grafana
./config/graf_conf.ini # Sektion [server]: cert_file, cert_key
./https
./cacert.pem
./grafanacert.pem
./grafanakey.pem
./influx
./config/influxdb.conf # Sektion [http]: https-certificate, https-private-key
./https
./cacert.pem
./influxcert.pem
./influxkey.pem
```
## Authentifizierung
In diesem Abschnitt wird gezeigt wie die Benutzer für Influx und Grafana erstellt werden.
### Grafana
Für Grafana werden zwei Benutzer angelegt. Ein Administrator und ein optionaler View-Bentuezr, der nur die Berechtigung hat Dashboards anzuzeigen. Angelegt werden die Benutzer mit dem ```./provision/grafana/config/setup_grafana.sh```-Skript. Die Standardpasswörter für die beiden Benutzer können in folgenden JSON-Dateien bearbeiten werden.
```shell
./provision/grafana/config/users
./admin_password.json
./view_user.json
```
#### Passwort ändern
Das ändern von Benutzer Passwörter sollten nach Möglichkeit über das Web-Interface erfolgen, entweder als Admin oder vom Benutzer selbst. Daneben besteht noch die Option die HTTP-API zu benutzen. Hierfür können Sie sich am ```setup_grafana.sh```-Skript von Grafana orientieren und den CURL Befehl entweder mit BasicAuth oder mit dem API-Token bauen.
#### Admin Passwort zurücksetzen
Sollten keine Zugriff mehr auf den Admin-Benutzer bestehen, kann mit der Grafana-CLI das Passwort zurückgesetzen werden. Hierfür muss local auf der VM folgender Befehl ausgeführt werden.
```shell
vagrant ssh graf # verbinden mit der VM
sudo grafana-cli --homepath /usr/share/grafana admin reset-admin-password newpass
```
### Influx
In der InfluxDB wir ein Admin-Benutzer mit allen Berechtigungen erzeugt und anschließend werden mit diesem zwei weitere Benutzer für Grafana und Prometheus erstellt. Die Standardwete hierfür sind in folgenden Dateien. Dabei ist festgelegt, dass der Prometheus Bentutzer nur Schreib-Rechte und Grafana nur Lese-Rechte bekommt.
```shell
./provision/influx/config
./admin.pw
./setup.queries
```
Sollten Sie an diesen Werten etwas ändern, müssen Sie auch in den Konfigurationen von Prometheus und Grafana dies vornehmen. Für Prometheus öffnen Sie die ```./provision/prometheus/config/prom.yml``` und tragen unten in der Sektion "remote_write:" die aktualisierten Benutzerdaten ein. Bei Grafana müssen Sie in ````./provision/grafana/config/datasources/ds_influx.json``` die neuen Benutzerdaten eintragen. Dieser Option setzt aber voraus, dass Sie die Maschinen neu provisionieren müssen.
#### Passwörter ändern (live)
Wenn Sie das Passwort für den Grafana nutzer ändern möchten, können Sie dies im Chronograf Web-Interface in der Sektion "InfluxDB Admin" tun. Sobald Sie die Änderung bei der InfluxDB vorgenommen haben, müssen Sie auch in Grafana dies aktualisieren. Hierfür wechseln Sie in das Grafana Web-Interface und von hier nach "Configurationen" > "Data Sources" > "InfluxDB" und tragen hier die neuen Benutzerdaten ein.
Um den Influx-Benutzer in Prometheus zu ändern ohne die Provisionierung neu auszuführen und ohne Restart des Services, müssen Sie die Lokale Konfiguration bearbeiten.
``` Shell
vagrant ssh prom # mit VM verbinden
sudo nano /etc/prometheus/prometheus.yml # Lokale Konfiguration
sudo curl -X POST http://localhost:9090/-/reload # Konfiguration neu laden
```
Denken Sie daran auch in der Konfiguration im Projektverzeichnis diese Änderung vorzunehmen, da ansonsten beim nächsten Durchlauf der Provisionierung die Konfiguration mit den alten Werten überschriben werden würde.
#### Admin Passwort zurücksetzen
Sollte ein 2.ter Adminnutzer existieren, kann dieser sich mit dem Chronograf anmelden und das Passwort über das Web-Interface ändern. Existiert nur ein Admin, muss lokal auf der VM das Passwort zurückgestzt werden, indem die Authentifizierung kurzfristig ausgeschaltet wird.
TODO
### Klassifizierung von Dateien
Um eine überschaubare Umgebung zu schaffen, wird versucht die hier verwendeten Daten und Dateien in drei Kategorien zu unterteilt.
#### 1. Executable
In die Kategorie Executable fallen alle Binären oder Ausführbaren Dateien. In diesem Projekt werden alle Programme von den jeweiligen Paketmanagern installiert, lediglich Skripte, wie z.B. die für den Backup- und Restore-Workflow werden mit dem File-Provisionierer kopiert. Zusätzlich gelten Unit- und Timer-Dateien in diesem Projekt auch in die Kategorie Executable, die auch je nach VM provisioniert werden.
```shell
.vagrant-prometheus/
./provision
./chronograf
./config
./chronograf.service
./grafana
./setup_grafana.sh
./influx
./backup
./backup_call.sh
./backup.sh
./restore.sh
./config
./backup.service
./backup.timer
./node
./config
./stress.service
./prometheus
./config
./prom.service
./scripts
./influx_backup.sh
./influx_restore.sh
./node_start_stress.sh
./node_stop_stress.sh
./openssl_fingerprint.sh
./openssl_generate.sh
./openssl_node.sh
```
#### 2. Konfigurations-Daten
Konfigurationsdateien werden beim Start der Executables gebraucht. Hierrunter fallen z.B. Ini- oder Conf-Dateien. Einen Sonderfall in diesem Projekt haben die Text- und JSON-Dateien, diese enthalten Daten, die nicht direkt von den Executables interpretiert werden. So werden z.B. die JSON-Dateien mittels CURL an die HTTP-API von Grafana gesendet, um einen Zustand zu erzeugen. Da der Workflow für Openssl bzw. Zertifikate oben schon beschrieben wurde, wird hier kein Bezug mehr darauf genommen.
```shell
.vagrant-prometheus/
./openssl
./config/*.cnf # Zertifikat Konfigurationen
./provision
./grafana
./config
./dashboards/*.json # Grfana Dashboards
./datasources/*.json # Grafana Datasources
./users/*.json # Grafana Benutzer
./graf_conf.ini # Konfigurationsdatei
./request_token.json # API-Token
./influx
./config
./admin.pw # Standartlogin für den DB-Admin
./influxdb.conf # Konfigurationsdatei
./setup.queries # Queries die auf der Influxdb ausgeführt werden müssen
./prometheus
./config
./prom.yml # Konfigurationsdatei
```
#### 3. Benutzer-Daten
Hiermit sind alle Daten gemeint, die bei Inbetriebnahme und während dem Betrieb entstehen. Im Projektverzeichnis enthalten folgende Ordner Benutzerdaten:
```shell
.vagrant-prometheus/
./backup
./openssl/data
```
Weiter Benutzerdaten befinden sich auf den VMs.
* Chronograf
```shell
/var/lib/chronograf/chronograf-v1.db
```
* Grafana
```shell
/var/lib/grafana/
./grafana.db
./token/apitoken.json
```
* Influxdb
```shell
/var/lib/influxdb/
./data
./meta
./wal
```
* Prometheus
```shell
/var/lib/prometheus/data
```
## Vagrant Kommandos
* ```vagrant up <vm>```
Startet und erstellt falls nötig die Maschine. Wird die Maschine zum ersten Mal gestartet, wird auch die Provision ausgeführt, andernfalls muss mit der Option "--provision" die Provisionierung explizit gefordert werden.
* ```vagrant destroy <vm>```
Zerstört die Maschine unwiderruflich.
* ```vagrant provision <vm>```
Mit diesem Befehl führen Sie bei einer laufenden Maschine die Provisionierung neu aus. Dabei werden die Befehle aus der Vagrantfile (%vm_name%.vm.provision) in absteigender Reihenfolge nacheinander ausgeführt. Das bedeutet, als erstes werden mit dem File-Provisionierer die aktuellen Dateien aus dem Projektverzeichnis erneut auf die VM kopiert und anschließend die Inline-Skripte ausgeführt.
* ```vagrant ssh <vm>```
Baut eine SSH Verbindung mit dem von Vagrant hinzugefügten Key auf.
\ 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

https://git.gsi.de is provided by CIT-HPC | GSI Helmholtzzentrum fuer Schwerionenforschung GmbH | Imprint (in German) | Privacy policy