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.5 KiB
Docker
42 lines
2.5 KiB
Docker
# lavinmq's runtime: the tool runtime, carrying this module's compiled bootstrap, 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/lavinmq
|
|
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.
|
|
#
|
|
# Four entrypoints and a client, because this module is four things: a run-once bootstrap that
|
|
# writes the broker's configuration before it first starts, a provisioner that grants consumers
|
|
# their own vhost and user, a set of tools, and an event consumer.
|
|
RUN node /app/node_modules/typescript/bin/tsc \
|
|
client.ts index.ts bootstrap/index.ts provisioner/index.ts tools/index.ts \
|
|
--module NodeNext --moduleResolution NodeNext --target ES2022 --outDir dist
|
|
|
|
FROM ${RUNTIME_BASE}
|
|
COPY --from=build /app/modules/lavinmq/dist /app/modules/lavinmq/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 bootstrap and the
|
|
# provisioner are not listed here — the declaration names each in its container's `args`, because
|
|
# they are what this module's own containers run. One image, because they are one module and share
|
|
# a client.
|
|
ENV MESH_TOOL_MODULES=/app/modules/lavinmq/dist/index.js,/app/modules/lavinmq/dist/tools/index.js,/app/modules/lavinmq/dist/provisioner/index.js
|