Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial implementation of DO-attached containers API #3354

Merged
merged 5 commits into from
Jan 25, 2025
Merged

Conversation

kentonv
Copy link
Member

@kentonv kentonv commented Jan 17, 2025

Implemented here:

  • Basic lifecycle (start/monitor/destroy/signal)
  • Connecting to a TCP port in the container, either as a raw socket or HTTP.

Not implemented yet:

  • Intercepting outgoing connections from container (listenTcp()).
  • Starting the DO with an already-running container.
  • Hibernating while container is running.
  • vsocks
  • stdio interception
  • Any sort of local testing with workerd (only the production runtime is fully wired up for now).

@kentonv kentonv requested review from gabivlj and shrima-cf January 17, 2025 22:57
@kentonv kentonv requested review from a team as code owners January 17, 2025 22:57
Copy link

github-actions bot commented Jan 17, 2025

The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉

@kentonv kentonv requested a review from a team as a code owner January 22, 2025 17:09
@kentonv
Copy link
Member Author

kentonv commented Jan 22, 2025

Fixups:

New commits:

No methods are implemented yet, but if a container capability is passed in when creating an actor, then `ctx.container` will be populated.
@jasnell
Copy link
Member

jasnell commented Jan 24, 2025

Couple of nits remaining but otherwise LGTM

Tests are currently in the internal codebase, since that's where the mock container service lives, but probably some of that should be ported out here later, especially once we figure out how local testing of containers will work.
This is really two changes:

1. Make these lazy properties. This is a strict win since the properties cannot change value during the lifetime of the object, so there's no reason to call into C++ on every access. This might even be a non-negligible performance gain for people who use `ctx.storage` a lot without memoizing it.

2. Make them writable. There's no real reason to prevent people from overwriting these if they really want to. Moreover, introducing `container` as a read-only property could arguably break someone who is, for whatever reason, monkey-patching this property in today.
@kentonv kentonv merged commit fa6bf31 into main Jan 25, 2025
16 checks passed
@kentonv kentonv deleted the kenton/containers branch January 25, 2025 14:34
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.

3 participants