Fehlerbehebung für AWS CodeBuild

Verwenden Sie die Informationen in diesem Thema, um Fehler zu identifizieren, zu diagnostizieren und zu beheben. Für Informationen zum Protokollieren und Überwachen von CodeBuild-Builds zur Behebung von Problemen sieheProtokollierung und Überwachungaus.

Apache Maven erstellt Referenzartefakte aus dem falschen Repository

Problem: Wenn du Maven mit einemAWS CodeBuild-Bereitgestellte Java Build-Umgebung ruft Maven Build- und Plugin-Abhängigkeiten aus dem sicheren zentralen Maven-Repository unterhttps://repo1.maven.org/maven2aus. Das passiert auch dann, wenn die Datei pom.xml des Build-Projekts explizit die Verwendung anderer Verzeichnisse angibt.

Mögliche Ursache: Von CodeBuild bereitgestellte Java Build-Umgebungen enthalten eine Datei namenssettings.xmldas ist in der Build-Umgebung vorinstalliert/root/.m2-Verzeichnis Diese Datei settings.xml enthält die folgenden Deklarationen, die Maven anweisen, Build- und Plugin-Abhängigkeiten aus dem sicheren zentralen Maven-Repository unter https://repo1.maven.org/maven2 abzurufen.

<settings>
  <activeProfiles>
    <activeProfile>securecentral</activeProfile>
  </activeProfiles>
  <profiles>
    <profile>
      <id>securecentral</id>
      <repositories>
        <repository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
</settings>

Empfohlene Lösung: Gehen Sie wie folgt vor:

1. Fügen Sie eine Datei settings.xml zu Ihrem Quellcode hinzu.

2. Verwenden Sie in dieser Datei settings.xml das oben angegebene Format für settings.xml als Richtlinie zur Deklaration der Repositorys, aus denen Maven stattdessen die Build- und Plugin-Abhängigkeiten abrufen soll.

3. In derinstallPhase des Build-Projekts, weisen Sie CodeBuild an, Ihresettings.xmlDatei in die Build-Umgebung/root/.m2-Verzeichnis Ein Beispiel ist der folgende Codeausschnitt aus der Datei buildspec.yml, der dieses Verhalten veranschaulicht.

   version 0.2
   
   phases:
     install:
       commands:
         - cp ./settings.xml /root/.m2/settings.xml

Build-Befehle werden standardmäßig als Root-Benutzer ausgeführt

Problem: AWS CodeBuild führt Ihre Build-Befehle als Root-Benutzer aus. Dies passiert, auch wenn das Dockerfile des entsprechenden Build-Image die USER-Anweisungen auf einen anderen Benutzer umstellt.

Ursache: Standardmäßig führt CodeBuild alle Build-Befehle als Root-Benutzer aus.

Empfohlene Lösung: Keine.

Builds könnten fehlschlagen, wenn Dateinamen nicht-US-englische Zeichen enthalten

Problem: Wenn Sie einen Build ausführen, der Dateien mit Dateinamen verwendet, die nicht-US- englische Zeichen (z. B. chinesische Zeichen) enthalten, schlägt der Build fehl.

Mögliche Ursache: Build-Umgebungen bereitgestellt vonAWS CodeBuildlassen Sie ihr Standardgebietsschema aufPOSIXaus.POSIXLokalisierungseinstellungen sind weniger kompatibel mit CodeBuild und Dateinamen, die nicht-US- englische Zeichen enthalten. Dies kann dazu führen, dass zugehörige Builds fehlschlagen.

Empfohlene Lösung: Fügen Sie der folgenden Befehle hinzupre_build-Abschnitt Ihrer Build-Spezifikationsdatei. Diese Befehle sorgen dafür, dass die Build-Umgebung US English UTF 8 für die Lokalisierungseinstellungen verwendet, wodurch die Kompatibilität mit CodeBuild und Dateinamen mit nicht-US- englische Zeichen enthalten, besser kompatibel ist.

Für Build-Umgebungen basierend auf Ubuntu:

pre_build:
  commands:
    - export LC_ALL="en_US.UTF-8"
    - locale-gen en_US en_US.UTF-8
    - dpkg-reconfigure locales

Für Build-Umgebungen basierend auf Amazon Linux:

pre_build:
  commands:
    - export LC_ALL="en_US.utf8"

Builds könnten fehlschlagen, wenn Parameter aus dem Amazon EC2 EC2-Parameterspeicher abgerufen werden

Problem: Wenn Builds versuchen, im Amazon EC2 Parameter Store gespeicherte Parameterwerte abzurufen, erhalten Sie im Amazon EC2 Parameter Store gespeicherte Parameterwerte imDOWNLOAD_SOURCEPhase mit dem FehlerParameter does not existaus.

Mögliche Ursache: Die Dienstrolle, auf die sich das Build-Projekt stützt, hat keine Berechtigung zum Aufrufen desssm:GetParametersAktion oder das Build-Projekt verwendet eine Servicerolle, die vonAWS CodeBuildund ermöglicht das Anrufen desssm:GetParametersAktion, aber die Parameter haben Namen, die nicht mit beginnen/CodeBuild/aus.

Empfohlene Lösungen:

• Wenn die Servicerolle nicht von CodeBuild erstellt wurde, aktualisieren Sie ihre Definition, damit CodeBuild diessm:GetParametersAktion Die folgende Richtlinienanweisung erlaubt es beispielsweise, die Aktion ssm:GetParameters auszuführen und Parameter, deren Namen mit /CodeBuild/ beginnen, abzurufen:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "ssm:GetParameters",
        "Effect": "Allow",
        "Resource": "arn:aws:ssm:REGION_ID:ACCOUNT_ID:parameter/CodeBuild/*"
      }
    ]
  }

• Wenn die Service-Rolle von CodeBuild erstellt wurde, aktualisieren Sie ihre Definition, um es CodeBuild zu ermöglichen, auf die Parameter im Amazon EC2 Parameter Store zuzugreifen, deren Namen nicht mit beginnen/CodeBuild/aus. Die folgende Richtlinienanweisung erlaubt es beispielsweise, die Aktion ssm:GetParameters auszuführen und Parameter mit dem angegebenen Namen abzurufen:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "ssm:GetParameters",
        "Effect": "Allow",
        "Resource": "arn:aws:ssm:REGION_ID:ACCOUNT_ID:parameter/PARAMETER_NAME"
      }
    ]
  }

Zugriff auf Verzweigungsfilter in der CodeBuild-Konsole nicht möglich

Problem: Die Verzweigungsfilter-Option ist in der Konsole nicht verfügbar, wenn Sie eineAWS CodeBuild-Projekt.

Mögliche Ursache: Die Verzweigungsfilter-Option ist veraltet. Sie wurde durch Webhook-Filtergruppen ersetzt, die eine bessere Kontrolle über die Webhook-Ereignisse bieten, die einen neuen -Build in CodeBuild auslösen.

Empfohlene Lösung: Erstellen Sie zum Migrieren eines Verzweigungsfilters, den Sie vor der Einführung von Webhook-Filtern erstellt haben, erstellen Sie eine Webhook-Filtergruppe mit einemHEAD_REFfiltern mit dem regulären Ausdruck^refs/heads/branchName$aus. Wenn der reguläre Ausdruck Ihres Verzweigungsfilters beispielsweise ^branchName$ lautete, ist der aktualisierte reguläre Ausdruck, den Sie in den HEAD_REF-Filter eingeben, ^refs/heads/branchName$. Weitere Informationen finden Sie unter BitBucket-Webhook-Ereignissen und Filtern von GitHub-Webhook-Ereignissen (Konsole).

Erfolg oder Misserfolg der Build-Erstellung wird nicht angezeigt

Problem: Sie können den Erfolg oder Misserfolg eines wiederholten Builds nicht erkennen.

Mögliche Ursache: Die Option zum Melden des Build-Status ist nicht aktiviert.

Empfohlene Lösungen: Aktivieren vonMelden des Build-Statuswenn Sie ein CodeBuild-Projekt erstellen oder aktualisieren. Diese Option weist CodeBuild an, den Status zurückzugeben, wenn Sie einen Build auslösen. Weitere Informationen finden Sie unter reportBuildStatus in der AWS CodeBuild-API-Referenz.

Build-Status wurde nicht an den Quellanbieter gemeldet

Problem: Nachdem Sie den Build-Statusbericht an einen Quellanbieter wie GitHub oder Bitbucket zugelassen haben, wird der Build-Status nicht aktualisiert.

Mögliche Ursache: Der mit dem Quellanbieter verknüpfte Benutzer hat keinen Schreibzugriff auf das Repo.

Empfohlene Lösungen: Um den Build-Status an den Quellanbieter melden zu können, muss der mit dem Quellanbieter verknüpfte Benutzer Schreibzugriff auf das Repo haben. Wenn der Benutzer keinen Schreibzugriff hat, kann der Build-Status nicht aktualisiert werden. Weitere Informationen finden Sie unter Zugriff auf Quellcode.

Das Basis-Image der Windows Server Core 2019-Plattform kann nicht gefunden und ausgewählt werden

Problem: Sie können das Basis-Image der Windows Server Core 2019-Plattform nicht finden oder auswählen.

Mögliche Ursache: Du benutzt einAWSRegion, die dieses Image nicht unterstützt.

Empfohlene Lösungen: Nutzen Sie einen der FolgendenAWSRegionen, in denen das Basis-Image der Windows Server Core 2019-Plattform unterstützt wird:

• USA Ost (Nord-Virginia)

• USA Ost (Ohio)

• USA West (Oregon)

• Europa (Ireland)

Vorherige Befehle in den Build-Spezifikationsdateien werden von nachfolgenden Befehlen nicht erkannt

Problem: Die Ergebnisse von einem oder mehreren Befehlen in den Build-Spezifikationsdateien werden von nachfolgenden Befehlen in derselben buildspec-Datei nicht erkannt. Beispielsweise legt ein Befehl eine lokale Umgebungsvariable fest, aber ein späterer Befehl ruft den Wert dieser lokalen Umgebungsvariable nicht ab.

Mögliche Ursache: In der buildspec Dateiversion 0.1AWS CodeBuildführt jeden Befehl in einer separaten Instance der Standard-Shell in der Build-Umgebung aus. d. h., dass jeder Befehl unabhängig von allen anderen Befehlen ausgeführt wird. Daher können Sie keinen Einzelbefehl ausführen, der auf dem Status eines vorherigen Befehls basiert.

Empfohlene Lösungen: Wir empfehlen die Verwendung der Build-Spezifikationsversion 0.2, die dieses Problem behebt. Falls Sie doch die Build-Spezifikationsversion 0.1 verwenden müssen, empfehlen wir die Verwendung des Shell-Befehlsverkettungsoperators (z. B. && in Linux), um mehrere Befehle zu einem einzigen Befehl zu kombinieren. Oder schließen Sie ein Shell-Skript in den Quellcode ein, das mehrere Befehle enthält, und rufen Sie dann dieses Shell-Skript über einen Einzelbefehl in der Build-Spezifikationsdatei auf. Weitere Informationen finden Sie unter Shells und Befehle in Build-Umgebungen und Umgebungsvariablen in Build-Umgebungen.

Fehler: „Zugriff verweigert“ beim Versuch, den Cache herunterzuladen

Problem: Beim Versuch, den Cache für ein Build-Projekt herunterzuladen, in dem Cache aktiviert ist, erhalten Sie eineAccess deniedFehler.

Mögliche Ursachen:

• Sie haben gerade Caching als Teil Ihres Build-Projekts konfiguriert.

• Der Cache wurde vor Kurzem durch die InvalidateProjectCache-API ungültig gemacht.

• Die Service-Rolle von CodeBuild verfügt nicht über die Berechtigungen s3:GetObject und s3:PutObject für den S3-Bucket, in dem sich der Cache befindet.

Empfohlene Lösung: Bei der ersten Verwendung ist es normal, dies direkt nach der Aktualisierung der Cache-Konfiguration zu erhalten. Wenn das Problem weiterhin besteht, sollten Sie prüfen, ob Ihre Service-Rolle über die Berechtigungen s3:GetObject und s3:PutObject für den S3-Bucket verfügt, in dem sich der Cache befindet. Weitere Informationen finden Sie unterAngeben von S3-BerechtigungenimAmazon S3 Entwicklerhandbuchaus.

Fehler: „BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE“ bei der Verwendung eines benutzerdefinierten Build-Image

Problem: Wenn Sie versuchen, einen Build auszuführen, der ein benutzerdefiniertes Build-Image verwendet, schlägt der Build mit der Fehlermeldung fehl.BUILD_CONTAINER_UNABLE_TO_PULL_IMAGEaus.

Mögliche Ursache: Die unkomprimierte Gesamtgröße des Build-Image ist größer als der für den Datenverarbeitungstyp der Build-Umgebung verfügbare Speicherplatz. Zum Prüfen der Größe des Build-Image nutzen Sie Docker und führen den Befehl docker images REPOSITORY:TAG aus. Eine Liste der für die jeweiligen Datenverarbeitungstypen verfügbaren Speicherplätze finden Sie unter Arten der Datenverarbeitung bei der Build-Umgebung.

Empfohlene Lösung: Verwenden Sie einen größeren Datenverarbeitungstyp, bei dem mehr Speicherplatz zur Verfügung steht, oder reduzieren Sie die Größe Ihres benutzerdefinierten Build-Image.

Mögliche Ursache: AWS CodeBuildist nicht berechtigt, das Build-Image aus Ihrer Amazon Elastic Container Registry (Amazon ECR) abzurufen.

Empfohlene Lösung: Aktualisieren Sie Ihre Repository-Berechtigungen in Amazon ECR, sodass CodeBuild Ihr benutzerdefiniertes Build-Image in die Build-Umgebung ziehen kann: Weitere Informationen hierzu finden Sie unter Amazon-ECR-Beispiel.

Mögliche Ursache: Das angeforderte Amazon ECR-Bild ist nicht verfügbar in derAWSRegion, die IhrAWSKonto verwendet.

Empfohlene Lösung: Verwenden Sie ein Amazon ECR-Bild, das sich im selben befindetAWSRegion als diejenigeAWSKonto verwendet.

Mögliche Ursache: Sie verwenden eine private Registrierung in einer VPC, die keinen öffentlichen Internetzugang hat. CodeBuild kann kein Abbild von einer privaten IP-Adresse in einer VPC abrufen. Weitere Informationen finden Sie unter Privates Register mitAWS Secrets Manager Beispiel für CodeBuild.

Empfohlene Lösung: Wenn Sie eine private Registrierung in einer VPC verwenden, stellen Sie sicher, dass die VPC über einen öffentlichen Internetzugang verfügt.

Mögliche Ursache: Wenn die Fehlermeldung enthält“toomanyrequests„, und das Bild wird von Docker Hub erhalten, dieser Fehler bedeutet, dass das Docker Hub Pull Limit erreicht wurde.

Empfohlene Lösung: Verwenden Sie eine private Docker Hub Registry oder rufen Sie Ihr Image von Amazon ECR ab. Weitere Informationen zur Verwendung einer privaten Registrierung finden Sie unter Privates Register mitAWS Secrets Manager Beispiel für CodeBuildaus. Weitere Informationen zur Verwendung von Amazon ECR finden Sie unterAmazon ECR-Beispiel für CodeBuild aus.

Fehler: „Build container dead, bevor Build container died was out of memory, or the Docker image is not supported.“ ErrorCode: 500"

Problem: Wenn Sie versuchen, einen Microsoft Windows- oder Linux-Container inAWS CodeBuildtritt dieser Fehler während der PROVISIONING-Phase auf.

Mögliche Ursachen:

• Die Container-OS-Version wird von CodeBuild nicht unterstützt.

• HTTP_PROXY, HTTPS_PROXY oder beides werden im Container angegeben.

Empfohlene Lösungen:

• Für Microsoft Windows verwenden Sie einen Windows-Container mit einem Container-Betriebssystem der Version microsoft/windowsservercore:10.0.x (z. B. microsoft/windowsservercore:10.0.14393.2125).

• Löschen Sie für Linux die HTTP_PROXY- und HTTPS_PROXY-Einstellungen in Ihrem Docker Image oder geben Sie die VPC-Konfiguration in Ihrem Build-Projekt an.

Fehler: „Es kann keine Verbindung mit dem Docker-Daemon hergestellt werden“ beim Ausführen eines Builds

Problem: Ihr Build schlägt fehl und Sie erhalten eine Fehlermeldung ähnlich wieCannot connect to the Docker daemon at unix:/var/run/docker.sock. Is the docker daemon running?im Build-Protokoll.

Mögliche Ursache: Sie führen Ihren Build nicht im privilegierten Modus aus.

Empfohlene Lösung: Führen Sie die folgenden Schritte aus, um Ihren Build im privilegierten Modus auszuführen:

1. Öffnen Sie die CodeBuild-Konsole unter https://console.aws.amazon.com/codebuild/.

2. Wählen Sie im Navigationsbereich Build projects (Build-Projekte) und anschließend Ihr Build-Projekt aus.

3. Wählen Sie in Edit (Bearbeiten) Environment (Umgebung) aus.

4. Wählen Sie Override images (Images überschreiben) und anschließend Environment (Umgebung) aus.

5. Geben Sie das Umgebungs-Image, das Betriebssystem, die Laufzeit und das Image an. Diese Einstellungen sollten den Einstellungen für den Build entsprechen, der fehlgeschlagen ist.

6. Wählen Sie Privileged (Privilegiert) aus.

   Anmerkung

   Standardmäßig erlauben Docker-Container keinen Zugriff auf Geräte. Der privilegierte Modus gewährt dem Docker-Container eines Build-Projekts Zugriff auf alle Geräte. Weitere Informationen finden Sie unter Laufzeitberechtigungen und Linux-Funktionen auf der Docker-Docs-Website.

7. Wählen Sie Update environment (Umgebung aktualisieren).

8. Wählen Sie Start build (Build starten) aus, um erneut zu versuchen, den Build zu erstellen.

Fehler: „CodeBuild ist nicht berechtigt, auszuführen: sts:AssumeRole“ beim Erstellen oder Aktualisieren eines Build-Projekts

Problem: Wenn Sie versuchen, ein Build-Projekt zu erstellen oder zu aktualisieren, wird der Fehler angezeigtCode:InvalidInputException, Message:CodeBuild is not authorized to perform: sts:AssumeRole on arn:aws:iam::account-ID:role/service-role-nameaus.

Mögliche Ursachen:

• AWS Security Token Service (AWS STS) wurde für die AWS-Region deaktiviert, in der Sie versuchen, das Build-Projekt zu erstellen oder zu aktualisieren.

• DieAWS CodeBuildDie mit dem Build-Projekt verknüpfte -Servicerolle ist nicht vorhanden oder hat keine ausreichende Berechtigung, CodeBuild zu vertrauen.

Empfohlene Lösungen:

• Stellen Sie sicher, dass AWS STS für die AWS-Region aktiviert ist, in der Sie versuchen, das Build-Projekt zu erstellen oder zu aktualisieren. Weitere Informationen finden Sie unter AWS STS in einer AWS-Region aktivieren und deaktivieren im IAM-Benutzerhandbuch.

• Stellen Sie sicher, dass die CodeBuild-Ziel-Servicerolle in IhremAWSKonto. Wenn Sie nicht die Konsole verwenden, achten Sie darauf, dass Sie den Amazon-Ressourcenname (ARN) der Servicerolle beim Erstellen oder Aktualisieren des Build-Projekts richtig geschrieben haben.

• Stellen Sie sicher, dass die CodeBuild-Ziel-Servicerolle eine ausreichende Berechtigung für CodeBuild hat Weitere Informationen finden Sie in der Vertrauensbeziehung-Richtlinienanweisung unter Erstellen Sie eine CodeBuild Servicerolle.

Fehler: „Fehler beim Aufrufen von GetBucketAcl: Entweder hat sich der Bucket-Besitzer geändert oder die Servicerolle ist nicht mehr berechtigt, s3:GetBucketAcl aufzurufen“

Problem: Wenn Sie einen Build ausführen, erhalten Sie eine Fehlermeldung in Bezug auf die Änderung eines S3-Bucket-Eigentümers undGetBucketAcl-Berechtigungen

Mögliche Ursache: Du hast dass3:GetBucketAclunds3:GetBucketLocationBerechtigungen für Ihre IAM-Rolle. Diese Berechtigungen sichern den S3-Bucket Ihres Projekts und stellen Sie sicher, dass nur Sie Zugriff auf diesen haben. Nachdem Sie diese Berechtigungen hinzugefügt haben, hat sich der Besitzer des S3-Buckets geändert.

Empfohlene Lösung: Überprüfen Sie, ob Sie der Besitzer des S3-Buckets sind. Wenn dies der Fall ist, fügen Sie Ihrer IAM-Rolle die Berechtigungen erneut hinzu. Weitere Informationen finden Sie unter Sicherer Zugriff auf S3-Buckets.

Fehler: „Artefakte konnten nicht hochgeladen werden: Ungültiger arn“ beim Ausführen eines Builds

Problem: Wenn Sie einen Build ausführen, wird dieUPLOAD_ARTIFACTSBuild-Phase schlägt mit dem Fehler fehlFailed to upload artifacts: Invalid arnaus.

Mögliche Ursache: Ihr S3-Ausgabe-Bucket (der Bucket woAWS CodeBuildspeichert seine Ausgabe aus dem Build) befindet sich in einemAWSRegion anders als das CodeBuild-Build-Projekt.

Empfohlene Lösung: Aktualisieren Sie die Einstellungen des Build-Projekts, sodass diese auf einen Ausgabe-Bucket verweisen, der sich in demselben befindetAWSRegion als Build-Projekt.

Fehler: „Git-Klon ist fehlgeschlagen: Zugriff nicht möglich'your-repository-URL': Problem mit dem SSL-Zertifikat: Selbstsigniertes Zertifikat“

Problem: Wenn Sie versuchen, ein Build-Projekt auszuführen, schlägt der Build mit dieser Fehlermeldung fehl.

Mögliche Ursache: Ihr Quell-Repository verfügt über ein selbstsigniertes Zertifikat, Sie haben jedoch nicht gewählt, das Zertifikat als Teil Ihres Build-Projekts aus Ihrem S3-Bucket zu installieren.

Empfohlene Lösungen:

• Bearbeiten Sie Ihr Projekt. Für Certificate wählen Sie Install certificate from S3. Für Bucket of certificate wählen Sie den S3-Bucket, in dem Ihr SSL-Zertifikat gespeichert ist. Für Object key of certificate (Objektschlüssel des Zertifikats) geben Sie den Namen Ihres S3-Objektschlüssels ein.

• Bearbeiten Sie Ihr Projekt. Wählen Sie Insecure SSL (Unsicheres SSL), um SSL-Warnungen zu ignorieren, während Sie eine Verbindung zu Ihrem GitHub Enterprise Server-Projekt-Repository einrichten.

  Anmerkung

  Wir empfehlen, dass Sie Insecure SSL nur für Tests verwenden. Es sollte nicht in einer Produktionsumgebung verwendet werden.

Fehler: „Der Bucket, auf den Sie zugreifen möchten, muss mit dem angegebenen Endpunkt adressiert werden“ beim Ausführen eines Builds

Problem: Wenn Sie einen Build ausführen, wird dieDOWNLOAD_SOURCEBuild-Phase schlägt mit dem Fehler fehlThe bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpointaus.

Mögliche Ursache: Der vordefinierte Quellcode ist in einem S3-Bucket gespeichert, und dieser Bucket befindet sich in einemAWSAndere Region von derAWS CodeBuildBuild-Projekt.

Empfohlene Lösung: Aktualisieren Sie die Einstellungen des Build-Projekts, sodass diese auf einen Bucket verweisen, der Ihren vorgefertigten Quellcode enthält. Stellen Sie sicher, dass sich der Bucket im selben befindetAWSRegion als Build-Projekt.

Fehler: „Die Standardversion der Richtlinie wurde nicht durch die erweiterte Erstellung von Nullklickrollen erstellt oder war nicht die neueste Version, die durch die erweiterte Erstellung von Nullklickrollen erstellt wurde.“

Problem: Beim Versuch, ein -Projekt in der Konsole zu aktualisieren, schlug die Aktualisierung mit dieser Fehlermeldung fehl.

Mögliche Ursachen:

• Sie haben die Richtlinien, die der AWS CodeBuild-Ziel-Servicerolle angefügt sind, aktualisiert.

• Sie haben eine frühere Version einer Richtlinie ausgewählt, die der CodeBuild-Ziel-Servicerolle angefügt ist.

Empfohlene Lösungen:

• Bearbeiten Sie Ihr CodeBuild-Projekt und löschen Sie dasAllow CodeBuild, diese Servicerolle so zu ändern, dass sie mit diesem Build-Projekt verwendet werden kann. Überprüfen Sie, ob die von Ihnen verwendete CodeBuild-Servicerolle über ausreichende Berechtigungen verfügt. Wenn Sie Ihr CodeBuild-Projekt erneut bearbeiten, müssen Sie dieses Kontrollkästchen erneut deaktivieren. Weitere Informationen finden Sie unter Erstellen Sie eine CodeBuild Servicerolle.

• Befolgen Sie diese Schritte, um Ihr CodeBuild-Projekt so zu bearbeiten, dass eine neue Servicerolle verwendet wird:

  1. Öffnen Sie die IAM-Konsole und erstellen Sie eine neue Servicerolle. Weitere Informationen finden Sie unter Erstellen Sie eine CodeBuild Servicerolle.

  2. Öffnen SieAWS CodeBuild-Konsole beihttps://console.aws.amazon.com/codesuite/codebuild/homeaus.

  3. Wählen Sie im linken Navigationsbereich Build projects aus.

  4. Wählen Sie die Schaltfläche neben Ihrem Build-Projekt, dann Edit (Bearbeiten) und dann Environment (Umgebung).

  5. Wählen Sie für die Service role (Servicerolle) die von Ihnen erstellte Rolle aus.

  6. Wählen Sie Update environment (Umgebung aktualisieren).

Fehler: „Für dieses Build-Image müssen mindestens eine Laufzeitversion ausgewählt werden.“

Problem: Wenn Sie einen Build ausführen, wird dieDOWNLOAD_SOURCEBuild-Phase schlägt mit dem Fehler fehlYAML_FILE_ERROR: This build image requires selecting at least one runtime versionaus.

Mögliche Ursache: Ihr Build verwendet Version 1.0 oder höher des Amazon Linux 2 (AL2) -Standardabbilds oder Version 2.0 oder höher des Ubuntu-Standardabbilds und in der buildspec-Datei wird keine Laufzeit angegeben.

Empfohlene Lösung: Wenn Sie dasaws/codebuild/standard:2.0Von CodeBuild verwaltetes Image müssen Sie eine Laufzeitversion in derruntime-versions-Abschnitt der Build-Spezifikationsdatei. Sie können beispielsweise die folgende Build-Spezifikationsdatei für ein Projekt mit PHP verwenden:

version: 0.2

phases:
  install:
    runtime-versions:
        php: 7.3
  build:
    commands:
      - php --version
artifacts:
  files:
    -  README.md

Anmerkung

Wenn Sie einruntime-versionsverwenden und verwenden Sie ein anderes Bild als Ubuntu Standard Image 2.0 oder höher oder das Amazon Linux 2 (AL2) -Standardabbild 1.0 oder höher, der Build gibt die Warnung aus,“Skipping install of runtimes. Runtime version selection is not supported by this build image.“

Weitere Informationen finden Sie unter Specify runtime versions in the buildspec file.

Fehler: „IN DER WARTESCHLANGE: INSUFFICIENT_SUBNET“, wenn ein Build in einer Build-Warteschlange fehlschlägt

Problem: Ein Build in einer Build-Warteschlange schlägt fehl und es wird eine Fehlermeldung ähnlich wie angezeigtQUEUED: INSUFFICIENT_SUBNETaus.

Mögliche Ursachen: Der für Ihre VPC angegebene IPv4-CIDR-Block verwendet eine reservierte IP-Adresse. Die ersten vier sowie auch die letzte IP-Adresse in jedem Subnetz CIDR-Block stehen nicht zu Ihrer Verfügung und können daher keiner Instance zugewiesen werden. So sind beispielsweise in einem Subnetz mit dem CIDR-Block 10.0.0.0/24 die folgenden fünf IP-Adressen reserviert:

• 10.0.0.0:: Netzwerkadresse.

• 10.0.0.1: Von AWS für den VPC-Router reserviert.

• 10.0.0.2: Von reserviert AWS. Die IP-Adresse des DNS-Servers ist immer die Basis des VPC-Netzwerk-Bereichs plus zwei. Wir reservieren jedoch auch die Basis jedes Subnetzbereichs plus zwei. Für VPCs mit mehreren CIDR-Blöcken befindet sich die IP-Adresse des DNS-Servers im primären CIDR. Weitere Informationen finden Sie unter Amazon DNS-Server im Amazon VPC Benutzerhandbuch.

• 10.0.0.3: Von AWS für die spätere Verwendung reserviert.

• 10.0.0.255: Broadcast Adresse des Netzwerks. Wir unterstützen keinen Broadcast in eine VPC. Diese Adresse ist reserviert.

Empfohlene Lösungen: Überprüfen Sie, ob Ihre VPC eine reservierte IP-Adresse verwendet. Ersetzen Sie eine reservierte IP-Adresse durch eine IP-Adresse, die nicht reserviert ist. Weitere Informationen finden Sie unter Dimensionierung der VPC und der Subnetze im Amazon VPC Benutzerhandbuch.

Fehler: „Cache kann nicht heruntergeladen werden: RequestError: Sendeanfrage fehlgeschlagen verursacht durch: x509: Systemwurzeln konnten nicht geladen werden und es wurden keine Wurzeln bereitgestellt“

Problem: Wenn Sie versuchen, ein Build-Projekt auszuführen, schlägt der Build mit dieser Fehlermeldung fehl.

Mögliche Ursache: Sie haben die Zwischenspeicherung als Teil Ihres Build-Projekts konfiguriert und verwenden ein älteres Docker-Image mit einem abgelaufenen Stammzertifikat.

Empfohlene Lösung: Aktualisieren Sie das Docker-Image, das in Ihrem AWS CodeBuild-Projekt verwendet wird. Weitere Informationen finden Sie unter Von bereitgestellte Docker-Images CodeBuild.

Fehler: „Zertifikat kann nicht von S3 heruntergeladen werden. AccessDenied"

Problem: Wenn Sie versuchen, ein Build-Projekt auszuführen, schlägt der Build mit dieser Fehlermeldung fehl.

Mögliche Ursachen:

• Sie haben den falschen S3-Bucket für Ihr Zertifikat gewählt.

• Sie haben den falschen Objektschlüssel für Ihr Zertifikat eingegeben.

Empfohlene Lösungen:

• Bearbeiten Sie Ihr Projekt. Für Bucket of certificate wählen Sie den S3-Bucket, in dem Ihr SSL-Zertifikat gespeichert ist.

• Bearbeiten Sie Ihr Projekt. Für Object key of certificate (Objektschlüssel des Zertifikats) geben Sie den Namen Ihres S3-Objektschlüssels ein.

Fehler: „Anmeldeinformationen können nicht gefunden werden

Problem: Wenn du versuchst, dasAWS CLI, benutze einAWSSDK oder rufen Sie eine ähnliche Komponente als Teil eines Builds auf, erhalten Sie Build-Fehler, die sich direkt auf dieAWS CLI,AWSSDK oder Komponente. Sie könnten zum Beispiel eine Build-Fehlermeldung wie Unable to locate credentials erhalten.

Mögliche Ursachen:

• Die Version der AWS CLI, des AWS-SDK oder der Komponente in der Build-Umgebung ist nicht mit AWS CodeBuild kompatibel.

• Sie führen einen Docker-Container in einer Build-Umgebung aus, die Docker verwendet. Dieser Docker-Container hat standardmäßig keinen Zugriff auf die AWS-Anmeldeinformationen.

Empfohlene Lösungen:

• Stellen Sie sicher, dass Ihre Build-Umgebung mindestens folgende Version der AWS CLI, des AWS SDK oder der Komponente hat.

  • AWS CLI: 1.10.47

  • AWSSDK for C++: 0.2.19

  • AWSSDK for Go: 1.2.5

  • AWSSDK for Java: 1.11.16

  • AWSSDK für JavaScript: 2.4.7

  • AWSSDK for PHP: 3.18.28

  • AWSSDK for Python (Boto3): 1.4.0

  • AWSSDK for Ruby: 2.3.22

  • Botocore: 1.4.37

  • CoreCLR: 3.2.6-beta

  • Node.js: 2.4.7

• Wenn Sie einen Docker-Container in einer Build-Umgebung ausführen möchten und der Container dazu Zugriff auf AWS-Anmeldeinformationen benötigt, müssen Sie die Anmeldeinformationen von der Build-Umgebung auf den Container übertragen. Fügen Sie in Ihrer Build-Spezifikationsdatei wie in dem nachfolgenden Beispiel einen Docker-run-Befehl ein. In diesem Beispiel werden die verfügbaren S3-Buckets mit dem aws s3 ls Befehl aufgeführt. Mit der Option -e werden die erforderlichen Umgebungsvariablen übergeben, damit Ihr Container Zugriff auf die AWS-Anmeldeinformationen erhält.

  docker run -e AWS_DEFAULT_REGION -e AWS_CONTAINER_CREDENTIALS_RELATIVE_URI your-image-tag aws s3 ls

• Wenn Sie ein Docker-Image erstellen und der Build erfordertAWSAnmeldeinformationen (z. B. um eine Datei von Amazon S3 herunterzuladen), müssen Sie die Anmeldeinformationen wie nachfolgend beschrieben von der Build-Umgebung auf den Docker-Build-Prozess übertragen.

  1. Geben Sie in Ihrem Quellcode für das Dockerfile des Docker-Image die folgenden ARG-Anweisungen ein.

     ARG AWS_DEFAULT_REGION
     ARG AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

  2. Fügen Sie in Ihrer Build-Spezifikationsdatei wie in dem nachfolgenden Beispiel einen Docker-build-Befehl ein. Mit den Optionen --build-arg werden die Umgebungsvariablen festgelegt, die für Ihren Docker-Buildprozess erforderlich sind, um auf die AWS-Anmeldeinformationen zugreifen zu können.

     docker build --build-arg AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION --build-arg AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI -t your-image-tag .

RequestError-Timeout-Fehler beim Ausführen von CodeBuild in einem Proxy-Server

Problem: Du erhältst einRequestErrorFehler ähnlich einer der folgenden:

• RequestError: send request failed caused by: Post https://logs.<your-region>.amazonaws.com/: dial tcp 52.46.158.105:443: i/o timeoutvon CloudWatch Logs.

• Error uploading artifacts: RequestError: send request failed caused by: Put https://your-bucket.s3.your-aws-region.amazonaws.com/*: dial tcp 52.219.96.208:443: connect: connection refusedvon Amazon S3.

Mögliche Ursachen:

• ssl-bump ist nicht ordnungsgemäß konfiguriert.

• Die Sicherheitsrichtlinie Ihrer Organisation lässt nicht zu, dass Sie ssl_bump verwenden.

• Für Ihre Buildspec-Datei sind keine Proxy-Einstellungen mit einem proxy -Element angegeben.

Empfohlene Lösungen:

• Stellen Sie sicher, dass ssl-bump korrekt konfiguriert ist. Wenn Sie Squid als Proxy-Server verwenden, beachten Sie die Informationen im Abschnitt Konfigurieren von Squid als expliziter Proxy-Server.

• Gehen Sie folgendermaßen vor, um private Endpunkte für Amazon S3 und CloudWatch Logs zu verwenden:

  1. Entfernen Sie in der Routing-Tabelle Ihres privaten Subnetzes die von Ihnen hinzugefügte Regel, die für das Internet bestimmten Datenverkehr an Ihren Proxy-Server weiterleitet. Weitere Informationen finden Sie unterErstellen eines Subnetzes in Ihrer VPCimAmazon VPC User Guideaus.

  2. Erstellen Sie einen privaten Amazon S3 S3-Endpunkt und CloudWatch Logs Logs-Endpunkt und verknüpfen Sie sie mit dem privaten Subnetz Ihrer Amazon VPC. Weitere Informationen finden Sie unterVPC-Endpunkt-ServicesimAmazon VPC User Guideaus.

  3. BestätigenAktivieren Sie Private DNS-Namenin Ihrer Amazon VPC ist ausgewählt. Weitere Informationen finden Sie unter Erstellung eines Schnittstellenendpunkts im Amazon VPC Benutzerhandbuch.

• Wenn Sie für einen expliziten Proxy-Server kein ssl-bump verwenden, fügen Sie Ihrer Buildspec-Datei mithilfe eines proxy -Elements eine Proxy-Konfiguration hinzu. Weitere Informationen finden Sie unter Führen Sie CodeBuild in einem expliziten Proxy-Server aus und Syntax der Build-Spezifikation.

  version: 0.2
  proxy:
    upload-artifacts: yes
    logs: yes
  phases:
    build:
      commands:

Die Bourne-Shell (sh) muss in Build-Images vorhanden sein

Problem: Sie verwenden ein Build-Image, das nicht von bereitgestellt wirdAWS CodeBuild, und Ihre Builds scheitern mit der NachrichtBuild container found dead before completing the buildaus.

Mögliche Ursache: Die Bourne Muschel (sh) ist nicht in Ihrem Build-Image enthalten. CodeBuild-Anforderungenshum Build-Befehle und -Skripte auszuführen.

Empfohlene Lösung: WennshWenn nicht in Ihrem Build-Image enthalten ist, sollte es eingefügt werden, bevor Sie das Image in einem anderen Build verwenden. (CodeBuild enthält bereitssh) in seinen Build-Images.)

Warnung: „Die Installation von Laufzeiten überspringen. Die Auswahl der Laufzeitversion wird von diesem Build-Image nicht unterstützt“ beim Ausführen eines Builds

Problem: Wenn Sie einen Build ausführen, enthält das Build-Protokoll diese Warnung.

Mögliche Ursache: Ihr Build verwendet nicht Version 1.0 oder höher des Amazon Linux 2 (AL2) -Standardabbilds oder Version 2.0 oder höher des Ubuntu-Standardabbilds und in einemruntime-versions-Abschnitt in Ihrer Buildspec-Datei.

Empfohlene Lösung: Stellen Sie sicher, dass Ihre buildspec-Datei keine enthältruntime-versionsAbschnitts erstellt. Dieruntime-versions-Abschnitt ist nur erforderlich, wenn Sie das Amazon Linux 2 (AL2) -Standardabbild oder höher oder das Ubuntu-Standardabbild, Version 2.0 oder höher, verwenden.

Fehler: „Die JobWorker-Identität kann nicht überprüft werden“ beim Öffnen der CodeBuild-Konsole

Problem: Wenn Sie die CodeBuild-Konsole öffnen, wird die Fehlermeldung „JobWorker-Identität nicht überprüft“ angezeigt.

Mögliche Ursache: Die IAM-Rolle, die für den Konsolenzugriff verwendet wird, hat ein Tag mitjobIdals Schlüssel. Dieser Tag-Schlüssel ist für CodeBuild reserviert und verursacht diesen Fehler, wenn er vorhanden ist.

Empfohlene Lösung: Ändern Sie alle benutzerdefinierten IAM-Rollen-Tags, die den Schlüssel habenjobIdum einen anderen Schlüssel zu haben, wiejobIdentifieraus.

Build konnte nicht gestartet werden

Problem: Wenn Sie einen Build starten, erhalten Sie eineBuild konnte nicht gestartet werdenFehlermeldung.

Mögliche Ursache: Die Anzahl der gleichzeitigen Builds wurde erreicht.

Empfohlene Lösungen: Warten Sie, bis andere Builds abgeschlossen sind, oder erhöhen Sie das gleichzeitige Build-Limit für das Projekt und starten Sie den Build erneut. Weitere Informationen finden Sie unter Konfiguration des Projekts.

Zugriff auf GitHub-Metadaten in lokal zwischengespeicherten Builds

Problem: In einigen Fällen ist das .git-Verzeichnis in einem zwischengespeicherten Build eine Textdatei und kein Verzeichnis.

Mögliche Ursachen: Wenn das lokale Quell-Caching für einen Build aktiviert ist, erstellt CodeBuild einen Gitlink für.git-Verzeichnis Dies bedeutet, dass der.gitVerzeichnis ist eigentlich eine Textdatei, die den Pfad zum Verzeichnis enthält.

Empfohlene Lösungen: Verwenden Sie in allen Fällen den folgenden Befehl, um das Git-Metadatenverzeichnis abzurufen. Dieser Befehl funktioniert unabhängig vom Format von.git:

git rev-parse --git-dir

AccessDenied: Der Bucket-Besitzer der Berichtsgruppe stimmt nicht mit dem Besitzer des S3-Bucket-Eigentümers überein...

Problem: Beim Hochladen von Testdaten in einen Amazon S3 S3-Bucket kann CodeBuild die Testdaten nicht in den Bucket schreiben.

Mögliche Ursachen:

• Das für den Bucket-Besitzer der Berichtsgruppe angegebene Konto stimmt nicht mit dem Eigentümer des Amazon S3 S3-Buckets überein.

• Die Servicerolle hat keinen Schreibzugriff auf den Bucket.

Empfohlene Lösungen:

• Ändern Sie den Bucket-Besitzer der Berichtsgruppe so, dass er dem Besitzer des Amazon S3 S3-Buckets entspricht.

• Ändern Sie die Servicerolle, um Schreibzugriff auf den Amazon S3 S3-Bucket zu ermöglichen.