Files
bikoret/deploy/docker/Dockerfile.korban_processor
T
Scott KarpandClaude Fable 5.1 c0d0555aed the name: Bikoret — code, contracts, images
Headers X-Bikoret-Key / -Rebuke / -Verdict / -Bedikah; the `bikoret`
object and the "— bikoret …" fringe on a gate reply; environment
variables BIKORET_*; the image user and paths (/home/bikoret,
/tmp/bikoret, /var/lib/bikoret/manna, /etc/bikoret/secrets,
/opt/bikoret/spec); the tmp-bikoret pod volume; local databases
bikoret_dev/_test. Kubernetes resource names, the shorashim_app role and
the domain are unchanged (Tamid §1.1, "the names that still carry the
old word"). Doorpost c963c4fe…. Elixir 604/0, L3 10/0, korban 295,
Prolog bedikah 44/44. Gitea repo renamed heaviness510/bikoret (old URL
redirects).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-13 22:13:36 +00:00

80 lines
3.3 KiB
Docker

# check=skip=FromPlatformFlagConstDisallowed
# ^ The --platform=linux/amd64 pins below are DELIBERATE (Exoscale SKS
# nodes are amd64). BuildKit lints a constant --platform as a smell;
# here it is the fix. Silenced so a real warning is not lost in noise.
# Bikoret Korban Processor — Python offering protocol
# Construction spec §1.1: Python 3.12.2
# Processes korbanot (model outputs) through the offering protocol
#
# PLATFORM PIN: see Dockerfile.vav_pipeline for the rationale.
# Exoscale SKS = amd64; arm64 images cannot exec on the cluster.
#
# AZAZEL CO-RESIDENT:
# Per BUILD_AZAZEL.md, azazel_processor (the disposal channel) is
# imported by korban_processor.external_offering and runs in the
# same Python process. It is NOT a separate container — the two-goat
# architecture (Vayikra 16:8) requires equal-capacity disposal in
# the SAME pool. Both sources are baked into this image.
FROM --platform=linux/amd64 python:3.12.2-slim AS build
WORKDIR /app
# Copy korban_processor
COPY korban_processor/pyproject.toml ./
COPY korban_processor/src/ src/
COPY korban_processor/test/ test/
# Copy azazel_processor source — imported by korban_processor.external_offering
COPY azazel_processor/src/azazel_processor/ src/azazel_processor/
# Install dependencies FROM THE LOCK FILE (Construction §1.1).
# Until 2026-10-04 this line named three packages by hand and let pip
# choose every transitive one on the day of the build; and an unpinned
# `pip install poetry-core` rode along into the image. The lock's main
# group is rendered to hashed requirements and installed exactly:
# --require-hashes refuses anything the lock did not record, --no-deps
# refuses anything the lock did not list.
COPY korban_processor/poetry.lock ./
COPY scripts/lock_to_requirements.py /tmp/lock_to_requirements.py
RUN python /tmp/lock_to_requirements.py poetry.lock > /tmp/requirements.txt && \
pip install --no-cache-dir --require-hashes --no-deps -r /tmp/requirements.txt && \
pip check
# === RUNTIME STAGE ===
FROM --platform=linux/amd64 python:3.12.2-slim
RUN useradd --create-home --shell /bin/bash bikoret
USER bikoret
WORKDIR /home/bikoret/korban_processor
COPY --from=build --chown=bikoret:bikoret /app/ ./
COPY --from=build /usr/local/lib/python3.12/site-packages/ /usr/local/lib/python3.12/site-packages/
# PYTHONPATH puts korban_processor first; azazel_processor is a
# sibling package under the same src/ tree (see build stage above).
ENV PYTHONPATH=/home/bikoret/korban_processor/src
# L1 Torah filesystem — baked into the image
# L1 is read-only in fact, not only in name. Until 2026-10-04 the scroll
# was copied in owned by the service user with its write bits on: the
# process that reads Torah could also have rewritten it, and only the
# SHA-256 check would have noticed afterwards. Owned by root, no write
# bit for anyone; the service user can read and traverse, nothing more.
USER root
COPY --chown=root:root l1/ /mnt/torah/
RUN chmod -R a-w,a+rX /mnt/torah
# The second scroll (bishe'arecha §IV): the mesorah snapshot, read-only like L1.
COPY --chown=root:root mesorah/ /mnt/mesorah/
RUN chmod -R a-w,a+rX /mnt/mesorah
USER bikoret
ENV L1_MOUNT_POINT=/mnt/torah
ENV MESORAH_MOUNT_POINT=/mnt/mesorah
# The korban processor is invoked by the vav_pipeline
# In Phase 5, it will also expose an HTTP endpoint for external model integration
CMD ["python", "-m", "korban_processor"]