Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

feat: make supervisor base image configurable via build ARG

Đã đóng Phù hợp với người mới
#4,205 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
84/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
docker
Lĩnh vực
build-system, devops

Hướng nghiên cứu

Bắt đầu bằng cách so sánh deploy/docker/Dockerfile.supervisor với deploy/docker/Dockerfile.gateway và đọc tài liệu về image cơ sở trong architecture/build.md. Thêm phần ghi đè supervisor, dùng image hiện đang được ghim làm giá trị mặc định, sau đó build cả khi có và không có phần ghi đè để kiểm tra hành vi mặc định và khả năng cấu hình. Công việc được xem là hoàn tất khi tài liệu đề cập đến cả hai phần ghi đè và giá trị mặc định vẫn không thay đổi.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

state:triage-needed

User Story

As an operator or downstream packager deploying OpenShell's supervisor container in an environment with specific registry-trust, compliance, or support constraints (e.g. a registry allowlist, a FIPS-validated base image requirement, or an internal support SLA tied to a specific image vendor), I want to override the supervisor's base image at build time, so that I can satisfy my environment's constraints without forking the Dockerfile.

Problem Statement

deploy/docker/Dockerfile.gateway already exposes its base image as a build ARG:

ARG GATEWAY_BASE_IMAGE=gcr.io/distroless/cc-debian13:nonroot@sha256:54df941ed0d06a1bd95ef5e0ce391fd8d9f94b64782dc9a60062727849ee3f97
FROM ${GATEWAY_BASE_IMAGE} AS gateway

deploy/docker/Dockerfile.supervisor does not. It hardcodes:

FROM gcr.io/distroless/base-nossl-debian13@sha256:af5cb8dd589b8520b8c06bebb9efb73d7e16406cab58e85c51761fff49d370a0 AS supervisor

There is no equivalent override point, so substituting an alternate base image for the supervisor today requires forking/patching the Dockerfile.

Impact / Why This Matters

Downstream consumers building in a registry-restricted environment, needing a FIPS-validated base, or needing a base image they can patch/support on their own schedule currently have to maintain a forked Dockerfile to get a different supervisor base image. A fork drifts from upstream over time (missed binary/build-step changes) and duplicates this maintenance burden across every downstream consumer who needs it. The gateway already solves this cleanly; the supervisor's inconsistency with that pattern is the actual gap, not a missing capability invented from scratch.

Proposed Design

Add a build ARG to deploy/docker/Dockerfile.supervisor (e.g. SUPERVISOR_BASE_IMAGE) defaulting to the current pinned image/digest, mirroring GATEWAY_BASE_IMAGE's existing pattern. This is purely additive: no default behavior change, and no change to published images unless a builder explicitly overrides the ARG. Exact ARG naming/defaulting mechanics are left to the implementing PR.

Acceptance Criteria

  • deploy/docker/Dockerfile.supervisor accepts a build ARG for its base image, with the current image pinned as the default.
  • Building without overriding the ARG produces the same image as today (no default-behavior change).
  • Wherever the gateway's GATEWAY_BASE_IMAGE override is documented (e.g. architecture/build.md) is updated to document the supervisor's new equivalent consistently.

Alternatives Considered

  • Status quo (hardcoded base, consumers fork the Dockerfile if they need something else) — rejected: duplicates maintenance effort per downstream consumer and drifts from upstream over time.
  • Change the default base image itself (e.g. to Red Hat's Project Hummingbird registry.access.redhat.com/hi/core-runtime) — rejected for now: a direct comparison (skopeo inspect against both) shows Hummingbird's core-runtime image is larger and has more layers than the current default (12.82 MB / 23 layers vs. the current base's 5.94 MB / 14 layers), and its image config sets CMD ["/bin/bash"], suggesting a shell may be present where the current distroless base has none. It is not a demonstrated improvement, and changing the project's default base is a larger decision needing broader maintainer alignment, not a mechanical change.
  • Make the sandbox image configurable the same way (deploy/docker/Dockerfile.sandbox, FROM scratch) — rejected: the sandbox image has no runtime base to swap, it's a bare static binary with no base at all, so this axis doesn't apply there.

Agent Investigation

Confirmed by reading the current Dockerfiles directly and inspecting published images/registries with skopeo inspect:

  • deploy/docker/Dockerfile.gateway already has the GATEWAY_BASE_IMAGE ARG described above.
  • deploy/docker/Dockerfile.supervisor has no equivalent ARG.
  • deploy/docker/Dockerfile.sandbox is FROM scratch with no base image to parameterize.
  • Published ghcr.io/nvidia/openshell/supervisor:dev is 15 layers / ~19.6 MB total; its base (distroless/base-nossl-debian13) is 14 layers / ~5.94 MB.
  • registry.access.redhat.com/hi/core-runtime:latest (Project Hummingbird's comparable minimal base) is 23 layers / ~12.82 MB, with image config CMD ["/bin/bash"].

No RFC needed — this is a small, additive, non-breaking build-configuration change, not a change to OpenShell's architecture or default behavior.

Ngôn ngữ chính
Rust
Star
13.2k
Fork
1.6k
Merge trung bình
1 ngày 19 giờ
Pull request đã merge (30 ngày)
343

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của NVIDIA/OpenShell

Tất cả issue của NVIDIA/OpenShell

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.