Dockerisiertes Projekt

Automatisierte Bereitstellung einer Docker-Umgebung aus GIT, die Folgendes umfasst:

• systemd-Integration
• produktspezifische .env-Konfiguration
• testserverspezifische .env-Konfiguration (wenn: host gleich localhost)
• Makefile-Unterstützung zur Verwaltung des Projekts
• Optional: Verschlüsselte .env-prod-Dateien im Projekt-Repository, die während der Bereitstellung entschlüsselt werden

Vorbedingungen

1. Sie benötigen ein Projekt auf einem beliebigen Git-Server.
2. Das Projekt muss ein Makefile mit der Aufgabe "deployment_pre" haben.
3. Ihr Projekt muss eine .env-Datei oder eine .env-template haben, die in .env kopiert wird.

Umgebung

# Benutzer, der die Anwendung bereitstellt
deploy_user: tech.admin
deploy_group: technical
compose_env_name: "ihr-docker-compose-umgebungsname"
systemd_service_sleep: 30

project_dir: /project

# Ändern Sie es ggf. in "./make.sh", wenn Sie einen als root ausgeführten Einstiegspunkt für diese Benutzergruppe haben
# Verwenden Sie hier kein sudo (vermeiden Sie, sudo in einer sudo-Inception)
make_executable: "./make.sh"

# Diese Herkunft wird nur während der Bereitstellung eingestellt
git_deploy_url: https://user:password@somehost/someuser/somerepo

# Ohne Benutzer und Passwort bleibt diese Form auf dem Server
git_regular_deploy_url: https://somehost/someuser/somerepo

# Verhindert, dass die gesamte Umgebung beim wiederholten Bereitstellen des Projekts neu gestartet wird
avoid_whole_environment_restart: ja

#
# Wiederherstellung aus einem Backup, bei der ersten Bereitstellung möchten Sie möglicherweise die gesamte Umgebung aus einem Backup wiederherstellen
# oder im Falle eines Fehlers. Dieses Flag sollte in der Regel manuell pro Bereitstellung gesetzt werden.
#
# Nur wenn Sie eine File Repository-Instanz auf einem externen Server für Backup-Speicher eingerichtet haben.
#
restore_from_backup_with_recovery_plan: nein

# Bevorzugen Sie .env-prod (wenn vorhanden im geklonten Git-Repository) anstelle von .env-dist
prefer_env_prod_over_dist: ja

# Unterstützung für .env (funktioniert auch mit .env-prod)
test_specific_env:
    - { line: "DOMAIN_SUFFIX=.localhost", regexp: '^DOMAIN_SUFFIX', title: 'env: Domain-Suffix hinzufügen - .localhost' }

production_specific_env:
    - { line: "DOMAIN_SUFFIX=", regexp: '^DOMAIN_SUFFIX', title: 'env: Domain-Suffix entfernen' }

Fehlerbehebung

1. Bereitstellung als Benutzer X, aber Ausführung von Riotkit's Harbor als Benutzer Y

Das kann für das Makefile sehr verwirrend sein, wer genau nicht-privilegierte Befehle ausführen sollte. Die Lösung ist, die automatische Benutzererkennung zu überspringen, indem Benutzer- und Gruppen-ID in die .env-Datei hartkodiert werden.

test_specific_env:
    - { line: "DOMAIN_SUFFIX=.localhost", regexp: '^DOMAIN_SUFFIX', title: 'env: Domain-Suffix hinzufügen - .localhost' }
    - { line: "APP_USER=tech.admin", regexp: '^APP_USER', title: 'env: APP_USER' }
    - { line: "APP_GROUP_ID=1800", regexp: '^APP_GROUP_ID', title: 'env: APP_GROUP_ID' }

production_specific_env:
    - { line: "DOMAIN_SUFFIX=", regexp: '^DOMAIN_SUFFIX', title: 'env: Domain-Suffix entfernen' }
    - { line: "APP_USER=tech.admin", regexp: '^APP_USER', title: 'env: APP_USER' }
    - { line: "APP_GROUP_ID=1800", regexp: '^APP_GROUP_ID', title: 'env: APP_GROUP_ID' }