jschoubben
591b26f712
keycloak, mailu, minio, mongodb, mssql, nextcloud, portainer, redis, umami and verdaccio get the Dockerfile + build section the eight buildable modules already had; their runtime containers name the artifact instead of a placeholder digest. One convention, settled (060's open question, informed by 061): the runtime container runs serve mode with every serve-time entrypoint in MESH_TOOL_MODULES — tools serve, events flow, and a provider's provisioner reconciles in the same process with the broker connected. postgres, gitea and lavinmq are retrofitted from args-run provisioners, which served no tools and emitted lifecycle events nowhere. route-proxy is deferred: its build context is the mesh-controller repository, a cross-repo shape the build section cannot yet express.
42 lines
2.6 KiB
Docker
42 lines
2.6 KiB
Docker
# postgres's runtime: the tool runtime, carrying this module's compiled provisioner, tools and
|
|
# event consumer.
|
|
#
|
|
# **Built from this module's own directory and nothing else.** The sdk is in the base image, so
|
|
# nothing is copied out of a neighbouring checkout — which is what lets the mesh build this from a
|
|
# repository and a path (novox/hq ADR 0069) rather than only on a workstation that happens to have
|
|
# the siblings.
|
|
#
|
|
# Two bases, named rather than pinned: the image this is COMPILED in, and the image it RUNS in.
|
|
# They are different images on purpose — the first carries a compiler and the second must not, or
|
|
# every running container would carry one it never invokes. The mesh answers both with the copies it
|
|
# holds, because a fingerprint written here would name one particular copy and no other mesh has it
|
|
# (novox/hq issue 044). Declared in module.json's `build.on`; deliberately no defaults, so a build
|
|
# nobody told stops here and says which module to build first.
|
|
ARG BUILD_BASE
|
|
ARG RUNTIME_BASE
|
|
|
|
FROM ${BUILD_BASE} AS build
|
|
# Compiled under /app/modules so `@novox/mesh-sdk` resolves upward into the base's own
|
|
# node_modules — the module is compiled against exactly the sdk it will run against.
|
|
WORKDIR /app/modules/postgres
|
|
COPY . .
|
|
# The compiler is invoked by its real path rather than through node_modules/.bin, whose entries are
|
|
# symlinks to a launcher that requires its library relatively — resolved away when the base image
|
|
# was assembled.
|
|
RUN node /app/node_modules/typescript/bin/tsc client.ts index.ts provisioner/index.ts tools/index.ts \
|
|
--module NodeNext --moduleResolution NodeNext --target ES2022 --outDir dist
|
|
|
|
FROM ${RUNTIME_BASE}
|
|
# **This module talks to its database through psql, so psql has to be here.** The client is how
|
|
# postgres's provisioner runs DDL — it does not carry a driver — and the runtime base holds only
|
|
# what every module needs.
|
|
RUN apt-get update \
|
|
&& apt-get install -y --no-install-recommends postgresql-client \
|
|
&& rm -rf /var/lib/apt/lists/*
|
|
COPY --from=build /app/modules/postgres/dist /app/modules/postgres/dist
|
|
# What a tool host should load from this module: its event consumer and its tools, which are
|
|
# separate entrypoints because they are loaded by different things. The provisioner is the third,
|
|
# and is not listed here — the declaration names it in the container's `args`, because it is what
|
|
# this module's own container runs. One image, because they are one module and share a client.
|
|
ENV MESH_TOOL_MODULES=/app/modules/postgres/dist/index.js,/app/modules/postgres/dist/tools/index.js,/app/modules/postgres/dist/provisioner/index.js
|