Implantar imagens de contêiner
O Cloud Run oferece várias opções de implantação. Todas as opções de implantação resultam em uma imagem de contêiner executada como um serviço, job ou pool de workers do Cloud Run na infraestrutura totalmente gerenciada e altamente escalonável do Cloud Run.
Imagens de contêiner implantáveis
É possível implantar qualquer imagem de contêiner que siga o contrato de ambiente de execução de contêiner do Cloud Run em um serviço, job ou pool de trabalhadores do Cloud Run.
Implantar a partir do código-fonte
Para sua conveniência, o Cloud Run permite criar e implantar o código-fonte com um único comando. Consulte Como implantar serviços do código-fonte e Como implantar pools de trabalhadores do código-fonte para mais detalhes.
Ao implantar do código-fonte, o Cloud Build transforma o código em uma imagem de contêiner
armazenada no Artifact Registry. É possível implantar código-fonte que inclui um Dockerfile ou que usa um dos
ambientes de execução de linguagem com suporte.
Funções
É possível implantar funções com uma única finalidade que respondem a eventos emitidos pelos serviços e pela infraestrutura em nuvem. O Cloud Run aciona sua função quando um evento monitorado é disparado.
Uma implantação de funções é um tipo especial de implantação de código-fonte, em que você só precisa fornecer o código da função. É possível escrever funções do Cloud Run usando várias linguagens de programação compatíveis.
A implantação de uma função cria um serviço do Cloud Run.
Implantação contínua de código-fonte do git
O Cloud Run ajuda a configurar a implantação contínua do Git.
Assim como nas implantações de origem, é possível implantar código-fonte que inclui um
Dockerfile ou que foi gravado em um dos ambientes de execução de linguagem compatíveis.
A implantação contínua do Git está disponível para serviços do Cloud Run. É possível configurar manualmente no Cloud Build para jobs do Cloud Run.
Serviços do Cloud Run
Os serviços são um dos principais recursos do Cloud Run. Cada serviço está localizado em uma regiãoGoogle Cloud específica. Para oferecer redundância e failover, o Cloud Run replica automaticamente serviços em várias zonas de uma região. Um determinado Google Cloud projeto pode executar muitos serviços em diferentes regiões.
Cada serviço expõe um endpoint exclusivo. Por padrão, o Cloud Run escalona automaticamente para processar as solicitações recebidas. Se necessário, você pode mudar o comportamento de escalonamento para escalonamento manual. É possível implantar um serviço de um contêiner, repositório ou código-fonte.
O diagrama a seguir mostra o modelo de recursos do Cloud Run para serviços:
O diagrama mostra um projeto Google Cloud com três serviços do Cloud Run (Serviço A, Serviço B e Serviço C), cada um com várias revisões:
O serviço A está recebendo várias solicitações, então o Cloud Run iniciou várias instâncias para processar a carga. Cada uma dessas instâncias executa apenas um contêiner (o contêiner do aplicativo).
O serviço B não tem solicitações, então está inativo, e o Cloud Run não está executando nenhuma cópia do aplicativo dele.
O serviço C tem solicitações e foi escalonado para processar a carga criando várias instâncias. Cada instância contém vários contêineres e funciona como um conjunto independente. Em cada conjunto, apenas o contêiner de entrada recebe a solicitação, mas os outros contêineres ajudam a atender a ela.
Revisões de serviço do Cloud Run
Cada implantação em um serviço cria uma revisão. Uma revisão consiste em uma ou mais imagens de contêiner, além de configurações, como variáveis de ambiente, limites de memória ou valor de simultaneidade de solicitação.
Não é possível modificar uma revisão depois da criação. Por exemplo, quando você implanta uma imagem de contêiner em um novo serviço, o Cloud Run cria a primeira revisão. Se você implantar uma imagem de contêiner diferente no mesmo serviço, o Cloud Run vai criar uma segunda revisão. Se você definir uma variável de ambiente depois, o Cloud Run vai criar uma terceira revisão. Com o tempo, o Cloud Run remove revisões mais antigas e não utilizadas.
O Cloud Run encaminha automaticamente as solicitações o quanto antes para a última revisão de serviço íntegra.
Instâncias de serviço do Cloud Run
O Cloud Run escalona automaticamente cada revisão de serviço que recebe solicitações para o número de instâncias necessárias para lidar com todas essas solicitações. As instâncias podem receber muitas solicitações ao mesmo tempo. Com a configuração de simultaneidade de solicitações, é possível definir o número máximo de solicitações que podem ser enviadas em paralelo a cada instância de uma revisão.
Jobs do Cloud Run
Cada job está localizado em uma Google Cloud região específica e consiste em uma ou mais tarefas que são executadas para rodar um ou mais contêineres até a conclusão. As tarefas de job são independentes e podem ser executadas em paralelo em uma determinada execução de job.
Execuções de job do Cloud Run
Quando um job é executado, uma execução de job é criada e todas as tarefas são iniciadas. Todas as tarefas em uma execução de job precisam ser concluídas com êxito para que a execução seja bem-sucedida. É possível definir tempos limite em tarefas e especificar o número de novas tentativas em caso de falha de tarefas.
Se uma tarefa exceder o número máximo de novas tentativas, o Cloud Run vai marcar essa tarefa e o job como falhas. Por padrão, as tarefas são executadas em paralelo até um máximo de 100, mas você pode especificar um máximo menor se algum dos recursos de apoio, como um banco de dados, exigir.
Tarefas de job do Cloud Run
Cada execução de job executa várias tarefas em paralelo, e cada tarefa executa uma instância. O Cloud Run tenta executar automaticamente as tarefas com falha novamente, dependendo da configuração do job para maxRetries.
Pools de workers do Cloud Run
Os pools de workers são um recurso do Cloud Run projetado especificamente para cargas de trabalho sem solicitação, como filas de extração. Os pools de workers não têm os seguintes recursos:
- Nenhum endpoint/URL
- Não há necessidade de o contêiner implantado detectar solicitações em uma porta.
- Sem escalonamento automático
Assim como um serviço do Cloud Run, a implantação ou atualização de um pool de workers cria uma nova revisão.
As instâncias do pool de workers podem ser escalonadas manualmente conforme necessário para escalonar instâncias suficientes para as cargas de trabalho. No entanto, é possível criar seu próprio autoescalador, se necessário. Um exemplo disso é o escalonador automático do Kafka, que processa o escalonamento de cargas de trabalho provenientes da fila de mensagens do Kafka.