feat(sdk): start sandbox from Dockerfile via Image.from_dockerfile#931
Closed
Issac-Newton wants to merge 2 commits into
Closed
feat(sdk): start sandbox from Dockerfile via Image.from_dockerfile#931Issac-Newton wants to merge 2 commits into
Issac-Newton wants to merge 2 commits into
Conversation
Issac-Newton
force-pushed
the
feature/start-from-dockerfile
branch
from
8ac6e5f to
fa0f985
Compare
Issac-Newton
force-pushed
the
feature/start-from-dockerfile
branch
2 times, most recently
from
c6c851b to
80311e3
Compare
Add Image declarative class with from_dockerfile() factory and a unified sandbox.ImageBuilder that resolves builds via a DinD builder sandbox. SandboxConfig accepts Image as input; Sandbox.start() builds and pushes the image, then syncs registry credentials to admin so it can pull. Includes specs (requirement / investigation / implementation) and integration tests that drive the build via a test-managed builder with iptables loopback NAT, so a local registry on 127.0.0.1 is reachable from inside the builder's network namespace. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…y/tag Replace the single-string image_name auto-generation in from_dockerfile() with explicit 4-segment composition: registry_url / namespace / repository : tag. Repository defaults to SandboxConfig.user_id (or "default" fallback), injected by Sandbox.start(). Tag uses the full 64-hex SHA-256 of the build context, matching the OCI digest standard for collision safety. Add ROCK_IMAGE_NAMESPACE env var (default "rock") and thread Image._resolve_full_name() through ImageBuilder so dockerfile-based images compose the registry tag once. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Issac-Newton
force-pushed
the
feature/start-from-dockerfile
branch
from
80311e3 to
a591513
Compare
Collaborator
Author
|
Superseded — history was rewritten (squashed 16 commits → 2, dropped one unrelated commit). Reopening as a fresh PR for clean review. New PR will be linked in the next comment. |
4 tasks
Collaborator
Author
|
Replaced by #1043. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fixes #531
Summary
Imagedeclarative type (rock/sdk/sandbox/image.py) withImage.base()andImage.from_dockerfile()factories.SandboxConfig.imageacceptsstr | Image; resolution to a tag string happens transparently insideSandbox.start()so admin / db schemas stay untouched._ImageResolverorchestrates DinD build/push inside a builder sandbox: cache check viadocker manifest inspect+ content-hash label, build withrock.content_hashbaked in, push with credentials supplied by theImage. Builder lifecycle is split intocreate_builder()/resolve()/resolve_with_builder()so callers (e.g. tests) can manage the builder themselves and inject environment-specific setup before the build runs.Sandbox.start()syncs theImage's registry credentials toSandboxConfigso admin can pull the just-pushed image.ImageBuilder(rock/sdk/builder/image_builder.py) implementing theEnvBuilderinterface for use from non-SDK call sites (e.g. Harbor flow).ROCK_IMAGE_BUILDER_IMAGEpoints torock-env-builder:latestwhich has a non-conflicting docker0 (bip=192.168.250.1/24) so inner dockerd doesn't collide with the outer admin's docker0 (172.17/16); also pre-configuresinsecure-registriesfor local CIDRs so test registries work.Spec / Design
Test plan
pytest tests/integration/sdk/sandbox/test_image_build.py -m need_admin— 3/3 PASSEDtest_from_dockerfile_build_and_start— build + push + start sandbox + verify COPY'd filetest_from_dockerfile_cache_skip— second build of same Image hits cache (CACHE_HIT), skips pushtest_from_dockerfile_rebuilds_on_content_change— content_hash change triggers rebuildpytest tests/integration/sdk/builder/test_image_builder.py -m need_admin—ImageBuilder.buildagainst local registryuv run pytest -m "not need_ray and not need_admin and not need_admin_and_network" --reruns 1Notes for reviewers
local_registryonlocalhost:port. From inside the builder sandbox (own netns),localhostis its own loopback so push needs an iptables OUTPUT DNAT to the host bridge IP plus POSTROUTING MASQUERADE; the test installs this via_inject_loopback_natbefore callingresolve_with_builder. Production path (admin pulls from a real registry) is unaffected.rock-n-roll-registry.cn-hangzhou.cr.aliyuncs.com/rock/rock-env-builder:latest(digest sha256:9bf940765b2b...). It carries thebip+insecure-registriesdaemon.json fixes and the ulimit-tolerant init.d.🤖 Generated with Claude Code