Compare o App Engine e o Cloud Run

ID da região

O REGION_ID é um código abreviado que a Google atribui com base na região que seleciona quando cria a sua app. O código não corresponde a um país ou uma província, embora alguns IDs de regiões possam parecer semelhantes aos códigos de países e províncias usados frequentemente. Para apps criadas após fevereiro de 2020, REGION_ID.r está incluído nos URLs do App Engine. Para apps existentes criadas antes desta data, o ID da região é opcional no URL.

Saiba mais acerca dos IDs de regiões.

Este guia apresenta o Cloud Run para utilizadores familiarizados com o App Engine. Abrange as principais semelhanças e diferenças entre as plataformas sem servidor para ajudar a preparar a migração do ambiente padrão do App Engine ou do ambiente flexível do App Engine.

Vista geral

O Cloud Run é a mais recente evolução do Google Cloud sem servidor, baseando-se na experiência de execução do App Engine há mais de uma década. O Cloud Run é executado na mesma infraestrutura que o ambiente padrão do App Engine, pelo que existem muitas semelhanças entre estas duas plataformas.

O Cloud Run foi concebido para melhorar a experiência do App Engine, incorporando muitas das melhores funcionalidades do ambiente padrão do App Engine e do ambiente flexível do App Engine. Os serviços do Cloud Run podem processar as mesmas cargas de trabalho que os serviços do App Engine, mas o Cloud Run oferece aos clientes muito mais flexibilidade na implementação destes serviços. Esta flexibilidade, juntamente com as integrações melhoradas com o Google Cloud e os serviços de terceiros, também permite que o Cloud Run processe cargas de trabalho que não podem ser executadas no App Engine.

Resumo da comparação

Embora existam muitas semelhanças e diferenças entre o App Engine e o Cloud Run, esta vista geral foca-se nas áreas mais relevantes para os clientes do App Engine que estão a começar a usar o Cloud Run.

Ambiente padrão do App Engine Ambiente flexível do App Engine Cloud Run
Terminologia Aplicação N/A
Serviço Serviço
Versão Revisão

Pontos finais de URL

URL da app
(Serviço default)
https://PROJECT_ID.REGION_ID.r.appspot.com N/A
URL do serviço https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • https://SERVICE_IDENTIFIER.run.app
URL da versão/revisão https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://TAG---SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • https://TAG---SERVICE_IDENTIFIER.run.app

Dimensionar

Escala automática Sim Sim Sim
Escala manual Sim Sim Sim
Escalabilidade para zero Sim Não Sim
Pedidos de preparação Configurável Não Automático
Limite de tempo de inatividade da instância (após a conclusão do último pedido) Até 15 minutos Depende da definição de faturação. Use a faturação baseada em instâncias para emular o comportamento do App Engine
Tempo limite de pedido
  • Escala automática: 10 minutos
  • Dimensionamento manual/básico: 24 horas
60 minutos Configurável até 60 minutos (predefinição: 5 minutos)

Implementação

A partir da origem Sim Yes
Imagem de contentor Não Sim (tempos de execução personalizados) Yes
Contentores auxiliares Não Sim. Os sidecars são executados juntamente com o contentor principal, atendendo a pedidos Web.

Recursos de computação

vCPU
Classe da instância vCPU* Memória
F/B1 ,25 384MB
F/B2 0,5 768MB
F/B4 1 1,5 GB
F/B4_1G 1 3GB
B8 2 3GB
* Os equivalentes de vCPU são aproximados
Até 80 vCPU Até 8 vCPU
Memória Até 6,5 GB por vCPU Até 32 GB
GPUs Não Sim. Pode configurar uma GPU por instância do Cloud Run.
Suportes de volume Não Sim. Pode montar um contentor do Cloud Storage diretamente no sistema de ficheiros do contentor.

Modelo de preços

Taxa por pedido Não Não, quando usa a faturação baseada em instâncias.
Sim, quando usa a faturação baseada em pedidos.
Instâncias mínimas inativas O mesmo custo que as instâncias ativas Custo mais baixo para instâncias mínimas inativas (consulte Tempo de instância de contentor faturável)
Descontos de fidelidade (CUDs) Não Yes
Faturação baseada em instâncias (custo por hora da instância) Instância F4/B4: 0,2 USD
  • vCPU: 0,0526 $
  • Memória: 0,0071 USD
    • vCPU: 0,0648 $
    • Memória: 0,0072 USD

    Segurança

    Definições de entrada Yes Yes Yes
    Função de invocador Não Yes
    IAP Yes Yes Yes
    Firewalls Yes Yes Configure a utilização do Google Cloud Armor
    Secret Manager Sim, com as bibliotecas cliente da nuvem. Sim. Pode montar cada segredo como um volume ou transmitir um segredo através de variáveis de ambiente.

    Conetividade

    Domínios personalizados Yes Yes Yes
    Conetividade da VPC (incluindo a VPC partilhada) Yes N/A Yes
    Definições de saída da VPC Yes N/A Yes
    Balanceamento de carga multirregião Não Yes
    Streaming do servidor Não Yes

    Aceder aos Google Cloud serviços

    Cloud SQL Yes Yes Yes
    Bibliotecas cliente do Cloud Se estiver a usar as bibliotecas de cliente da nuvem no App Engine, não tem de alterar nada quando migrar para o Cloud Run. Estas bibliotecas clientes funcionam em qualquer lugar, o que significa que a sua aplicação é mais portátil.
    Serviços agrupados antigos do App Engine Sim (apenas Java, Python, Go e PHP) Não Não

    Modelo de recurso

    Diagrama do modelo de recursos do App Engine e do Cloud Run

    O modelo de recursos do Cloud Run é muito semelhante ao do App Engine, mas existem algumas diferenças importantes:

    • O Cloud Run não tem um recurso de aplicação de nível superior nem o serviço default correspondente.
    • Os serviços do Cloud Run no mesmo projeto podem ser implementados em diferentes regiões. No App Engine, todos os serviços no projeto estão na mesma região.
    • O Cloud Run usa o termo Revisão, em vez de Versão, para se alinhar com o modelo de recursos do Knative.
    • Os nomes das revisões do Cloud Run usam o formato: SERVICE_NAME-REVISION_SUFFIX, onde REVISION_SUFFIX é gerado automaticamente ou definido através da flag de implementação --revision-suffix=REVISION_SUFFIX.
    • As revisões do Cloud Run são imutáveis, o que significa que não pode reutilizar nomes como pode fazer com as versões do App Engine (usando a flag de implementação --version=VERSION_ID).
    • Os URLs dos serviços do Cloud Run baseiam-se num identificador de serviço que é gerado automaticamente na primeira implementação do serviço. Os identificadores de serviço usam o formato: SERVICE_NAME-<auto-generated identifier>. O identificador de serviço é exclusivo e não se altera durante a vida útil do serviço.
    • No Cloud Run, apenas os URLs de serviço (SERVICE_IDENTIFIER.run.app e https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app) são expostos por predefinição. Para resolver uma revisão específica, tem de configurar uma etiqueta de tráfego. No App Engine, os URLs de serviço e de versão são expostos automaticamente.

    Implementação e configuração

    No App Engine, a maioria da configuração é feita no app.yaml incluído em cada implementação. Esta simplicidade tem um custo, uma vez que, embora seja possível atualizar algumas definições através da API Admin, a maioria das alterações requer a reimplementação do serviço.

    Embora o Cloud Run tenha o ficheiro de configuração service.yaml, não é usado da mesma forma que o app.yaml. Não é possível usar o Cloud Run service.yaml quando implementa a partir da origem, uma vez que um dos elementos necessários é o caminho para a imagem do contentor final. Além disso, o service.yaml está em conformidade com a especificação Knative e pode ser difícil de ler para quem não está familiarizado com os ficheiros de configuração no estilo Kubernetes. Para mais informações sobre a utilização da service.yaml para gerir a configuração, consulte a documentação do Cloud Run.

    Para os clientes do App Engine que estão a começar a usar o Cloud Run, a utilização das flags de implementação da CLI gcloud alinha-se muito mais com a gestão da configuração no momento da implementação do App Engine.

    Para definir a configuração quando implementar novo código no Cloud Run, use os sinalizadores gcloud run deploy:

    gcloud run deploy SERVICE_NAME \
    --cpu CPU \
    --memory MEMORY \
    --concurrency CONCURRENCY
    

    Embora não seja necessário usar as flags de configuração com cada implementação (consulte Gerir configurações), pode fazê-lo para ajudar a simplificar a gestão da configuração.

    No Cloud Run, também pode atualizar a configuração sem voltar a implementar o código-fonte através do comando gcloud run services update:

    gcloud run services update SERVICE_NAME \
    --cpu CPU \
    --memory MEMORY \
    --concurrency CONCURRENCY
    

    Como as revisões do Cloud Run são imutáveis, este comando cria uma nova revisão com a configuração atualizada, mas usa a mesma imagem de contentor que a revisão existente.

    Gerir configurações

    Para implementações do App Engine, todas as definições têm de ser fornecidas para cada implementação, e as definições não fornecidas são atribuídas a valores predefinidos. Por exemplo, considere o App Engine service-a, com versões que usam os ficheiros app.yaml na tabela seguinte:

    App Engine service-a version1 App Engine service-a version2
    app.yaml
    runtime: python39
    service: service-a
    instance_class: F4
    
    runtime: python39
    service: service-a
    
    Configuração aplicada
    runtime: python39
    service: service-a
    instance_class: F4
    default values:
    ..
    ..
    runtime: python39
    service: service-a
    default values:
    instance_class: F1
    ..
    ..

    version1 está configurado com instance_class: F4, enquanto version2, que não forneceu nenhum valor para instance_class, está configurado com o valor predefinido instance_class: F1.

    Para o Cloud Run, são aplicadas todas as definições de configuração fornecidas, mas as que não são fornecidas mantêm os respetivos valores existentes. Só tem de fornecer valores para as definições que quer alterar. Por exemplo:

    Cloud Run service-a revision1 Cloud Run service-a revision2
    Comando de implementação
    gcloud run deploy service-a \
    --cpu=4
    
    gcloud run deploy service-a
    
    Configuração aplicada
    service: service-a
    vCPUs: 4
    default values:
    ..
    ..
    service: service-a
    vCPUs: 4
    default values:
    ..
    ..

    No App Engine, a implementação sem definições de configuração cria uma versão com todas as predefinições. No Cloud Run, a implementação sem definições de configuração cria uma revisão com as mesmas definições de configuração da revisão anterior. Para a primeira revisão de um serviço do Cloud Run, a implementação sem definições de configuração cria uma revisão com todas as definições predefinidas.

    Predefinições de configuração

    Definição de configuração Ambiente padrão do App Engine Ambiente flexível do App Engine Cloud Run
    Recursos de computação F1 1 vCPU, 0,6 GB 1 vCPU, 512MB
    Simultaneidade máxima (pedidos) 10 Nenhum 80
    Tempo limite de pedido
    • Escala automática: 10 minutos
    • Dimensionamento manual/básico: 24 horas
    60 minutos 5 minutos
    Objetivo de utilização da CPU 60% 50% 60%
    Máximo de instâncias Nenhum 20 100
    Instâncias mínimas 0 2 0

    Ponto de entrada

    Quando implementa a partir da origem, o App Engine lê o comando de ponto de entrada do atributo entrypoint no ficheiro app.yaml. Se não for fornecido nenhum ponto de entrada, é utilizada uma predefinição específica do tempo de execução. O Cloud Run usa os buildpacks do Google Cloud quando implementa a partir da origem. Alguns idiomas não têm um ponto de entrada predefinido, o que significa que tem de fornecer um ou a compilação falha. Por exemplo, os buildpacks do Python requerem um Procfile ou a especificação da variável de ambiente de compilação GOOGLE_ENTRYPOINT.

    Reveja a documentação dos buildpacks para conhecer os requisitos de configuração específicos do idioma.

    Dimensionar

    Embora o Cloud Run e o ambiente padrão do App Engine partilhem grande parte da mesma infraestrutura de escalabilidade, o Cloud Run foi simplificado para permitir uma escalabilidade muito mais rápida. No âmbito desta simplificação, as definições configuráveis estão limitadas ao seguinte:

    Para instâncias do Cloud Run, a utilização da CPU de destino não é configurável e está fixada em 60%. Consulte a documentação do Cloud Run para ver mais detalhes sobre o dimensionamento automático.

    O ambiente flexível do App Engine usa o autoscaler do Compute Engine, pelo que tem características de escalabilidade muito diferentes do ambiente padrão do App Engine e do Cloud Run.

    Limite de tempo de inatividade da instância

    No App Engine, as instâncias inativas permanecem ativas até 15 minutos após o processamento do último pedido. O Cloud Run permite-lhe configurar este comportamento através da atribuição de CPU. Para ter o mesmo comportamento que o App Engine, defina a atribuição de CPU como CPU sempre atribuída. Em alternativa, use a opção CPU apenas alocada durante o processamento de pedidos para que as instâncias inativas sejam encerradas imediatamente (se não existirem pedidos pendentes).

    Pedidos de aquecimento

    O Cloud Run aquece automaticamente as instâncias através do comando de ponto de entrada do contentor, pelo que não precisa de ativar manualmente os pedidos de aquecimento nem configurar um controlador /_ah/warmup. Se tiver código que quer executar no arranque da instância, antes de quaisquer pedidos serem processados, pode:

    Conteúdo estático

    No ambiente padrão do App Engine, pode publicar conteúdo estático sem usar recursos de computação publicando a partir do Cloud Storage ou configurando processadores.O Cloud Run não tem a opção de processadores para publicar conteúdo estático, pelo que pode publicar o conteúdo a partir do serviço do Cloud Run (igual ao conteúdo dinâmico) ou do Cloud Storage.

    Função de invocador do Cloud Run

    O Cloud Run também oferece a capacidade de controlar o acesso a um serviço com a gestão de identidade e de acesso (IAM). As associações de políticas de IAM para um serviço podem ser definidas através da CLI gcloud, da consola ou do Terraform.

    Para replicar o comportamento do App Engine, pode tornar o serviço público permitindo pedidos não autenticados. Isto pode ser definido na implementação ou atualizando as associações de políticas de IAM num serviço existente.

    Implementação

    Use a --allow-unauthenticatedflag de implementação:

    gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

    Serviço existente

    Use o comando gcloud run services add-iam-policy-binding:

    gcloud run services add-iam-policy-binding SERVICE_NAME \
    --member="allUsers" \
    --role="roles/run.invoker"

    em que SERVICE_NAME é o nome do serviço do Cloud Run.

    Em alternativa, pode optar por controlar quem tem acesso ao serviço concedendo a função do IAM Cloud Run Invoker, que é configurável por serviço.

    Implementação

    gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
    gcloud run services add-iam-policy-binding SERVICE_NAME \
    --member=MEMBER_TYPE \
    --role="roles/run.invoker"

    onde SERVICE_NAME é o nome do serviço e MEMBER_TYPE é o tipo principal. Por exemplo, user:email@domain.com.

    Para ver uma lista de valores aceitáveis para MEMBER_TYPE, consulte Identificadores principais.

    Serviço existente

    gcloud run services add-iam-policy-binding SERVICE_NAME \
    --member=MEMBER_TYPE \
    --role="roles/run.invoker"

    onde SERVICE_NAME é o nome do serviço e MEMBER_TYPE é o tipo principal. Por exemplo, user:email@domain.com.

    Para ver uma lista de valores aceitáveis para MEMBER_TYPE, consulte Identificadores principais.

    Variáveis de ambiente e metadados

    O App Engine e o Cloud Run têm determinadas variáveis de ambiente que são definidas automaticamente. A tabela seguinte mostra as variáveis de ambiente do App Engine, juntamente com os respetivos equivalentes do Cloud Run. O Cloud Run implementa apenas algumas variáveis de ambiente, em comparação com o App Engine, mas os dados disponíveis no servidor de metadados são maioritariamente equivalentes.

    Variáveis de ambiente predefinidas

    Nome do App Engine {[cloud_run_name]} Name Descrição
    GAE_SERVICE K_SERVICE O nome do serviço atual. No App Engine, este valor é definido como "default" se não for especificado.
    GAE_VERSION K_REVISION A etiqueta da versão atual do seu serviço.
    PORT PORT A porta que recebe pedidos HTTP.
    N/A K_CONFIGURATION O nome da configuração do Cloud Run que criou a revisão.
    GOOGLE_CLOUD_PROJECT N/A O Google Cloud ID do projeto associado à sua aplicação.
    GAE_APPLICATION O ID da sua aplicação do App Engine. Este ID tem o prefixo "código da região~", como "e~" para aplicações implementadas na Europa.
    GAE_DEPLOYMENT_ID O ID da implementação atual.
    GAE_ENV O ambiente do App Engine. Defina como "standard" se estiver no ambiente padrão.
    GAE_INSTANCE O ID da instância na qual o seu serviço está a ser executado.
    GAE_MEMORY_MB A quantidade de memória disponível para o processo da aplicação, em MB.
    NODE_ENV (disponível apenas no tempo de execução do Node.js) Defina como produção quando o serviço for implementado.
    GAE_RUNTIME O tempo de execução especificado no ficheiro app.yaml.

    Caminhos comuns do servidor de metadados

    Caminho Descrição Exemplo
    /computeMetadata/v1/project/project-id ID do projeto ao qual o serviço pertence test_project
    /computeMetadata/v1/project/numeric-project-id Número do projeto ao qual o serviço pertence 12345678912
    /computeMetadata/v1/instance/id Identificador exclusivo da instância do contentor (também disponível nos registos). 16a61494692b7432806a16
    (string of alpha-numeric characters)
    /computeMetadata/v1/instance/region
    ** Não disponível para o ambiente flexível do App Engine
    Região deste serviço, devolve projects/PROJECT_NUMBER/regions/REGION projects/12345678912/regions/us-central1
    /computeMetadata/v1/instance/service-accounts/default/email Email da conta de serviço de tempo de execução deste serviço. service_account@test_project.iam.gserviceaccount.com
    /computeMetadata/v1/instance/service-accounts/default/token Gera uma chave de acesso OAuth2 para a conta de serviço deste serviço. Este ponto final devolve uma resposta JSON com um atributo access_token. {
    "access_token":"<TOKEN>",
    "expires_in":1799,
    "token_type":"Bearer"
    }

    O que se segue?