什么是 cloudflare KV preview_ids 以及如何获得?

What are cloudflare KV preview_ids and how to get one?

我有一个追随者wrangler.toml。当我想使用 devpreview(例如 npx wrangler devnpx wrangler preview)时,wrangler 要求将 preview_id 添加到 KV 命名空间。这是现有 KV 名称空间的标识符吗?

我在 https://github.com/cloudflare/wrangler/issues/1458 的 Cloudflare Workers GH 中看到一张票,告诉我应该对此进行澄清,但票已关闭并添加了一条错误消息

In order to preview a worker with KV namespaces, you must designate a preview_id in your configuration file for each KV namespace you'd like to preview."

这就是我来这里的原因。 :)

至于更大的上下文,如果有人能澄清,我会很高兴:我看到如果我给现有命名空间的值,我可以预览并且我看到生成了类型 __some-worker-dev-1234-workers_sites_assets_preview 的 KV 命名空间在 Cloudflare 中。这与 preview_id 中使用的标识符所指向的 KV 名称空间具有不同的标识符,而我在 preview_id 中使用的标识符所指向的 KV 名称空间是空的。为什么提供现有 KV 命名空间的标识符会删除错误消息、部署资产并允许预览,但实际的 KV 命名空间为空并创建一个新命名空间?

kv-asset-handler 如何知道查看这个生成的命名空间以检索资产?

我目前正在使用默认生成的 Cloudare Worker 对我的站点进行测试,我想知道我是否误解了什么,或者是否有一些机制在 preview/publish 将站点名称空间捆绑到 scipt 期间。

如果有一些自动映射的随机机制,是否可以让每个开发者都可以拥有自己的私有预览 KV 命名空间?

type = "javascript"
name = "some-worker-dev-1234"
account_id = "<id>"
workers_dev = true

kv_namespaces = [
  { binding = "site_data", id = "<test-site-id>" }
]

[site]
# The location for the site.
bucket = "./dist"

# The entry directory for the package.json that contains 
# main field for the file name of the compiled worker file in "main" field.
entry-point = ""

[env.production]
name = "some-worker-1234"
zone_id = "<zone-id>"
routes = [
  "http://<site>/*",
  "https://www.<site>/*"
]

# kv_namespaces = [
#  { binding = "site_data", id = "<production-site-id>" }
# ]

import { getAssetFromKV, mapRequestToAsset } from '@cloudflare/kv-asset-handler'

/**
 * The DEBUG flag will do two things that help during development:
 * 1. we will skip caching on the edge, which makes it easier to
 *    debug.
 * 2. we will return an error message on exception in your Response rather
 *    than the default 404.html page.
 */
const DEBUG = false

addEventListener('fetch', event => {
  try {
    event.respondWith(handleEvent(event))
  } catch (e) {
    if (DEBUG) {
      return event.respondWith(
        new Response(e.message || e.toString(), {
          status: 500,
        }),
      )
    }
    event.respondWith(new Response('Internal Error', { status: 500 }))
  }
})

async function handleEvent(event) {
  const url = new URL(event.request.url)
  let options = {}

  /**
   * You can add custom logic to how we fetch your assets
   * by configuring the function `mapRequestToAsset`
   */
  // options.mapRequestToAsset = handlePrefix(/^\/docs/)

  try {
    if (DEBUG) {
      // customize caching
      options.cacheControl = {
        bypassCache: true,
      }
    }

    const page = await getAssetFromKV(event, options)

    // allow headers to be altered
    const response = new Response(page.body, page)

    response.headers.set('X-XSS-Protection', '1; mode=block')
    response.headers.set('X-Content-Type-Options', 'nosniff')
    response.headers.set('X-Frame-Options', 'DENY')
    response.headers.set('Referrer-Policy', 'unsafe-url')
    response.headers.set('Feature-Policy', 'none')

    return response

  } catch (e) {
    // if an error is thrown try to serve the asset at 404.html
    if (!DEBUG) {
      try {
        let notFoundResponse = await getAssetFromKV(event, {
          mapRequestToAsset: req => new Request(`${new URL(req.url).origin}/404.html`, req),
        })

        return new Response(notFoundResponse.body, { ...notFoundResponse, status: 404 })
      } catch (e) {}
    }

    return new Response(e.message || e.toString(), { status: 500 })
  }
}

/**
 * Here's one example of how to modify a request to
 * remove a specific prefix, in this case `/docs` from
 * the url. This can be useful if you are deploying to a
 * route on a zone, or if you only want your static content
 * to exist at a specific path.
 */
function handlePrefix(prefix) {
  return request => {
    // compute the default (e.g. / -> index.html)
    let defaultAssetKey = mapRequestToAsset(request)
    let url = new URL(defaultAssetKey.url)

    // strip the prefix from the path for lookup
    url.pathname = url.pathname.replace(prefix, '/')

    // inherit all other props from the default request
    return new Request(url.toString(), defaultAssetKey)
  }
}

此答案适用于 Wrangler >= 1.10.0

的版本

wrangler asks to add a preview_id to the KV namespaces. Is this an identifier to an existing KV namespace?

是的!预览命名空间有不同标识符的原因是,在使用 wrangler devwrangler preview 进行开发时,您不会意外地使用可能有错误或不兼容的代码对现有生产数据进行更改。您可以向大多数 wrangler kv 命令添加 --preview 标志以与您的预览命名空间交互。


对于你这里的情况,实际上有一些事情正在发生。

  1. 您正在使用 Workers Sites
  2. 您在 wrangler.toml
  3. 中定义了一个 KV 命名空间

Workers Sites 将自动为您 运行 wrangler publish 所在的每个环境配置一个生产命名空间,并为您 运行 wrangler dev 或 [=] 的每个环境自动配置一个预览命名空间11=] 上。如果您只需要 Workers Sites,那么根本不需要在清单中指定 kv-namepsaces table。 table 用于 其他 KV 名称空间,您可能希望从中读取数据或向其中写入数据。如果那是你需要的,你需要配置你自己的命名空间,如果你想使用 wrangler publishpreview_id(应该是不同)如果你想使用 wrangler devwrangler preview.

如果格式不明显(对我来说不是),这里是 docs 的示例配置块,其中 preview_id 指定用于几个 KV 命名空间:

kv_namespaces = [  
  { binding = "FOO", id = "0f2ac74b498b48028cb68387c421e279", preview_id = "6a1ddb03f3ec250963f0a1e46820076f" },
  { binding = "BAR", id = "068c101e168d03c65bddf4ba75150fb0", preview_id = "fb69528dbc7336525313f2e8c3b17db0" }
]

您可以在仪表板的 Workers KV 部分或使用 Wrangler CLI 生成新的命名空间 ID: wrangler kv:namespace create "SOME_NAMESPACE" --preview