Benutzerdefinierte Build-Schritte erstellen

Wenn Sie Build-Konfigurationen erstellen, können Sie die unterstützten Open-Source-Build-Schritte verwenden, die von Cloud Build zur Verfügung gestellt werden, oder eigene benutzerdefinierte Build-Schritte festlegen.

Ein benutzerdefinierter Build-Schritt ist ein Container-Image, das von der Worker-VM von Cloud Build abgerufen und mit Ihrem, auf /workspace geladenen, Quellvolume ausgeführt wird. Ihr benutzerdefinierter Build-Schritt kann jedes Skript oder Binärprogramm innerhalb des Containers ausführen. Insofern kann der Schritt alles, was der Container kann.

Benutzerdefinierte Build-Schritte eignen sich für Folgendes:

  • Herunterladen von Quellcode oder Paketen von externen Speicherorten
  • Verwenden einer externen Toolchain
  • Caching aller notwendigen Bibliotheken
  • Vorbereiten einer Quelle, wobei die einzige Aufgabe von Cloud Build darin besteht, den Build in ein Container-Image zu verpacken

Benutzerdefinierte Build-Schritte werden mit der unter /workspace bereitgestellten Quelle und einem Arbeitsverzeichnis in /workspace ausgeführt. Alle Dateien, die von einem bestehenden Build-Schritt in /workspace hinterlassen wurden, stehen für andere Build-Schritte zur Verfügung, egal ob diese Schritte gleichzeitig oder nacheinander ausgeführt werden.

Mit einem benutzerdefinierten Build-Schritt können Sie Push- oder Pull-Übertragungen zum bzw. vom Repository der Google Container Registry vornehmen. Das Repository ist unter gcr.io/$PROJECT-NAME/ gehostet. Voraussetzung ist, dass Ihr Builder-Dienstkonto Zugriff auf das Repository hat. Die Anmeldedaten für das Befehlszeilentool docker reichen für den authentifizierten Zugriff auf Docker Hub nicht aus.

In dieser Anleitung wird erläutert, wie Sie einen benutzerdefinierten Build-Schritt erstellen. Sie enthält auch ein Beispiel für die Erstellung eines Build-Schritts, der ein Shell-Skript ausführt. Sie können ein "Shell-Skript-Ausführungsprogramm" als benutzerdefinierten Build-Schritt erstellen, um ein Shell-Skript innerhalb der Quelle Ihres Builds auszuführen.

Benutzerdefinierten Build-Schritt erstellen

Zum Erstellen eines benutzerdefinierten Build-Schritts generieren Sie eine Build-Konfigurationsdatei, die das Image des Build-Schritts erstellt und in eine Image-Registry (z. B. Container Registry) verschiebt, auf die das Builder-Dienstkonto zugreifen kann. Sie haben auch die Möglichkeit, das Image des benutzerdefinierten Build-Schritts mit einem anderen Tool zu erstellen und anschließend in einer Image-Registry zu speichern. Sie können dann den benutzerdefinierten Build-Schritt in zukünftigen Builds aufrufen.

Über das Feld entrypoint

Das Dockerfile des Images kann die Felder ENTRYPOINT und/oder CMD enthalten. ENTRYPOINT legt den Einstiegspunkt für den benutzerdefinierten Build-Schritt fest, wenn der Container als ausführbare Datei verwendet werden soll. Im Feld CMD sind Standardeinstellungen für die Ausführung angegeben. Wenn Sie ENTRYPOINT weglassen, sollte darin eine ausführbare Datei enthalten sein.

Mit dem optionalen Feld entrypoint definieren Sie in einer Build-Konfiguration, wie der Build-Schritt ausgeführt werden soll. Sie können beispielsweise den Hauptbefehl angeben, der bei der Ausführung des Build-Schritts aufgerufen werden soll. Der Einstiegspunkt des Build-Schritts docker lautet "/usr/bin/docker". Wenn Sie den Build-Schritt in einem späteren Build verwenden, können Sie den ENTRYPOINT des Dockerfile überschreiben. Geben Sie hierzu einen entrypoint für den Build an.

Wenn das Feld entrypoint in der Build-Anfragedatei des Build-Schritts nicht festgelegt und im Dockerfile für das Image des Build-Schritts kein ENTRYPOINT angegeben ist, wird als Einstiegspunkt das erste Element in args verwendet. Die restlichen Elemente in args dienen als Argumente.

Beispiel: Shell-Skript aus der Quelle ausführen

Damit ein benutzerdefinierter Build-Schritt ein Shell-Skript aus Ihrer Quelle ausführen kann, muss das Container-Image des Schritts ein Tool beinhalten, das zum Ausführen des Skripts in der Lage ist. Alle standardmäßigen Basis-Images wie ubuntu-, debian-, alpine- und busybox-Container-Images können Skripts ausführen, jedoch ist bei alpine- und busybox-Images bash nicht vorinstalliert. Deshalb können diese Images, im Gegensatz zu ubuntu- und debian-Images, bash-Skripts nicht ausführen.

Wenn ein Image alle Tools (einschließlich der Shell) enthält, die Sie zum Ausführen Ihres Skripts benötigen, können Sie dieses Image direkt als Build-Schritt verwenden.

In diesem Beispiel wird ein ubuntu-Image zum Ausführen von Skripts verwendet, da es bash bereits enthält und viele Entwicklertools unterstützt. Der Build selbst erstellt ein Image, das auf alpine basiert. Diese Images sind viel kleiner und beinhalten nur, was für die Laufzeitumgebung benötigt wird.

Hier ein Beispiel einer ./cloudbuild.yaml-Konfigurationsdatei für den benutzerdefinierten Build-Schritt:

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

Im Schritt wird das folgende Skript ausgeführt, das als ./myscript.bash bezeichnet wird:

echo "Hello, world!" > file.txt

Hier ist das Beispiel-Dockerfile:

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

Um den Build zu senden, der diesen benutzerdefinierten Build-Schritt verwendet, müssen Sie den folgenden Befehl in Ihrem Shell- oder Terminalfenster ausführen:

$ 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!

Es kann sein, dass das von Ihrem benutzerdefinierten Build-Schritt ausgeführte Skript mehr Ressourcen benötigt, als von dem in diesem Beispiel verwendeten alpine-basierten Image bereitgestellt werden. Sollte das der Fall sein, können Sie ein Image mit den notwendigen Ressourcen vorbereiten. Verwenden Sie dazu COPY-Anweisungen in Ihrem Dockerfile, um die Ressourcen aus dem Arbeitsplatz in Ihr Container-Image zu geben.

Beispiel: Sie möchten ein Skript ausführen, das mit curl eine Datei abruft, die im erstellten Image enthalten sein soll. Da das ubuntu-Image nicht von vornherein über das curl-Befehlszeilentool verfügt, erstellen wir ein neues Image mit einem auf ubuntu basierten Image und einer darübergelegten curl-Ebene.

Hier ist ein Beispiel für eine ./cloudbuild.yaml-Konfigurationsdatei für einen Build, der einen benutzerdefinierten ubuntu-curl-Build-Schritt verwendet:

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

Das Dockerfile.ubuntu-curl, mit dem das Tool curl installiert wird:

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

Das Skript ./curl.bash könnte so aussehen:

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

Das Beispiel-Dockerfile:

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

Führen Sie den folgenden Befehl in Ihrem Shell- oder Terminalfenster aus, um den benutzerdefinierten Build-Schritt für ubuntu-curl auszuführen und anschließend das Image zu erstellen:

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

Sobald Sie das von Ihnen erstellte Image mit Dockerfile.ubuntu-curl in eine Docker Registry übertragen, können Sie es direkt als Build-Schritt verwenden.

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

Sie können das Gleiche in einem Build erreichen, indem Sie einen vorbereitenden Schritt hinzufügen, um das Image für die Skriptausführung zu erstellen. Sobald Sie dieses Image erstellt haben, können Sie es als nächsten Schritt in Ihrem Build verwenden. Der Vorteil dieser Methode liegt darin, dass curl.bash sauber gehalten und der Großteil der Arbeit über den Cloud Build-Dienst ausgeführt wird.

Hier eine ./cloudbuild.yaml-Konfigurationsdatei mit einem zusätzlichen vorausgehenden Schritt als Beispiel:

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

Solange script-runner nicht im images-Feld in Ihrer cloudbuild.yaml enthalten ist, wird der Cloud Build-Dienst nicht versuchen, es mithilfe eines Push-Vorgangs zu übertragen (was in diesem Fall fehlschlagen würde). Im Zusammenhang mit diesem Build ist das script-runner-Image jedoch im Image-Cache vorhanden und kann als Build-Schritt verwendet werden.

Nächste Schritte