Comparar o App Engine e o Cloud Run

ID da região

O REGION_ID é um código abreviado que o Google atribui com base na região que você selecionou ao criar o aplicativo. O código não corresponde a um país ou estado, ainda que alguns IDs de região sejam semelhantes aos códigos de país e estado geralmente usados. Para apps criados após fevereiro de 2020, o REGION_ID.r está incluído nos URLs do App Engine. Para apps existentes criados antes dessa data, o ID da região é opcional no URL.

Saiba mais sobre IDs de região.

Este guia fornece uma introdução ao Cloud Run para quem está familiarizado com o App Engine. Ele aborda as principais semelhanças e diferenças entre as plataformas sem servidor para ajudar na preparação para a migração do ambiente padrão ou flexível do App Engine.

Visão geral

O Cloud Run é a evolução mais recente do Google Cloud sem servidor, com base na experiência de execução do App Engine por mais de uma década. O Cloud Run é executado em grande parte da mesma infraestrutura do ambiente padrão do App Engine. Portanto, há muitas semelhanças entre essas duas plataformas.

O Cloud Run foi desenvolvido para melhorar a experiência no App Engine, incorporando muitos dos melhores recursos do ambiente padrão e flexível do App Engine. Os serviços do Cloud Run podem lidar com 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 desses serviços. Essa flexibilidade, assim como integrações aprimoradas com serviços do Google Cloud e de terceiros, também permite que o Cloud Run lide com cargas de trabalho que não podem ser executadas no App Engine.

Resumo de comparação

Há muitas semelhanças e diferenças entre o App Engine e o Cloud Run, mas esta visão geral se concentra nas áreas mais relevantes para os clientes do App Engine que estão começando a usar o Cloud Run.

Ambiente padrão do App Engine Ambiente flexível do App Engine Cloud Run

Terminologia Aplicativo N/A

Serviço Serviço

Versão Revisão

Pontos de extremidade de URL

URL do aplicativo
(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_IDENTIFIER.run.app

URL da versão/revisão https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com https://TAG---SERVICE_IDENTIFIER.run.app

Escalonamento

Escalonamento automático Sim Sim Sim

Escalonamento manual Sim Sim Embora não haja uma configuração de escalonamento manual específica, é possível replicar o mesmo comportamento configurando máximo de instâncias igual ao mínimo de instâncias.

Escalonamento para zero Sim Não Sim

Solicitações de aquecimento Configurável Não Automática

Tempo limite da instância inativa (depois de concluir a última solicitação) Até 15 minutos Depende da configuração de Alocação de CPU. Use a CPU sempre alocada para emular o comportamento do App Engine.

Tempo limite da solicitação

Escalonamento automático: 10 minutos
Escalonamento manual/básico: 24 horas

60 minutos

Configurável até 60 minutos (padrão: 5 minutos)

Implantação

A partir da origem Sim Sim

Imagem do contêiner Não Sim (tempos de execução personalizados) Sim

Recursos de computação

vCPU

Classe da instância	vCPU*	Memória
F/B1	.25	384 MB
F/B2	0,5	768 MB
F/B4	1	1,5 GB
F/B4_1G	1	3 GB
B8	2	3 GB

* Os equivalentes da vCPU são aproximados

Até 80 vCPUs

Até 8 vCPUs

Memória Até 6.5 GB por vCPU Até 32 GB

Modelo de preços

Taxa por solicitação Não Não, quando a CPU está sempre alocada.
Sim, quando a CPU é alocada somente durante o processamento da solicitação.

Mínimo de instâncias inativas Mesmo custo das instâncias ativas Menor custo para instâncias mínimas inativas (consulte Tempo de instância do contêiner faturável )

Descontos por compromisso de uso (CUDs) Não Sim

Segurança

Configurações de entrada Sim Sim Sim

Papel de invocador Não Sim

IAP Sim Sim Configurar usando o Cloud Load Balancing

Firewalls Sim Sim Configurar usando o Google Cloud Armor

Conectividade

Domínios personalizados Sim Sim Configurar usando o Cloud Load Balancing

Conectividade VPC (incluindo VPC compartilhada) Sim N/A Sim

Configurações de saída da VPC Sim N/A Sim

Balanceamento de carga multirregional Não Sim

Como acessar serviços do Google Cloud

Cloud SQL Sim Sim Sim

Bibliotecas de cliente do Cloud Se você estiver usando as bibliotecas de cliente do Cloud no App Engine, não precisará mudar nada ao migrar para o Cloud Run. Essas bibliotecas funcionam em todos os tipos de ambiente, o que significa que o aplicativo será mais portátil.

Serviços agrupados do App Engine legado Sim (somente Java, Python, Go e PHP) Não Não

Modelo de recurso

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

O Cloud Run não tem um recurso de Aplicação de nível superior ou o serviço default correspondente.
Os serviços do Cloud Run no mesmo projeto podem ser implantados em regiões diferentes. 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 alinhar com o modelo de recursos do Knative.
Os nomes das revisões do Cloud Run usam o formato: SERVICE_NAME-REVISION_SUFFIX, em que REVISION_SUFFIX é gerado automaticamente ou definido usando o flag de implantação --revision-suffix=REVISION_SUFFIX.
As revisões do Cloud Run são imutáveis. Isso significa que não é possível reutilizar nomes como é possível fazer com versões do App Engine (usando o flag de implantação --version=VERSION_ID).
Os URLs de serviço do Cloud Run são baseados em um identificador de serviço gerado automaticamente na primeira implantaçã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 muda durante o ciclo de vida do serviço.
No Cloud Run, somente os URLs de serviço (SERVICE_IDENTIFIER.run.app) são expostos por padrão. Para abordar uma revisão específica, é preciso configurar uma tag de tráfego. No App Engine, os URLs de serviço e versão são expostos automaticamente.

Implantação e configuração

No App Engine, a maior parte da configuração é feita no app.yaml incluído em cada implantação. Essa simplicidade tem um custo, embora algumas configurações possam ser atualizadas usando a API Admin, a maioria das alterações exige a reimplantação do serviço.

Embora o Cloud Run tenha o arquivo de configuração service.yaml, ele não é usado da mesma forma que o app.yaml. O service.yaml do Cloud Run não pode ser usado na implantação a partir da origem, já que um dos elementos necessários é o caminho para a imagem final do contêiner. 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 arquivos de configuração no estilo do Kubernetes. Para mais informações sobre como usar o service.yaml para gerenciar a configuração, consulte a documentação do Cloud Run.

Para clientes do App Engine que estão começando a usar o Cloud Run, o uso dos flags de implantação da CLI gcloud se alinha muito mais com o gerenciamento de configuração na implantação do App Engine.

Para definir a configuração ao implantar um novo código no Cloud Run, use os flags gcloud run deploy:

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

Embora não seja necessário usar as sinalizações de configuração em cada implantação (consulte Como gerenciar configurações), é possível fazer isso para simplificar o gerenciamento de configuração.

No Cloud Run, também é possível atualizar a configuração sem reimplantar o código-fonte usando 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 criará uma nova revisão com a configuração atualizada, mas usará a mesma imagem do contêiner que a revisão existente.

Como gerenciar configurações

Para implantações do App Engine, todas as configurações precisam ser fornecidas para todas as implantações. As configurações não fornecidas são valores padrão atribuídos. Por exemplo, considere o service-a do App Engine, com versões usando os arquivos app.yaml mostrados abaixo:

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 .. ..

A version1 é configurada com instance_class: F4, enquanto a version2, que não fornece valor para instance_class, é configurada com a instance_class: F1 padrão.

No Cloud Run, todas as configurações fornecidas são aplicadas, mas as que não são mantém os valores atuais. Você só precisa fornecer os valores das configurações que quer alterar. Exemplo:

Cloud Run service-a revision1	Cloud Run service-a revision2
Comando de implantaçã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 implantação sem configurações cria uma versão usando todas as configurações padrão. No Cloud Run, a implantação sem definições de configuração cria uma revisão usando as mesmas definições da configuração anterior. Na primeira revisão de um serviço do Cloud Run, a implantação sem definições de configuração cria uma revisão usando todas as configurações padrão.

Padrões de configuração

Configuração	Ambiente padrão do App Engine	Ambiente flexível do App Engine	Cloud Run
Recursos de computação	F1	1 vCPU, .6 GB	1 vCPU, 512 MB
Simultaneidade máxima (solicitações)	10	Nenhuma	80
Tempo limite da solicitação	Escalonamento automático: 10 minutos Escalonamento manual/básico: 24 horas	60 minutos	5 minutos
Meta de utilização da CPU	60%	50%	60%
Número máximo de instâncias	Nenhuma	20	100
Número mínimo de instâncias	0	2	0

Ponto de entrada

Durante a implantação a partir da origem, o App Engine lê o comando entrypoint do atributo entrypoint no app.yaml. Se nenhum ponto de entrada for fornecido, um padrão específico do tempo de execução será usado. O Cloud Run usa os pacotes de criação do Google Cloud ao implantar a partir da origem, e algumas linguagens não têm um ponto de entrada padrão, o que significa que você precisa fornecer um ou a compilação falhará. Por exemplo, os buildpacks de Python exigem um Procfile ou especificam a variável de ambiente de build GOOGLE_ENTRYPOINT.

Consulte a documentação dos buildpacks para acessar os requisitos de configuração específicos da linguagem.

Escalonamento

O Cloud Run e o ambiente padrão do App Engine compartilham grande parte da mesma infraestrutura de escalonamento, mas o Cloud Run foi simplificado para permitir um escalonamento muito mais rápido. Como parte desse processo, as configurações configuráveis são limitadas a:

Simultaneidade máxima
Instâncias máxima e mínima

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

O ambiente flexível do App Engine usa o autoescalador do Compute Engine. Portanto, ele tem características de escalonamento muito diferentes do ambiente padrão do App Engine e do Cloud Run.

Tempo limite da instância inativa

No App Engine, as instâncias ociosas permanecem ativas por até 15 minutos após a conclusão do processamento da última solicitação. O Cloud Run permite que você configure esse comportamento usando a alocação de CPU. Para ter o mesmo comportamento do App Engine, defina a alocação de CPU como CPU sempre alocada. Como alternativa, use a CPU alocada somente durante o processamento da solicitação para que as instâncias ociosas sejam encerradas imediatamente (se não houver solicitações pendentes).

Solicitações de aquecimento

O Cloud Run aquece automaticamente as instâncias usando o comando do ponto de entrada do contêiner, para que você não precise ativar as solicitações de aquecimento manualmente nem configurar um gerenciador /_ah/warmup. Se você tiver um código que queira executar na inicialização da instância, antes que qualquer solicitação seja processada, é possível:

Conteúdo estático

No ambiente padrão do App Engine, é possível exibir conteúdo estático sem usar recursos de computação. Basta exibir no Cloud Storage ou configurar gerenciadores. O Cloud Run não tem a opção de gerenciadores para exibir conteúdo estático. Portanto, é possível exibir o conteúdo do serviço do Cloud Run (igual ao conteúdo dinâmico) ou do Cloud Storage.

Papel de invocador do Cloud Run

O Cloud Run também oferece a capacidade de controlar o acesso a um serviço com Identity and Access Management (IAM). As vinculações de política do IAM para um serviço podem ser definidas com a CLI gcloud, o console ou o Terraform.

Para replicar o comportamento do App Engine, torne o serviço público permitindo solicitações não autenticadas. Isso pode ser definido na implantação ou ao atualizar as vinculações de política do IAM em um Serviço atual.

Implantação

Use o flag de implantação --allow-unauthenticated:

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

Serviço atual

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.

Também é possível controlar quem tem acesso ao serviço concedendo o papel de invocador do Cloud Run do IAM, que pode ser configurado por serviço.

Implantaçã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"

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

Confira uma lista de valores aceitáveis para MEMBER_TYPE na página de conceitos do IAM.

Serviço atual

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

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

Confira uma lista de valores aceitáveis para MEMBER_TYPE na página de conceitos do IAM.

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 abaixo mostra as variáveis de ambiente do App Engine com os 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 do servidor de metadados são equivalentes.

Variáveis de ambiente padrão

Nome do App Engine	Nome do Cloud Run	Descrição
`GAE_SERVICE`	`K_SERVICE`	O nome do serviço atual. No App Engine, é definido como "default", se não for especificado.
`GAE_VERSION`	`K_REVISION`	O rótulo da versão atual do serviço.
`PORT`	`PORT`	A porta que recebe solicitações HTTP.
N/A	`K_CONFIGURATION`	O nome da configuração do Cloud Run que criou a revisão.
`GOOGLE_CLOUD_PROJECT`	N/A	O código do projeto do Cloud associado ao aplicativo.
`GAE_APPLICATION`		O ID do aplicativo do App Engine. Esse ID é prefixado com 'código de região~', como 'e~', para aplicativos implantados na Europa.
`GAE_DEPLOYMENT_ID`		O ID da implantaçã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 em que o serviço é executado no momento.
`GAE_MEMORY_MB`		A quantidade de memória disponível para o processo do aplicativo em MB.
`NODE_ENV` (disponível apenas no ambiente de execução do Node.js)		Definido como production quando o serviço é implantado.
`GAE_RUNTIME`		O ambiente de execução especificado no arquivo app.yaml.

Caminhos comuns do servidor de metadados

Caminho	Descrição	Exemplo
`/computeMetadata/v1/project/project-id`	ID do projeto do projeto a que o serviço pertence	test_project
`/computeMetadata/v1/project/numeric-project-id`	Número do projeto do projeto a que o serviço pertence	12345678912
`/computeMetadata/v1/instance/id`	Identificador exclusivo da instância do contêiner (também disponível em logs).	16a61494692b7432806a16 (string de caracteres alfanuméricos)
`/computeMetadata/v1/instance/region` ** Não disponível para o ambiente flexível do App Engine	Região desse serviço retorna `projects/PROJECT_NUMBER/regions/REGION`	projects/12345678912/regions/us-central1
`/computeMetadata/v1/instance/service-accounts/default/email`	E-mail da conta de serviço do ambiente de execução deste serviço.	service_account@test_project.iam.gserviceaccount.com
`/computeMetadata/v1/instance/service-accounts/default/token`	Gera um token de acesso OAuth2 para a conta de serviço deste serviço. Esse endpoint retornará uma resposta JSON com um atributo `access_token`.	{ "access_token":"<TOKEN>", "expires_in":1799, "token_type":"Bearer" }

A seguir

Guia de início rápido: implantar um serviço da Web com o Cloud Run
Meu app é adequado para o Cloud Run?
Migrar meu domínio personalizado do App Engine para o Cloud Load Balancing
Outros recursos:
- Migrar do App Engine para o Cloud Run com o Docker (Python: codelab, video, Java: codelab)
- Migrar do App Engine para o Cloud Run com buildpacks (Python: codelab, video, Java: codelab)