Files
apps-registry/workloads/commerce-backend/Dockerfile
T
devops 6be8dd409c Fase 2 ADR 0006 Etapa 2: plugin de Meilisearch + ruta de facetas
Instala @rokmohar/medusa-plugin-meilisearch@^1.4.1 (linea v1, la unica
compatible con nuestro Medusa 2.18.0 exacto -- confirmado contra
peerDependencies reales de npm: @medusajs/* ^2.15.2, satisfecho por
2.18.0). Conectado via un array `plugins:` nuevo en medusa-config.ts
(primer uso en este repo, no `modules:`), env vars leidos con `?? ""`
en vez de required() -- si Meilisearch esta caido o mal configurado,
el plugin se degrada solo en vez de tumbar el arranque de Medusa
entero.

No se escribe un subscriber propio: se verifico contra el codigo
fuente real del paquete (descargado el tarball exacto de npm,
inspeccionado en /app/node_modules dentro de una imagen Docker de
verdad) que trae sus propios subscribers de product/category/
collection/variant/etc, descubiertos por Medusa en runtime desde
dentro del propio paquete -- confirmado que sobreviven a
`npm prune --omit=dev` y llegan intactos a la imagen final. Tambien
trae un job de indexado inicial de una sola corrida al boot
(numberOfExecutions: 1, no un cron recurrente -- no viola la
restriccion del ADR de "nunca cron").

Nueva ruta Store API propia (src/api/store/search/route.ts): las
rutas /store/meilisearch/* que trae el plugin no devuelven
facetDistribution (verificado leyendo su codigo fuente), asi que esta
ruta pide facets explicitamente via additionalOptions.facets, y
despues re-hidrata los productos via query.graph (mismos campos que
ya usa el storefront) en vez de confiar en precios/inventario
indexados -- mismo patron "safe path" que ya usa la ruta oficial del
plugin para /store/meilisearch/products.

Transformer custom en medusa-config.ts que espeja mapProduct() del
storefront (category/collection/brand/ageRange desde metadata,
disponibilidad desde la primera variante) para que el documento
indexado sea exactamente lo que el storefront ya muestra.

Validado en vivo: build completo de Docker (target builder) corre
limpio -- npm ci, medusa build (typecheck + compile backend/frontend),
npm prune -- cero errores. package-lock.json regenerado con un
contenedor node:22.18.0-bookworm-slim real (mismo base image que el
Dockerfile), no a mano.

Dockerfile: dummy MEILISEARCH_HOST/MEILISEARCH_API_KEY en el stage de
build (insurance barata, no son required() asi que no eran
estrictamente necesarios para que el build pasara, y de hecho paso
sin ellos en la prueba -- se dejan de todas formas por consistencia
con el resto de dummies de esa capa).
2026-08-26 15:39:30 -05:00

107 lines
3.5 KiB
Docker

# syntax=docker/dockerfile:1.7
#############################################################
# Builder
#############################################################
FROM node:22.18.0-bookworm-slim AS builder
WORKDIR /app
ENV CI=true \
NODE_ENV=development \
NPM_CONFIG_UPDATE_NOTIFIER=false \
DATABASE_URL=postgres://medusa:[email protected]:5432/medusa \
REDIS_URL=redis://127.0.0.1:6379 \
STORE_CORS=http://localhost:8000 \
ADMIN_CORS=http://localhost:7001 \
AUTH_CORS=http://localhost:7001 \
JWT_SECRET=build-only-jwt-secret \
COOKIE_SECRET=build-only-cookie-secret \
S3_FILE_URL=http://localhost:9000/ari-shopping \
S3_ACCESS_KEY_ID=build-access-key \
S3_SECRET_ACCESS_KEY=build-secret-key \
S3_BUCKET=ari-shopping \
S3_ENDPOINT=http://127.0.0.1:9000 \
MEILISEARCH_HOST=http://127.0.0.1:7700 \
MEILISEARCH_API_KEY=build-only-meili-key
COPY package.json package-lock.json .npmrc ./
RUN --mount=type=cache,id=medusa-npm-cache,target=/root/.npm \
npm ci \
--legacy-peer-deps \
--prefer-offline \
--no-audit \
--no-fund
COPY tsconfig.json ./
COPY medusa-config.ts ./
COPY src ./src
RUN npm run build
#
# Elimina todas las dependencias de desarrollo
#
RUN npm prune --omit=dev
#
# Limpia cache de npm
#
RUN npm cache clean --force
#############################################################
# Runtime
#############################################################
FROM node:22.18.0-bookworm-slim
WORKDIR /app
ENV NODE_ENV=production \
PORT=9000 \
NPM_CONFIG_UPDATE_NOTIFIER=false
#
# libgnutls30 en la base node:22.18.0-bookworm-slim trae dos CVE
# CRITICAL con fix ya publicado por Debian (CVE-2026-33845,
# CVE-2026-42010) -- detectado por el gate de Trivy imagen del
# pipeline (run 138). Solo se actualiza este paquete puntual, no toda
# la imagen, para minimizar el diff de superficie de la base.
RUN apt-get update \
&& apt-get upgrade -y libgnutls30 \
&& rm -rf /var/lib/apt/lists/*
# El CLI global de npm que trae la imagen base node:*-slim arrastra su
# propia copia vendorizada de `tar` con un CVE CRITICAL
# (CVE-2026-59873, detectado por Trivy en
# usr/local/lib/node_modules/npm/node_modules/tar). Se elimina npm
# entero -- no alcanza con borrar solo el tar vendorizado: el propio
# `npx` depende de ese tar internamente (pacote/arborist) incluso para
# ejecutar un binario ya instalado localmente, así que queda roto igual
# si el paquete tar desaparece pero npm sigue ahí (confirmado
# probando "npx medusa --version" contra la imagen: falla con
# "Cannot find module 'tar'").
#
# OJO con este cambio: el init container "migrations" de
# workloads/ecommerce/commerce/medusa.yaml corría "npx medusa
# db:migrate" contra esta misma imagen -- un primer intento de este
# fix borraba npm sin ajustar ese comando y rompió el init container
# en producción ("npx: executable file not found in $PATH",
# medusa-deploy atascado en Init:CrashLoopBackOff, detectado revisando
# el estado real del cluster después del deploy). El fix completo
# incluye cambiar ese comando a invocar el CLI directo con `node`, sin
# pasar por npm/npx -- mismo patrón que ya usa el CMD de este
# Dockerfile más abajo.
RUN rm -rf /usr/local/lib/node_modules/npm
#
# Solo lo necesario para ejecutar Medusa
#
COPY --from=builder --chown=node:node /app/node_modules ./node_modules
COPY --from=builder --chown=node:node /app/.medusa/server ./
USER node
EXPOSE 9000
CMD ["node","node_modules/@medusajs/cli/dist/index.js","start"]