Oracle Cloud Infrastructure-Dokumentation

Fehler in DevOps beheben

Mit den Informationen zur Fehlerbehebung können Sie allgemeine Probleme erkennen und beheben, die beim Arbeiten mit dem DevOps-Service auftreten können.

Anwendungen in OKE bereitstellen

Der Schritt zum Anwenden des Kubernetes-Manifests verläuft aufgrund mehrerer Fehler nicht erfolgreich.

Autorisierungsfehler:

Das Cluster ist nicht vorhanden, oder die dynamische Gruppe und die Policy, die der Pipelineressource Zugriff auf andere Oracle Cloud Infrastructure-(OCI-)Ressourcen im Compartment erteilt, fehlen.

Prüfen Sie, ob relevante OCI-Ressourcen vorhanden sind und ob eine dynamische Gruppe für die Pipelineressource des OCI-DevOps-Deployments erstellt wurde sowie eine Policy, die dieser dynamischen Gruppe Zugriff auf relevante OCI-Ressourcen erteilt.

Beispiel: Erstellen Sie eine dynamische Gruppe für die Deployment-Pipeline. Sie können die dynamische Gruppe als DeployDynamicGroup benennen und compartmentOCID durch die OCID Ihres Compartments ersetzen: All {resource.type = 'devopsdeploypipeline', resource.compartment.id = 'compartmentOCID'}

Erstellen Sie eine IAM-Policy, die der dynamischen Gruppe Zugriff auf alle Ressourcen erteilt: Allow dynamic-group DeployDynamicGroup to manage all-resources in compartment <compartment_name>

Siehe DevOps-IAM-Policys.

Fehlendes Protokollfeld:

Folgende Fehlermeldung wird Ihnen möglicherweise angezeigt: io.kubernetes.client.openapi.ApiException: class V1Status { apiVersion: v1 code: 500 details: null kind: Status message: failed to create typed patch object: .spec.template.spec.containers[name=\"helloworld\"].ports: element 0: associative list with keys has an element that omits key field \"protocol\" metadata: class V1ListMeta { _continue: null remainingItemCount: null resourceVersion: null selfLink: null } reason: null status: Failure }

Das Kubernetes-Manifest muss ein Protokollfeld aufweisen, wenn der Containerport definiert ist.

Dieses Problem ist ein vorhandener Bug für Kubernetes Server-side Apply für Clusterversionen unter 1.20. Weitere Informationen finden Sie in den Problemen 130 und 92332.

Sie müssen ein Protokollfeld hinzufügen, wenn ein Containerport definiert ist.

Socket Timeout:

Folgende Fehlermeldung wird Ihnen möglicherweise angezeigt: io.kubernetes.client.openapi.ApiException: java.net.SocketTimeoutException: connect timed out

Dieser Fehler kann auftreten, wenn der öffentliche Kubernetes-Endpunkt nicht erreichbar ist oder nicht verbunden werden kann.

Der Kubernetes-API-Endpunkt muss eine gültige erreichbare Adresse sein. Für einen gültigen öffentlichen IP-Endpunkt müssen Sie die Netzwerkkonfiguration des Clusters prüfen. Siehe Beispiele.

Der Deployment-Status ist wegen eines Timeouts nicht erfolgreich:

Dies kann auftreten, wenn die Dauer des Kubernetes-Deployments die Ablauffrist überschreitet.

Die Ablauffrist für Kubernetes beträgt standardmäßig 600 Sekunden. Siehe Ablauffrist in Sekunden.

Wenn das Rollout von Pods des K8s-Deployments innerhalb dieser Frist nicht erfolgreich ausgeführt werden kann, wird diese Fehlermeldung in den Deployment-Logs angezeigt. Weitere Informationen finden Sie unter Nicht erfolgreiches Deployment.

Prüfen Sie die Logs für diese Pods im Cluster.

Fehler beim Sicherheitslückenaudit

Schritt VulnerabilityAudit ist in der Phase "Verwalteter Build" nicht erfolgreich.

Ungültige pom.xml-Dateikonfiguration oder Client-JAR-Datei kann pom.xml-Dateien nicht verarbeiten:

Die JAR-Datei des Application Dependency Management-(ADM-)Maven-Clients kann die Stückliste (Payload zum Erstellen des Schrittes VulnerabilityAudit) nicht erstellen, da die pom.xml-Dateikonfiguration ungültig ist oder die Client-JAR-Datei die pom.xml-Dateien nicht verarbeiten kann.

  1. Korrigieren und validieren Sie die pom.xml-Datei.
  2. Öffnen Sie eine Serviceanfrage.

Timeout oder Fehler in Schritt VulnerabilityAudit:

Der Schritt VulnerabilityAudit wird erstellt, erreicht jedoch aufgrund eines Timeouts oder Fehlers im Schritt VulnerabilityAudit nie einen erfolgreichen endgültigen Status.

Öffnen Sie eine Serviceanfrage, wenn ein Fehler aufgetreten ist.

Validierungsfehler:

Validierungsfehler können auftreten, wenn in der Build-Spezifikationsdatei ein falscher Wert für knowledgeBaseId oder vulnerabilityCompartmentId eingegeben wird.

Prüfen Sie die Werte in der Datei build spec.

IAM-Policys nicht definiert:

Der Schritt VulnerabilityAudit ist möglicherweise nicht erfolgreich, wenn keine Policys definiert sind, damit die Build-Pipeline auf die ADM-Ressourcen zugreifen kann.

Definieren Sie Policys für den Zugriff auf die ADM-Ressourcen.

Serverfehler:

Servicefehler können aufgrund eines vorübergehenden Ausfalls auftreten.

Öffnen Sie eine Serviceanfrage.

Private Verbindung konfigurieren

Build-Ausführung verläuft bei verschiedenen Schritten konsistent nicht erfolgreich.

Build-Ausführung verläuft beim Schritt "Privaten Zugriff durch Provisioning bereitstellen" nicht erfolgreich:

Folgende Fehlermeldung wird möglicherweise angezeigt: Setup des privaten Zugriffs war nicht erfolgreich, weil subnetId oder nsgId nicht authentifiziert oder nicht gefunden wurde.

Dies kann auftreten, wenn die Identity and Access Management-(IAM-)Policys falsch sind oder wenn die während der Konfiguration angegebenen Werte für subnetId oder nsgId ungültig sind.

Je nach Fehlerursache ist eine der folgenden Lösungen möglich:

  1. Schreiben Sie korrekte IAM-Policys. Policy-Beispiele finden Sie unter Build-Policys.
  2. Prüfen Sie, ob die Werte subnetId und nsgId korrekt sind.

Build-Ausführung verläuft beim Schritt "Softwareumgebung einrichten" konsistent nicht erfolgreich:

Möglicherweise kann das Zertifikats-Bundle für die Build-Quelle <source> und die caBundleId <Oracle Cloud-ID (OCID) des CA-Bundles> nicht aus Zertifikatservice abgerufen werden.

Dies kann auftreten, wenn das IAM-Policy-Setup für die Build-Pipeline für den Zugriff auf das Zertifikat falsch ist oder Sie eine falsche caBundleId in der Verbindungsressource konfiguriert haben.

Je nach Fehlerursache ist eine der folgenden Lösungen möglich:

  1. Schreiben Sie korrekte IAM-Policys. Policy-Beispiele finden Sie unter Build-Policys.
  2. Überprüfen Sie die caBundleId, und korrigieren Sie sie in der externen Verbindungsressource.

Build-Ausführung verläuft im Schritt "Quelle herunterladen" konsistent nicht erfolgreich:

Wenn die URL korrekt und für den Repository-Server ein selbstsigniertes Zertifikat installiert ist, prüfen Sie TLSVerifyConfiguration in der Verbindungsressource.

Eine andere Ursache könnte sein, dass Sie einen Repository-Server konfiguriert haben, für den das SSL-Zertifikat nicht bekannt ist.

Befolgen Sie die angegebenen Schritte, und konfigurieren Sie die Transport Layer Security-(TLS-)Verifizierung in der externen Verbindungsressource:

  1. Rufen Sie das Certificate-Authority-(CA-)Zertifikat wie folgt ab: echo -n | openssl s_client -connect <host>:<port> | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ca.pem
  2. Laden Sie das Zertifikat in die CA-Bundle-Ressource hoch.
  3. Konfigurieren Sie beim Erstellen einer externen Verbindungsressource TLSVerifyConfiguration, indem Sie die erstellte CA-Bundle-Ressource auswählen.

Build-Ausführung verläuft beim Schritt "Quelle herunterladen" konsistent nicht erfolgreich:

Folgende Fehlermeldung wird möglicherweise angezeigt: Auf das Repository <repo-URL> kann nicht zugegriffen werden/Herstellen der Verbindung mit <repo-ID und Portnummer> verläuft nicht erfolgreich.

Dies kann auftreten, wenn die in einer der buildSource in buildStage konfigurierte Repository-URL für den Build Runner nicht erreichbar ist.

Prüfen Sie, ob die konfigurierte Repository-URL korrekt ist, und konfigurieren Sie den privaten Zugriff, wenn die Repository-URL eine private IP ist.

Build-Ausführung verläuft beim Schritt "Softwareumgebung einrichten", "Quelle herunterladen" oder einem der "Kundenschritte in Build-Spezifikationsdatei" konsistent nicht erfolgreich.:

Eine der folgenden Fehlermeldungen wird möglicherweise angezeigt:
  1. Interner Fehler. Tritt beim Fehler im Schritt setup_software_env auf.
  2. Kein Zugriff auf das Repository. Tritt beim Fehler der Downloadquelle auf.
  3. Netzwerkfehler in Kundenlogs.

Dies kann auftreten, wenn Sie das virtuelle Cloud-Netzwerk (VCN) nicht korrekt eingerichtet haben.

Wenn Sie den privaten Zugriff konfigurieren, wird der ausgehende Traffic der Build Runner-VM vom VCN gesteuert. Die interne DNS-(Domain Name System-)Auflösung von VCNs wird für den privaten Zugriff nicht unterstützt. Verwenden Sie IPs für die Kommunikation mit Services, die im privaten Netzwerk gehostet werden. Für das VCN (Subnetz), in dem Sie den privaten Zugriff konfigurieren, müssen die folgenden Voraussetzungen erfüllt sein:

  1. Das konfigurierte VCN muss entweder ein Servicegateway oder ein NAT-Gateway enthalten.
  2. Routingregeln müssen hinzugefügt werden, um Zugriff auf alle OCI-Services über eines dieser Gateways zu ermöglichen. Wenn der Quellcode oder die Befehle in der Build-Spezifikationsdatei Zugriff auf das Internet benötigen, müssen entsprechende Regeln vorhanden sein, bevor der Build ausgeführt wird. Dies ist erforderlich, da der gesamte ausgehende Traffic vom Build Runner durch das Netzwerk geleitet wird.

Die Build-Ausführung verläuft nicht erfolgreich, wenn Docker-Befehle in der Build-Spezifikation aus der Phase "Verwalteter Build" mit privatem Zugriff ausgeführt werden:

Dieser Fehler tritt auf, wenn die Phase "Verwalteter Build" mit privatem Zugriff konfiguriert ist und Sie Docker-Befehle in der Build-Spezifikationsdatei haben. Beispiel: Der Docker-Build verläuft nicht erfolgreich mit einem Fehler bei der DNS-Auflösung oder einem Verbindungstimeoutfehler, wenn die Docker-Datei Befehle enthält, die auf das Internet zugreifen. Ebenso verläuft die Docker-Ausführung mit DNS-Auflösungsfehler oder Verbindungs-Timeout nicht erfolgreich, wenn versucht wird, über den Container auf das Internet zuzugreifen.

Um dies zu beheben, verwenden Sie --network host in den Dockbefehlen, um das Docker-Containernetzwerk entsprechend zu konfigurieren. Beispiel: 
docker build --network host -t hello-world:1.0
docker run --network host hello-world:1.0