# Installation de l'environnement — enso (docv / enso) Ce document décrit l’installation de l’environnement du projet **sans Docker** : prérequis, clone, build, et déploiement sur les machines **test**, **pprod** et **prod**. La configuration du **proxy** et des **certificats** sur la machine proxy est prévue ultérieurement. **Références :** [README.md](README.md), [ARCHITECTURE_DOCV_ENSO.md](ARCHITECTURE_DOCV_ENSO.md), [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md). --- ## 1. Vue d’ensemble | Élément | Description | |--------|-------------| | **Pas de Docker** | Les applications sont installées et exécutées directement sur l’OS (binaires Rust, build Next.js, processus Node). | | **Machines cibles** | **test** (192.168.1.101), **pprod** (192.168.1.102), **prod** (192.168.1.103). Chaque environnement est déployé sur sa machine dédiée. | | **Domaines DNS** | **enso :** `test.enso.4nkweb.com`, `pprod.enso.4nkweb.com`, `prod.enso.4nkweb.com`. **docv :** `test.docv.4nkweb.com`, `pprod.docv.4nkweb.com`, `prod.docv.4nkweb.com` (configurés). | | **Proxy** | La machine **proxy** (192.168.1.100) assure le reverse proxy et les certificats SSL. La configuration détaillée pour **enso** et **docv** est **à faire plus tard** (voir `deploy/nginx/`). | | **Ports** | Mêmes ports en développement, test, pprod et prod ; aucun port déjà utilisé par d’autres services. Détail : [PORTS_ENSO.md](PORTS_ENSO.md). | | **Accès** | Accès SSH aux machines via le proxy (ProxyJump). Utilisateur : `ncantu`. | | **smart_ide** | Dépôt outillage ([smart_ide](https://git.4nkweb.com/4nk/smart_ide)) : socle dev orienté IA (Ollama, AnythingLLM, etc.). **Accès SSH sur le LAN : 192.168.1.164** (même mode d’accès que les autres hôtes internes : bastion / proxy selon votre `~/.ssh/config`). | --- ## 2. Prérequis À installer sur chaque machine cible (test, pprod, prod) et sur la machine de développement. | Logiciel | Version minimale | Usage | |----------|------------------|--------| | **Node.js** | 18+ | Build des fronts (Next.js), scripts npm. | | **npm** | 9+ | Workspaces, install, build. | | **Rust** (cargo, rustc) | **1.78+** (lock **Cargo.lock** version 4), toolchain **épinglée 1.88.0** (fichier `rust-toolchain.toml` à la racine du dépôt) | Compilation des backends **docv-back** et **enso-back** ; **rustup** obligatoire — éviter le seul paquet `cargo`/`rustc` du système si votre `PATH` pointe encore vers `/usr/bin/cargo` (souvent trop ancien). | | **PostgreSQL** | 14+ | BDD par environnement (une instance par machine ou une BDD par projet selon choix). | | **Git** | 2+ | Clone du dépôt et du sous-module `ai`. | Sous Debian/Ubuntu (à adapter selon l’OS) : ```bash # Node.js (via NodeSource ou nvm selon politique) sudo apt-get update sudo apt-get install -y build-essential pkg-config libssl-dev # Rust (rustup — après install, ~/.cargo/bin doit précéder /usr/bin dans PATH) curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain 1.88.0 source "$HOME/.cargo/env" # Depuis la racine du dépôt cloné : prise en compte de rust-toolchain.toml (ex. 1.88.0) # rustup show && cargo --version # PostgreSQL client et serveur sudo apt-get install -y postgresql postgresql-client # Git sudo apt-get install -y git ``` --- ## 3. Clone du dépôt et sous-modules ### 3.1 Dépôt canonique et fork (`4nk/enso` vs `nicolas.cantu/enso`) | Rôle | URL typique | |------|-------------| | **Canonique (organisation)** | `https://git.4nkweb.com/4nk/enso.git` — SSH : `git@git.4nkweb.com:4nk/enso.git` | | **Fork / miroir personnel** | `https://git.4nkweb.com/nicolas.cantu/enso.git` (exemple) | Les deux peuvent coexister : un poste de développement peut avoir **`origin`** sur le fork tandis que les **serveurs** (test, pprod, prod) clonent le dépôt que le compte de déploiement peut lire — en pratique souvent **`4nk/enso`** (variable **`ENSO_GIT_CLONE_URL`** dans **`.secrets//enso-deploy.env`**, voir **`deploy/enso-deploy.env.example`**). L’historique Git attendu reste aligné entre fork et canonique. ### 3.2 Clone Sur la machine de développement ou sur chaque machine cible (si build sur la cible) : ```bash git clone https://git.4nkweb.com/4nk/enso.git cd enso git submodule update --init --recursive ``` Le sous-module **ai** (API IA) est référencé dans `.gitmodules`. Si le dépôt `ai` est vide ou indisponible, le clone du sous-module peut échouer ; dans ce cas, poursuivre sans `ai` ou initialiser le sous-module lorsque le dépôt est prêt. ### 3.3 Branche `test` (et équivalent) sur le dépôt distant Le script **`deploy/scripts_v2/deploy.sh`** fait un **`git pull origin `** sur la cible (ex. **`test`**). Il faut que la branche distante existe (ex. **`git push origin master:test`** depuis la branche contenant le code à déployer) ou que la phase distante retombe sur **`master`** tant que **`origin/test`** n’existe pas (message d’avertissement dans les logs). Sur **Gitea**, si le message **« Push to create is not enabled for users »** apparaît, la création de branche à la volée est désactivée : un administrateur peut activer l’option correspondante ou créer la branche **`test`** sur le dépôt, puis vous pousser dessus avec les droits habituels. --- ## 4. Variables d’environnement Chaque environnement (test, pprod, prod) utilise ses propres variables. Aucun secret ne doit être commité : utiliser `.env` (ignoré par Git) ou un mécanisme de déploiement (fichiers dans `.secrets//` copiés à la main ou par script). ### 4.1 Backends **enso-back (Rust)** : binaire **`enso-back`**, variables **`HOST`**, **`PORT`** (**3040** derrière le proxy — voir [PORTS_ENSO.md](PORTS_ENSO.md)), `enso/enso-back/.env.example`. Build : `cargo build --release --manifest-path enso/enso-back/Cargo.toml` ; exécution : `enso/enso-back/target/release/enso-back`. Déploiement sur **192.168.1.164** : section **7.5** (adapter le chemin si besoin). **docv-back (Rust)** — variables attendues (documentées dans le code et dans [docs/docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) §5.4) : | Variable | Description | Exemple | |----------|-------------|---------| | `DATABASE_URL` | URL de connexion PostgreSQL | `postgres://user:password@localhost:5432/docv_test` | | `JWT_SECRET` | Secret pour la signature des JWT | Chaîne longue et aléatoire | | `OAUTH_CLIENT_ID` | Identifiant(s) client OAuth2 publics (virgule = plusieurs applis) | `enso-web` ou `enso-web,autre-id` | | `OAUTH_CLIENT_SECRET` | Secret confidentiel pour `/oauth/token` | Aligné avec le front / enso-back | | `OAUTH_REDIRECT_URIS` | URIs de callback autorisées (séparées par des virgules) | `https://test.enso.4nkweb.com/auth/docv-callback` | | `OAUTH_BROWSER_PATH_PREFIX` | Préfixe public devant `/oauth/…` (reverse proxy, ex. `/docv-api`) | `/docv-api` ; vide seulement si OAuth est à la racine du site | | `DOCV_USERS_PK_COLUMN` | Colonne PK sur `users` pour le login OAuth : `id` (défaut) ou `uid` (schéma existant type IMPL) | `uid` si la table utilise `uid` au lieu de `id` | | `DOCV_OAUTH_ACCESS_TOKEN_TTL_SEC` | Durée **unique** (secondes) pour : jeton **Bearer** (`JWT` `exp`, `expires_in`), JWT dans le cookie **`docv_oauth_session`** et **`Max-Age`** du cookie après **`POST /oauth/sign-in`**. | Défaut **900** (15 min) ; plage **60**–**86400**. Détail : [docv/AUTH_SESSION.md](docv/AUTH_SESSION.md). | | `DOCV_DEMO_MEMBER_EMAILS` | (optionnel) **Contournement test / BDD incomplete** : emails séparés par des **virgules** ; au **démarrage** de docv-back, chaque utilisateur listé **sans** ligne `office_members` reçoit un lien sur le **plus ancien** office en rôle **`client`** (champ technique). Ne remplace pas le rattachement métier cabinet / client ni le choix d’espace au login (docv). | Ex. `client@example.com` | | `DOCV_LINK_ORPHAN_USERS_TO_FIRST_OFFICE` | (optionnel) **`1`** / **`true`** / **`yes`** / **`on`** : au **démarrage**, **tout** utilisateur **sans** `office_members` est lié au **plus ancien** office uniquement. **Test** : avec plusieurs offices démo, un compte « orphelin » ne verra qu’**une** société ; memberships explicites requis pour le périmètre réel. **Déconseillé en prod**. Voir [AUTH_SESSION.md](docv/AUTH_SESSION.md) § modèle produit. | `1` sur **test** par défaut via deploy (surcharge possible) | | `OAUTH_TENANTS_JSON` | (optionnel) JSON de branding par `client_id` | Voir `docv/docv-back/tenants.default.json` | | `OAUTH_TENANTS_PATH` | (optionnel) chemin fichier JSON de branding | `/chemin/vers/tenants.json` | | `HOST` | Adresse d’écoute du serveur HTTP | `0.0.0.0` | | `PORT` | Port d’écoute | `3038` (docv-back), **3040** (enso-back). Fronts : `3032` (enso-front), **3005** (docv-front prévu). Voir [PORTS_ENSO.md](PORTS_ENSO.md). | | `ANCHORING_URL` | URL de l’API d’ancrage (serveur services) | À définir selon l’infra | | `IA_API_URL` | URL de l’API IA (sous-module ai) | **Nominal :** `http://192.168.1.164:3022` (API IA sur le serveur smart_ide / LAN). **Poste client** : utiliser cette URL si l’API ne tourne pas localement ; sinon `http://localhost:3022`. **test, pprod, prod** : `http://192.168.1.164:3022`. Voir [PORTS_ENSO.md](PORTS_ENSO.md). | | `DOCV_FILE_STORAGE_DIR` | (optionnel) Répertoire des octets pour `POST .../documents/binary` | Ex. `/var/lib/docv/uploads` ; sans cette variable, pas de téléchargement binaire (`503`). | | `DOCV_UPLOAD_MAX_BYTES` | (optionnel) Taille max du corps d’upload binaire | Défaut `10485760`. | | `DOCV_DP_GIT_SYNC` | (optionnel) `1` / `true` : après miroir sous `data/dossiers-permanents/`, enchaîne `git add` / `commit` / `push` | Nécessite un clone « writable » avec remote configuré ; voir [features/DOSSIERS_PERMANENTS_DATA_GIT.md](features/DOSSIERS_PERMANENTS_DATA_GIT.md). | | `DOCV_DP_GIT_REPO_ROOT` | Racine du dépôt Git (monorepo enso ou copie miroir) | Ex. `/srv/4NK/enso-test/repo` | | `DOCV_DP_GIT_DATA_SUBPATH` | Sous-chemin des DP versionnés depuis la racine | Défaut `data/dossiers-permanents` | | `DOCV_DP_GIT_REMOTE` | Nom du remote pour `git push` | Défaut `origin` | | `DOCV_DP_GIT_BRANCH` | Branche distante ciblée (`git push HEAD:refs/heads/…`) | Ex. `test` ; si vide, `git push` sans refspec explicite | **Note `JWT_SECRET` :** le changer sur docv-back **invalide** les access tokens déjà émis. Les utilisateurs connectés doivent se **reconnecter**. Côté **enso-front**, une réponse **401** sur les appels **docv** (`docvFetch`, upload binaire, etc.) déclenche la même séquence que la **déconnexion menu** : effacement jeton / état OAuth dans le **sessionStorage**, puis **`GET /oauth/sign-out`** docv avec **`return_url`** = **`/?signed_out=1`** (accueil ; enchaînement vers **`/login?signed_out=1`** — voir `invalidateLocalSessionAndGoHome`, `ensoSignedOutHomeReturnUrl`). Fichier d’exemple (à copier et renseigner, ne pas commiter les valeurs réelles) : ```bash # .env.example (à copier en .env) DATABASE_URL=postgres://user:password@localhost:5432/docv_test JWT_SECRET=your-jwt-secret HOST=0.0.0.0 PORT=3038 ANCHORING_URL= IA_API_URL= ``` ### 4.2 Fronts (enso-front) **enso-front (Next.js)** : copier `enso/enso-front/.env.example` vers `.env.local` (dev) ou `.env.production.local` (serveur, non versionné). Le script **`deploy/scripts_v2/remote/bootstrap-enso-remote.sh`** écrit un fichier **`enso/enso-front/.env.production.local`** aligné sur **`ENSO_PUBLIC_ORIGIN`** (mêmes clés que l’exemple, secret OAuth docv partagé avec la valeur générée pour `docv-back`). | Variable | Portée | Description | |----------|--------|-------------| | `NEXT_PUBLIC_ENSO_PUBLIC_ORIGIN` | client | Origine publique du site enso (ex. `https://test.enso.4nkweb.com`). | | `NEXT_PUBLIC_DOCV_OAUTH_CLIENT_ID` | client | Identifiant client OAuth (ex. `enso-web`, aligné sur docv-back). | | `NEXT_PUBLIC_DOCV_OAUTH_AUTHORIZE_BASE` | client | URL de base du endpoint authorize docv (ex. `…/docv-api/oauth/authorize`). | | `NEXT_PUBLIC_DOCV_API_BASE` | client | Optionnel : base URL des appels API métier avec Bearer (`/api/v1/…`). Défaut navigateur : origine du site + `/docv-api`. Écrit par **`deploy/scripts_v2/remote/bootstrap-enso-remote.sh`** sur les déploiements bootstrap. | | `DOCV_OAUTH_TOKEN_URL` | serveur Next | URL du endpoint token docv (sur la machine : en général `http://127.0.0.1:3038/oauth/token`). | | `DOCV_OAUTH_CLIENT_ID` | serveur Next | Même id que côté public. | | `DOCV_OAUTH_CLIENT_SECRET` | serveur Next | Secret partagé avec **docv-back** (`OAUTH_CLIENT_SECRET`). | Si la route **`/api/auth/docv-token`** renvoie *Configuration serveur incomplète (secret OAuth)*, **`DOCV_OAUTH_CLIENT_SECRET`** est absent ou vide dans **`.env.production.local`** côté Next : il doit être **identique** à **`OAUTH_CLIENT_SECRET`** dans **`docv/docv-back/.env`**. Le script **`bootstrap-enso-remote.sh`** synchronise ce secret vers **`enso-front`** et **`enso-back`** même lorsqu’il ne réécrit pas **`docv-back/.env`** (fichier déjà présent). L’unité **`deploy/systemd/enso-enso-front.service`** charge ce fichier via **`EnvironmentFile`** (comme **`enso-back`** avec **`.env`**) : après modification des secrets, **`systemctl --user daemon-reload`** puis **`systemctl --user restart enso-enso-front`**, ou relancer **`deploy/systemd/install-user-units.sh`** si le modèle d’unité a changé. Chaque déploiement distant (**`deploy/scripts_v2/remote/enso-remote-phase.sh`**) exécute **`sync-docv-oauth-secret-to-enso.sh`** : copie **`OAUTH_CLIENT_SECRET`** depuis **`docv/docv-back/.env`** vers **`DOCV_OAUTH_CLIENT_SECRET`** dans **`enso-front/.env.production.local`** et **`enso/enso-back/.env`**, afin d’éviter un front déployé sans secret alors que docv en dispose déjà. **HTTP 500** sur cette route avec un corps JSON : en pratique, le cas le plus fréquent est le secret manquant ci‑dessus (**Next** ne voit pas **`DOCV_OAUTH_CLIENT_SECRET`**). Après correction des fichiers, **`systemctl --user restart enso-enso-front`** (ou un nouveau déploiement) recharge l’**`EnvironmentFile`**. Sinon, lire le corps de la réponse dans les outils réseau du navigateur : une clé **`detail`** (renvoyée par docv) indique le rejet côté **`/oauth/token`** (code invalide, redirect_uri, etc.). Vérifier aussi que nginx envoie **`location /api/`** vers **enso-front (3032)** et non vers **enso-back (3040)** (voir **`docs/operations/NGINX_ENSO_API_ROUTING.md`**). En développement : `npm run dev` (port **3032**). Sur les machines test/pprod/prod : **`npm run start`** après `next build` (unit **systemd** : `deploy/systemd/enso-enso-front.service`). Les anciennes variables **Vite** `VITE_DOCV_*` ne sont plus utilisées ; tout l’OAuth / callback passe par les clés ci-dessus et la route handler **`/api/auth/docv-token`**. Le tableau de bord et la barre latérale appellent **docv-back** en HTTPS sur **`{origine publique}/docv-api/api/v1/…`** avec l’en-tête **`Authorization: Bearer`** (token d’accès OAuth). Nginx route le préfixe **`/docv-api/`** vers docv-back (port **3038** sur l’infra de référence). Liste des routes HTTP et câblage front : [features/DOCV_API_ENSO_FRONT_MAP.md](features/DOCV_API_ENSO_FRONT_MAP.md) §1 ; socle, migrations et narrative : [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) §3.1. Le front agrège les requêtes stubs (notifications, pending-documents, conversations) dans **`DocvStubListsProvider`** via **`Promise.all`**. ### 4.3 Par environnement - **test** : BDD dédiée (ex. `docv_test`, `enso_test`), secrets de test, URLs pointant vers les domaines de test. - **pprod** : BDD et secrets de préproduction ; URLs de préproduction. - **prod** : BDD et secrets de production ; URLs de production. Les fichiers `.secrets//` (ex. `.secrets/test/`, `.secrets/pprod/`, `.secrets/prod/`) peuvent contenir les `.env` ou fichiers équivalents par projet ; à déployer manuellement ou via script (hors dépôt). --- ## 5. Build ### 5.1 Fronts Depuis la racine du monorepo : ```bash npm install npm run build ``` Cela build les workspaces configurés (`enso/enso-front`). **enso-front** produit le build Next.js (`.next/`, `next start`) sur le port **3032** ; le reverse proxy doit router **`/api/`** vers **enso-front (3032)** pour les Route Handlers Next (ex. **`/api/auth/docv-token`**), pas vers **enso-back (3040)**. Pour un seul front enso : ```bash cd enso/enso-front npm install npm run build ``` ### 5.2 Backends (Rust) Depuis la racine : ```bash # docv (workspace : docv-shared + docv-back) cargo build --release --manifest-path docv/Cargo.toml --workspace # enso-back cargo build --release --manifest-path enso/enso-back/Cargo.toml ``` Binaires produits (à déployer sur la machine cible) : - `docv/target/release/docv-back` - `enso/enso-back/target/release/enso-back` **enso-back** : `enso/enso-back/target/release/enso-back` après `cargo build --release --manifest-path enso/enso-back/Cargo.toml`, avec `.env` (**PORT=3040** typiquement). --- ## 6. Base de données PostgreSQL Sur chaque machine (test, pprod, prod), créer les bases et utilisateurs nécessaires. Exemple pour l’environnement **test** : ```bash sudo -u postgres psql -c "CREATE USER enso_test WITH PASSWORD '...';" sudo -u postgres psql -c "CREATE DATABASE docv_test OWNER enso_test;" sudo -u postgres psql -c "CREATE DATABASE enso_test OWNER enso_test;" ``` Exécuter les **migrations** (SQL ou outil utilisé par le projet — SQLx migrate, Diesel, etc.) avant le premier démarrage des backends. Les migrations sont dans le dépôt (ex. `docv/docv-back/migrations/` ou équivalent) et doivent être appliquées avec les bons droits. --- ## 7. Déploiement sur chaque machine ### 7.1 Répertoire cible Convention courante sur l’infra 4NK : `/srv/4NK//`. Pour enso, exemples possibles : - **test** : `/srv/4NK/enso-test/` (ou un répertoire par produit : `docv-test`, `enso-test`). - **pprod** : `/srv/4NK/enso-pprod/` - **prod** : `/srv/4NK/enso-prod/` À aligner avec la convention réelle des autres projets sur les machines. ### 7.15 Chaîne `deploy/scripts_v2` et outillage partagé (`dev_ai` / `ai_dev`) Le dépôt inclut **`deploy/scripts_v2/deploy.sh`** : synchronisation Git optionnelle en local, puis **SSH** vers la cible (**ProxyJump** via **`deploy/lib/ssh.sh`** dans l'outillage partagé, résolu par **`AI_DEV_ROOT`**, **`DEV_AI_ROOT`**, **`IA_DEV_ROOT`**, ou chemins **`~/code/dev_ai`**, **`~/code/ai_dev`**, repli **`~/code/ia_dev`**) pour `git pull`, builds Rust/npm et **restart** des unités **systemd --user** `enso-*` si installées. - Documentation opérationnelle : **[deploy/README.md](../deploy/README.md)** ; intégration détaillée : **[AI_DEV_INTEGRATION.md](AI_DEV_INTEGRATION.md)**. - Fichier **`enso-deploy.env`** : de préférence **`/.secrets/enso//enso-deploy.env`** ; repli **`.secrets//enso-deploy.env`** dans le monorepo (voir **`deploy/enso-deploy.env.example`**). Synchronisation : **`deploy/scripts_v2/sync-secrets-to-ai_dev.sh`**. - Depuis le monorepo : **`./deploy/deploy.sh [options]`** (wrapper vers **`deploy/deploy.sh enso`** de l'outil) ou **`~/code/dev_ai/deploy/deploy.sh enso [options]`** selon l'emplacement du clone (voir configuration projet côté tooling, ex. **`deploy.repository_root`** vers le clone **enso**). ### 7.2 Contenu à déployer Pour chaque machine et chaque environnement : 1. **Backends** : copier les binaires release **docv-back** et **`enso/enso-back/target/release/enso-back`** (avec `.env`, **PORT=3040** selon [PORTS_ENSO.md](PORTS_ENSO.md)). 2. **Fronts** : pour **enso-front**, déployer le build (`.next/` ou `dist/` selon la stack) et exécuter le serveur de prod sur **3032** ; proxy `/api` vers enso-back côté nginx si nécessaire. 3. **Config** : copier le fichier `.env` (ou équivalent) pour chaque processus, avec les variables correspondant à l’environnement (test, pprod, prod). 4. **Migrations** : déjà appliquées (voir section 6). ### 7.3 Démarrage des services Sans Docker, les processus peuvent être gérés par **systemd** (recommandé) ou par un gestionnaire de processus (supervisor, etc.). Exemple de unit systemd pour un backend : ```ini [Unit] Description=docv-back (enso test) After=network.target postgresql.service [Service] Type=simple User=ncantu WorkingDirectory=/srv/4NK/enso-test EnvironmentFile=/srv/4NK/enso-test/docv-back.env ExecStart=/srv/4NK/enso-test/bin/docv-back Restart=on-failure [Install] WantedBy=multi-user.target ``` Adapter pour enso-back (**3040**) et **enso-front** sur **3032**. Les ports sont fixés dans [PORTS_ENSO.md](PORTS_ENSO.md) et doivent correspondre à la configuration du proxy (voir section 8). ### 7.4 Résumé par machine | Machine | Rôle | Déploiement | |---------|------|-------------| | **test** (192.168.1.101) | Environnement de test | docv-back, enso-back, enso-front ; BDD test ; config test. | | **pprod** (192.168.1.102) | Préproduction | Idem avec BDD et config pprod. | | **prod** (192.168.1.103) | Production | Idem avec BDD et config prod. | ### 7.5 Machine LAN **192.168.1.164** (smart_ide) — **enso-back** dans `~/code/enso` Pour déployer uniquement **enso-back** (Node) sur l’hôte **192.168.1.164**, avec le code sous **`~/code/enso/enso-back`** (créé si absent) : 1. Cloner ou disposer du dépôt **enso** sur la machine **d’où vous lancez le script** (poste de dev ou autre). 2. Depuis la racine du clone (répertoire qui contient **`enso/`**), exécuter : ```bash bash enso/scripts/deploy-enso-back-remote.sh ``` Variables optionnelles : **`TARGET_HOST`** (défaut `192.168.1.164`), **`DEPLOY_USER`** (défaut `ncantu`), **`REMOTE_PROJECT`** (défaut `enso` → chemin `~/code/enso/enso-back`), **`SSH_OPTS`** (ex. `'-J ncantu@4nk.myftp.biz'` si accès via bastion), **`SKIP_INSTALL=1`** pour ne pas lancer `npm install` sur la cible. Le script : **SSH** + **rsync** (`--delete`, exclusion de **`node_modules/`** et **`data/`** pour ne pas effacer la persistance distante), **`mkdir -p …/data/uploads`**, **`chmod 750`** sur **`data/`** et **`data/uploads/`**, puis **`npm install --omit=dev`** dans **`enso-back`**. Démarrage sur la cible (exemple) : `cd ~/code/enso/enso-back && HOST=0.0.0.0 PORT=3040 ./target/release/enso-back` (ou `cargo run --manifest-path enso/enso-back/Cargo.toml`). Chiffrement au repos, sauvegardes dédiées, antivirus sur **`uploads/`**, quotas et réplication ne sont pas couverts par ce script. --- ## 8. Proxy et certificats La machine **proxy** (192.168.1.100) assure : - Le reverse proxy HTTP/HTTPS (Nginx ou équivalent) vers les backends et fronts déployés sur test, pprod, prod. - La terminaison SSL (certificats Let’s Encrypt ou existants). - **enso :** `test.enso.4nkweb.com` → **192.168.1.101** ; `pprod.enso.4nkweb.com` → **192.168.1.102** ; `prod.enso.4nkweb.com` → **192.168.1.103** (nginx : `/` → **3032**, `/api/` → **3040**, `/docv-api/` → **3038**). - **docv :** `test.docv.4nkweb.com` → **101** ; `pprod.docv.4nkweb.com` → **102** ; `prod.docv.4nkweb.com` → **103** — API **docv-back** **3038** (**3038** / **3040** enso sont réservés au produit enso) ; **docv-front** prévu sur **3005** (voir [PORTS_ENSO.md](PORTS_ENSO.md)). - Snippets nginx de référence : `deploy/nginx/*.locations.snippet` (`*.enso.*` et `*.docv.*`). Chaque snippet **docv** rappelle l’inclusion dans un bloc `server { listen 443 ssl; server_name … }` avec chemins `ssl_certificate` / `ssl_certificate_key` (ou équivalent). ### 8.1 Certificats TLS des vhosts **docv** Exigences : - **SNI / SAN** : le certificat présenté sur le **443** du proxy pour chaque FQDN doit inclure ce nom en **Subject Alternative Name** (un certificat par vhost ou SAN multi-noms selon politique infra). - **Chaîne** : confiance publique (ex. **Let’s Encrypt**) ou certificat d’entreprise explicitement approuvé ; **pas** de certificat auto-signé en production (règles projet). Contrôle depuis un poste ayant accès au **443** public des FQDN (remplacer le nom de domaine) : ```bash openssl s_client -connect test.docv.4nkweb.com:443 -servername test.docv.4nkweb.com &1 \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName ``` Répéter pour `pprod.docv.4nkweb.com` et `prod.docv.4nkweb.com`. Points à valider sur la sortie : **`subject` / SAN** = FQDN attendu, **`issuer`** cohérent (ex. Let’s Encrypt), **`notAfter`** dans le futur. La configuration détaillée du proxy (fichiers nginx complets, renouvellement **certbot**, alignement avec l’infra 4NK) reste à consolider côté exploitation. Référence : documentation infrastructure Cloud 4NK (règles utilisateur). --- ### 8.2 Front **enso** : message Vite « This host is not allowed » derrière le proxy Symptôme (navigateur) : *Blocked request. This host ("…") is not allowed. To allow this host, add "…" to `preview.allowedHosts` in vite.config.* **Cause :** l'instance sert le build avec **`vite preview`** (recommandation actuelle du dépôt : **`next build`** puis **`npm run start`** sans Vite). À partir de Vite 5, le serveur de **preview** restreint l'en-tête **`Host`** sauf configuration explicite. **Correctif si l'hôte utilise encore Vite :** dans `enso/enso-front/vite.config.ts` (ou `.js`), ajouter les FQDN attendus derrière le proxy. Section **`preview`** (mode `vite preview`) **et**, en développement (`vite`), section **`server`**, même tableau **`allowedHosts`** : ```ts const allowedHosts = [ "test.enso.4nkweb.com", "pprod.enso.4nkweb.com", "prod.enso.4nkweb.com", "test.docv.4nkweb.com", "pprod.docv.4nkweb.com", "prod.docv.4nkweb.com", ] as const; // server: { … allowedHosts, … } // preview: { … allowedHosts, … } ``` Si un **docv-front** distinct (ex. port **3005**) utilise Vite, lister les mêmes noms (ou équivalent) dans **son** `vite.config`. Puis redémarrer le service (ex. `systemctl --user restart enso-enso-front`). **Pérenne :** aligner l'arbre sur le front **Next.js** du dépôt et l'unité **systemd** `deploy/systemd/enso-enso-front.service` (`npm run start` après `next build`). --- ## 9. Checklist d’installation (par environnement) - [ ] Prérequis installés (Node, Rust, PostgreSQL, Git). - [ ] Dépôt cloné et sous-modules initialisés. - [ ] Variables d’environnement définies (`.env` ou `.secrets//`). - [ ] BDD créées et migrations appliquées. - [ ] Build des fronts et des backends effectué. - [ ] Fichiers déployés sur la machine cible (binaires, build Next.js, config). - [ ] Services configurés (systemd ou équivalent) et démarrés. - [ ] Proxy : vhosts HTTPS et certificats (contrôle §8.1 pour **docv** ; idem **enso** selon mêmes principes). --- ## 10. Références - [README.md](README.md) — index de la documentation. - [ARCHITECTURE_DOCV_ENSO.md](ARCHITECTURE_DOCV_ENSO.md) — découpage des projets et infra. - [docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) — stack, config back (DATABASE_URL, JWT_SECRET, etc.). - [PLAN_DEVELOPPEMENT.md](PLAN_DEVELOPPEMENT.md) — jalons et scripts deploy. - [PORTS_ENSO.md](PORTS_ENSO.md) — cartographie des ports (déjà utilisés, ports attribués enso, identiques en dev/test/pprod/prod). - Infrastructure Cloud 4NK — adresses des machines (proxy, test, pprod, prod), accès SSH, conventions de déploiement.