Implantar um serviço ou job do Cloud Run

Neste documento, descrevemos como implantar seus aplicativos, incluindo os serviços e os jobs do Cloud Run.

O Cloud Deploy permite implantar cargas de trabalho baseadas em contêiner em qualquer serviço do Cloud Run ou job. Todos os recursos do Cloud Deploy são compatíveis quando você implanta em destinos do Cloud Run para serviços do Cloud Run, mas as implantações canário não são compatíveis para jobs do Cloud Run.

Neste documento, descrevemos as três configurações principais que você precisa concluir para implantar no Cloud Run:

Limitações

  • Só é possível implantar um serviço ou job do Cloud Run por destino.

  • Não é possível executar uma implantação canário em um job do Cloud Run.

    No entanto, os serviços do Cloud Run podem usar uma implantação canário.

Antes de começar

Criar a configuração de destino

O destino pode ser configurado no YAML do pipeline de entrega ou pode estar em um arquivo separado. Além disso, é possível configurar mais de um destino no mesmo arquivo.

Na definição do destino, crie uma estrofe run para identificar o local em que o serviço do Cloud Run será criado.

A sintaxe para especificar o serviço ou job do Cloud Run na definição de destino é a seguinte:

run:
 location: projects/[project_name]/locations/[region_name]

Esse identificador de recurso usa os seguintes elementos:

  • [project_name] é o nome do projeto do Google Cloud em que o serviço ou job do Cloud Run será criado.

    Você vai fazer isso para cada destino. Recomendamos um projeto diferente para cada serviço ou job do Cloud Run. Se você quiser mais de um serviço ou job no mesmo projeto, precisará usar perfis do Skaffold (em inglês) no arquivo de configuração skaffold.yaml.

  • [region_name] é a região em que o serviço ou job será criado. O serviço ou job pode estar em qualquer região compatível com o Cloud Run.

Este é um exemplo de configuração de destino que define o serviço ou job do Cloud Run a ser criado:

      apiVersion: deploy.cloud.google.com/v1
      kind: Target
      metadata:
       name: dev
      description: development service
      run:
       location: projects/my-app/locations/us-central1

É possível definir esse destino dentro de uma definição de pipeline de entrega do Cloud Deploy ou separadamente. De qualquer forma, é necessário registrar o destino antes de criar a versão para implantar o serviço ou job do Cloud Run.

Criar a configuração do Skaffold

Veja a seguir um exemplo de arquivo skaffold.yaml para uma implantação do Cloud Run:

apiVersion: skaffold/v4beta7
kind: Config
metadata:
  name: cloud-run-application
manifests:
  rawYaml:
  - service.yaml
deploy:
  cloudrun: {}

Neste arquivo skaffold.yaml...

  • manifests.rawYaml fornece os nomes das definições de serviço do Cloud Run.

    Neste exemplo, service.yaml é o arquivo que define um serviço do Cloud Run que o Skaffold implantará. Esse nome de arquivo pode ser qualquer coisa, mas, por convenção, é service.yaml para um serviço e job.yaml para um job.

  • A estrofe deploy especifica como você quer que o manifesto seja implantado, especificamente, o projeto e o local. deploy é obrigatório.

    Recomendamos que você deixe o campo {} em branco. O Cloud Deploy preenche esse campo durante a renderização, com base no projeto e no local da definição de destino.

    Para desenvolvimento local, no entanto, você pode fornecer valores aqui. No entanto, o Cloud Deploy sempre usa o projeto e o local da definição de destino, independentemente de os valores serem fornecidos aqui.

Criar definições de serviço do Cloud Run

Para criar uma definição de serviço do Cloud Run, crie uma manualmente ou copie uma de um serviço atual. Ambas estão descritas nesta seção.

Opção 1: criar um novo service.yaml do Cloud Run

O service.yaml define o serviço do Cloud Run. Quando você cria uma versão, o Skaffold usa essa definição para implantar seu serviço.

Veja um exemplo simplificado:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: [SERVICE_NAME]
spec:
 template:
  spec:
   containers:
   - image: [IMAGE_PATH]

Em que:

  • [SERVICE_NAME] é um nome para este serviço do Cloud Run.

  • [IMAGE_PATH] aponta para a imagem ou as imagens de contêiner que você está implantando com esse serviço.

Opção 2: copiar um service.yaml de um serviço atual usando o console do Google Cloud

É possível criar um serviço usando o console do Google Cloud ou usar um atual e copiar seu service.yaml nele.

Para acessar o service.yaml usando a Google Cloud CLI:

gcloud run services describe [service_name] --format=export

Para acessar o service.yaml no console do Google Cloud:

  1. No console do Google Cloud, acesse a página "Serviços do Cloud Run".

  2. Selecione o serviço que tem a definição que você quer usar.

Também é possível criar um novo código e selecionar essa opção. Quando você seleciona o serviço, a página "Detalhes do serviço" é exibida:

página de detalhes do serviço Console do Google Cloud, mostrando a guia YAML

  1. Selecione a guia YAML.

  2. Clique em Edit e copie o conteúdo do YAML em um novo arquivo chamado service.yaml no sistema de arquivos para que o Skaffold possa usá-lo ao criar uma versão.

crie as definições do job do Cloud Run

Para implantar uma definição de job do Cloud Run, crie uma manualmente ou copie-a de um job atual. Ambas estão descritas nesta seção.

Os jobs não são necessariamente executados ao serem implantados pelo Cloud Deploy. Isso é diferente dos serviços, que executam aplicativos depois de implantados. A forma como um job é invocado depende do job.

Opção 1: criar um novo job.yaml do Cloud Run

O job.yaml define o job do Cloud Run. Quando você cria uma versão, o Skaffold usa essa definição para implantar o job.

Veja um exemplo simplificado:

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
 name: [JOB_NAME]
spec:
  template:
  spec:
   containers:
   - image: [IMAGE_PATH]

Em que:

  • [JOB_NAME] é um nome para este job do Cloud Run.

  • [IMAGE_PATH] aponta para a imagem do contêiner que você está implantando para esse job.

Opção 2: copiar um job.yaml de um job atual usando o console do Google Cloud

É possível criar um job usando o console do Google Cloud ou usar um atual e copiar o job.yaml dele.

Para acessar o job.yaml usando a Google Cloud CLI:

gcloud run jobs describe [job_name] --format=export

Para acessar o job.yaml no console do Google Cloud:

  1. No console do Google Cloud, acesse a página "Jobs do Cloud Run".

  2. Selecione o job com a definição que você quer usar.

Também é possível criar um novo código e selecionar essa opção. Quando você seleciona o job, a página "Detalhes do job" é exibida:

Página de detalhes do job Console do Google Cloud, mostrando a guia YAML

  1. Selecione a guia YAML.

  2. Clique em Edit e copie o conteúdo do YAML em um novo arquivo chamado job.yaml no sistema de arquivos para que o Skaffold possa usá-lo ao criar uma versão.

Como tudo funciona em conjunto

Agora que você tem o serviço ou a definição do job do Cloud Run, a configuração skaffold.yaml e a definição de destino do Cloud Deploy e você registrou o destino como um recurso do Cloud Deploy, é possível invocar o pipeline de entrega para criar uma versão e avançar pela progressão dos destinos definidos no pipeline.

O guia de início rápido Implantar um app no Cloud Run usando o Cloud Deploy mostra tudo isso em ação.

Comportamento dos serviços em todas as revisões

Quando você reimplanta um serviço, a nova revisão é baseada no service.yaml recém-implantado. Nada sobre a revisão anterior é mantido, a menos que seja o mesmo no YAML recém-implantado. Por exemplo, se houver definições de configuração ou rótulos na revisão anterior que não estão no novo YAML, essas configurações ou rótulos estarão ausentes na nova revisão.

Como implantar jobs e serviços do Cloud Run em vários projetos

Se for preciso implantar serviços ou jobs em projetos diferentes, a conta de serviço de execução precisará de permissão para acessar os projetos em que esses serviços ou jobs estão definidos.

Para mais informações, consulte a conta de serviço de execução do Cloud Deploy e os papéis e permissões do Identity and Access Management.

A seguir