Firebase-tools: 如果功能区域不是默认值,则托管不执行功能

创建于 2018-07-28  ·  41评论  ·  资料来源: firebase/firebase-tools

版本信息

4.00

平台信息

操作系统

重现步骤

函数部署到europe-west1

// function code
const functions = require('firebase-functions');

exports.helloIvanA = functions
  .region('europe-west1')
  .https.onRequest((request, response) => {
    response.send('Hello from Ivan!');
  });

// firebase.json
{
  "hosting": {
    "public": "public",

    "rewrites": [
      {
        "source": "**",
        "function": "helloIvanA"
      }
    ]
  }
}

预期行为

https://blablabla.firebaseapp.com将从helloIvanA获取数据

实际行为

https://blablabla.firebaseapp.com重定向到https://us-central1-yushkarala.cloudfunctions.net/helloIvanA/
并给出
Error: Forbidden Your client does not have permission to get URL /helloIvanA/ from this server.

最有用的评论

很想看到这个实现。 我的访客来自欧洲, us-central1的 TTFB 至少比europe-west1大 3 倍。

所有41条评论

您好,这是预期行为,请参阅https://firebase.google.com/docs/functions/locations#http_and_client_callable_functions ,蓝色框表示所有用作托管重定向的函数都必须在“us-central1”中,这是由于这是托管来源所在的事实。

谢谢,这种预期的行为是否有可能在不久的将来或至少在将来发生改变?

嗨,它会在未来改变,但不会在不久的将来。 这取决于 Firebase 托管何时在其他地区启动。

你好,
我的问题与此非常相似,但我的功能应该在欧盟,因为它使用外部网络,并且以这种方式延迟要好得多(2-4 秒对 4-600 毫秒)执行时间
描述了我的问题:
https://github.com/firebase/firebase-js-sdk/issues/1101
所以目前还没有解决方案来使用重写到其他区域?
(我有一个解决方法,使用直接链接来达到欧盟功能,但从开发方面来说并不理想,我需要重新部署所有东西来测试它)

很想看到这个实现。 我的访客来自欧洲, us-central1的 TTFB 至少比europe-west1大 3 倍。

嗨,它会在未来改变,但不会在不久的将来。 这取决于 Firebase 托管何时在其他地区启动。

@laurenzlong

这是否意味着当主机通过us-central1的其他位置可用时,我们也将能够绕过以下限制?
Important: If you are using HTTP functions to serve dynamic content for hosting, you must use us-central1. 来自文档

我的应用程序需要该功能。 所以,越早越好:)!

非常感谢这一切。

在解决此问题之前,应写入粗体警告。 我花了太多时间才意识到会发生什么。
至少在重写中添加一个region选项,以便我们可以重定向到欧洲。

希望 Firebase 的云功能支持region选项,就像cloud run设置所做的那样。 我正在使用tokyo区域。 它离us-central1真的很远。

这是否意味着当主机通过us-central1的其他位置可用时,我们也将能够绕过以下限制?
Important: If you are using HTTP functions to serve dynamic content for hosting, you must use us-central1.来自文档

@laurenzlong

你有(好)吗? 关于这个的消息?

我同意正如@wangchou所说,云运行将是一种替代方案,但它增加了服务/技术堆栈。

希望尽快读到你。 谢谢!

我们仍在研究这一点,但现在我们的原始基础设施集中在us-central ,这意味着在大多数情况下,允许在其他区域进行功能代理最终会产生额外的延迟。 例如:

tokyo -> CDN edge -> origin (us-central) -> function (tokyo)

这意味着往返时间实际上会加倍。

我们正在研究扩展我们的原始基础设施的位置,但在此之前我们对添加此功能持谨慎态度,因为它更有可能造成弊大于利。

@mbleigh - 当主机起源将位于美国境外时,请您给我们任何估计?

整个 Firebase 环境令人惊叹,但这让我们在切换到它之前三思而后行。 谢谢

真不知道为什么这个issue还没解决就关闭了,顶一下+1。

其次,Firebase 很棒,但对于欧洲用户来说,这是一个主要的警告。

抱歉,我们无法对时间表发表评论,因为它们太容易发生变化。 我很欣赏持续支持这一功能的声音,这绝对是我们在计划和构建产品时考虑的因素。

我有一个可能与此有关的问题,但我不完全理解,所以我不知道。 如果有更了解并有时间的人想对此发表评论,请参阅此问题:

https://stackoverflow.com/questions/57367131/403-from-deployed-firebase-function

拥有这个将是一件很棒的事情,我们终于可以为我们已经存在于 europe-west1 的函数添加一个托管重写。

确实会很棒。 目前,还使用@hgghyxo提到的重定向:

函数名称api
地区europe-west1

firebase.json

"redirects": {
    {
          "source": "/api/endpoint",
          "destination": "https://europe-west1-project-id.cloudfunctions.net/api/endpoint",
          "type": 301
    },
    ...
}

@mcoevert2019 年 8 月 19 日上午 10:36 GMT+2发表评论:

确实会很棒。 目前,还使用@hgghyxo提到的重定向:

重定向不会解决 CORS 问题。

也希望看到欧洲地区的支持。

似乎现在可以使用托管在europe-west1区域(目前唯一可用于 Cloud Run 的欧洲区域)上的 Cloud Run 服务进行重写。 它不完全相同,但非常接近。

您好,这是预期行为,请参阅https://firebase.google.com/docs/functions/locations#http_and_client_callable_functions ,蓝色框表示所有用作托管重定向的函数都必须在“us-central1”中,这是由于这是托管来源所在的事实。

抱歉,很容易错过一个蓝色的小盒子。 我们在这个问题上浪费了太多时间,认为这是我们最终的配置问题。

为什么关闭 - 这对我们欧洲来说是个问题。 有什么解释为什么它只适用于我们地区吗?

此问题已关闭,因为它是 Firebase 托管的功能请求,无法直接在 Firebase CLI 中解决。 功能请求在内部进行跟踪,我鼓励您通过此表单请求对其他区域的支持。

我们肯定知道你们中的许多人都想要这个功能,感谢您的反馈!

此问题已关闭,因为它是 Firebase 托管的功能请求,无法直接在 Firebase CLI 中解决。 功能请求在内部进行跟踪,我鼓励您通过此表单请求对其他区域的支持。

我们肯定知道你们中的许多人都想要这个功能,感谢您的反馈!

功能请求仅在内部跟踪? 这不会带来很多重复的请求吗? 我想表明对这些功能的支持,以包括非美国地区。

是的——如果您发送功能请求,我们将针对其他请求进行重复数据删除以进行内部跟踪(这肯定有助于显示对请求的更多支持!)。

如果您不需要 VPC,则可以使用 Cloud Run 而不是 Cloud Function。 Cloud Run(全托管)目前无法连接到 VPC 网络。 我测试过的使用 VPC + 自定义域 + Cloud Function 的解决方法是使用 Cloud Run 和作为 Cloud Function 代理的自定义域。 它增加了一些开销,但如果您的 Cloud Run 和 Cloud Function 在同一个区域,那么理论上它应该不会有太多延迟。 话虽如此,我已经监控了一个多月,但 Cloud Run 测试版并不是 100% 稳定:

image

如果您想将它部署到 Cloud Run 并试一试https://github.com/reactgraphqlacademy/cloud-run-proxy ,这是我使用的代理的 repo

我已经在 Cloud Function 所在的同一区域测试了具有代理的 Cloudflare 工作人员,并在同一时期对其进行了监控。 它比 Cloud Run 慢,尽管它是 100% 可靠的。

image

如果您想测试 Cloudflare worker https://gist.github.com/alexlbr/814446f03cf12e22f07ccaa580eb1154 ,可以使用此代码。 @wangchou如果我没记错的话,您可以在 Tokio 中运行 Cloudflare 工作程序,因此它可以更接近用户所在的边缘,因为该地区尚不支持 Cloud Run。

以下是同期直接监控云功能,无需任何代理。

image

我使用https://uptimerobot.com进行监控。

Cloud Run 对我来说很有希望,我等不及要完整发布了

对此有何更新? 为什么关门了?

不可能的?

@abdellahaski @l2aelba我们肯定听到了这里的痛点。 正如@mbleigh之前所说,将其作为功能请求提交(见下文)是帮助我们在内部获得牵引力的最佳方式。 谢谢!

此问题已关闭,因为它是 Firebase 托管的功能请求,无法直接在 Firebase CLI 中解决。 功能请求在内部进行跟踪,我鼓励您通过此表单请求对其他区域的支持。

我们肯定知道你们中的许多人都想要这个功能,感谢您的反馈!

也希望看到 asia-east2 支持。

由于文档不好,我几乎要放弃 firebase。

如果 us-central 中没有与重定向中的函数匹配的函数,则绝对最低限度会发出警告!

我建议 firebase 团队尝试让某人开发一个用户在美国以外的项目。 我们没有收到这类东西的警告真是太疯狂了。

让我们按照他们的要求互相帮助 - 发布功能请求:
https://firebase.google.com/support/troubleshooter/report/features

这是一份供您复制/粘贴的草稿 - 完成即可:)

在非美国地区托管重写功能
https://github.com/firebase/firebase-tools/issues/842

确实需要能够对 US-Central1 以外的地区的功能进行重写。

我们的目标受众不在美国,缺乏此功能对我们来说是一个很大的痛点,这使我们不确定是否将我们的技术堆栈整体专用于 Firebase。

请考虑在不久的将来优先考虑此功能。
谢谢,

image

在这里希望尽快使用此功能!

有没有人研究过使用云运行而不是云功能?

Cloud run 也提供其他地区的功能

两年后,这仍然是一个问题。为什么顺便关闭?

您好,这是预期行为,请参阅https://firebase.google.com/docs/functions/locations#http_and_client_callable_functions ,蓝色框表示所有用作托管重定向的函数都必须在“us-central1”中,这是由于这是托管来源所在的事实。

寻呼@laurenzlong

Cloud Functions 在以下区域可用:

  • us-central1(爱荷华州)
  • us-east1(南卡罗来纳州)
  • us-east4(弗吉尼亚北部)
  • europe-west1(比利时)
  • 欧洲西部2(伦敦)
  • europe-west3(法兰克福)
  • asia-east2(香港)
  • asia-northeast1(东京)

我选择了 eur3(欧洲西部),因为它与 us-central1 一起在列表的顶部,并且与其他位置分开。 以为这两个是默认的。

我该怎么办,有什么解决办法吗?

为什么?????

大家好,感谢您对此的所有反馈。 我们绝对听说您希望看到us-central1之外的 Firebase 托管支持功能。 不幸的是,在它能够正常运行之前,必须进行大量的基础设施工作,所以我们不能只是“翻转开关”并让其他地区上线。

我们经常听说这是一项功能请求,它在我们的路线图上,尽管我无法对具体的时间表发表评论。 此存储库不是发布整个 Firebase 托管产品功能请求的正确位置 - 如果您对此功能感兴趣,请提交功能请求,以便我们可以继续在内部跟踪对此的兴趣并确定工作的优先级这需要发生才能启用它。

谢谢大家!

你好,

我认为没有人关心你在哪里托管,我们只需要一个简单的修复,这样错误就不会出现。

此修复可以在您的代码中完成,与您托管的地方无关。

这不是对功能的要求,消除错误不会成为功能。 只需删除该错误

谢谢..

此页面是否有帮助?
0 / 5 - 0 等级