Configure workerd for FUSE when safe to do so - #15134
Conversation
🦋 Changeset detectedLatest commit: ca438f7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
|
UnknownError: ProviderInitError |
|
✅ All changesets look good |
|
@gpanders Bonk workflow failed. Check the logs for details. View workflow run · To retry, trigger Bonk again. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Check the configuration of the Docker daemon to determine if it is safe to configure workerd for use with FUSE. If the host platform is non-Linux (which means the Docker daemon is running in a VM) OR if Docker is running in rootless mode, we configure workerd with the CAP_SYS_ADMIN capability and mount the `/dev/fuse` device into the container. This means that rootful Docker on Linux DOES NOT support FUSE by default. Linux users should configure rootless Docker before using FUSE.
@cloudflare/autoconfig
@cloudflare/build-output-utils
@cloudflare/config
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-functions
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
emily-shen
left a comment
emily-shen
left a comment
There was a problem hiding this comment.
Sorry - miniflare is going through a messy transition at the moment as we're soft launching a new major.
I've moved the container engine configuration to miniflare's top level, out of the durable object config. The image name is still defined on the DO, this is just the stuff like the socket. That made more sense to me as I don't think you can (or should) have multiple different container engine configs.
For some background:
Miniflare's config is now an extension of our new programmatic version of wrangler.json (in packages/config), with extensions defined all in one place in src/config/schema.ts, rather than in each individual plugin. Each plugin now gets the whole worker's options, rather than just the binding options for that resource type.
However, I think for this feature we don't need to add any user facing config, so all of this logic should just go inside miniflare. Currently the PR doesn't work with vite for example, but if you just move it all inside miniflare then it will work for any local dev.
As a followup, you could then add user-facing config so that this works on rootful linux too, or let people turn this off, but we can do that separately?
3 participants
Check the configuration of the Docker daemon to determine if it is safe to configure workerd for use with FUSE. If the host platform is non-Linux (which means the Docker daemon is running in a VM) OR if Docker is running in rootless mode, we configure workerd with the CAP_SYS_ADMIN capability, mount the
/dev/fusedevice into the container, and disable the AppArmor profile.This means that rootful Docker on Linux DOES NOT support FUSE by default. Linux users should configure rootless Docker before using FUSE.