Projet Dockerisé

Déploiement automatisé d'un environnement Dockerisé à partir de GIT qui comprend :

• intégration avec systemd
• configuration .env spécifique à la production
• configuration .env spécifique au serveur de test (quand : l'hôte est égal à localhost)
• support de Makefile pour gérer le projet
• Optionnel : fichiers .env-prod chiffrés dans le dépôt du projet, déchiffrés pendant le déploiement

Préliminaires

1. Vous avez besoin d'un projet sur n'importe quel serveur git.
2. Le projet doit avoir un Makefile avec la tâche "deployment_pre".
3. Votre projet doit avoir un fichier .env, ou .env-template qui sera copié dans .env.

Environnement

# utilisateur qui déploie l'application
deploy_user: tech.admin
deploy_group: technical
compose_env_name: "nom-de-votre-environnement-docker-compose-ici"
systemd_service_sleep: 30

project_dir: /project

# changez-le en sg. "./make.sh" si vous avez un point d'entrée exécuté par root pour un groupe donné d'utilisateurs
# n'utilisez pas sudo ici (évitez l'inception sudo)
make_executable: "./make.sh"

# cette origine sera définie uniquement lors de la période de déploiement
git_deploy_url: https://user:password@somehost/someuser/somerepo

# sans utilisateur et mot de passe, cette forme restera sur le serveur
git_regular_deploy_url: https://somehost/someuser/somerepo

# empêche le redémarrage de tout l'environnement lors du déploiement du projet à plusieurs reprises
avoid_whole_environment_restart: yes

#
# Récupération depuis une sauvegarde, lors du premier déploiement vous souhaiterez peut-être restaurer tout l'environnement à partir de la sauvegarde
# ou en cas d'échec. En général, ce drapeau doit être défini manuellement par déploiement.
#
# Seulement si vous avez configuré une instance de Répétiteur de fichiers sur un serveur externe pour le stockage des sauvegardes.
#
restore_from_backup_with_recovery_plan: no

# préférez .env-prod (s'il est présent dans le dépôt git cloné) au lieu de .env-dist
prefer_env_prod_over_dist: yes

# support .env (fonctionne également avec .env-prod)
test_specific_env:
    - { line: "DOMAIN_SUFFIX=.localhost", regexp: '^DOMAIN_SUFFIX', title: 'env: Ajouter suffixe de domaine - .localhost' }

production_specific_env:
    - { line: "DOMAIN_SUFFIX=", regexp: '^DOMAIN_SUFFIX', title: 'env: Supprimer suffixe de domaine' }

Dépannage

1. Provisionnement par l'utilisateur X, mais exécution de Harbor de Riotkit par l'utilisateur Y

Cela peut être très déroutant pour le Makefile, qui devrait exactement exécuter des commandes non privilégiées. La solution consiste à ignorer la détection automatique de l’utilisateur, en codant en dur l'identifiant de l'utilisateur et du groupe dans le fichier .env

test_specific_env:
    - { line: "DOMAIN_SUFFIX=.localhost", regexp: '^DOMAIN_SUFFIX', title: 'env: Ajouter suffixe de domaine - .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: Supprimer suffixe de domaine' }
    - { 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' }