| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Add new ContainerBackend based on new container runtime (#162) * computer: add a container backend for durable-object scheduling A container the durable object schedules has no image or size of its own: the wrangler containers block rejects instance_type under that policy, and the platform prepares images for the object to name rather than booting one itself. Every start() therefore has to carry an image, and carry a size if the workload needs one. This backend does that. The launch spec widens to the platform's own startup options, so entrypoint, labels and the snapshot fields reach start() too, and the caller names an image through `name`, which the host resolves against ctx.container.images. Consumers were previously reduced to patching ctx.container.start to inject any of it. Both launch paths build their spec through one helper. They reach the platform through different host methods, and a spec assembled separately in each place drifts silently: the restart drops what the initial start was given, and the replacement container comes up on a different image or at a different size than the one it replaced. The adoption digest grows the fields that cannot change on a running container, so a container launched at one size is no longer adopted by a caller asking for another. Snapshot fields stay out of it: they describe how a container was created rather than a property of the running one, and digesting them would relaunch a healthy container every time the stored handle moved on. An unresolvable image fails loudly rather than falling back. An empty images map means the container is platform-scheduled, which is a valid deployment this backend does not serve, so the error names the one that does. * computer, docs, examples/container: Document both backends Add a runnable example for the durable-object-scheduled backend and use it in the primary setup documentation. The example shows how image and instance selection move from the Wrangler configuration into each container launch. Keep the platform-scheduled example under `container-legacy` for callers that still use that policy and for documentation tied to its exact setup. * ci: Test the new container example alongside the legacy one This branch adds examples/container back next to examples/container-legacy, so the example matrix tests both. --------- Co-authored-by: Matt Carey <mcarey@cloudflare.com> | 11 天前 |