7.1 KiB
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
+-------------------+
| 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
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