chore: sync staging workspace
This commit is contained in:
551
deployment/docs/guides/code-change-workflow.md
Normal file
551
deployment/docs/guides/code-change-workflow.md
Normal file
@@ -0,0 +1,551 @@
|
||||
# Codeänderungen pushen und deployen
|
||||
|
||||
## Übersicht
|
||||
|
||||
Dieses Dokument erklärt, wie Codeänderungen gepusht werden und automatisch in Production deployed werden.
|
||||
|
||||
**Quick Start:**
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "feat: Add new feature"
|
||||
git push origin main
|
||||
```
|
||||
→ Automatisches Deployment startet (~8-15 Minuten)
|
||||
|
||||
**📖 Verwandte Dokumentation:**
|
||||
- **[Application Stack Deployment](../reference/application-stack.md)** - Wie das Deployment genau funktioniert
|
||||
- **[CI/CD Status](../status/ci-cd-status.md)** - Aktueller Status der Pipeline
|
||||
|
||||
---
|
||||
|
||||
## Normaler Workflow: Codeänderungen deployen
|
||||
|
||||
### Schritt 1: Code lokal ändern
|
||||
|
||||
```bash
|
||||
# Änderungen in deinem lokalen Repository machen
|
||||
# z.B. Datei bearbeiten: src/App/Controller/HomeController.php
|
||||
|
||||
# Änderungen anzeigen
|
||||
git status
|
||||
|
||||
# Änderungen anschauen
|
||||
git diff
|
||||
```
|
||||
|
||||
### Schritt 2: Änderungen committen
|
||||
|
||||
```bash
|
||||
# Änderungen zum Staging hinzufügen
|
||||
git add .
|
||||
|
||||
# Oder nur spezifische Dateien
|
||||
git add src/App/Controller/HomeController.php
|
||||
|
||||
# Commit erstellen
|
||||
git commit -m "feat: Add new feature to home controller"
|
||||
```
|
||||
|
||||
**Commit-Message Konventionen:**
|
||||
- `feat:` - Neue Feature
|
||||
- `fix:` - Bug-Fix
|
||||
- `refactor:` - Code-Refactoring
|
||||
- `docs:` - Dokumentation
|
||||
- `test:` - Tests
|
||||
- `chore:` - Wartungsaufgaben
|
||||
|
||||
### Schritt 3: Code zu Gitea pushen
|
||||
|
||||
```bash
|
||||
# Zu main branch pushen (triggert automatisches Deployment)
|
||||
git push origin main
|
||||
|
||||
# Oder zu anderem Branch pushen (kein Auto-Deploy)
|
||||
git push origin feature/new-feature
|
||||
```
|
||||
|
||||
### Schritt 4: Automatisches Deployment
|
||||
|
||||
**Was passiert automatisch:**
|
||||
|
||||
1. **Git Push** → Gitea erhält den Push
|
||||
2. **Workflow wird getriggert** (bei Push zu `main` Branch)
|
||||
3. **CI/CD Pipeline startet:**
|
||||
- Tests laufen
|
||||
- Docker Image wird gebaut
|
||||
- Image wird zur Registry gepusht
|
||||
- Ansible Deployment wird ausgeführt
|
||||
- Application Stack wird aktualisiert
|
||||
|
||||
**Zeitdauer:** ~8-15 Minuten für komplettes Deployment
|
||||
|
||||
---
|
||||
|
||||
## Deployment-Trigger
|
||||
|
||||
### Automatisches Deployment (bei Push zu `main`)
|
||||
|
||||
**Workflow:** `.gitea/workflows/production-deploy.yml`
|
||||
|
||||
```yaml
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
paths-ignore:
|
||||
- 'docs/**'
|
||||
- '**.md'
|
||||
- '.github/**'
|
||||
```
|
||||
|
||||
**Bedeutung:**
|
||||
- ✅ Push zu `main` Branch → Deployment startet automatisch
|
||||
- ❌ Push zu anderen Branches → Kein Deployment
|
||||
- ❌ Push nur von Markdown-Dateien → Kein Deployment (wegen `paths-ignore`)
|
||||
|
||||
**Beispiel:**
|
||||
```bash
|
||||
# Triggert Deployment
|
||||
git push origin main
|
||||
|
||||
# Triggert KEIN Deployment (nur Markdown)
|
||||
git commit -m "docs: Update README" --only README.md
|
||||
git push origin又问
|
||||
|
||||
# Triggert KEIN Deployment (anderer Branch)
|
||||
git checkout -b feature/new-feature
|
||||
git push origin feature/new-feature
|
||||
```
|
||||
|
||||
### Manuelles Deployment (Workflow-Dispatch)
|
||||
|
||||
**Workflow kann manuell gestartet werden:**
|
||||
|
||||
1. Gehe zu: `https://git.michaelschiemer.de/michael/michaelschiemer/actions`
|
||||
2. Wähle: "Production Deployment Pipeline"
|
||||
3. Klicke: "Run workflow"
|
||||
4. Wähle Branch (z.B. `main` oder anderer Branch)
|
||||
5. Optionale Einstellungen:
|
||||
- `skip_tests`: `true` (nur in Notfällen!)
|
||||
6. Klicke: "Run workflow"
|
||||
|
||||
**Verwendung:**
|
||||
- Deployment von anderem Branch (z.B. `develop`, `staging`)
|
||||
- Deployment ohne Code-Änderung (z.B. nach Config-Änderung)
|
||||
- Notfall-Deployment mit `skip_tests: true`
|
||||
|
||||
---
|
||||
|
||||
## Workflow-Details
|
||||
|
||||
### Was passiert bei jedem Push zu `main`?
|
||||
|
||||
#### Job 1: Tests (ca. 2-5 Minuten)
|
||||
|
||||
```yaml
|
||||
- PHP 8.3 Setup
|
||||
- Composer Dependencies installieren
|
||||
- Pest Tests ausführen
|
||||
- PHPStan Code Quality Check
|
||||
- Code Style Check (composer cs)
|
||||
```
|
||||
|
||||
**Bei Fehler:** Pipeline stoppt, kein Deployment
|
||||
|
||||
#### Job 2: Build (ca. 3-5 Minuten)
|
||||
|
||||
```yaml
|
||||
- Docker Buildx Setup
|
||||
- Image Metadata generieren (Tag: <short-sha>-<timestamp>)
|
||||
- Docker Image Build (Dockerfile.production)
|
||||
- Image mit Tags pushen:
|
||||
- registry.michaelschiemer.de/framework:latest
|
||||
- registry.michaelschiemer.de/framework:<tag>
|
||||
- registry.michaelschiemer.de/framework:git-<short-sha>
|
||||
```
|
||||
|
||||
#### Job 3: Deploy (ca. 2-4 Minuten)
|
||||
|
||||
```yaml
|
||||
- SSH Setup (mit Secret)
|
||||
- Ansible Installation
|
||||
- Ansible Playbook ausführen:
|
||||
- Image Pull
|
||||
- docker-compose.yml Update
|
||||
- Stack Neustart
|
||||
- Health-Check (10x versuche)
|
||||
- Rollback bei Fehler
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Branching-Strategie
|
||||
|
||||
### Empfohlener Workflow
|
||||
|
||||
```
|
||||
main (Production)
|
||||
↓
|
||||
develop (Entwicklung/Testing)
|
||||
↓
|
||||
feature/* (Feature Branches)
|
||||
```
|
||||
|
||||
### Workflow-Beispiele
|
||||
|
||||
#### 1. Feature entwickeln
|
||||
|
||||
```bash
|
||||
# Feature Branch erstellen
|
||||
git checkout -b feature/user-authentication
|
||||
|
||||
# Änderungen machen
|
||||
# ... Code schreiben ...
|
||||
|
||||
# Committen
|
||||
git add .
|
||||
git commit -m "feat: Add user authentication"
|
||||
|
||||
# Zu Gitea pushen (kein Auto-Deploy)
|
||||
git push origin feature/user-authentication
|
||||
|
||||
# Pull Request erstellen in Gitea
|
||||
# → Code Review
|
||||
# → Merge zu develop (oder main)
|
||||
```
|
||||
|
||||
#### 2. Direkt zu Production deployen
|
||||
|
||||
```bash
|
||||
# Änderungen lokal
|
||||
git checkout main
|
||||
# ... Änderungen machen ...
|
||||
git add .
|
||||
git commit -m "fix: Critical bug fix"
|
||||
|
||||
# Pushen → Triggert automatisches Deployment
|
||||
git push origin main
|
||||
|
||||
# Pipeline läuft automatisch:
|
||||
# ✅ Tests
|
||||
# ✅ Build
|
||||
# ✅ Deploy
|
||||
```
|
||||
|
||||
#### 3. Hotfix (Notfall)
|
||||
|
||||
```bash
|
||||
# Hotfix Branch von main
|
||||
git checkout -b hotfix/critical-security-fix main
|
||||
|
||||
# Fix implementieren
|
||||
# ... Code schreiben ...
|
||||
git add .
|
||||
git commit -m "fix: Critical security vulnerability"
|
||||
|
||||
# Direkt zu main mergen
|
||||
git checkout main
|
||||
git merge hotfix/critical-security-fix Ker
|
||||
|
||||
# Pushen → Auto-Deploy
|
||||
git push origin main
|
||||
|
||||
# Optional: Manuelles Deployment mit skip_tests
|
||||
# (nur wenn Tests lokal bereits erfolgreich)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Deployment-Status prüfen
|
||||
|
||||
### 1. Pipeline-Status in Gitea
|
||||
|
||||
```
|
||||
https://git.michaelschiemer.de/michael/michaelschiemer/actions
|
||||
```
|
||||
|
||||
**Status-Anzeigen:**
|
||||
- 🟢 Grüner Haken = Erfolgreich
|
||||
- 🔴 Roter Haken = Fehlgeschlagen
|
||||
- 🟡 Gelber Kreis = Läuft gerade
|
||||
|
||||
### 2. Logs ansehen
|
||||
|
||||
1. Gehe zu Actions
|
||||
2. Klicke auf den Workflow-Run
|
||||
3. Klicke auf Job (z.B. "Deploy to Production Server")
|
||||
4. Klicke auf Step (z.B. "Deploy via Ansible")
|
||||
5. Logs ansehen
|
||||
|
||||
### 3. Application-Status prüfen
|
||||
|
||||
```bash
|
||||
# SSH zum Production-Server
|
||||
ssh deploy@94.16.110.151
|
||||
|
||||
# Container-Status prüfen
|
||||
cd ~/deployment/stacks/application
|
||||
docker compose ps
|
||||
|
||||
# Logs ansehen
|
||||
docker compose logs -f app
|
||||
|
||||
# Health-Check manuell
|
||||
curl https://michaelschiemer.de/health
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Deployment verhindern
|
||||
|
||||
### Temporäres Deployment verhindern
|
||||
|
||||
**Option 1: Push zu anderem Branch**
|
||||
```bash
|
||||
# Entwickle auf Feature-Branch
|
||||
git checkout -b feature/my-feature
|
||||
git push origin feature/my-feature
|
||||
# → Kein Auto-Deploy
|
||||
```
|
||||
|
||||
**Option CT 2: [skip ci] in Commit-Message**
|
||||
```bash
|
||||
# Workflow wird übersprungen
|
||||
git commit -m "docs: Update documentation [skip ci]"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
**Hinweis:** `[skip ci]` wird aktuell **nicht** unterstützt, da kein entsprechender Filter im Workflow ist.
|
||||
|
||||
### Deployment-Trigger deaktivieren
|
||||
|
||||
**Temporär (Workflow anpassen):**
|
||||
```yaml
|
||||
# In .gitea/workflows/production-deploy.yml
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
# workflow_dispatch: # Kommentiere aus für temporäres Deaktivieren
|
||||
```
|
||||
|
||||
**Besser:** Nutze Feature-Branches für Entwicklung ohne Auto-Deploy.
|
||||
|
||||
---
|
||||
|
||||
## Häufige Szenarien
|
||||
|
||||
### Szenario 1: Kleine Bug-Fix
|
||||
|
||||
```bash
|
||||
# 1. Bug-Fix lokal implementieren
|
||||
git checkout main
|
||||
# ... Fix implementieren ...
|
||||
git add .
|
||||
git commit -m "fix: Resolve login issue"
|
||||
|
||||
# 2. Pushen → Auto-Deploy
|
||||
git push origin main
|
||||
|
||||
# 3. Pipeline beobachten
|
||||
# → Tests ✅
|
||||
# → Build ✅
|
||||
# → Deploy ✅
|
||||
|
||||
# 4. Verifizieren
|
||||
curl https://michaels chasing.de/health
|
||||
```
|
||||
|
||||
### Szenario 2: Große Feature-Entwicklung
|
||||
|
||||
```bash
|
||||
# 1. Feature-Branch erstellen
|
||||
git checkout -b feature/new-dashboard
|
||||
|
||||
# 2. Feature entwickeln
|
||||
# ... viele Commits ...
|
||||
|
||||
# 3. Regelmäßig pushen (kein Auto-Deploy)
|
||||
git push origin feature/new-dashboard
|
||||
|
||||
# 4. Pull Request erstellen in Gitea
|
||||
# → Code Review
|
||||
# → Diskussion
|
||||
|
||||
# 5. Merge zu main (triggert Auto-Deploy)
|
||||
# → Via Gitea UI: "Merge Pull Request"
|
||||
# → Oder lokal:
|
||||
git checkout main
|
||||
git merge feature/new-dashboard
|
||||
git push origin main
|
||||
```
|
||||
|
||||
### Szenario 3: Config-Änderung ohne Code-Änderung
|
||||
|
||||
```bash
|
||||
# Beispiel: .env Variablen ändern
|
||||
# (wird über Ansible Template generiert, daher direkt auf Server ändern)
|
||||
|
||||
# Oder: docker-compose.yml anpassen
|
||||
# Änderungen machen
|
||||
git add .
|
||||
git commit -m "chore: Update docker-compose configuration"
|
||||
git push origin main
|
||||
|
||||
# → Pipeline läuft
|
||||
# → Build: Keine Code-Änderung, aber Image wird neu getaggt
|
||||
# → Deploy: docker-compose.yml wird aktualisiert
|
||||
```
|
||||
|
||||
### Szenario 4: Notfall-Rollback
|
||||
|
||||
```bash
|
||||
# Option 1: Rollback via Ansible Playbook
|
||||
cd deployment/ansible
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/rollback.yml \
|
||||
-e "rollback_timestamp=2025-10-31T01-20-15Z"
|
||||
|
||||
# Option 2: Alten Commit pushen
|
||||
git log --oneline
|
||||
# Finde letzten funktionierenden Commit
|
||||
git checkout <commit-hash>
|
||||
git checkout -b rollback/previous-version
|
||||
git push origin rollback/previous-version
|
||||
|
||||
# Manuell zu main mergen oder direkt:
|
||||
git checkout main
|
||||
git reset --hard <commit-hash>
|
||||
git push origin main --force # ⚠️ Vorsicht!
|
||||
# → Triggert Auto-Deploy mit altem Code
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Commits
|
||||
|
||||
- ✅ Klare, beschreibende Commit-Messages
|
||||
entweder
|
||||
- ✅ Atomic Commits (ein Feature = ein Commit)
|
||||
- ✅ Regelmäßig pushen (nicht alles auf einmal)
|
||||
|
||||
### 2. Testing
|
||||
|
||||
- ✅ Tests lokal ausführen vor Push:
|
||||
```bash
|
||||
composer cs # Code Style
|
||||
make phpstan # Static Analysis
|
||||
./vendor/bin/pest # Tests
|
||||
```
|
||||
|
||||
### 3. Deployment
|
||||
|
||||
- ✅ **Niemals** direkt zu `main` pushen ohne lokale Tests
|
||||
- ✅ Feature-Branches für größere Änderungen
|
||||
- ✅ Pull Requests für Code Review
|
||||
- ✅ Pipeline-Status beobachten nach Push
|
||||
|
||||
### 4. Rollback-Plan
|
||||
|
||||
- ✅ Immer Backup vor größeren Änderungen
|
||||
- ✅ Rollback-Playbook bereit halten
|
||||
- ✅ Deployment-Metadaten dokumentieren
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Pipeline schlägt fehl
|
||||
|
||||
**Problem:** Tests fehlgeschlagen
|
||||
```bash
|
||||
# Tests lokal ausführen
|
||||
./vendor/bin/pest
|
||||
|
||||
# Fehler beheben
|
||||
# ... Code anpassen ...
|
||||
git add .
|
||||
git commit -m "fix: Fix failing tests"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
**Problem:** Build fehlgeschlagen
|
||||
```bash
|
||||
# Docker Build lokal testen
|
||||
docker build -f Dockerfile.production -t test-image .
|
||||
|
||||
# Fehler beheben
|
||||
# ... Dockerfile anpassen ...
|
||||
git add .
|
||||
git commit -m "fix: Fix Docker build"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
**Problem:** Deployment fehlgeschlagen
|
||||
```bash
|
||||
# SSH zum Server
|
||||
ssh deploy@94.16.110.151
|
||||
|
||||
# Logs prüfen
|
||||
cd ~/deployment/stacks/application
|
||||
docker compose logs app
|
||||
|
||||
# Manuell rollback
|
||||
cd ~/deployment/ansible
|
||||
ansible-playbook -i inventory/production.yml playbooks/rollback.yml
|
||||
```
|
||||
|
||||
### Deployment läuft zu lange
|
||||
|
||||
**Pipeline hängt:**
|
||||
- Prüfe Runner-Status: `docker compose ps` in `deployment/gitea-runner`
|
||||
- Prüfe Runner-Logs: `docker compose logs gitea-runner`
|
||||
- Prüfe Workflow-Logs in Gitea UI
|
||||
|
||||
**Deployment hängt:**
|
||||
- Prüfe Server-Status: `ssh deploy@94.16.110.151 "docker ps"`
|
||||
- Prüfe Container-Logs: `docker compose logs`
|
||||
- Prüfe Disk-Space: `df -h`
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
### Normaler Workflow
|
||||
|
||||
1. **Code ändern** lokal
|
||||
2. **Committen** mit klarer Message
|
||||
3. **Push zu `main`** → Auto-Deploy startet
|
||||
4. **Pipeline beobachten** in Gitea Actions
|
||||
5. **Verifizieren** auf Production
|
||||
|
||||
### Wichtige Commands
|
||||
|
||||
```bash
|
||||
# Änderungen pushen (triggert Auto-Deploy)
|
||||
git push origin main
|
||||
|
||||
# Feature entwickeln (kein Auto-Deploy)
|
||||
git checkout -b feature/my-feature
|
||||
git push origin feature/my-feature
|
||||
|
||||
# Pipeline-Status prüfen
|
||||
# → https://git.michaelschiemer.de/michael/michaelschiemer/actions
|
||||
|
||||
# Application-Status prüfen
|
||||
ssh deploy@94.16.110.151 "cd ~/deployment/stacks/application && docker compose ps"
|
||||
```
|
||||
|
||||
### Deployment-Zeit
|
||||
|
||||
- **Gesamt:** ~8-15 Minuten
|
||||
- **Tests:** ~2-5 Minuten
|
||||
- **Build:** ~3-5 Minuten
|
||||
- **Deploy:** ~2-4 Minuten
|
||||
- **Health-Check:** ~1 Minute
|
||||
|
||||
---
|
||||
|
||||
**Ready to deploy!** 🚀
|
||||
151
deployment/docs/guides/deployment-commands.md
Normal file
151
deployment/docs/guides/deployment-commands.md
Normal file
@@ -0,0 +1,151 @@
|
||||
# Deployment Commands - Quick Reference
|
||||
|
||||
Alle Deployment-Operationen werden über **Ansible Playbooks** durchgeführt.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Häufig verwendete Commands
|
||||
|
||||
### Code deployen (Image-basiert)
|
||||
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/deploy-update.yml \
|
||||
-e "image_tag=abc1234-1696234567" \
|
||||
-e "git_commit_sha=$(git rev-parse HEAD)"
|
||||
```
|
||||
|
||||
### Code synchen (Git-basiert)
|
||||
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/sync-code.yml \
|
||||
-e "git_branch=main"
|
||||
```
|
||||
|
||||
### Rollback zu vorheriger Version
|
||||
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/rollback.yml
|
||||
```
|
||||
|
||||
### Infrastructure Setup (einmalig)
|
||||
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/setup-infrastructure.yml
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📋 Alle verfügbaren Playbooks
|
||||
|
||||
### Deployment & Updates
|
||||
|
||||
- **`playbooks/deploy-update.yml`** - Deployt neues Docker Image
|
||||
- **`playbooks/sync-code.yml`** - Synchronisiert Code aus Git Repository
|
||||
- **`playbooks/rollback.yml`** - Rollback zu vorheriger Version
|
||||
|
||||
### Infrastructure Setup
|
||||
|
||||
- **`playbooks/setup-infrastructure.yml`** - Deployed alle Stacks (Traefik, PostgreSQL, Registry, Gitea, Monitoring, Application)
|
||||
- **`playbooks/setup-production-secrets.yml`** - Deployed Secrets zu Production
|
||||
- **`playbooks/setup-ssl-certificates.yml`** - SSL Certificate Setup
|
||||
- **`playbooks/sync-stacks.yml`** - Synchronisiert Stack-Konfigurationen
|
||||
|
||||
### Troubleshooting & Maintenance
|
||||
|
||||
- **`playbooks/troubleshoot.yml`** - Unified Troubleshooting Playbook mit Tags
|
||||
```bash
|
||||
# Nur Diagnose
|
||||
ansible-playbook ... troubleshoot.yml --tags diagnose
|
||||
|
||||
# Health Check prüfen
|
||||
ansible-playbook ... troubleshoot.yml --tags health,check
|
||||
|
||||
# Health Checks fixen
|
||||
ansible-playbook ... troubleshoot.yml --tags health,fix
|
||||
|
||||
# Nginx 404 fixen
|
||||
ansible-playbook ... troubleshoot.yml --tags nginx,404,fix
|
||||
|
||||
# Alles ausführen
|
||||
ansible-playbook ... troubleshoot.yml --tags all
|
||||
```
|
||||
|
||||
### VPN
|
||||
|
||||
- **`playbooks/setup-wireguard.yml`** - WireGuard VPN Setup
|
||||
- **`playbooks/add-wireguard-client.yml`** - WireGuard Client hinzufügen
|
||||
|
||||
### CI/CD
|
||||
|
||||
- **`playbooks/setup-gitea-runner-ci.yml`** - Gitea Runner CI Setup
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Ansible Variablen
|
||||
|
||||
### Häufig verwendete Extra Variables
|
||||
|
||||
```bash
|
||||
# Image Tag für Deployment
|
||||
-e "image_tag=abc1234-1696234567"
|
||||
|
||||
# Git Branch für Code Sync
|
||||
-e "git_branch=main"
|
||||
-e "git_repo_url=https://git.michaelschiemer.de/michael/michaelschiemer.git"
|
||||
|
||||
# Registry Credentials (wenn nicht im Vault)
|
||||
-e "docker_registry_username=admin"
|
||||
-e "docker_registry_password=secret"
|
||||
|
||||
# Dry Run (Check Mode)
|
||||
--check
|
||||
|
||||
# Verbose Output
|
||||
-v # oder -vv, -vvv für mehr Details
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📖 Vollständige Dokumentation
|
||||
|
||||
- **[README.md](../../README.md)** - Haupt-Dokumentation
|
||||
- **[quick-start.md](quick-start.md)** - Schnellstart-Guide
|
||||
- **[code-change-workflow.md](code-change-workflow.md)** - Codeänderungen workflow
|
||||
|
||||
---
|
||||
|
||||
## 💡 Tipps
|
||||
|
||||
### Vault Passwort setzen
|
||||
|
||||
```bash
|
||||
export ANSIBLE_VAULT_PASSWORD_FILE=~/.ansible/vault_pass
|
||||
# oder
|
||||
ansible-playbook ... --vault-password-file ~/.ansible/vault_pass
|
||||
```
|
||||
|
||||
### Nur bestimmte Tasks ausführen
|
||||
|
||||
```bash
|
||||
ansible-playbook ... --tags "deploy,restart"
|
||||
```
|
||||
|
||||
### Check Mode (Dry Run)
|
||||
|
||||
```bash
|
||||
ansible-playbook ... --check --diff
|
||||
```
|
||||
|
||||
### Inventory prüfen
|
||||
|
||||
```bash
|
||||
ansible -i inventory/production.yml production -m ping
|
||||
```
|
||||
192
deployment/docs/guides/quick-start.md
Normal file
192
deployment/docs/guides/quick-start.md
Normal file
@@ -0,0 +1,192 @@
|
||||
# Quick Start Guide - Deployment & CI/CD
|
||||
|
||||
## 🚀 Schnellstart: Code deployen
|
||||
|
||||
### Einfachste Methode
|
||||
|
||||
```bash
|
||||
# 1. Code ändern
|
||||
# ... Dateien bearbeiten ...
|
||||
|
||||
# 2. Committen
|
||||
git add .
|
||||
git commit -m "feat: Add new feature"
|
||||
|
||||
# 3. Pushen → Automatisches Deployment!
|
||||
git push origin main
|
||||
```
|
||||
|
||||
**Das war's!** Die Pipeline läuft automatisch (~8-15 Minuten).
|
||||
|
||||
---
|
||||
|
||||
## 📋 Status-Übersicht
|
||||
|
||||
### ✅ Vollständig konfiguriert
|
||||
|
||||
- ✅ **CI/CD Pipeline** - Automatisches Deployment bei Push zu `main`
|
||||
- ✅ **Gitea Runner** - Läuft und ist registriert
|
||||
- ✅ **Secrets** - Alle kritischen Secrets konfiguriert
|
||||
- ✅ **Application Stack** - Integration in `setup-infrastructure.yml`
|
||||
- ✅ **Ansible Playbooks** - Deployment & Rollback vorhanden
|
||||
|
||||
### ⚠️ Ausstehend
|
||||
|
||||
- [ ] **Pipeline testen** - End-to-End Test durchführen
|
||||
- [ ] **Backup-Scripts** - Backup-Playbook erstellen
|
||||
- [ ] **Dokumentation vervollständigen** - Finale Updates
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Pipeline-Status prüfen
|
||||
|
||||
### Nach einem Push
|
||||
|
||||
**Gitea Actions UI:**
|
||||
```
|
||||
https://git.michaelschiemer.de/michael/michaelschiemer/actions
|
||||
```
|
||||
|
||||
**Status-Anzeigen:**
|
||||
- 🟢 Grüner Haken = Erfolgreich
|
||||
- 🔴 Roter Haken = Fehlgeschlagen
|
||||
- 🟡 Gelber Kreis = Läuft gerade
|
||||
|
||||
**Logs ansehen:**
|
||||
1. Klicke auf den Workflow-Run
|
||||
2. Klicke auf Job (z.B. "Deploy to Production Server")
|
||||
3. Klicke auf Step (z.B. "Deploy via Ansible")
|
||||
4. Logs ansehen
|
||||
|
||||
### Application-Status prüfen
|
||||
|
||||
```bash
|
||||
# SSH zum Production-Server
|
||||
ssh deploy@94.16.110.151
|
||||
|
||||
# Container-Status
|
||||
cd ~/deployment/stacks/application
|
||||
docker compose ps
|
||||
|
||||
# Logs ansehen
|
||||
docker compose logs app
|
||||
|
||||
# Health-Check
|
||||
curl https://michaelschiemer.de/health
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📚 Vollständige Dokumentation
|
||||
|
||||
### Deployment-Dokumentation
|
||||
|
||||
- **`CODE_CHANGE_WORKFLOW.md`** - Wie Codeänderungen gepusht werden
|
||||
- **`APPLICATION_STACK_DEPLOYMENT.md`** - Detaillierter Deployment-Ablauf
|
||||
- **`CI_CD_STATUS.md`** - CI/CD Pipeline Status & Checkliste
|
||||
- **`DEPLOYMENT-TODO.md`** - Aktuelle TODO-Liste
|
||||
|
||||
### Setup-Dokumentation
|
||||
|
||||
- **`docs/guides/setup-guide.md`** - Kompletter Setup-Guide
|
||||
- **`ansible/README.md`** - Ansible Playbooks Dokumentation
|
||||
- **`stacks/application/README.md`** - Application Stack Details
|
||||
|
||||
### Workflow-Dokumentation
|
||||
|
||||
- **`.gitea/workflows/production-deploy.yml`** - Haupt-Deployment-Pipeline
|
||||
- **`.gitea/workflows/TEST_WORKFLOW.md`** - Workflow-Test-Anleitung
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Nächste Schritte
|
||||
|
||||
### 1. Pipeline testen (Empfohlen)
|
||||
|
||||
**Option A: Test-Commit pushen**
|
||||
```bash
|
||||
# Kleine Änderung
|
||||
echo "# Test" >> README.md
|
||||
git add README.md
|
||||
git commit -m "test: CI/CD pipeline test"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
**Option B: Workflow manuell triggern**
|
||||
```
|
||||
https://git.michaelschiemer.de/michael/michaelschiemer/actions
|
||||
→ "Production Deployment Pipeline"
|
||||
→ "Run workflow"
|
||||
```
|
||||
|
||||
### 2. Backup-Scripts erstellen
|
||||
|
||||
```bash
|
||||
# Backup-Playbook erstellen
|
||||
cd deployment/ansible/playbooks
|
||||
# → Erstelle backup.yml
|
||||
```
|
||||
|
||||
### 3. Dokumentation finalisieren
|
||||
|
||||
- Finale Updates in `DEPLOYMENT-STATUS.md`
|
||||
- README aktualisieren
|
||||
|
||||
---
|
||||
|
||||
## 🆘 Troubleshooting
|
||||
|
||||
### Pipeline schlägt fehl
|
||||
|
||||
**Tests fehlgeschlagen:**
|
||||
```bash
|
||||
# Tests lokal ausführen
|
||||
./vendor/bin/pest
|
||||
composer cs
|
||||
make phpstan
|
||||
```
|
||||
|
||||
**Build fehlgeschlagen:**
|
||||
```bash
|
||||
# Docker Build lokal testen
|
||||
docker build -f Dockerfile.production -t test .
|
||||
```
|
||||
|
||||
**Deployment fehlgeschlagen:**
|
||||
```bash
|
||||
# Logs prüfen
|
||||
ssh deploy@94.16.110.151 "cd ~/deployment/stacks/application && docker compose logs"
|
||||
|
||||
# Manueller Rollback
|
||||
cd deployment/ansible
|
||||
ansible-playbook -i inventory/production.yml playbooks/rollback.yml
|
||||
```
|
||||
|
||||
### Runner-Probleme
|
||||
|
||||
```bash
|
||||
# Runner-Status prüfen
|
||||
cd deployment/gitea-runner
|
||||
docker compose ps
|
||||
docker compose logs gitea-runner
|
||||
|
||||
# Runner neu starten
|
||||
docker compose restart gitea-runner
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📞 Support
|
||||
|
||||
**Dokumentation:**
|
||||
- `deployment/README.md` - Haupt-Dokumentation
|
||||
- `deployment/CI_CD_STATUS.md` - CI/CD Details
|
||||
- `deployment/CODE_CHANGE_WORKFLOW.md` - Workflow-Guide
|
||||
|
||||
**Gitea:**
|
||||
- Actions: `https://git.michaelschiemer.de/michael/michaelschiemer/actions`
|
||||
- Runners: `https://git.michaelschiemer.de/admin/actions/runners`
|
||||
|
||||
---
|
||||
|
||||
**Ready to deploy!** 🚀
|
||||
793
deployment/docs/guides/setup-guide.md
Normal file
793
deployment/docs/guides/setup-guide.md
Normal file
@@ -0,0 +1,793 @@
|
||||
# Production Deployment - Complete Setup Guide
|
||||
|
||||
**Status**: 🚧 In Progress
|
||||
**Last Updated**: 2025-10-30
|
||||
**Target Server**: 94.16.110.151 (Netcup)
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This guide walks through the complete setup of production deployment from scratch, covering:
|
||||
1. Gitea Runner (Development Machine)
|
||||
2. Ansible Vault Secrets
|
||||
3. Production Server Initial Setup
|
||||
4. CI/CD Pipeline Testing
|
||||
5. Monitoring & Health Checks
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
**Development Machine:**
|
||||
- ✅ Docker & Docker Compose installed
|
||||
- ✅ Ansible installed (`pip install ansible`)
|
||||
- ✅ SSH key for production server (`~/.ssh/production`)
|
||||
- ✅ Git SSH key configured (see Phase 0)
|
||||
- ✅ Access to Gitea admin panel
|
||||
|
||||
**Production Server (94.16.110.151):**
|
||||
- ✅ Docker & Docker Compose installed
|
||||
- ✅ User `deploy` created with Docker permissions
|
||||
- ✅ SSH access configured
|
||||
- ✅ Firewall configured (ports 80, 443, 2222)
|
||||
|
||||
---
|
||||
|
||||
## Phase 0: Git Repository SSH Access Setup (Development Machine)
|
||||
|
||||
### Step 0.1: Generate Git SSH Key
|
||||
|
||||
Create a separate SSH key specifically for Git operations (different from the production server SSH key):
|
||||
|
||||
```bash
|
||||
# Generate SSH key for Git
|
||||
ssh-keygen -t ed25519 -f ~/.ssh/git_michaelschiemer -C "git@michaelschiemer.de" -N ""
|
||||
|
||||
# Set correct permissions
|
||||
chmod 600 ~/.ssh/git_michaelschiemer
|
||||
chmod 644 ~/.ssh/git_michaelschiemer.pub
|
||||
```
|
||||
|
||||
### Step 0.2: Configure SSH Config
|
||||
|
||||
Add Git SSH configuration to `~/.ssh/config`:
|
||||
|
||||
```bash
|
||||
# Edit SSH config
|
||||
nano ~/.ssh/config
|
||||
```
|
||||
|
||||
Add the following configuration:
|
||||
|
||||
```
|
||||
Host git.michaelschiemer.de
|
||||
HostName git.michaelschiemer.de
|
||||
Port 2222
|
||||
User git
|
||||
IdentityFile ~/.ssh/git_michaelschiemer
|
||||
StrictHostKeyChecking no
|
||||
UserKnownHostsFile /dev/null
|
||||
```
|
||||
|
||||
### Step 0.3: Add Public Key to Gitea
|
||||
|
||||
1. Display your public key:
|
||||
```bash
|
||||
cat ~/.ssh/git_michaelschiemer.pub
|
||||
```
|
||||
|
||||
2. Copy the output (starts with `ssh-ed25519 ...`)
|
||||
|
||||
3. In Gitea:
|
||||
- Go to **Settings** → **SSH / GPG Keys**
|
||||
- Click **Add Key**
|
||||
- Paste the public key
|
||||
- Click **Add Key**
|
||||
|
||||
4. Verify the connection:
|
||||
```bash
|
||||
ssh -T git@git.michaelschiemer.de
|
||||
```
|
||||
|
||||
Expected output: `Hi there! You've successfully authenticated...`
|
||||
|
||||
### Step 0.4: Update Git Remote (if needed)
|
||||
|
||||
If your `origin` remote uses HTTPS, switch it to SSH:
|
||||
|
||||
```bash
|
||||
# Check current remote URL
|
||||
git remote -v
|
||||
|
||||
# Update to SSH
|
||||
git remote set-url origin git@git.michaelschiemer.de:michael/michaelschiemer.git
|
||||
|
||||
# Test push (should work without password prompt)
|
||||
git push origin main
|
||||
```
|
||||
|
||||
**Note**: This SSH key is separate from the production server SSH key (`~/.ssh/production`). The production key is used for Ansible/server access, while the Git key is only for repository operations.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Gitea Runner Setup (Development Machine)
|
||||
|
||||
### Step 1.1: Get Gitea Registration Token
|
||||
|
||||
1. Navigate to Gitea admin panel:
|
||||
```
|
||||
https://git.michaelschiemer.de/admin/actions/runners
|
||||
```
|
||||
|
||||
2. Click **"Create New Runner"**
|
||||
|
||||
3. Copy the registration token (format: `<long-random-string>`)
|
||||
|
||||
### Step 1.2: Configure Runner Environment
|
||||
|
||||
```bash
|
||||
cd deployment/gitea-runner
|
||||
|
||||
# Copy environment template
|
||||
cp .env.example .env
|
||||
|
||||
# Edit configuration
|
||||
nano .env
|
||||
```
|
||||
|
||||
**Required Configuration in `.env`:**
|
||||
```bash
|
||||
# Gitea Instance URL
|
||||
GITEA_INSTANCE_URL=https://git.michaelschiemer.de
|
||||
|
||||
# Registration Token (from Step 1.1)
|
||||
GITEA_RUNNER_REGISTRATION_TOKEN=<your-token-from-gitea>
|
||||
|
||||
# Runner Name (appears in Gitea UI)
|
||||
GITEA_RUNNER_NAME=dev-runner-01
|
||||
|
||||
# Runner Labels (environments this runner supports)
|
||||
GITEA_RUNNER_LABELS=ubuntu-latest:docker://node:20-bullseye,ubuntu-22.04:docker://catthehacker/ubuntu:act-22.04
|
||||
|
||||
# Runner Capacity (concurrent jobs)
|
||||
GITEA_RUNNER_CAPACITY=1
|
||||
|
||||
# Docker-in-Docker settings
|
||||
DOCKER_HOST=tcp://docker-dind:2376
|
||||
DOCKER_TLS_VERIFY=1
|
||||
```
|
||||
|
||||
### Step 1.3: Register and Start Runner
|
||||
|
||||
```bash
|
||||
# Register runner with Gitea
|
||||
./register.sh
|
||||
|
||||
# Expected output:
|
||||
# ✅ Starting Gitea Runner services...
|
||||
# ✅ Runner registered successfully
|
||||
# ✅ Runner is now active
|
||||
|
||||
# Verify runner is running
|
||||
docker compose ps
|
||||
|
||||
# Check logs
|
||||
docker compose logs -f gitea-runner
|
||||
```
|
||||
|
||||
### Step 1.4: Verify Runner in Gitea
|
||||
|
||||
1. Go to: https://git.michaelschiemer.de/admin/actions/runners
|
||||
2. You should see `dev-runner-01` listed as **"Idle"** or **"Active"**
|
||||
3. Status should be green/online
|
||||
|
||||
**✅ Checkpoint**: Runner visible in Gitea UI and showing as "Idle"
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Ansible Vault Secrets Setup
|
||||
|
||||
### Step 2.1: Create Vault Password
|
||||
|
||||
```bash
|
||||
cd deployment/ansible/secrets
|
||||
|
||||
# Create vault password file (gitignored)
|
||||
echo "your-secure-vault-password-here" > .vault_pass
|
||||
|
||||
# Secure the file
|
||||
chmod 600 .vault_pass
|
||||
```
|
||||
|
||||
**⚠️ IMPORTANT**: Store this vault password in your password manager! You'll need it for all Ansible operations.
|
||||
|
||||
### Step 2.2: Create Production Secrets File
|
||||
|
||||
```bash
|
||||
# Copy example template
|
||||
cp production.vault.yml.example production.vault.yml
|
||||
|
||||
# Edit with your actual secrets
|
||||
nano production.vault.yml
|
||||
```
|
||||
|
||||
**Required Secrets in `production.vault.yml`:**
|
||||
```yaml
|
||||
---
|
||||
# Docker Registry Credentials
|
||||
docker_registry_user: "admin"
|
||||
docker_registry_password: "your-registry-password"
|
||||
|
||||
# Application Environment Variables
|
||||
app_key: "base64:generated-32-character-key"
|
||||
app_env: "production"
|
||||
app_debug: "false"
|
||||
|
||||
# Database Credentials
|
||||
db_host: "postgres"
|
||||
db_port: "5432"
|
||||
db_name: "framework_production"
|
||||
db_user: "framework_user"
|
||||
db_password: "your-secure-db-password"
|
||||
|
||||
# Redis Configuration
|
||||
redis_host: "redis"
|
||||
redis_port: "6379"
|
||||
redis_password: "your-secure-redis-password"
|
||||
|
||||
# Cache Configuration
|
||||
cache_driver: "redis"
|
||||
cache_prefix: "framework"
|
||||
|
||||
# Queue Configuration
|
||||
queue_connection: "redis"
|
||||
queue_name: "default"
|
||||
|
||||
# Session Configuration
|
||||
session_driver: "redis"
|
||||
session_lifetime: "120"
|
||||
|
||||
# Encryption Keys
|
||||
encryption_key: "base64:your-32-byte-encryption-key"
|
||||
state_encryption_key: "base64:your-32-byte-state-encryption-key"
|
||||
|
||||
# SMTP Configuration (Optional)
|
||||
mail_mailer: "smtp"
|
||||
mail_host: "smtp.example.com"
|
||||
mail_port: "587"
|
||||
mail_username: "noreply@michaelschiemer.de"
|
||||
mail_password: "your-smtp-password"
|
||||
mail_encryption: "tls"
|
||||
mail_from_address: "noreply@michaelschiemer.de"
|
||||
mail_from_name: "Framework"
|
||||
|
||||
# Admin IPs (comma-separated)
|
||||
admin_allowed_ips: "127.0.0.1,::1"
|
||||
|
||||
# Rate Limiting
|
||||
rate_limit_enabled: "true"
|
||||
rate_limit_default: "60"
|
||||
rate_limit_window: "60"
|
||||
```
|
||||
|
||||
### Step 2.3: Generate Encryption Keys
|
||||
|
||||
```bash
|
||||
# Generate app_key (32 bytes base64)
|
||||
php -r "echo 'base64:' . base64_encode(random_bytes(32)) . PHP_EOL;"
|
||||
|
||||
# Generate encryption_key (32 bytes base64)
|
||||
php -r "echo 'base64:' . base64_encode(random_bytes(32)) . PHP_EOL;"
|
||||
|
||||
# Generate state_encryption_key (32 bytes base64)
|
||||
php -r "echo 'base64:' . base64_encode(random_bytes(32)) . PHP_EOL;"
|
||||
|
||||
# Copy these values into production.vault.yml
|
||||
```
|
||||
|
||||
### Step 2.4: Encrypt Secrets File
|
||||
|
||||
```bash
|
||||
# Encrypt the secrets file
|
||||
ansible-vault encrypt production.vault.yml \
|
||||
--vault-password-file .vault_pass
|
||||
|
||||
# Verify encryption worked
|
||||
file production.vault.yml
|
||||
# Should output: production.vault.yml: ASCII text
|
||||
|
||||
# View encrypted content (should show encrypted data)
|
||||
cat production.vault.yml
|
||||
|
||||
# Test decryption (view content)
|
||||
ansible-vault view production.vault.yml \
|
||||
--vault-password-file .vault_pass
|
||||
```
|
||||
|
||||
**✅ Checkpoint**: `production.vault.yml` is encrypted and can be decrypted with vault password
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Production Server Initial Setup
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Before running Phase 3, ensure:
|
||||
- ✅ SSH access to production server configured (`~/.ssh/production`)
|
||||
- ✅ Repository cloned on production server at `~/deployment/stacks` (or adjust `stacks_base_path` in playbook)
|
||||
- ✅ Ansible installed on your development machine: `pip install ansible`
|
||||
- ✅ Ansible collections installed: `ansible-galaxy collection install community.docker`
|
||||
|
||||
### Step 3.1: Clone Repository on Production Server (if not already done)
|
||||
|
||||
**On Production Server:**
|
||||
|
||||
```bash
|
||||
# SSH to production server
|
||||
ssh deploy@94.16.110.151
|
||||
|
||||
# Clone repository (if not already present)
|
||||
mkdir -p ~/deployment
|
||||
cd ~/deployment
|
||||
git clone git@git.michaelschiemer.de:michael/michaelschiemer.git . || git clone https://git.michaelschiemer.de/michael/michaelschiemer.git .
|
||||
```
|
||||
|
||||
### Step 3.2: Deploy Infrastructure Stacks with Ansible
|
||||
|
||||
**On Development Machine:**
|
||||
|
||||
```bash
|
||||
# Navigate to Ansible directory
|
||||
cd deployment/ansible
|
||||
|
||||
# Run infrastructure deployment playbook
|
||||
ansible-playbook playbooks/setup-infrastructure.yml \
|
||||
-i inventory/production.yml
|
||||
|
||||
# The playbook will:
|
||||
# 1. Create required Docker networks (traefik-public, app-internal)
|
||||
# 2. Deploy Traefik (Reverse Proxy & SSL)
|
||||
# 3. Deploy PostgreSQL (Database)
|
||||
# 4. Deploy Docker Registry (Private Registry)
|
||||
# 5. Deploy Gitea (Git Server + PostgreSQL)
|
||||
# 6. Deploy Monitoring (Portainer + Grafana + Prometheus)
|
||||
# 7. Wait for all services to be healthy
|
||||
# 8. Verify accessibility
|
||||
```
|
||||
|
||||
**Expected output:**
|
||||
- ✅ All stacks deployed successfully
|
||||
- ✅ All services healthy
|
||||
- ✅ Gitea accessible at https://git.michaelschiemer.de
|
||||
|
||||
**Note:** If monitoring passwords need to be stored in Vault (recommended for production), add them to `secrets/production.vault.yml`:
|
||||
- `vault_grafana_admin_password`
|
||||
- `vault_prometheus_password`
|
||||
|
||||
Then run the playbook with vault:
|
||||
```bash
|
||||
ansible-playbook playbooks/setup-infrastructure.yml \
|
||||
-i inventory/production.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
```
|
||||
|
||||
### Step 3.3: Configure Gitea (Manual Step)
|
||||
|
||||
1. Access Gitea: https://git.michaelschiemer.de
|
||||
2. Complete initial setup wizard (first-time only):
|
||||
- **Database Type**: PostgreSQL
|
||||
- **Database Host**: `postgres:5432`
|
||||
- **Database User**: `gitea`
|
||||
- **Database Password**: `gitea_password` (or check `deployment/stacks/gitea/docker-compose.yml`)
|
||||
- **Database Name**: `gitea`
|
||||
- **Admin Account**: Create your admin user
|
||||
- **Repository Root**: `/data/git/repositories` (default)
|
||||
3. **Enable Actions** (required for Phase 1):
|
||||
- Go to **Site Administration** → **Actions**
|
||||
- Enable **Enable Actions** checkbox
|
||||
- Save settings
|
||||
|
||||
### Step 3.4: Verify Docker Registry
|
||||
|
||||
The Ansible playbook automatically creates registry authentication. To retrieve credentials:
|
||||
|
||||
```bash
|
||||
# SSH to production server
|
||||
ssh deploy@94.16.110.151
|
||||
|
||||
# View registry htpasswd (contains username:password hash)
|
||||
cat ~/deployment/stacks/registry/auth/htpasswd
|
||||
|
||||
# The default username is 'admin'
|
||||
# Password hash can be used to login, or create new user:
|
||||
cd ~/deployment/stacks/registry
|
||||
docker compose exec registry htpasswd -Bbn <username> <password> >> auth/htpasswd
|
||||
docker compose restart registry
|
||||
|
||||
# Test login
|
||||
docker login registry.michaelschiemer.de
|
||||
# Or if using port:
|
||||
docker login registry.michaelschiemer.de
|
||||
```
|
||||
|
||||
**✅ Checkpoint**: All infrastructure stacks running, Gitea accessible, Actions enabled
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Deploy Application Secrets
|
||||
|
||||
### Step 4.1: Deploy Secrets to Production
|
||||
|
||||
**On Development Machine:**
|
||||
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
|
||||
# Test Ansible connectivity
|
||||
ansible production -m ping
|
||||
|
||||
# Deploy secrets to production server
|
||||
ansible-playbook playbooks/setup-production-secrets.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
|
||||
# Expected output:
|
||||
# PLAY [Deploy Production Secrets] ***
|
||||
# TASK [Ensure secrets directory exists] *** ok
|
||||
# TASK [Deploy environment file] *** changed
|
||||
# PLAY RECAP *** production: ok=2 changed=1
|
||||
```
|
||||
|
||||
### Step 4.2: Verify Secrets Deployed
|
||||
|
||||
```bash
|
||||
# SSH to production server
|
||||
ssh deploy@94.16.110.151
|
||||
|
||||
# Check secrets directory
|
||||
ls -la ~/secrets/
|
||||
|
||||
# Verify .env.production exists (do NOT cat - contains secrets!)
|
||||
file ~/secrets/.env.production
|
||||
# Should output: .env.production: ASCII text
|
||||
|
||||
# Check file permissions
|
||||
stat ~/secrets/.env.production
|
||||
# Should be 600 (readable only by deploy user)
|
||||
```
|
||||
|
||||
**✅ Checkpoint**: Secrets deployed to production server in ~/secrets/.env.production
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Setup Gitea Secrets for CI/CD
|
||||
|
||||
### Step 5.1: Configure Repository Secrets
|
||||
|
||||
1. Go to repository settings in Gitea:
|
||||
```
|
||||
https://git.michaelschiemer.de/<username>/michaelschiemer/settings/secrets
|
||||
```
|
||||
|
||||
2. Add the following secrets:
|
||||
|
||||
**REGISTRY_USER**
|
||||
```
|
||||
admin
|
||||
```
|
||||
|
||||
**REGISTRY_PASSWORD**
|
||||
```
|
||||
<your-registry-password>
|
||||
```
|
||||
|
||||
**SSH_PRIVATE_KEY**
|
||||
```
|
||||
<content-of-~/.ssh/production>
|
||||
```
|
||||
|
||||
**ANSIBLE_VAULT_PASSWORD**
|
||||
```
|
||||
<your-vault-password-from-step-2.1>
|
||||
```
|
||||
|
||||
### Step 5.2: Verify Secrets in Gitea
|
||||
|
||||
1. Check secrets are visible in repository settings
|
||||
2. Each secret should show "Hidden" value with green checkmark
|
||||
|
||||
**✅ Checkpoint**: All required secrets configured in Gitea repository
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: First Deployment Test
|
||||
|
||||
### Step 6.1: Manual Deployment Dry-Run
|
||||
|
||||
**On Development Machine:**
|
||||
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
|
||||
# Test deployment (check mode - no changes)
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/deploy-update.yml \
|
||||
-e "image_tag=test-$(date +%s)" \
|
||||
-e "git_commit_sha=test123" \
|
||||
-e "deployment_timestamp=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
|
||||
-e "docker_registry_username=admin" \
|
||||
-e "docker_registry_password=your-registry-password" \
|
||||
--check
|
||||
|
||||
# Expected: Should show what would be changed
|
||||
```
|
||||
|
||||
### Step 6.2: Trigger CI/CD Pipeline
|
||||
|
||||
**Option A: Push to main branch**
|
||||
```bash
|
||||
# Make a small change (add comment to file)
|
||||
echo "# Deployment test $(date)" >> deployment/DEPLOYMENT_TEST.txt
|
||||
|
||||
# Commit and push to main
|
||||
git add deployment/DEPLOYMENT_TEST.txt
|
||||
git commit -m "test(deployment): trigger CI/CD pipeline"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
**Option B: Manual trigger**
|
||||
1. Go to Gitea repository: Actions tab
|
||||
2. Select workflow: "Production Deployment Pipeline"
|
||||
3. Click "Run workflow"
|
||||
4. Select branch: main
|
||||
5. Click "Run"
|
||||
|
||||
### Step 6.3: Monitor Pipeline Execution
|
||||
|
||||
1. Go to: https://git.michaelschiemer.de/<username>/michaelschiemer/actions
|
||||
2. Find the running workflow
|
||||
3. Click to view details
|
||||
4. Monitor each job:
|
||||
- ✅ Test: Tests & quality checks pass
|
||||
- ✅ Build: Docker image built and pushed
|
||||
- ✅ Deploy: Application deployed to production
|
||||
|
||||
### Step 6.4: Verify Deployment
|
||||
|
||||
```bash
|
||||
# Test health endpoint
|
||||
curl -k https://michaelschiemer.de/health
|
||||
|
||||
# Expected response:
|
||||
# {"status":"healthy","timestamp":"2025-10-30T14:30:00Z"}
|
||||
|
||||
# Check application logs
|
||||
ssh deploy@94.16.110.151 "docker compose -f ~/application/docker-compose.yml logs -f app-php"
|
||||
```
|
||||
|
||||
**✅ Checkpoint**: CI/CD pipeline executed successfully, application running on production
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Monitoring & Health Checks
|
||||
|
||||
### Step 7.1: Access Monitoring Tools
|
||||
|
||||
**Portainer**
|
||||
```
|
||||
https://portainer.michaelschiemer.de
|
||||
```
|
||||
- View all running containers
|
||||
- Monitor resource usage
|
||||
- Check logs
|
||||
|
||||
**Grafana**
|
||||
```
|
||||
https://grafana.michaelschiemer.de
|
||||
```
|
||||
- Username: admin
|
||||
- Password: (set during setup)
|
||||
- View application metrics
|
||||
- Setup alerts
|
||||
|
||||
**Prometheus**
|
||||
```
|
||||
https://prometheus.michaelschiemer.de
|
||||
```
|
||||
- Query metrics
|
||||
- Check targets
|
||||
- Verify scraping
|
||||
|
||||
### Step 7.2: Configure Alerting
|
||||
|
||||
**In Grafana:**
|
||||
|
||||
1. Go to Alerting > Contact points
|
||||
2. Add email notification channel
|
||||
3. Create alert rules:
|
||||
- High CPU usage (>80% for 5 minutes)
|
||||
- High memory usage (>80%)
|
||||
- Application down (health check fails)
|
||||
- Database connection failures
|
||||
|
||||
### Step 7.3: Setup Health Check Monitoring
|
||||
|
||||
```bash
|
||||
# Create cron job on production server
|
||||
ssh deploy@94.16.110.151
|
||||
|
||||
# Add health check script
|
||||
crontab -e
|
||||
|
||||
# Add line:
|
||||
*/5 * * * * curl -f https://michaelschiemer.de/health || echo "Health check failed" | mail -s "Production Health Check Failed" admin@michaelschiemer.de
|
||||
```
|
||||
|
||||
**✅ Checkpoint**: Monitoring tools accessible, alerts configured
|
||||
|
||||
---
|
||||
|
||||
## Phase 8: Backup & Rollback Testing
|
||||
|
||||
### Step 8.1: Verify Backups
|
||||
|
||||
```bash
|
||||
# SSH to production server
|
||||
ssh deploy@94.16.110.151
|
||||
|
||||
# Check backup directory
|
||||
ls -lh ~/backups/
|
||||
|
||||
# Should see backup folders with timestamps
|
||||
# Example: 2025-10-30T14-30-00/
|
||||
```
|
||||
|
||||
### Step 8.2: Test Rollback
|
||||
|
||||
```bash
|
||||
# On development machine
|
||||
cd deployment/ansible
|
||||
|
||||
# Rollback to previous version
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/rollback.yml
|
||||
|
||||
# Verify rollback worked
|
||||
curl -k https://michaelschiemer.de/health
|
||||
```
|
||||
|
||||
**✅ Checkpoint**: Backups created, rollback mechanism tested
|
||||
|
||||
---
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
### Infrastructure
|
||||
- [ ] Traefik running and routing HTTPS
|
||||
- [ ] PostgreSQL accessible and accepting connections
|
||||
- [ ] Docker Registry accessible at registry.michaelschiemer.de
|
||||
- [ ] Gitea accessible at git.michaelschiemer.de
|
||||
- [ ] Monitoring stack (Portainer, Grafana, Prometheus) running
|
||||
|
||||
### Deployment
|
||||
- [ ] Gitea Runner registered and showing "Idle" in UI
|
||||
- [ ] Ansible Vault secrets encrypted and deployable
|
||||
- [ ] SSH access configured for Ansible
|
||||
- [ ] Repository secrets configured in Gitea
|
||||
- [ ] CI/CD pipeline runs successfully end-to-end
|
||||
|
||||
### Application
|
||||
- [ ] Application accessible at https://michaelschiemer.de
|
||||
- [ ] Health endpoint returns 200 OK
|
||||
- [ ] Database migrations ran successfully
|
||||
- [ ] Queue workers processing jobs
|
||||
- [ ] Logs showing no errors
|
||||
|
||||
### Monitoring
|
||||
- [ ] Portainer shows all containers running
|
||||
- [ ] Grafana dashboards displaying metrics
|
||||
- [ ] Prometheus scraping all targets
|
||||
- [ ] Alerts configured and sending notifications
|
||||
|
||||
### Security
|
||||
- [ ] All secrets encrypted with Ansible Vault
|
||||
- [ ] SSH keys secured (600 permissions)
|
||||
- [ ] Registry requires authentication
|
||||
- [ ] HTTPS enforced on all public endpoints
|
||||
- [ ] Firewall configured correctly
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Gitea Runner Not Registering
|
||||
|
||||
**Symptoms**: Runner not appearing in Gitea UI after running `./register.sh`
|
||||
|
||||
**Solutions**:
|
||||
```bash
|
||||
# Check runner logs
|
||||
docker compose logs gitea-runner
|
||||
|
||||
# Verify registration token is correct
|
||||
nano .env
|
||||
# Check GITEA_RUNNER_REGISTRATION_TOKEN
|
||||
|
||||
# Unregister and re-register
|
||||
./unregister.sh
|
||||
./register.sh
|
||||
```
|
||||
|
||||
### Ansible Connection Failed
|
||||
|
||||
**Symptoms**: `Failed to connect to the host via ssh`
|
||||
|
||||
**Solutions**:
|
||||
```bash
|
||||
# Test SSH manually
|
||||
ssh -i ~/.ssh/production deploy@94.16.110.151
|
||||
|
||||
# Check SSH key permissions
|
||||
chmod 600 ~/.ssh/production
|
||||
|
||||
# Verify SSH key is added to server
|
||||
ssh-copy-id -i ~/.ssh/production.pub deploy@94.16.110.151
|
||||
```
|
||||
|
||||
### Docker Registry Authentication Failed
|
||||
|
||||
**Symptoms**: `unauthorized: authentication required`
|
||||
|
||||
**Solutions**:
|
||||
```bash
|
||||
# Verify credentials
|
||||
docker login registry.michaelschiemer.de
|
||||
# Username: admin
|
||||
# Password: <your-registry-password>
|
||||
|
||||
# Check htpasswd file on server
|
||||
ssh deploy@94.16.110.151 "cat ~/deployment/stacks/registry/auth/htpasswd"
|
||||
```
|
||||
|
||||
### Deployment Health Check Failed
|
||||
|
||||
**Symptoms**: Health check returns 404 or times out
|
||||
|
||||
**Solutions**:
|
||||
```bash
|
||||
# Check application logs
|
||||
ssh deploy@94.16.110.151 "docker compose -f ~/application/docker-compose.yml logs app-php"
|
||||
|
||||
# Verify application stack is running
|
||||
ssh deploy@94.16.110.151 "docker ps"
|
||||
|
||||
# Check Traefik routing
|
||||
ssh deploy@94.16.110.151 "docker compose -f ~/deployment/stacks/traefik/docker-compose.yml logs"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
After successful deployment:
|
||||
|
||||
1. **Configure DNS**: Point michaelschiemer.de to 94.16.110.151
|
||||
2. **SSL Certificates**: Traefik will automatically request Let's Encrypt certificates
|
||||
3. **Monitoring**: Review Grafana dashboards and setup additional alerts
|
||||
4. **Backups**: Configure automated database backups
|
||||
5. **Performance**: Review application performance and optimize
|
||||
6. **Documentation**: Update team documentation with production procedures
|
||||
|
||||
---
|
||||
|
||||
## Support Contacts
|
||||
|
||||
- **Infrastructure Issues**: Check Portainer logs
|
||||
- **Deployment Issues**: Review Gitea Actions logs
|
||||
- **Application Issues**: Check application logs in Portainer
|
||||
- **Emergency Rollback**: Run `ansible-playbook playbooks/rollback.yml`
|
||||
|
||||
---
|
||||
|
||||
**Setup Status**: 🚧 In Progress
|
||||
**Next Action**: Start with Phase 1 - Gitea Runner Setup
|
||||
262
deployment/docs/guides/vault-password.md
Normal file
262
deployment/docs/guides/vault-password.md
Normal file
@@ -0,0 +1,262 @@
|
||||
# Ansible Vault Password Dokumentation
|
||||
|
||||
## ?bersicht
|
||||
|
||||
Das Ansible Vault-Passwort wird verwendet, um verschl?sselte Secrets-Dateien (`production.vault.yml`) zu sch?tzen. Diese Dokumentation beschreibt, wie das Vault-Passwort angelegt, gespeichert und verwendet wird.
|
||||
|
||||
## Historischer Kontext
|
||||
|
||||
### Erstellungsdatum
|
||||
- **Erstellt am:** 30. Oktober 2025, 21:42:27
|
||||
- **Datei:** `deployment/ansible/secrets/.vault_pass`
|
||||
- **Erstes Setup-Script:** 31. Oktober 2025 (Commit `e26eb2a`)
|
||||
- **Script-Datei:** `deployment/ansible/scripts/init-secrets.sh`
|
||||
|
||||
### Einf?hrung
|
||||
Das Vault-Passwort-System wurde im Rahmen des CI/CD-Pipeline-Setups eingef?hrt, um die sichere Verwaltung von Production-Secrets zu erm?glichen. Das automatische Setup-Script wurde am 31. Oktober 2025 hinzugef?gt, um die manuelle Erstellung zu vereinfachen.
|
||||
|
||||
## Speicherort und Sicherheit
|
||||
|
||||
### Dateispeicherort
|
||||
- **Pfad:** `deployment/ansible/secrets/.vault_pass`
|
||||
- **Berechtigungen:** `600` (nur Owner lesbar/schreibbar)
|
||||
- **Gitignored:** ? Ja (in `.gitignore` hinterlegt)
|
||||
- **Inhalt:** Eine Zeile mit dem Vault-Passwort (plaintext)
|
||||
|
||||
### Sicherheitshinweise
|
||||
?? **WICHTIG:**
|
||||
- Das Passwort ist in Klartext in der Datei gespeichert
|
||||
- Die Datei ist **gitignored** und wird **nie** ins Repository committet
|
||||
- Berechtigungen sind auf `600` gesetzt (nur Owner-Zugriff)
|
||||
- Das Passwort sollte zus?tzlich im **Passwort-Manager** gespeichert werden
|
||||
- F?r verschiedene Umgebungen (dev/staging/prod) sollten unterschiedliche Passw?rter verwendet werden
|
||||
|
||||
## Erstellung des Vault-Passworts
|
||||
|
||||
### Methode 1: Automatisiertes Script (Empfohlen)
|
||||
|
||||
Das Script `init-secrets.sh` f?hrt Sie interaktiv durch den Setup-Prozess:
|
||||
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
./scripts/init-secrets.sh
|
||||
```
|
||||
|
||||
**Was das Script macht:**
|
||||
1. Pr?ft, ob `.vault_pass` bereits existiert
|
||||
2. Falls nicht vorhanden: Fragt interaktiv nach dem Passwort (mit Best?tigung)
|
||||
3. Speichert das Passwort in `secrets/.vault_pass`
|
||||
4. Setzt Berechtigungen auf `600`
|
||||
5. Erstellt und verschl?sselt `production.vault.yml` (optional)
|
||||
|
||||
**Vorteile:**
|
||||
- Automatische Berechtigungen
|
||||
- Passwort-Best?tigung verhindert Tippfehler
|
||||
- Vollst?ndiger Setup-Workflow inkl. Vault-Datei-Erstellung
|
||||
|
||||
### Methode 2: Manuelle Erstellung
|
||||
|
||||
```bash
|
||||
cd deployment/ansible/secrets
|
||||
|
||||
# Passwort erstellen
|
||||
echo "your-secure-vault-password-here" > .vault_pass
|
||||
|
||||
# Sicherheit: Berechtigungen setzen
|
||||
chmod 600 .vault_pass
|
||||
```
|
||||
|
||||
**Wichtig:** Verwenden Sie ein sicheres, zuf?lliges Passwort!
|
||||
|
||||
## Verwendung des Vault-Passworts
|
||||
|
||||
### In Ansible Playbooks
|
||||
|
||||
Das Vault-Passwort wird bei der Ausf?hrung von Playbooks ?bergeben:
|
||||
|
||||
```bash
|
||||
# Beispiel: Production Secrets deployen
|
||||
ansible-playbook playbooks/setup-production-secrets.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
|
||||
# Beispiel: Infrastructure deployen
|
||||
ansible-playbook playbooks/setup-infrastructure.yml \
|
||||
-i inventory/production.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
|
||||
# Beispiel: Application Update deployen
|
||||
ansible-playbook playbooks/deploy-update.yml \
|
||||
-e "image_tag=sha-abc123" \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
```
|
||||
|
||||
### Vault-Dateien verwalten
|
||||
|
||||
```bash
|
||||
# Vault-Datei entschl?sseln und anzeigen
|
||||
ansible-vault view secrets/production.vault.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
|
||||
# Vault-Datei bearbeiten
|
||||
ansible-vault edit secrets/production.vault.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
|
||||
# Neue Vault-Datei erstellen und verschl?sseln
|
||||
ansible-vault encrypt secrets/production.vault.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
|
||||
# Vault-Datei entschl?sseln (dauerhaft)
|
||||
ansible-vault decrypt secrets/production.vault.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
```
|
||||
|
||||
## CI/CD Integration
|
||||
|
||||
### Gitea Actions
|
||||
|
||||
In Gitea Actions wird das Vault-Passwort als Secret gespeichert:
|
||||
|
||||
- **Secret-Name:** `ANSIBLE_VAULT_PASSWORD`
|
||||
- **Verwendung:** Wird automatisch in Workflows verwendet, die Ansible-Vault ben?tigen
|
||||
|
||||
**Hinzuf?gen des Secrets in Gitea:**
|
||||
1. Gehe zu: Repository Settings ? Secrets
|
||||
2. Erstelle neues Secret: `ANSIBLE_VAULT_PASSWORD`
|
||||
3. Wert: Das Vault-Passwort aus `.vault_pass`
|
||||
|
||||
**Workflow-Beispiel:**
|
||||
```yaml
|
||||
- name: Deploy with Ansible
|
||||
run: |
|
||||
ansible-playbook playbooks/deploy-update.yml \
|
||||
--vault-password-file <(echo "${{ secrets.ANSIBLE_VAULT_PASSWORD }}")
|
||||
```
|
||||
|
||||
## Passwort zur?cksetzen/?ndern
|
||||
|
||||
### Passwort ?ndern
|
||||
|
||||
Wenn das Vault-Passwort ge?ndert werden muss:
|
||||
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
|
||||
# 1. Alte Vault-Datei entschl?sseln (mit altem Passwort)
|
||||
ansible-vault decrypt secrets/production.vault.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
|
||||
# 2. Neues Passwort setzen
|
||||
echo "new-secure-vault-password" > secrets/.vault_pass
|
||||
chmod 600 secrets/.vault_pass
|
||||
|
||||
# 3. Vault-Datei mit neuem Passwort verschl?sseln
|
||||
ansible-vault encrypt secrets/production.vault.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
|
||||
# 4. Passwort im Passwort-Manager aktualisieren
|
||||
# 5. CI/CD Secret in Gitea aktualisieren (ANSIBLE_VAULT_PASSWORD)
|
||||
```
|
||||
|
||||
### Passwort vergessen
|
||||
|
||||
?? **Wenn das Vault-Passwort verloren geht:**
|
||||
- Die verschl?sselte `production.vault.yml` kann nicht mehr entschl?sselt werden
|
||||
- Eine neue Vault-Datei muss erstellt werden
|
||||
- Alle Secrets m?ssen neu konfiguriert werden
|
||||
- **L?sung:** Passwort im Passwort-Manager speichern!
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Problem: "Decryption failed"
|
||||
|
||||
**Fehler:**
|
||||
```
|
||||
ERROR! Decryption failed (no vault secrets were found)
|
||||
```
|
||||
|
||||
**L?sung:**
|
||||
1. Passwort-Datei pr?fen:
|
||||
```bash
|
||||
cat deployment/ansible/secrets/.vault_pass
|
||||
```
|
||||
2. Korrekten Pfad verwenden:
|
||||
```bash
|
||||
--vault-password-file secrets/.vault_pass
|
||||
```
|
||||
3. Berechtigungen pr?fen:
|
||||
```bash
|
||||
ls -la deployment/ansible/secrets/.vault_pass
|
||||
# Sollte: -rw------- (600)
|
||||
```
|
||||
|
||||
### Problem: "Vault password file not found"
|
||||
|
||||
**Fehler:**
|
||||
```
|
||||
ERROR! the vault password file secrets/.vault_pass was not found
|
||||
```
|
||||
|
||||
**L?sung:**
|
||||
```bash
|
||||
# Pr?fen ob Datei existiert
|
||||
ls -la deployment/ansible/secrets/.vault_pass
|
||||
|
||||
# Falls nicht vorhanden, neu erstellen (siehe "Erstellung des Vault-Passworts")
|
||||
```
|
||||
|
||||
### Problem: "Permission denied"
|
||||
|
||||
**Fehler:**
|
||||
```
|
||||
Permission denied: secrets/.vault_pass
|
||||
```
|
||||
|
||||
**L?sung:**
|
||||
```bash
|
||||
chmod 600 deployment/ansible/secrets/.vault_pass
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ? Empfohlene Vorgehensweise
|
||||
|
||||
1. **Passwort-Manager:** Vault-Passwort im Passwort-Manager speichern
|
||||
2. **Sichere Passw?rter:** Verwendung von zuf?lligen, starken Passw?rtern
|
||||
3. **Separate Passw?rter:** Verschiedene Passw?rter f?r dev/staging/prod
|
||||
4. **Regelm??ige Rotation:** Passwort regelm??ig ?ndern (z.B. viertelj?hrlich)
|
||||
5. **Backup:** Passwort an sicherem Ort (Passwort-Manager) sichern
|
||||
6. **Zugriffskontrolle:** Nur autorisierte Personen sollten Zugriff haben
|
||||
|
||||
### ? Zu vermeiden
|
||||
|
||||
- Passwort ins Repository committen (gitignored!)
|
||||
- Passwort in unverschl?sselten Dokumenten speichern
|
||||
- Passwort per Email oder Chat teilen
|
||||
- Einfache/erratbare Passw?rter verwenden
|
||||
- Passwort mehreren Umgebungen teilen
|
||||
|
||||
## Verwandte Dateien
|
||||
|
||||
- **Setup-Script:** [`deployment/ansible/scripts/init-secrets.sh`](../../ansible/scripts/init-secrets.sh)
|
||||
- **Vault-Datei:** `deployment/ansible/secrets/production.vault.yml`
|
||||
- **Vault-Template:** `deployment/ansible/secrets/production.vault.yml.example`
|
||||
- **Gitignore:** `deployment/ansible/secrets/.gitignore`
|
||||
- **Haupt-Dokumentation:** [`deployment/ansible/README.md`](../../ansible/README.md)
|
||||
- **Setup-Guide:** [`deployment/docs/guides/setup-guide.md`](setup-guide.md)
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [Ansible Vault Dokumentation](https://docs.ansible.com/ansible/latest/user_guide/vault.html)
|
||||
- [Ansible Vault Best Practices](https://docs.ansible.com/ansible/latest/user_guide/vault.html#best-practices)
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Aspekt | Details |
|
||||
|--------|---------|
|
||||
| **Erstellt am** | 30. Oktober 2025, 21:42:27 |
|
||||
| **Speicherort** | `deployment/ansible/secrets/.vault_pass` |
|
||||
| **Berechtigungen** | `600` (nur Owner) |
|
||||
| **Gitignored** | ? Ja |
|
||||
| **Setup-Script** | `scripts/init-secrets.sh` |
|
||||
| **CI/CD Secret** | `ANSIBLE_VAULT_PASSWORD` |
|
||||
| **Verwendung** | `--vault-password-file secrets/.vault_pass` |
|
||||
Reference in New Issue
Block a user