Problemlösung für Hauptspeicherbegrenzung beim Build

Siehe Build schlägt fehl, wenn der Speichergrenzwert überschritten wird für die Auflösungsinformationen.

Problemlösung für Problem mit Container-Registry beim Build

In diesem Szenario existiert kein Registrierungsgeheimnis für den Zugriff auf Ihre Container-Registrierung oder das Geheimnis ist nicht korrekt.

1. Stellen Sie fest, welcher geheime Schlüssel verwendet wird. Verwenden Sie den ibmcloud ce build get um das verwendete Registrierungsgeheimnis anzuzeigen.

2. Stellen Sie fest, ob der Schlüssel .dockerconfigjson vorhanden ist. Verwenden Sie den Befehl ibmcloud ce secret get für den geheimen Registry-Schlüssel. Bitte beachten Sie, dass die Daten des geheimen Schlüssels mithilfe von Base64 codiert sind und nicht direkt angezeigt werden; im geheimen Schlüssel sind jedoch Berechtigungsnachweise enthalten. Überprüfen Sie in der Befehlsausgabe den Abschnitt Data. Er muss einen Schlüssel mit dem Namen .dockerconfigjson enthalten. Wenn der Schlüssel .dockerconfigjson nicht angezeigt wird, ist dieser geheime Schlüssel nicht für eine Authentifizierung an der Container-Registry geeignet; in diesem Fall müssen Sie einen korrekten geheimen Schlüssel erstellen und im Build auf diesen verweisen. Weitere Informationen finden Sie unter Zugriff auf private Container-Registry hinzufügen.

   Beispielausgabe

   $ ibmcloud code-engine secret get -n <REGISTRY_SECRET>
   Getting secret <REGISTRY_SECRET>...
   OK
   
   Name:        <REGISTRY_SECRET>
   ID:          <REGISTRY_SECRET_ID>
   Project:     <PROJECT_NAME>
   Project ID:  <PROJECT_NAMESPACE>
   Age:         8s
   Created:     2021-02-12T10:26:59-06:00
   
   Data:
   ---
   .dockerconfigjson: <BASE64_STRING>
   

3. Wenn der Schlüssel .dockerconfigjson vorhanden ist, entschlüsseln Sie den Schlüssel, bei dem es sich um eine mit Base64 codierte Zeichenfolge handelt; führen Sie hierzu den folgenden Befehl aus:

   echo "<BASE64_STRING>" | base64 -d
   {"auths":{"<REGISTRY>":{"username":"<USERNAME>","password":"<PASSWORD>","auth":"<AUTH>"}}}
   

   Die Ausgabe dieses Befehls enthält normalerweise einen <REGISTRY>-Schlüssel.

4. Überprüfen Sie die folgenden Informationen zu dem Schlüssel:

   a. Sehen Sie sich den Wert <REGISTRY> an. Dieser Wert muss mit dem Image des Builds übereinstimmen.

   • Wenn der Imagename auf IBM Cloud Container Registry ist, z. B. us.icr.io/aNamespace/anImage, dann muss <REGISTRY> us.icr.io sein.

   • Wenn der Imagename docker.io/aNamespace/aRepository oder /aNamespace/aRepository ohne Hostnamen ist, wird Docker Hub vom Build verwendet. In diesem Fall muss <REGISTRY> https://index.docker.io/v1/ sein.

   b. Sehen Sie sich den Wert <USERNAME> an. Wenn es sich bei der Registry um eine Instanz von IBM Cloud Container Registry handelt, muss für die Authentifizierung ein API-Schlüssel verwendet werden. <USERNAME> muss iamapikey sein und das Kennwort muss ein API-Schlüssel sein. Informationen zu den Schritten zum Erstellen des API-Schlüssels finden Sie unter Zugriff auf IBM Cloud Container Registry automatisieren.

   c. Die Berechtigungsnachweise müssen validiert werden. IBM Cloud® Identity and Access Management (IAM) ermöglicht die differenzierte Zuordnung von Berechtigungen. Beispiel: Für eine Service-ID mit Zugriff auf einen IBM Cloud Container Registry-Namensbereich und der Berechtigung zum Extrahieren von Images kann festgelegt werden, dass das Übertragen von Images mit einer Push-Operation durch diese Service-ID nicht zulässig ist. In diesem Fall ist diese Berechtigung aber erforderlich.

5. Erstellen Sie nach dem Bestimmen der erforderlichen Änderungen einen geheimen Schlüssel für die Container-Registry, von dem die korrigierten Werte verwendet werden. Verwenden Sie den Befehl ibmcloud ce secret create --format. Beispiel:

   ibmcloud ce secret create --format registry --name <REGISTRY_SECRET> --server <REGISTRY_SERVER> --username <USERNAME> --password <PASSWORD>
   

6. Aktualisieren Sie den Build so, dass auf den Namen des geheimen Schlüssels für die Registry verwiesen wird.

   a. Verwenden Sie den Befehl ibmcloud ce build update, um die Buildkonfiguration so zu aktualisieren, dass der Name des geheimen Schlüssels für die Registry verwendet wird. Beispiel:

   ibmcloud ce build update --name <BUILD_NAME> --registry-secret <REGISTRY_SECRET>
   

   b. Verwenden Sie den Befehl ibmcloud ce buildrun submit, um eine neue Buildausführung zu übergeben. Für den Befehl buildrun submit müssen Sie die Option --build angeben, um den Namen der Buildkonfiguration anzugeben. Optional können Sie auch die Option --name angeben, um den Namen für diese Buildausführung anzugeben. Wenn Sie die Option --name angeben, stellen Sie sicher, dass Sie für die Buildausführung einen anderen Namen als den Namen der fehlgeschlagenen Buildausführung verwenden; stellen Sie alternativ sicher, dass die fehlgeschlagene Buildausführung mit dem Befehl ibmcloud ce buildrun delete gelöscht wurde. Beispiel:

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Problemlösung für nicht gefundene Dockerfile beim Build

Für einen Docker-Build ist eine Dockerfile erforderlich, in der angegeben ist, wie das Container-Image erstellt werden soll. Wenn das Quellenrepository eine solche Datei nicht enthält, müssen Sie diese Datei bereitstellen oder die Verwendung von Buildpacks als Buildstrategie in Betracht ziehen. Weitere Informationen finden Sie unter Build planen.

1. Wenn die Dockerfile vorhanden ist, aber einen anderen Namen aufweist oder sich nicht im Stammverzeichnis befindet, müssen im Build zusätzliche Einstellungen angegeben werden.

   • Wenn sich die Dockerfile nicht im Stammverzeichnis des Quellenrepositorys befindet, müssen Sie das Argument --context-dir angeben und den Pfad zu dem Verzeichnis angeben, in dem sich die Dockerfile befindet.
   • Wenn die Dockerfile einen anderen Namen als Dockerfile aufweist, müssen Sie das Argument --dockerfile und den Namen der Dockerfile angeben.

2. Aktualisieren Sie den Build bei Bedarf so, dass die Optionen --context-dir oder --dockerfile verwendet werden.

   a. Verwenden Sie den Befehl ibmcloud ce build update, um die Buildkonfiguration so zu aktualisieren, dass nach Bedarf die Optionen --context-dir oder --dockerfile verwendet werden. Beispiel:

   ibmcloud ce build update --name <BUILD_NAME> [--context-dir <CONTEXT_DIR>] [--dockerfile <DOCKERFILE_NAME>]
   

   b. Verwenden Sie den Befehl ibmcloud ce buildrun submit, um eine neue Buildausführung zu übergeben. Für den Befehl buildrun submit müssen Sie die Option --build angeben, um den Namen der Buildkonfiguration anzugeben. Optional können Sie auch die Option --name angeben, um den Namen für diese Buildausführung anzugeben. Wenn Sie die Option --name angeben, stellen Sie sicher, dass Sie für die Buildausführung einen anderen Namen als den Namen der fehlgeschlagenen Buildausführung verwenden; stellen Sie alternativ sicher, dass die fehlgeschlagene Buildausführung mit dem Befehl ibmcloud ce buildrun delete gelöscht wurde. Beispiel:

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Problemlösung bei Erreichen des Grenzwerts für IBM Cloud Container Registry-Kontingente beim Build

IBM Cloud Container Registry verfügt über zwei Servicepläne, einen kostenfreien Plan und einen Standardplan. Bei Verwendung des kostenfreien Plans für IBM Cloud Container Registry gelten strenge Grenzwerte, insbesondere für die Imagegröße, die insgesamt gespeichert werden kann (500 MB). Für den Standardplan können Sie die Kontingente konfigurieren. Weitere Informationen hierzu finden Sie im Abschnitt Informationen zu IBM Cloud Container Registry.

1. Führen Sie eine der folgenden Aktionen aus:

   • Löschen Sie nicht verwendete Images im IBM Cloud Container Registry-Namensbereich, um den verfügbaren Speicherplatz zu erhöhen.
   • Führen Sie ein Upgrade von einem kostenfreien Plan auf den Standardplan durch.
   • Erhöhen Sie die Kontingente des IBM Cloud Container Registry-Namensbereichs.

   Die Image-URL ist in der Fehlernachricht enthalten, damit Sie leichter feststellen können, welcher IBM Cloud Container Registry-Namensbereich betroffen ist. Der Namensbereich kann sich in einem anderen IBM Cloud-Konto als Ihrem IBM Cloud Code Engine-Projekt befinden.

2. Verwenden Sie nach dem Ausführen der Korrekturen den Befehl ibmcloud ce buildrun submit, um eine neue Buildausführung zu übergeben. Für den Befehl buildrun submit müssen Sie die Option --build angeben, um den Namen der Buildkonfiguration anzugeben. Optional können Sie auch die Option --name angeben, um den Namen für diese Buildausführung anzugeben. Wenn Sie die Option --name angeben, stellen Sie sicher, dass Sie für die Buildausführung einen anderen Namen als den Namen der fehlgeschlagenen Buildausführung verwenden; stellen Sie alternativ sicher, dass die fehlgeschlagene Buildausführung mit dem Befehl ibmcloud ce buildrun delete gelöscht wurde. Beispiel:

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Problemlösung bei nicht ordnungsgemäß angegebener Buildquelle

Dieser Fehler tritt in der Regel auf, weil sich die Buildquelle nicht im Stammverzeichnis des Git-Repositorys befindet, sondern in einem Unterverzeichnis. Wenn sich die Buildquelle nicht im Stammverzeichnis befindet, geben Sie die entsprechende Position im Build an.

1. Verwenden Sie den Befehl ibmcloud ce build update, um die Buildkonfiguration so zu aktualisieren, dass mit der Option --context-dir der Pfad zur Quelle im Git-Repository angegeben wird. Beispiel:

   ibmcloud ce build update --name <BUILD_NAME> --context-dir <CONTEXT_DIR>
   

2. Verwenden Sie den Befehl ibmcloud ce buildrun submit, um eine neue Buildausführung zu übergeben. Für den Befehl buildrun submit müssen Sie die Option --build angeben, um den Namen der Buildkonfiguration anzugeben. Optional können Sie auch die Option --name angeben, um den Namen für diese Buildausführung anzugeben. Wenn Sie die Option --name angeben, stellen Sie sicher, dass Sie für die Buildausführung einen anderen Namen als den Namen der fehlgeschlagenen Buildausführung verwenden; stellen Sie alternativ sicher, dass die fehlgeschlagene Buildausführung mit dem Befehl ibmcloud ce buildrun delete gelöscht wurde. Beispiel:

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Lösung für ein Problem aufgrund von Docker Hub-Ratenbegrenzungen

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. Wenn Sie diesen Fehler erhalten, versuchen Sie eine der folgenden Lösungen.

• Erhöhen Sie die Ratenbegrenzungen. Sie können sich bei Bedarf mit Docker Hub authentifizieren oder für Ihr Konto ein Upgrade auf ein Docker Pro oder Team durchführen.

• Ziehen Sie das erstellte Image aus Docker Hub und veröffentlichen Sie das Image in einer anderen Registrierung, z. B. IBM Cloud® Container Registry. Extrahieren Sie anschließend Ihr Image mit einer Pull-Operation von der neuen Position. Code Engine unterstützt die Referenzierung eines einzelnen geheimen Schlüssels. Wenn das Basisimage für Ihren Dockerfile-Build aus einer anderen Registry extrahiert wird als die, in der das erstellte Image veröffentlicht wird, und beide Registrys eine Authentifizierung erfordern, können Sie kubectl verwenden, um einen geheimen Kubernetes-Schlüssel des Typs kubernetes.io/dockerconfigjson zu erstellen, der Berechtigungsnachweise für beide Registrys enthält. Informationen zum Arbeiten mit Zugriffsberechtigungsnachweisen für beide Registrys finden Sie in der Dokumentation zuKubernetes zum Extrahieren eines Images aus einem privaten Repository.

Problemlösung bei nicht vom Buildpack unterstützter Buildquelle

Wenn Sie überprüfen möchten, ob das Quellenrepository für den Build von Code Engine unterstützt wird, überprüfen Sie die Informationen im Abschnitt Buildstrategie wählen auf die unterstützten Laufzeiten. Wenn Ihre Sprache aufgelistet ist, überprüfen Sie die verlinkten Beispiele und stellen Sie sicher, dass Sie die Quellen ordnungsgemäß so strukturiert sind, dass sie von den Buildpacks erfolgreich erkannt und diese erstellt werden können. Wenn Sie kein geeignetes Buildpack für die Quelle finden oder die standardisierte Methode für die Ausführung des Buildpacks nicht Ihren Anforderungen entspricht, können Sie eine Dockerfile angeben, die Erstellung des Containers manuell in the Dockerfile beschreiben und danach die Buildstrategie dockerfile in der Buildkonfiguration verwenden.

Problemlösung bei Problem mit Docker-Build

Wenn der Schritt zur Erstellung und Übertragung mit einer Push-Operation nicht durch ein Problem mit dem Hauptspeicher, dem geheimen Schlüssel für die Container-Registry oder einer Dockerfile fehlgeschlagen ist, ist wahrscheinlich der Docker-Build die Ursache für das Problem. Das Problem kann ein Fehler in der Dockerfile selbst sein, wie zum Beispiel ein Syntaxfehler, oder mit der Korrektheit der ausgeführten Operation zusammenhängen. Das Problem kann auch in Ihrem Quellcode auftreten, der möglicherweise nicht kompiliert werden kann, z. B. wenn Java®-Code enthalten ist.

Wenn Sie Ihr Projekt lokal erfolgreich erstellen konnten, der Build mit demselben Quellcode in Code Engine jedoch nicht möglich ist, sind unter Umständen bestimmte Dateien lokal verfügbar, die sich nicht im Git-Repository befinden. So ist es beispielsweise bei Node.js-Projekten üblich, den Befehl npm install lokal auszuführen, damit Projektabhängigkeiten heruntergeladen und im Verzeichnis node_modules innerhalb des Projektverzeichnisses gespeichert werden. Es ist eine gute Praxis, das Verzeichnis node_modules in die Datei.gitignore aufzunehmen, um das Repository Git klein zu halten. Häufig wird vergessen, npm install (oder npm ci) auch in der Dockerfile auszuführen. Ein Docker-Build, den Sie lokal ausführen, kann auf das lokale node_modules-Verzeichnis zugreifen, wenn Sie das gesamte Projekt in den Container kopieren, z. B. mit dem Befehl COPY . /app im Dockerfile. Der Code Engine-Build erfolgt jedoch über ein neu ausgechecktes Git-Repository und kann nicht auf das Verzeichnis node_modules zugreifen. Sie müssen deshalb im Rahmen des Builds npm install (oder npm ci) in der Dockerfile ausführen.

Eine gute Praxis ist es, Verzeichnisse wie node_modules auch in eine .dockerignore-Datei einzuschließen, so dass sich der Docker Build, den Sie lokal ausführen, genauso verhält wie der Code Engine Build.

Ein weiterer Grund dafür, dass ein Projektbuild lokal erfolgreich ist, als Code Engine-Build jedoch fehlschlägt, sind Einschränkungen aufgrund der Sicherheit. Wie auch bei Anwendungen und Stapeljobs lässt Code Engine keine beliebigen Systemoperationen im Code Engine-Cluster zu. Die meisten dieser Systemoperationen sind für Docker-Builds ohnehin nicht relevant. Von Code Engine wird jedoch auch nicht das Öffnen von Server-Sockets für privilegierte Ports zugelassen. Der Bereich ist 0 to 1023. Wenn Sie zum Beispiel eine Webanwendung erstellen und der Build einen Testschritt umfasst, durch den ein Webanwendungsserver gestartet wird, müssen Sie für diesen Server Ports mit höheren Nummern verwenden.