421 lines
7.1 KiB
Markdown
421 lines
7.1 KiB
Markdown
# Pingu Infrastructure
|
|
|
|
Zentrale Infrastruktur- und Deployment-Repository für:
|
|
- Raspberry Pis
|
|
- Linux Server
|
|
- Cloudsysteme
|
|
- Docker Hosts
|
|
- Automatisierte Updates & Deployments
|
|
|
|
Die Systeme ziehen regelmäßig automatisch den aktuellen Stand aus dem Gitea-Repository und synchronisieren Skripte und Konfigurationen.
|
|
|
|
---
|
|
|
|
# Architektur
|
|
|
|
```text
|
|
+-------------------+
|
|
| Gitea Server |
|
|
| 10.200.200.2:2222 |
|
|
+---------+---------+
|
|
|
|
|
WireGuard VPN
|
|
|
|
|
+-----------------+-----------------+
|
|
| |
|
|
+-------+--------+ +---------+--------+
|
|
| Raspberry Pis | | Cloud / VPS |
|
|
| Heimnetz | | IONOS / Internet |
|
|
+----------------+ +------------------+
|
|
```
|
|
|
|
# Voraussetzungen
|
|
## Allgemein
|
|
Debian / Ubuntu basiertes Linux
|
|
Netzwerkzugriff auf den Gitea-Server
|
|
SSH-Key in Gitea hinterlegt
|
|
Git installiert
|
|
|
|
## Optional
|
|
Docker + Docker Compose
|
|
WireGuard VPN
|
|
|
|
# SSH-Key vorbereiten
|
|
## SSH-Key erzeugen
|
|
```
|
|
ssh-keygen -t ed25519
|
|
```
|
|
## Public Key anzeigen
|
|
```
|
|
cat ~/.ssh/id_ed25519.pub
|
|
```
|
|
## Key in Gitea hinzufügen
|
|
|
|
Gitea:
|
|
|
|
Profil -> Settings -> SSH Keys -> Add Key
|
|
|
|
---
|
|
|
|
# Git installieren
|
|
```
|
|
sudo apt update
|
|
sudo apt install git -y
|
|
```
|
|
---
|
|
|
|
# Repository klonen
|
|
## Standard
|
|
```
|
|
sudo mkdir -p /opt/pingu
|
|
sudo chown -R $USER:$USER /opt/pingu
|
|
git clone ssh://git@10.200.200.2:2222/kai/pingu-infra.git /opt/pingu/repo
|
|
```
|
|
---
|
|
# Verzeichnisstruktur
|
|
|
|
/opt/pingu/
|
|
├── logs/
|
|
│ ├── deploy.log
|
|
│ └── update.log
|
|
└── repo/
|
|
├── scripts/
|
|
├── docker/
|
|
└── configs/
|
|
|
|
---
|
|
|
|
# Deploy-Prozess
|
|
|
|
Das Deploy-Skript aktualisiert:
|
|
|
|
- Repository
|
|
- Skripte
|
|
- Berechtigungen
|
|
|
|
## Deploy manuell starten
|
|
```
|
|
bash /opt/pingu/repo/scripts/deploy.sh
|
|
```
|
|
# Deploy per Cronjob
|
|
## Raspberry / interne Systeme
|
|
```
|
|
*/15 * * * * /opt/pingu/repo/scripts/deploy.sh >> /opt/pingu/logs/deploy.log 2>&1
|
|
```
|
|
## Cloudserver
|
|
```
|
|
0 * * * * /opt/pingu/repo/scripts/deploy.sh >> /opt/pingu/logs/deploy.log 2>&1
|
|
```
|
|
Cronjob bearbeiten:
|
|
```
|
|
crontab -e
|
|
```
|
|
---
|
|
# Update-Prozess
|
|
|
|
Das Update-Skript:
|
|
|
|
- führt apt updates durch
|
|
- prüft Docker Updates
|
|
- aktualisiert Systempakete
|
|
- loggt Ergebnisse
|
|
## Manuell starten
|
|
```
|
|
- bash /opt/pingu/repo/scripts/update.sh
|
|
```
|
|
---
|
|
# Sudo-Rechte für Update-Skript
|
|
|
|
Damit apt ohne Passwort funktioniert:
|
|
```
|
|
sudo visudo
|
|
```
|
|
Hinzufügen:
|
|
```
|
|
kai ALL=(ALL) NOPASSWD: /usr/bin/apt, /usr/bin/apt-get
|
|
```
|
|
---
|
|
|
|
# WireGuard Setup (Cloudzugriff)
|
|
## Ziel
|
|
|
|
Cloudserver greifen sicher auf interne Dienste zu:
|
|
|
|
- Gitea
|
|
- Pi-hole
|
|
- Interne APIs
|
|
- Docker Services
|
|
|
|
---
|
|
|
|
# Beispiel Netzwerk
|
|
## Gerät WireGuard IP
|
|
Gitea/Home Server 10.200.200.2
|
|
Cloudserver 10.200.200.1
|
|
|
|
---
|
|
|
|
# Heimserver Config
|
|
|
|
Datei:
|
|
```
|
|
/etc/wireguard/wg0.conf
|
|
```
|
|
```
|
|
[Interface]
|
|
Address = 10.200.200.2/24
|
|
PrivateKey = HOME_PRIVATE_KEY
|
|
|
|
[Peer]
|
|
PublicKey = CLOUD_PUBLIC_KEY
|
|
AllowedIPs = 10.200.200.1/32
|
|
Endpoint = CLOUD_IP:51820
|
|
PersistentKeepalive = 25
|
|
```
|
|
Cloudserver Config
|
|
```
|
|
[Interface]
|
|
Address = 10.200.200.1/24
|
|
PrivateKey = CLOUD_PRIVATE_KEY
|
|
ListenPort = 51820
|
|
|
|
[Peer]
|
|
PublicKey = HOME_PUBLIC_KEY
|
|
AllowedIPs = 10.200.200.2/32
|
|
PersistentKeepalive = 25
|
|
```
|
|
---
|
|
|
|
# WireGuard starten
|
|
```
|
|
sudo systemctl enable wg-quick@wg0
|
|
sudo systemctl restart wg-quick@wg0
|
|
```
|
|
---
|
|
|
|
# Verbindung testen
|
|
```
|
|
ping 10.200.200.2
|
|
sudo wg
|
|
```
|
|
---
|
|
|
|
# Docker Systeme
|
|
## Docker installieren
|
|
```
|
|
sudo apt install docker.io docker-compose-plugin -y
|
|
```
|
|
---
|
|
|
|
# Docker Compose Update Workflow
|
|
## Compose-Verzeichnis öffnen
|
|
```
|
|
cd /opt/paperless
|
|
```
|
|
---
|
|
# Backup erstellen
|
|
## PostgreSQL Dump
|
|
```
|
|
sudo bash -c 'docker exec paperless-db-1 pg_dump -U paperless paperless > ~/paperless_backup.sql'
|
|
```
|
|
---
|
|
|
|
# Neue Images herunterladen
|
|
```
|
|
sudo docker compose pull
|
|
```
|
|
---
|
|
|
|
# Container neu erstellen
|
|
```
|
|
sudo docker compose up -d
|
|
```
|
|
---
|
|
|
|
# Status prüfen
|
|
```
|
|
sudo docker ps
|
|
```
|
|
---
|
|
|
|
# Logs prüfen
|
|
```
|
|
sudo docker logs -f paperless-webserver-1
|
|
```
|
|
---
|
|
|
|
# Docker Cleanup
|
|
|
|
Nicht mehr benötigte Images entfernen:
|
|
```
|
|
sudo docker image prune -a
|
|
```
|
|
---
|
|
# Logrotate
|
|
## Konfiguration erstellen
|
|
```
|
|
sudo nano /etc/logrotate.d/pingu-deploy
|
|
```
|
|
|
|
Inhalt:
|
|
```
|
|
/opt/pingu/logs/*.log {
|
|
weekly
|
|
rotate 4
|
|
compress
|
|
missingok
|
|
notifempty
|
|
copytruncate
|
|
}
|
|
```
|
|
---
|
|
|
|
# Nützliche Befehle
|
|
|
|
## Git Status
|
|
```
|
|
git -C /opt/pingu/repo status
|
|
```
|
|
## Remote prüfen
|
|
```
|
|
git -C /opt/pingu/repo remote -v
|
|
```
|
|
|
|
## Repository aktualisieren
|
|
```
|
|
git -C /opt/pingu/repo pull
|
|
```
|
|
## Docker Container anzeigen
|
|
```
|
|
sudo docker ps
|
|
```
|
|
## WireGuard Status
|
|
```
|
|
sudo wg
|
|
```
|
|
|
|
## Troubleshooting
|
|
Permission denied bei apt
|
|
|
|
Script nicht als root gestartet oder fehlende sudo-Regeln.
|
|
|
|
Git fragt nach Passwort
|
|
|
|
SSH-Key fehlt oder nicht in Gitea hinterlegt.
|
|
|
|
WireGuard kein Handshake
|
|
|
|
Prüfen:
|
|
|
|
Firewall
|
|
UDP 51820
|
|
Endpoint
|
|
AllowedIPs
|
|
Hinweise
|
|
Deploy-Skripte laufen absichtlich simpel.
|
|
Docker Updates werden bewusst nicht automatisch durchgeführt.
|
|
Produktivsysteme sollten vor Updates gesichert werden.
|
|
WireGuard ermöglicht sicheren Zugriff ohne öffentliche Freigaben interner Dienste.
|
|
Philosophie
|
|
|
|
Kleine Infrastruktur.
|
|
Wenig Overhead.
|
|
Maximal nachvollziehbar.
|
|
Lieber einfache Bash-Skripte als unnötige Komplexität.
|
|
|
|
# Logrotate
|
|
|
|
Die Deploy- und Update-Logs wachsen dauerhaft mit.
|
|
Um zu verhindern, dass Logdateien über Monate oder Jahre unendlich groß werden, wird logrotate verwendet.
|
|
|
|
Die Logrotate-Konfiguration wird zentral über das Git-Repository verteilt und automatisch installiert.
|
|
|
|
---
|
|
|
|
# Repository Struktur
|
|
|
|
```text
|
|
repo/
|
|
├── scripts/
|
|
│ ├── deploy.sh
|
|
│ ├── update.sh
|
|
│ └── install-logrotate.sh
|
|
│
|
|
├── configs/
|
|
│ └── logrotate/
|
|
│ └── pingu
|
|
Logrotate Konfiguration
|
|
|
|
Datei im Repository:
|
|
|
|
configs/logrotate/pingu
|
|
|
|
Inhalt:
|
|
|
|
/opt/pingu/logs/*.log {
|
|
weekly
|
|
rotate 4
|
|
compress
|
|
missingok
|
|
notifempty
|
|
copytruncate
|
|
}
|
|
Installationsskript
|
|
|
|
Datei:
|
|
|
|
scripts/install-logrotate.sh
|
|
|
|
Inhalt:
|
|
|
|
#!/bin/bash
|
|
|
|
set -euo pipefail
|
|
|
|
REPO_DIR="/opt/pingu/repo"
|
|
|
|
echo "[INFO] Installiere logrotate config..."
|
|
|
|
sudo cp "$REPO_DIR/configs/logrotate/pingu" /etc/logrotate.d/pingu
|
|
|
|
sudo chmod 644 /etc/logrotate.d/pingu
|
|
|
|
echo "[OK] Logrotate config installiert"
|
|
Integration in deploy.sh
|
|
|
|
Im deploy.sh wird das Installationsskript automatisch ausgeführt.
|
|
|
|
Beispiel:
|
|
|
|
echo "Install logrotate config..."
|
|
bash "$REPO_DIR/scripts/install-logrotate.sh"
|
|
|
|
Dadurch werden Änderungen an der Logrotate-Konfiguration automatisch auf alle Systeme verteilt.
|
|
|
|
Funktion
|
|
|
|
Die Konfiguration sorgt dafür:
|
|
|
|
Rotation einmal pro Woche
|
|
4 alte Logs werden behalten
|
|
alte Logs werden komprimiert
|
|
fehlende Logs erzeugen keinen Fehler
|
|
laufende Prozesse können weiterloggen
|
|
Logrotate testen
|
|
|
|
Konfiguration prüfen:
|
|
|
|
sudo logrotate -d /etc/logrotate.d/pingu
|
|
|
|
Rotation erzwingen:
|
|
|
|
sudo logrotate -f /etc/logrotate.d/pingu
|
|
Typische Logdateien
|
|
/opt/pingu/logs/deploy.log
|
|
/opt/pingu/logs/update.log
|
|
Vorteile dieses Ansatzes
|
|
zentrale Verwaltung über Git
|
|
automatische Verteilung
|
|
keine manuelle Pflege auf einzelnen Systemen
|
|
identisches Verhalten auf allen Hosts
|
|
leicht erweiterbar für weitere Systemconfigs |