Perry Container Subsystem Production Readiness#76
Conversation
feat: implement production-ready container and workload orchestration
Finalize the OCI stack by implementing the `perry/container` and
`perry/container-compose` (workloads) subsystems. This moves the
implementation from initial stubs to a hardened, spec-compliant architecture.
Core Subsystems:
- Orchestration: Implemented `WorkloadGraphEngine` and `ComposeEngine`
using Kahn's algorithm for deterministic dependency resolution and
topological startup/shutdown/rollback.
- Backend Logic: Multi-layered auto-detection for 7+ runtimes (Apple, Podman,
Docker, Lima, etc.) with liveness probes and strict priority ordering.
- Security & Policy:
* Implemented `PolicySpec` enforcement (Isolated, Hardened, Untrusted).
* Added image verification via Sigstore/cosign (opt-in via environment).
* Hardened ephemeral runners with `cap_drop: ALL`, seccomp, and read-only
root support.
- FFI Bridge: Expanded `perry-stdlib` with async-safe, promise-based
handlers optimized for raw C-ABI passing of primitives.
Technical Details:
- Restructured `perry-container-compose` into a flat module layout.
- Standardized container naming to `{image_hash_8}-{random_hex8}` with
label-based orphan cleanup.
- Refactored `CliBackend` to be generic over `CliProtocol` for zero vtable
overhead.
- Modernized internal registries with `DashMap` for concurrent access.
- Integrated with Perry compiler (HIR registration and codegen dispatch).
Refinements & Fixes:
- Fixed SQLite linker conflicts by gating runtime stubs.
- Restored `Buffer` synonym and `process.argv` specialization in `lower.rs`.
- Implemented robust IP and label extraction for the `DockerProtocol`.
- Expanded `MockBackend` for high-fidelity orchestration testing.
Validation:
- Added 12 new tests covering orchestration states and policy enforcement.
- Verified 79/0 pass in `perry-container-compose`.
- Verified 33/0 pass in `perry-stdlib` container features and smoke tests.
…rfaced by running it (v0.5.371)
Replaces example-code/forgejo-deployment with a production-quality
deployment using the real Forgejo image — `data.forgejo.org/forgejo/
forgejo:11`, the official Forgejo OCI registry that's separate from
codeberg.org's gated mirror, no Gitea fallback. Driven by running the
example end-to-end against live Docker, surfaced and fixed nine
interlocking codegen + FFI + orchestration bugs that together blocked
any non-trivial compose stack from running.
CODEGEN / FFI fixes (composeUp / down / handle round-trip):
1. composeUp({...}) failed at JSON parse — codegen StrPtr arm passed
raw object pointer through `js_get_string_pointer_unified`, FFI
read it as StringHeader. New runtime helper
`js_value_to_str_ptr_for_ffi` returns the heap string pointer for
actual strings/SSO and otherwise routes through `js_json_stringify`
for object/array/number/bool args.
2. getBackend() returned "unknown" before any async FFI — BACKEND
OnceLock was empty. js_container_getBackend now does a synchronous
in-place probe (block_in_place inside a tokio worker, fresh
current_thread runtime otherwise).
3. composeUp Promise resolved with f64=5e-324 (subnormal). Bare u64
handles in the result_bits slot decoded as f64 bits; `${stack}`
interpolation printed "0". `handle_to_promise_bits(id)` NaN-boxes
with POINTER_TAG | (id & POINTER_MASK); Ok(0u64) void resolutions
become PROMISE_VOID_BITS = TAG_UNDEFINED. Swept across 23 sites.
4. down(stack, opts) failed with "Invalid compose handle". Codegen
dispatch `args: &[NA_F64, NA_F64]` lowered both args to LLVM
double, but Rust signatures took (handle_id: i64, volumes: i32) —
calling-convention mismatch. Changed every compose handle-arg FFI
signature to (handle: f64, ...) and added handle_id_from_f64
helper.
5. exec(stack, 'svc', cmd) failed with "No such container".
service::service_container_name regenerated random suffix per call.
Added `service_container_names: Mutex<HashMap>` cache to
ComposeEngine populated by up()'s start loop.
6. ${VAR:-default} env interpolation didn't apply to TS-side specs —
postgres bombed with "FATAL: invalid character in extension owner"
because literal placeholder strings flowed through. Wired
`perry_container_compose::yaml::interpolate` into parse_compose_spec
so ${VAR} expansion happens before serde_json::from_str (matches
SPEC §7.8 / §7.9 — same engine, FFI boundary).
7. down(stack, { volumes: false }) silently REMOVED volumes.
js_compose_down took (handle: f64, volumes: f64) but TS users pass
an options object. The object NaN-boxed to a non-zero pointer →
`volumes != 0.0` → remove_volumes flipped to true. Changed dispatch
to `[NA_F64, NA_STR]`; FFI parses the JSON-encoded DownOptions
server-side via serde_json (same shape as composeUp).
8. ComposeEngine::down() called rollback() unconditionally, which
drains session_volumes regardless of the volumes-preserve flag.
Snapshot+restore around rollback when remove_volumes=false.
9. types/perry/compose/index.d.ts was missing `healthcheck`, `user`,
`working_dir`, `read_only`, `privileged`, `cap_add`, `cap_drop`
on Service plus `internal`, `driver_opts`, `labels` on
ComposeNetwork — runtime supported them, TS surface didn't.
Added a `Healthcheck` interface (compose-spec §service.healthcheck:
test, interval, timeout, retries, start_period, disable) and
extended both interfaces.
EXAMPLE structure (example-code/forgejo-deployment/main.ts):
- Two-service stack: postgres:16-alpine + data.forgejo.org/forgejo/
forgejo:11.
- depends_on: { db: { condition: 'service_healthy' } }.
- Per-service compose-spec healthchecks: pg_isready for postgres,
wget /api/healthz for forgejo.
- Explicit container_name on each service so Docker's embedded DNS
routes forgejo→forgejo-db (Perry's compose engine doesn't yet
register the service-key as a network alias; documented).
- Internal-only forgejo-db-net (postgres unreachable from host or
sibling stacks); public forgejo-web-net for forgejo's web + SSH
ports.
- Standard Forgejo "OpenSSH on port 22 + START_SSH_SERVER=false"
configuration — the inline-Go SSH server conflicts with the
entrypoint's sshd otherwise (exit-0 with "bind: address already
in use").
- Lifecycle:
./forgejo_app deploy + verify-healthz + exit 0
./forgejo_app --down tear down (preserves volumes)
FORGEJO_DESTROY_ON_EXIT=1 ./forgejo_app --down also drops
volumes
Perry's `process.on('SIGINT', ...)` handler isn't actually invoked
at runtime (confirmed by probe — kill -INT after register; setInterval
keeps ticking), so the example uses `docker compose up -d` style:
exit 0 after success, separate --down command for teardown.
- Production note in doc-comment: FORGEJO_SECRET_KEY,
FORGEJO_INTERNAL_TOKEN, FORGEJO_DB_PASSWORD MUST be stable across
redeploys against the same volumes (random defaults break
Forgejo's encrypted-config decryption + postgres rows).
- Local `tsconfig.json` with paths: { "perry/*": ["../../types/
perry/*"] } for IDE typechecking + `perry-globals.d.ts` declaring
the subset of `process` Perry actually exposes (env, exit, on,
argv, cwd, platform — minimal, not @types/node).
- Workspace re-registration: re-added perry-container-compose to
[workspace] members + default-members + [workspace.dependencies].
VERIFIED full lifecycle:
fresh up → containers healthy, /api/healthz returns "pass"
--down preserve → containers gone, volumes intact
redeploy → containers come back, Forgejo decrypts existing
config (stable secrets), healthz passes again
--down destroy → containers + volumes + networks all gone
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…container/ section
Seven new pages cover overview, single-container lifecycle (perry/container), compose orchestration (perry/compose), networking (incl. the container_name DNS workaround), volumes, security, and a Forgejo-deployment case study. New docs/examples/stdlib/container/snippets.ts with 11 ANCHOR blocks pulled into the markdown via {{#include}}. doc-tests --lint and --filter container both pass.
- Refine platform candidate priority and liveness checks (Spec §5.2) - Align container naming with service YAML configuration MD5 (Spec §8.1) - Standardize FFI signatures with f64 parameters and JSON options (Spec §9.1) - Synchronize codegen dispatch tables with updated FFI signatures - Enforce image verification in compose orchestration flow (Spec §11.2) - Register perry-container-compose as a workspace member in Cargo.toml Co-authored-by: yumin-chen <10954839+yumin-chen@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
a7e9d31 to
dd181eb
Compare
This PR implements the core production readiness requirements for the Perry container subsystem.
Key changes include:
docker info.perry-stdlibto usef64for all numeric/boolean values to align with Perry's NaN-boxing. Refactorslogsandexecto take options objects (JSON), matching the TypeScript API surface.perry-container-composecrate to the root workspace for correct build resolution.All 41 tests in
perry-container-composepass, andperry-stdlibcompiles correctly with thecontainerfeature enabled.PR created automatically by Jules for task 10053886145636669141 started by @yumin-chen