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
- Builds manuell starten und Builds mit Build-Triggern automatisieren
- Build-Ergebnisse mithilfe der Google Cloud Platform Console oder mit dem gcloud-Befehlszeilentool aufrufen