Déploiement sur etherbay.tech

La démonstration publique de BlockLucky est hébergée sous le domaine etherbay.tech, sur une machine virtuelle Azure. Cette page décrit ce qui est en place, la procédure prévue pour déployer l'application et ce qui reste à faire.

#Ressources

L'adresse IP publique et la clé SSH ne sont pas consignées dans la documentation. La connexion se fait par le nom de domaine :

ssh etherbay@etherbay.tech

#Architecture cible

flowchart LR
    U["Navigateur ou application mobile"] -->|"HTTPS 443"| C["Caddy, projet edge, network_mode host"]
    C -->|"etherbay.tech"| W["web, 127.0.0.1:3000"]
    C -->|"api.etherbay.tech"| A["backend, 127.0.0.1:2053"]
    C -->|"tourisme.etherbay.tech"| T["tourisme, 127.0.0.1:4000"]
    C -->|"docs.etherbay.tech"| D["fichiers statiques /srv/docs"]
    A --> PG["postgres"]
    A --> R["redis"]
    A --> BC["blockchain, nœud Hardhat"]
    K["worker"] --> PG
    K --> R
    K --> BC

Deux projets Compose cohabitent sur la VM :

• edge, dans /opt/edge : Caddy seul, en network_mode: host, qui écoute sur les ports 80 et 443 de l'hôte et obtient les certificats Let's Encrypt ;
• blocklucky : la stack du dépôt avec le profil app, dont les ports applicatifs sont publiés sur 127.0.0.1.

Le nœud Hardhat tourne sur la VM, dans le service blockchain de la stack. La démonstration n'utilise pas Sepolia : elle reste indépendante des robinets et du financement d'un abonnement Chainlink.

#Ce qui est en place

#Préparation de la machine

#Proxy Caddy

Caddy route chaque nom vers sa cible et gère HTTPS de bout en bout :

Le statut 503 signale aux robots d'indexation une indisponibilité temporaire et non une page définitive.

Le Caddyfile de /opt/edge n'est pas versionné dans le dépôt, à l'exception du bloc de la documentation (documentation-officielle/deploiement/Caddyfile).

#Procédure de déploiement prévue

Les commandes s'exécutent sur la VM, sous le compte etherbay, depuis la racine d'un clone du dépôt.

#1. Récupérer le code

Cloner le dépôt MarceauTDML/BlockLucky et se placer sur la branche ou le commit à présenter. Noter le SHA du commit déployé : c'est la référence pour un retour arrière.

#2. Créer les secrets

Créer un fichier .env à la racine du clone, lisible par le seul compte etherbay :

umask 077
cat > .env <<EOF
JWT_SECRET=$(openssl rand -hex 32)
ENCRYPTION_KEY=$(openssl rand -hex 32)
RELAYER_PRIVATE_KEY=0x$(openssl rand -hex 32)
WEBHOOK_SECRET=$(openssl rand -hex 24)
METRICS_TOKEN=$(openssl rand -hex 24)
EOF

Ces cinq variables sont exigées par le schéma de env.config.ts dès que NODE_ENV=production (voir Docker Compose). Une clé RELAYER_PRIVATE_KEY aléatoire convient : le service blockchain habilite et approvisionne automatiquement le compte qui en dérive. Conserver une copie de ENCRYPTION_KEY hors de la VM tant que la démonstration dure : sans elle, les portefeuilles intégrés ne peuvent plus être déchiffrés.

#3. Adapter la configuration aux URL publiques (à faire)

Le fichier docker-compose.yml vise localhost. Plusieurs valeurs y sont écrites en dur et doivent être remplacées. La solution prévue est un fichier de surcharge propre à la VM, par exemple docker-compose.etherbay.yml, non commité, chargé après le fichier principal.

Pourquoi chaque point compte :

• TRUST_PROXY. Derrière Caddy, toutes les requêtes arrivent au conteneur depuis la même adresse interne. Sans TRUST_PROXY=1, Express ignore l'en-tête X-Forwarded-For posé par Caddy : tous les visiteurs partagent alors le même compteur du rate limiter global (300 requêtes par 15 minutes) et du limiteur d'authentification (30 tentatives par 10 minutes), et la démonstration se bloque en quelques minutes. La valeur 1 fait confiance à un seul saut, Caddy. La lecture de la variable est faite dans trustProxy de env.config.ts, qui convertit un entier en nombre de sauts.
• NEXT_PUBLIC_*. Ces valeurs sont des arguments de build. Après modification, l'image web doit être reconstruite (--build), sinon le navigateur continue d'appeler localhost et la CSP bloque les appels vers api.etherbay.tech.
• POAP_BASE_URI. Le préfixe est passé au constructeur de BlockLuckyPOAP par deploy-local.ts. Il ne change qu'au prochain démarrage du service blockchain, qui redéploie les contrats, ou par un appel à setBaseUri signé par un détenteur de DEFAULT_ADMIN_ROLE (le compte Hardhat n° 0 en local).
• Ports. Docker écrit ses propres règles iptables pour les ports publiés, en amont de ufw. Un port publié sur toutes les interfaces est joignable depuis Internet malgré le pare-feu, sauf si le groupe de sécurité réseau Azure le bloque. Lier les ports à 127.0.0.1 laisse Caddy seul exposé.

Exemple de fichier de surcharge :

services:
  backend:
    environment:
      FRONTEND_URL: https://etherbay.tech
      CORS_ORIGINS: https://etherbay.tech
      TRUST_PROXY: "1"
    ports: !override
      - "127.0.0.1:2053:2053"
  worker:
    environment:
      FRONTEND_URL: https://etherbay.tech
      CORS_ORIGINS: https://etherbay.tech
      TRUST_PROXY: "1"
  web:
    build:
      args:
        NEXT_PUBLIC_API_URL: https://api.etherbay.tech/api
        NEXT_PUBLIC_WS_URL: https://api.etherbay.tech
    ports: !override
      - "127.0.0.1:3000:3000"
  tourisme:
    ports: !override
      - "127.0.0.1:4000:8080"
  blockchain:
    environment:
      POAP_BASE_URI: https://api.etherbay.tech/api/v1/lottery/poap/

Les clés environment et build.args se fusionnent clé par clé avec le fichier principal. Les listes ports, elles, s'additionnent : la balise !override de Compose remplace la liste au lieu de la compléter. Avant tout démarrage, contrôler le résultat :

docker compose -f docker-compose.yml -f docker-compose.etherbay.yml --profile app config

Vérifier dans la sortie que chaque port applicatif commence par 127.0.0.1 et que les URL sont en https://.

#4. Construire et démarrer (à faire)

docker compose -f docker-compose.yml -f docker-compose.etherbay.yml --profile app up -d --build --wait

L'ordre de démarrage est géré par Compose : PostgreSQL, Redis et la blockchain, puis les migrations, puis l'API et le worker, puis le web (voir Docker Compose). Le premier démarrage de blockchain compile et déploie les contrats, ce qui peut prendre une minute.

#5. Basculer Caddy vers l'application (à faire)

Dans le Caddyfile de /opt/edge, remplacer la réponse 503 de chaque nom par un proxy :

etherbay.tech {
	reverse_proxy 127.0.0.1:3000
}

api.etherbay.tech {
	reverse_proxy 127.0.0.1:2053
}

tourisme.etherbay.tech {
	reverse_proxy 127.0.0.1:4000
}

reverse_proxy relaie aussi les connexions WebSocket de Socket.IO, sans réglage supplémentaire. Caddy ajoute X-Forwarded-For, X-Forwarded-Proto et X-Forwarded-Host. Le frontend web et le site de l'Office de Tourisme envoient déjà leurs propres en-têtes de sécurité. Recharger Caddy depuis /opt/edge après modification.

Il est recommandé de ne pas exposer /metrics publiquement, même s'il est protégé par METRICS_TOKEN, par exemple avec un bloc respond /metrics 404 dans le site api.etherbay.tech.

#6. Décider du contenu de démonstration (à faire)

Le service migrate applique les migrations mais ne lance aucun seed : la base démarre vide, sans compte administrateur, sans partenaire ni récompense. Pour présenter l'espace Mairie et la boutique, il faut charger les données de prisma/seed.ts. L'image runtime ne contient pas tsx ; l'image migrator contient toutes les dépendances de développement et le dossier prisma/. Le chargement depuis cette image, et la façon dont l'administrateur obtient ensuite sa double authentification, restent à valider sur la stack Docker locale avant la VM. Voir Seed et Comptes de démonstration et connexion.

#7. Décider de l'envoi des emails (à faire)

En production, la connexion exige un code envoyé par email (LOGIN_EMAIL_CODE_REQUIRED ne peut pas être désactivé quand NODE_ENV=production). Dans la stack, SMTP_HOST vaut mailpit : les codes sont capturés par Mailpit et n'atteignent pas les boîtes des visiteurs. Deux options :

• Démonstration encadrée : garder Mailpit et lire les codes dans son interface, liée à 127.0.0.1:8025 sur la VM, par un tunnel SSH :

  Terminal

  ssh -L 8025:127.0.0.1:8025 etherbay@etherbay.tech

  puis ouvrir http://localhost:8025 sur le poste. Seules les personnes ayant la clé SSH peuvent se connecter.

• Démonstration ouverte : configurer un vrai relais SMTP. SMTP_HOST et SMTP_PORT sont écrits en dur dans x-backend-env et SMTP_USER, SMTP_PASS, SMTP_FROM n'y figurent pas : il faut les ajouter dans la surcharge pour backend et worker. Le port 465 active TLS (secure dans mailer.config.ts). Le domaine d'expédition doit alors être autorisé par le relais (SPF, DKIM).

#8. Vérifier

curl -fsS https://api.etherbay.tech/health/ready

curl -fsS https://api.etherbay.tech/api/config

curl -fsS -H "Authorization: Bearer $METRICS_TOKEN" https://api.etherbay.tech/health/deep

Puis, dans un navigateur : ouverture de https://etherbay.tech, absence d'erreur CSP dans la console, inscription, réception du code, achat d'un ticket et apparition du tirage en direct. Le scénario complet de démonstration est dans Préparer la soutenance. Un test de fumée k6 peut compléter (voir Tests de charge).

#9. Application mobile (à faire)

Pour qu'un téléphone utilise la démonstration, construire l'application avec EXPO_PUBLIC_API_URL=https://api.etherbay.tech/api et EXPO_PUBLIC_WS_URL=https://api.etherbay.tech. Ces variables sont lues par api.client.ts et socket.client.ts. Les applications natives n'envoient pas d'en-tête Origin et ne sont donc pas concernées par CORS_ORIGINS.

#Exploitation pendant la démonstration

Les journaux se lisent depuis le clone :

docker compose --profile app logs -f --since 10m backend worker

#Fin de vie

Après la soutenance, vers le 18 novembre 2026 :

1. sauvegarder ce qui doit l'être (aucune donnée réelle n'est traitée, une sauvegarde n'est utile que pour rejouer la démonstration) ;

2. supprimer le groupe de ressources, ce qui supprime la VM, son disque, son adresse IP et son groupe de sécurité réseau :

   Terminal

   az group delete --name rg-etherbay

3. retirer ou rediriger les enregistrements DNS chez get.tech, pour qu'aucun sous-domaine ne pointe vers une adresse IP réattribuée à un tiers.

Le domaine reste enregistré jusqu'au 11 novembre 2027 et ne sera pas renouvelé automatiquement.

#Récapitulatif de ce qui reste à faire