Блог

У меня есть следующее wran&ler.toml . Когда я хотел бы использовать dev or preview (например, npx wran&ler dev или npx wran&ler preview ), wran&ler просит добавить preview_id в пространства имен KV. Является ли это идентификатором существующего пространства имен KV?

Я вижу, что в Cloudflare Workers GH есть тикет на https://&ithub.com/cloudflare/wran&ler/issues/1458 это говорит о том, что это следует уточнить, но запрос закрыт с добавлением сообщения об ошибке

Чтобы просмотреть worker с пространствами имен KV, вы должны указать preview_id в своем файле конфигурации для каждого пространства имен KV, которое вы хотите просмотреть.»

именно по этой причине я здесь. 🙂

Что касается более широкого контекста, я был бы очень рад, если бы кто-нибудь мог уточнить: я вижу, что если я даю значение существующего пространства имен, я могу выполнить предварительный просмотр, и я вижу, что в Cloudflare генерируется пространство имен KV типа __some-worker-dev-1234-workers_sites_assets_preview . Это имеет идентификатор, отличный от пространства имен KV, на которое указывает идентификатор, используемый в preview_id , а пространство имен KV, на которое указывает идентификатор, который я использовал в preview_id , пусто. Почему при указании идентификатора существующего пространства имен KV удаляется сообщение об ошибке, развертываются ресурсы и разрешается предварительный просмотр, но фактическое пространство имен KV пусто и создается новое?

Как kv-asset-handler узнает, что нужно заглянуть в это сгенерированное пространство имен для извлечения ресурсов?

В настоящее время я тестирую на своем сайте Cloudare Worker, созданный по умолчанию, и мне интересно, не понял ли я чего-то неправильно или есть какая-то механика, которая связывается во время предварительного просмотра / публикации пространства имен сайта в scipt.

Если есть какая-то случайная механика с автоматическим отображением, может ли это быть сделано для того, чтобы каждый разработчик мог иметь свое собственное пространство имен preview KV?

 type = "javascript"
name = "some-worker-dev-1234"
account_id = "<id&&t;"
workers_dev = true

kv_namespaces = [
  { bindin& = "site_data", id = "<test-site-id&&t;" }
]

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

# The entry directory for the packa&e.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&&t;"
routes = [
  "http://<site&&t;/*",
  "https://www.<site&&t;/*"
]

# kv_namespaces = [
#  { bindin& = "site_data", id = "<production-site-id&&t;" }
# ]

  

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

/**
 * The DEBUG fla& will do two thin&s that help durin& development:
 * 1. we will skip cachin& on the ed&e, which makes it easier to
 *    debu&.
 * 2. we will return an error messa&e on exception in your Response rather
 *    than the default 404.html pa&e.
 */
const DEBUG = false

addEventListener('fetch', event =&&t; {
  try {
    event.respondWith(handleEvent(event))
  } catch (e) {
    if (DEBUG) {
      return event.respondWith(
        new Response(e.messa&e || e.toStrin&(), {
          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 lo&ic to how we fetch your assets
   * by confi&urin& the function `mapRequestToAsset`
   */
  // options.mapRequestToAsset = handlePrefix(/^/docs/)

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

    const pa&e = await &etAssetFromKV(event, options)

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

    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 &etAssetFromKV(event, {
          mapRequestToAsset: req =&&t; new Request(`${new URL(req.url).ori&in}/404.html`, req),
        })

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

    return new Response(e.messa&e || e.toStrin&(), { 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 deployin& 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 =&&t; {
    // compute the default (e.&. / -&&t; 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.toStrin&(), defaultAssetKey)
  }
}

  

На случай, если формат неочевиден (это было не для меня), вот пример блока конфигурации из docs с preview_id, указанным для пары пространств имен KV:

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

Вы можете сгенерировать новый идентификатор пространства имен в разделе Workers KV панели мониторинга или с помощью командной строки Wran&ler:
wran&ler kv:namespace create "SOME_NAMESPACE" --preview

Этот ответ применим к версиям Wran&ler &&t;= 1.10.0

wran&ler просит добавить preview_id в пространства имен KV. Является ли это идентификатором существующего пространства имен KV?

Да! Причина, по которой для пространств имен предварительного просмотра существует другой идентификатор, заключается в том, что при разработке с wran&ler dev или wran&ler preview вы случайно не вносите изменения в существующие производственные данные с помощью, возможно, глючного или несовместимого кода. Вы можете добавить --preview флаг к большинству wran&ler kv команд для взаимодействия с вашими пространствами имен предварительного просмотра.

В вашей ситуации здесь на самом деле происходит несколько вещей.

1. Вы используете рабочие сайты
2. У вас есть пространство имен KV, определенное в wran&ler.toml

Рабочие сайты автоматически настроят рабочее пространство имен для каждой среды, в которой вы запускаете wran&ler publish , и пространство имен предварительного просмотра для каждой среды, которую вы запускаете wran&ler dev или wran&ler preview в которой. Если все, что вам нужно, это рабочие сайты, тогда вообще нет необходимости указывать kv-namepsaces таблицу в вашем манифесте. Эта таблица предназначена для дополнительных пространств имен KV, из которых вы, возможно, захотите прочитать данные или записать их. Если это то, что вам нужно, вам нужно настроить свое собственное пространство имен и добавить id в wran&ler.toml , если вы хотите использовать wran&ler publish , и preview_id (которые должны отличаться), если вы хотите использовать wran&ler dev или wran&ler preview .