Firebase-tools: El alojamiento no ejecuta la función si la región de la función no es la predeterminada

Creado en 28 jul. 2018  ·  41Comentarios  ·  Fuente: firebase/firebase-tools

Información de la versión

4.00

Información de la plataforma

sistema operativo X

pasos para reproducir

función implementada en 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"
      }
    ]
  }
}

Comportamiento esperado

https://blablabla.firebaseapp.com obtendrá datos de helloIvanA

Comportamiento real

https://blablabla.firebaseapp.com redirige a https://us-central1-yushkarala.cloudfunctions.net/helloIvanA/
y da
Error: Forbidden Your client does not have permission to get URL /helloIvanA/ from this server.

Comentario más útil

Me encantaría ver esto implementado. Mis visitantes son de Europa, y el TTFB de us-central1 es al menos 3 veces más grande que europe-west1 .

Todos 41 comentarios

También ejemplo de repositorio https://github.com/istarkov/firebase-hosting-error

Hola, este es el comportamiento esperado, consulte https://firebase.google.com/docs/functions/locations#http_and_client_callable_functions , el cuadro azul indica que todas las funciones que funcionan como redirecciones de alojamiento deben estar en 'us-central1', esto es debido al hecho de que ahí es donde está el origen del alojamiento.

Gracias, ¿hay alguna posibilidad de que este comportamiento esperado cambie en un futuro cercano o al menos en un futuro?

Hola, cambiará en un futuro, pero no en un futuro cercano. Depende de los orígenes del lanzamiento de Firebase Hosting en otras geografías.

Hola,
Mi problema es muy similar a este, pero mis funciones deberían estar en la UE, ya que usa una red externa, y la latencia es mucho mejor de esta manera (2-4 segundos frente a 4-600 ms) tiempo de ejecución
Describí mi problema en:
https://github.com/firebase/firebase-js-sdk/issues/1101
Entonces, ¿todavía no hay una solución para usar reescrituras en otra región en este momento?
(Tengo una solución, usando enlaces directos para llegar a la función de la UE, pero eso no es ideal desde el lado del desarrollo, necesito volver a implementar todo para probarlo)

Me encantaría ver esto implementado. Mis visitantes son de Europa, y el TTFB de us-central1 es al menos 3 veces más grande que europe-west1 .

Hola, cambiará en un futuro, pero no en un futuro cercano. Depende de los orígenes del lanzamiento de Firebase Hosting en otras geografías.

Hola @laurenzlong ,

¿Significa eso que cuando el alojamiento esté disponible a través de otras ubicaciones que us-central1 , también podremos evitar la siguiente limitación?
Important: If you are using HTTP functions to serve dynamic content for hosting, you must use us-central1. del documento

Necesito esa característica para mi aplicación. Entonces, cuanto antes, mejor :)!

Muchas gracias por todo esto.

Se debe escribir una advertencia en negrita hasta que esto se solucione. He pasado demasiado tiempo hasta que me di cuenta de lo que sucede.
Al menos agregue una opción region a las reescrituras para que podamos redirigir a Europa.

La función de esperanza en la nube para Firebase admite la opción region como lo hizo la configuración cloud run . Estoy usando la región tokyo . Está muy lejos de us-central1 .

¿Significa eso que cuando el alojamiento esté disponible a través de otras ubicaciones que us-central1 , también podremos evitar la siguiente limitación?
Important: If you are using HTTP functions to serve dynamic content for hosting, you must use us-central1. del documento

Hola @laurenzlong ,

¿tienes alguno (bueno)? noticias sobre esto?

Estoy de acuerdo en que, como dijo @wangchou , la ejecución en la nube sería una alternativa, pero agrega una pila de servicios/tecnología.

Esperando leerte pronto. ¡Gracias!

Todavía estamos investigando esto, pero en este momento nuestra infraestructura de origen se concentra en us-central lo que significa que permitir el proxy de funciones en otras regiones terminaría creando una latencia adicional en la mayoría de los casos. Por ejemplo:

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

Esto significa que el tiempo de ida y vuelta en realidad se duplica.

Estamos investigando la expansión de las ubicaciones de nuestra infraestructura de origen, pero hasta entonces desconfiamos de agregar esta capacidad, ya que es más probable que cause daños que beneficios.

@mbleigh : ¿podría darnos alguna estimación de cuándo el origen del alojamiento se ubicará fuera de EE. UU.?

Todo el entorno de Firebase es asombroso, pero esto nos hace pensar dos veces antes de cambiar a él. Gracias

Realmente no sé por qué se ha cerrado este problema si no se ha resuelto, superando +1.

En segundo lugar, Firebase es increíble, pero para los usuarios europeos es una advertencia importante.

Lo sentimos, no podemos comentar sobre los plazos, ya que están demasiado sujetos a cambios. Agradezco la voz continua por respaldar esto como una característica, eso es definitivamente algo que tenemos en cuenta cuando planificamos y creamos el producto.

Tengo un problema que podría estar relacionado con esto, pero no lo entiendo completamente, así que no lo sé. Si alguien que sabe mejor y tiene tiempo quiere comentar sobre eso, vea esta pregunta:

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

Sería genial tener esto, finalmente podríamos agregar una reescritura de alojamiento a nuestras funciones que ya viven en europe-west1.

Sería genial de hecho. Por ahora, también usando redireccionamientos como mencionó @hgghyxo :

Nombre de la función api
Región europe-west1

base de fuego.json

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

@mcoevert comentó el 19 de agosto de 2019 a las 10:36 a. m. GMT+2 :

Sería genial de hecho. Por ahora, también usando redireccionamientos como mencionó @hgghyxo :

Sin embargo, las redirecciones no resolverán los problemas de CORS.

También me gustaría ver el apoyo de la región de Europa.

Parece que ahora se puede hacer una reescritura con un servicio de Cloud Run alojado en la región europe-west1 (actualmente la única región de Europa disponible para Cloud Run). No es exactamente lo mismo, pero bastante parecido.

Hola, este es el comportamiento esperado, consulte https://firebase.google.com/docs/functions/locations#http_and_client_callable_functions , el cuadro azul indica que todas las funciones que funcionan como redirecciones de alojamiento deben estar en 'us-central1', esto es debido al hecho de que ahí es donde está el origen del alojamiento.

Lo sentimos, pero es fácil pasar por alto una pequeña caja azul. Hemos desperdiciado demasiadas horas en este problema, pensando que era un problema de configuración de nuestra parte.

¿Por qué está cerrado? Es un problema para nosotros en Europa. ¿Hay alguna explicación de por qué solo funciona para la región de nosotros?

Este problema está cerrado porque es una solicitud de función para Firebase Hosting que no se puede abordar directamente en Firebase CLI. Las solicitudes de funciones se rastrean internamente y le recomiendo que solicite asistencia para regiones adicionales a través de este formulario .

Definitivamente somos conscientes de que muchos de ustedes quieren esta función, ¡gracias por sus comentarios!

Este problema está cerrado porque es una solicitud de función para Firebase Hosting que no se puede abordar directamente en Firebase CLI. Las solicitudes de funciones se rastrean internamente y le recomiendo que solicite asistencia para regiones adicionales a través de este formulario .

Definitivamente somos conscientes de que muchos de ustedes quieren esta función, ¡gracias por sus comentarios!

¿Las solicitudes de funciones solo se rastrean internamente? ¿No trae eso muchas solicitudes duplicadas? Me gustaría mostrar soporte para estas características para incluir regiones fuera de EE. UU.

Sí, si envía una solicitud de función, la deduplicaremos con otras para nuestro seguimiento interno (¡y definitivamente ayuda a mostrar más soporte para las solicitudes!).

Podría usar Cloud Run en lugar de Cloud Function si no necesita una VPC. Cloud Run (totalmente administrado) no puede conectarse a la red de VPC actualmente. Una solución alternativa que probé para usar VPC + dominio personalizado + Cloud Function es usar Cloud Run con un dominio personalizado que es un proxy para Cloud Function. Agrega un poco de sobrecarga, pero si su Cloud Run y ​​Cloud Function están en la misma región, en teoría, no debería haber mucha latencia. Dicho esto, lo he monitoreado durante un mes y la versión beta de Cloud Run no es 100 % tan estable:

image

Este es un repositorio con el proxy que he usado si desea implementarlo en Cloud Run y ​​probarlo https://github.com/reactgraphqlacademy/cloud-run-proxy

Probé un trabajador de Cloudflare con un proxy en la misma región que Cloud Function y lo supervisé durante el mismo período. Era más lento que el Cloud Run, aunque era 100% fiable.

image

Puede usar este código si desea probar el trabajador de Cloudflare https://gist.github.com/alexlbr/814446f03cf12e22f07ccaa580eb1154 . @wangchou Si no me equivoco, podría ejecutar el trabajador de Cloudflare en Tokio, por lo que puede estar más cerca del borde donde se encuentra el usuario, ya que Cloud Run aún no es compatible en esa región.

Lo siguiente monitorea la función de la nube directamente sin ningún proxy durante el mismo período.

image

He usado https://uptimerobot.com para el monitoreo.

Cloud Run me parece muy prometedor, no puedo esperar al lanzamiento completo

¿Alguna actualización sobre esto? ¿Por qué está cerrado?

¿Imposible?

@abdellahaski @l2aelba Definitivamente escuchamos el punto de dolor aquí. Como @mbleigh dijo anteriormente, presentarlo como una solicitud de función (ver más abajo) es la mejor manera de ayudar a que esto gane tracción para nosotros internamente. ¡Gracias!

Este problema está cerrado porque es una solicitud de función para Firebase Hosting que no se puede abordar directamente en Firebase CLI. Las solicitudes de funciones se rastrean internamente y le recomiendo que solicite asistencia para regiones adicionales a través de este formulario .

Definitivamente somos conscientes de que muchos de ustedes quieren esta función, ¡gracias por sus comentarios!

También me gustaría ver el soporte de asia-east2.

Estoy cerca de renunciar a firebase debido a la mala documentación.

¡Un mínimo absoluto sería emitir una advertencia si no hay una función en us-central que coincida con la función en la redirección!

Sugiero que el equipo de firebase intente dejar que alguien desarrolle un proyecto donde los usuarios estén fuera de los EE. UU. Es una locura que no recibamos advertencias para este tipo de cosas.

Ayudémonos unos a otros haciendo lo que piden: publique una solicitud de función:
https://firebase.google.com/support/troubleshooter/report/features

Aquí hay un borrador para que copie / pegue, solo hágalo :)

El hospedaje se reescribe en funciones en una región fuera de los EE. UU.
https://github.com/firebase/firebase-tools/issues/842

Realmente necesito poder crear reescrituras para funciones en regiones que no sean US-Central1.

Nuestro público objetivo no está en los EE. UU. y la falta de esta función es un gran problema para nosotros, lo que nos hace sentir inseguros de dedicar nuestra pila tecnológica a Firebase en general.

Considere priorizar esta función en un futuro próximo.
Gracias,

image

¡Aquí esperando esta función pronto!

¿Alguien ha investigado sobre el uso de la ejecución en la nube en lugar de las funciones en la nube?

Cloud Run proporciona funcionalidades en otras regiones también

Dos años después y esto sigue siendo un problema... ¿Por qué está cerrado por cierto?

Hola, este es el comportamiento esperado, consulte https://firebase.google.com/docs/functions/locations#http_and_client_callable_functions , el cuadro azul indica que todas las funciones que funcionan como redirecciones de alojamiento deben estar en 'us-central1', esto es debido al hecho de que ahí es donde está el origen del alojamiento.

Paginando a @laurenzlong

Cloud Functions está disponible en las siguientes regiones:

  • us-central1 (Iowa)
  • us-east1 (Carolina del Sur)
  • us-east4 (Norte de Virginia)
  • europe-west1 (Bélgica)
  • europe-west2 (Londres)
  • europe-west3 (Fráncfort)
  • asia-este2 (Hong Kong)
  • asia-noreste1 (Tokio)

Elegí eur3 (europe-west) porque estaba en la parte superior de la lista junto con us-central1 y separado de otras ubicaciones. Pensé que estos dos son predeterminados.

¿Qué debo hacer, hay alguna solución a esto?

¿¿¿¿¿Por qué?????

Hola amigos, gracias por todos los comentarios sobre esto. Definitivamente escuchamos que le gustaría ver las funciones de soporte de Firebase Hosting fuera de us-central1 . Desafortunadamente, hay una cantidad significativa de trabajo de infraestructura que debe realizarse antes de que funcione bien, por lo que no podemos simplemente "pulsar un interruptor" y poner en línea a otras regiones.

Hemos escuchado sobre esto con bastante frecuencia como una solicitud de función, y está en nuestra hoja de ruta, aunque no puedo comentar sobre plazos específicos. Este repositorio no es el lugar correcto para publicar solicitudes de funciones para el producto Firebase Hosting en su conjunto. Si está interesado en esta función, envíe una solicitud de función para que podamos seguir rastreando el interés en esto internamente y priorizar el trabajo. eso tiene que suceder para habilitarlo.

¡Gracias a todos!

Hola,

Creo que a nadie le importa dónde hospedas, solo queremos una solución simple para que el error no se muestre.

Esta solución se puede hacer en su código, nada que hacer donde hace su alojamiento.

Y esto no es una solicitud de función, la eliminación de un error no se convierte en una función. Solo elimina ese error

Gracias..

¿Fue útil esta página
0 / 5 - 0 calificaciones