Fehlerbehebung AWS CodeBuild

Verwenden Sie die Informationen in diesem Thema, um Fehler zu identifizieren, zu diagnostizieren und zu beheben. Informationen zum Protokollieren und Überwachen von CodeBuild Builds zur Behebung von Problemen finden Sie unter Protokollierung und Überwachung.

Apache Maven erstellt Referenzartefakte aus dem falschen Repository

Problem: Wenn Sie Maven mit einer von bereitgestellten Java AWS CodeBuild-Build-Umgebung verwenden, ruft Maven Build- und Plugin-Abhängigkeiten aus dem sicheren zentralen Maven-Repository unter https://repo1.maven.org/maven2 ab. Das passiert auch dann, wenn die Datei pom.xml des Build-Projekts explizit die Verwendung anderer Verzeichnisse angibt.

Mögliche Ursache: CodeBuild Von bereitgestellte Java-Build-Umgebungen enthalten eine Datei mit dem Namen settings.xml, die im /root/.m2 Verzeichnis der Build-Umgebung vorinstalliert ist. 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. Weisen Sie in der -installPhase Ihres Build-Projekts CodeBuild an, Ihre settings.xml Datei in das /root/.m2 Verzeichnis der Build-Umgebung zu kopieren. 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

Issue: 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 CodeBuild führt alle Build-Befehle als Root-Benutzer aus.

Empfohlene Lösung: Keine.

Builds können fehlschlagen, wenn Dateinamen nicht in den USA liegen. Englische Zeichen

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

Mögliche Ursache: Bei Build-Umgebungen, die von bereitgestellt AWS CodeBuild werden, ist ihr Standardgebietsschema auf festgelegtPOSIX. -POSIXStandorteinstellungen sind weniger kompatibel mit - CodeBuild und -Dateinamen, die Nicht-USA enthalten. Englische Zeichen und können dazu führen, dass zugehörige Builds fehlschlagen.

Empfohlene Lösung: Fügen Sie die folgenden Befehle zum Abschnitt pre_build Ihrer Build-Spezifikationsdatei hinzu. Diese Befehle machen die Build-Umgebung zur Verwendung von UTF-8 in US-Englisch für ihre Lokalisierungseinstellungen, das mit - CodeBuild und -Dateinamen, die Nicht-USA enthalten, besser kompatibel ist. Englische Zeichen.

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, die auf Amazon Linux basieren:

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

Builds können fehlschlagen, wenn Parameter aus dem Amazon EC2 Parameter Store abgerufen werden

Problem: Wenn ein Build versucht, den Wert eines oder mehrerer Parameter abzurufen, die im Amazon EC2 Parameter Store gespeichert sind, schlägt der Build in der -DOWNLOAD_SOURCEPhase mit dem Fehler fehlParameter does not exist.

Mögliche Ursache: Die Servicerolle, auf die das Build-Projekt angewiesen ist, verfügt nicht über die Berechtigung zum Aufrufen der ssm:GetParameters Aktion oder das Build-Projekt verwendet eine Servicerolle, die von generiert wird AWS CodeBuild und den Aufruf der ssm:GetParameters Aktion ermöglicht, aber die Parameter haben Namen, die nicht mit beginnen/CodeBuild/.

Empfohlene Lösungen:

• Wenn die Servicerolle nicht von generiert wurde CodeBuild, aktualisieren Sie ihre Definition, damit die ssm:GetParameters Aktion CodeBuild aufrufen kann. 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 Servicerolle von generiert wurde CodeBuild, aktualisieren Sie ihre Definition, um den Zugriff auf Parameter im Amazon EC2 Parameter Store CodeBuild mit anderen Namen als denen zu ermöglichen, die mit beginnen/CodeBuild/. 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 Verzweigungsfilteroption ist in der Konsole nicht verfügbar, wenn Sie ein - AWS CodeBuild Projekt erstellen oder aktualisieren.

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 CodeBuild-Build auslösen.

Empfohlene Lösung: Um einen Verzweigungsfilter zu migrieren, den Sie vor der Einführung von Webhook-Filtern erstellt haben, erstellen Sie eine Webhook-Filtergruppe mit einem HEAD_REF-Filter mit dem regulären Ausdruck ^refs/heads/branchName$. 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-Ereignisse und Filtern von GitHub Webhook-Ereignissen (Konsole).

Erfolg oder Misserfolg der Build-Erstellung wird nicht angezeigt

Problem: Erfolg oder Misserfolg einer wiederholten Build-Erstellung wird nicht angezeigt.

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

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

Build-Status wird nicht an den Quellanbieter gemeldet

Problem: Nachdem Sie einem Quellanbieter wie GitHub oder Bitbucket Build-Statusberichte gewährt haben, wird der Build-Status nicht aktualisiert.

Mögliche Ursache: Der dem Quellanbieter zugeordnete Benutzer hat keinen Schreibzugriff auf das Repo.

Empfohlene Lösungen: Um den Build-Status an den Quellanbieter melden zu können, muss der dem Quellanbieter zugeordnete 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 Quellanbieter.

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: Sie verwenden eine - AWS Region, die dieses Image nicht unterstützt.

Empfohlene Lösungen: Verwenden Sie eine der folgenden AWS Regionen, 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 (Irland)

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

Problem: Die Ergebnisse von einem oder mehreren Befehlen in der Build-Spezifikationsdatei werden von nachfolgenden Befehlen in derselben Build-Spezifikationsdatei 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 Build-Spezifikationsdateiversion 0.1 führt AWS CodeBuild 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: „Access denied“ (Zugriff verweigert) beim Versuch, den Cache herunterzuladen

Problem: Beim Versuch, den Cache für ein Build-Projekt herunterzuladen, das den Cache aktiviert hat, wird eine Access denied-Fehlermeldung angezeigt.

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 von verwendete Servicerolle CodeBuild verfügt nicht über - s3:GetObject und -s3:PutObjectBerechtigungen für den S3-Bucket, der den Cache enthält.

Empfohlene Lösung: Bei der ersten Verwendung ist es normal, diese Fehlermeldung 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 unter Angeben von S3-Berechtigungen im Amazon S3-Entwicklerhandbuch.

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

Problem: Wenn Sie versuchen, Builds auszuführen, die benutzerdefinierte Build-Images verwenden, erhalten Sie die Fehlermeldung BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE.

Mögliche Ursache: Die Gesamtgröße des Build-Images ist größer als der verfügbare Speicherplatz des Datenverarbeitungstyps der Build-Umgebung. 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 Datenverarbeitungsmodi und -typen für Build-Umgebungen.

Empfohlene Lösung: Verwenden Sie einen größeren Datenverarbeitungstyp mit mehr verfügbarem Speicherplatz oder reduzieren Sie die Größe Ihres benutzerdefinierten Build-Images.

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

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

Mögliche Ursache: Das angeforderte Amazon-ECR-Image ist in der AWS Region, die Ihr AWS Konto verwendet, nicht verfügbar.

Empfohlene Lösung: Verwenden Sie ein Amazon-ECR-Image, das sich in derselben AWS Region befindet wie das, das Ihr AWS Konto verwendet.

Mögliche Ursache: Sie verwenden eine private Registrierung in einer VPC, die keinen öffentlichen Internetzugang hat. CodeBuild kann kein Image von einer privaten IP-Adresse in einer VPC abrufen. Weitere Informationen finden Sie unter Private Registrierung mit AWS 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 öffentlichen Internetzugang verfügt.

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

Empfohlene Lösung: Verwenden Sie eine private Docker-Hub-Registrierung oder erhalten Sie Ihr Image von Amazon ECR. Weitere Informationen zur Verwendung einer privaten Registrierung finden Sie unter Private Registrierung mit AWS Secrets Manager Beispiel für CodeBuild. Weitere Informationen zur Verwendung von Amazon ECR finden Sie unter Amazon-ECR-Beispiel für CodeBuild .

Fehler: „Build-Container vor Abschluss des Builds tot gefunden. Der Build-Container ist gestorben, weil er nicht genügend Speicher hatte oder das Docker ErrorCode-Image nicht unterstützt wird.“

Problem: Wenn Sie versuchen, einen Microsoft-Windows- oder Linux-Container in zu verwenden AWS CodeBuild, tritt dieser Fehler während der PROVISIONING-Phase auf.

Mögliche Ursachen:

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

• 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 ist nicht erfolgreich und Sie erhalten eine Fehlermeldung ähnlich Cannot 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 den Build nicht im privilegierten Modus aus.

Empfohlene Lösung: Um diesen Fehler zu beheben, müssen Sie den privilegierten Modus aktivieren und Ihre Build-Spezifikation mithilfe der folgenden Anweisungen aktualisieren.

Gehen Sie folgendermaßen vor, 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 und dann Ihr Build-Projekt aus.

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

4. Wählen Sie Additional configuration (Zusätzliche Konfiguration).

5. Wählen Sie unter Privilegiert die Option Dieses Flag aktivieren aus, wenn Sie Docker-Images erstellen möchten oder möchten, dass Ihre Builds erhöhte Berechtigungen erhalten.

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

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

Sie müssen auch den Docker-Daemon in Ihrem Container starten. Die install Phase Ihrer Build-Spezifikation könnte in etwa so aussehen.

phases:
  install:
    commands:
      - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
      - timeout 15 sh -c "until docker info; do echo .; sleep 1; done"

Weitere Informationen über die OverlayFS-Speichertreiber, auf die in der Build-Spezifikationsdatei verwiesen wird, finden Sie auf der Docker-Website unter Verwenden des OverlayFS-Speichertreibers.

Anmerkung

Wenn das Basis-Betriebssystem Alpine Linux ist,fügen Sie in buildspec.yml das Argument -t zu timeout hinzu:

- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"

Weitere Informationen zum Erstellen und Ausführen eines Docker-Images mithilfe von finden Sie AWS CodeBuild unter Docker im benutzerdefinierten Image-Beispiel für CodeBuild .

Fehler: „CodeBuild ist nicht zur Ausführung autorisiert: sts:AssumeRole“ beim Erstellen oder Aktualisieren eines Build-Projekts

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

Mögliche Ursachen:

• Die 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.

• Die dem Build-Projekt zugeordnete AWS CodeBuild Servicerolle ist nicht vorhanden oder verfügt nicht über ausreichende Berechtigungen, um zu vertrauen CodeBuild.

Empfohlene Lösungen:

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

• Stellen Sie sicher, dass die CodeBuild Zielservicerolle in Ihrem AWS Konto vorhanden ist. 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 Zielservicerolle über ausreichende Berechtigungen verfügt, um zu vertrauen CodeBuild. 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-Eigentümer geändert oder die Servicerolle hat keine Berechtigung mehr zum Aufrufen von s3:GetBucketAcl“

Problem: Ihnen wird beim Ausführen eines Builds eine Fehlermeldung in Bezug auf die Änderung eines S3-Bucket-Eigentümers und von GetBucketAcl-Berechtigungen angezeigt.

Mögliche Ursache: Sie haben die s3:GetBucketLocation Berechtigungen s3:GetBucketAcl und zu Ihrer IAM-Rolle hinzugefügt. 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 Besitzer des S3-Buckets sind, und fügen Sie dann Ihrer IAM-Rolle erneut Berechtigungen hinzu. Weitere Informationen finden Sie unter Sicherer Zugriff auf S3-Buckets.

Fehler: „Failed to upload artifacts: Invalid arn” beim Ausführen eines Builds

Problem: Beim Ausführen eines Builds schlägt die Build-Phase UPLOAD_ARTIFACTS mit der Fehlermeldung Failed to upload artifacts: Invalid arn fehl.

Mögliche Ursache: Ihr S3-Ausgabe-Bucket (der Bucket, in dem seine Ausgabe aus dem Build AWS CodeBuild speichert) befindet sich in einer anderen - AWS Region als das CodeBuild Build-Projekt.

Empfohlene Lösung: Aktualisieren Sie die Einstellungen des Build-Projekts so, dass sie auf einen Ausgabe-Bucket verweisen, der sich in derselben AWS Region wie das Build-Projekt befindet.

Fehler: „Git clone failed: Unable to access 'your-repository-URL': SSL certificate problem: Self signed certificate“

Problem: Beim Versuch, 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 angegeben, dass das Zertifikat aus Ihrem S3-Bucket als Teil Ihres Build-Projekts installiert werden soll.

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 SSL unsicher aus, um SSL-Warnungen zu ignorieren, während Sie eine Verbindung zu Ihrem GitHub Enterprise Server-Projekt-Repository herstellen.

  Anmerkung

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

Fehler: „The bucket you are attempting to access must be addressed using the specified endpoint” beim Ausführen eines Builds

Problem: Beim Ausführen eines Builds schlägt die Build-Phase DOWNLOAD_SOURCE mit der Fehlermeldung The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint fehl.

Mögliche Ursache: Ihr vorgefertigter Quellcode wird in einem S3-Bucket gespeichert und dieser Bucket befindet sich in einer anderen - AWS Region als das AWS CodeBuild Build-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 in derselben AWS Region wie das Build-Projekt befindet.

Fehler: "This build image requires selecting at least one runtime version."

Problem: Beim Ausführen eines Builds schlägt die Build-Phase DOWNLOAD_SOURCE mit der Fehlermeldung YAML_FILE_ERROR: This build image requires selecting at least one runtime version fehl.

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 das aws/codebuild/standard:2.0 CodeBuild verwaltete Image verwenden, müssen Sie eine Laufzeitversion im runtime-versions Abschnitt der buildspec-Datei angeben. 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 einen runtime-versions Abschnitt angeben und ein anderes Image als Ubuntu Standard Image 2.0 oder höher oder das Amazon Linux 2 (AL2) Standard-Image 1.0 oder höher verwenden, gibt der Build die Warnung „“ ausSkipping 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: "QUEUED: 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 QUEUED: INSUFFICIENT_SUBNET angezeigt.

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: Reserviert von AWS für den VPC-Router.

• 10.0.0.2: Reserviert von 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: Reserviert von AWS für die zukünftige Verwendung.

• 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 konnte nicht heruntergeladen werden: RequestError: Die Sendeanforderung ist fehlgeschlagen, verursacht durch: x509: System-Roots konnten nicht geladen werden und es wurden keine Roots angegeben“

Problem: Beim Versuch, ein Build-Projekt auszuführen, schlägt der Build mit dieser Fehlermeldung fehl.

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

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

Fehler: „Zertifikat konnte nicht von S3 heruntergeladen werden AccessDenied.“

Problem: Beim Versuch, 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: „Unable to locate credentials“

Problem: Wenn Sie versuchen, die auszuführen AWS CLI, ein AWS SDK zu verwenden oder eine andere ähnliche Komponente als Teil eines Builds aufzurufen, erhalten Sie Build-Fehler, die sich direkt auf die AWS CLI, das AWS SDK oder die Komponente beziehen. Sie könnten zum Beispiel eine Build-Fehlermeldung wie Unable to locate credentials erhalten.

Mögliche Ursachen:

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

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

Empfohlene Lösungen:

• Stellen Sie sicher, dass Ihre Build-Umgebung über die folgende Version oder höher des AWS CLI, AWS SDK oder der Komponente verfügt.

  • AWS CLI: 1.10.47

  • AWS SDK für C++: 0.2.19

  • AWS SDK für Go: 1.2.5

  • AWS SDK für Java: 1.11.16

  • AWS SDK für JavaScript: 2.4.7

  • AWS SDK für PHP: 3.18.28

  • AWS SDK für Python (Boto3): 1.4.0

  • AWS SDK für 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üssen und der Container AWS Anmeldeinformationen erfordert, müssen Sie die Anmeldeinformationen von der Build-Umgebung an den Container übergeben. 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. Die -e Option durchläuft die Umgebungsvariablen, die Ihr Container für den Zugriff auf AWS Anmeldeinformationen benötigt.

  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 AWS Anmeldeinformationen erfordert (z. B. um eine Datei von Amazon S3 herunterzuladen), müssen Sie die Anmeldeinformationen wie folgt aus der Build-Umgebung an den Docker-Build-Prozess übergeben.

  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. Die --build-arg Optionen legen die Umgebungsvariablen fest, die für Ihren Docker-Build-Prozess für den Zugriff auf die AWS Anmeldeinformationen erforderlich sind.

     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 auf einem Proxy-Server

Problem: Sie erhalten eine RequestError-Fehlermeldung ä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 timeout aus 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 refused aus 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 wie folgt 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 unter Erstellen eines Subnetzes in Ihrer VPC im Amazon-VPC-Benutzerhandbuch.

  2. Erstellen Sie einen privaten Amazon S3-Endpunkt und einen CloudWatch Logs-Endpunkt und verknüpfen Sie sie mit dem privaten Subnetz Ihrer Amazon VPC. Weitere Informationen finden Sie unter VPC-Endpunktservices im Amazon-VPC-Benutzerhandbuch.

  3. Bestätigen Sie, dass Private DNS-Name in Ihrer Amazon VPC aktivieren ausgewählt ist. Weitere Informationen finden Sie unter Erstellung eines Schnittstellenendpunkts im Benutzerhandbuch für Amazon VPC.

• 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 wird AWS CodeBuild, und Ihre Builds schlagen mit der Nachricht fehlBuild container found dead before completing the build.

Mögliche Ursache: Die Bourne-Shell (sh) ist nicht in Ihrem Build-Image enthalten. CodeBuild benötigt sh, um Build-Befehle und Skripts auszuführen.

Empfohlene Lösung: Wenn sh in Ihrem Build-Image nicht vorhanden ist, müssen Sie es unbedingt einschließen, bevor Sie weitere Builds starten, die Ihr Image verwenden. (schließt CodeBuild bereits sh in die Build-Images ein.)

Warnung: „Skipping install of runtimes. runtime version selection is not supported by this build image“ beim Ausführen eines Builds

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

Mögliche Ursache: Ihr Build verwendet nicht Version 1.0 oder höher des Amazon Linux 2 (AL2)-Standard-Images oder Version 2.0 oder höher des Ubuntu-Standard-Images und eine Laufzeit ist in einem runtime-versions Abschnitt in Ihrer buildspec-Datei angegeben.

Empfohlene Lösung: Stellen Sie sicher, dass Ihre buildspec-Datei keinen runtime-versions-Abschnitt enthält. Der runtime-versions Abschnitt ist nur erforderlich, wenn Sie das Amazon Linux 2 (AL2)-Standard-Image oder höher oder die Ubuntu-Standard-Image-Version 2.0 oder höher verwenden.

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

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

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

Empfohlene Lösung: Ändern Sie alle benutzerdefinierten IAM-Rollen-Tags, die den Schlüssel haben, jobId so, dass sie einen anderen Schlüssel haben, z. B. jobIdentifier.

Build konnte nicht gestartet werden

Problem: Beim Starten eines Builds erhalten Sie die Fehlermeldung Build konnte nicht gestartet werden.

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 Limit für gleichzeitige Builds für das Projekt und starten Sie den Build erneut. Weitere Informationen finden Sie unter Projektkonfiguration.

Zugreifen 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, CodeBuild erstellt einen Gitlink für das .git Verzeichnis . Das bedeutet, dass das .git Verzeichnis tatsächlich eine Textdatei ist, 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-Eigentümer für die Berichtsgruppe stimmt nicht mit dem Eigentümer des S3-Buckets überein...

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

Mögliche Ursachen:

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

• Die Servicerolle hat keinen Schreibzugriff auf den Bucket.

Empfohlene Lösungen:

• Ändern Sie den Bucket-Eigentümer der Berichtsgruppe so, dass er mit dem Eigentümer des Amazon S3-Buckets übereinstimmt.

• Ändern Sie die Servicerolle, um Schreibzugriff auf den Amazon S3-Bucket zu gewähren.