kesh/docker-compose.dev.yml at main · guycorbaz/kesh · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
# Mode dev : MariaDB + kesh-api (mode test intégration)
# Pour le développement quotidien avec hot reload : cargo run + MariaDB seule
# Pour la production : voir docker-compose.yml (Story 8.1)

services:
  kesh:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: kesh-dev
    restart: unless-stopped
    ports:
      - "127.0.0.1:80:80"
    environment:
      DATABASE_URL: mysql://kesh:kesh_dev@mariadb:3306/kesh
      KESH_PORT: "80"
      # Story 6.4 : le défaut applicatif est désormais 127.0.0.1. En Docker,
      # on bind 0.0.0.0 pour que le port mapping `127.0.0.1:80:80`
      # de la section `ports:` fonctionne (sinon le container écouterait
      # uniquement sur sa propre loopback, inaccessible depuis l'hôte).
      # Ne JAMAIS set KESH_TEST_MODE=true avec KESH_HOST=0.0.0.0
      # (ConfigError::TestModeWithPublicBind refusera le démarrage).
      KESH_HOST: "0.0.0.0"
      KESH_ADMIN_USERNAME: ${KESH_ADMIN_USERNAME:-admin}
      KESH_ADMIN_PASSWORD: ${KESH_ADMIN_PASSWORD:-admin}
      KESH_JWT_SECRET: ${KESH_JWT_SECRET:-dev-secret-at-least-32-bytes-long-for-testing}
      # Onboarding reset gate (Story 7-1, KF-002).
      # Set to "1" / "true" / "yes" to allow /onboarding/reset past step 2 in demo mode.
      # NEVER enable in production — see docs/MULTI-TENANT-SCOPING-PATTERNS.md.
      KESH_PRODUCTION_RESET: ${KESH_PRODUCTION_RESET:-}
      RUST_LOG: ${RUST_LOG:-info}
      # Logs fichier (Story v011-1, Issue #119) — DÉSACTIVÉS par défaut en dev
      # (stdout/`docker logs` suffit). Pour les activer : set KESH_LOG_FILE_PATH
      # (ex. /var/log/kesh/kesh.log) + ajouter un mount `- ./log:/var/log/kesh`.
      KESH_LOG_FILE_PATH: ${KESH_LOG_FILE_PATH:-}
      KESH_LOG_FILE_ROTATION: ${KESH_LOG_FILE_ROTATION:-daily}
      KESH_LOG_FILE_MAX_FILES: ${KESH_LOG_FILE_MAX_FILES:-7}
      KESH_LOG_FILE_FORMAT: ${KESH_LOG_FILE_FORMAT:-pretty}
    depends_on:
      mariadb:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 15s

  mariadb:
    image: mariadb:10.11
    container_name: kesh-mariadb-dev
    restart: unless-stopped
    ports:
      - "127.0.0.1:3306:3306"
    environment:
      MARIADB_ROOT_PASSWORD: kesh_dev_root
      MARIADB_DATABASE: kesh
      MARIADB_USER: kesh
      MARIADB_PASSWORD: kesh_dev
    # Story 22-5 (#251) — LA BASE DE DEV EST JETABLE, ET MONTÉE EN RAM.
    #
    # ⚠️ Conséquence assumée : /var/lib/mysql ne survit PAS au restart du
    # conteneur. La base `kesh` repart vide, et son seed doit être rejoué —
    # procédure dans docs/testing.md § « Base de dev jetable ». L'oubli est
    # bruyant, pas silencieux : les 154 tests sur base partagée s'ouvrent sur
    # `expect("need at least one company in DB for tests")`.
    #
    # En contrepartie, les bases éphémères de `#[sqlx::test]` ne touchent plus
    # le disque, et les orphelines qu'un run interrompu laisse derrière lui
    # sont effacées par le restart au lieu de s'accumuler.
    #
    # `size=` est EXPLICITE, et c'est le point important : le défaut d'un tmpfs
    # est la MOITIÉ de la RAM de l'hôte, ce qui ferait de cette ligne une réserve
    # de 15 Go sur une station qui a déjà perdu deux sessions à l'OOM (cf.
    # CLAUDE.md § « Plafonds mémoire »). Les pages d'un tmpfs sont du shmem, donc
    # NON recyclables : elles pèsent sur cette pression-là, et le conteneur vit
    # dans `system.slice`, hors de portée de `scripts/mem-guard.sh`.
    #
    # ⚠️ 4 Go couvrent un run VERT (≤ 6 bases éphémères vivantes à la fois, plus
    # la base de dev et celles de gate), pas un run massivement ROUGE : sqlx ne
    # détruit PAS la base d'un test échoué. À ~17 Mo la base, les ~3,3 Go libres
    # en tiennent environ 190 — au-delà, MariaDB rend « table is full » sur les
    # suivants. Les PREMIERS échecs portent la cause réelle ; ceux d'après ne
    # portent que la saturation. La reprise est un `restart` du conteneur, qui
    # efface tout (cf. docs/testing.md § « Base de dev jetable »).
    # *(Chiffres mesurés dans le conteneur par la passe 1 de revue de code, qui
    # a réfuté l'affirmation « 4 Go couvrent largement un run complet ».)*
    tmpfs:
      - /var/lib/mysql:size=4g
    # Corollaire du tmpfs : les tables système repartent vierges à chaque
    # démarrage, donc les droits globaux dont `#[sqlx::test]` a besoin pour
    # créer ses bases éphémères disparaissent avec elles. L'entrypoint MariaDB
    # rejoue ce répertoire dès que le datadir est vide — ici, à tous les coups.
    volumes:
      - ./scripts/mariadb-init:/docker-entrypoint-initdb.d:ro
    # Durabilité relâchée : la donnée ne survit pas au restart de toute façon,
    # payer les fsync de chaque commit n'achète plus rien.
    command:
      - --innodb_flush_log_at_trx_commit=0
      - --sync_binlog=0
      - --innodb-doublewrite=0
    # ⚠️ Le budget d'attente a été élargi avec le tmpfs : CHAQUE démarrage est
    # désormais un démarrage à froid (`mysql_install_db` + les scripts de
    # /docker-entrypoint-initdb.d), là où un restart retrouvait auparavant un
    # datadir initialisé. Sur station chargée, l'ancienne fenêtre (~60 s) rendait
    # le conteneur `unhealthy` et faisait échouer le `depends_on` du service
    # `kesh`. *(Relevé en passe 1 de revue de code.)*
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 90s