Resolver problemas do Cloud Run

Nesta página, mostramos como solucionar mensagens de erro e problemas ao usar o Cloud Run.

Você também pode verificar problemas existentes ou abrir novos nos issue trackers públicos.

Para ver outras mensagens de erro não listadas nesta página, consulte a página de problemas conhecidos.

Erros de implantação

Nesta seção, listamos problemas de implantação que você pode encontrar e fornecemos sugestões de como corrigir cada um deles.

Falha ao iniciar o contêiner

O seguinte erro ocorre quando você tenta implantar:

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

Para resolver esse problema, elimine as seguintes causas possíveis:

  1. Verifique se é possível executar a imagem do contêiner localmente. Se não for possível executar a imagem do contêiner localmente, será preciso diagnosticar e corrigir o problema localmente primeiro.

  2. Verifique se o contêiner está detectando solicitações na porta esperada, conforme documentado no contrato de ambiente de execução do contêiner. O contêiner precisa detectar solicitações de entrada na porta definida pelo Cloud Run e fornecidas na variável de ambiente PORT. Consulte Como configurar contêineres para ver instruções sobre como especificar a porta.

  3. Verifique se o contêiner está detectando as solicitações em todas as interfaces de rede, normalmente indicadas como 0.0.0.0.

  4. Verifique se a imagem do contêiner é compilada para o Linux de 64 bits, conforme solicitado no contrato de ambiente de execução do contêiner.

  5. Use o Cloud Logging para procurar erros de aplicativo nos registros stdout ou stderr. Também é possível procurar por falhas capturadas no Error Reporting.

    Talvez seja necessário atualizar o código ou as configurações de revisão para corrigir erros ou falhas. Também é possível resolver problemas do serviço localmente.

Erro interno: o prazo de prontidão do recurso foi excedido

O seguinte erro ocorre quando você tenta implantar ou chamar outra API do Google Cloud:

The server has encountered an internal error. Please try again later. Resource readiness deadline exceeded.

Esse problema pode ocorrer quando o agente de serviço do Cloud Run não existe ou não tem o papel de agente de serviço do Cloud Run (roles/run.serviceAgent).

Para verificar se o agente de serviço do Cloud Run existe no projeto do Google Cloud e se ele tem o papel necessário, siga estas etapas:

  1. Abra o Console do Google Cloud:

    Acessar a página "Permissões"

  2. No canto superior direito da página Permissões, marque a caixa de seleção Incluir concessões de papel fornecidas pelo Google.

  3. Na lista Principais, localize o ID do agente de serviço do Cloud Run, que usa o ID
    service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com.

  4. Verifique se o agente de serviço tem o papel Agente de serviço do Cloud Run. Se não tiver, conceda-o.

Erro usuário "raiz" não encontrado em /etc/passwd

O seguinte erro ocorre quando você tenta implantar:

ERROR: "User \"root\""not found in /etc/passwd

O problema ocorre quando chaves de criptografia gerenciadas pelo cliente são especificadas usando um parâmetro --key

Para resolver esse problema, especifique USER 0 em vez de USER root no Dockerfile.

A conta de serviço padrão do Compute Engine foi excluída

O seguinte erro ocorre quando você tenta implantar:

ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

Esse problema ocorre em um destes casos:

Para resolver o problema:

  1. Especifique uma conta de serviço usando a sinalização --service-account gcloud.
  2. Verifique se a conta de serviço especificada tem as permissões necessárias para implantação.

Para verificar se o agente de serviço padrão do Compute Engine existe no projeto do Google Cloud, siga estas etapas:

  1. Abra o Console do Google Cloud:

    Acessar a página "Permissões"

  2. No canto superior direito da página Permissões, marque a caixa de seleção Incluir concessões de papel fornecidas pelo Google.

  3. Na lista Principais, localize o ID do agente de serviço do Compute Engine, que usa o ID
    PROJECT_NUMBER-compute@developer.gserviceaccount.com.

O agente de serviço do Cloud Run não tem permissão para ler a imagem

O seguinte erro ocorre quando você tenta implantar a partir de PROJECT-ID usando uma imagem armazenada no Container Registry em PROJECT-ID-2:

Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.

Para resolver esse problema, siga estas recomendações de solução de problemas:

  • Siga as instruções para implantar imagens de contêiner de outros projetos do Google Cloud para garantir que seus principais tenham as permissões necessárias.

  • Esse problema também poderá ocorrer se o projeto estiver em um perímetro do VPC Service Controls com uma restrição na API Cloud Storage que proíbe solicitações do agente de serviço do Cloud Run. Para corrigir isso, faça o seguinte:

    1. Abra o Explorador de registros no console do Google Cloud. Não use a página Registros na página do Cloud Run:

      Acessar o Explorador de registros

    2. Digite o seguinte texto no campo de consulta:

      protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
severity=ERROR
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"

    3. Se você vir alguma entrada de registro depois de usar esta consulta, examine-a e determine se é necessário atualizar as políticas do VPC Service Controls. Eles podem indicar que você precisa adicionar service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com a uma política de acesso preexistente.

Erros de importação de contêineres

O seguinte erro ocorre quando você tenta implantar:

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

Para resolver esse problema, elimine as seguintes causas possíveis:

  1. Verifique se o sistema de arquivos do contêiner não contém caracteres não utf8.

  2. Algumas imagens do Docker baseadas no Windows usam camadas externas. O Container Registry não gera um erro quando há camadas externas, mas o plano de controle do Cloud Run não é compatível com elas. Para resolver o problema, tente definir a sinalização --allow-nondistributable-artifacts no daemon do Docker.

Erros de veiculação

Nesta seção, listamos problemas de veiculação que você pode encontrar e fornecemos sugestões de como corrigir cada um deles.

HTTP 401: o cliente não foi autenticado corretamente.

Este erro ocorre durante a veiculação:

The request was not authorized to invoke this service

Para resolver o problema:

  • Se invocada por uma conta de serviço, a declaração de público-alvo (aud) do token de ID assinado pelo Google precisará ser definida da seguinte maneira:

    • O URL do Cloud Run do serviço de recebimento, usando o formato https://service-xyz.run.app.
      • O serviço do Cloud Run precisa exigir autenticação.
      • O serviço do Cloud Run pode ser invocado pelo URL do Cloud Run ou por um URL do balanceador de carga.
    • O ID do cliente de um OAuth 2.0 com o tipo de aplicativo da Web, usando o formato nnn-xyz.apps.googleusercontent.com.
    • Um público-alvo personalizado configurado que usa os valores exatos fornecidos. Por exemplo, se o público-alvo personalizado for service.example.com, o valor da declaração de público-alvo (aud) também precisará ser service.example.com. Se o público-alvo personalizado for https://service.example.com, o valor da declaração de público-alvo também precisará ser https://service.example.com.

  • A ferramenta jwt.io é boa para verificar declarações em um JWT.

  • Se o token de autenticação tiver um formato inválido, ocorrerá um erro 401. Se o token tiver um formato válido e o membro do IAM usado para gerar o token não tiver a permissão run.routes.invoke, um erro 403 ocorrerá.

  • Quando você usa o servidor de metadados para buscar tokens de ID e acesso para autenticar solicitações com o serviço do Cloud Run ou a identidade do job com um proxy HTTP para rotear o tráfego de saída, e você recebe tokens inválidos, adicione os hosts a seguir às exceções de proxy HTTP:

    • 169.254.* ou 169.254.0.0/16
    • *.google.internal

    Esse erro geralmente ocorre quando as bibliotecas de cliente do Cloud usam o servidor de metadados para buscar o Application Default Credentials e autenticar as invocações REST ou gRPC. Se você não definir as exceções do proxy HTTP, os seguintes resultados de comportamento vão aparecer:

    • Se o serviço ou job do Cloud Run e o proxy HTTP estiverem hospedados em diferentes cargas de trabalho do Google Cloud, mesmo que as bibliotecas de cliente do Google Cloud consigam credenciais, os tokens serão gerados para a conta de serviço atribuída à carga de trabalho do proxy HTTP, que pode não ter as permissões necessárias para executar as operações pretendidas da API Google Cloud. Nesse caso, os tokens são buscados na visualização do servidor de metadados da carga de trabalho do proxy HTTP, em vez do do Cloud Run.

    • Se o proxy HTTP não estiver hospedado no Google Cloud, e as solicitações do servidor de metadados forem roteadas usando o proxy, as solicitações de token falharão, e as operações das APIs do Google Cloud não serão autenticadas.

HTTP 403: o cliente não está autorizado a invocar ou chamar o serviço

O erro a seguir pode ou não estar no Cloud Logging com resource.type = "cloud_run_revision":

The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header

O seguinte erro está presente na resposta HTTP retornada ao cliente:

403 Forbidden
Your client does not have permission to get URL from this server.

Para resolver esse problema quando o recurso resource.type = "cloud_run_revision" está presente:

  • Se você quiser que o serviço possa ser chamado por qualquer pessoa, atualize as configurações do IAM para tornar o serviço público.
  • Se quiser que o serviço possa ser invocado apenas por determinadas identidades, invoque-o com o token de autorização apropriado.
    • Se invocado por um desenvolvedor ou invocado por usuário final: verifique se o desenvolvedor ou usuário tem a permissão run.routes.invoke, que é possível fornecer com os papéis de administrador do Cloud Run (roles/run.admin) e de invocador do Cloud Run (roles/run.invoker).
    • Se invocado por uma conta de serviço: verifique se a conta de serviço é membro do serviço do Cloud Run e se tem o papel de invocador do Cloud Run (roles/run.invoker).
    • As chamadas sem um token de autenticação ou com um token de autenticação no formato válido, mas com o membro do IAM usado para gerar o token sem a permissão run.routes.invoke, resultam neste erro 403.

Para resolver esse problema quando o recurso resource.type = "cloud_run_revision" não está presente:

  • Um código de status 403 pode ser retornado quando um serviço tem a entrada configurada como All, mas foi bloqueada devido ao VPC Service Controls. Consulte a próxima seção sobre erros 404 para mais informações sobre como solucionar negações do VPC Service Controls.

HTTP 404: não encontrado

Este problema ocorre durante a veiculação:

Ocorreu um erro HTTP 404.

Para resolver o problema:

  1. Confirme se o URL solicitado está correto. Para isso, verifique a página de detalhes do serviço no console do Cloud ou execute o seguinte comando:

    gcloud run services describe SERVICE_NAME | grep URL

  2. Inspecione onde a lógica do aplicativo pode estar retornando códigos de erro 404. Se o aplicativo retornar o 404, ele ficará visível no Cloud Logging.

  3. Verifique se o aplicativo não começa a detectar a porta configurada antes de estar pronto para receber solicitações.

  4. Verifique se o aplicativo não retorna um código de erro 404 quando você o executa localmente.

Uma 404 é retornada quando as configurações de entrada de um serviço do Cloud Run são definidas como "Interno" ou "Balanceamento de carga interno e do Cloud" e uma solicitação não está de acordo com a restrição de rede especificada. Nesse cenário, a solicitação não chega ao contêiner e o 404 não está presente no Cloud Logging com o seguinte filtro:

resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404

Com as mesmas configurações de entrada, a solicitação pode ser bloqueada pelo VPC Service Controls com base no contexto do autor da chamada, incluindo o projeto e o endereço IP. Para verificar se há uma violação da política do VPC Service Controls:

  1. Abra a Análise de registros no console do Google Cloud (não a página Registros do Cloud Run):

    Acessar o Explorador de registros

  2. Digite o seguinte texto no campo de consulta:

    resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"

  3. Se você vir entradas de registro depois de usar essa consulta, examine-as para determinar se é necessário atualizar as políticas do VPC Service Controls.

HTTP 429: nenhuma instância de contêiner disponível

Este erro ocorre durante a veiculação:

HTTP 429
The request was aborted because there was no available instance.
The Cloud Run service might have reached its maximum container instance
limit or the service was otherwise not able to scale to incoming requests.
This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.

Para resolver esse problema, verifique a métrica "Contagem de instâncias do contêiner" do seu serviço e considere aumentar esse limite se o uso estiver próximo do máximo. Consulte as configurações da instância máxima e, se precisar de mais instâncias, solicite um aumento de cota.

HTTP 500: o Cloud Run não pôde gerenciar a taxa de tráfego

O erro a seguir ocorre durante a disponibilização e também pode ocorrer quando o serviço não atingir o limite máximo de instâncias de contêiner:

HTTP 500
The request was aborted because there was no available instance

Esse erro pode ser causado por um dos motivos a seguir:

  • Um grande aumento repentino no tráfego
  • Um longo tempo de inicialização a frio
  • Tempo longo de processamento de uma solicitação ou um aumento repentino no tempo de processamento da solicitação.
  • O serviço atinge o limite máximo de instâncias de contêiner (HTTP 429).
  • Fatores temporários atribuídos ao serviço do Cloud Run.

Para resolver esse problema, resolva os problemas citados anteriormente.

Além disso, é possível implementar espera exponencial e novas tentativas para solicitações que o cliente não pode descartar.

Um aumento curto e repentino no tráfego ou no tempo de processamento da solicitação só ficará visível no Cloud Monitoring se você aumentar o zoom para uma resolução de 10 segundos.

Quando a causa raiz do problema for um período de erros temporários maiores atribuíveis exclusivamente ao Cloud Run, entre em contato com o Suporte.

HTTP 500 / HTTP 503: as instâncias de contêiner estão excedendo os limites de memória

Este erro ocorre durante a veiculação:

No Cloud Logging:

While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.

Para resolver o problema:

  1. Determine se as instâncias de contêiner estão excedendo a memória disponível. Procure erros relacionados nos registros varlog/system.
  2. Se as instâncias estiverem excedendo a memória disponível, considere aumentar o limite de memória.

No Cloud Run, os arquivos gravados no sistema de arquivos local são contabilizados na memória disponível. Isso também inclui todos os arquivos de registro gravados em locais diferentes de /var/log/* e /dev/log.

HTTP 503: resposta incorreta ou problema de conexão da instância do contêiner

Um destes erros ocorre durante a veiculação: 

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.

Para resolver esse problema, siga estas recomendações de solução de problemas:

  • Verifique o Cloud Logging Use o Cloud Logging para procurar erros de falta de memória nos registros. Se você vir mensagens de erro relacionadas a instâncias de contêiner que excedem os limites de memória, siga as recomendações para resolver esse problema.

  • Tempo limite no nível do app Se as solicitações forem encerradas com o código de erro 503 antes de atingir o tempo limite da solicitação definido no Cloud Run, talvez seja necessário atualizar a configuração de tempo limite da solicitação para o framework da linguagem:

  • Gargalo de rede downstream: em alguns casos, um código de erro 503 pode resultar indiretamente em um gargalo de rede downstream, como durante o teste de carga. Por exemplo, se o serviço direciona o tráfego por um conector de acesso VPC sem servidor, siga estas etapas para garantir que o conector não exceda o limite de capacidade:

    1. Abra o acesso VPC sem servidor no console do Google Cloud:

      Página do console sobre o acesso VPC sem servidor

    2. Verifique se há barras vermelhas no histograma do gráfico de capacidade. Se houver uma barra vermelha, considere aumentar o número máximo de instâncias ou o tipo de instância que seu conector usa. Como alternativa, compacte o tráfego enviado por um conector de acesso VPC sem servidor.

  • Limite de solicitação de entrada para um único contêiner Há um problema conhecido, em que há taxas de solicitação altas por contêiner que resultam no erro 503. Se uma instância de contêiner receber mais de 800 solicitações por segundo, os soquetes TCP disponíveis poderão ser esgotados. Para resolver isso, tente uma das seguintes opções:

    1. Ative o HTTP/2 no seu serviço e faça as alterações necessárias para que ele seja compatível com o HTTP/2.

    2. Evite enviar mais de 800 solicitações/segundo para uma única instância de contêiner reduzindo a simultaneidade configurada. Use a seguinte equação para ver uma estimativa da taxa de solicitação por instância de contêiner: requests/sec/container_instance ~= concurrency * (1sec / median_request_latency)

HTTP 503: não foi possível processar algumas solicitações devido à alta configuração de simultaneidade

Estes erros ocorrem durante a veiculação:

HTTP 503
The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.

Esse problema ocorre quando as instâncias de contêiner estão usando muita CPU para processar solicitações e, como resultado, as instâncias de contêiner não podem processar todas as solicitações. Por isso, algumas solicitações retornam um código de erro 503.

Para resolver esse problema, tente uma ou mais destas opções:

HTTP 504: erro de tempo limite do gatewayy

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

Se o serviço estiver processando solicitações longas, é possível aumentar o tempo limite da solicitação. Se o serviço não retornar uma resposta dentro do tempo especificado, a solicitação será encerrada e o serviço retornará umHTTP 504 conforme documentado nocontrato de ambiente de execução do contêiner de dados.

Para resolver esse problema, tente uma ou mais destas opções:

  • Instrumente a geração de registros e o rastreamento para entender onde seu app está passando tempo antes de exceder o tempo limite configurado da solicitação.

  • As conexões de saída são redefinidas às vezes devido a atualizações de infraestrutura. Se o aplicativo reutilizar conexões de longa duração, recomendamos configurá-lo para restabelecer as conexões e evitar a reutilização de uma conexão inativa.

    • Dependendo da lógica do app ou do tratamento de erros, um erro 504 pode ser um sinal de que seu app está tentando reutilizar uma conexão inativa e que a solicitação bloqueia até o tempo limite configurado da solicitação.
    • Use uma sondagem de atividade para ajudar a encerrar uma instância que retorna erros persistentes.

  • Erros de falta de memória que acontecem no código do app, por exemplo, java.lang.OutOfMemoryError, não necessariamente encerram uma instância de contêiner. Se o uso da memória não exceder o limite de memória do contêiner, a instância não será encerrada. Dependendo de como o app trata erros de memória insuficiente, as solicitações podem ficar suspensas até excederem o tempo limite configurado da solicitação.

    • Se você quiser que a instância do contêiner seja encerrada no cenário acima, configure o limite de memória no nível do app para ser maior que o limite de memória do contêiner.
    • Use uma sondagem de atividade para ajudar a encerrar uma instância que retorna erros persistentes.

Conexão redefinida pelo par

Um destes erros ocorre durante a veiculação:

Connection reset by peer
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
grpc.StatusRuntimeException: UNAVAILABLE: io exception
psycopg.OperationalError: the connection is closed
ECONNRESET

Esse erro ocorre quando um aplicativo tem uma conexão TCP estabelecida com um peering na rede e ele fecha a conexão inesperadamente.

Para resolver o problema:

  • Se você estiver tentando executar o trabalho em segundo plano com a limitação de CPU, tente usar a configuração de alocação de CPU "A CPU está sempre alocada".

  • Verifique se você está dentro dos tempos limite das solicitações de saída. Se o aplicativo mantiver qualquer conexão em um estado inativo além desses limites, o gateway precisará conseguir a conexão.

  • Por padrão, a opção de soquete TCP keepalive está desativada para o Cloud Run. Não há uma forma direta de configurar a opção keepalive no Cloud Run no nível do serviço, mas é possível ativar a opção keepalive em cada conexão de soquete. Para isso, forneça as opções corretas ao abrir uma nova conexão de soquete TCP, dependendo da biblioteca de cliente que você está usando para essa conexão no aplicativo.

  • Às vezes, conexões de saída serão redefinidas devido a atualizações de infraestrutura. Se o aplicativo reutilizar conexões de longa duração, recomendamos configurá-lo para restabelecer as conexões e evitar a reutilização de uma conexão inativa.

  • Se você estiver usando um proxy HTTP para rotear o tráfego de saída de jobs ou serviços do Cloud Run, e o proxy aplicar a duração máxima da conexão, o proxy poderá descartar silenciosamente as conexões TCP de longa duração, como as estabelecidas usando pools de conexão. Isso faz com que clientes HTTP falhem ao reutilizar uma conexão já fechada. Se você pretende rotear o tráfego de saída por um proxy HTTP, considere esse cenário implementando a validação de conexão, novas tentativas e a espera exponencial. Para pools de conexões, configure os valores máximos de idade da conexão, conexões inativas e tempo limite de inatividade da conexão.

Tempos limite de conexão

Erros de latência ou um dos erros a seguir ocorrem quando há tempos limite de conexão ao fazer uma solicitação para um host remoto:

java.io.IOException: Connection timed out
ConnectionError: HTTPSConnectionPool
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded

Esse tipo de erro ocorre quando um aplicativo tenta criar uma nova conexão TCP com um host remoto e a conexão demora muito para ser estabelecida.

  • Se você estiver roteando todo o tráfego de saída por uma rede VPC, usando conectores de VPC ou saída direta da VPC, verifique se:

    • Você definiu todas as regras de firewall necessárias para permitir o tráfego de entrada para os conectores VPC.

    • Suas regras de firewall da VPC permitem que o tráfego de entrada dos conectores da VPC ou da sub-rede de saída da VPC direta chegue ao host ou à sub-rede de destino.

    • Você tem todas as rotas necessárias para permitir o roteamento correto do tráfego para os hosts de destino e de volta. Isso é importante ao rotear o tráfego de saída por meio de peering de rede VPC ou conectividade de nuvem híbrida, já que os pacotes atravessam várias redes antes de chegar ao host remoto.

  • Se você estiver usando um proxy HTTP para rotear todo o tráfego de saída dos serviços ou jobs do Cloud Run, verifique se os hosts remotos podem ser acessados usando o proxy.

    Dependendo da utilização dos recursos do proxy, o tráfego roteado por um proxy HTTP pode atrasar. Se você pretende rotear o tráfego de saída HTTP usando um proxy, considere esse cenário implementando novas tentativas, espera exponencial ou disjuntores.

Configurar exceções de proxy HTTP

Ao usar um proxy HTTP para rotear o tráfego de saída de jobs ou serviços do Cloud Run, adicione exceções para APIs do Cloud e outros hosts e sub-redes sem proxy para evitar latência, tempos limite de conexão, redefinições de conexão e erros de autenticação.

Hosts e sub-redes sem proxy precisam incluir, no mínimo, o seguinte:

  • 127.0.0.1
  • 169.254.* ou 169.254.0.0/16
  • localhost
  • *.google.internal
  • *.googleapis.com

Como opção, os hosts sem proxy podem incluir:

  • *.appspot.com
  • *.run.app
  • *.cloudfunctions.net
  • *.gateway.dev
  • *.googleusercontent.com
  • *.pkg.dev
  • *.gcr.io

Confira algumas maneiras comuns de configurar exceções de proxy HTTP para redes de saída:

  • Variáveis de ambiente: NO_PROXY ou no_proxy

  • Sinalização de máquina virtual Java http.nonProxyHosts.

    • A propriedade do sistema https.nonProxyHosts não está definida, então http.nonProxyHosts se aplica a HTTP e HTTPS.
    • A propriedade do sistema http.nonProxyHosts não é compatível com a notação CIDR. Por isso, é necessário usar expressões que correspondam a padrões.

Assinatura do token de identidade editada pelo Google

Estes erros ocorrem durante a veiculação:

SIGNATURE_REMOVED_BY_GOOGLE

Isso pode ocorrer durante o desenvolvimento e teste nestas circunstâncias:

  1. Um usuário faz login usando a CLI do Google Cloud ou o Cloud Shell.
  2. O usuário gera um token de ID usando comandos gcloud.
  3. O usuário tenta usar o token de ID para invocar um serviço não público do Cloud Run.

Isso ocorre por design. O Google remove a assinatura do token devido a questões de segurança para evitar que serviços não públicos do Cloud Run reproduzam tokens de ID gerados dessa forma.

Para resolver esse problema, invoque o seu serviço privado com um novo token de ID. Veja como testar a autenticação no seu serviço para mais informações.

Aviso do OpenBLAS nos registros

Se você usa bibliotecas baseadas em OpenBLAS, como o NumPy com o ambiente de execução de primeira geração, talvez veja o seguinte aviso nos registros:

OpenBLAS WARNING - could not determine the L2 cache size on this system, assuming 256k

Este é apenas um alerta e não afeta seu serviço. Isso ocorre porque o sandbox de contêiner usado pelo ambiente de execução de primeira geração não expõe recursos de hardware de baixo nível. Também é possível alternar para o ambiente de execução de segunda geração, se você não quiser ter esses avisos nos registros.

O Spark falha ao conseguir o endereço IP da máquina a ser vinculado

Um destes erros ocorre durante a veiculação:

assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>

Para resolver o problema:

Para alterar o valor da variável de ambiente e resolver o problema, defina ENV SPARK_LOCAL_IP="127.0.0.1" no seu Dockerfile. No Cloud Run, se a variável SPARK_LOCAL_IP não estiver definida, ela usará como padrão a contraparte IPv6 em vez de localhost. A configuração RUN export SPARK_LOCAL_IP="127.0.0.1" não estará disponível no ambiente de execução, e o Spark vai atuar como se não estivesse definido.

Como mapear domínios personalizados

O domínio personalizado está travado no estado de provisionamento de certificados

Um destes erros ocorre quando você tenta mapear um domínio personalizado:

The domain is available over HTTP.  Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.

Para resolver o problema:

  • Aguarde pelo menos 24 horas. O provisionamento do certificado SSL geralmente leva cerca de 15 minutos, mas pode levar até 24 horas.

  • Verifique se você atualizou corretamente os registros DNS no registrador de domínios usando a ferramenta de escavação do Google Admin Toolbox.

    Os registros DNS no registrador de domínios precisam corresponder ao que o console do Google Cloud solicita a adicionar.

  • Confirme se a raiz do domínio foi verificada na sua conta usando um destes métodos:

  • Verifique se o certificado do domínio não expirou. Para encontrar os limites de expiração, use este comando:

    echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout

O app não pode ter mais de 1.000 serviços (módulos)

O seguinte erro ocorre durante a execução do job: 

Your app may not have more than 1000 services (modules). Please delete one of the existing services (modules) before trying to create a new service (module)
.

Cada implantação do serviço do Cloud Run conta como um serviço ou módulo na cota disponível, independentemente de quantas solicitações recebe. No entanto, para jobs do Cloud Run, cada um deles com execução ativa do job conta como um serviço em relação à cota. Portanto, se você executar muitas execuções de jobs simultâneas, poderá exceder a cota e receber esse erro. O uso de tarefas paralelas em uma única execução de job em vez de muitas execuções de jobs pode resolver isso.

Admin API

O recurso não tem suporte na etapa do lançamento declarado

Este erro ocorre ao chamar a API Cloud Run Admin:

The feature is not supported in the declared launch stage

Esse erro ocorre quando você chama a API Cloud Run Admin diretamente e usa um recurso Beta sem especificar um campo ou uma anotação da fase de lançamento.

Para resolver esse problema, adicione o campo da fase de lançamento às solicitações. Confira abaixo exemplos para a API REST v1 e a API REST v2:

O seguinte exemplo adiciona uma anotação da fase de lançamento a uma solicitação de cliente usando JSON e a API REST v1:

    "annotations": {
      "run.googleapis.com/launch-stage": "BETA"
    }

O seguinte exemplo adiciona uma referência LaunchStage a uma solicitação de cliente usando JSON e a API REST v2:

  "launchStage": "BETA"

O seguinte exemplo adiciona uma anotação da fase de lançamento a uma solicitação de serviço usando YAML e a API REST v1:

kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA

A desconexão do cliente não é propagada para o Cloud Run

Quando você usa HTTP/1.1 no Cloud Run, os eventos de desconexão do cliente não são propagados para o contêiner do Cloud Run.

A solução é usar Websockets ou HTTP/2.0, que propagam desconexões do cliente.

Solução de problemas do sistema de arquivos de rede

Saiba mais sobre como usar sistemas de arquivos de rede.

Não é possível acessar arquivos usando NFS

Erro Solução sugerida
mount.nfs: Protocol not supported Algumas imagens base, como debian e adoptopenjdk/openjdk11, não têm a dependência nfs-kernel-server.
mount.nfs: Connection timed out Se a conexão expirar, verifique se você está fornecendo o endereço IP correto da instância do Filestore.
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE Se o acesso tiver sido negado pelo servidor, verifique se o nome do compartilhamento de arquivos está correto.

Não é possível acessar arquivos usando o Cloud Storage FUSE

Consulte o guia de solução de problemas do Cloud Storage FUSE.