Summary
ess-service does not yet have a Bazel-native container image. Every other
control-plane Java service (api-keys, notary, cloud-tasks) builds its image
from the monorepo through the shared java_oci_image macro and guards it with
java_image_contract_test. ess-service is still built only from its standalone
Dockerfile, so it is the odd one out and cannot be produced or verified by the
monorepo image tooling.
Motivation
- Consistency: bring ess-service in line with the other Java services so all
images are built the same way, on the same NVIDIA distroless Java base, with
the same multi-arch output.
- Correctness: the distroless base uses a shelless_ulimit entrypoint shim that
only raises the file-descriptor soft limit when ULIMIT_FLAG=1. The
ess-service Dockerfile did not set it, so ESS ran on the default 1024 soft
limit while every peer service raised it.
- Safety: a contract test that fails the build if the jar path, entrypoint
shim, env, or working directory drift, on both amd64 and arm64.
Proposed change
- Add a java_oci_image target (ess-service-oss-image) and a
java_image_contract_test target (image_contract_test) to
src/control-plane-services/ess/ess-service/BUILD.bazel.
- Align the ess-service Dockerfile with the peer services so the Dockerfile
and the Bazel image agree:
- use COPY instead of ADD and install the jar at /usr/share/app.jar
- set ULIMIT_FLAG=1
- set WORKDIR /home/app
- Keep the ESS-specific JVM memory tuning in JAVA_TOOL_OPTIONS unchanged.
Acceptance criteria
- ess-service-oss-image builds as a multi-arch index (amd64 and arm64).
- image_contract_test passes and asserts the jar location, the shelless_ulimit
entrypoint, all declared env entries, and the working directory.
- The Dockerfile and the Bazel image declare the same jar path, env, and
working directory.
- No change to ESS runtime behavior beyond raising the file-descriptor limit
through ULIMIT_FLAG.
Verification
bazel test //src/control-plane-services/ess/ess-service:image_contract_test
Out of scope
- Whether to drop -XX:+PrintFlagsFinal from JAVA_TOOL_OPTIONS (noisy at
startup). Tracked separately.
- Switching JAVA_TOOL_OPTIONS to JDK_JAVA_OPTIONS. ESS values are
service-specific and left as-is.
Summary
ess-service does not yet have a Bazel-native container image. Every other
control-plane Java service (api-keys, notary, cloud-tasks) builds its image
from the monorepo through the shared java_oci_image macro and guards it with
java_image_contract_test. ess-service is still built only from its standalone
Dockerfile, so it is the odd one out and cannot be produced or verified by the
monorepo image tooling.
Motivation
images are built the same way, on the same NVIDIA distroless Java base, with
the same multi-arch output.
only raises the file-descriptor soft limit when ULIMIT_FLAG=1. The
ess-service Dockerfile did not set it, so ESS ran on the default 1024 soft
limit while every peer service raised it.
shim, env, or working directory drift, on both amd64 and arm64.
Proposed change
java_image_contract_test target (image_contract_test) to
src/control-plane-services/ess/ess-service/BUILD.bazel.
and the Bazel image agree:
Acceptance criteria
entrypoint, all declared env entries, and the working directory.
working directory.
through ULIMIT_FLAG.
Verification
Out of scope
startup). Tracked separately.
service-specific and left as-is.