Résorption-bidonvilles
Agir pour résorber les bidonvilles

[Structure de déploiement]
Consulter le wiki »

Voir la plateforme · Déployer une instance sur sa machine · Déployer une instance sur un serveur

🤓 Préambule

Résorption-bidonvilles est une plateforme publiée sous la forme d'images Docker dans Docker Hub. Il existe une image pour l'api, et deux images pour le frontend (landing et plateforme).

Ce dépôt fournit une configuration Docker et Docker-compose permettant de monter une instance de dev, staging, ou production de Résorption-bidonvilles.

🛠 Pré-requis

• make
• docker
• docker-compose
• openssl
• envsubst
• curl
• unzip
• grep
• sed
• timeout

👩🏼‍💻 Instance de développement

1. Initialiser

Les étapes suivantes sont obligatoires :

• sur votre machine, cloner les projets suivants dans des dossiers au même niveau :
  • ce dépôt dans un dossier resorption-bidonvilles-deploy
  • les sources de la plateforme dans un dossier resorption-bidonvilles
• créer et remplir un fichier resorption-bidonvilles-deploy/config/.env en copiant le fichier .env.dev.sample (voir ici pour une explication complète sur son contenu)
• créer et remplir les fichiers resorption-bidonvilles/packages/api/.env, resorption-bidonvilles/packages/frontend/www/.env, resorption-bidonvilles/packages/frontend/webapp/.env en copiant les fichiers env.sample respectifs (voir ici pour une explication complète sur leur contenu)
• déclarer dans votre fichier /etc/hosts les trois domaines locaux suivants :

127.0.0.1   resorption-bidonvilles.localhost
127.0.0.1   app.resorption-bidonvilles.localhost
127.0.0.1   api.resorption-bidonvilles.localhost

• générer un certificat https auto-signé : make localcert (cette commande génère plusieurs certificats dans data/ssl qui seront utilisés par le proxy nginx)

Les étapes suivantes sont optionnelles et peuvent être faites plus tard :

• faire autoriser, au niveau de votre système, le certificat d'autorité data/ssl/RootCA.crt généré plus haut. Sur MacOS cela revient à rajouter ce certificat au trousseau d'accès système.

2. Démarrer l'instance

2.1 Services tiers

Les différents applicatifs de Résorption-bidonvilles dépendent de services tiers (bases de données, notamment). Ces services tiers sont mis à disposition via des containers Docker qui peuvent être démarrés et gérés grâce à docker-compose.

Pour démarrer les services tiers (voir ici la liste des services montés) :

docker-compose --env-file ./config/.env -f docker-compose.yml -f docker-compose.dev.yml up

Pour simplifier l'utilisation, un fichier Makefile met à disposition une target dev qui sert d'alias. La commande ci-dessus peut-être réécrite ainsi :

make dev up

Plus généralement, vous pouvez utiliser cette target pour manipuler les différents services :

• démarrer une session SHELL sur le service database_data : make dev exec rb_database_data bash
• forcer un build des images : `make dev build
• etc.

Note : pour passer des options à ces commandes, entourez les de guillemets : make dev "up --remove-orphans --build", autrement, Make retournera une erreur

2.2 Applicatifs

Résorption-bidonvilles fonctionne avec trois applicatifs distincts que vous devez démarrer chacun séparément sur votre machine :

• l'api : cd resorption-bidonvilles/packages/api && yarn dev
• la landing (www) : cd resorption-bidonvilles/packages/frontend/www && yarn dev
• la plateforme (webapp) : cd resorption-bidonvilles/packages/frontend/webapp && yarn dev

🚀 Instance de staging / production

1. Initialiser

• cloner ce dépôt à l'endroit souhaité (sur une machine Debian, la localisation attendue est le dossier /srv : /srv/resorption-bidonvilles par exemple)
• créer le fichier config/.env en copiant l'un des fichiers d'exemple config/.env.*.sample
• faire l'acquisition des certificats https : make remotecert
• monter l'instance : make prod "up -d"

2. Maintenir

• modifier la version attendue de la plateforme dans config/.env
• relancer un up : make prod "up -d"
• lancer les migrations via le service rb_api : make prod exec rb_api yarn sequelize db:migrate
• lancer des seeders via le service rb_api : make prod exec rb_api yarn sequelize db:seed --seed db/seeders/...
• accéder à la base de données : make prod exec rb_database_data bash

🧩 Liste des services montés

Quel que soit l'environnement choisi, les services suivants seront montés :

• rb_proxy : le serveur Nginx qui écoute l'intégralité des requêtes HTTP(S) et redirige vers le service approprié sur la base du nom de domaine
• rb_database_data : la base de données PostgreSQL utilisée par l'API
• rb_database_agenda : la base de données MongoDB qui sert à planifier des tâches futures via l'outil agenda

Sur les environnements de staging/production, les services suivants seront montés :

• rb_certbot : un outil permettant le renouvellement automatique des certificats HTTPS
• rb_www : le frontend de la landing-page
• rb_webapp : le frontend de la plateforme, une SPA développée avec VueJS
• rb_api : l'API REST qui alimente la plateforme et landing-page, développée avec NodeJS

📒 Configuration

Plusieurs remarques :

• tous les chemins indiqués comme "relatifs" dans cette section sont relatifs à la racine de ce dépôt.
• les variables indiquées prod-only ne sont nécessaires que pour la production (pas la dev, ni staging) et inversement pour dev-only

Commune

RB_DEPLOY_VERSION prod-only	Variable utilisée uniquement pour les versions prod/staging. Nom du tag de l'image docker à utiliser (voir les repositories sur Docker Hub). Par défaut, le même numéro de version est utilisé pour frontend et api, mais vous pouvez forcer des versions différentes en modifiant directement RB_DEPLOY_VERSION et RB_FRONTEND_VERSION (voir plus bas).
RB_DEPLOY_DATA_FOLDER	Chemin relatif ou absolu vers le dossier `data` qui doit être créé pour stocker par défaut les données locales (certificats https, base de données ,etc.)

Proxy

RB_PROXY_CONFIG_FOLDER	Chemin relatif ou absolu vers le dossier de configuration du proxy Nginx.
RB_PROXY_FRONTEND_HOST	Adresse de l'hôte pour le frontend (nom de domaine uniquement, pas d'IP). Exemple : `resorption-bidonvilles.localhost`
RB_PROXY_API_HOST	Adresse de l'hôte pour l'api (nom de domaine uniquement, pas d'IP). Obligatoirement un sous-domaine du frontend. Exemple : `api.resorption-bidonvilles.localhost`
RB_PROXY_CERTIFICATE_PATH	Chemin relatif ou absolu vers le certificat https, utilisé par Nginx pour le chiffrage.
RB_PROXY_CERTIFICATE_KEY_PATH	Chemin relatif ou absolu vers la clé du certificat https, utilisé par Nginx pour le chiffrage.
RB_PROXY_TRUSTED_CERTIFICATE_PATH	Chemin relatif ou absolu vers le certificat d'autorité https, utilisé par Nginx pour le chiffrage.
RB_PROXY_TEMPLATE	Soit `full`, soit `certonly`. Cette variable est configurée automatiquement via make. La version `certonly` met en place la configuration nginx minimale nécessaire à l'acquisition d'un premier certificat https. La version `full` met en place la configuration complète qui pré-suppose l'existence du certificat (et rendrait une erreur s'il n'existe pas).

Base de données (données)

RB_DATABASE_DATA_FOLDER	Chemin relatif ou absolu vers le dossier de l'hôte auquel doit être bindée cette base de données.
RB_DATABASE_EXTERNAL_PORT	Port de l'hôte qui doit être bindé à celui de la base de données.
RB_DATABASE_LOCALBACKUP_FOLDER	Chemin absolu du dossier du conteneur dans lequel seront générés les fichiers de backup
RB_DATABASE_REMOTEBACKUP_KEY_ID prod-only	Voir la page du wiki Mise en place de la backup cloud
RB_DATABASE_REMOTEBACKUP_KEY_SECRET prod-only
RB_DATABASE_REMOTEBACKUP_BUCKET_ENDPOINT prod-only
RB_DATABASE_REMOTEBACKUP_BUCKET_NAME prod-only
RB_DATABASE_REMOTEBACKUP_BUCKET_PASSWORD prod-only
POSTGRES_DB		Nom de la base de données
POSTGRES_USER	Nom de l'utilisateur PostgreSQL propriétaire de la base de données
POSTGRES_PASSWORD	Mot de passe de l'utilisateur PostgreSQL

Base de données (agenda)

RB_AGENDA_MONGO_VERSION	Tag d'image docker Mongo à utiliser (voir Docker Hub)
RB_AGENDA_DATA_FOLDER	Chemin relatif ou absolu vers le dossier de l'hôte auquel doit être bindée cette base de données.
MONGO_INITDB_ROOT_USERNAME	Nom de l'utilisateur MongoDB
MONGO_INITDB_ROOT_PASSWORD	Mot de passe de l'utilisateur MongoDB

Frontend

RB_FRONTEND_VERSION	Variable utilisée uniquement pour les versions prod/staging. Nom du tag de l'image docker à utiliser (voir Docker Hub)
VUE_APP_API_URL	URL vers l'API, ne finissant pas par un /. Exemple : https://api.resorption-bidonvilles.localhost
VUE_APP_MATOMO_ON	Soit `true`, soit `false. Est-ce que le tracking Matomo doit être activé ou non.
VUE_APP_SENTRY_ON	Soit `true`, soit `false. Est-ce que le tracking Sentry doit être activé ou non.
VUE_APP_SENTRY_SOURCEMAP_AUTHKEY prod-only	Authkey pour communication avec le projet Sentry
VUE_APP_SENTRY prod-only	DSN du projet Sentry frontend

API

RB_DEPLOY_VERSION	Variable utilisée uniquement pour les versions prod/staging. Nom du tag de l'image docker à utiliser (voir Docker Hub)
RB_API_BACK_URL	URL vers l'API, ne finissant pas par un /. Exemple : https://api.resorption-bidonvilles.localhost
RB_API_FRONT_URL	URL vers le frontend, sans `/` à la fin. Exemple : https://resorption-bidonvilles.localhost
RB_API_AUTH_SECRET	Chaîne secrète servant à chiffrer les tokens de l'API. Utiliser une chaîne d'au moins 40 caractères.
RB_API_AUTH_EXPIRES_IN	Nombre d'heures de validité d'un token d'authentification. Exemple : `24h`.
RB_API_ACTIVATION_TOKEN_EXPIRES_IN	Nombre d'heures de validité d'un token d'activation de compte. Exemple : `24h`
RB_API_PASSWORD_RESET_EXPIRES_IN	Nombre d'heures de validité d'un token de réinitialisation de mot de passe. Exemple : `24h`
RB_API_TEST_EMAIL	Adresse email qui est utilisée pour remplacer certains destinataires d'emails transactionnels. À utiliser en préproduction pour tester les notifications mails à l'ajout de commentaire par exemple.
RB_API_MAILJET_PUBLIC_KEY	Clé publique de l'API Mailjet
RB_API_MAILJET_PRIVATE_KEY	Clé privée de l'API Mailjet
RB_API_MONGO_USERNAME	Nom de l'utilisateur pour la connexion à la base de données Agenda
RB_API_MONGO_PASSWORD	Mot de passe de l'utilisateur Mongo pour la base de données Agenda
RB_API_MATTERMOST_WEBHOOK prod-only	URL du webhook Mattermost pour les notifications
RB_API_SENTRY_DSN prod-only	DSN du projet Sentry API
RB_API_SOLIGUIDE_KEY	Clé privé de communication avec l'API soliguide
RB_API_EMAIL_BLACKLIST	Une liste d'id utilisateurs, séparés par des virgules (sans espaces !), qui doivent être exclus des notifications mail d'ouverture et fermeture de site. Exemple : `1,2,3,4`
RB_API_SEND_ACTIVITY_SUMMARY	Un booléen (0 ou 1), qui indique à l'API si elle doit programmer l'envoi automatique de résumé d'activités par mail. Théoriquement à 1 uniquement en production

🙇🏼 Contributeur(ices)

Anis Safine Laget	Christophe Benard	⠀⠀Gaël Destrem

📝 Licence

Ce projet est distribué sous license AGPL-3.0.