dev-int01/README.md
2026-09-07 14:44:49 +02:00

139 lines
No EOL
4 KiB
Markdown

touch README.md
git init
git checkout -b main
git add README.md
git commit -m "first commit"
git remote add origin http://10.100.20.13:3000/infra/xy-xy.git
git push -u origin main
und später dann nur noch mit git commit -m "" und git push... bzw. über das GUI
# dev-int01
`dev-int01` ist die zentrale Dev-/Git-VM fuer die interne Infrastruktur.
## Zweck der VM
Auf `dev-int01` laufen die Werkzeuge, mit denen Infrastruktur, Container-Stacks und Konfigurationen gepflegt werden.
Geplante bzw. genutzte Kernkomponenten:
- Forgejo als Git-Server
- code-server als browserbasierte Entwicklungsumgebung
- Arbeitsverzeichnisse fuer Infrastruktur-, Compose- und Konfigurationsdateien
- optionale Build-, Deploy- und Hilfsskripte
Damit ist `dev-int01` nicht die Laufzeitumgebung fuer produktive Dienste, sondern die zentrale Stelle fuer:
- Erfassen und Bearbeiten von Konfigurationen
- Versionierung in Git
- Dokumentation von Infrastruktur
- Vorbereitung von Deployments auf andere VMs
## Rolle im Gesamtbild
Im Zielbild ist `dev-int01` die Dev-/Git-VM im internen Servernetz. Die Rollen sind bewusst getrennt [1]:
- `dev-int01`: Entwicklung, Git, code-server, Forgejo
- `infra-int01`: interne Reverse-Proxy- und technische Infra-Dienste
- `mon01`: Monitoring und Logging
- weitere VMs: Apps, Media, Home Assistant, Mail
Das bedeutet:
- Auf `dev-int01` werden Compose-Dateien, Konfigurationen und Doku erstellt.
- Diese Inhalte werden in Forgejo versioniert.
- Andere VMs wie `infra-int01` oder `mon01` holen sich diese Inhalte spaeter per `git pull` und setzen sie lokal um.
## Grundprinzip
`dev-int01` ist die Quelle fuer deklarative Infrastrukturdateien.
Der gewuenschte Ablauf ist:
1. In `code-server` an einer lokalen Arbeitskopie arbeiten
2. Aenderungen in Git committen
3. Nach Forgejo pushen
4. Auf Ziel-VMs wie `infra-int01` oder `mon01` das Repository klonen oder aktualisieren
5. Dort mit `docker compose up -d` oder aehnlichen Befehlen ausrollen
Damit gilt:
- `code-server` = Editor und Arbeitsumgebung
- Forgejo = zentrales Git-Remote
- Ziel-VMs = Laufzeit- und Deployment-Ziele
## Nutzen von `dev-int01`
Die VM bringt mehrere Vorteile:
- zentrale Pflege von Infrastrukturdateien
- nachvollziehbare Aenderungen ueber Git-Historie
- reproduzierbare Deployments
- Trennung zwischen Entwicklung und produktivem Betrieb
- einfache Zusammenarbeit zwischen Editor, Git und Zielsystemen
Dadurch werden Aenderungen nicht "direkt auf Produktivsystemen zusammengeklickt", sondern zuerst sauber erfasst, versioniert und dann ausgerollt.
## Zusammenspiel von Forgejo, code-server und Infrastruktur
### Forgejo
Forgejo ist der interne Git-Server.
Dort liegen die Repositories fuer:
- VM-Konfigurationen
- Docker-Compose-Dateien
- nginx-/Proxy-Konfigurationen
- Monitoring-Konfigurationen
- Dokumentation
- Deploy-/Hilfsskripte
### code-server
`code-server` ist die Entwicklungsumgebung im Browser.
Dort werden lokale Arbeitskopien von Repositories geoeffnet und bearbeitet. `code-server` speichert selbst nicht "anstelle von Git", sondern arbeitet mit normalen lokalen Git-Repositories.
### Infrastruktur-VMs
VMs wie `infra-int01` und `mon01` verwenden die in Forgejo versionierten Dateien als Quelle fuer ihre Konfiguration.
Typischer Ablauf:
- Repo auf `dev-int01` in code-server bearbeiten
- Aenderungen nach Forgejo pushen
- auf Ziel-VM Repo pullen
- lokal deployen
## Empfohlener Workflow
### Entwicklung auf `dev-int01`
- Repository in Forgejo anlegen
- Repository lokal in den Workspace klonen
- Repository in `code-server` oeffnen
- Dateien bearbeiten
- committen
- pushen
### Deployment auf Ziel-VMs
- Repository auf Ziel-VM klonen
- bei Aenderungen `git pull`
- danach Dienste aktualisieren oder neu starten
## Verzeichnisidee
Beispielhaft getrennt nach Zweck:
```text
/srv
├── data
│ ├── code-server
│ ├── forgejo
│ └── mariadb-forgejo
├── git
│ └── repos
└── workspace
├── infra
├── web-dev
├── builds
└── scripts