Files
michaelschiemer/deployment/docs/server-directory-structure.md
Michael Schiemer 36ef2a1e2c
Some checks failed
🚀 Build & Deploy Image / Determine Build Necessity (push) Failing after 10m14s
🚀 Build & Deploy Image / Build Runtime Base Image (push) Has been skipped
🚀 Build & Deploy Image / Build Docker Image (push) Has been skipped
🚀 Build & Deploy Image / Run Tests & Quality Checks (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Staging (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Production (push) Has been skipped
Security Vulnerability Scan / Check for Dependency Changes (push) Failing after 11m25s
Security Vulnerability Scan / Composer Security Audit (push) Has been cancelled
fix: Gitea Traefik routing and connection pool optimization
- Remove middleware reference from Gitea Traefik labels (caused routing issues)
- Optimize Gitea connection pool settings (MAX_IDLE_CONNS=30, authentication_timeout=180s)
- Add explicit service reference in Traefik labels
- Fix intermittent 504 timeouts by improving PostgreSQL connection handling

Fixes Gitea unreachability via git.michaelschiemer.de
2025-11-09 14:46:15 +01:00

5.4 KiB

Server-Verzeichnisstruktur

Übersicht

Auf dem Production-Server (deploy@michaelschiemer) existieren zwei Hauptverzeichnisse im Home-Verzeichnis:

/home/deploy/
├── deployment/          # Infrastructure-as-Code (24M)
└── michaelschiemer/    # Application Code (491M)

Verzeichnis-Details

/home/deploy/deployment/ - Infrastructure Repository

Zweck: Enthält alle Deployment-Infrastruktur-Konfigurationen

Inhalt:

deployment/
├── stacks/             # Docker Compose Stacks
│   ├── traefik/       # Reverse Proxy & SSL
│   ├── gitea/         # Git Repository Server
│   ├── postgresql-production/
│   ├── postgresql-staging/
│   ├── production/    # Production Application Stack
│   ├── staging/       # Staging Application Stack
│   └── ...
└── backups/          # Backup-Dateien

Verwendet von:

  • Ansible Playbooks für Infrastructure-Deployment
  • Docker Compose für Container-Orchestrierung
  • Traefik für Service Discovery

Ansible Variable:

stacks_base_path: "/home/deploy/deployment/stacks"

Verwendung in Playbooks:

  • setup-infrastructure.yml - Deployt alle Docker Stacks
  • backup.yml - Erstellt Backups
  • sync-stacks.yml - Synchronisiert Stack-Konfigurationen

/home/deploy/michaelschiemer/ - Application Repository

Zweck: Enthält den eigentlichen Application-Code (PHP, Composer, etc.)

Inhalt:

michaelschiemer/
├── current/           # Symlink → Aktuelle deployed Version
│   ├── src/          # PHP Source Code
│   ├── vendor/       # Composer Dependencies
│   ├── composer.json
│   ├── worker.php
│   └── console.php
├── .archive/         # Alte Versionen (Rollback)
├── backups/          # Application-spezifische Backups
└── ...

Verwendet von:

  • Ansible Playbooks für Application-Deployment
  • Docker Container (gemountet als Volume)
  • PHP-FPM, Queue Workers, etc.

Ansible Variable:

application_code_dest: "/home/deploy/michaelschiemer/current"

Verwendung in Playbooks:

  • deploy-application-code.yml - Deployt neuen Application Code
  • sync-application-code.yml - Synchronisiert Code
  • install-composer-dependencies.yml - Installiert Dependencies

Warum zwei Verzeichnisse?

Trennung von Concerns

  1. Infrastructure (deployment/)

    • Ändert sich selten
    • Wird von DevOps verwaltet
    • Enthält Docker, Traefik, Datenbanken, etc.
  2. Application (michaelschiemer/)

    • Ändert sich häufig (bei jedem Deployment)
    • Wird von Entwicklern verwaltet
    • Enthält Business-Logic, PHP-Code, etc.

Vorteile

  • Klarere Verantwortlichkeiten: Infrastructure vs. Application
  • Einfacheres Backup: Separate Backups für Infrastructure und Code
  • Bessere Skalierung: Infrastructure kann unabhängig vom Code aktualisiert werden
  • Rollback-Möglichkeiten: Alte Application-Versionen in .archive/

Deployment-Workflow

Infrastructure Deployment

# Infrastructure wird aus lokalem Repository deployed
ansible-playbook -i inventory/production.yml \
  playbooks/setup-infrastructure.yml \
  --vault-password-file secrets/.vault_pass

Was passiert:

  1. Ansible kopiert deployment/stacks/ auf den Server
  2. Docker Compose startet Container basierend auf Stack-Konfigurationen
  3. Traefik entdeckt Services via Docker Labels

Application Deployment

# Application Code wird aus Gitea deployed
ansible-playbook -i inventory/production.yml \
  playbooks/deploy-application-code.yml \
  --vault-password-file secrets/.vault_pass

Was passiert:

  1. Ansible klont/pullt Code aus Gitea
  2. Code wird nach ~/michaelschiemer/current/ deployed
  3. Composer installiert Dependencies
  4. Docker Container werden neu gestartet (mit neuem Code)

Verzeichnis-Größen

# Aktuelle Größen (Stand: 2025-11-08)
24M    /home/deploy/deployment      # Infrastructure
491M   /home/deploy/michaelschiemer  # Application Code

Hinweis: Die Application ist größer, da sie Composer Dependencies (vendor/) enthält.


Wartung

Prüfen, ob beide Verzeichnisse existieren

ssh deploy@michaelschiemer.de
ls -la ~/deployment ~/michaelschiemer
ls -la ~/michaelschiemer/current
# Sollte zeigen: current -> /path/to/version

Verzeichnis-Größen prüfen

du -sh ~/deployment ~/michaelschiemer

Troubleshooting

Lösung:

# Manuell erstellen oder Playbook ausführen
ansible-playbook -i inventory/production.yml \
  playbooks/deploy-application-code.yml

Problem: Verzeichnis zu groß

Lösung:

# Alte Versionen aufräumen
rm -rf ~/michaelschiemer/.archive/*
# Composer Cache leeren
rm -rf ~/michaelschiemer/cache/*

Problem: Beide Verzeichnisse fehlen

Lösung:

# Infrastructure deployen
ansible-playbook -i inventory/production.yml \
  playbooks/setup-infrastructure.yml

# Application deployen
ansible-playbook -i inventory/production.yml \
  playbooks/deploy-application-code.yml

Siehe auch