Proyecto Dockerizado

Despliegue automatizado del entorno Dockerizado desde GIT que incluye:

• integración con systemd
• configuración específica de producción en .env
• configuración específica de servidor de prueba en .env (cuando: el host es localhost)
• soporte de Makefile para gestionar el proyecto
• Opcional: Archivos .env-prod cifrados en el repositorio del proyecto, descifrados durante el despliegue

Preliminares

1. Necesitas un proyecto en cualquier servidor git.
2. El proyecto debe tener un Makefile con la tarea "deployment_pre".
3. Tu proyecto debe tener un archivo .env, o un .env-template que se copiará en .env.

Entorno

# usuario que despliega la aplicación
deploy_user: tech.admin
deploy_group: technical
compose_env_name: "nombre-de-tu-entorno-docker-compose-aquí"
systemd_service_sleep: 30

project_dir: /project

# cámbialo a sg. "./make.sh" si tienes un entrypoint ejecutado por root para un grupo de usuarios dado
# no uses sudo aquí (evita hacer sudo en un inicio de sudo)
make_executable: "./make.sh"

# este origen se establecerá solo durante el tiempo de despliegue
git_deploy_url: https://user:password@somehost/someuser/somerepo

# sin usuario y contraseña, esta forma se quedará en el servidor
git_regular_deploy_url: https://somehost/someuser/somerepo

# evita reiniciar todo el entorno cuando se despliega el proyecto una y otra vez
avoid_whole_environment_restart: yes

#
# Recuperación de una copia de seguridad, en el primer despliegue puede que desees restaurar todo el entorno
# desde una copia de seguridad o en caso de un fallo. Generalmente, esta bandera debe ser configurada manualmente por despliegue.
#
# Solo si has configurado una instancia de Repositorio de Archivos en un servidor externo para el almacenamiento de copias de seguridad.
#
restore_from_backup_with_recovery_plan: no

# preferir .env-prod (si está presente en el repositorio git clonado) en lugar de .env-dist
prefer_env_prod_over_dist: yes

# soporte .env (también funciona con .env-prod)
test_specific_env:
    - { line: "DOMAIN_SUFFIX=.localhost", regexp: '^DOMAIN_SUFFIX', title: 'env: Agregar sufijo de dominio - .localhost' }

production_specific_env:
    - { line: "DOMAIN_SUFFIX=", regexp: '^DOMAIN_SUFFIX', title: 'env: Eliminar sufijo de dominio' }

Solución de Problemas

1. Provisión como usuario X, pero ejecutando el Harbor de Riotkit como usuario Y

Esto puede ser muy confuso para el Makefile, sobre quién exactamente debería ejecutar comandos no privilegiados. La solución es omitir la detección automática del usuario, codificando el id de usuario y grupo en el archivo .env.

test_specific_env:
    - { line: "DOMAIN_SUFFIX=.localhost", regexp: '^DOMAIN_SUFFIX', title: 'env: Agregar sufijo de dominio - .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: Eliminar sufijo de dominio' }
    - { 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' }