Skip to content

Perry Container Subsystem Production Readiness#76

Open
yumin-chen wants to merge 4 commits into
feat/container-composefrom
feat/perry-container-production-readiness-10053886145636669141
Open

Perry Container Subsystem Production Readiness#76
yumin-chen wants to merge 4 commits into
feat/container-composefrom
feat/perry-container-production-readiness-10053886145636669141

Conversation

@yumin-chen

Copy link
Copy Markdown

This PR implements the core production readiness requirements for the Perry container subsystem.

Key changes include:

  1. Backend Detection: Strictly follows the specification priority order for macOS, Linux, and Windows. Adds detailed liveness checks for all supported runtimes, including identity verification for OrbStack and Rancher Desktop via docker info.
  2. Naming Strategy: Switches the stable container name prefix to be based on the MD5 hash of the service configuration YAML rather than just the image name. This ensures unique names for services using the same image with different environment or network settings.
  3. FFI Standardization: Updates the FFI bridge in perry-stdlib to use f64 for all numeric/boolean values to align with Perry's NaN-boxing. Refactors logs and exec to take options objects (JSON), matching the TypeScript API surface.
  4. Codegen Synchronization: Ensures the Perry compiler's native module table is in sync with the refined FFI signatures.
  5. Security: Integrates Sigstore/cosign verification into the multi-container orchestration flow.
  6. Workspace: Adds the perry-container-compose crate to the root workspace for correct build resolution.

All 41 tests in perry-container-compose pass, and perry-stdlib compiles correctly with the container feature enabled.


PR created automatically by Jules for task 10053886145636669141 started by @yumin-chen

yumin-chen and others added 4 commits April 29, 2026 01:00
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>
@google-labs-jules

Copy link
Copy Markdown

👋 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 @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@yumin-chen yumin-chen force-pushed the feat/container-compose branch 13 times, most recently from a7e9d31 to dd181eb Compare May 3, 2026 01:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant