Dockerized Project

Overview

This guide details how to automatically deploy a Dockerized environment from a GIT repository. It covers:

• Integration with systemd
• Configuration files for production and test servers
• Using a Makefile to manage the project
• Optionally storing encrypted production configuration files in the repository, which will be decrypted during deployment

Requirements

1. You must have a project hosted on any Git server.
2. The project should include a Makefile with the task "deployment_pre".
3. Your project must have an .env file or an .env-template that can be copied to create an .env file.

Environment Settings

# User who will deploy the application
deploy_user: tech.admin
deploy_group: technical
compose_env_name: "your-docker-compose-environment-name-there"
systemd_service_sleep: 30

project_dir: /project

# Change to something like "./make.sh" if you have a custom entrypoint for your user group
# Avoid using sudo here
make_executable: "./make.sh"

# Temporary URL set only during deployment
git_deploy_url: https://user:password@somehost/someuser/somerepo

# Public URL for deployment without user/password (remains on server)
git_regular_deploy_url: https://somehost/someuser/somerepo

# Prevents complete environment restart during repeated deployments
avoid_whole_environment_restart: yes

# Option to restore the environment from a backup upon first deployment or failure
# This should only be set if you have an external repository for backups
restore_from_backup_with_recovery_plan: no

# Prefer using .env-prod if it exists in the repository
prefer_env_prod_over_dist: yes

# Environment variable settings for testing
test_specific_env:
    - { line: "DOMAIN_SUFFIX=.localhost", regexp: '^DOMAIN_SUFFIX', title: 'env: Add domain suffix - .localhost' }

# Environment variable settings for production
production_specific_env:
    - { line: "DOMAIN_SUFFIX=", regexp: '^DOMAIN_SUFFIX', title: 'env: Remove domain suffix' }

Troubleshooting

1. Problem: Using different users for provisioning and running services

This can cause confusion about which user should execute certain commands. To fix this, you can set the user and group ID directly in the .env file instead of automatically detecting it.

test_specific_env:
    - { line: "DOMAIN_SUFFIX=.localhost", regexp: '^DOMAIN_SUFFIX', title: 'env: Add domain suffix - .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: Remove domain suffix' }
    - { 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' }