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.
Informações gerais
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
|
|
|||||||||||||||||||
| URL da versão/revisão |
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
|
|||||||||||||||||||
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 |
|
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 |
|
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
defaultcorrespondente. - 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 queREVISION_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.appehttps://SERVICE_NAME-PROJECT_NUMBER.REGION.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: |
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. Por 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 | Nenhum | 80 |
| Tempo limite da solicitação |
|
60 minutos | 5 minutos |
| Meta de utilização da CPU | 60% | 50% | 60% |
| Número máximo de instâncias | Nenhum | 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:
- Configurar seu app para detectar solicitações
- Configurar uma sondagem de inicialização personalizada
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: