Compare o App Engine e o Cloud Run

Este guia apresenta o Cloud Run para utilizadores que conhecem 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.

Modelo de recurso

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 do Knative e pode ser difícil de ler para quem não está familiarizado com os ficheiros de configuração no estilo do 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:

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a

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:

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a

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

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.

Verificações de funcionamento

No App Engine, as verificações de estado são em grande parte automáticas e geridas pela plataforma. O App Engine realiza verificações de atividade e disponibilidade para determinar se uma instância está operacional e pronta para publicar tráfego. Se uma instância falhar consistentemente nas verificações automáticas, o App Engine termina a instância e substitui-a por uma nova para garantir a continuidade do serviço.

O Cloud Run oferece um controlo mais detalhado com sondas de inicialização e de atividade configuráveis. Estas sondas permitem-lhe definir uma instância saudável, o que é fundamental para microsserviços complexos.

No Cloud Run, pode configurar as seguintes sondas:

• Sondagem de arranque para definir quando um contentor foi iniciado e está pronto para publicar tráfego. Quando configura uma sondagem de arranque, esta desativa as verificações de atividade até o arranque ser bem-sucedido, garantindo que as sondagens de atividade não interferem com o arranque da aplicação.

• Sonda de atividade para determinar quando reiniciar um contentor. Por exemplo, as sondas de atividade podem detetar um impasse quando uma aplicação está em execução, mas não consegue progredir. O reinício de um contentor nesse estado garante que a sua aplicação está disponível apesar dos erros.

Para mais informações, consulte o artigo Configure verificações de estado do contentor para serviços.

Dimensionar

Embora o Cloud Run e o ambiente padrão do App Engine partilhem uma infraestrutura de escalabilidade semelhante, o Cloud Run está otimizado para uma escalabilidade mais rápida e capacidades de escalabilidade até zero. Isto resulta em menos definições configuráveis. Esta simplificação limita as definições configuráveis a:

• Simultaneidade máxima
• Máximo e mínimo de instâncias

Para instâncias do Cloud Run, a utilização da CPU alvo não é configurável. É fixa em 60%. Para mais detalhes, consulte o artigo Acerca do dimensionamento automático de instâncias nos serviços do Cloud Run.

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

Migre os controlos de escalabilidade do App Engine para o Cloud Run

Esta secção descreve como mapear a configuração de escalabilidade do App Engine existente para o Cloud Run.

Instâncias mínimas (aquecimento)

Mantenha um número mínimo de instâncias ativas para processar o tráfego de base e evitar inícios a frio.

Estratégia de migração: defina o número mínimo de instâncias para o aquecimento ao nível do serviço. Se direcionar tráfego para uma revisão específica, a definição ao nível da revisão substitui a predefinição ao nível do serviço. Use esta definição para testar uma nova revisão com uma contagem mínima de instâncias diferente antes de a promover para produção.

Máximo de instâncias

Defina um limite máximo para o número total de instâncias para controlar os custos e proteger as dependências a jusante.

Estratégia de migração: defina um limite global ao nível do serviço. O Cloud Run aplica as definições de nível de serviço e de nível de revisão mais baixas. Para mais informações, consulte o artigo Defina o número máximo de instâncias para serviços.

Simultaneidade

Defina a capacidade de pedido de uma única instância.

Estratégia de migração: siga uma de duas estratégias de migração:

• Comece com a capacidade predefinida da instância do Cloud Run de 80 e faça testes de carga para encontrar o limite de concorrência estável para a sua aplicação no Cloud Run. Ajustar este valor é uma forma eficaz de otimizar o desempenho e o custo no Cloud Run. Ajuste o valor para baixo a partir de 80 com base nos resultados dos testes. Para mais informações, consulte o artigo Defina o número máximo de pedidos simultâneos por instância.

• Use o valor de configuração existente no ambiente padrão do App Engine, que é um valor predefinido de 10 pedidos simultâneos por instância. Esta é uma opção segura, porque é uma configuração conhecida e funcional para a sua aplicação. No entanto, isto pode levar a uma subutilização significativa das suas instâncias do Cloud Run e a custos potencialmente mais elevados, uma vez que o escalador automático cria mais instâncias do que o necessário para processar a carga.

Utilização da CPU

Aumente a escala quando a carga da CPU exceder um determinado limite.

Estratégia de migração: não pode configurar este valor. O escalador automático do Cloud Run mantém uma utilização da CPU de ~60% nas instâncias ativas. Ao contrário do App Engine, o Cloud Run só atribui CPU durante o processamento de pedidos e limita a zero caso contrário. No ambiente padrão do App Engine, independentemente do tipo de escalabilidade que configurar, o App Engine garante que a CPU está disponível continuamente para a sua instância.

Se a sua aplicação realizar qualquer trabalho em segundo plano entre pedidos, como usar threads em segundo plano no escalonamento básico ou manual, configure a faturação baseada em instâncias no Cloud Run para evitar a suspensão das suas tarefas de processamento em segundo plano.

Débito do pedido

Escale com base no débito de pedidos quando a sua aplicação atingir o limite de concorrência.

Estratégia de migração: o escalador automático do Cloud Run tenta manter o número de pedidos simultâneos por instância a 60% do valor maxInstanceRequestConcurrency. Quando define este valor, define implicitamente o débito alvo que aciona um evento de expansão.

Latência

Defina um período de tempo de espera do utilizador que aciona o dimensionamento. O App Engine é parcialmente reativo ao enfileiramento de pedidos.

Estratégia de migração: o Cloud Run é dimensionado automaticamente antes de os pedidos começarem a entrar em fila e de haver picos de latência. Se ocorrerem picos de latência, pondere ajustar o valor de template.maxInstanceRequestConcurrency para garantir uma expansão mais rápida.

Instâncias inativas

Objetivo: no App Engine, as definições de instâncias inativas controlam um conjunto de instâncias inativas pré-aquecidas que absorvem picos de tráfego e controlam os custos.

Estratégia de migração: não pode configurar um número mínimo ou máximo separado de instâncias inativas no Cloud Run. Para manter as instâncias ativas e prontas para tráfego imediato e mitigar inícios a frio no Cloud Run, use a definição scaling.min_instance_count, que garante que um número mínimo especificado de contentores está sempre em execução. Para mais informações, consulte o artigo Acerca do dimensionamento automático de instâncias nos serviços do Cloud Run.

Limite de tempo de inatividade da instância

No App Engine, as instâncias inativas permanecem ativas durante aproximadamente 15 minutos após o último pedido. O Cloud Run controla este comportamento através da respetiva definição de faturação.

Para alcançar um comportamento de faturação semelhante ao do App Engine, em que a CPU é alocada fora do processamento de pedidos, use a faturação baseada em instâncias no Cloud Run.

Em alternativa, use a faturação baseada em pedidos para ter a CPU alocada apenas durante o processamento de pedidos. Com esta definição, a instância permanece ativa durante um máximo de 15 minutos após o último pedido, mas a CPU é limitada durante esse período de inatividade.

Dimensionamento básico

Quando configura a definição basic_scaling no ambiente padrão do App Engine, são criadas instâncias quando recebe pedidos e a escala é reduzida a zero após um período de inatividade. Pode replicar este comportamento no Cloud Run usando o escalamento automático definindo min-instances como 0.

Escala manual

Executar um número fixo de instâncias e desativar o dimensionamento automático.

Estratégia de migração: existe um mapeamento direto no Cloud Run para o escalamento manual. Defina o modo de escalabilidade como MANUAL ao nível do serviço no Cloud Run e especifique o número exato de instâncias a executar através de manualInstanceCount. Isto tem o mesmo efeito que desativar completamente o ajuste automático de escala. Para mais informações, consulte o artigo Dimensionamento manual no Cloud Run.

Período de repouso

Configurar um período de repouso após um evento de expansão antes de ocorrer outro evento.

Estratégia de migração: não é necessária. O Cloud Run cria uma escala automática com base na procura e na utilização, e foi concebido para reagir de forma eficiente sem uma configuração manual do período de repouso.

Pedidos de aquecimento

O Cloud Run aquece automaticamente as instâncias através do comando entrypoint 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:

• Configure a sua app para ouvir pedidos
• Configure uma sondagem de arranque personalizada

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.

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

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

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.

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

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

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

Caminhos comuns do servidor de metadados

O que se segue?

• Início rápido: implemente um serviço Web com o Cloud Run
• A minha app é adequada para o Cloud Run?
• Migre o meu domínio personalizado do App Engine para o Cloud Load Balancing
• Outros recursos:
  • Migre do App Engine para o Cloud Run com o Docker (Python: codelab, vídeo, Java: codelab)
  • Migre do App Engine para o Cloud Run com buildpacks (Python: codelab, vídeo, Java: codelab)