Crea pasos de compilación personalizados

Cuando escribes tus configuraciones de compilación, puedes usar los pasos de compilación compatibles y de código abierto proporcionados por Cloud Build o puedes definir tus propios pasos de compilación personalizados.

Un paso de compilación personalizado es una imagen de contenedor que la VM de trabajador de Cloud Build extrae y ejecuta con tu fuente activada por volumen en /workspace. El paso de compilación personalizado puede ejecutar cualquier secuencia de comandos o binario dentro del contenedor. Como tal, puede hacer todo lo que hace un contenedor.

Los pasos de compilación personalizados son útiles para lo siguiente:

  • Descargar código fuente o paquetes de ubicaciones externas
  • Usar de una cadena de herramientas externa
  • Almacenar en caché cualquier biblioteca necesaria
  • Compilar una fuente previamente (con Cloud Build responsable solo si se debe empaquetar la compilación en una imagen de contenedor)

Un paso de compilación personalizado se ejecuta con la fuente activa en /workspace y con un directorio de trabajo en algún lugar de /workspace. Todos los archivos que quedan en /workspace por cierto paso de compilación están disponibles para otros pasos de compilación, sin importar si esos pasos se ejecutan en simultáneo o con posterioridad.

Tu paso de compilación personalizado puede enviar o extraer del repositorio de Container Registry de Google (alojado en gcr.io/$PROJECT-NAME/) al que tiene acceso tu cuenta de servicio de compilador. Las credenciales de la herramienta de línea de comandos docker no son suficientes para proporcionar acceso autenticado a Docker Hub.

En esta guía, se explica cómo crear un paso de compilación personalizado que ejecuta una secuencia de comandos de shell. Puedes crear un “ejecutor de secuencias de comandos de shell” como un paso de compilación personalizado para ejecutar una secuencia de comandos de shell desde algún lugar de tu fuente de compilación.

Crea un paso de compilación personalizado

Para crear un paso de compilación personalizado, puedes crear un archivo de configuración de compilación que compile y envíe la imagen de paso de compilación a un registro de imagen, como Container Registry, al que tenga acceso la cuenta de servicio de compilador. De forma alternativa, puedes usar otra herramienta para compilar la imagen de paso de compilación personalizado y, luego, almacenarla en un registro de imagen. Una vez que esto termina, puedes invocar a tu paso de compilación personalizado en compilaciones futuras.

Acerca del campo entrypoint

El Dockerfile de tu imagen puede tener un campo ENTRYPOINT o CMD. ENTRYPOINT especifica el punto de entrada para usar con tu paso de compilación personalizado si el contenedor se ejecuta como un ejecutable. CMD proporciona configuración predeterminada para la ejecución y, si se omite ENTRYPOINT, debe incluir un ejecutable.

En una configuración de compilación, el campo opcional entrypoint define cómo se debe ejecutar el paso de compilación cuando se invoca. Por ejemplo, puedes especificar el comando principal que se debe llamar cuando se ejecuta el paso de compilación: el punto de entrada del paso de compilación de docker es "/usr/bin/docker". Cuando usas tu paso de compilación en una compilación posterior, puedes anular el Dockerfile ENTRYPOINT mediante la especificación de un entrypoint en esa compilación.

Si no especificas el campo entrypoint en el archivo de solicitud de compilación de tu paso de compilación y la imagen del paso de compilación no tiene un ENTRYPOINT especificado en su Dockerfile, el primer elemento en args se usa como el punto de entrada con los elementos restantes en args como argumentos.

Ejemplo: ejecuta una secuencia de comandos de shell de tu fuente

Para que un paso de compilación personalizado ejecute una secuencia de comandos de shell desde tu fuente, la imagen de contenedor del paso debe constar de una herramienta capaz de ejecutar la secuencia de comandos. Las imágenes base estándar como las imágenes de contenedor ubuntu, debian, alpine, y busybox pueden ejecutar secuencias de comandos; sin embargo, las imágenes alpine y busybox no vienen con bash instalado con anterioridad (y, por lo tanto, no pueden ejecutar secuencias de comandos bash), mientras que ubuntu y debian pueden.

Si una imagen contiene todas las herramientas (incluida la shell) que necesitas para ejecutar la secuencia de comandos, puedes usar la imagen como un paso de compilación directamente.

En este ejemplo, se usa una imagen ubuntu para ejecutar secuencias de comandos, ya que viene empaquetado con anterioridad con bash y es compatible con muchas de las herramientas para desarrolladores. La compilación crea imágenes basadas en alpine; esas imágenes son mucho más pequeñas y solo contienen lo que se necesita para el entorno de ejecución.

Aquí vemos un ejemplo de un archivo de configuración ./cloudbuild.yaml para el paso de compilación personalizado:

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']

El paso ejecuta la secuencia de comandos siguiente, llamada ./myscript.bash:

echo "Hello, world!" > file.txt

Aquí está el Dockerfile de ejemplo:

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

Para enviar la compilación que usa este paso de compilación personalizado, ejecuta el comando siguiente en tu shell o ventana 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!

La secuencia de comandos que ejecuta tu paso de compilación personalizado puede requerir más recursos que aquellos proporcionados en la imagen base alpine que se usa en este ejemplo. Si ese es el caso, puedes construir con anterioridad una imagen con los recursos necesarios mediante las directivas COPY en tu Dockerfile para traer recursos de tu espacio de trabajo a una imagen de contenedor.

Por ejemplo, supón que quieres ejecutar una secuencia de comandos que usa curl para desplegar un archivo que se incluya en la imagen de compilación. Dado que la imagen ubuntu no viene empaquetada con anterioridad con la herramienta de línea de comandos curl, haremos una imagen nueva con una imagen base ubuntu y curl con capas en la parte superior.

Aquí se muestra un archivo de configuración de ejemplo ./cloudbuild.yaml para una compilación que usa un paso de compilación personalizado ubuntu-curl:

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']

El Dockerfile.ubuntu-curl que instala la herramienta curl:

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

La secuencia de comandos ./curl.bash puede parecerse a la siguiente:

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

El ejemplo Dockerfile:

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

Para ejecutar el paso de compilación personalizado ubuntu-curl y, luego, compilar la imagen, ejecuta el comando siguiente en tu shell o ventana 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
...

Una vez que enviaste la imagen que creaste con Dockerfile.ubuntu-curl a un registro de Docker, puedes usar la imagen directamente como un paso de compilación.

# 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`>`

Puedes lograr lo mismo en una compilación si agregas un paso preliminar para compilar tu imagen de ejecutor de secuencias de comandos. Una vez que compilaste esa imagen, puedes usarla como paso siguiente en tu compilación. Eso te da la ventaja de mantener curl.bash limpio y realizar la mayor parte del trabajo en el servicio de Cloud Build.

Aquí se muestra un archivo de configuración de ejemplo ./cloudbuild.yaml con el paso preliminar agregado:

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']

Mientras dejes script-runner fuera del campo images en tu cloudbuild.yaml, el servicio de Cloud Build no tratará de enviarlo (fallaría en este ejemplo). En el contexto de la compilación, sin embargo, la imagen script-runner existirá en la caché de la imagen y se puede usar como un paso de compilación.

Pasos siguientes

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…