Build planen

Machen Sie sich vor dem Erstellen der Images mit IBM Cloud® Code Engine mit den unterschiedlichen Optionen für Ihren Build vertraut.

Ein Build oder ein Image-Build ist ein Mechanismus, mit dem Sie ein Container-Image aus Ihrem Quellcode erstellen können. Code Engine unterstützt die Erstellung aus einer Dockerfile und Cloud Native Buildpacks.

Wenn Sie ein Image erstellt haben, das in einer Container-Registrierung vorhanden ist und das Image mit einem nicht Intel-basierten Prozessor erstellt wurde, kann Code Engine Ihr Container-Image nicht ausführen. Code Engine verwendet Intel-basierte Prozessoren. Sie können Ihr eigenes Image erstellen, wenn Sie einen Intel-Prozessor verwenden ( x86 ). Sie können den Erstellungsprozess auch Code Engine überlassen.

Code Engine stellt CRD-Methoden (CRD = Custom Resource Definition) bereit. Weitere Informationen finden Sie unter Quelle-zu-Bild-CRD-Methoden.

Quellenposition vorbereiten

Damit Code Engine auf Ihren Quellcode zugreifen kann, müssen Sie ihn in einem Git-Repository oder an einer zugänglichen Position auf Ihrer lokalen Workstation verfügbar machen.

Git-Repository
Speichern Sie Ihren Code in einem Git Repository, zum Beispiel in GitHub oder GitLab. Ihr Code kann sich auf der Ausgangsebene Ihres Repositorys oder in einem Unterverzeichnis befinden. Wenn das Quellenrepository nicht öffentlich ist, müssen Sie Zugriff auf Code Engine hinzufügen.
Lokale Workstation
Speichern Sie Ihren Code auf Ihrer lokalen Workstation. Wenn Sie ein Build übergeben, das Code aus dem lokalen Verzeichnis extrahiert, wird Ihr Quellcode in eine Archivdatei gepackt und in Ihre IBM Cloud Container Registry-Instanz hochgeladen. Das Quellenimage wird in demselben Namensbereich erstellt wie Ihr Build-Image. Beachten Sie, dass Sie nur IBM Cloud Container Registry für Ihre lokalen Builds verwenden können. Sie können bestimmte Dateimuster aus Ihrem Quellcode ignorieren, indem Sie die Datei .ceignore verwenden, die sich ähnlich wie eine .gitignore-Datei verhält. Einträge für eine .ceignore-Datei bezüglich einer Node.js-Anwendung können beispielsweise node_modules und .npm enthalten. Weitere Beispiele für zu ignorierende Dateimuster finden Sie im GitHub.gitignore Repository.

Buildstrategie wählen

Code Engine kann Ihr Container-Image mit einer der folgenden Strategien erstellen.

Dockerfile

Dockerfile-Build, der das BuildKit werkzeug. Fügen Sie eine Dockerfile zum Quellenrepository hinzu, falls Sie diese Strategie verwenden möchten. In dieser Dockerfile werden die Schritte beschrieben, die erforderlich sind, um ein Container-Image aus dem Quellenrepository zu erstellen. Die Dockerfile kann Schritte zum Kopieren statischer Dateien aus den Quellen in den Container enthalten, der zum Beispiel von einem Web-Service gehostet werden soll. Hierbei kann Quellcode kompiliert werden, der in der jeweils gewünschten Sprache geschrieben ist, und die daraus resultierende Binärdatei zum Container-Image hinzugefügt werden. Weitere Informationen zu Dockerfile-Builds enthält der Abschnitt Dockerfile für Code Engine schreiben.

Wenn Sie ein Bild von Docker Hub abrufen, um es mit Anwendungen oder Aufträgen in Code Engine zu verwenden, beachten Sie bitte die Ratenbeschränkungen von Docker für Nutzer des kostenlosen Tarifs (ohne Authentifizierung). Wenn Sie einen Fehler 429 erhalten, dass Sie Ihre Ratenbegrenzung für Pull-Operationen erreicht haben, wurde Ihre Ratenbegrenzung für Pull-Operationen möglicherweise erreicht. Um die Tarifgrenzen zu erhöhen, können Sie Ihr Konto auf ein Docker Pro oder Team Abonnement erweitern.

Cloud Native Buildpacks

Cloud Native Buildpack, das Paketo verwendet, um Ihr Quellcode-Repository zu untersuchen und zu erkennen, auf welcher Laufzeitumgebung Ihr Code basiert und wie ein Container-Image aus Ihren Quellen erstellt wird. Buildpacks gehen von Annahmen über die Verzeichnisstruktur Ihrer Quellenrepositorys aus. Weitere Informationen zum ordnungsgemäßen Strukturieren des Quellenrepository finden Sie in den Beispielen, die für die Laufzeit bereitgestellt werden.

Laufzeitbeispieldateien
Laufzeit Version Beispiele
Los 1.24.12 Proben gehen.
Java 21.0.10 Java proben.
Node.js 24.14.0 Node.js proben.
PHP 8.1.28 PHP-Beispiele.
Python 3.11.14 Python proben.
Ruby 3.1.7 Ruby proben.
.NET Core 9.0.311 (.NET Core SDK),
9.0.13 (.NET Core Runtime)		 .NET Core proben.

Bilder, die mit Cloud Native Buildpacks erstellt werden, verwenden nicht mehr den neutralen Zeitstempel von Jan, 1st 1980 als Zeitstempel der Bilderstellung. Der Zeitstempel der Eingabequelle wird als Zeitstempel für die Erstellung des Abbilds verwendet, z.B. der Git commit-Zeitstempel des Commits, der für Ihren Build verwendet wurde.

Die Version einer bestimmten Laufzeit für ein Paketo-Buildpack kann sich für kurze Zeit zwischen den Regionen unterscheiden, wenn eine aktualisierte Version eines Buildpacks in die verschiedenen Regionen von IBM Cloud ausgerollt wird.

Größe des Builds festlegen

Code Engine klassifiziert Builds in die Größen small, medium, large, xlarge und xxlarge. Mit der Größe des Builds wird festgelegt, wie viel CPU-Kerne, Hauptspeicher und Plattenspeicher dem Build zugeordnet werden. Ein kleinerer Build ist kostengünstiger, aber in der Regel auch langsamer, da er weniger CPU-Kerne verwendet. Außerdem können die Speicheranforderungen und die Plattenanforderungen des Builds zu einem Fehlschlagen des Builds mit einer kleineren Größe führen.

Werte der Buildgrößen
Größe Dockerfile Buildpacks
small
  • CPU 0.5
  • Speicher 2 GB
  • Platte 2 GB
  • CPU 0.5
  • Speicher 2 GB
  • Platte 2 GB
medium
  • CPU 1
  • Speicher 4 GB
  • Platte 4 GB
  • CPU 1
  • Speicher 4 GB
  • Platte 4 GB
large
  • CPU 2
  • Speicher 8 GB
  • Platte 8 GB
  • CPU 2
  • Speicher 8 GB
  • Platte 8 GB
xlarge
  • CPU 4
  • Speicher 16 GB
  • Platte 16 GB
  • CPU 4
  • Speicher 16 GB
  • Platte 16 GB
xxlarge
  • CPU 12
  • Arbeitsspeicher 48 GB
  • Festplatte 48 GB
  • CPU 12
  • Arbeitsspeicher 48 GB
  • Festplatte 48 GB

Wenn Sie bei der Wahl der Größe unsicher sind, ziehen Sie in Betracht, mit small oder medium zu beginnen. Wenn der Build aufgrund von nicht ausreichendem Hauptspeicher oder Plattenspeicher fehlschlägt oder nicht schnell genug ist, wechseln später Sie zu einer größeren Größe.

Container-Image-Registry auswählen

Code Engine extrahiert Quellcode aus einem Git-Repository oder einem lokalen Verzeichnis, erstellt einen Build und überträgt das Image mit einer Push-Operation an eine Container-Image-Registry.

Sie können Repositorys für Ihre Quelle und Registrys für Ihr Container-Image verwenden, die öffentlich oder privat sind. Sie können auch Registry-Details mit einem Registry-Geheimnis für Ihre Build-Ausgabe angeben, oder Sie können sich dafür entscheiden, dass Code Engine die Erstellung des Abbilds aus Ihren Quellen für Sie übernimmt und das Abbild in IBM Cloud Container Registry mit automatischem Zugriff speichert.

Wählen Sie Ihre Erstellungsmethode

Bei den folgenden Build-Optionen zieht Code Engine den Quellcode aus einem Git Repository oder einem lokalen Verzeichnis, erstellt das Container-Image und lädt es dann in eine Registry hoch (Push). Sie können zwischen öffentlichen und privaten Repositories und Registries wählen. Wenn Ihre Registrierung privat ist, geben Sie Registrierungsdetails mit einem Registrierungsgeheimnis für Ihre Build-Ausgabe mit benutzerdefiniertem Zugriff an. Sie können auch wählen, dass Code Engine für Sie einen Zugang zum Speichern des Bildes in IBM Cloud Container Registry mit automatischem Zugriff erstellt.

Build-Konfigurationen erstellen

In diesem Szenario erstellt Code Engine eine Konfiguration für Ihren Build.

Bei der Erstellung einer Build-Konfiguration wird kein Image erstellt, sondern die Konfiguration für die Erstellung eines Images erstellt. Sie können ein Image aus der Konfiguration erstellen, indem Sie den Build ausführen. Die Buildkonfiguration wird erst bei der Ausführung des Builds validiert oder zum Erstellen eines Images verwendet. Mit der Buildkonfiguration können nacheinander mehrere Builds für ein Image ausgeführt werden, beispielsweise nach dem Anwenden von Änderungen auf das Quellenrepository.

Vollständige Informationen finden Sie in den folgenden Abschnitten:

Nachdem Sie Ihre Build-Konfiguration erstellt haben, können Sie sie ausführen.

Container-Image mit eigenständigen Build-Befehlen erstellen

Wie Sie Ihr Container-Image mit einem einzigen Code Engine-CLI-Befehl erstellen und das Container-Image erstellen, ohne eine wiederverwendbare Build-Konfiguration zu erstellen, erfahren Sie unter Container-Image mit eigenständigen Build-Befehlen (CLI) erstellen.

Erstellen Sie Ihren Code und erzeugen Sie Ihre Arbeitslast

Wenn Sie einen Workload aus lokalem Quellcode erstellen, wird der Quellcode in eine Archivdatei gepackt und in einen verwalteten Namespace innerhalb der Instanz IBM Cloud Container Registry in Ihrem Konto hochgeladen. Das Bild wird ebenfalls in diesem Namespace gespeichert.

Um Ihren Code zu erstellen und Ihre Arbeitslast mit einem einzigen Vorgang zu erzeugen, lesen Sie die folgenden Themen.

Git-Repository
Lokale Datei

Nächste Schritte für Builds

Benötigen Sie weitere Codebeispiele? Sehen Sie sich das Samples for IBM Cloud Code Engine GitHub repo an.