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