Como criar etapas personalizadas de versão

Ao gravar suas configurações de versão, use as etapas de versão de código aberto compatíveis fornecidas pelo Cloud Build ou defina suas próprias etapas personalizadas de versão.

Uma etapa personalizada de versão é uma imagem de contêiner que a VM de trabalho do Cloud Build extrai e executa com o volume do seu código-fonte montado em /workspace. Sua etapa personalizada de versão pode executar qualquer script ou binário dentro do contêiner. Ou seja, ela pode fazer tudo que um contêiner faz.

As etapas personalizadas de versão são úteis para:

  • fazer o download de código-fonte ou pacotes de locais externos;
  • usar uma cadeia de ferramentas externa;
  • armazenar as bibliotecas necessárias em cache;
  • pré-criar a fonte (deixando o Cloud Build responsável apenas por empacotar a versão em uma imagem de contêiner).

Uma etapa personalizada de versão é executada com a fonte ativada em /workspace e é executada com um diretório de trabalho em algum lugar no /workspace. Os arquivos criados em /workspace por uma etapa de versão estão disponíveis para outras etapas, sejam elas simultâneas ou posteriores.

Sua etapa personalizada de versão pode fazer envios ou extrações de qualquer repositório do Google Container Registry (hospedado em gcr.io/$PROJECT-NAME/) ao qual sua conta de serviço do criador tem acesso. As credenciais da ferramenta de linha de comando docker não são suficientes para conceder acesso autenticado ao Docker Hub.

Neste guia, explicamos como criar uma etapa de versão personalizada com um exemplo que o orienta sobre como criar uma etapa de versão que executa um script de shell. Você pode criar um "executor de script de shell" como uma etapa personalizada de versão para executar um script de shell de algum lugar na origem da sua versão.

Como criar uma etapa personalizada de versão

Para criar uma etapa personalizada de versão, gere um arquivo de configuração de versão que crie e envie a imagem da etapa de versão para um registro de imagem, como o Container Registry, ao qual a conta de serviço do criador tem acesso. Como alternativa, você pode usar outra ferramenta para criar a imagem de etapa personalizada de versão e, em seguida, armazená-la em um registro de imagem. Assim que isso for concluído, você pode invocar sua etapa personalizada de versão em versões futuras.

Sobre o campo entrypoint

O Dockerfile da sua imagem pode ter um campo ENTRYPOINT e/ou CMD. O ENTRYPOINT especificará o ponto de entrada a ser usado na sua etapa personalizada de versão caso o contêiner precise ser usado como executável. CMD fornece padrões para execução e, se ENTRYPOINT for omitido, deverá incluir um executável.

Em uma solicitação de versão, o campo opcional entrypoint define como a etapa de versão precisa ser executada quando é invocada. Por exemplo, você pode especificar o comando principal que deve ser chamado quando a etapa de versão é executada: o ponto de entrada da etapa de versão do docker é "/usr/bin/docker". Quando você usa sua etapa de versão em uma versão posterior, você pode substituir o ENTRYPOINT do Dockerfile especificando um entrypoint nessa versão.

Se você não especificar o campo entrypoint no arquivo de solicitação de versão e se a imagem da etapa de versão não tiver um ENTRYPOINT especificado no Dockerfile, o primeiro item em args será usado como ponto de entrada com os itens restantes no args como argumentos.

Exemplo: como executar um script de shell do seu código-fonte

Para que uma etapa personalizada de versão execute um script de shell do seu código-fonte, a imagem de contêiner da etapa precisa ter uma ferramenta capaz de executar o script. Imagens de base padrão, como imagens de contêiner ubuntu, debian, alpine e busybox, podem executar scripts. Já as imagens alpine e busybox não vêm com bash pré-instalado e, portanto, não podem executar scripts bash, enquanto que ubuntu e debian vêm.

Se uma imagem tiver todas as ferramentas (inclusive o shell) de que você precisa para executar seu script, você pode usar essa imagem diretamente como uma etapa de versão.

Este exemplo usa uma imagem ubuntu para executar scripts, pois é fornecida com bash e aceita várias ferramentas de desenvolvedor. A versão cria imagens com base em alpine. Essas imagens são muito menores e contêm apenas o necessário para o ambiente de tempo de execução.

Veja um exemplo de arquivo de configuração ./cloudbuild.yaml para a etapa personalizada da versão:

steps:
- name: 'ubuntu'
  args: ['bash', './myscript.bash']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/custom-script-test', '.']
images: ['gcr.io/$PROJECT_ID/custom-script-test']

A etapa executa o seguinte script, chamado ./myscript.bash:

echo "Hello, world!" > file.txt

Este é o exemplo de Dockerfile:

FROM alpine
COPY file.txt /file.txt
ENTRYPOINT ["cat", "/file.txt"]

Para enviar a versão que usa esta etapa personalizada de versão, execute o seguinte comando no seu shell ou janela de terminal:

$ gcloud builds submit --config cloudbuild.yaml .
...
$ gcloud docker -- pull gcr.io/<your-project-id>/custom-script-test
...
$ docker run gcr.io/<your-project-id>/custom-script-test
Hello, world!

O script executado pela sua etapa personalizada pode exigir mais recursos que os fornecidos na imagem de base alpine usada no exemplo. Se esse for o caso, você pode pré-criar uma imagem com os recursos necessários usando diretivas COPY no seu Dockerfile para trazer os recursos do seu local de trabalho para a imagem de contêiner.

Por exemplo, suponha que você quer executar um script que usa curl para solicitar um arquivo que deve ser incluído na imagem da versão. Como a imagem ubuntu não é fornecida com a ferramenta de linha de comando curl, criamos uma nova imagem com uma imagem de base ubuntu e incluímos curl nela.

Veja um exemplo de arquivo de configuração ./cloudbuild.yaml de uma versão que usa uma etapa ubuntu-curl personalizada:

steps:
- name: 'gcr.io/$PROJECT_ID/ubuntu-curl'
  args: ['bash', './curl.bash']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/custom-script-test2', '.']
images: ['gcr.io/$PROJECT_ID/custom-script-test2']

O Dockerfile.ubuntu-curl que instala a ferramenta curl:

FROM ubuntu
RUN apt-get -q update && apt-get install -qqy curl

O script ./curl.bash pode ter o seguinte formato:

#!/bin/bash
curl http://example.com > example.html

O exemplo de Dockerfile:

FROM alpine
COPY example.html /example.html
ENTRYPOINT ["cat", "/example.html"]

Para executar a etapa personalizada de versão para ubuntu-curl e criar a imagem, execute o seguinte comando no seu shell ou janela de terminal:

# First, build and push the `ubuntu-curl` custom build step.
$ docker build -f Dockerfile.ubuntu-curl -t gcr.io/your-project/ubuntu-curl .
...
$ gcloud docker -- push gcr.io/your-project/ubuntu-curl
...

Depois de enviar a imagem criada com Dockerfile.ubuntu-curl para um Docker Registry, você pode usá-la diretamente como uma etapa de versão.

# Then, use the custom `ubuntu-curl` build step in a new build.
$ gcloud builds submit --config cloudbuild.yaml .
...
$ gcloud docker -- pull gcr.io/your-project/custom-script-test2
...
$ docker run gcr.io/your-project/custom-script-test2
`<`contents of example.com source`>`

Você pode conseguir o mesmo resultado em uma versão se adicionar uma etapa preliminar para criar a imagem de executor do seu script. Depois de criar essa imagem, você pode usá-la como a próxima etapa da sua versão. Isso tem a vantagem de manter curl.bash limpo e realizar a maior parte do trabalho no serviço Cloud Build.

Veja um exemplo de arquivo de configuração ./cloudbuild.yaml com uma etapa preliminar:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-f', 'Dockerfile.ubuntu-curl', '-t', 'script-runner', '.']
- name: 'script-runner'
  args: ['bash', './curl.bash']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/custom-script-test2', '.']
images: ['gcr.io/$PROJECT_ID/custom-script-test2']

Se script-runner não for inserido no campo images no seu cloudbuild.yaml, o serviço do Cloud Build não tentará enviá-lo, o que causaria um erro nesse exemplo. Entretanto, no contexto da versão, a imagem script-runner existirá no cache de imagens e poderá ser usada como uma etapa de versão.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…