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
|
|
|||||||||||||||||||
| URL da versão/revisão |
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
|
|||||||||||||||||||
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 |
|
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 |
|
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 |
|
|
||||||||||||||||||
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
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
defaultcorrespondente. - 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, ondeREVISION_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.appehttps://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: |
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 |
|
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:
- Simultaneidade máxima
- Instâncias máximas e mínimas
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?
- 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: